From sarikaya2012@gmail.com Mon Jul 1 08:32:37 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99B9A11E821D for ; Mon, 1 Jul 2013 08:32:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qGgNaPGhV5rj for ; Mon, 1 Jul 2013 08:32:37 -0700 (PDT) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 79C4311E821C for ; Mon, 1 Jul 2013 08:32:36 -0700 (PDT) Received: by mail-la0-f42.google.com with SMTP id eb20so4486056lab.29 for ; Mon, 01 Jul 2013 08:32:35 -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=/OskHYkUxZwON5RLqVXZMkoXOsnrqhcASQNz5rBHg9g=; b=MLzEZUb03T1wHgmjZWBocw0TVQ1i4aoagHd1NPJ9czZWlf8W2K/e7OEM5lrLGS/x5S veD3kBlSh3OdRlzDSOyy7fhdw4eOh5dnSFZvSEQIQ7lm1HnM/5qdxgea1VsJmcRZ35Xp S57Oylqc4ELxLeMQJC/G0rMIIjrnqEcyTPqC9C2fXe5AYMxjT00nDjUy4AW1IzPc2BBF YMnHy18oNoYXEPX8+PJOrpNWjNA/fMq3eCGhCWKqCiHkm/6zXxwvFl0QWjOHumjfESWf k4kj1s3pbaHDbvTsVW2D0xHfL+8aeeShm8lywCnFhV/+cD9YzLXK/5v/U5a1shNvXWys lghg== MIME-Version: 1.0 X-Received: by 10.112.61.199 with SMTP id s7mr11866466lbr.53.1372692755104; Mon, 01 Jul 2013 08:32:35 -0700 (PDT) Received: by 10.114.176.37 with HTTP; Mon, 1 Jul 2013 08:32:35 -0700 (PDT) In-Reply-To: References: Date: Mon, 1 Jul 2013 10:32:35 -0500 Message-ID: From: Behcet Sarikaya To: "Moses, Danny" Content-Type: multipart/alternative; boundary=001a1133d17a0dc89004e074f051 Cc: "dmm@ietf.org" Subject: Re: [DMM] Last Call comment on dmm requirements X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 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, 01 Jul 2013 15:32:37 -0000 --001a1133d17a0dc89004e074f051 Content-Type: text/plain; charset=ISO-8859-1 Hi Danny, On Sun, Jun 30, 2013 at 4:22 AM, Moses, Danny wrote: > Hi,**** > > ** ** > > I am sorry by this requirement sounds to me too generic and limiting. What > functionality must not be modified? Why?**** > > I am assuming that the motivation might be related to backwards > compatibility. > No. It is related to the protocol being network based. It does not make sense to get MN's help in such a protocol, because otherwise it is no longer network based. Network based protocols with MN modification blur the difference between client based and network based protocols. So everything becomes client based. > If this is the case, it is already addressed. Furthermore, I do not see a > reason why not to enable modifications that may enhance performance or > improve user experience as long as they are optional (hence do not violate > the backwards compatibility requirement).**** > > ** ** > > Regards,**** > > /Danny**** > > ** ** > > *From:* dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] *On Behalf Of *Behcet > Sarikaya > *Sent:* Saturday, June 29, 2013 00:35 > *To:* dmm@ietf.org > *Subject:* [DMM] Last Call comment on dmm requirements**** > > ** ** > > Add this requirement: > > R. XX. In network based dmm solutions, the mobile node MUST not be > modified. No changes on the mobile node behavior can be allowed. > > > Regards, > > Behcet**** > > --------------------------------------------------------------------- > A member of the Intel Corporation group of companies > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > --001a1133d17a0dc89004e074f051 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Danny,


On Sun, Jun 30, 2013 at 4:2= 2 AM, Moses, Danny <danny.moses@intel.com> wrote:

Hi,<= /p>

=A0<= /p>

I am sorry by this requir= ement sounds to me too generic and limiting. What functionality must not be= modified? Why?

I am assuming that the mo= tivation might be related to backwards compatibility.


No. It is related to the protocol being network based= . It does not make sense to get MN's help in such a protocol, because o= therwise it is no longer network based.

Network based protocols with= MN modification blur the difference between client based and network based= protocols.

So everything becomes client based.
=A0

If this is the case, it is already addressed. Fu= rthermore, I do not see a reason why not to enable modifications that may enhance performance or improve us= er experience as long as they are optional (hence do not violate the backwa= rds compatibility requirement).

=A0<= /p>

Regards,

=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0 /Danny

=A0<= /p>

From: dmm-bounces@ietf.org= [mailto:dmm-boun= ces@ietf.org] On Behalf Of Behcet Sarikaya
Sent: Saturday, June 29, 2013 00:35
To: dmm@ietf.org
Subject: [DMM] Last Call comment on dmm requirements

--------------------------------------------------------------------- A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.


--001a1133d17a0dc89004e074f051-- From Peter.McCann@huawei.com Mon Jul 1 09:03:22 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC00711E8289 for ; Mon, 1 Jul 2013 09:03:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APVJmcyWbDZh for ; Mon, 1 Jul 2013 09:03:17 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3D3F811E8291 for ; Mon, 1 Jul 2013 09:03:17 -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.5-GA FastPath queued) with ESMTP id AUO57935; Mon, 01 Jul 2013 16:03:08 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 1 Jul 2013 17:02:29 +0100 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 2 Jul 2013 00:02:36 +0800 Received: from dfweml512-mbx.china.huawei.com ([169.254.1.163]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.007; Mon, 1 Jul 2013 09:02:32 -0700 From: Peter McCann To: "sarikaya@ieee.org" , "Moses, Danny" Thread-Topic: [DMM] Last Call comment on dmm requirements Thread-Index: AQHOdnBxnKEmb7+5YEad3ImCY7V7CplP+tkQ Date: Mon, 1 Jul 2013 16:02:32 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE716F4E186@dfweml512-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.125.163] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dmm@ietf.org" Subject: Re: [DMM] Last Call comment on dmm requirements X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 16:03:22 -0000 This is not the netlmm working group. Client modifications are very=20 much in scope. I think that mobile nodes will at least need to be enhanced with more flexibility about the way they handle assigned addresses. The scope of mobility for a given address may be limited or it may cost resources to extend the scope too far with network-based means. The MN must be allowed to monitor its applications' use of IP addresses and release those addresses that are no longer used, and get a new IP address for new application connections. This does not necessarily involve a new protocol for the MN but is a modification of its usual behavior. -Pete Behcet Sarikaya wrote: > Hi Danny, >=20 >=20 >=20 > On Sun, Jun 30, 2013 at 4:22 AM, Moses, Danny > wrote: >=20 >=20 > Hi, >=20 >=20 >=20 > I am sorry by this requirement sounds to me too generic and limiting. > What functionality must not be modified? Why? >=20 > I am assuming that the motivation might be related to backwards=20 > compatibility. >=20 >=20 > No. It is related to the protocol being network based. It does not=20 > make sense to get MN's help in such a protocol, because otherwise it=20 > is no longer network based. >=20 > Network based protocols with MN modification blur the difference=20 > between client based and network based protocols. >=20 > So everything becomes client based. >=20 >=20 >=20 > If this is the case, it is already addressed. Furthermore, I do not=20 > see a reason why not to enable modifications that may enhance=20 > performance or improve user experience as long as they are optional=20 > (hence do not violate the backwards compatibility requirement). >=20 >=20 >=20 > Regards, >=20 > /Danny >=20 >=20 >=20 > From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of=20 > Behcet Sarikaya > Sent: Saturday, June 29, 2013 00:35 > To: dmm@ietf.org > Subject: [DMM] Last Call comment on dmm requirements >=20 >=20 >=20 > Add this requirement: >=20 > R. XX. In network based dmm solutions, the mobile node MUST not be=20 > modified. No changes on the mobile node behavior can be allowed. >=20 >=20 > Regards, >=20 > Behcet >=20 > ----------------------------------------------------------------- ---- > A member of the Intel Corporation group of companies >=20 > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > From sarikaya2012@gmail.com Mon Jul 1 09:49:30 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7F2521F99B3 for ; Mon, 1 Jul 2013 09:49:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2nmFAFLSwjrI for ; Mon, 1 Jul 2013 09:49:30 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id DFA8D21F99AF for ; Mon, 1 Jul 2013 09:49:24 -0700 (PDT) Received: by mail-la0-f48.google.com with SMTP id lx15so4537892lab.21 for ; Mon, 01 Jul 2013 09:49:23 -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=tXdCiF9Nb70Kser0kh7Q23y9QvOFyh1ImW5nqz3aZyg=; b=TEKDeFzFncAO2tBpkK6YcBQRj4Td79/sYJJk82SVWg7ODqFemHlF7RmzaS92WWczwa LYsfk0TB8Z8F3boV9GblBH4rzwbvGsfZEUgza6WiPhOKqICZiIg56WbHmyfjeG91v/Ea saxL7ZCIBmIeCbAF5MlLohm4lcnOpi/8/f4X4BIc1C/ZF6ZXAe93Y6cBbO4hUKgj5mce 8Hb0unpLXYyF248P2NAteu5GhwnUjv9RKO3PnLJk2h2fWsG3h5tj+bS1nAbVlxUrR0CC E/y59ziZ4g1xXA829i9It2tlydqdYDJz5KLTY8O1CmS847+BHJFcwsYilfKyQCLQC6Id wlkQ== MIME-Version: 1.0 X-Received: by 10.152.6.228 with SMTP id e4mr2665228laa.61.1372697363818; Mon, 01 Jul 2013 09:49:23 -0700 (PDT) Received: by 10.114.176.37 with HTTP; Mon, 1 Jul 2013 09:49:23 -0700 (PDT) In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716F4E186@dfweml512-mbx.china.huawei.com> References: <5963DDF1F751474D8DEEFDCDBEE43AE716F4E186@dfweml512-mbx.china.huawei.com> Date: Mon, 1 Jul 2013 11:49:23 -0500 Message-ID: From: Behcet Sarikaya To: Peter McCann Content-Type: multipart/alternative; boundary=089e013d0f8ac12d1004e07602d7 Cc: "dmm@ietf.org" Subject: Re: [DMM] Last Call comment on dmm requirements X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 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, 01 Jul 2013 16:49:30 -0000 --089e013d0f8ac12d1004e07602d7 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Jul 1, 2013 at 11:02 AM, Peter McCann wrote: > This is not the netlmm working group. Client modifications are very > much in scope. > > Who said so? The chair is not saying it. I would stay away from making big statements. > I think that mobile nodes will at least need to be enhanced with more > flexibility about the way they handle assigned addresses. The scope > of mobility for a given address may be limited or it may cost resources > to extend the scope too far with network-based means. The MN must be > allowed to monitor its applications' use of IP addresses and release > those addresses that are no longer used, and get a new IP address for > new application connections. This does not necessarily involve a new > protocol for the MN but is a modification of its usual behavior. > > Then let's not call such a protocol network-based :-). > -Pete > > > Behcet Sarikaya wrote: > > Hi Danny, > > > > > > > > On Sun, Jun 30, 2013 at 4:22 AM, Moses, Danny > > wrote: > > > > > > Hi, > > > > > > > > I am sorry by this requirement sounds to me too generic and > limiting. > > What functionality must not be modified? Why? > > > > I am assuming that the motivation might be related to backwards > > compatibility. > > > > > > No. It is related to the protocol being network based. It does not > > make sense to get MN's help in such a protocol, because otherwise it > > is no longer network based. > > > > Network based protocols with MN modification blur the difference > > between client based and network based protocols. > > > > So everything becomes client based. > > > > > > > > If this is the case, it is already addressed. Furthermore, I do not > > see a reason why not to enable modifications that may enhance > > performance or improve user experience as long as they are optional > > (hence do not violate the backwards compatibility requirement). > > > > > > > > Regards, > > > > /Danny > > > > > > > > From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On > Behalf Of > > Behcet Sarikaya > > Sent: Saturday, June 29, 2013 00:35 > > To: dmm@ietf.org > > Subject: [DMM] Last Call comment on dmm requirements > > > > > > > > Add this requirement: > > > > R. XX. In network based dmm solutions, the mobile node MUST not be > > modified. No changes on the mobile node behavior can be allowed. > > > > > > Regards, > > > > Behcet > > > > ----------------------------------------------------------------- > ---- > > A member of the Intel Corporation group of companies > > > > This e-mail and any attachments may contain confidential material > for > > the sole use of the intended recipient(s). Any review or > distribution > > by others is strictly prohibited. If you are not the intended > > recipient, please contact the sender and delete all copies. > > > > > > --089e013d0f8ac12d1004e07602d7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Mon, Jul 1, 2013 at 11:02 AM, Peter M= cCann <Peter.McCann@huawei.com> wrote:
This is not the netlmm working group. =A0Client modifications are very
much in scope.


Who said so?

The chair is not saying it.
I would stay away from making big statements.
=A0
I think that mobile nodes will at least need to be enhanced with more
flexibility about the way they handle assigned addresses. =A0The scope
of mobility for a given address may be limited or it may cost resources
to extend the scope too far with network-based means. =A0The MN must be
allowed to monitor its applications' use of IP addresses and release those addresses that are no longer used, and get a new IP address for
new application connections. =A0This does not necessarily involve a new
protocol for the MN but is a modification of its usual behavior.



Then let's not call such a protocol netwo= rk-based :-).

=A0
-Pete


Behcet Sarikaya wrote:
> Hi Danny,
>
>
>
> On Sun, Jun 30, 2013 at 4:22 AM, Moses, Danny <danny.moses@intel.com>
> wrote:
>
>
> =A0 =A0 =A0 Hi,
>
>
>
> =A0 =A0 =A0 I am sorry by this requirement sounds to me too generic an= d limiting.
> What functionality must not be modified? Why?
>
> =A0 =A0 =A0 I am assuming that the motivation might be related to back= wards
> compatibility.
>
>
> No. It is related to the protocol being network based. It does not
> make sense to get MN's help in such a protocol, because otherwise = it
> is no longer network based.
>
> Network based protocols with MN modification blur the difference
> between client based and network based protocols.
>
> So everything becomes client based.
>
>
>
> =A0 =A0 =A0 If this is the case, it is already addressed. Furthermore,= I do not
> see a reason why not to enable modifications that may enhance
> performance or improve user experience as long as they are optional > (hence do not violate the backwards compatibility requirement).
>
>
>
> =A0 =A0 =A0 Regards,
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 /Danny
>
>
>
> =A0 =A0 =A0 From: dmm-bounces@= ietf.org [mailto:dmm-bounces@ie= tf.org] On Behalf Of
> Behcet Sarikaya
> =A0 =A0 =A0 Sent: Saturday, June 29, 2013 00:35
> =A0 =A0 =A0 To: dmm@ietf.org
> =A0 =A0 =A0 Subject: [DMM] Last Call comment on dmm requirements
>
>
>
> =A0 =A0 =A0 Add this requirement:
>
> =A0 =A0 =A0 R. XX. In network based dmm solutions, the mobile node MUS= T not be
> modified. No changes on the mobile node behavior can be allowed.
>
>
> =A0 =A0 =A0 Regards,
>
> =A0 =A0 =A0 Behcet
>
> =A0 =A0 =A0 ----------------------------------------------------------= ------- ----
> =A0 =A0 =A0 A member of the Intel Corporation group of companies
>
> =A0 =A0 =A0 This e-mail and any attachments may contain confidential m= aterial for
> =A0 =A0 =A0 the sole use of the intended recipient(s). Any review or d= istribution
> =A0 =A0 =A0 by others is strictly prohibited. If you are not the inten= ded
> =A0 =A0 =A0 recipient, please contact the sender and delete all copies= .
>




--089e013d0f8ac12d1004e07602d7-- From hassan.aliahmad@orange.com Mon Jul 1 10:32:10 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F232311E8135 for ; Mon, 1 Jul 2013 10:32:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bsmgZ2VU6kQN for ; Mon, 1 Jul 2013 10:32:04 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id 3388611E80D7 for ; Mon, 1 Jul 2013 10:32:04 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id D94B6264570; Mon, 1 Jul 2013 19:32:02 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id BA51427C08B; Mon, 1 Jul 2013 19:32:02 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Mon, 1 Jul 2013 19:32:02 +0200 From: To: "'sarikaya@ieee.org'" , Peter McCann Thread-Topic: [DMM] Last Call comment on dmm requirements Thread-Index: AQHOdnr70r6+nZrz5ESOf2c211Um85lQEsYA Date: Mon, 1 Jul 2013 17:32:02 +0000 Message-ID: <28905_1372699922_51D1BD12_28905_3190_1_C5B6A9A3D7D5C941A08B34159DEFE902078BCA87@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <5963DDF1F751474D8DEEFDCDBEE43AE716F4E186@dfweml512-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, fr-FR Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: multipart/alternative; boundary="_000_C5B6A9A3D7D5C941A08B34159DEFE902078BCA87PEXCVZYM11corpo_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.7.1.81520 Cc: "dmm@ietf.org" Subject: Re: [DMM] Last Call comment on dmm requirements X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 17:32:10 -0000 --_000_C5B6A9A3D7D5C941A08B34159DEFE902078BCA87PEXCVZYM11corpo_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Behcet, All, I think that almost all current DMM approaches that are based on MIPv6 or P= MIPv6 require a new source address selection (SAS) mechanism, even the PMIP= v6-based ones. Yes, in part of them, the MN is not required to participate in the mobility= -related signaling... and those could be categorized network-based. Well, "MN MUST not be modified. No changes on the MN behavior can be allowe= d" is a very strict constraint that, as I believe, blocks all current DMM p= roposals. Best regards, Hassan From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of Behce= t Sarikaya Sent: Monday, July 01, 2013 6:49 PM To: Peter McCann Cc: dmm@ietf.org Subject: Re: [DMM] Last Call comment on dmm requirements On Mon, Jul 1, 2013 at 11:02 AM, Peter McCann > wrote: This is not the netlmm working group. Client modifications are very much in scope. Who said so? The chair is not saying it. I would stay away from making big statements. I think that mobile nodes will at least need to be enhanced with more flexibility about the way they handle assigned addresses. The scope of mobility for a given address may be limited or it may cost resources to extend the scope too far with network-based means. The MN must be allowed to monitor its applications' use of IP addresses and release those addresses that are no longer used, and get a new IP address for new application connections. This does not necessarily involve a new protocol for the MN but is a modification of its usual behavior. Then let's not call such a protocol network-based :-). -Pete Behcet Sarikaya wrote: > Hi Danny, > > > > On Sun, Jun 30, 2013 at 4:22 AM, Moses, Danny > > wrote: > > > Hi, > > > > I am sorry by this requirement sounds to me too generic and limitin= g. > What functionality must not be modified? Why? > > I am assuming that the motivation might be related to backwards > compatibility. > > > No. It is related to the protocol being network based. It does not > make sense to get MN's help in such a protocol, because otherwise it > is no longer network based. > > Network based protocols with MN modification blur the difference > between client based and network based protocols. > > So everything becomes client based. > > > > If this is the case, it is already addressed. Furthermore, I do not > see a reason why not to enable modifications that may enhance > performance or improve user experience as long as they are optional > (hence do not violate the backwards compatibility requirement). > > > > Regards, > > /Danny > > > > From: dmm-bounces@ietf.org [mailto:dmm= -bounces@ietf.org] On Behalf Of > Behcet Sarikaya > Sent: Saturday, June 29, 2013 00:35 > To: dmm@ietf.org > Subject: [DMM] Last Call comment on dmm requirements > > > > Add this requirement: > > R. XX. In network based dmm solutions, the mobile node MUST not be > modified. No changes on the mobile node behavior can be allowed. > > > Regards, > > Behcet > > ----------------------------------------------------------------- -= --- > A member of the Intel Corporation group of companies > > This e-mail and any attachments may contain confidential material f= or > the sole use of the intended recipient(s). Any review or distributi= on > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_C5B6A9A3D7D5C941A08B34159DEFE902078BCA87PEXCVZYM11corpo_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Behcet, All,

 <= /p>

I think that almost all c= urrent DMM approaches that are based on MIPv6 or PMIPv6 require a new sourc= e address selection (SAS) mechanism, even the PMIPv6-based ones.

 <= /p>

Yes, in part of them, the= MN is not required to participate in the mobility-related signaling…= and those could be categorized network-based.

 <= /p>

Well, “MN MUST not = be modified. No changes on the MN behavior can be allowed” is a very = strict constraint that, as I believe, blocks all current DMM proposals.

 <= /p>

Best regards,<= /span>

Hassan<= /p>

 <= /p>

 <= /p>

From: dmm-boun= ces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of Behcet Sarikaya
Sent: Monday, July 01, 2013 6:49 PM
To: Peter McCann
Cc: dmm@ietf.org
Subject: Re: [DMM] Last Call comment on dmm requirements<= /span>

 

 

On Mon, Jul 1, 2013 at 11:02 AM, Peter McCann <Peter.McCann@hua= wei.com> wrote:

This is not the netlm= m working group.  Client modifications are very
much in scope.


Who said so?

The chair is not saying it.

I would stay away from making big statements.
 

I think that mobile n= odes will at least need to be enhanced with more
flexibility about the way they handle assigned addresses.  The scope of mobility for a given address may be limited or it may cost resources
to extend the scope too far with network-based means.  The MN must be<= br> allowed to monitor its applications' use of IP addresses and release
those addresses that are no longer used, and get a new IP address for
new application connections.  This does not necessarily involve a new<= br> protocol for the MN but is a modification of its usual behavior.=



Then let's not call such a protocol network-based :-).

 

-Pete



Behcet Sarikaya wrote:
> Hi Danny,
>
>
>
> On Sun, Jun 30, 2013 at 4:22 AM, Moses, Danny <danny.moses@intel.com>
> wrote:
>
>
>       Hi,
>
>
>
>       I am sorry by this requirement sounds to me too g= eneric and limiting.
> What functionality must not be modified? Why?
>
>       I am assuming that the motivation might be relate= d to backwards
> compatibility.
>
>
> No. It is related to the protocol being network based. It does not
> make sense to get MN's help in such a protocol, because otherwise it > is no longer network based.
>
> Network based protocols with MN modification blur the difference
> between client based and network based protocols.
>
> So everything becomes client based.
>
>
>
>       If this is the case, it is already addressed. Fur= thermore, I do not
> see a reason why not to enable modifications that may enhance
> performance or improve user experience as long as they are optional
> (hence do not violate the backwards compatibility requirement).
>
>
>
>       Regards,
>
>                     =   /Danny
>
>
>
>       From: dmm= -bounces@ietf.org [mailto:dmm-b= ounces@ietf.org] On Behalf Of
> Behcet Sarikaya
>       Sent: Saturday, June 29, 2013 00:35
>       To: dmm@ietf.org<= /a>
>       Subject: [DMM] Last Call comment on dmm requireme= nts
>
>
>
>       Add this requirement:
>
>       R. XX. In network based dmm solutions, the mobile= node MUST not be
> modified. No changes on the mobile node behavior can be allowed.
>
>
>       Regards,
>
>       Behcet
>
>       -------------------------------------------------= ---------------- ----
>       A member of the Intel Corporation group of compan= ies
>
>       This e-mail and any attachments may contain confi= dential material for
>       the sole use of the intended recipient(s). Any re= view or distribution
>       by others is strictly prohibited. If you are not = the intended
>       recipient, please contact the sender and delete a= ll copies.
>


 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_C5B6A9A3D7D5C941A08B34159DEFE902078BCA87PEXCVZYM11corpo_-- From Peter.McCann@huawei.com Mon Jul 1 11:00:32 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7FD5411E819C for ; Mon, 1 Jul 2013 11:00:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQV2y4n29HBa for ; Mon, 1 Jul 2013 11:00:27 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id AEAF911E8144 for ; Mon, 1 Jul 2013 11:00:24 -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.5-GA FastPath queued) with ESMTP id AUO63866; Mon, 01 Jul 2013 17:55:10 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 1 Jul 2013 18:55:00 +0100 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 1 Jul 2013 18:55:07 +0100 Received: from dfweml512-mbx.china.huawei.com ([169.254.1.163]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.007; Mon, 1 Jul 2013 10:55:02 -0700 From: Peter McCann To: "sarikaya@ieee.org" Thread-Topic: [DMM] Last Call comment on dmm requirements Thread-Index: AQHOdnBxnKEmb7+5YEad3ImCY7V7CplP+tkQgACDf4D//5t7cA== Date: Mon, 1 Jul 2013 17:55:02 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE716F4E1D8@dfweml512-mbx.china.huawei.com> References: <5963DDF1F751474D8DEEFDCDBEE43AE716F4E186@dfweml512-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.125.163] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dmm@ietf.org" Subject: Re: [DMM] Last Call comment on dmm requirements X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jul 2013 18:00:32 -0000 Behcet Sarikaya wrote: >=20 >=20 > On Mon, Jul 1, 2013 at 11:02 AM, Peter McCann > wrote: >=20 >=20 > This is not the netlmm working group. Client modifications are very > much in scope. >=20 >=20 >=20 >=20 > Who said so? >=20 > The chair is not saying it. Yes he is: Jouni Korhonen wrote: > The charter makes it clear that solutions that may involve a host > are within our scope. >=20 > - JOuni Behcet Sarikaya wrote:=20 > I would stay away from making big statements. I would stay away from making incorrect statements. > I think that mobile nodes will at least need to be enhanced with more > flexibility about the way they handle assigned addresses. The scope > of mobility for a given address may be limited or it may cost resources > to extend the scope too far with network-based means. The MN must be > allowed to monitor its applications' use of IP addresses and release > those addresses that are no longer used, and get a new IP address for > new application connections. This does not necessarily involve a new > protocol for the MN but is a modification of its usual behavior. >=20 >=20 > Then let's not call such a protocol network-based :-). There will be a network component and a (possibly optional) client componen= t. The network component will get you only so far. Then behavior and/or proto= cols on the client will be required. -Pete From rute.sofia@ulusofona.pt Wed Jul 3 03:03:33 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 374F321F9C25 for ; Wed, 3 Jul 2013 03:03:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1r0UqD1PYZSD for ; Wed, 3 Jul 2013 03:03:28 -0700 (PDT) Received: from mail-bk0-f46.google.com (mail-bk0-f46.google.com [209.85.214.46]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7A621F9C20 for ; Wed, 3 Jul 2013 03:03:27 -0700 (PDT) Received: by mail-bk0-f46.google.com with SMTP id na10so2791862bkb.5 for ; Wed, 03 Jul 2013 03:03:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding :x-gm-message-state; bh=6tq02BpkWgZ64A96xVSX0ps6XChq8YOWkr2zDRk78WY=; b=ccmqslfouK7R6yx21IurrERdE0MJyUzykzIfmbosYkmmOH+MHewBDRNQm903vAt6A/ kWKbIMfvIudD0MqGt1/sIeBXURHmad7QhKNZohji1vkmc5ZeRAbkusxwAO5fPzONbZV8 u6Lcrpf8X7s8VldG3LKi/BseuDi0kWD9naTH6oSlg8bnlcqad/tzIR5WCvWwyuoujVex QSzf96b3u86tqQk07bQCp/wnI+lfeQLxZpxjKNrkOTxpvHPHmhmhmB2ZR14zf0drPq34 xqBAm7vXq9jKICfVgCs80qGvXGByMsUsINXcg0ZoVY9GsjzoFsfCZIcL6k4zFg8ghqAp a8CQ== X-Received: by 10.205.12.135 with SMTP id pi7mr1219bkb.173.1372845802901; Wed, 03 Jul 2013 03:03:22 -0700 (PDT) Received: from linux-8b5g.lan (sitivoip.ulusofona.pt. [193.137.75.156]) by mx.google.com with ESMTPSA id ok9sm13166682bkb.8.2013.07.03.03.03.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Jul 2013 03:03:21 -0700 (PDT) Message-ID: <51D3F6E7.6080800@ulusofona.pt> Date: Wed, 03 Jul 2013 11:03:19 +0100 From: Rute Sofia User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130510 Thunderbird/17.0.6 MIME-Version: 1.0 To: Jouni Korhonen References: <51C82485.1000906@ulusofona.pt> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQlCli1805iaeV1G+FwysLmMy2JebG+H14pM3PuRoWK8vbN3wdaTw6kTQ9Fz7WwA1T16UJtw Cc: dmm@ietf.org, dmm-chairs@tools.ietf.org Subject: Re: [DMM] DMM at IETF 87, contributions X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 10:03:33 -0000 Hello Jouni, any news on the agenda? I do have a presentation to propose but as said this would require to understand when is the meeting. Otherwise I will leave it for November if there is room. The proposal relates with the use of roaming estimation towards DMM architectures, as a way to reduced required signaling. BR Rute On 06/25/2013 08:41 PM, Jouni Korhonen wrote: > The IETF wide draft agenda is due 27th June. We are still supposed to have > our DMM WG meeting. Agenda slots for the WG meeting are given typically using > the algorithm: first WG items, second chartered/milestoned but still individual > work usually using fifo order, and last the rest in fifo order till the slot > time runs out. > > - Jouni > > > On Jun 24, 2013, at 1:50 PM, Rute Sofia wrote: > >> Dear Jouni and Julien, >> >> as the IETF 87th meeting is approaching, I would like to know if the 2-hour reserved DMM slot is still up, and if there is still room to propose contributions. >> >> Best Regards, >> >> -- >> Melhores Cumprimentos/Best Regards/mit freundlichen Gruessen, >> >> Rute Carvalho Sofia >> >> >> ........................................................ >> Rute Sofia, PhD (rute.sofia@ulusofona.pt) >> SITILABS - R&D in Informatics Systems and Technologies >> Scientific Director for Technology >> University Lusofona, Portugal >> rute.sofia@ulusofona.pt >> >> http://siti.ulusofona.pt >> Tel.: +351 21 7505021/20 >> ....................................................... >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm -- Melhores Cumprimentos/Best Regards/mit freundlichen Gruessen, Rute Carvalho Sofia ........................................................ Rute Sofia, PhD (rute.sofia@ulusofona.pt) SITILABS - R&D in Informatics Systems and Technologies Scientific Director for Technology University Lusofona, Portugal rute.sofia@ulusofona.pt http://siti.ulusofona.pt Tel.: +351 21 7505021/20 ....................................................... From Dirk.von-Hugo@telekom.de Wed Jul 3 03:34:24 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B6BA21F934C for ; Wed, 3 Jul 2013 03:34:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kqsimlpIujVd for ; Wed, 3 Jul 2013 03:34:19 -0700 (PDT) Received: from tcmail93.telekom.de (tcmail93.telekom.de [80.149.113.205]) by ietfa.amsl.com (Postfix) with ESMTP id 17FB521F91C4 for ; Wed, 3 Jul 2013 03:34:18 -0700 (PDT) Received: from he113470.emea1.cds.t-internal.com ([10.134.93.128]) by tcmail91.telekom.de with ESMTP/TLS/AES128-SHA; 03 Jul 2013 12:34:16 +0200 Received: from HE113484.emea1.cds.t-internal.com ([10.134.93.124]) by HE113470.emea1.cds.t-internal.com ([::1]) with mapi; Wed, 3 Jul 2013 12:34:16 +0200 From: To: , Date: Wed, 3 Jul 2013 12:34:14 +0200 Thread-Topic: [DMM] DMM at IETF 87, contributions Thread-Index: Ac531JtsxuIEtrnuQ7eZNgJGFngtRQAA/k1g Message-ID: <05C81A773E48DD49B181B04BA21A342A2C5269A3B2@HE113484.emea1.cds.t-internal.com> References: <51C82485.1000906@ulusofona.pt> <51D3F6E7.6080800@ulusofona.pt> In-Reply-To: <51D3F6E7.6080800@ulusofona.pt> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: dmm@ietf.org, dmm-chairs@tools.ietf.org Subject: Re: [DMM] DMM at IETF 87, contributions X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Jul 2013 10:34:24 -0000 Dear all, According to http://datatracker.ietf.org/meeting/agenda/ DMM session will b= e=20 THURSDAY, August 1, 2013, 0900-1020, 1030-1130 CEST Thursday Morning Sessio= n I & II=20 Best regards Dirk -----Original Message----- From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of Rute = Sofia Sent: Mittwoch, 3. Juli 2013 12:03 To: Jouni Korhonen Cc: dmm@ietf.org; dmm-chairs@tools.ietf.org Subject: Re: [DMM] DMM at IETF 87, contributions Hello Jouni, any news on the agenda? I do have a presentation to propose but as said thi= s would require to understand when is the meeting. Otherwise I will leave i= t for November if there is room. The proposal relates with the use of roaming estimation towards DMM archite= ctures, as a way to reduced required signaling. BR Rute On 06/25/2013 08:41 PM, Jouni Korhonen wrote: > The IETF wide draft agenda is due 27th June. We are still supposed to hav= e > our DMM WG meeting. Agenda slots for the WG meeting are given typically u= sing > the algorithm: first WG items, second chartered/milestoned but still indi= vidual > work usually using fifo order, and last the rest in fifo order till the s= lot > time runs out. > > - Jouni > > > On Jun 24, 2013, at 1:50 PM, Rute Sofia wrote: > >> Dear Jouni and Julien, >> >> as the IETF 87th meeting is approaching, I would like to know if the 2-h= our reserved DMM slot is still up, and if there is still room to propose co= ntributions. >> >> Best Regards, >> >> --=20 >> Melhores Cumprimentos/Best Regards/mit freundlichen Gruessen, >> >> Rute Carvalho Sofia >> >> >> ........................................................ >> Rute Sofia, PhD (rute.sofia@ulusofona.pt) >> SITILABS - R&D in Informatics Systems and Technologies >> Scientific Director for Technology >> University Lusofona, Portugal >> rute.sofia@ulusofona.pt >> >> http://siti.ulusofona.pt >> Tel.: +351 21 7505021/20 >> ....................................................... >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm --=20 Melhores Cumprimentos/Best Regards/mit freundlichen Gruessen, Rute Carvalho Sofia ........................................................ Rute Sofia, PhD (rute.sofia@ulusofona.pt) SITILABS - R&D in Informatics Systems and Technologies Scientific Director for Technology University Lusofona, Portugal rute.sofia@ulusofona.pt http://siti.ulusofona.pt Tel.: +351 21 7505021/20 ....................................................... _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm From danny.moses@intel.com Thu Jul 4 00:26:28 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E06821F9EE8 for ; Thu, 4 Jul 2013 00:26:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Le3lbz9EYLTu for ; Thu, 4 Jul 2013 00:26:23 -0700 (PDT) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by ietfa.amsl.com (Postfix) with ESMTP id 13E6721F9ECB for ; Thu, 4 Jul 2013 00:26:22 -0700 (PDT) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by orsmga102.jf.intel.com with ESMTP; 04 Jul 2013 00:23:52 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.87,993,1363158000"; d="scan'208";a="360353905" Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54]) by fmsmga001.fm.intel.com with ESMTP; 04 Jul 2013 00:26:53 -0700 Received: from fmsmsx153.amr.corp.intel.com (10.19.17.7) by FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 4 Jul 2013 00:25:56 -0700 Received: from hasmsx105.ger.corp.intel.com (10.184.198.19) by FMSMSX153.amr.corp.intel.com (10.19.17.7) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 4 Jul 2013 00:25:48 -0700 Received: from hasmsx106.ger.corp.intel.com ([169.254.2.62]) by HASMSX105.ger.corp.intel.com ([169.254.1.111]) with mapi id 14.03.0123.003; Thu, 4 Jul 2013 10:24:22 +0300 From: "Moses, Danny" To: Peter McCann , "sarikaya@ieee.org" Thread-Topic: [DMM] Last Call comment on dmm requirements Thread-Index: AQHOdEfl+7AH7k/BjkWBtja32df3R5lN/F+ggAHJMoCAAAheAIAEUd8Q Date: Thu, 4 Jul 2013 07:24:22 +0000 Message-ID: References: <5963DDF1F751474D8DEEFDCDBEE43AE716F4E186@dfweml512-mbx.china.huawei.com> In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716F4E186@dfweml512-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.184.70.12] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Cc: "dmm@ietf.org" Subject: Re: [DMM] Last Call comment on dmm requirements X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Jul 2013 07:26:28 -0000 I agree that one example of optimizing network overhead is by improving the= mobile node's usage of it source IP address and I am sure there are more e= xamples. So the proposed new requirement is too restrictive. Having said that, I do not think we should allow functionality that will br= eak if backwards compatibility is not maintained. Only optimizations that a= re optional. Regards, /Danny -----Original Message----- From: Peter McCann [mailto:Peter.McCann@huawei.com] = Sent: Monday, July 01, 2013 19:03 To: sarikaya@ieee.org; Moses, Danny Cc: dmm@ietf.org Subject: RE: [DMM] Last Call comment on dmm requirements This is not the netlmm working group. Client modifications are very much i= n scope. I think that mobile nodes will at least need to be enhanced with more flexi= bility about the way they handle assigned addresses. The scope of mobility= for a given address may be limited or it may cost resources to extend the = scope too far with network-based means. The MN must be allowed to monitor = its applications' use of IP addresses and release those addresses that are = no longer used, and get a new IP address for new application connections. = This does not necessarily involve a new protocol for the MN but is a modifi= cation of its usual behavior. -Pete Behcet Sarikaya wrote: > Hi Danny, > = > = > = > On Sun, Jun 30, 2013 at 4:22 AM, Moses, Danny > wrote: > = > = > Hi, > = > = > = > I am sorry by this requirement sounds to me too generic and limiting. > What functionality must not be modified? Why? > = > I am assuming that the motivation might be related to backwards = > compatibility. > = > = > No. It is related to the protocol being network based. It does not = > make sense to get MN's help in such a protocol, because otherwise it = > is no longer network based. > = > Network based protocols with MN modification blur the difference = > between client based and network based protocols. > = > So everything becomes client based. > = > = > = > If this is the case, it is already addressed. Furthermore, I do not = > see a reason why not to enable modifications that may enhance = > performance or improve user experience as long as they are optional = > (hence do not violate the backwards compatibility requirement). > = > = > = > Regards, > = > /Danny > = > = > = > From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of = > Behcet Sarikaya > Sent: Saturday, June 29, 2013 00:35 > To: dmm@ietf.org > Subject: [DMM] Last Call comment on dmm requirements > = > = > = > Add this requirement: > = > R. XX. In network based dmm solutions, the mobile node MUST not be = > modified. No changes on the mobile node behavior can be allowed. > = > = > Regards, > = > Behcet > = > ----------------------------------------------------------------- ---- > A member of the Intel Corporation group of companies > = > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. > --------------------------------------------------------------------- A member of the Intel Corporation group of companies This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. From alper.yegin@yegin.org Mon Jul 8 08:30:37 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6F6821F9AA3 for ; Mon, 8 Jul 2013 08:30:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4uKBFMdtmEZY for ; Mon, 8 Jul 2013 08:30:33 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id A923521F8E2A for ; Mon, 8 Jul 2013 08:30:32 -0700 (PDT) Received: from [172.20.10.4] ([188.38.41.250]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0LcB81-1UX5nB2DlV-00jpfZ; Mon, 08 Jul 2013 11:30:26 -0400 From: Alper Yegin Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 8 Jul 2013 18:30:22 +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:kphHpsaHoIROI54TjX/XPT+mHEMLpUCnVZbJYsWTLdM 7dRJRxjVWyArS6c93/SeZLjnNb3lFAUIUiyBMaZyQTwC3RxzpJ 092qLyEQ40TGbOIX6sSeFN56HKTzlZh/LtTB239OiveU1ml+Pr FG3eAuSj/MLt4EKfSCldxrhr+L/L1mHeEeABn7qCRPpsJ96Gi3 JXmIDeNgI8LWvvW3Jk3w1xJdQvgN5WWvZRJcER8T7HPF+uv8DX 8ymSxwr0bkVYa65d80pNhAa+wD7BWF7cVbbvTZcAGqUClgJFu1 BFOS93Q8T+wgMXYfkHAS/i3+B2rPOCqGjxBtN7UAv8N6uv60hq o3aog7l4yryRFMuCdGdphr9gWTYdMTodvwUlVKPOZY9mhgG0yS mjh9Iy1qEpyxA== Subject: [DMM] Two new drafts X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jul 2013 15:30:38 -0000 Hello dear DMM folks, We published the following two new drafts which relate to the DMM WG. http://www.ietf.org/id/draft-yegin-dmm-cnet-homing-00.txt http://www.ietf.org/id/draft-yegin-dmm-ondemand-mobility-00.txt We'd appreciate if you can read and share your comments. (Related IPR statements will be posted on the IETF site soon) Cheers, Alper From sgundave@cisco.com Mon Jul 8 22:22:54 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F78F21F9F3D for ; Mon, 8 Jul 2013 22:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K12j2cGjRkVZ for ; Mon, 8 Jul 2013 22:22:49 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 7045621F9F50 for ; Mon, 8 Jul 2013 22:22:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1844; q=dns/txt; s=iport; t=1373347366; x=1374556966; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=z+E2cFtYtFTB9kLsLjY8GPsUOgHFv7SP2UEYZ+yZfU0=; b=boacxkDWlyd3afGm/lb6YQ97gIkKP87b6ggOvUtYI5WmqUyKtxKGWGDL EkOBs3oaW3l6sfWP7lbJRIESVeki5oLoliNjG6juljkgQ0Q5lzag7AwbC 2Y6SlWCMg/v7UMPrBnJyZSlyPHdoUZ2CE+VTxDh1hJ9qF4yAajjPpNffy Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgoFAByd21GtJV2a/2dsb2JhbABbFoJzMk3BAoEdFnSCJQEEAQEBax0BCCJLCyUCBAESCAGIBgy4bo86OIMHaQOYfJAfgxGCKA X-IronPort-AV: E=Sophos;i="4.87,1025,1363132800"; d="scan'208";a="232387457" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-2.cisco.com with ESMTP; 09 Jul 2013 05:22:45 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r695Mjwg003128 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Jul 2013 05:22:45 GMT Received: from xmb-rcd-x03.cisco.com ([169.254.7.100]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Tue, 9 Jul 2013 00:22:45 -0500 From: "Sri Gundavelli (sgundave)" To: Alper Yegin , "dmm@ietf.org" Thread-Topic: [DMM] Two new drafts Thread-Index: AQHOfGRX/VWckbuYCE6YJLmoLYcGfw== Date: Tue, 9 Jul 2013 05:22:45 +0000 Message-ID: <24C0F3E22276D9438D6F366EB89FAEA8103223DB@xmb-rcd-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.32.246.213] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [DMM] Two new drafts X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 05:22:54 -0000 Hi Alper, Thanks for sharing the documents. I did a quick review of the dmm-ondemand draft. This is inline with my thinking as well. IMO, the following base semantics will allow us to realize some of the DMM deployment models. - Prefix Coloring/ Coloring of IP addresses based on the properties - Delivering the properties as meta-data in address assignment procedures (ND, DHCP ..) - Evolving the source address selection Rules, allowing application to pick source address based on the requirements With these semantics, a UE can obtain multiple IP addresses with different properties, bind applications to those addresses based on the application requirements, roam within the network loosing some local addresses and generating some new ones ... =20 Slides from 2010 I think ..? http://www.psg.com/~charliep/txt/ietf81/alt_mext/Evolving-The-SAS-Rules-for -Mobility-Awareness-2.pdf Good to see this. Hope we make progress on these base work such as prefix coloring =8Awhich are the enablers .. http://www.ietf.org/id/draft-korhonen-6man-prefix-properties-01.txt http://datatracker.ietf.org/doc/draft-bhandari-dhc-class-based-prefix/ Your proposal can leverage the above work. Regards Sri On 7/8/13 8:30 AM, "Alper Yegin" wrote: >Hello dear DMM folks, > >We published the following two new drafts which relate to the DMM WG. > >http://www.ietf.org/id/draft-yegin-dmm-cnet-homing-00.txt > >http://www.ietf.org/id/draft-yegin-dmm-ondemand-mobility-00.txt > >We'd appreciate if you can read and share your comments. > >(Related IPR statements will be posted on the IETF site soon) > >Cheers, > >Alper > > >_______________________________________________ >dmm mailing list >dmm@ietf.org >https://www.ietf.org/mailman/listinfo/dmm From seiljeon@av.it.pt Tue Jul 9 03:02:59 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7DED21F9FDC for ; Tue, 9 Jul 2013 03:02:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1IQLJOcnJ51f for ; Tue, 9 Jul 2013 03:02:55 -0700 (PDT) Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id 1621321F9FDA for ; Tue, 9 Jul 2013 03:02:54 -0700 (PDT) Received: from [188.81.162.140] (account seiljeon@av.it.pt HELO SeilATNOG) by av.it.pt (CommuniGate Pro SMTP 5.4.2) with ESMTPSA id 70038413; Tue, 09 Jul 2013 11:02:52 +0100 From: "Seil Jeon" To: "'Sri Gundavelli \(sgundave\)'" References: <24C0F3E22276D9438D6F366EB89FAEA8103223DB@xmb-rcd-x03.cisco.com> In-Reply-To: <24C0F3E22276D9438D6F366EB89FAEA8103223DB@xmb-rcd-x03.cisco.com> Date: Tue, 9 Jul 2013 11:02:53 +0100 Message-ID: <002501ce7c8b$7b532cf0$71f986d0$@av.it.pt> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJajx5StVCtTO1CSyUUnVj/sOa/WphD9u5A Content-Language: ko Cc: dmm@ietf.org Subject: Re: [DMM] Two new drafts X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 10:02:59 -0000 Hi Sri, Picking source address by an application would be the right way to go? = I've known that's the work of the middleware. The middleware needs to be aware of the applications and thus to act properly. Regards Seil -----Original Message----- From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of = Sri Gundavelli (sgundave) Sent: Tuesday, July 09, 2013 6:23 AM To: Alper Yegin; dmm@ietf.org Subject: Re: [DMM] Two new drafts Hi Alper, Thanks for sharing the documents. I did a quick review of the dmm-ondemand draft. This is inline with my thinking as well. IMO, the following base semantics will allow us to = realize some of the DMM deployment models. - Prefix Coloring/ Coloring of IP addresses based on the properties - Delivering the properties as meta-data in address assignment = procedures (ND, DHCP ..) - Evolving the source address selection Rules, allowing application to = pick source address based on the requirements With these semantics, a UE can obtain multiple IP addresses with = different properties, bind applications to those addresses based on the = application requirements, roam within the network loosing some local addresses and generating some new ones ... =20 Slides from 2010 I think ..? http://www.psg.com/~charliep/txt/ietf81/alt_mext/Evolving-The-SAS-Rules-f= or -Mobility-Awareness-2.pdf Good to see this. Hope we make progress on these base work such as = prefix coloring =A9which are the enablers .. http://www.ietf.org/id/draft-korhonen-6man-prefix-properties-01.txt http://datatracker.ietf.org/doc/draft-bhandari-dhc-class-based-prefix/ Your proposal can leverage the above work. Regards Sri On 7/8/13 8:30 AM, "Alper Yegin" wrote: >Hello dear DMM folks, > >We published the following two new drafts which relate to the DMM WG. > >http://www.ietf.org/id/draft-yegin-dmm-cnet-homing-00.txt > >http://www.ietf.org/id/draft-yegin-dmm-ondemand-mobility-00.txt > >We'd appreciate if you can read and share your comments. > >(Related IPR statements will be posted on the IETF site soon) > >Cheers, > >Alper > > >_______________________________________________ >dmm mailing list >dmm@ietf.org >https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm From sgundave@cisco.com Tue Jul 9 12:45:57 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4859611E813A for ; Tue, 9 Jul 2013 12:45:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yhCzjuxmOLtY for ; Tue, 9 Jul 2013 12:45:52 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id AA86211E8145 for ; Tue, 9 Jul 2013 12:45:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3135; q=dns/txt; s=iport; t=1373399152; x=1374608752; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=oBtg62AgXFzug/ouvbEmcsZMh+fKYXYIyGWFKslaQmo=; b=mXiximpmxujmrfuY2RGIpmh07h25/pBdIidNRobzv9YnIFq6egBx33Ih V6huvBEuhG9dcbdmqxmqI3eGZzDPpeepLe08yD1c5MPZ3pBPKgKt99WyC PgYz/stUGkbgIHTDy1RzUuDq+zPx969FfIOmCs66SDq2U33hmWqMiiJj4 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFABRo3FGtJXHA/2dsb2JhbABbFoJzMk3BEIEaFnSCIwEBAQQBAQFrCwwGAQgRBAEBAQodLgsUCQgCBA4FCAESh3QMuXuPOjEHBoMDawOYfZAggxGCKA X-IronPort-AV: E=Sophos;i="4.87,1029,1363132800"; d="scan'208";a="232785620" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-3.cisco.com with ESMTP; 09 Jul 2013 19:45:52 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r69JjpWA014942 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 9 Jul 2013 19:45:52 GMT Received: from xmb-aln-x03.cisco.com ([169.254.6.173]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Tue, 9 Jul 2013 14:45:51 -0500 From: "Sri Gundavelli (sgundave)" To: Seil Jeon Thread-Topic: [DMM] Two new drafts Thread-Index: AQHOfNzqcBpPAutMk0mWcj9nsZrcaw== Date: Tue, 9 Jul 2013 19:45:51 +0000 Message-ID: <24C0F3E22276D9438D6F366EB89FAEA81032CE4E@xmb-aln-x03.cisco.com> In-Reply-To: <002501ce7c8b$7b532cf0$71f986d0$@av.it.pt> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.32.246.213] Content-Type: text/plain; charset="iso-8859-2" Content-ID: <2169411AB97C4F49B3934C39B1ADC6DB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dmm@ietf.org" Subject: Re: [DMM] Two new drafts X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jul 2013 19:45:57 -0000 Hi Seil, In one abstraction, that middleware is the socket layer performing address binding. The key point is that we need to add additional meta-data to a prefix and carry them in ND/DHCP from the network to the host. So, the host has awareness on different types of IP addresses for use and with the corresponding properties. This helps in DMM solution, also for supporting SIPTO in WLAN-EPC integrated solutions. We don't have to deal with monster NAT's in case of IPv6-based flow offload. Regards Sri =20 On 7/9/13 3:02 AM, "Seil Jeon" wrote: >Hi Sri, > >Picking source address by an application would be the right way to go? >I've >known that's the work of the middleware. >The middleware needs to be aware of the applications and thus to act >properly. > >Regards >Seil > >-----Original Message----- >From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of Sri >Gundavelli (sgundave) >Sent: Tuesday, July 09, 2013 6:23 AM >To: Alper Yegin; dmm@ietf.org >Subject: Re: [DMM] Two new drafts > >Hi Alper, > >Thanks for sharing the documents. > >I did a quick review of the dmm-ondemand draft. This is inline with my >thinking as well. IMO, the following base semantics will allow us to >realize >some of the DMM deployment models. > >- Prefix Coloring/ Coloring of IP addresses based on the properties > >- Delivering the properties as meta-data in address assignment procedures >(ND, DHCP ..) >- Evolving the source address selection Rules, allowing application to >pick >source address based on the requirements > >With these semantics, a UE can obtain multiple IP addresses with different >properties, bind applications to those addresses based on the application >requirements, roam within the network loosing some local addresses and >generating some new ones ... >=20 > >Slides from 2010 I think ..? > >http://www.psg.com/~charliep/txt/ietf81/alt_mext/Evolving-The-SAS-Rules-fo >r >-Mobility-Awareness-2.pdf > > >Good to see this. Hope we make progress on these base work such as prefix >coloring =A9which are the enablers .. > >http://www.ietf.org/id/draft-korhonen-6man-prefix-properties-01.txt >http://datatracker.ietf.org/doc/draft-bhandari-dhc-class-based-prefix/ > > >Your proposal can leverage the above work. > > > >Regards >Sri > > > > > > > >On 7/8/13 8:30 AM, "Alper Yegin" wrote: > >>Hello dear DMM folks, >> >>We published the following two new drafts which relate to the DMM WG. >> >>http://www.ietf.org/id/draft-yegin-dmm-cnet-homing-00.txt >> >>http://www.ietf.org/id/draft-yegin-dmm-ondemand-mobility-00.txt >> >>We'd appreciate if you can read and share your comments. >> >>(Related IPR statements will be posted on the IETF site soon) >> >>Cheers, >> >>Alper >> >> >>_______________________________________________ >>dmm mailing list >>dmm@ietf.org >>https://www.ietf.org/mailman/listinfo/dmm > >_______________________________________________ >dmm mailing list >dmm@ietf.org >https://www.ietf.org/mailman/listinfo/dmm > From seiljeon@av.it.pt Wed Jul 10 05:33:35 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1496D21F9FFE for ; Wed, 10 Jul 2013 05:33:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqQfWh3PagMH for ; Wed, 10 Jul 2013 05:33:31 -0700 (PDT) Received: from av.it.pt (mail.av.it.pt [193.136.92.53]) by ietfa.amsl.com (Postfix) with ESMTP id 8D0E021F9AFE for ; Wed, 10 Jul 2013 05:33:29 -0700 (PDT) Received: from [192.168.20.80] (account seiljeon@av.it.pt HELO SeilATNOG) by av.it.pt (CommuniGate Pro SMTP 5.4.2) with ESMTPSA id 70056986; Wed, 10 Jul 2013 13:33:26 +0100 From: "Seil Jeon" To: "'Sri Gundavelli \(sgundave\)'" References: <002501ce7c8b$7b532cf0$71f986d0$@av.it.pt> <24C0F3E22276D9438D6F366EB89FAEA81032CE4E@xmb-aln-x03.cisco.com> In-Reply-To: <24C0F3E22276D9438D6F366EB89FAEA81032CE4E@xmb-aln-x03.cisco.com> Date: Wed, 10 Jul 2013 13:33:28 +0100 Message-ID: <001b01ce7d69$ae834680$0b89d380$@av.it.pt> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIbO6oMkUKV0Wbe/UrbjBuMgiCTAJjEUeWQ Content-Language: ko Cc: dmm@ietf.org Subject: Re: [DMM] Two new drafts X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 12:33:35 -0000 Hi Sri, In the sense that NAT-based solutions have not been documented in the = 3GPP standards and the NATing with single PDN connection would give = complexities much in handling the flows and dynamically applying policies, I agree = with your opinions. Additionally, I took the potential of putting mobility properties to prefixes into my head, though it needs to be reviewed more = in the way. Regards, Seil -----Original Message----- From: Sri Gundavelli (sgundave) [mailto:sgundave@cisco.com]=20 Sent: Tuesday, July 09, 2013 8:46 PM To: Seil Jeon Cc: 'Alper Yegin'; dmm@ietf.org Subject: Re: [DMM] Two new drafts Hi Seil, In one abstraction, that middleware is the socket layer performing = address binding. The key point is that we need to add additional meta-data to a prefix and carry them in ND/DHCP from the network to the host. So, the = host has awareness on different types of IP addresses for use and with the corresponding properties. This helps in DMM solution, also for = supporting SIPTO in WLAN-EPC integrated solutions. We don't have to deal with = monster NAT's in case of IPv6-based flow offload. Regards Sri =20 On 7/9/13 3:02 AM, "Seil Jeon" wrote: >Hi Sri, > >Picking source address by an application would be the right way to go? >I've >known that's the work of the middleware. >The middleware needs to be aware of the applications and thus to act=20 >properly. > >Regards >Seil > >-----Original Message----- >From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of=20 >Sri Gundavelli (sgundave) >Sent: Tuesday, July 09, 2013 6:23 AM >To: Alper Yegin; dmm@ietf.org >Subject: Re: [DMM] Two new drafts > >Hi Alper, > >Thanks for sharing the documents. > >I did a quick review of the dmm-ondemand draft. This is inline with my=20 >thinking as well. IMO, the following base semantics will allow us to=20 >realize some of the DMM deployment models. > >- Prefix Coloring/ Coloring of IP addresses based on the properties > >- Delivering the properties as meta-data in address assignment=20 >procedures (ND, DHCP ..) >- Evolving the source address selection Rules, allowing application to=20 >pick source address based on the requirements > >With these semantics, a UE can obtain multiple IP addresses with=20 >different properties, bind applications to those addresses based on the = >application requirements, roam within the network loosing some local=20 >addresses and generating some new ones ... >=20 > >Slides from 2010 I think ..? > >http://www.psg.com/~charliep/txt/ietf81/alt_mext/Evolving-The-SAS-Rules >-fo >r >-Mobility-Awareness-2.pdf > > >Good to see this. Hope we make progress on these base work such as=20 >prefix coloring =A9which are the enablers .. > >http://www.ietf.org/id/draft-korhonen-6man-prefix-properties-01.txt >http://datatracker.ietf.org/doc/draft-bhandari-dhc-class-based-prefix/ > > >Your proposal can leverage the above work. > > > >Regards >Sri > > > > > > > >On 7/8/13 8:30 AM, "Alper Yegin" wrote: > >>Hello dear DMM folks, >> >>We published the following two new drafts which relate to the DMM WG. >> >>http://www.ietf.org/id/draft-yegin-dmm-cnet-homing-00.txt >> >>http://www.ietf.org/id/draft-yegin-dmm-ondemand-mobility-00.txt >> >>We'd appreciate if you can read and share your comments. >> >>(Related IPR statements will be posted on the IETF site soon) >> >>Cheers, >> >>Alper >> >> >>_______________________________________________ >>dmm mailing list >>dmm@ietf.org >>https://www.ietf.org/mailman/listinfo/dmm > >_______________________________________________ >dmm mailing list >dmm@ietf.org >https://www.ietf.org/mailman/listinfo/dmm > From ryuji.wakikawa@gmail.com Wed Jul 10 09:12:24 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DE5021F9CC5 for ; Wed, 10 Jul 2013 09:12:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fU0D1f5IV9Bw for ; Wed, 10 Jul 2013 09:12:24 -0700 (PDT) Received: from mail-qe0-x22b.google.com (mail-qe0-x22b.google.com [IPv6:2607:f8b0:400d:c02::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 2413B21F9BF3 for ; Wed, 10 Jul 2013 09:12:20 -0700 (PDT) Received: by mail-qe0-f43.google.com with SMTP id q19so3890342qeb.30 for ; Wed, 10 Jul 2013 09:12:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:references :to:message-id:mime-version:x-mailer; bh=aeZOGVdYhlOmqSAlRarF0hbzMra+6hpG4Q7fhVU/U9w=; b=Y/YziM4hsfFZNf4ZhoLjIXOnkJ+onVt+rBTQ2L8xcGc6Cy+iHwXGDuQjpMKkEIRxge IfeWNG+Qam8AMeL8/HUGFzyj9Rc78sz0HYmrdr73rZ3u9V9Xhl5EUtFGDwCb7WSrkFf5 k44c4mmcXXDfL0X5gQAI/MhEtZVqcUhb1uawJxb/0a3B6wRGjwIR7RLshf/dMQBs3NJ8 nUS1Ks5/rb6hYhw1LhhEXaxB0lpMpFxKeXE9+TlX1j6+9yVaIDRJiAKn4icKkkCdQO/n Ilx1tU7xLDUlrA5fUPKHFxOAxOIxDJytXQxbPo0ykt6znsCgVPxwjYFRg7mGGnzfmZk4 ullw== X-Received: by 10.49.74.136 with SMTP id t8mr26158326qev.28.1373472739564; Wed, 10 Jul 2013 09:12:19 -0700 (PDT) Received: from [10.71.31.234] ([38.126.120.10]) by mx.google.com with ESMTPSA id 2sm25373096qap.7.2013.07.10.09.12.15 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Jul 2013 09:12:18 -0700 (PDT) From: Ryuji Wakikawa Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 10 Jul 2013 09:12:14 -0700 References: <20130710160944.11064.6824.idtracker@ietfa.amsl.com> To: dmm@ietf.org Message-Id: <724A5F78-33A4-4608-82B9-231DC2AAE2F6@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [DMM] Fwd: New Version Notification for draft-matsushima-stateless-uplane-vepc-00.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 16:12:24 -0000 Hi=20 We submit a new document. Your comments are appreciated!=20 thanks, ryuji Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-matsushima-stateless-uplane-vepc-00.txt > Date: July 10, 2013 9:09:44 AM PDT > To: Ryuji Wakikawa , Satoru Matsushima = >=20 >=20 > A new version of I-D, draft-matsushima-stateless-uplane-vepc-00.txt > has been successfully submitted by Satoru Matsushima and posted to the > IETF repository. >=20 > Filename: draft-matsushima-stateless-uplane-vepc > Revision: 00 > Title: Stateless user-plane architecture for = virtualized EPC (vEPC) > Creation date: 2013-07-10 > Group: Individual Submission > Number of pages: 19 > URL: = http://www.ietf.org/internet-drafts/draft-matsushima-stateless-uplane-vepc= -00.txt > Status: = http://datatracker.ietf.org/doc/draft-matsushima-stateless-uplane-vepc > Htmlized: = http://tools.ietf.org/html/draft-matsushima-stateless-uplane-vepc-00 >=20 >=20 > Abstract: > We envision a new mobile architecture for the future Evolved Packet > Core (EPC). The new architecture is designed to support the > virtualization scheme called NFV (Network Function Virtualization). > In our architecture, the user plane of EPC is decoupled from the > control-plane and uses routing information to forward packets of > mobile nodes. Although the EPC control plane will run on = hypervisor, > our proposal does not modify the signaling of the EPC control plane. > The benefits of our architecture are 1) scalability, 2) flexibility > and 3) Manageability. How to run the EPC control plane on NFV is = out > of our focus in this document. >=20 >=20 >=20 >=20 > The IETF Secretariat >=20 From jouni.nospam@gmail.com Wed Jul 10 23:27:37 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF08F21F9DA2 for ; Wed, 10 Jul 2013 23:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0AbzmoP5uELb for ; Wed, 10 Jul 2013 23:27:37 -0700 (PDT) Received: from mail-bk0-x235.google.com (mail-bk0-x235.google.com [IPv6:2a00:1450:4008:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id F30A121F9D8F for ; Wed, 10 Jul 2013 23:27:36 -0700 (PDT) Received: by mail-bk0-f53.google.com with SMTP id e11so3141520bkh.40 for ; Wed, 10 Jul 2013 23:27:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version:x-mailer; bh=BXqNQoP5Hq/0o68lxwdj2Paaullsa438X2HrORLxk/o=; b=Kh4JN2GlFnC7A61SlHS1Q2zBKNAJlNtcvjn31QUq8//7e7I8ZlCiSxh3lvPEXVsuyK j8jrO5Ql0gVlFG0i1s6+aif7KW/pyyLRB3KHvqKH+x3nujiOoiq6WgeobFbnZ/VD5hGC in2Zkx/lW9KSW97SgTSnWnQ7t1CzcEXGBpNdCoCNQb234FjPwG1dRzdw6X/Jm8J24WDI 9vG5RIzcMBE/DHfyHI/DKcaGparbZfptVDl1eUO2kSSlCfs0bP0IZkpt4HnZwpLwRHrJ i5plQMLgIgI5PL1QuRqAG8b4x0TRY5wu5UCjOIjSi2UViIDgwZtqfcPJCo4HxZ52uTFx 3+Kg== X-Received: by 10.205.73.194 with SMTP id yt2mr5396778bkb.57.1373524054475; Wed, 10 Jul 2013 23:27:34 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:7c45:54b5:e8cb:9cbb? ([2001:1bc8:101:f101:7c45:54b5:e8cb:9cbb]) by mx.google.com with ESMTPSA id l11sm7732102bkk.13.2013.07.10.23.27.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Jul 2013 23:27:34 -0700 (PDT) From: Jouni Korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: Date: Thu, 11 Jul 2013 09:27:32 +0300 To: "dmm@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [DMM] preliminary agenda forming up.. X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 06:27:37 -0000 Folks, The agenda so far based on the requests we got and I managed to track myslef.. if you think you were forgotten and need to be on the agenda, just let the chairs know. With 10min individual I-D slots we are pretty much within our time budget still. One of the key outcomes from this meeting is getting all remaining stuff sorted out for the requirements document, so I encourage folks to prepare for that. - Jouni & Julien ------------------------------------------------------------------------- THURSDAY, August 1, 2013, 0900-1130 CEST DMM WG IETF 87: 120 min (excluding break) Chairs: 09:00 o Agenda and WG update 10 min WG documents: 09:10 o draft-ietf-dmm-requirements 25 min (Anthony Chan) - Resolve all remaining Issue Tracker tickets. - Heading to IESG (once done) 09:35 o draft-ietf-dmm-best-practices-gap-analysis 25 min (Dapeng Liu/Juan-Carlos Zuniga) Individual documents: 10:00 o MA selection use-cases nn min (Danny) 10:nn o draft-yegin-dmm-cnet-homing-00 nn min 10:nn o draft-yegin-dmm-ondemand-mobility-00 nn min (Alper) 10:nn o draft-bernardos-dmm-distributed-anchoring-02 nn min (Carlos & Juan-Carlos) 10:nn o draft-chan-dmm-framework-01 nn min (Anthony) From jouni.nospam@gmail.com Wed Jul 10 23:48:42 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D96B021F9E39 for ; Wed, 10 Jul 2013 23:48:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fZ7OjubmLRBO for ; Wed, 10 Jul 2013 23:48:42 -0700 (PDT) Received: from mail-bk0-x230.google.com (mail-bk0-x230.google.com [IPv6:2a00:1450:4008:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 07AD921F9E2C for ; Wed, 10 Jul 2013 23:48:41 -0700 (PDT) Received: by mail-bk0-f48.google.com with SMTP id jf17so3159754bkc.7 for ; Wed, 10 Jul 2013 23:48:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=Rd3lp7hyeQv6a/tB2ttKHqz3iCBoq+VnlGwUnSyt0/A=; b=E9Vq7jZErBRsCkb3Li2ParPLZJQRrox1G0KKk+I//wZ58dZYfiV8UJGMIltr+vs+8Z efx47khIld0xjoVEPLaWFtffKhnjgdUL8bZtygfSHTvbNWltvYyTdpJVuC+du+1+8EnY ZsSchTMrXmht+kdUq78BNq0o+85t1vRrv887vDD1aKsL0FmIW8pqal++N2OQFvOv6uyO +jC94BL+BlOFG2+MXquVpRdDfQ9jLKSE2zk2/5SkNJLtPo3LLTn39fHbuUY4DXuLomTE 7Hzv20X9w2P+UxV9zpya+loBJhdivtP0GGQyQplHtcXreG6ZO22H8/ATo5uxays5IGZ0 oJeQ== X-Received: by 10.204.232.12 with SMTP id js12mr5505266bkb.22.1373525321022; Wed, 10 Jul 2013 23:48:41 -0700 (PDT) Received: from [188.117.15.109] ([188.117.15.109]) by mx.google.com with ESMTPSA id rj6sm7735839bkb.12.2013.07.10.23.48.40 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 10 Jul 2013 23:48:40 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jouni Korhonen In-Reply-To: <724A5F78-33A4-4608-82B9-231DC2AAE2F6@gmail.com> Date: Thu, 11 Jul 2013 09:48:38 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130710160944.11064.6824.idtracker@ietfa.amsl.com> <724A5F78-33A4-4608-82B9-231DC2AAE2F6@gmail.com> To: Ryuji Wakikawa X-Mailer: Apple Mail (2.1508) Cc: dmm@ietf.org Subject: Re: [DMM] New Version Notification for draft-matsushima-stateless-uplane-vepc-00.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 06:48:43 -0000 Thanks for winding up a good old discussion on this specific GTP topic. I have not yet read the I-D in a close detail but I have some initial questions - so there might be some gaps in my understanding of the I-D. Previously when similar architectures were exercised the question of backward compatibility always came up. One of the sticking points was the established practices to use of GTP-U header extensions to carry subscriber specific data within the core (i.e. between SGW/SGSN and PGW/GGSN). Have you thought=20 of this? Another question/note I have is that now quite a bit of tasks that used to belong to PGW/GGSN are now assigned to EPC-E (like policy control). Has this been seen as an issue? - Jouni On Jul 10, 2013, at 7:12 PM, Ryuji Wakikawa = wrote: > Hi=20 >=20 > We submit a new document. Your comments are appreciated!=20 >=20 > thanks, > ryuji >=20 >=20 > Begin forwarded message: >=20 >> From: internet-drafts@ietf.org >> Subject: New Version Notification for = draft-matsushima-stateless-uplane-vepc-00.txt >> Date: July 10, 2013 9:09:44 AM PDT >> To: Ryuji Wakikawa , Satoru Matsushima = >>=20 >>=20 >> A new version of I-D, draft-matsushima-stateless-uplane-vepc-00.txt >> has been successfully submitted by Satoru Matsushima and posted to = the >> IETF repository. >>=20 >> Filename: draft-matsushima-stateless-uplane-vepc >> Revision: 00 >> Title: Stateless user-plane architecture for = virtualized EPC (vEPC) >> Creation date: 2013-07-10 >> Group: Individual Submission >> Number of pages: 19 >> URL: = http://www.ietf.org/internet-drafts/draft-matsushima-stateless-uplane-vepc= -00.txt >> Status: = http://datatracker.ietf.org/doc/draft-matsushima-stateless-uplane-vepc >> Htmlized: = http://tools.ietf.org/html/draft-matsushima-stateless-uplane-vepc-00 >>=20 >>=20 >> Abstract: >> We envision a new mobile architecture for the future Evolved Packet >> Core (EPC). The new architecture is designed to support the >> virtualization scheme called NFV (Network Function Virtualization). >> In our architecture, the user plane of EPC is decoupled from the >> control-plane and uses routing information to forward packets of >> mobile nodes. Although the EPC control plane will run on = hypervisor, >> our proposal does not modify the signaling of the EPC control plane. >> The benefits of our architecture are 1) scalability, 2) flexibility >> and 3) Manageability. How to run the EPC control plane on NFV is = out >> of our focus in this document. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >>=20 >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From maxpassion@gmail.com Thu Jul 11 00:06:15 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3978A21F9BC0 for ; Thu, 11 Jul 2013 00:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cyEh0IPfgtDq for ; Thu, 11 Jul 2013 00:06:14 -0700 (PDT) Received: from mail-vb0-x234.google.com (mail-vb0-x234.google.com [IPv6:2607:f8b0:400c:c02::234]) by ietfa.amsl.com (Postfix) with ESMTP id 7958321F938E for ; Thu, 11 Jul 2013 00:06:14 -0700 (PDT) Received: by mail-vb0-f52.google.com with SMTP id f12so265766vbg.25 for ; Thu, 11 Jul 2013 00:06:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=d5GnLDP7UNeA+IcRRUm0F0N/1Q+f7IcInWElpoRvDD0=; b=RHF2Y7LqkKIS/IWDVn36Sa8bgxz+OL+8mbGR9SvhMf3sDbUWHKbh3FAF5SpxxW72UI FcrYQBr6SVrx20Y58Qm0rUhId5RYT5+2ENZEUYgIcDJ8LLRRyioNcXX8q6VIPiuprRmC lTHHaArzAjNP9Cw66M/ftPZgYDw0osNF4uk1inAAcnMapkROngIbEIP2NDeFFKxVWsCI 8C3XUJ4LNpjR8hwI25ULO6EUQ01ICrRDeTEheFawb80EfJ9MeOrZNKDGrpQ7WGeY3vkI +zB5L99SKaQ01y6XP7EvbAvl+Kb/75lTbFcoF56GlARMb3bKTm73MBqheIYQYv8ag0aG 5XGA== MIME-Version: 1.0 X-Received: by 10.52.0.52 with SMTP id 20mr17472700vdb.22.1373526368077; Thu, 11 Jul 2013 00:06:08 -0700 (PDT) Received: by 10.221.65.2 with HTTP; Thu, 11 Jul 2013 00:06:08 -0700 (PDT) Date: Thu, 11 Jul 2013 15:06:08 +0800 Message-ID: From: Liu Dapeng To: dmm Content-Type: text/plain; charset=ISO-8859-1 Subject: [DMM] I-D Action: draft-liu-sdn-mobility-00.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 07:06:15 -0000 Hi all, We submit a SDN mobility draft. The purpose is to trigger discussions on the topic of SDN mobility. Your comments are appreciated. Thanks, Dapeng Liu ________________________________ A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Mobility Support in Software Defined Networking Author(s) : Dapeng Liu Hui Deng Filename : draft-liu-sdn-mobility-00.txt Pages : 6 Date : 2013-07-08 Abstract: This document discusses the SDN mobility problem and potential solutions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-liu-sdn-mobility There's also a htmlized version available at: http://tools.ietf.org/html/draft-liu-sdn-mobility-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ -- ------ Best Regards, Dapeng Liu From maxpassion@gmail.com Thu Jul 11 00:19:11 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87DA921F99FB for ; Thu, 11 Jul 2013 00:19:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAe4SD6BCWxM for ; Thu, 11 Jul 2013 00:19:11 -0700 (PDT) Received: from mail-vb0-x22d.google.com (mail-vb0-x22d.google.com [IPv6:2607:f8b0:400c:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id EF00C21F9D78 for ; Thu, 11 Jul 2013 00:18:58 -0700 (PDT) Received: by mail-vb0-f45.google.com with SMTP id p14so273927vbm.4 for ; Thu, 11 Jul 2013 00:18:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=SxS+GXBLImTIlIvz/RPMWOPPJs/XnFojt99rcTnXf+M=; b=fWGU4nhsViH9M/nSoQqwAKe0XkIQC8KfOFdgQNbM9I3aOZMBOH4hFfCimN61jrPMCY 3a0PyTJGKQn+Rt8VLGRM5lU5iUWINW/OI83XMixi8BXeRIVEE/UncyO0aZ07h1lqiXMQ mrDht/gjtR1lbZwZF0vBnZbLizzo788/qJ6movAxK02lQSFjju5lzPUc+9M7OIbO40ud aOlSnFyYkbxysyL/JZyYb0NUN4VWqgkcVKlHG4jkbZINtx7Qub/TCd5xRcNzvyPyPCe9 gqlATiqMk0fIdmU1qKUawNofUBGkF/rZkBZ1dRUq7uzlnVpy6Pzg1Ex7rUP3K9O3tNgT MZqQ== MIME-Version: 1.0 X-Received: by 10.220.90.71 with SMTP id h7mr20997442vcm.16.1373527135020; Thu, 11 Jul 2013 00:18:55 -0700 (PDT) Received: by 10.221.65.2 with HTTP; Thu, 11 Jul 2013 00:18:54 -0700 (PDT) Date: Thu, 11 Jul 2013 15:18:54 +0800 Message-ID: From: Liu Dapeng To: dmm Content-Type: text/plain; charset=ISO-8859-1 Subject: [DMM] updated draft: draft-liu-dmm-mobility-api-01.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 07:19:11 -0000 Hi all, We update the dmm mobility api draft. Your comments are appreciated. Thanks, Dapeng Liu ------------------------ A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Mobility API Extension for Distributed Mobility Management Author(s) : Dapeng Liu Hui Deng Filename : draft-liu-dmm-mobility-api-01.txt Pages : 4 Date : 2013-07-07 Abstract: [RFC5014] specifies extension to socket API to allow application to specify the preference among multiple source addresses. [I-D.draft-korhonen-6man-prfix-properties] and [I-D.draft-bhandari-dhc-class-based-prefix-04] propose to extend router advertisment to carry the prefix property and class information. The mobile node can learn the prefix property and class information from the router advertisment message. This document proposes an extension to [RFC5014] to enable the application to select the distributed mobility management related prefixes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-liu-dmm-mobility-api There's also a htmlized version available at: http://tools.ietf.org/html/draft-liu-dmm-mobility-api-01 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-liu-dmm-mobility-api-01 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ -- ------ Best Regards, Dapeng Liu From maxpassion@gmail.com Thu Jul 11 01:12:17 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFC1021F9E7D for ; Thu, 11 Jul 2013 01:12:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KHeFqF4UIi3q for ; Thu, 11 Jul 2013 01:12:17 -0700 (PDT) Received: from mail-vc0-x22b.google.com (mail-vc0-x22b.google.com [IPv6:2607:f8b0:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 48FAD21F9E77 for ; Thu, 11 Jul 2013 01:12:15 -0700 (PDT) Received: by mail-vc0-f171.google.com with SMTP id gd11so6476684vcb.2 for ; Thu, 11 Jul 2013 01:12:14 -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=R75ANddlaDQHwFe5cSLv2bsHx2GoVHzLPLiWgG89Mug=; b=pYSz3VG6JEP+74ekTq+hDgAyT3uH5vPaJe819tgHlZ3BKryn9yihLtkRoTClM0PAsc 4kWnSdLx7rRzp/JktUaEshLnO3RajV2nUTNgcAQ5khLPnbcELM7fki5mcSOwF55pck5E TkeE8hguCiQrg4sdW1W/8CSLuUI44A0jl2pWRRB1GPm0tQnd6ZH9xnOG0e9k7NN+Et3e 39L8xQGYgO0M88F7OtFtDO8UDhdp4krA6JSPOxGpqjZ7fhTVT9pMYbhAfn+jtQInd1QY xZq9OmFEVzrH2scDG+5fhMLOTK2LuNz3+D/QWj6eTado1HTDjfmmWcotvipBxcwKVuti ikyg== MIME-Version: 1.0 X-Received: by 10.52.0.52 with SMTP id 20mr17578228vdb.22.1373530334719; Thu, 11 Jul 2013 01:12:14 -0700 (PDT) Received: by 10.221.65.2 with HTTP; Thu, 11 Jul 2013 01:12:14 -0700 (PDT) In-Reply-To: <724A5F78-33A4-4608-82B9-231DC2AAE2F6@gmail.com> References: <20130710160944.11064.6824.idtracker@ietfa.amsl.com> <724A5F78-33A4-4608-82B9-231DC2AAE2F6@gmail.com> Date: Thu, 11 Jul 2013 16:12:14 +0800 Message-ID: From: Liu Dapeng To: Ryuji Wakikawa Content-Type: text/plain; charset=ISO-8859-1 Cc: dmm Subject: Re: [DMM] Fwd: New Version Notification for draft-matsushima-stateless-uplane-vepc-00.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 08:12:18 -0000 Hi Ryuji, Thanks for posting an very interesting draft. Build distributed mobility using BGP has been discussed in DMM before. For example: http://tools.ietf.org/html/draft-mccann-dmm-flatarch-00. My comments: 1. How to deal with routing fluctuation problem? Using BGP in Boeing on-board system is quite different from mobile network. Boeing on-board system normally does not have too much mobile node (the flight is only one mobile node), but for the mobile network, there could be hundreds of millions of mobile nodes keep moving and will result in lots of routing updates. 2. Billing and policy enforcement is not discussed in the draft. Do you have any thoughts on this? Thanks, Dapeng Liu 2013/7/11 Ryuji Wakikawa : > Hi > > We submit a new document. Your comments are appreciated! > > thanks, > ryuji > > > Begin forwarded message: > >> From: internet-drafts@ietf.org >> Subject: New Version Notification for draft-matsushima-stateless-uplane-vepc-00.txt >> Date: July 10, 2013 9:09:44 AM PDT >> To: Ryuji Wakikawa , Satoru Matsushima >> >> >> A new version of I-D, draft-matsushima-stateless-uplane-vepc-00.txt >> has been successfully submitted by Satoru Matsushima and posted to the >> IETF repository. >> >> Filename: draft-matsushima-stateless-uplane-vepc >> Revision: 00 >> Title: Stateless user-plane architecture for virtualized EPC (vEPC) >> Creation date: 2013-07-10 >> Group: Individual Submission >> Number of pages: 19 >> URL: http://www.ietf.org/internet-drafts/draft-matsushima-stateless-uplane-vepc-00.txt >> Status: http://datatracker.ietf.org/doc/draft-matsushima-stateless-uplane-vepc >> Htmlized: http://tools.ietf.org/html/draft-matsushima-stateless-uplane-vepc-00 >> >> >> Abstract: >> We envision a new mobile architecture for the future Evolved Packet >> Core (EPC). The new architecture is designed to support the >> virtualization scheme called NFV (Network Function Virtualization). >> In our architecture, the user plane of EPC is decoupled from the >> control-plane and uses routing information to forward packets of >> mobile nodes. Although the EPC control plane will run on hypervisor, >> our proposal does not modify the signaling of the EPC control plane. >> The benefits of our architecture are 1) scalability, 2) flexibility >> and 3) Manageability. How to run the EPC control plane on NFV is out >> of our focus in this document. >> >> >> >> >> The IETF Secretariat >> > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm -- ------ Best Regards, Dapeng Liu From hassan.aliahmad@orange.com Thu Jul 11 03:30:24 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2173211E80E1 for ; Thu, 11 Jul 2013 03:30:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uXXupEhsgoWr for ; Thu, 11 Jul 2013 03:30:20 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id B40D521F9FDB for ; Thu, 11 Jul 2013 03:30:19 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 61FEF2642F1; Thu, 11 Jul 2013 12:30:18 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 21E3C238071; Thu, 11 Jul 2013 12:30:18 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Thu, 11 Jul 2013 12:30:14 +0200 From: To: "dmm@ietf.org" Thread-Topic: New Version Notification for draft-aliahmad-dmm-anchor-selection-01.txt Thread-Index: AQHOfh/BExnkF/PxIkerMzdWTdlk4plfRIvA Date: Thu, 11 Jul 2013 10:30:14 +0000 Message-ID: <5908_1373538618_51DE893A_5908_1979_1_3f9c958a-edbc-4e99-b13d-7ebac7a91937@PEXCVZYH01.corporate.adroot.infra.ftgroup> Accept-Language: en-US, fr-FR Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.2] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.21.113319 Cc: 'Tiago Condeixa' , "Moustafa, Hassnaa" Subject: [DMM] FW: New Version Notification for draft-aliahmad-dmm-anchor-selection-01.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 10:30:24 -0000 SGkgQWxsLA0KDQpBIG5ldyB2ZXJzaW9uIG9mIHRoZSBhbmNob3Igc2VsZWN0aW9uIHVzZS1jYXNl cyBkcmFmdCBoYXMgYmVlbiBzdWJtaXR0ZWQ7IHdlIHRyaWVkIG91ciBiZXN0IHRvIHJlcGx5IHRv IHRoZSBhZGRyZXNzZWQgcXVlc3Rpb25zIGluIElFVEYtODYuDQoNCkRhbm55IHdpbGwgcHJlc2Vu dCB0aGUgZHJhZnQgaW4gSUVURi04NywgaG9waW5nIHdlIGNhbiBpbml0aWF0ZSBmcnVpdGZ1bCBk aXNjdXNzaW9ucyBhcm91bmQgdGhlIHRvcGljLiANCg0KTWVhbndoaWxlLCBhbGwgY29tbWVudHMg YW5kIHF1ZXN0aW9ucyBhcmUgd2VsY29tZWQgYW5kIGhpZ2hseSBhcHByZWNpYXRlZC4NCg0KVGhh bmtzLA0KSGFzc2FuDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpT ZW50OiBUaHVyc2RheSwgSnVseSAxMSwgMjAxMyAxMjoxNyBQTQ0KVG86IFRpYWdvIENvbmRleGlh OyBBTEkgQUhNQUQgSGFzc2FuIE9MTkMvT0xOOyBEYW5ueSBNb3NlczsgSGFzc25hYSBNb3VzdGFm YTsgU0VJVEUgUGllcnJpY2sgT0xOQy9PTE4NClN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNh dGlvbiBmb3IgZHJhZnQtYWxpYWhtYWQtZG1tLWFuY2hvci1zZWxlY3Rpb24tMDEudHh0DQoNCg0K QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWFsaWFobWFkLWRtbS1hbmNob3Itc2VsZWN0aW9u LTAxLnR4dA0KaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBIYXNzYW4gQWxpLUFo bWFkIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KRmlsZW5hbWU6CSBkcmFm dC1hbGlhaG1hZC1kbW0tYW5jaG9yLXNlbGVjdGlvbg0KUmV2aXNpb246CSAwMQ0KVGl0bGU6CQkg TW9iaWxpdHkgQW5jaG9yIFNlbGVjdGlvbiBpbiBETU06IFVzZS1jYXNlIFNjZW5hcmlvcw0KQ3Jl YXRpb24gZGF0ZToJIDIwMTMtMDctMTENCkdyb3VwOgkJIEluZGl2aWR1YWwgU3VibWlzc2lvbg0K TnVtYmVyIG9mIHBhZ2VzOiAxNw0KVVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy9kcmFmdC1hbGlhaG1hZC1kbW0tYW5jaG9yLXNlbGVjdGlvbi0wMS50 eHQNClN0YXR1czogICAgICAgICAgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFm dC1hbGlhaG1hZC1kbW0tYW5jaG9yLXNlbGVjdGlvbg0KSHRtbGl6ZWQ6ICAgICAgICBodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1hbGlhaG1hZC1kbW0tYW5jaG9yLXNlbGVjdGlvbi0w MQ0KRGlmZjogICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFm dC1hbGlhaG1hZC1kbW0tYW5jaG9yLXNlbGVjdGlvbi0wMQ0KDQpBYnN0cmFjdDoNCiAgIFRoaXMg ZG9jdW1lbnQgcHJlc2VudHMgYW5kIGRpc2N1c3NlcyBkaWZmZXJlbnQgdXNlLWNhc2Ugc2NlbmFy aW9zIG9mDQogICBtb2JpbGl0eSBhbmNob3Igc2VsZWN0aW9uIGluIERpc3RyaWJ1dGVkIE1vYmls aXR5IE1hbmFnZW1lbnQgKERNTSkuDQoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCg0KDQpU aGUgSUVURiBTZWNyZXRhcmlhdA0KDQoKX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwoKQ2UgbWVzc2FnZSBldCBzZXMgcGllY2Vz IGpvaW50ZXMgcGV1dmVudCBjb250ZW5pciBkZXMgaW5mb3JtYXRpb25zIGNvbmZpZGVudGllbGxl cyBvdSBwcml2aWxlZ2llZXMgZXQgbmUgZG9pdmVudCBkb25jCnBhcyBldHJlIGRpZmZ1c2VzLCBl eHBsb2l0ZXMgb3UgY29waWVzIHNhbnMgYXV0b3Jpc2F0aW9uLiBTaSB2b3VzIGF2ZXogcmVjdSBj ZSBtZXNzYWdlIHBhciBlcnJldXIsIHZldWlsbGV6IGxlIHNpZ25hbGVyCmEgbCdleHBlZGl0ZXVy IGV0IGxlIGRldHJ1aXJlIGFpbnNpIHF1ZSBsZXMgcGllY2VzIGpvaW50ZXMuIExlcyBtZXNzYWdl cyBlbGVjdHJvbmlxdWVzIGV0YW50IHN1c2NlcHRpYmxlcyBkJ2FsdGVyYXRpb24sCk9yYW5nZSBk ZWNsaW5lIHRvdXRlIHJlc3BvbnNhYmlsaXRlIHNpIGNlIG1lc3NhZ2UgYSBldGUgYWx0ZXJlLCBk ZWZvcm1lIG91IGZhbHNpZmllLiBNZXJjaS4KClRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1l bnRzIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBvciBwcml2aWxlZ2VkIGluZm9ybWF0aW9uIHRo YXQgbWF5IGJlIHByb3RlY3RlZCBieSBsYXc7CnRoZXkgc2hvdWxkIG5vdCBiZSBkaXN0cmlidXRl ZCwgdXNlZCBvciBjb3BpZWQgd2l0aG91dCBhdXRob3Jpc2F0aW9uLgpJZiB5b3UgaGF2ZSByZWNl aXZlZCB0aGlzIGVtYWlsIGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgYW5kIGRl bGV0ZSB0aGlzIG1lc3NhZ2UgYW5kIGl0cyBhdHRhY2htZW50cy4KQXMgZW1haWxzIG1heSBiZSBh bHRlcmVkLCBPcmFuZ2UgaXMgbm90IGxpYWJsZSBmb3IgbWVzc2FnZXMgdGhhdCBoYXZlIGJlZW4g bW9kaWZpZWQsIGNoYW5nZWQgb3IgZmFsc2lmaWVkLgpUaGFuayB5b3UuCgo= From maxpassion@gmail.com Thu Jul 11 03:34:48 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 954F021F9FE6 for ; Thu, 11 Jul 2013 03:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.39 X-Spam-Level: X-Spam-Status: No, score=-2.39 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFzMbNR9Oi-3 for ; Thu, 11 Jul 2013 03:34:48 -0700 (PDT) Received: from mail-vb0-x230.google.com (mail-vb0-x230.google.com [IPv6:2607:f8b0:400c:c02::230]) by ietfa.amsl.com (Postfix) with ESMTP id 37F8F21F9E79 for ; Thu, 11 Jul 2013 03:34:47 -0700 (PDT) Received: by mail-vb0-f48.google.com with SMTP id w15so394823vbf.21 for ; Thu, 11 Jul 2013 03:34:46 -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=1emcBUrcqzyk2FOycKEFG7X9/DKaT2vQW8MtYz/I+Rs=; b=zl/sgIOFD0ye3HIbBAMKEJduKb+Xng9tYsn6ZMUV+FymGvwVLyCEKlNWHDm4jlnAoO oxJcUyV8PPKt8+36JTwJ9BueZwsnmMaMn/eIneHsPTRwleUVWVEbjjVDlIJH328/D19E 8OeUH8wDMNn+0b0XqSTMeHLZvTaxaiDr8eExnf7vNO6rH6ziTiBkUPC06lkFAByl0fHJ bp4S1NtjYd+yTzytjq/SLSp9nXh9zn7Kydtrd44zy8g3niTHjO1FS6320Ap5ulL9kFMl FuQEKpky0dpNFAolYEqEbjU+Hqegx1cDPZlQqJaTXNWKOnmGmDYvf2z+BRLR4VNW+3CQ Fv2Q== MIME-Version: 1.0 X-Received: by 10.52.69.177 with SMTP id f17mr18274934vdu.48.1373538886700; Thu, 11 Jul 2013 03:34:46 -0700 (PDT) Received: by 10.221.65.2 with HTTP; Thu, 11 Jul 2013 03:34:46 -0700 (PDT) In-Reply-To: References: <20130710160944.11064.6824.idtracker@ietfa.amsl.com> <724A5F78-33A4-4608-82B9-231DC2AAE2F6@gmail.com> Date: Thu, 11 Jul 2013 18:34:46 +0800 Message-ID: From: Liu Dapeng To: Ryuji Wakikawa Content-Type: text/plain; charset=ISO-8859-1 Cc: dmm Subject: Re: [DMM] Fwd: New Version Notification for draft-matsushima-stateless-uplane-vepc-00.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 10:34:48 -0000 Another comment is the roaming issue. It is not covered in the draft. But anyway, I agree with the motivation as discussed in section 2.1 and we also have submitted a SDN mobility discussion draft: http://tools.ietf.org/html/draft-liu-sdn-mobility-00. Thanks, Regards, Dapeng Liu 2013/7/11 Liu Dapeng : > Hi Ryuji, > > Thanks for posting an very interesting draft. Build distributed > mobility using BGP has been discussed in DMM before. For example: > http://tools.ietf.org/html/draft-mccann-dmm-flatarch-00. > > My comments: > 1. How to deal with routing fluctuation problem? Using BGP in Boeing > on-board system is quite different from mobile network. Boeing > on-board system normally does not have too much mobile node (the > flight is only one mobile node), but for the mobile network, there > could be hundreds of millions of mobile nodes keep moving and will > result in lots of routing updates. > > 2. Billing and policy enforcement is not discussed in the draft. Do > you have any thoughts on this? > > Thanks, > Dapeng Liu > > 2013/7/11 Ryuji Wakikawa : >> Hi >> >> We submit a new document. Your comments are appreciated! >> >> thanks, >> ryuji >> >> >> Begin forwarded message: >> >>> From: internet-drafts@ietf.org >>> Subject: New Version Notification for draft-matsushima-stateless-uplane-vepc-00.txt >>> Date: July 10, 2013 9:09:44 AM PDT >>> To: Ryuji Wakikawa , Satoru Matsushima >>> >>> >>> A new version of I-D, draft-matsushima-stateless-uplane-vepc-00.txt >>> has been successfully submitted by Satoru Matsushima and posted to the >>> IETF repository. >>> >>> Filename: draft-matsushima-stateless-uplane-vepc >>> Revision: 00 >>> Title: Stateless user-plane architecture for virtualized EPC (vEPC) >>> Creation date: 2013-07-10 >>> Group: Individual Submission >>> Number of pages: 19 >>> URL: http://www.ietf.org/internet-drafts/draft-matsushima-stateless-uplane-vepc-00.txt >>> Status: http://datatracker.ietf.org/doc/draft-matsushima-stateless-uplane-vepc >>> Htmlized: http://tools.ietf.org/html/draft-matsushima-stateless-uplane-vepc-00 >>> >>> >>> Abstract: >>> We envision a new mobile architecture for the future Evolved Packet >>> Core (EPC). The new architecture is designed to support the >>> virtualization scheme called NFV (Network Function Virtualization). >>> In our architecture, the user plane of EPC is decoupled from the >>> control-plane and uses routing information to forward packets of >>> mobile nodes. Although the EPC control plane will run on hypervisor, >>> our proposal does not modify the signaling of the EPC control plane. >>> The benefits of our architecture are 1) scalability, 2) flexibility >>> and 3) Manageability. How to run the EPC control plane on NFV is out >>> of our focus in this document. >>> >>> >>> >>> >>> The IETF Secretariat >>> >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm > > > > -- > > ------ > Best Regards, > Dapeng Liu -- ------ Best Regards, Dapeng Liu From fabio.giust@imdea.org Thu Jul 11 03:47:02 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3073921F9DB0 for ; Thu, 11 Jul 2013 03:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IVwych1vymBO for ; Thu, 11 Jul 2013 03:46:57 -0700 (PDT) Received: from estafeta.imdea.org (maquina46.madrimasd.org [193.145.15.46]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1BD21F9BD8 for ; Thu, 11 Jul 2013 03:46:57 -0700 (PDT) Received: from localhost (estafeta21.imdea.org [172.17.99.144]) by estafeta21.imdea.org (Postfix) with ESMTP id 150FD189270; Thu, 11 Jul 2013 12:46:57 +0200 (CEST) X-Virus-Scanned: by antispam-antivirus system at imdea.org Received: from estafeta.imdea.org ([172.17.99.144]) by localhost (estafeta21.imdea.org [172.17.99.144]) (amavisd-new, port 10024) with ESMTP id Tzx108rFjbV5; Thu, 11 Jul 2013 12:46:56 +0200 (CEST) Received: from Fabbbbio (unknown [163.117.140.235]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: fabio.giust) by estafeta21.imdea.org (Postfix) with ESMTP id B18B118926F; Thu, 11 Jul 2013 12:46:56 +0200 (CEST) From: "Fabio Giust" To: "'Jouni Korhonen'" , References: In-Reply-To: Date: Thu, 11 Jul 2013 12:46:52 +0200 Message-ID: <002b01ce7e23$f46e2f60$dd4a8e20$@giust@imdea.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac59/72DGc9A0eSITo+CHzYTdAxd8gAIbZng Content-Language: es Cc: dmm@ietf.org Subject: Re: [DMM] preliminary agenda forming up.. X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 10:47:02 -0000 Hi all, We are preparing a new version of the PMIP-based DMM solution draft-bernardos-dmm-pmip-02, as well as the draft for a client-based solution (draft-bernardos-dmm-cmip-00). Both will be submitted soon, you = can find the old versions at http://tools.ietf.org/id/draft-bernardos-dmm-pmip-01.txt http://tools.ietf.org/id/draft-bernardos-mext-dmm-cmip-00.txt I'd like to request the chairs a couple of slots to present the two individual drafts during next meeting. Thanks, Fabio Giust Research assistant Institute IMDEA Networks Avda. del Mar Mediterraneo, 22 28918 Legan=E9s (Madrid) Spain www.networks.imdea.org e-mail: fabio.giust@imdea.org phone: +34 91 624 8859 fax: +34 91 481 6965 |-----Original Message----- |From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of |Jouni Korhonen |Sent: jueves, 11 de julio de 2013 8:28 |To: dmm@ietf.org |Subject: [DMM] preliminary agenda forming up.. | |Folks, | |The agenda so far based on the requests we got and I managed to track |myslef.. if you think you were forgotten and need to be on the agenda, |just let the chairs know. With 10min individual I-D slots we are pretty |much within our time budget still. | |One of the key outcomes from this meeting is getting all remaining = stuff |sorted out for the requirements document, so I encourage folks to |prepare for that. | |- Jouni & Julien | |------------------------------------------------------------------------= |- | |THURSDAY, August 1, 2013, 0900-1130 CEST | | DMM WG IETF 87: 120 min (excluding break) | |Chairs: | |09:00 o Agenda and WG update 10 = min | |WG documents: | |09:10 o draft-ietf-dmm-requirements 25 = min | (Anthony Chan) | - Resolve all remaining Issue Tracker tickets. | - Heading to IESG (once done) | |09:35 o draft-ietf-dmm-best-practices-gap-analysis 25 = min | (Dapeng Liu/Juan-Carlos Zuniga) | |Individual documents: | |10:00 o MA selection use-cases nn = min | (Danny) | |10:nn o draft-yegin-dmm-cnet-homing-00 nn = min |10:nn o draft-yegin-dmm-ondemand-mobility-00 nn = min | (Alper) | |10:nn o draft-bernardos-dmm-distributed-anchoring-02 nn = min | (Carlos & Juan-Carlos) | | |10:nn o draft-chan-dmm-framework-01 nn = min | (Anthony) | |_______________________________________________ |dmm mailing list |dmm@ietf.org |https://www.ietf.org/mailman/listinfo/dmm From ryuji.wakikawa@gmail.com Thu Jul 11 08:11:12 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 161E521F9BFE for ; Thu, 11 Jul 2013 08:11:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oinlZspsKy37 for ; Thu, 11 Jul 2013 08:11:11 -0700 (PDT) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 626EE21F9B0F for ; Thu, 11 Jul 2013 08:11:11 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id c10so4392917qcz.14 for ; Thu, 11 Jul 2013 08:11:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=XFCju2BIi7SmtvQ+QW4IA5ZviWjjcb5RwZeuWudAPdY=; b=tvFhKxBfM2DUbGb5BMUSEGyFuW0zlQlko0m2XqUSlhY+fTU1npuFihWb7C1A1GLEsk TOug8x3u2w5sGnK12nPd+sxqEZmcSviPUtGwR6m/dOyRLuTIkryEXKJp9HpGEc7os9st WvNTmphGMBUROeKOvJbWvCXryX/DIvH9aVNH+365QXjr7M/R16vEhrEJWF9UAaftfpb+ gJa004wVYQsrD6bR8ZVzzbrIoyslA0FAwrtdzvhXscZlOOj/sESKP6jQ4tsV+O6Ld08u YRq/IO4DFQZv4zHmGgnwpQEekJNXBOe9orMhCMLgvQcWmNqfJoAalhCfCY9YK/Djxeol inDg== X-Received: by 10.49.29.106 with SMTP id j10mr30980252qeh.37.1373555470820; Thu, 11 Jul 2013 08:11:10 -0700 (PDT) Received: from [10.71.31.234] ([38.126.120.10]) by mx.google.com with ESMTPSA id pg6sm29037095qeb.5.2013.07.11.08.11.08 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Jul 2013 08:11:09 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ryuji Wakikawa In-Reply-To: Date: Thu, 11 Jul 2013 08:11:14 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130710160944.11064.6824.idtracker@ietfa.amsl.com> <724A5F78-33A4-4608-82B9-231DC2AAE2F6@gmail.com> To: Jouni Korhonen X-Mailer: Apple Mail (2.1508) Cc: dmm@ietf.org Subject: Re: [DMM] New Version Notification for draft-matsushima-stateless-uplane-vepc-00.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 15:11:12 -0000 Hi Jouni Thanks for comments.=20 Our proposal keeps the control plane untouched. All the signalling and = functions stay same in U-Plane. However If the information is carried in GTP-U header, the information = is missed in our system. =20 Can you point out what kind of data is that? The pointer to 3GPP = specification is helpful too? For the tasks in EPC-E, we don't have particular solution at this = moment, but we are expecting some solution from network service = chaining. I heard there will be a bog at the coming IETF.=20 regards, ryuji On Jul 10, 2013, at 11:48 PM, Jouni Korhonen = wrote: >=20 > Thanks for winding up a good old discussion on this specific GTP > topic. I have not yet read the I-D in a close detail but I have > some initial questions - so there might be some gaps in my > understanding of the I-D. Previously when similar architectures > were exercised the question of backward compatibility always came > up. One of the sticking points was the established practices to use > of GTP-U header extensions to carry subscriber specific data within > the core (i.e. between SGW/SGSN and PGW/GGSN). Have you thought=20 > of this? Another question/note I have is that now quite a bit of > tasks that used to belong to PGW/GGSN are now assigned to EPC-E > (like policy control). Has this been seen as an issue? >=20 > - Jouni >=20 >=20 >=20 >=20 > On Jul 10, 2013, at 7:12 PM, Ryuji Wakikawa = wrote: >=20 >> Hi=20 >>=20 >> We submit a new document. Your comments are appreciated!=20 >>=20 >> thanks, >> ryuji >>=20 >>=20 >> Begin forwarded message: >>=20 >>> From: internet-drafts@ietf.org >>> Subject: New Version Notification for = draft-matsushima-stateless-uplane-vepc-00.txt >>> Date: July 10, 2013 9:09:44 AM PDT >>> To: Ryuji Wakikawa , Satoru Matsushima = >>>=20 >>>=20 >>> A new version of I-D, draft-matsushima-stateless-uplane-vepc-00.txt >>> has been successfully submitted by Satoru Matsushima and posted to = the >>> IETF repository. >>>=20 >>> Filename: draft-matsushima-stateless-uplane-vepc >>> Revision: 00 >>> Title: Stateless user-plane architecture for = virtualized EPC (vEPC) >>> Creation date: 2013-07-10 >>> Group: Individual Submission >>> Number of pages: 19 >>> URL: = http://www.ietf.org/internet-drafts/draft-matsushima-stateless-uplane-vepc= -00.txt >>> Status: = http://datatracker.ietf.org/doc/draft-matsushima-stateless-uplane-vepc >>> Htmlized: = http://tools.ietf.org/html/draft-matsushima-stateless-uplane-vepc-00 >>>=20 >>>=20 >>> Abstract: >>> We envision a new mobile architecture for the future Evolved Packet >>> Core (EPC). The new architecture is designed to support the >>> virtualization scheme called NFV (Network Function Virtualization). >>> In our architecture, the user plane of EPC is decoupled from the >>> control-plane and uses routing information to forward packets of >>> mobile nodes. Although the EPC control plane will run on = hypervisor, >>> our proposal does not modify the signaling of the EPC control plane. >>> The benefits of our architecture are 1) scalability, 2) flexibility >>> and 3) Manageability. How to run the EPC control plane on NFV is = out >>> of our focus in this document. >>>=20 >>>=20 >>>=20 >>>=20 >>> The IETF Secretariat >>>=20 >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >=20 From ryuji.wakikawa@gmail.com Thu Jul 11 08:24:17 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB6E621F9CE7 for ; Thu, 11 Jul 2013 08:24:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.442 X-Spam-Level: X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[AWL=-0.157, BAYES_00=-2.599, SARE_MILLIONSOF=0.315, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bUbfVzHhqstm for ; Thu, 11 Jul 2013 08:24:17 -0700 (PDT) Received: from mail-qe0-x22d.google.com (mail-qe0-x22d.google.com [IPv6:2607:f8b0:400d:c02::22d]) by ietfa.amsl.com (Postfix) with ESMTP id F2CE421F9C8D for ; Thu, 11 Jul 2013 08:24:16 -0700 (PDT) Received: by mail-qe0-f45.google.com with SMTP id w7so4489703qeb.4 for ; Thu, 11 Jul 2013 08:24:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=mTuqv0cmJskBrSNLKBKBzN8Wm15UbNxGzYse26BGkIU=; b=a4Anz3x7DDxXR+ISdQi1D+9zwgdZh3L7Nz9bRylkAyjD5yOKocQRCMYQd0JOECsjZG xBOa6e4Eo4dfx1ft2TpUnTQE+MwK2BXFSOJwuAu66EUpgR7hfkiuUwepZVVFd+EK4Ps2 hr7F0n38pcl4XL/BVWaEV8Y2MbTtNrXrzczGbGNqtHA7hGhEJSXzppBgWniMJLva6dy4 xa8rWN8MiiM+hXN/RqikjGGHgFfq5EdQCVNEkG0llGmYFqa6FQ1Qp5tX6mMfEkLLaEhi uqn45PvulRHuxLodW123fJu3HgLqIOeQ0cbTtxpDLJklJClfG2s7D3Uu2cZ4hTGJkf+u NTXg== X-Received: by 10.49.24.13 with SMTP id q13mr29379089qef.49.1373556256472; Thu, 11 Jul 2013 08:24:16 -0700 (PDT) Received: from [10.71.31.234] ([38.126.120.10]) by mx.google.com with ESMTPSA id 15sm30136512qaa.9.2013.07.11.08.24.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 11 Jul 2013 08:24:11 -0700 (PDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Ryuji Wakikawa In-Reply-To: Date: Thu, 11 Jul 2013 08:24:08 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130710160944.11064.6824.idtracker@ietfa.amsl.com> <724A5F78-33A4-4608-82B9-231DC2AAE2F6@gmail.com> To: Liu Dapeng X-Mailer: Apple Mail (2.1508) Cc: Satoru Matsushima , dmm Subject: Re: [DMM] New Version Notification for draft-matsushima-stateless-uplane-vepc-00.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 15:24:17 -0000 Hi Liu For routing update matter, I will let my colleague to answer this.=20 The routing update is happened just within an operator's network.=20 The route for UE is just overwritten with the new information. I = believe BGP can easily handle these updates.=20 We haven't discussed billing and roaming. but what we are thinking now = is following.=20 If special treatment is needed (like roaming), we keep using the = original EPC functions available at NFV. Packets are routed to EPC = U-/C-planes on NFV.=20 For billing, we need some mechanism between U-/C- plane and didn't = identify a solution yet. We will try to identify it at the next = revision.=20 thanks ryuji On Jul 11, 2013, at 1:12 AM, Liu Dapeng wrote: > Hi Ryuji, >=20 > Thanks for posting an very interesting draft. Build distributed > mobility using BGP has been discussed in DMM before. For example: > http://tools.ietf.org/html/draft-mccann-dmm-flatarch-00. >=20 > My comments: > 1. How to deal with routing fluctuation problem? Using BGP in Boeing > on-board system is quite different from mobile network. Boeing > on-board system normally does not have too much mobile node (the > flight is only one mobile node), but for the mobile network, there > could be hundreds of millions of mobile nodes keep moving and will > result in lots of routing updates. >=20 > 2. Billing and policy enforcement is not discussed in the draft. Do > you have any thoughts on this? >=20 > Thanks, > Dapeng Liu >=20 > 2013/7/11 Ryuji Wakikawa : >> Hi >>=20 >> We submit a new document. Your comments are appreciated! >>=20 >> thanks, >> ryuji >>=20 >>=20 >> Begin forwarded message: >>=20 >>> From: internet-drafts@ietf.org >>> Subject: New Version Notification for = draft-matsushima-stateless-uplane-vepc-00.txt >>> Date: July 10, 2013 9:09:44 AM PDT >>> To: Ryuji Wakikawa , Satoru Matsushima = >>>=20 >>>=20 >>> A new version of I-D, draft-matsushima-stateless-uplane-vepc-00.txt >>> has been successfully submitted by Satoru Matsushima and posted to = the >>> IETF repository. >>>=20 >>> Filename: draft-matsushima-stateless-uplane-vepc >>> Revision: 00 >>> Title: Stateless user-plane architecture for = virtualized EPC (vEPC) >>> Creation date: 2013-07-10 >>> Group: Individual Submission >>> Number of pages: 19 >>> URL: = http://www.ietf.org/internet-drafts/draft-matsushima-stateless-uplane-vepc= -00.txt >>> Status: = http://datatracker.ietf.org/doc/draft-matsushima-stateless-uplane-vepc >>> Htmlized: = http://tools.ietf.org/html/draft-matsushima-stateless-uplane-vepc-00 >>>=20 >>>=20 >>> Abstract: >>> We envision a new mobile architecture for the future Evolved Packet >>> Core (EPC). The new architecture is designed to support the >>> virtualization scheme called NFV (Network Function Virtualization). >>> In our architecture, the user plane of EPC is decoupled from the >>> control-plane and uses routing information to forward packets of >>> mobile nodes. Although the EPC control plane will run on = hypervisor, >>> our proposal does not modify the signaling of the EPC control = plane. >>> The benefits of our architecture are 1) scalability, 2) flexibility >>> and 3) Manageability. How to run the EPC control plane on NFV is = out >>> of our focus in this document. >>>=20 >>>=20 >>>=20 >>>=20 >>> The IETF Secretariat >>>=20 >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >=20 >=20 >=20 > --=20 >=20 > ------ > Best Regards, > Dapeng Liu From sarikaya2012@gmail.com Thu Jul 11 10:05:37 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6F4E21F9A70 for ; Thu, 11 Jul 2013 10:05:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.469 X-Spam-Level: X-Spam-Status: No, score=-2.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKbQoHC5AOMh for ; Thu, 11 Jul 2013 10:05:36 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB7A21F9974 for ; Thu, 11 Jul 2013 10:05:36 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id v20so6922668lbc.3 for ; Thu, 11 Jul 2013 10:05:35 -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=Vmap0PYlJnMftoR0/Afj9sQkvSZD+lO5CIDFWtmgMrk=; b=WCGs0xivXXJuA7VfXIHV3S4WbH/1gUiwJiQjC79QBbXaLeNjR8GpG8wwU+9nAcDEi/ ioLW3WBVSULBr5eFGnJhJIUOX78zC5nZzNLvPxw1ZIuLSCLXg5ijZrGrNgvkbvHGy9ny v17G8coX76FN8DMG/PowKrPzgb88gZhTzbSozL6PxM9XpzzfhIuq2LWagCChqViWKQRw P9rDb+k1PF3Gk8QjXNyAPuZqCs78twF1IUaAzQVc2v/u2allTdSDeGQ7vnaIpR6TXLc8 j0tZ1UnFkV1d5i2dt88dFDOEuXSor6kagi8iKaUoMxem9SOyab49QyVk8ntnqm8mKwhZ B61g== MIME-Version: 1.0 X-Received: by 10.112.141.202 with SMTP id rq10mr17189657lbb.83.1373562335207; Thu, 11 Jul 2013 10:05:35 -0700 (PDT) Received: by 10.114.176.37 with HTTP; Thu, 11 Jul 2013 10:05:35 -0700 (PDT) In-Reply-To: <724A5F78-33A4-4608-82B9-231DC2AAE2F6@gmail.com> References: <20130710160944.11064.6824.idtracker@ietfa.amsl.com> <724A5F78-33A4-4608-82B9-231DC2AAE2F6@gmail.com> Date: Thu, 11 Jul 2013 12:05:35 -0500 Message-ID: From: Behcet Sarikaya To: Ryuji Wakikawa Content-Type: multipart/alternative; boundary=001a11c3872c1128ed04e13f6719 Cc: dmm@ietf.org Subject: Re: [DMM] Fwd: New Version Notification for draft-matsushima-stateless-uplane-vepc-00.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 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, 11 Jul 2013 17:05:37 -0000 --001a11c3872c1128ed04e13f6719 Content-Type: text/plain; charset=ISO-8859-1 Hi Ryuji, Thanks for submitting this draft. I read it and I also the comments. Your draft is inline with the direction I have been advocating for dmm, I think we should work on such issues. I think you should present the draft in Berlin. Regards, Behcet On Wed, Jul 10, 2013 at 11:12 AM, Ryuji Wakikawa wrote: > Hi > > We submit a new document. Your comments are appreciated! > > thanks, > ryuji > > > Begin forwarded message: > > > From: internet-drafts@ietf.org > > Subject: New Version Notification for > draft-matsushima-stateless-uplane-vepc-00.txt > > Date: July 10, 2013 9:09:44 AM PDT > > To: Ryuji Wakikawa , Satoru Matsushima < > satoru.matsushima@g.softbank.co.jp> > > > > > > A new version of I-D, draft-matsushima-stateless-uplane-vepc-00.txt > > has been successfully submitted by Satoru Matsushima and posted to the > > IETF repository. > > > > Filename: draft-matsushima-stateless-uplane-vepc > > Revision: 00 > > Title: Stateless user-plane architecture for virtualized > EPC (vEPC) > > Creation date: 2013-07-10 > > Group: Individual Submission > > Number of pages: 19 > > URL: > http://www.ietf.org/internet-drafts/draft-matsushima-stateless-uplane-vepc-00.txt > > Status: > http://datatracker.ietf.org/doc/draft-matsushima-stateless-uplane-vepc > > Htmlized: > http://tools.ietf.org/html/draft-matsushima-stateless-uplane-vepc-00 > > > > > > Abstract: > > We envision a new mobile architecture for the future Evolved Packet > > Core (EPC). The new architecture is designed to support the > > virtualization scheme called NFV (Network Function Virtualization). > > In our architecture, the user plane of EPC is decoupled from the > > control-plane and uses routing information to forward packets of > > mobile nodes. Although the EPC control plane will run on hypervisor, > > our proposal does not modify the signaling of the EPC control plane. > > The benefits of our architecture are 1) scalability, 2) flexibility > > and 3) Manageability. How to run the EPC control plane on NFV is out > > of our focus in this document. > > > > > > > > > > The IETF Secretariat > > > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > --001a11c3872c1128ed04e13f6719 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Ryuji,

Thanks for submitting this draft. I read it and I also the= comments.

Your draft is inline with the direction I have been advoc= ating for dmm, I think we should work on such issues.

I think you sh= ould present the draft in Berlin.

Regards,

Behcet

On Wed, Jul 10= , 2013 at 11:12 AM, Ryuji Wakikawa <ryuji.wakikawa@gmail.com>= ; wrote:
Hi

We submit a new document. =A0Your comments are appreciated!

thanks,
ryuji


Begin forwarded message:

> From: internet-drafts@ietf= .org
> Subject: New Version Notification for draft-matsushima-stateless-uplan= e-vepc-00.txt
> Date: July 10, 2013 9:09:44 AM PDT
> To: Ryuji Wakikawa <ryu= ji.wakikawa@gmail.com>, Satoru Matsushima <satoru.matsushima@g.softbank.co.jp><= br> >
>
> A new version of I-D, draft-matsushima-stateless-uplane-vepc-00.txt > has been successfully submitted by Satoru Matsushima and posted to the=
> IETF repository.
>
> Filename: =A0 =A0 =A0draft-matsushima-stateless-uplane-vepc
> Revision: =A0 =A0 =A000
> Title: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Stateless user-plane architectu= re for virtualized EPC (vEPC)
> Creation date: =A0 =A0 =A0 =A0 2013-07-10
> Group: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Individual Submission
> Number of pages: 19
> URL: =A0 =A0 =A0 =A0 =A0 =A0 http= ://www.ietf.org/internet-drafts/draft-matsushima-stateless-uplane-vepc-00.t= xt
> Status: =A0 =A0 =A0 =A0 =A0http://datatracke= r.ietf.org/doc/draft-matsushima-stateless-uplane-vepc
> Htmlized: =A0 =A0 =A0 =A0http://tools.ietf.org= /html/draft-matsushima-stateless-uplane-vepc-00
>
>
> Abstract:
> =A0 We envision a new mobile architecture for the future Evolved Packe= t
> =A0 Core (EPC). =A0The new architecture is designed to support the
> =A0 virtualization scheme called NFV (Network Function Virtualization)= .
> =A0 In our architecture, the user plane of EPC is decoupled from the > =A0 control-plane and uses routing information to forward packets of > =A0 mobile nodes. =A0Although the EPC control plane will run on hyperv= isor,
> =A0 our proposal does not modify the signaling of the EPC control plan= e.
> =A0 The benefits of our architecture are 1) scalability, 2) flexibilit= y
> =A0 and 3) Manageability. =A0How to run the EPC control plane on NFV i= s out
> =A0 of our focus in this document.
>
>
>
>
> The IETF Secretariat
>

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

--001a11c3872c1128ed04e13f6719-- From satoru.matsushima@gmail.com Thu Jul 11 12:52:58 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8651F11E8118 for ; Thu, 11 Jul 2013 12:52:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.342 X-Spam-Level: X-Spam-Status: No, score=-2.342 tagged_above=-999 required=5 tests=[AWL=-0.058, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sf2MMIgnKmwv for ; Thu, 11 Jul 2013 12:52:57 -0700 (PDT) Received: from mail-la0-x22d.google.com (mail-la0-x22d.google.com [IPv6:2a00:1450:4010:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 6C18A21E804C for ; Thu, 11 Jul 2013 12:52:49 -0700 (PDT) Received: by mail-la0-f45.google.com with SMTP id fr10so7148887lab.18 for ; Thu, 11 Jul 2013 12:52:47 -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=WT7QVx4wJG9D/rjDbZ3vnNgtxBtxCurP3BLV7m6ToqM=; b=gsM7Ksg45JLmOG2CHhjRhl1bbv5paV6r0u1JTRWvq2p6wMOhRYxrRAHczeneaDqFOR 4W3Z2zlaqkNLwV8DFwhWTdiqbRel6wx0FQKL0VHYu9q3eqgmkinsdVDNIeYz5BWFF8Iy CYdnLR/hOwut/G+5keVPtjJuPQ0zVL3m8PKkTMXJo++rRpkXbmLVvvAsPE2Lp2P3mdzJ TDabZXD3UOB6rQ89TnR9GYzr8yvAwfHGoixGXcnsPGK8/GvWgjP+Cw03RE9kZPE4w8Ju aExgjUP09aoWtxBf+9w/uv6dBw5jMsUrR4/6b0NoVVPp3NN8wvWOMbeAe15NUv0vNoNK vXUg== MIME-Version: 1.0 X-Received: by 10.152.88.105 with SMTP id bf9mr17765502lab.38.1373572366945; Thu, 11 Jul 2013 12:52:46 -0700 (PDT) Received: by 10.112.167.169 with HTTP; Thu, 11 Jul 2013 12:52:46 -0700 (PDT) In-Reply-To: References: <20130710160944.11064.6824.idtracker@ietfa.amsl.com> <724A5F78-33A4-4608-82B9-231DC2AAE2F6@gmail.com> Date: Fri, 12 Jul 2013 04:52:46 +0900 Message-ID: From: Satoru Matsushima To: Ryuji Wakikawa Content-Type: multipart/alternative; boundary=001a11c367220153cd04e141bd82 Cc: dmm Subject: Re: [DMM] New Version Notification for draft-matsushima-stateless-uplane-vepc-00.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jul 2013 19:52:58 -0000 --001a11c367220153cd04e141bd82 Content-Type: text/plain; charset=ISO-8859-1 Hi Liu, Thanks for your good question. We, bgp operator are struggle fast convergence for bgp that most of the issues come from best path recalculation on bgp speaker. In the proposed architecture we expect no such kind of recalc but just simple update to epc-e from vepc. BGP is an incremental routing protocol so that bgp should be capable to continuously update route to mobile nodes as they moving. Please noted that it is happened only on RAN facing side on epc-e, not on ipv6 core network side. So routing in ipv6 core can be much stable. cheers, --satoru On Fri, Jul 12, 2013 at 12:24 AM, Ryuji Wakikawa wrote: > Hi Liu > > For routing update matter, I will let my colleague to answer this. > The routing update is happened just within an operator's network. > The route for UE is just overwritten with the new information. I believe > BGP can easily handle these updates. > > We haven't discussed billing and roaming. but what we are thinking now is > following. > If special treatment is needed (like roaming), we keep using the original > EPC functions available at NFV. Packets are routed to EPC U-/C-planes on > NFV. > For billing, we need some mechanism between U-/C- plane and didn't > identify a solution yet. We will try to identify it at the next revision. > > thanks > ryuji > > On Jul 11, 2013, at 1:12 AM, Liu Dapeng wrote: > > > Hi Ryuji, > > > > Thanks for posting an very interesting draft. Build distributed > > mobility using BGP has been discussed in DMM before. For example: > > http://tools.ietf.org/html/draft-mccann-dmm-flatarch-00. > > > > My comments: > > 1. How to deal with routing fluctuation problem? Using BGP in Boeing > > on-board system is quite different from mobile network. Boeing > > on-board system normally does not have too much mobile node (the > > flight is only one mobile node), but for the mobile network, there > > could be hundreds of millions of mobile nodes keep moving and will > > result in lots of routing updates. > > > > 2. Billing and policy enforcement is not discussed in the draft. Do > > you have any thoughts on this? > > > > Thanks, > > Dapeng Liu > > > > 2013/7/11 Ryuji Wakikawa : > >> Hi > >> > >> We submit a new document. Your comments are appreciated! > >> > >> thanks, > >> ryuji > >> > >> > >> Begin forwarded message: > >> > >>> From: internet-drafts@ietf.org > >>> Subject: New Version Notification for > draft-matsushima-stateless-uplane-vepc-00.txt > >>> Date: July 10, 2013 9:09:44 AM PDT > >>> To: Ryuji Wakikawa , Satoru Matsushima < > satoru.matsushima@g.softbank.co.jp> > >>> > >>> > >>> A new version of I-D, draft-matsushima-stateless-uplane-vepc-00.txt > >>> has been successfully submitted by Satoru Matsushima and posted to the > >>> IETF repository. > >>> > >>> Filename: draft-matsushima-stateless-uplane-vepc > >>> Revision: 00 > >>> Title: Stateless user-plane architecture for > virtualized EPC (vEPC) > >>> Creation date: 2013-07-10 > >>> Group: Individual Submission > >>> Number of pages: 19 > >>> URL: > http://www.ietf.org/internet-drafts/draft-matsushima-stateless-uplane-vepc-00.txt > >>> Status: > http://datatracker.ietf.org/doc/draft-matsushima-stateless-uplane-vepc > >>> Htmlized: > http://tools.ietf.org/html/draft-matsushima-stateless-uplane-vepc-00 > >>> > >>> > >>> Abstract: > >>> We envision a new mobile architecture for the future Evolved Packet > >>> Core (EPC). The new architecture is designed to support the > >>> virtualization scheme called NFV (Network Function Virtualization). > >>> In our architecture, the user plane of EPC is decoupled from the > >>> control-plane and uses routing information to forward packets of > >>> mobile nodes. Although the EPC control plane will run on hypervisor, > >>> our proposal does not modify the signaling of the EPC control plane. > >>> The benefits of our architecture are 1) scalability, 2) flexibility > >>> and 3) Manageability. How to run the EPC control plane on NFV is out > >>> of our focus in this document. > >>> > >>> > >>> > >>> > >>> The IETF Secretariat > >>> > >> > >> _______________________________________________ > >> dmm mailing list > >> dmm@ietf.org > >> https://www.ietf.org/mailman/listinfo/dmm > > > > > > > > -- > > > > ------ > > Best Regards, > > Dapeng Liu > > --001a11c367220153cd04e141bd82 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Liu,

Thanks for your good ques= tion. We, bgp operator are struggle fast convergence for bgp that most of t= he issues come from best path recalculation on bgp speaker. In the proposed= architecture we expect no such kind of recalc but just simple update to ep= c-e from vepc. BGP is an incremental routing protocol so that bgp should be= capable to continuously update route to mobile nodes as they moving. Pleas= e noted that it is happened only on RAN facing side on epc-e, not on ipv6 c= ore network side. So routing in ipv6 core can be much stable.

cheers,
--satoru



<= br>
On Fri, Jul 12, 2013 at 12:24 AM, Ryuji Wakik= awa <ryuji.wakikawa@gmail.com> wrote:
Hi Liu

For routing update matter, I will let my colleague to answer this.
The routing update is happened just within an operator's network.
The route for UE is just overwritten with the new information. =A0 I believ= e BGP can easily handle these updates.

We haven't discussed billing and roaming. but what we are thinking now = is following.
If special treatment is needed (like roaming), we keep using the original E= PC functions available at NFV. Packets are routed to EPC U-/C-planes on NFV= .
For billing, we need some mechanism between U-/C- plane and didn't iden= tify a solution yet. We will try to identify it at the next revision.

thanks
ryuji

On Jul 11, 2013, at 1:12 AM, Liu Dapeng <maxpassion@gmail.com> wrote:

> Hi Ryuji,
>
> Thanks for posting an very interesting draft. Build distributed
> mobility using BGP has been discussed in DMM before. For example:
> http://tools.ietf.org/html/draft-mccann-dmm-flatarch-00= .
>
> My comments:
> 1. How to deal with routing fluctuation problem? Using BGP in Boeing > on-board system is quite different from mobile network. Boeing
> on-board system normally does not have too much mobile node (the
> flight is only one mobile node), but for the mobile network, there
> could be hundreds of millions of mobile nodes keep moving and will
> result in lots of routing updates.
>
> 2. Billing and policy enforcement is not discussed in the draft. Do > you have any thoughts on this?
>
> Thanks,
> Dapeng Liu
>
> 2013/7/11 Ryuji Wakikawa <ryuji.wakikawa@gmail.com>:
>> Hi
>>
>> We submit a new document. =A0Your comments are appreciated!
>>
>> thanks,
>> ryuji
>>
>>
>> Begin forwarded message:
>>
>>> From: internet-dra= fts@ietf.org
>>> Subject: New Version Notification for draft-matsushima-statele= ss-uplane-vepc-00.txt
>>> Date: July 10, 2013 9:09:44 AM PDT
>>> To: Ryuji Wakikawa <ryuji.wakikawa@gmail.com>, Satoru Matsushima <satoru.matsushima@g.softbank.co.jp<= /a>>
>>>
>>>
>>> A new version of I-D, draft-matsushima-stateless-uplane-vepc-0= 0.txt
>>> has been successfully submitted by Satoru Matsushima and poste= d to the
>>> IETF repository.
>>>
>>> Filename: =A0 =A0 =A0draft-matsushima-stateless-uplane-vepc >>> Revision: =A0 =A0 =A000
>>> Title: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Stateless user-plane ar= chitecture for virtualized EPC (vEPC)
>>> Creation date: =A0 =A0 =A0 =A0 2013-07-10
>>> Group: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Individual Submission >>> Number of pages: 19
>>> URL: =A0 =A0 =A0 =A0 =A0 =A0 http://www.ietf.org/internet-drafts/draft-matsushima-stateless-uplane-v= epc-00.txt
>>> Status: =A0 =A0 =A0 =A0 =A0http://da= tatracker.ietf.org/doc/draft-matsushima-stateless-uplane-vepc
>>> Htmlized: =A0 =A0 =A0 =A0http://tools.= ietf.org/html/draft-matsushima-stateless-uplane-vepc-00
>>>
>>>
>>> Abstract:
>>> =A0We envision a new mobile architecture for the future Evolve= d Packet
>>> =A0Core (EPC). =A0The new architecture is designed to support = the
>>> =A0virtualization scheme called NFV (Network Function Virtuali= zation).
>>> =A0In our architecture, the user plane of EPC is decoupled fro= m the
>>> =A0control-plane and uses routing information to forward packe= ts of
>>> =A0mobile nodes. =A0Although the EPC control plane will run on= hypervisor,
>>> =A0our proposal does not modify the signaling of the EPC contr= ol plane.
>>> =A0The benefits of our architecture are 1) scalability, 2) fle= xibility
>>> =A0and 3) Manageability. =A0How to run the EPC control plane o= n NFV is out
>>> =A0of our focus in this document.
>>>
>>>
>>>
>>>
>>> The IETF Secretariat
>>>
>>
>> _______________________________________________
>> dmm mailing list
>> dmm@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmm
>
>
>
> --
>
> ------
> Best Regards,
> Dapeng Liu


--001a11c367220153cd04e141bd82-- From maxpassion@gmail.com Thu Jul 11 19:00:00 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B035821E8086 for ; Thu, 11 Jul 2013 19:00:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.364 X-Spam-Level: X-Spam-Status: No, score=-2.364 tagged_above=-999 required=5 tests=[AWL=-0.079, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UExUyLvD1qYl for ; Thu, 11 Jul 2013 19:00:00 -0700 (PDT) Received: from mail-vc0-x234.google.com (mail-vc0-x234.google.com [IPv6:2607:f8b0:400c:c03::234]) by ietfa.amsl.com (Postfix) with ESMTP id E9C7721E8083 for ; Thu, 11 Jul 2013 18:59:59 -0700 (PDT) Received: by mail-vc0-f180.google.com with SMTP id gf11so7246741vcb.39 for ; Thu, 11 Jul 2013 18:59:58 -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=0Dt23UY+lUm3REGRv9iccN3oPhUyGpkTiQI+FC+PGHA=; b=lZJPvIAuJwFXQQW7QiZ715kAsRJtBVrXkt8YxrsNeTPT6/1HSVkb475uBi7PkXdohe emtn8BNPDAOjZNgKiQvgmhmAgUtLriIHc90qA95p8XxT8C6lQcpu4dUgaO2BTLsZm8XK HQy6gZ5u6J+fnClTqgKXD5mmZLsHUI6TaAMKdPSKoBuyRJRUH4DykwzicGoYfQIeZ/ow GhylL58TMfj7f9lkaPAWf+gPV5syyS90dXmVuka9iYX3yfvbgEY9Of1jXf3IzkENiZMu s3plMvH+ct6j9jEo11bBc+ACqzkNPvmV+g6W4xqdtBLIgiEf0JF+YjbvwbOJaqPUBxyC l0tg== MIME-Version: 1.0 X-Received: by 10.52.69.177 with SMTP id f17mr20021405vdu.48.1373594398262; Thu, 11 Jul 2013 18:59:58 -0700 (PDT) Received: by 10.221.65.2 with HTTP; Thu, 11 Jul 2013 18:59:58 -0700 (PDT) In-Reply-To: References: <20130710160944.11064.6824.idtracker@ietfa.amsl.com> <724A5F78-33A4-4608-82B9-231DC2AAE2F6@gmail.com> Date: Fri, 12 Jul 2013 09:59:58 +0800 Message-ID: From: Liu Dapeng To: Satoru Matsushima Content-Type: text/plain; charset=ISO-8859-1 Cc: dmm Subject: Re: [DMM] New Version Notification for draft-matsushima-stateless-uplane-vepc-00.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 02:00:00 -0000 2013/7/12 Satoru Matsushima : > Hi Liu, > > Thanks for your good question. We, bgp operator are struggle fast > convergence for bgp that most of the issues come from best path > recalculation on bgp speaker. In the proposed architecture we expect no such > kind of recalc but just simple update to epc-e from vepc. BGP is an > incremental routing protocol so that bgp should be capable to continuously > update route to mobile nodes as they moving. Please noted that it is > happened only on RAN facing side on epc-e, not on ipv6 core network side. [Dapeng] You mean the MN's prefix can be converged in the core network? You can do this when the MN moves in a small area, but if the MN moves out from that area, it is difficult to converge. Thanks, Dapeng Liu So > routing in ipv6 core can be much stable. > > cheers, > --satoru > > > > > On Fri, Jul 12, 2013 at 12:24 AM, Ryuji Wakikawa > wrote: >> >> Hi Liu >> >> For routing update matter, I will let my colleague to answer this. >> The routing update is happened just within an operator's network. >> The route for UE is just overwritten with the new information. I believe >> BGP can easily handle these updates. >> >> We haven't discussed billing and roaming. but what we are thinking now is >> following. >> If special treatment is needed (like roaming), we keep using the original >> EPC functions available at NFV. Packets are routed to EPC U-/C-planes on >> NFV. >> For billing, we need some mechanism between U-/C- plane and didn't >> identify a solution yet. We will try to identify it at the next revision. >> >> thanks >> ryuji >> >> On Jul 11, 2013, at 1:12 AM, Liu Dapeng wrote: >> >> > Hi Ryuji, >> > >> > Thanks for posting an very interesting draft. Build distributed >> > mobility using BGP has been discussed in DMM before. For example: >> > http://tools.ietf.org/html/draft-mccann-dmm-flatarch-00. >> > >> > My comments: >> > 1. How to deal with routing fluctuation problem? Using BGP in Boeing >> > on-board system is quite different from mobile network. Boeing >> > on-board system normally does not have too much mobile node (the >> > flight is only one mobile node), but for the mobile network, there >> > could be hundreds of millions of mobile nodes keep moving and will >> > result in lots of routing updates. >> > >> > 2. Billing and policy enforcement is not discussed in the draft. Do >> > you have any thoughts on this? >> > >> > Thanks, >> > Dapeng Liu >> > >> > 2013/7/11 Ryuji Wakikawa : >> >> Hi >> >> >> >> We submit a new document. Your comments are appreciated! >> >> >> >> thanks, >> >> ryuji >> >> >> >> >> >> Begin forwarded message: >> >> >> >>> From: internet-drafts@ietf.org >> >>> Subject: New Version Notification for >> >>> draft-matsushima-stateless-uplane-vepc-00.txt >> >>> Date: July 10, 2013 9:09:44 AM PDT >> >>> To: Ryuji Wakikawa , Satoru Matsushima >> >>> >> >>> >> >>> >> >>> A new version of I-D, draft-matsushima-stateless-uplane-vepc-00.txt >> >>> has been successfully submitted by Satoru Matsushima and posted to the >> >>> IETF repository. >> >>> >> >>> Filename: draft-matsushima-stateless-uplane-vepc >> >>> Revision: 00 >> >>> Title: Stateless user-plane architecture for >> >>> virtualized EPC (vEPC) >> >>> Creation date: 2013-07-10 >> >>> Group: Individual Submission >> >>> Number of pages: 19 >> >>> URL: >> >>> http://www.ietf.org/internet-drafts/draft-matsushima-stateless-uplane-vepc-00.txt >> >>> Status: >> >>> http://datatracker.ietf.org/doc/draft-matsushima-stateless-uplane-vepc >> >>> Htmlized: >> >>> http://tools.ietf.org/html/draft-matsushima-stateless-uplane-vepc-00 >> >>> >> >>> >> >>> Abstract: >> >>> We envision a new mobile architecture for the future Evolved Packet >> >>> Core (EPC). The new architecture is designed to support the >> >>> virtualization scheme called NFV (Network Function Virtualization). >> >>> In our architecture, the user plane of EPC is decoupled from the >> >>> control-plane and uses routing information to forward packets of >> >>> mobile nodes. Although the EPC control plane will run on hypervisor, >> >>> our proposal does not modify the signaling of the EPC control plane. >> >>> The benefits of our architecture are 1) scalability, 2) flexibility >> >>> and 3) Manageability. How to run the EPC control plane on NFV is out >> >>> of our focus in this document. >> >>> >> >>> >> >>> >> >>> >> >>> The IETF Secretariat >> >>> >> >> >> >> _______________________________________________ >> >> dmm mailing list >> >> dmm@ietf.org >> >> https://www.ietf.org/mailman/listinfo/dmm >> > >> > >> > >> > -- >> > >> > ------ >> > Best Regards, >> > Dapeng Liu >> > -- ------ Best Regards, Dapeng Liu From satoru.matsushima@gmail.com Fri Jul 12 00:20:57 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB66F21F9A5E for ; Fri, 12 Jul 2013 00:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.327 X-Spam-Level: X-Spam-Status: No, score=-2.327 tagged_above=-999 required=5 tests=[AWL=-0.043, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vb5cxPbM+yOy for ; Fri, 12 Jul 2013 00:20:57 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 6654321F9A8C for ; Fri, 12 Jul 2013 00:20:56 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id v20so7506842lbc.31 for ; Fri, 12 Jul 2013 00:20:55 -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=hNRQP0lgMkApck1xQDeSu1p29g67HsBpEm3FWZmjZ4w=; b=AlVB2zijffZDo190QdAxnDWhYD3Y4pnQOSg4aXxj54AclZG/2ZeNugCfYkcMtyqvv8 KHZV3TzZIthZDsnXZQhpJAO3MPinsnjiFO3tqk3b0f+C3+CZGAyT53r1LBAMIzCMlOhh 8/tH9c++vzUdsfPAvZOfoNva1hteCY46cqp9remPnM0h9FF66gOHAXMGP2tLA/vfUADJ DgOcXyL5dL0mpGNLz/AcaBFAdBeJoYfSb+hZJWDas/99dfE05os1zCVfWOh9B4Oa6qE4 B0pYS8zacObVnHiBR5djaFUdGX7Lt9OvrWuWIBX3/EUrDd1lfsa3885NOt0XrGLiekvN Q3Vw== MIME-Version: 1.0 X-Received: by 10.112.157.226 with SMTP id wp2mr18534804lbb.65.1373613655314; Fri, 12 Jul 2013 00:20:55 -0700 (PDT) Received: by 10.112.167.169 with HTTP; Fri, 12 Jul 2013 00:20:55 -0700 (PDT) In-Reply-To: References: <20130710160944.11064.6824.idtracker@ietfa.amsl.com> <724A5F78-33A4-4608-82B9-231DC2AAE2F6@gmail.com> Date: Fri, 12 Jul 2013 16:20:55 +0900 Message-ID: From: Satoru Matsushima To: Liu Dapeng Content-Type: multipart/alternative; boundary=001a11c34772fbd61904e14b595a Cc: dmm Subject: Re: [DMM] New Version Notification for draft-matsushima-stateless-uplane-vepc-00.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 07:20:58 -0000 --001a11c34772fbd61904e14b595a Content-Type: text/plain; charset=ISO-8859-1 Liu, MN's prefixes could be converged into an aggregated route. It is routing. So MN are always expected within the area where it covers as long as the aggregated route existed in the core network. cheers, --satoru On Fri, Jul 12, 2013 at 10:59 AM, Liu Dapeng wrote: > 2013/7/12 Satoru Matsushima : > > Hi Liu, > > > > Thanks for your good question. We, bgp operator are struggle fast > > convergence for bgp that most of the issues come from best path > > recalculation on bgp speaker. In the proposed architecture we expect no > such > > kind of recalc but just simple update to epc-e from vepc. BGP is an > > incremental routing protocol so that bgp should be capable to > continuously > > update route to mobile nodes as they moving. Please noted that it is > > happened only on RAN facing side on epc-e, not on ipv6 core network side. > > [Dapeng] You mean the MN's prefix can be converged in the core network? > You can > do this when the MN moves in a small area, but if the MN moves out > from that area, > it is difficult to converge. > > Thanks, > Dapeng Liu > > So > > routing in ipv6 core can be much stable. > > > > cheers, > > --satoru > > > > > > > > > > On Fri, Jul 12, 2013 at 12:24 AM, Ryuji Wakikawa < > ryuji.wakikawa@gmail.com> > > wrote: > >> > >> Hi Liu > >> > >> For routing update matter, I will let my colleague to answer this. > >> The routing update is happened just within an operator's network. > >> The route for UE is just overwritten with the new information. I > believe > >> BGP can easily handle these updates. > >> > >> We haven't discussed billing and roaming. but what we are thinking now > is > >> following. > >> If special treatment is needed (like roaming), we keep using the > original > >> EPC functions available at NFV. Packets are routed to EPC U-/C-planes on > >> NFV. > >> For billing, we need some mechanism between U-/C- plane and didn't > >> identify a solution yet. We will try to identify it at the next > revision. > >> > >> thanks > >> ryuji > >> > >> On Jul 11, 2013, at 1:12 AM, Liu Dapeng wrote: > >> > >> > Hi Ryuji, > >> > > >> > Thanks for posting an very interesting draft. Build distributed > >> > mobility using BGP has been discussed in DMM before. For example: > >> > http://tools.ietf.org/html/draft-mccann-dmm-flatarch-00. > >> > > >> > My comments: > >> > 1. How to deal with routing fluctuation problem? Using BGP in Boeing > >> > on-board system is quite different from mobile network. Boeing > >> > on-board system normally does not have too much mobile node (the > >> > flight is only one mobile node), but for the mobile network, there > >> > could be hundreds of millions of mobile nodes keep moving and will > >> > result in lots of routing updates. > >> > > >> > 2. Billing and policy enforcement is not discussed in the draft. Do > >> > you have any thoughts on this? > >> > > >> > Thanks, > >> > Dapeng Liu > >> > > >> > 2013/7/11 Ryuji Wakikawa : > >> >> Hi > >> >> > >> >> We submit a new document. Your comments are appreciated! > >> >> > >> >> thanks, > >> >> ryuji > >> >> > >> >> > >> >> Begin forwarded message: > >> >> > >> >>> From: internet-drafts@ietf.org > >> >>> Subject: New Version Notification for > >> >>> draft-matsushima-stateless-uplane-vepc-00.txt > >> >>> Date: July 10, 2013 9:09:44 AM PDT > >> >>> To: Ryuji Wakikawa , Satoru Matsushima > >> >>> > >> >>> > >> >>> > >> >>> A new version of I-D, draft-matsushima-stateless-uplane-vepc-00.txt > >> >>> has been successfully submitted by Satoru Matsushima and posted to > the > >> >>> IETF repository. > >> >>> > >> >>> Filename: draft-matsushima-stateless-uplane-vepc > >> >>> Revision: 00 > >> >>> Title: Stateless user-plane architecture for > >> >>> virtualized EPC (vEPC) > >> >>> Creation date: 2013-07-10 > >> >>> Group: Individual Submission > >> >>> Number of pages: 19 > >> >>> URL: > >> >>> > http://www.ietf.org/internet-drafts/draft-matsushima-stateless-uplane-vepc-00.txt > >> >>> Status: > >> >>> > http://datatracker.ietf.org/doc/draft-matsushima-stateless-uplane-vepc > >> >>> Htmlized: > >> >>> > http://tools.ietf.org/html/draft-matsushima-stateless-uplane-vepc-00 > >> >>> > >> >>> > >> >>> Abstract: > >> >>> We envision a new mobile architecture for the future Evolved Packet > >> >>> Core (EPC). The new architecture is designed to support the > >> >>> virtualization scheme called NFV (Network Function Virtualization). > >> >>> In our architecture, the user plane of EPC is decoupled from the > >> >>> control-plane and uses routing information to forward packets of > >> >>> mobile nodes. Although the EPC control plane will run on > hypervisor, > >> >>> our proposal does not modify the signaling of the EPC control > plane. > >> >>> The benefits of our architecture are 1) scalability, 2) flexibility > >> >>> and 3) Manageability. How to run the EPC control plane on NFV is > out > >> >>> of our focus in this document. > >> >>> > >> >>> > >> >>> > >> >>> > >> >>> The IETF Secretariat > >> >>> > >> >> > >> >> _______________________________________________ > >> >> dmm mailing list > >> >> dmm@ietf.org > >> >> https://www.ietf.org/mailman/listinfo/dmm > >> > > >> > > >> > > >> > -- > >> > > >> > ------ > >> > Best Regards, > >> > Dapeng Liu > >> > > > > > > -- > > ------ > Best Regards, > Dapeng Liu > --001a11c34772fbd61904e14b595a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Liu,

MN's prefixes could be c= onverged into an aggregated route. It is routing. So MN are always expected= within the area where it covers as long as the aggregated route existed in= the core network.

cheers,
--satoru


On Fri, Jul = 12, 2013 at 10:59 AM, Liu Dapeng <maxpassion@gmail.com> w= rote:
2013/7/12 Satoru Matsushima <satoru.matsushima@gmail.com>:
> Hi Liu,
>
> Thanks for your good question. We, bgp operator are struggle fast
> convergence for bgp that most of the issues come from best path
> recalculation on bgp speaker. In the proposed architecture we expect n= o such
> kind of recalc but just simple update to epc-e from vepc. BGP is an > incremental routing protocol so that bgp should be capable to continuo= usly
> update route to mobile nodes as they moving. Please noted that it is > happened only on RAN facing side on epc-e, not on ipv6 core network si= de.

[Dapeng] You mean the MN's prefix can be converged in the core ne= twork? You can
do this when the MN moves in a small area, but if the MN moves out
from that area,
it is difficult to converge.

Thanks,
Dapeng Liu

=A0So
> routing in ipv6 core can be much stable.
>
> cheers,
> --satoru
>
>
>
>
> On Fri, Jul 12, 2013 at 12:24 AM, Ryuji Wakikawa <ryuji.wakikawa@gmail.com>
> wrote:
>>
>> Hi Liu
>>
>> For routing update matter, I will let my colleague to answer this.=
>> The routing update is happened just within an operator's netwo= rk.
>> The route for UE is just overwritten with the new information. =A0= I believe
>> BGP can easily handle these updates.
>>
>> We haven't discussed billing and roaming. but what we are thin= king now is
>> following.
>> If special treatment is needed (like roaming), we keep using the o= riginal
>> EPC functions available at NFV. Packets are routed to EPC U-/C-pla= nes on
>> NFV.
>> For billing, we need some mechanism between U-/C- plane and didn&#= 39;t
>> identify a solution yet. We will try to identify it at the next re= vision.
>>
>> thanks
>> ryuji
>>
>> On Jul 11, 2013, at 1:12 AM, Liu Dapeng <maxpassion@gmail.com> wrote:
>>
>> > Hi Ryuji,
>> >
>> > Thanks for posting an very interesting draft. Build distribut= ed
>> > mobility using BGP has been discussed in DMM before. For exam= ple:
>> > http://tools.ietf.org/html/draft-mccann-dmm-flatar= ch-00.
>> >
>> > My comments:
>> > 1. How to deal with routing fluctuation problem? Using BGP in= Boeing
>> > on-board system is quite different from mobile network. Boein= g
>> > on-board system normally does not have too much mobile node (= the
>> > flight is only one mobile node), but for the mobile network, = there
>> > could be hundreds of millions of mobile nodes keep moving and= will
>> > result in lots of routing updates.
>> >
>> > 2. Billing and policy enforcement is not discussed in the dra= ft. Do
>> > you have any thoughts on this?
>> >
>> > Thanks,
>> > Dapeng Liu
>> >
>> > 2013/7/11 Ryuji Wakikawa <ryuji.wakikawa@gmail.com>:
>> >> Hi
>> >>
>> >> We submit a new document. =A0Your comments are appreciate= d!
>> >>
>> >> thanks,
>> >> ryuji
>> >>
>> >>
>> >> Begin forwarded message:
>> >>
>> >>> From: int= ernet-drafts@ietf.org
>> >>> Subject: New Version Notification for
>> >>> draft-matsushima-stateless-uplane-vepc-00.txt
>> >>> Date: July 10, 2013 9:09:44 AM PDT
>> >>> To: Ryuji Wakikawa <ryuji.wakikawa@gmail.com>, Satoru Matsushima
>> >>> <satoru.matsushima@g.softbank.co.jp>
>> >>>
>> >>>
>> >>> A new version of I-D, draft-matsushima-stateless-upla= ne-vepc-00.txt
>> >>> has been successfully submitted by Satoru Matsushima = and posted to the
>> >>> IETF repository.
>> >>>
>> >>> Filename: =A0 =A0 =A0draft-matsushima-stateless-uplan= e-vepc
>> >>> Revision: =A0 =A0 =A000
>> >>> Title: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Stateless user= -plane architecture for
>> >>> virtualized EPC (vEPC)
>> >>> Creation date: =A0 =A0 =A0 =A0 2013-07-10
>> >>> Group: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Individual Sub= mission
>> >>> Number of pages: 19
>> >>> URL:
>> >>> http://www.ietf.= org/internet-drafts/draft-matsushima-stateless-uplane-vepc-00.txt
>> >>> Status:
>> >>> http://datatracker.ietf.org= /doc/draft-matsushima-stateless-uplane-vepc
>> >>> Htmlized:
>> >>> http://tools.ietf.org/html/dr= aft-matsushima-stateless-uplane-vepc-00
>> >>>
>> >>>
>> >>> Abstract:
>> >>> =A0We envision a new mobile architecture for the futu= re Evolved Packet
>> >>> =A0Core (EPC). =A0The new architecture is designed to= support the
>> >>> =A0virtualization scheme called NFV (Network Function= Virtualization).
>> >>> =A0In our architecture, the user plane of EPC is deco= upled from the
>> >>> =A0control-plane and uses routing information to forw= ard packets of
>> >>> =A0mobile nodes. =A0Although the EPC control plane wi= ll run on hypervisor,
>> >>> =A0our proposal does not modify the signaling of the = EPC control plane.
>> >>> =A0The benefits of our architecture are 1) scalabilit= y, 2) flexibility
>> >>> =A0and 3) Manageability. =A0How to run the EPC contro= l plane on NFV is out
>> >>> =A0of our focus in this document.
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> The IETF Secretariat
>> >>>
>> >>
>> >> _______________________________________________
>> >> dmm mailing list
>> >> dmm@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/dmm
>> >
>> >
>> >
>> > --
>> >
>> > ------
>> > Best Regards,
>> > Dapeng Liu
>>
>



--

------
Best Regards,
Dapeng Liu

--001a11c34772fbd61904e14b595a-- From maxpassion@gmail.com Fri Jul 12 02:11:45 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA31421F9C76 for ; Fri, 12 Jul 2013 02:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.348 X-Spam-Level: X-Spam-Status: No, score=-2.348 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, NO_RELAYS=-0.001, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K+mYINkpsD5E for ; Fri, 12 Jul 2013 02:11:45 -0700 (PDT) Received: from mail-vb0-x229.google.com (mail-vb0-x229.google.com [IPv6:2607:f8b0:400c:c02::229]) by ietfa.amsl.com (Postfix) with ESMTP id 6503C21F9C72 for ; Fri, 12 Jul 2013 02:11:40 -0700 (PDT) Received: by mail-vb0-f41.google.com with SMTP id p13so1343996vbe.14 for ; Fri, 12 Jul 2013 02:11:39 -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=+Rx8nxhVat+rRYpXlYD93v1ECOTyHWwuJLo/tqKKzqs=; b=nAOpJNFINxQJpZTotTh5FhMCxJyXQzXNGVYxb87eJP9prWmlo+vujIRSXJJ7xYCeFu EXSut68lMQ6qkqadGOmoUmYlWC5gu3FCHKtjIQgvnUpFzsTXAM5nZj8CqDwsajPI2W6f goTZjzAt0uiFxh76hRPaz4MdTebpGtN11zGE2Lu9LKFDD7G4r84kY1bcNca1Baw1LBNC 7MTlEjUf5HjkiKi1poGpVpq31F9BsB0BsotI6Ad0MyvTqHjI39CLGkAzsLUuOPxuyklZ zYf8wMRtCUaUHE+5Mi1yv4rVFrtkyetPZwrqNJh+mzrprQghmPzA3lLdrgBrGqfSYLer O0Kw== MIME-Version: 1.0 X-Received: by 10.52.33.162 with SMTP id s2mr7800828vdi.37.1373620299781; Fri, 12 Jul 2013 02:11:39 -0700 (PDT) Received: by 10.221.65.2 with HTTP; Fri, 12 Jul 2013 02:11:39 -0700 (PDT) In-Reply-To: References: <20130710160944.11064.6824.idtracker@ietfa.amsl.com> <724A5F78-33A4-4608-82B9-231DC2AAE2F6@gmail.com> Date: Fri, 12 Jul 2013 17:11:39 +0800 Message-ID: From: Liu Dapeng To: Satoru Matsushima Content-Type: text/plain; charset=ISO-8859-1 Cc: dmm Subject: Re: [DMM] New Version Notification for draft-matsushima-stateless-uplane-vepc-00.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 09:11:46 -0000 Hi Satoru, Then the question is how big this area will be to support all the users of an operator? regards, Dapeng Liu 2013/7/12 Satoru Matsushima : > Liu, > > MN's prefixes could be converged into an aggregated route. It is routing. So > MN are always expected within the area where it covers as long as the > aggregated route existed in the core network. > > cheers, > --satoru > > > On Fri, Jul 12, 2013 at 10:59 AM, Liu Dapeng wrote: >> >> 2013/7/12 Satoru Matsushima : >> > Hi Liu, >> > >> > Thanks for your good question. We, bgp operator are struggle fast >> > convergence for bgp that most of the issues come from best path >> > recalculation on bgp speaker. In the proposed architecture we expect no >> > such >> > kind of recalc but just simple update to epc-e from vepc. BGP is an >> > incremental routing protocol so that bgp should be capable to >> > continuously >> > update route to mobile nodes as they moving. Please noted that it is >> > happened only on RAN facing side on epc-e, not on ipv6 core network >> > side. >> >> [Dapeng] You mean the MN's prefix can be converged in the core network? >> You can >> do this when the MN moves in a small area, but if the MN moves out >> from that area, >> it is difficult to converge. >> >> Thanks, >> Dapeng Liu >> >> So >> > routing in ipv6 core can be much stable. >> > >> > cheers, >> > --satoru >> > >> > >> > >> > >> > On Fri, Jul 12, 2013 at 12:24 AM, Ryuji Wakikawa >> > >> > wrote: >> >> >> >> Hi Liu >> >> >> >> For routing update matter, I will let my colleague to answer this. >> >> The routing update is happened just within an operator's network. >> >> The route for UE is just overwritten with the new information. I >> >> believe >> >> BGP can easily handle these updates. >> >> >> >> We haven't discussed billing and roaming. but what we are thinking now >> >> is >> >> following. >> >> If special treatment is needed (like roaming), we keep using the >> >> original >> >> EPC functions available at NFV. Packets are routed to EPC U-/C-planes >> >> on >> >> NFV. >> >> For billing, we need some mechanism between U-/C- plane and didn't >> >> identify a solution yet. We will try to identify it at the next >> >> revision. >> >> >> >> thanks >> >> ryuji >> >> >> >> On Jul 11, 2013, at 1:12 AM, Liu Dapeng wrote: >> >> >> >> > Hi Ryuji, >> >> > >> >> > Thanks for posting an very interesting draft. Build distributed >> >> > mobility using BGP has been discussed in DMM before. For example: >> >> > http://tools.ietf.org/html/draft-mccann-dmm-flatarch-00. >> >> > >> >> > My comments: >> >> > 1. How to deal with routing fluctuation problem? Using BGP in Boeing >> >> > on-board system is quite different from mobile network. Boeing >> >> > on-board system normally does not have too much mobile node (the >> >> > flight is only one mobile node), but for the mobile network, there >> >> > could be hundreds of millions of mobile nodes keep moving and will >> >> > result in lots of routing updates. >> >> > >> >> > 2. Billing and policy enforcement is not discussed in the draft. Do >> >> > you have any thoughts on this? >> >> > >> >> > Thanks, >> >> > Dapeng Liu >> >> > >> >> > 2013/7/11 Ryuji Wakikawa : >> >> >> Hi >> >> >> >> >> >> We submit a new document. Your comments are appreciated! >> >> >> >> >> >> thanks, >> >> >> ryuji >> >> >> >> >> >> >> >> >> Begin forwarded message: >> >> >> >> >> >>> From: internet-drafts@ietf.org >> >> >>> Subject: New Version Notification for >> >> >>> draft-matsushima-stateless-uplane-vepc-00.txt >> >> >>> Date: July 10, 2013 9:09:44 AM PDT >> >> >>> To: Ryuji Wakikawa , Satoru Matsushima >> >> >>> >> >> >>> >> >> >>> >> >> >>> A new version of I-D, draft-matsushima-stateless-uplane-vepc-00.txt >> >> >>> has been successfully submitted by Satoru Matsushima and posted to >> >> >>> the >> >> >>> IETF repository. >> >> >>> >> >> >>> Filename: draft-matsushima-stateless-uplane-vepc >> >> >>> Revision: 00 >> >> >>> Title: Stateless user-plane architecture for >> >> >>> virtualized EPC (vEPC) >> >> >>> Creation date: 2013-07-10 >> >> >>> Group: Individual Submission >> >> >>> Number of pages: 19 >> >> >>> URL: >> >> >>> >> >> >>> http://www.ietf.org/internet-drafts/draft-matsushima-stateless-uplane-vepc-00.txt >> >> >>> Status: >> >> >>> >> >> >>> http://datatracker.ietf.org/doc/draft-matsushima-stateless-uplane-vepc >> >> >>> Htmlized: >> >> >>> >> >> >>> http://tools.ietf.org/html/draft-matsushima-stateless-uplane-vepc-00 >> >> >>> >> >> >>> >> >> >>> Abstract: >> >> >>> We envision a new mobile architecture for the future Evolved >> >> >>> Packet >> >> >>> Core (EPC). The new architecture is designed to support the >> >> >>> virtualization scheme called NFV (Network Function >> >> >>> Virtualization). >> >> >>> In our architecture, the user plane of EPC is decoupled from the >> >> >>> control-plane and uses routing information to forward packets of >> >> >>> mobile nodes. Although the EPC control plane will run on >> >> >>> hypervisor, >> >> >>> our proposal does not modify the signaling of the EPC control >> >> >>> plane. >> >> >>> The benefits of our architecture are 1) scalability, 2) >> >> >>> flexibility >> >> >>> and 3) Manageability. How to run the EPC control plane on NFV is >> >> >>> out >> >> >>> of our focus in this document. >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> The IETF Secretariat >> >> >>> >> >> >> >> >> >> _______________________________________________ >> >> >> dmm mailing list >> >> >> dmm@ietf.org >> >> >> https://www.ietf.org/mailman/listinfo/dmm >> >> > >> >> > >> >> > >> >> > -- >> >> > >> >> > ------ >> >> > Best Regards, >> >> > Dapeng Liu >> >> >> > >> >> >> >> -- >> >> ------ >> Best Regards, >> Dapeng Liu > > -- ------ Best Regards, Dapeng Liu From satoru.matsushima@gmail.com Fri Jul 12 08:13:28 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A3E121F92B7 for ; Fri, 12 Jul 2013 08:13:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.319 X-Spam-Level: X-Spam-Status: No, score=-2.319 tagged_above=-999 required=5 tests=[AWL=-0.035, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M5GsqzM7pwe1 for ; Fri, 12 Jul 2013 08:13:27 -0700 (PDT) Received: from mail-la0-x232.google.com (mail-la0-x232.google.com [IPv6:2a00:1450:4010:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id B82A421F9B20 for ; Fri, 12 Jul 2013 08:13:26 -0700 (PDT) Received: by mail-la0-f50.google.com with SMTP id ep20so3374194lab.23 for ; Fri, 12 Jul 2013 08:13:25 -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=SbCv8WQn1NpUWGsvH2oOTLLuRT16P6wmTZnrxSSpwuY=; b=skdW2te2/YM3Modv9EbIyWlpUb9htdK4U1Tl1dpssxxEslYRj3hLWiimJWC96c03LJ X6NgmHIYmIfl0vCLrj0mix+DQKsqxJG7IxWOHjNxH5nr1jctHUwlunNHe3V1uxCBHgk9 idJSVN/NGy9JOYnFaZVChKmEBQY1hkDQD7bfaNbFVZdZqKVzDih3gRxluj88y2qbxwG1 UPvV0KrzWT1KoijsBzaryB7OzJyJSTLJaKxH1No1Gzo5wQ7Eco666+ZZ7CrKmVggyUIM udtveqN1UjKwB8mUvXIGZdnP2y+hVvfMwMkJM/aUnuCe4tDWx/ex0d0E5atLoNiSch47 NL1Q== MIME-Version: 1.0 X-Received: by 10.152.115.175 with SMTP id jp15mr19958492lab.12.1373642004480; Fri, 12 Jul 2013 08:13:24 -0700 (PDT) Received: by 10.112.167.169 with HTTP; Fri, 12 Jul 2013 08:13:24 -0700 (PDT) In-Reply-To: References: <20130710160944.11064.6824.idtracker@ietfa.amsl.com> <724A5F78-33A4-4608-82B9-231DC2AAE2F6@gmail.com> Date: Sat, 13 Jul 2013 00:13:24 +0900 Message-ID: From: Satoru Matsushima To: Liu Dapeng Content-Type: multipart/alternative; boundary=001a11c34e32b9c6da04e151f3f7 Cc: dmm Subject: Re: [DMM] New Version Notification for draft-matsushima-stateless-uplane-vepc-00.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 15:13:28 -0000 --001a11c34e32b9c6da04e151f3f7 Content-Type: text/plain; charset=ISO-8859-1 Liu, Yes, scalability issue is not discussed on the draft. Thanks for good clarification. Since EPC-E has two side of network that one is RAN side and another is core side, scalability issue is not only on this architecture. The core side could be the size of grobe as the Internet scale. But RAN side, an operator would separate to some networks by region, or population, whatever. So the question is to about how big the area will be to support is a requirement of each operator. There could be multiple EPC-E routers are deployed to support multiple RAN, or to solve scalability issue which huge number of MN population that exceed the capacity of single EPC-E. This architecture should cover all of these scenarios by routing basis strategy, so we'll update the draft in a next version. thanks! --satoru On Fri, Jul 12, 2013 at 6:11 PM, Liu Dapeng wrote: > Hi Satoru, > > Then the question is how big this area will be to support all the > users of an operator? > > regards, > Dapeng Liu > > 2013/7/12 Satoru Matsushima : > > Liu, > > > > MN's prefixes could be converged into an aggregated route. It is > routing. So > > MN are always expected within the area where it covers as long as the > > aggregated route existed in the core network. > > > > cheers, > > --satoru > > > > > > On Fri, Jul 12, 2013 at 10:59 AM, Liu Dapeng > wrote: > >> > >> 2013/7/12 Satoru Matsushima : > >> > Hi Liu, > >> > > >> > Thanks for your good question. We, bgp operator are struggle fast > >> > convergence for bgp that most of the issues come from best path > >> > recalculation on bgp speaker. In the proposed architecture we expect > no > >> > such > >> > kind of recalc but just simple update to epc-e from vepc. BGP is an > >> > incremental routing protocol so that bgp should be capable to > >> > continuously > >> > update route to mobile nodes as they moving. Please noted that it is > >> > happened only on RAN facing side on epc-e, not on ipv6 core network > >> > side. > >> > >> [Dapeng] You mean the MN's prefix can be converged in the core network? > >> You can > >> do this when the MN moves in a small area, but if the MN moves out > >> from that area, > >> it is difficult to converge. > >> > >> Thanks, > >> Dapeng Liu > >> > >> So > >> > routing in ipv6 core can be much stable. > >> > > >> > cheers, > >> > --satoru > >> > > >> > > >> > > >> > > >> > On Fri, Jul 12, 2013 at 12:24 AM, Ryuji Wakikawa > >> > > >> > wrote: > >> >> > >> >> Hi Liu > >> >> > >> >> For routing update matter, I will let my colleague to answer this. > >> >> The routing update is happened just within an operator's network. > >> >> The route for UE is just overwritten with the new information. I > >> >> believe > >> >> BGP can easily handle these updates. > >> >> > >> >> We haven't discussed billing and roaming. but what we are thinking > now > >> >> is > >> >> following. > >> >> If special treatment is needed (like roaming), we keep using the > >> >> original > >> >> EPC functions available at NFV. Packets are routed to EPC U-/C-planes > >> >> on > >> >> NFV. > >> >> For billing, we need some mechanism between U-/C- plane and didn't > >> >> identify a solution yet. We will try to identify it at the next > >> >> revision. > >> >> > >> >> thanks > >> >> ryuji > >> >> > >> >> On Jul 11, 2013, at 1:12 AM, Liu Dapeng > wrote: > >> >> > >> >> > Hi Ryuji, > >> >> > > >> >> > Thanks for posting an very interesting draft. Build distributed > >> >> > mobility using BGP has been discussed in DMM before. For example: > >> >> > http://tools.ietf.org/html/draft-mccann-dmm-flatarch-00. > >> >> > > >> >> > My comments: > >> >> > 1. How to deal with routing fluctuation problem? Using BGP in > Boeing > >> >> > on-board system is quite different from mobile network. Boeing > >> >> > on-board system normally does not have too much mobile node (the > >> >> > flight is only one mobile node), but for the mobile network, there > >> >> > could be hundreds of millions of mobile nodes keep moving and will > >> >> > result in lots of routing updates. > >> >> > > >> >> > 2. Billing and policy enforcement is not discussed in the draft. Do > >> >> > you have any thoughts on this? > >> >> > > >> >> > Thanks, > >> >> > Dapeng Liu > >> >> > > >> >> > 2013/7/11 Ryuji Wakikawa : > >> >> >> Hi > >> >> >> > >> >> >> We submit a new document. Your comments are appreciated! > >> >> >> > >> >> >> thanks, > >> >> >> ryuji > >> >> >> > >> >> >> > >> >> >> Begin forwarded message: > >> >> >> > >> >> >>> From: internet-drafts@ietf.org > >> >> >>> Subject: New Version Notification for > >> >> >>> draft-matsushima-stateless-uplane-vepc-00.txt > >> >> >>> Date: July 10, 2013 9:09:44 AM PDT > >> >> >>> To: Ryuji Wakikawa , Satoru Matsushima > >> >> >>> > >> >> >>> > >> >> >>> > >> >> >>> A new version of I-D, > draft-matsushima-stateless-uplane-vepc-00.txt > >> >> >>> has been successfully submitted by Satoru Matsushima and posted > to > >> >> >>> the > >> >> >>> IETF repository. > >> >> >>> > >> >> >>> Filename: draft-matsushima-stateless-uplane-vepc > >> >> >>> Revision: 00 > >> >> >>> Title: Stateless user-plane architecture for > >> >> >>> virtualized EPC (vEPC) > >> >> >>> Creation date: 2013-07-10 > >> >> >>> Group: Individual Submission > >> >> >>> Number of pages: 19 > >> >> >>> URL: > >> >> >>> > >> >> >>> > http://www.ietf.org/internet-drafts/draft-matsushima-stateless-uplane-vepc-00.txt > >> >> >>> Status: > >> >> >>> > >> >> >>> > http://datatracker.ietf.org/doc/draft-matsushima-stateless-uplane-vepc > >> >> >>> Htmlized: > >> >> >>> > >> >> >>> > http://tools.ietf.org/html/draft-matsushima-stateless-uplane-vepc-00 > >> >> >>> > >> >> >>> > >> >> >>> Abstract: > >> >> >>> We envision a new mobile architecture for the future Evolved > >> >> >>> Packet > >> >> >>> Core (EPC). The new architecture is designed to support the > >> >> >>> virtualization scheme called NFV (Network Function > >> >> >>> Virtualization). > >> >> >>> In our architecture, the user plane of EPC is decoupled from the > >> >> >>> control-plane and uses routing information to forward packets of > >> >> >>> mobile nodes. Although the EPC control plane will run on > >> >> >>> hypervisor, > >> >> >>> our proposal does not modify the signaling of the EPC control > >> >> >>> plane. > >> >> >>> The benefits of our architecture are 1) scalability, 2) > >> >> >>> flexibility > >> >> >>> and 3) Manageability. How to run the EPC control plane on NFV > is > >> >> >>> out > >> >> >>> of our focus in this document. > >> >> >>> > >> >> >>> > >> >> >>> > >> >> >>> > >> >> >>> The IETF Secretariat > >> >> >>> > >> >> >> > >> >> >> _______________________________________________ > >> >> >> dmm mailing list > >> >> >> dmm@ietf.org > >> >> >> https://www.ietf.org/mailman/listinfo/dmm > >> >> > > >> >> > > >> >> > > >> >> > -- > >> >> > > >> >> > ------ > >> >> > Best Regards, > >> >> > Dapeng Liu > >> >> > >> > > >> > >> > >> > >> -- > >> > >> ------ > >> Best Regards, > >> Dapeng Liu > > > > > > > > -- > > ------ > Best Regards, > Dapeng Liu > --001a11c34e32b9c6da04e151f3f7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Liu,

Yes, scalability iss= ue is not discussed on the draft. Thanks for good clarification.
Since E= PC-E has two side of network that one is RAN side and another is core side,= scalability issue is not only on this architecture. The core side could be= the size of grobe as the Internet scale. But RAN side, an operator would s= eparate to some networks by region, or population, whatever. So the questio= n is to about how big the area will be to support is a requirement of each = operator.

There could be multiple EPC-E routers are deployed to support=A0 = multiple RAN, or to solve scalability issue which huge number of MN populat= ion that exceed the capacity of single EPC-E. This architecture should cove= r all of these scenarios by routing basis strategy, so we'll update the= draft in a next version.

thanks!
--satoru

On Fri, Jul 12, 2013 at 6:11 PM, Liu Dapeng= <maxpassion@gmail.com> wrote:
Hi Satoru,

Then the question is how big this area will be to support all the
users of an operator?

regards,
Dapeng Liu

2013/7/12 Satoru Matsushima <satoru.matsushima@gmail.com>:
> Liu,
>
> MN's prefixes could be converged into an aggregated route. It is r= outing. So
> MN are always expected within the area where it covers as long as the<= br> > aggregated route existed in the core network.
>
> cheers,
> --satoru
>
>
> On Fri, Jul 12, 2013 at 10:59 AM, Liu Dapeng <maxpassion@gmail.com> wrote:
>>
>> 2013/7/12 Satoru Matsushima <satoru.matsushima@gmail.com>:
>> > Hi Liu,
>> >
>> > Thanks for your good question. We, bgp operator are struggle = fast
>> > convergence for bgp that most of the issues come from best pa= th
>> > recalculation on bgp speaker. In the proposed architecture we= expect no
>> > such
>> > kind of recalc but just simple update to epc-e from vepc. BGP= is an
>> > incremental routing protocol so that bgp should be capable to=
>> > continuously
>> > update route to mobile nodes as they moving. Please noted tha= t it is
>> > happened only on RAN facing side on epc-e, not on ipv6 core n= etwork
>> > side.
>>
>> [Dapeng] You mean the MN's prefix can be converged in the core= network?
>> You can
>> do this when the MN moves in a small area, but if the MN moves out=
>> from that area,
>> it is difficult to converge.
>>
>> Thanks,
>> Dapeng Liu
>>
>> =A0So
>> > routing in ipv6 core can be much stable.
>> >
>> > cheers,
>> > --satoru
>> >
>> >
>> >
>> >
>> > On Fri, Jul 12, 2013 at 12:24 AM, Ryuji Wakikawa
>> > <ryuji.wakikaw= a@gmail.com>
>> > wrote:
>> >>
>> >> Hi Liu
>> >>
>> >> For routing update matter, I will let my colleague to ans= wer this.
>> >> The routing update is happened just within an operator= 9;s network.
>> >> The route for UE is just overwritten with the new informa= tion. =A0 I
>> >> believe
>> >> BGP can easily handle these updates.
>> >>
>> >> We haven't discussed billing and roaming. but what we= are thinking now
>> >> is
>> >> following.
>> >> If special treatment is needed (like roaming), we keep us= ing the
>> >> original
>> >> EPC functions available at NFV. Packets are routed to EPC= U-/C-planes
>> >> on
>> >> NFV.
>> >> For billing, we need some mechanism between U-/C- plane a= nd didn't
>> >> identify a solution yet. We will try to identify it at th= e next
>> >> revision.
>> >>
>> >> thanks
>> >> ryuji
>> >>
>> >> On Jul 11, 2013, at 1:12 AM, Liu Dapeng <maxpassion@gmail.com> wrote:
>> >>
>> >> > Hi Ryuji,
>> >> >
>> >> > Thanks for posting an very interesting draft. Build = distributed
>> >> > mobility using BGP has been discussed in DMM before.= For example:
>> >> > http://tools.ietf.org/html/draft-mccann-d= mm-flatarch-00.
>> >> >
>> >> > My comments:
>> >> > 1. How to deal with routing fluctuation problem? Usi= ng BGP in Boeing
>> >> > on-board system is quite different from mobile netwo= rk. Boeing
>> >> > on-board system normally does not have too much mobi= le node (the
>> >> > flight is only one mobile node), but for the mobile = network, there
>> >> > could be hundreds of millions of mobile nodes keep m= oving and will
>> >> > result in lots of routing updates.
>> >> >
>> >> > 2. Billing and policy enforcement is not discussed i= n the draft. Do
>> >> > you have any thoughts on this?
>> >> >
>> >> > Thanks,
>> >> > Dapeng Liu
>> >> >
>> >> > 2013/7/11 Ryuji Wakikawa <ryuji.wakikawa@gmail.com>:
>> >> >> Hi
>> >> >>
>> >> >> We submit a new document. =A0Your comments are a= ppreciated!
>> >> >>
>> >> >> thanks,
>> >> >> ryuji
>> >> >>
>> >> >>
>> >> >> Begin forwarded message:
>> >> >>
>> >> >>> From: internet-drafts@ietf.org
>> >> >>> Subject: New Version Notification for
>> >> >>> draft-matsushima-stateless-uplane-vepc-00.tx= t
>> >> >>> Date: July 10, 2013 9:09:44 AM PDT
>> >> >>> To: Ryuji Wakikawa <ryuji.wakikawa@gmail.com>, Satoru Matsushima<= br> >> >> >>> <satoru.matsushima@g.softbank.co.jp>
>> >> >>>
>> >> >>>
>> >> >>> A new version of I-D, draft-matsushima-state= less-uplane-vepc-00.txt
>> >> >>> has been successfully submitted by Satoru Ma= tsushima and posted to
>> >> >>> the
>> >> >>> IETF repository.
>> >> >>>
>> >> >>> Filename: =A0 =A0 =A0draft-matsushima-statel= ess-uplane-vepc
>> >> >>> Revision: =A0 =A0 =A000
>> >> >>> Title: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 State= less user-plane architecture for
>> >> >>> virtualized EPC (vEPC)
>> >> >>> Creation date: =A0 =A0 =A0 =A0 2013-07-10 >> >> >>> Group: =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Indiv= idual Submission
>> >> >>> Number of pages: 19
>> >> >>> URL:
>> >> >>>
>> >> >>> http://= www.ietf.org/internet-drafts/draft-matsushima-stateless-uplane-vepc-00.txt<= /a>
>> >> >>> Status:
>> >> >>>
>> >> >>> http://datatracker= .ietf.org/doc/draft-matsushima-stateless-uplane-vepc
>> >> >>> Htmlized:
>> >> >>>
>> >> >>> http://tools.ietf.or= g/html/draft-matsushima-stateless-uplane-vepc-00
>> >> >>>
>> >> >>>
>> >> >>> Abstract:
>> >> >>> =A0We envision a new mobile architecture for= the future Evolved
>> >> >>> Packet
>> >> >>> =A0Core (EPC). =A0The new architecture is de= signed to support the
>> >> >>> =A0virtualization scheme called NFV (Network= Function
>> >> >>> Virtualization).
>> >> >>> =A0In our architecture, the user plane of EP= C is decoupled from the
>> >> >>> =A0control-plane and uses routing informatio= n to forward packets of
>> >> >>> =A0mobile nodes. =A0Although the EPC control= plane will run on
>> >> >>> hypervisor,
>> >> >>> =A0our proposal does not modify the signalin= g of the EPC control
>> >> >>> plane.
>> >> >>> =A0The benefits of our architecture are 1) s= calability, 2)
>> >> >>> flexibility
>> >> >>> =A0and 3) Manageability. =A0How to run the E= PC control plane on NFV is
>> >> >>> out
>> >> >>> =A0of our focus in this document.
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>>
>> >> >>> The IETF Secretariat
>> >> >>>
>> >> >>
>> >> >> _______________________________________________<= br> >> >> >> dmm mailing list
>> >> >> dmm@ietf.org=
>> >> >> https://www.ietf.org/mailman/listinfo/dmm
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> >
>> >> > ------
>> >> > Best Regards,
>> >> > Dapeng Liu
>> >>
>> >
>>
>>
>>
>> --
>>
>> ------
>> Best Regards,
>> Dapeng Liu
>
>



--

------
Best Regards,
Dapeng Liu

--001a11c34e32b9c6da04e151f3f7-- From jouni.nospam@gmail.com Fri Jul 12 13:33:16 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB77521F9EA9 for ; Fri, 12 Jul 2013 13:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yvt-gwrVIr3z for ; Fri, 12 Jul 2013 13:33:15 -0700 (PDT) Received: from mail-bk0-x22b.google.com (mail-bk0-x22b.google.com [IPv6:2a00:1450:4008:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 1423321F9F49 for ; Fri, 12 Jul 2013 13:33:11 -0700 (PDT) Received: by mail-bk0-f43.google.com with SMTP id jm2so3969117bkc.16 for ; Fri, 12 Jul 2013 13:33:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=hSE55KBZKm9sMhCCXVEjoaYR5gT5z0uDRnxSns/kIuQ=; b=WffeCX71yweKOaC7nB+xtag12qiS2nr4Pw9Ou+tx0un3WDbMovnwslUZ3EfOgpjcLm GpFK3SSHP3N2AYNX4rDLX8w6kXOrULbDAe3rzk9O2S3t2wijGcY4iFu51j9534QuZZtF 1vO5c0dI1V26hlC5cfRDDvZeHSEQkCDb7EM27xX8XqtpFg4YpYe6N2i1vPJsYPy+braI 4TWzqyJoh2vTiU92MPCkgRshPP089kj7kic/h1XjPqG2pQR1hWkbv0AktzvjI9URclMG 38o3AIKxE4hjjyGLFHXyJifIthzcAWjXDllpyFHJREpJLPtxZ1obSWFuzODHDZCUhLsB qFkQ== X-Received: by 10.205.21.129 with SMTP id qs1mr6821246bkb.13.1373661191137; Fri, 12 Jul 2013 13:33:11 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:d092:efaf:3186:bc93? ([2001:1bc8:101:f101:d092:efaf:3186:bc93]) by mx.google.com with ESMTPSA id ok9sm9549874bkb.8.2013.07.12.13.33.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 12 Jul 2013 13:33:09 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jouni Korhonen In-Reply-To: Date: Fri, 12 Jul 2013 23:33:08 +0300 Content-Transfer-Encoding: 7bit Message-Id: References: To: "dmm@ietf.org" X-Mailer: Apple Mail (2.1508) Subject: Re: [DMM] preliminary agenda forming up.. X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jul 2013 20:33:16 -0000 Draft agenda after updates.. we have a packed up agenda, so we need to be strict with the time per presentation. - Jouni ------------------------- THURSDAY, August 1, 2013, 0900-1130 CEST DMM WG IETF 87: 140 min (excluding break) Chairs: 09:00 o Agenda and WG update 10 min WG documents: 09:10 o draft-ietf-dmm-requirements 25 min (Anthony Chan) - Resolve all remaining Issue Tracker tickets. - Heading to IESG 09:35 o draft-ietf-dmm-best-practices-gap-analysis 25 min (Dapeng Liu/Juan-Carlos Zuniga) - Heading to WGLC Individual documents: 10:00 o draft-aliahmad-dmm-anchor-selection 10 min (Danny) 10:10 o draft-bernardos-dmm-distributed-anchoring-02 10 min (Carlos & Juan-Carlos) 10:20 Break for 10 mins 10:30 o draft-yegin-dmm-cnet-homing-00 15 min o draft-yegin-dmm-ondemand-mobility-00 (Alper) 10:45 o draft-chan-dmm-framework-01 10 min (Anthony) 10:55 o draft-matsushima-stateless-uplane-vepc-00 10 min (Ryuji) 11:05 o draft-bernardos-dmm-pmip-02 15 min o draft-bernardos-dmm-cmip-00 (Carlos) 11:20 o draft-liebsch-dmm-framework-analysis-0x 10 min (Marco) 11:30 AOB On Jul 11, 2013, at 9:27 AM, Jouni Korhonen wrote: > Folks, > > The agenda so far based on the requests we got and I managed to > track myslef.. if you think you were forgotten and need to be on > the agenda, just let the chairs know. With 10min individual I-D > slots we are pretty much within our time budget still. > > One of the key outcomes from this meeting is getting all remaining > stuff sorted out for the requirements document, so I encourage > folks to prepare for that. > > - Jouni & Julien > > ------------------------------------------------------------------------- > > THURSDAY, August 1, 2013, 0900-1130 CEST > > DMM WG IETF 87: 120 min (excluding break) > > Chairs: > > 09:00 o Agenda and WG update 10 min > > WG documents: > > 09:10 o draft-ietf-dmm-requirements 25 min > (Anthony Chan) > - Resolve all remaining Issue Tracker tickets. > - Heading to IESG (once done) > > 09:35 o draft-ietf-dmm-best-practices-gap-analysis 25 min > (Dapeng Liu/Juan-Carlos Zuniga) > > Individual documents: > > 10:00 o MA selection use-cases nn min > (Danny) > > 10:nn o draft-yegin-dmm-cnet-homing-00 nn min > 10:nn o draft-yegin-dmm-ondemand-mobility-00 nn min > (Alper) > > 10:nn o draft-bernardos-dmm-distributed-anchoring-02 nn min > (Carlos & Juan-Carlos) > > > 10:nn o draft-chan-dmm-framework-01 nn min > (Anthony) > From Peter.McCann@huawei.com Sat Jul 13 08:50:15 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC69C21F9EBD for ; Sat, 13 Jul 2013 08:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YB9cg51fqmiu for ; Sat, 13 Jul 2013 08:50:09 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 9C6EF21F9E51 for ; Sat, 13 Jul 2013 08:50:05 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATK18037; Sat, 13 Jul 2013 15:50:02 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sat, 13 Jul 2013 16:49:31 +0100 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sat, 13 Jul 2013 16:49:58 +0100 Received: from dfweml512-mbx.china.huawei.com ([169.254.1.163]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.007; Sat, 13 Jul 2013 08:49:52 -0700 From: Peter McCann To: Ryuji Wakikawa , "dmm@ietf.org" Thread-Topic: [DMM] Fwd: New Version Notification for draft-matsushima-stateless-uplane-vepc-00.txt Thread-Index: AQHOfYhO6nXicJERUkyx1u+nahA+K5liwv+A Date: Sat, 13 Jul 2013 15:49:50 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE716F4F1E8@dfweml512-mbx.china.huawei.com> References: <20130710160944.11064.6824.idtracker@ietfa.amsl.com> <724A5F78-33A4-4608-82B9-231DC2AAE2F6@gmail.com> In-Reply-To: <724A5F78-33A4-4608-82B9-231DC2AAE2F6@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.211] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [DMM] Fwd: New Version Notification for draft-matsushima-stateless-uplane-vepc-00.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 15:50:15 -0000 Hi, Ryuji, Satoru, If I understand your draft correctly, you are encoding the PGW ID and the TEID into the prefix portion of an IPv6 address. You seem to allocate 16 bits for the TEID. I thought that TEIDs in 3GPP were 32 bits. Do you have enough space? Could you instead encode the TEID in the Interface Identifier part of the IPv6 address? Perhaps I have misunderstood how the routing update is supposed to work, but why do you need to encode the UE's prefix or address at all in the Next-Hop IPv6 address? You have the UE's prefix as the Destination, and the Next-Hop can just point to the tunnel, correct? -Pete Ryuji Wakikawa wrote: > Hi >=20 > We submit a new document. Your comments are appreciated! >=20 > thanks, > ryuji >=20 >=20 > Begin forwarded message: >=20 >> From: internet-drafts@ietf.org >> Subject: New Version Notification for >> draft-matsushima-stateless-uplane-vepc-00.txt >> Date: July 10, 2013 9:09:44 AM PDT >> To: Ryuji Wakikawa , Satoru Matsushima >> >>=20 >>=20 >> A new version of I-D, draft-matsushima-stateless-uplane-vepc-00.txt has >> been successfully submitted by Satoru Matsushima and posted to the IETF >> repository. >>=20 >> Filename: draft-matsushima-stateless-uplane-vepc Revision: 00 >> Title: Stateless user-plane architecture for virtualized EPC (vEPC) >> Creation date: 2013-07-10 Group: Individual Submission Number of >> pages: 19 URL: http://www.ietf.org/internet-drafts/draft- >> matsushima-stateless-uplane-vepc-00.txt Status: =20 >> http://datatracker.ietf.org/doc/draft-matsushima- stateless-uplane-vepc >> Htmlized: http://tools.ietf.org/html/draft-matsushima- >> stateless-uplane-vepc-00 >>=20 >>=20 >> Abstract: >> We envision a new mobile architecture for the future Evolved Packet >> Core (EPC). The new architecture is designed to support the >> virtualization scheme called NFV (Network Function Virtualization). >> In our architecture, the user plane of EPC is decoupled from the >> control-plane and uses routing information to forward packets of >> mobile nodes. Although the EPC control plane will run on hypervisor, >> our proposal does not modify the signaling of the EPC control plane. >> The benefits of our architecture are 1) scalability, 2) flexibility >> and 3) Manageability. How to run the EPC control plane on NFV is out >> of our focus in this document. >>=20 >>=20 >>=20 >> The IETF Secretariat >>=20 >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From satoru.matsushima@gmail.com Sat Jul 13 10:21:01 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61F2B21F9A51 for ; Sat, 13 Jul 2013 10:21:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4+4BZbPVeTH for ; Sat, 13 Jul 2013 10:21:00 -0700 (PDT) Received: from mail-pb0-x22e.google.com (mail-pb0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 3358D21F8423 for ; Sat, 13 Jul 2013 10:21:00 -0700 (PDT) Received: by mail-pb0-f46.google.com with SMTP id rq2so9949142pbb.5 for ; Sat, 13 Jul 2013 10:20:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=KBs/nEGuj67PtNDyxRporSTiCrYEtJx7EKmDtJiai0w=; b=OEPvdQInpOT0uR4OjRejLJk1lqHY5YJtg7DHlTDc6x3QT0PrKt5zyPGqkpUpVfWKWC RkGHlY/bgW1SW3Ajup0o/UiYAVV4fchgrSOs5plKcLn5sDEnl5hU2kq8Q+027atl2B1y tRKNw3h+vFK5kWXHCbMGbm0FpYu0a96HAZi/cLC4cfC4Y7Fy33cH78hcmrmCrnmj8Syw 6jIhaDHdGcC7uztd7BVyNwYwmDPELvAqaczhHobGryKjiCaIxiNpnQSibknG3WRaaeb2 04swvyKYTrMorUWP9dND2XpSLIJ+icPdlmk/w+IgOiZtgDm8Lw10JYO7k4zJSCF1SE6W rp6g== X-Received: by 10.69.8.164 with SMTP id dl4mr47053788pbd.125.1373736058777; Sat, 13 Jul 2013 10:20:58 -0700 (PDT) Received: from ?IPv6:2400:2411:8900::9cf6:a7db:4393:dcfe? ([2400:2411:8900:0:9cf6:a7db:4393:dcfe]) by mx.google.com with ESMTPSA id qg10sm21898235pbb.2.2013.07.13.10.20.55 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 13 Jul 2013 10:20:57 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Satoru Matsushima In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716F4F1E8@dfweml512-mbx.china.huawei.com> Date: Sun, 14 Jul 2013 02:20:53 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <504A19F8-3C16-4821-86A5-3C3BCA96FE78@gmail.com> References: <20130710160944.11064.6824.idtracker@ietfa.amsl.com> <724A5F78-33A4-4608-82B9-231DC2AAE2F6@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716F4F1E8@dfweml512-mbx.china.huawei.com> To: Peter McCann X-Mailer: Apple Mail (2.1508) Cc: "dmm@ietf.org" Subject: Re: [DMM] Fwd: New Version Notification for draft-matsushima-stateless-uplane-vepc-00.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 17:21:01 -0000 Hi Pete, Thanks for your comments. On 2013/07/14, at 0:49, Peter McCann wrote: > Hi, Ryuji, Satoru, >=20 > If I understand your draft correctly, you are encoding the PGW ID and = the > TEID into the prefix portion of an IPv6 address. You seem to allocate > 16 bits for the TEID. I thought that TEIDs in 3GPP were 32 bits. Do = you > have enough space? Could you instead encode the TEID in the Interface > Identifier part of the IPv6 address? Oops. Yes, you are correct. I'll update it soon. Using TEID is one of the candidates of generating unique MN's prefix as = described in stateless-pd draft. (http://tools.ietf.org/html/draft-savolainen-stateless-pd-01) Full of 32bits space is not necessary because embedded ID could be = shortened by taking a part 16 bits or more longer from an TEID as long = as its uniqueness is kept. We assume that the RAN side TEID assigned by = SGW are encoded to MN's prefix.=20 >=20 > Perhaps I have misunderstood how the routing update is supposed to = work, > but why do you need to encode the UE's prefix or address at all in the > Next-Hop IPv6 address? You have the UE's prefix as the Destination, = and > the Next-Hop can just point to the tunnel, correct? UE's prefix is not encoded in the next-hop. The next-hop indicates = tunnel endpoint in the way of BGP remote next-hop draft. Please see = "http://tools.ietf.org/html/draft-vandevelde-idr-remote-next-hop-03" cheers, --satoru >=20 > -Pete >=20 > Ryuji Wakikawa wrote: >> Hi >>=20 >> We submit a new document. Your comments are appreciated! >>=20 >> thanks, >> ryuji >>=20 >>=20 >> Begin forwarded message: >>=20 >>> From: internet-drafts@ietf.org >>> Subject: New Version Notification for >>> draft-matsushima-stateless-uplane-vepc-00.txt >>> Date: July 10, 2013 9:09:44 AM PDT >>> To: Ryuji Wakikawa , Satoru Matsushima >>> >>>=20 >>>=20 >>> A new version of I-D, draft-matsushima-stateless-uplane-vepc-00.txt = has >>> been successfully submitted by Satoru Matsushima and posted to the = IETF >>> repository. >>>=20 >>> Filename: draft-matsushima-stateless-uplane-vepc Revision: = 00 >>> Title: Stateless user-plane architecture for = virtualized EPC (vEPC) >>> Creation date: 2013-07-10 Group: Individual = Submission Number of >>> pages: 19 URL: = http://www.ietf.org/internet-drafts/draft- >>> matsushima-stateless-uplane-vepc-00.txt Status: =20 >>> http://datatracker.ietf.org/doc/draft-matsushima- = stateless-uplane-vepc >>> Htmlized: http://tools.ietf.org/html/draft-matsushima- >>> stateless-uplane-vepc-00 >>>=20 >>>=20 >>> Abstract: >>> We envision a new mobile architecture for the future Evolved Packet >>> Core (EPC). The new architecture is designed to support the >>> virtualization scheme called NFV (Network Function Virtualization). >>> In our architecture, the user plane of EPC is decoupled from the >>> control-plane and uses routing information to forward packets of >>> mobile nodes. Although the EPC control plane will run on = hypervisor, >>> our proposal does not modify the signaling of the EPC control = plane. >>> The benefits of our architecture are 1) scalability, 2) flexibility >>> and 3) Manageability. How to run the EPC control plane on NFV is = out >>> of our focus in this document. >>>=20 >>>=20 >>>=20 >>> The IETF Secretariat >>>=20 >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >=20 >=20 >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From jouni.nospam@gmail.com Sat Jul 13 13:13:17 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A8FB321F9A98 for ; Sat, 13 Jul 2013 13:13:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YYlQa4CqNWYX for ; Sat, 13 Jul 2013 13:13:16 -0700 (PDT) Received: from mail-bk0-x236.google.com (mail-bk0-x236.google.com [IPv6:2a00:1450:4008:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id B63E221F9A8E for ; Sat, 13 Jul 2013 13:13:11 -0700 (PDT) Received: by mail-bk0-f54.google.com with SMTP id it16so4087992bkc.41 for ; Sat, 13 Jul 2013 13:13:10 -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:x-mailer; bh=qGR+OYS3FQ0gp6jxJM6H2mTQ5rIKbvP5rC4dFulJe6U=; b=YKaTHfs+WVxNFY5ELIqKNiOg2VNUV5V1o0CbOaCYLPGZ3ALXucRzkPDlbiHpysAmjL WCc//uiBMGc9wnZgA405t7NiPlt1kAEtGUHO10YYBMc0is7r5SjZ1+7MxJv4kEwxD8eK xGbbLXWS82JUPN2CbkqixqZ4J6jB9YF6nzlE8gnf//X5Et0h2ZadIMYPAT9eoGsNIH9o /eoCGYCsUVq4cS+t83m4vgjuWM+1cuPOswA52ViNWiWGBZ3BQr/zaADYG3bRv7LSO58X QRws3VYBMmvYIzQyilStB9HtBtonWbB+HZZJobUggWjY4wMXq9noxJQW7iNXUa8Eps8B 9nWw== X-Received: by 10.204.228.207 with SMTP id jf15mr7135306bkb.16.1373746390789; Sat, 13 Jul 2013 13:13:10 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:24d9:6f3f:6d0e:ba68? ([2001:1bc8:101:f101:24d9:6f3f:6d0e:ba68]) by mx.google.com with ESMTPSA id de17sm10387741bkb.5.2013.07.13.13.13.07 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 13 Jul 2013 13:13:08 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Jouni In-Reply-To: <504A19F8-3C16-4821-86A5-3C3BCA96FE78@gmail.com> Date: Sat, 13 Jul 2013 23:13:06 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <966B4584-6662-459E-98BD-28AD9B9BD920@gmail.com> References: <20130710160944.11064.6824.idtracker@ietfa.amsl.com> <724A5F78-33A4-4608-82B9-231DC2AAE2F6@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716F4F1E8@dfweml512-mbx.china.huawei.com> <504A19F8-3C16-4821-86A5-3C3BCA96FE78@gmail.com> To: Satoru Matsushima X-Mailer: Apple Mail (2.1283) Cc: Peter McCann , "dmm@ietf.org" Subject: Re: [DMM] New Version Notification for draft-matsushima-stateless-uplane-vepc-00.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Jul 2013 20:13:17 -0000 On Jul 13, 2013, at 8:20 PM, Satoru Matsushima wrote: > Hi Pete, >=20 > Thanks for your comments. >=20 > On 2013/07/14, at 0:49, Peter McCann wrote: >=20 >> Hi, Ryuji, Satoru, >>=20 >> If I understand your draft correctly, you are encoding the PGW ID and = the >> TEID into the prefix portion of an IPv6 address. You seem to = allocate >> 16 bits for the TEID. I thought that TEIDs in 3GPP were 32 bits. Do = you >> have enough space? Could you instead encode the TEID in the = Interface >> Identifier part of the IPv6 address? >=20 > Oops. Yes, you are correct. I'll update it soon. > Using TEID is one of the candidates of generating unique MN's prefix = as described in stateless-pd draft. > (http://tools.ietf.org/html/draft-savolainen-stateless-pd-01) >=20 > Full of 32bits space is not necessary because embedded ID could be = shortened by taking a part 16 bits or more longer from an TEID as long = as its uniqueness is kept. We assume that the RAN side TEID assigned by = SGW are encoded to MN's prefix.=20 TEIDs do not have structure, thus I would be careful starting to take = shorter subsets out of it.=20 There is quite a bit of vendor specific information already encoded into = TEIDs so the text need to be clear it does not assume anything about TEID or then state each = deployment & prefix "structure" is deployment/vendor specific. - Jouni >> Perhaps I have misunderstood how the routing update is supposed to = work, >> but why do you need to encode the UE's prefix or address at all in = the >> Next-Hop IPv6 address? You have the UE's prefix as the Destination, = and >> the Next-Hop can just point to the tunnel, correct? >=20 > UE's prefix is not encoded in the next-hop. The next-hop indicates = tunnel endpoint in the way of BGP remote next-hop draft. Please see = "http://tools.ietf.org/html/draft-vandevelde-idr-remote-next-hop-03" >=20 > cheers, > --satoru >=20 >>=20 >> -Pete >>=20 >> Ryuji Wakikawa wrote: >>> Hi >>>=20 >>> We submit a new document. Your comments are appreciated! >>>=20 >>> thanks, >>> ryuji >>>=20 >>>=20 >>> Begin forwarded message: >>>=20 >>>> From: internet-drafts@ietf.org >>>> Subject: New Version Notification for >>>> draft-matsushima-stateless-uplane-vepc-00.txt >>>> Date: July 10, 2013 9:09:44 AM PDT >>>> To: Ryuji Wakikawa , Satoru Matsushima >>>> >>>>=20 >>>>=20 >>>> A new version of I-D, draft-matsushima-stateless-uplane-vepc-00.txt = has >>>> been successfully submitted by Satoru Matsushima and posted to the = IETF >>>> repository. >>>>=20 >>>> Filename: draft-matsushima-stateless-uplane-vepc Revision: = 00 >>>> Title: Stateless user-plane architecture for = virtualized EPC (vEPC) >>>> Creation date: 2013-07-10 Group: Individual = Submission Number of >>>> pages: 19 URL: = http://www.ietf.org/internet-drafts/draft- >>>> matsushima-stateless-uplane-vepc-00.txt Status: =20 >>>> http://datatracker.ietf.org/doc/draft-matsushima- = stateless-uplane-vepc >>>> Htmlized: http://tools.ietf.org/html/draft-matsushima- >>>> stateless-uplane-vepc-00 >>>>=20 >>>>=20 >>>> Abstract: >>>> We envision a new mobile architecture for the future Evolved Packet >>>> Core (EPC). The new architecture is designed to support the >>>> virtualization scheme called NFV (Network Function Virtualization). >>>> In our architecture, the user plane of EPC is decoupled from the >>>> control-plane and uses routing information to forward packets of >>>> mobile nodes. Although the EPC control plane will run on = hypervisor, >>>> our proposal does not modify the signaling of the EPC control = plane. >>>> The benefits of our architecture are 1) scalability, 2) flexibility >>>> and 3) Manageability. How to run the EPC control plane on NFV is = out >>>> of our focus in this document. >>>>=20 >>>>=20 >>>>=20 >>>> The IETF Secretariat >>>>=20 >>>=20 >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm >>=20 >>=20 >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From danny.moses@intel.com Sun Jul 14 03:40:38 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A125C21E805A for ; Sun, 14 Jul 2013 03:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kKnIMCUJgPsY for ; Sun, 14 Jul 2013 03:40:34 -0700 (PDT) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by ietfa.amsl.com (Postfix) with ESMTP id 6AA2B21E804D for ; Sun, 14 Jul 2013 03:40:34 -0700 (PDT) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 14 Jul 2013 03:40:14 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.89,663,1367996400"; d="scan'208,217";a="369986924" Received: from fmsmsx107.amr.corp.intel.com ([10.19.9.54]) by fmsmga002.fm.intel.com with ESMTP; 14 Jul 2013 03:40:14 -0700 Received: from fmsmsx152.amr.corp.intel.com (10.19.17.221) by FMSMSX107.amr.corp.intel.com (10.19.9.54) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sun, 14 Jul 2013 03:40:14 -0700 Received: from hasmsx103.ger.corp.intel.com (10.184.198.6) by fmsmsx152.amr.corp.intel.com (10.19.17.221) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sun, 14 Jul 2013 03:40:14 -0700 Received: from hasmsx106.ger.corp.intel.com ([169.254.2.62]) by HASMSX103.ger.corp.intel.com ([169.254.6.70]) with mapi id 14.03.0123.003; Sun, 14 Jul 2013 13:40:12 +0300 From: "Moses, Danny" To: "dmm@ietf.org" Thread-Topic: New version of draft-aliahmad-dmm-anchor-selection-01 Thread-Index: Ac6AfoRgl2sv4TFGSI2sBNPlfj9S/A== Date: Sun, 14 Jul 2013 10:40:11 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.184.70.12] Content-Type: multipart/alternative; boundary="_000_F0CF5715D3D1884BAC731EA1103AC281027F159AHASMSX106gercor_" MIME-Version: 1.0 Subject: [DMM] New version of draft-aliahmad-dmm-anchor-selection-01 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Jul 2013 10:40:38 -0000 --_000_F0CF5715D3D1884BAC731EA1103AC281027F159AHASMSX106gercor_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi guys, Thank you for the valuable comments regarding the mobility anchor selection= presentation during the face-to-face meeting in Orlando. We Have addressed the comments that we received during the draft's presenta= tion and produced a new version of the draft (draft-aliahmad-dmm-anchor-sel= ection-01). This version includes a list of applications and a mapping table to= the traffic characteristics described in the draft. It also includes link= s to some traffic measurements that were published by Cisco including netwo= rk and user behavior, which highlights the importance of mobility anchor se= lection. We will appreciate information from the WG on traffic characteristics in re= al networks (This point was addressed during the session and some of the pa= rticipants mentioned the possibility of having some). We believe that traf= fic characteristics in terms of flow lengths and user's consumption pattern= s in terms of presence of a mobile node in various points of access (mobili= ty characteristics of mobile nodes) are very interesting. We are wondering = if anyone can share any data. Another concern expressed in the meeting was regarding the complexity of th= e solution. Although we have some initial thoughts about selection ideas, w= e prefer at this stage to concentrate on the problem statement. We believe = that it will be more efficient to address potential solutions after complet= ing the problem definition. We appreciate all feedback that you can provide. Regards, The draft authors --------------------------------------------------------------------- A member of the Intel Corporation group of companies This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. --_000_F0CF5715D3D1884BAC731EA1103AC281027F159AHASMSX106gercor_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable
Hi guys,
Thank you for the valuable comments rega= rding the mobility anchor selection presentation during the face-to-face me= eting in Orlando.
We Have addressed the comments that we r= eceived during the draft’s presentation and produced a new version of= the draft (draft-aliahmad-dmm-anchor-selection-01= ). This version includes a list of applications and a mapping table to the tra= ffic characteristics described in the draft. It  also includes links t= o some traffic measurements that were published by Cisco including network = and user behavior, which highlights the importance of mobility anchor selection.
We will appreciate information from the = WG on traffic characteristics in real networks (This point was addressed du= ring the session and some of the participants mentioned the possibility of = having some).  We believe that traffic characteristics in terms of flow lengths and user’s consumption patte= rns in terms of presence of a mobile node in various points of access (mobi= lity characteristics of mobile nodes) are very interesting. We are wonderin= g if anyone can share any data.
Another concern expressed in the meeting= was regarding the complexity of the solution. Although we have some initia= l thoughts about selection ideas, we prefer at this stage to concentrate on= the problem statement. We believe that it will be more efficient to address potential solutions after complet= ing the problem definition.
We appreciate all feedback that you can = provide.
Regards,
      &nbs= p; The draft authors
 
 

---------------------------------------------------------------------
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.

--_000_F0CF5715D3D1884BAC731EA1103AC281027F159AHASMSX106gercor_-- From Peter.McCann@huawei.com Mon Jul 15 11:49:18 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25E3C11E81D5 for ; Mon, 15 Jul 2013 11:49:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jXJT7zD24cob for ; Mon, 15 Jul 2013 11:49:14 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 654AD11E817C for ; Mon, 15 Jul 2013 11:49:13 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVA77835; Mon, 15 Jul 2013 18:49:11 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 15 Jul 2013 19:48:37 +0100 Received: from DFWEML408-HUB.china.huawei.com (10.193.5.134) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 15 Jul 2013 19:49:09 +0100 Received: from dfweml512-mbx.china.huawei.com ([169.254.1.163]) by dfweml408-hub.china.huawei.com ([10.193.5.134]) with mapi id 14.01.0323.007; Mon, 15 Jul 2013 11:49:05 -0700 From: Peter McCann To: Satoru Matsushima Thread-Topic: [DMM] Fwd: New Version Notification for draft-matsushima-stateless-uplane-vepc-00.txt Thread-Index: AQHOf+1dxJFkGTjvHU+gGYpUTKOvgJlmE6Ag Date: Mon, 15 Jul 2013 18:49:05 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE716F4F44C@dfweml512-mbx.china.huawei.com> References: <20130710160944.11064.6824.idtracker@ietfa.amsl.com> <724A5F78-33A4-4608-82B9-231DC2AAE2F6@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716F4F1E8@dfweml512-mbx.china.huawei.com> <504A19F8-3C16-4821-86A5-3C3BCA96FE78@gmail.com> In-Reply-To: <504A19F8-3C16-4821-86A5-3C3BCA96FE78@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.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dmm@ietf.org" Subject: Re: [DMM] Fwd: New Version Notification for draft-matsushima-stateless-uplane-vepc-00.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jul 2013 18:49:18 -0000 Hi, Satoru, Satoru Matsushima wrote: > Hi Pete, >=20 > Thanks for your comments. >=20 > On 2013/07/14, at 0:49, Peter McCann wrote: >=20 >> Hi, Ryuji, Satoru, >>=20 >> If I understand your draft correctly, you are encoding the PGW ID >> and the TEID into the prefix portion of an IPv6 address. You seem >> to allocate >> 16 bits for the TEID. I thought that TEIDs in 3GPP were 32 bits. >> Do you have enough space? Could you instead encode the TEID in the >> Interface Identifier part of the IPv6 address? >=20 > Oops. Yes, you are correct. I'll update it soon. Using TEID is one of > the candidates of generating unique MN's prefix as described in > stateless-pd draft. > (http://tools.ietf.org/html/draft-savolainen-stateless-pd-01) > > Full of 32bits space is not necessary because embedded ID could be > shortened by taking a part 16 bits or more longer from an TEID as long > as its uniqueness is kept. We assume that the RAN side TEID assigned > by SGW are encoded to MN's prefix. >=20 >>=20 >> Perhaps I have misunderstood how the routing update is supposed to >> work, but why do you need to encode the UE's prefix or address at >> all in the Next-Hop IPv6 address? You have the UE's prefix as the >> Destination, and the Next-Hop can just point to the tunnel, correct? >=20 > UE's prefix is not encoded in the next-hop. The next-hop indicates > tunnel endpoint in the way of BGP remote next-hop draft. Please see > "http://tools.ietf.org/html/draft-vandevelde-idr-remote-next-hop-03" I guess I don't understand the "PDN Prefix" and "subnet ID" fields that you have in Figure 4. You state: Each PDN is assumed to have single or several prefixes (called PDN prefix) used to generate UE's address. Followed by the PDN prefix in Figure 4, there is 16-bit TEID assigned for a UE's session at SGW on the control plane. TEID is 16 bits identifier in GTP header to distinguish each bearer. The remaining bits are filled by subnet ID. The prefix is allocated per UE and used for address assignment by SLAAC or DHCPv6. Is Figure 4 supposed to be the Next Hop or the Destination? I assumed it was Next Hop because it has the TEID encoded in it. However, some of the above paragraph leads me to believe it is about the UE's user plane IP address. -Pete >=20 > cheers, > --satoru >=20 >>=20 >> -Pete >>=20 >> Ryuji Wakikawa wrote: >>> Hi >>>=20 >>> We submit a new document. Your comments are appreciated! >>>=20 >>> thanks, >>> ryuji >>>=20 >>>=20 >>> Begin forwarded message: >>>=20 >>>> From: internet-drafts@ietf.org >>>> Subject: New Version Notification for >>>> draft-matsushima-stateless-uplane-vepc-00.txt >>>> Date: July 10, 2013 9:09:44 AM PDT >>>> To: Ryuji Wakikawa , Satoru Matsushima >>>> >>>>=20 >>>>=20 >>>> A new version of I-D, >>>> draft-matsushima-stateless-uplane-vepc-00.txt >>>> has been successfully submitted by Satoru Matsushima and posted to >>>> the IETF repository. >>>>=20 >>>> Filename: draft-matsushima-stateless-uplane-vepc Revision: 00 >>>> Title: Stateless user-plane architecture for virtualized EPC (vEPC) >>>> Creation date: 2013-07-10 Group: Individual Submission Number of >>>> pages: 19 URL: http://www.ietf.org/internet- >>>> drafts/draft- matsushima-stateless-uplane-vepc-00.txt Status: >>>> http://datatracker.ietf.org/doc/draft-matsushima- stateless-uplane- >>>> vepc Htmlized: http://tools.ietf.org/html/draft-matsushima- >>>> stateless-uplane-vepc-00 >>>>=20 >>>>=20 >>>> Abstract: >>>> We envision a new mobile architecture for the future Evolved > Packet >>>> Core (EPC). The new architecture is designed to support the >>>> virtualization scheme called NFV (Network Function Virtualization). >>>> In our architecture, the user plane of EPC is decoupled from the >>>> control-plane and uses routing information to forward packets of >>>> mobile nodes. Although the EPC control plane will run on >>>> hypervisor, our proposal does not modify the signaling of the EPC > control plane. >>>> The benefits of our architecture are 1) scalability, 2) > flexibility >>>> and 3) Manageability. How to run the EPC control plane on NFV is >>>> out of our focus in this document. >>>>=20 >>>>=20 >>>>=20 >>>> The IETF Secretariat >>>>=20 >>>=20 >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm >>=20 >>=20 >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm From satoru.matsushima@gmail.com Tue Jul 16 00:25:44 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6314811E80E2 for ; Tue, 16 Jul 2013 00:25:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mQLJixGsAkYG for ; Tue, 16 Jul 2013 00:25:41 -0700 (PDT) Received: from mail-pb0-x232.google.com (mail-pb0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 7B19721E81B1 for ; Tue, 16 Jul 2013 00:25:41 -0700 (PDT) Received: by mail-pb0-f50.google.com with SMTP id wz7so394361pbc.9 for ; Tue, 16 Jul 2013 00:25:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=OQLRkcZw0JJxmCG/wCZU0oJoaGeHV9GQIxCR6Fydi14=; b=xhDc3U63XF4Ku1GNV582qjkCbpVnz/esiEqbbNIeCX9BUAMsCzzAfXycUMTxekGAVW KR39V9WWuXTuOkJ8J/3F0jsw6UXtPq6eBciwM4Kcec7FLpchxAbXI4gzrh3cG+t99Oh4 qms42gpU6wJ3+9QiJCeujmvxDqQmZ4lyNY0oxQmEz/yE/ISfzAKejb+dQTHL78dYJaEf PHAUGH8ygkqkpGmrN0mni/+7V2J5cY5Ek9gnKt9y6yhT9t3pK/cFLZWL2Q1ySw7ReQ00 93SU3XeXE0DnOvISn/PK9TcSQlNlWEudHJoNZPzsiyKdeDRBEqvrRchmONAVs4AkByeA zI6A== X-Received: by 10.66.216.164 with SMTP id or4mr1246403pac.95.1373959541192; Tue, 16 Jul 2013 00:25:41 -0700 (PDT) Received: from [10.248.69.9] (i118-21-136-4.s30.a048.ap.plala.or.jp. [118.21.136.4]) by mx.google.com with ESMTPSA id z14sm405508pbt.0.2013.07.16.00.25.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Jul 2013 00:25:38 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Satoru Matsushima In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716F4F44C@dfweml512-mbx.china.huawei.com> Date: Tue, 16 Jul 2013 16:25:33 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20130710160944.11064.6824.idtracker@ietfa.amsl.com> <724A5F78-33A4-4608-82B9-231DC2AAE2F6@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716F4F1E8@dfweml512-mbx.china.huawei.com> <504A19F8-3C16-4821-86A5-3C3BCA96FE78@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716F4F44C@dfweml512-mbx.china.huawei.com> To: Peter McCann X-Mailer: Apple Mail (2.1508) Cc: "dmm@ietf.org" Subject: Re: [DMM] Fwd: New Version Notification for draft-matsushima-stateless-uplane-vepc-00.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 07:25:44 -0000 Hi Peter, On 2013/07/16, at 3:49, Peter McCann wrote: > I guess I don't understand the "PDN Prefix" and "subnet ID" fields = that > you have in Figure 4. You state: >=20 > Each PDN is assumed to have single or several prefixes (called PDN > prefix) used to generate UE's address. Followed by the PDN prefix = in > Figure 4, there is 16-bit TEID assigned for a UE's session at SGW on > the control plane. TEID is 16 bits identifier in GTP header to > distinguish each bearer. The remaining bits are filled by subnet = ID. > The prefix is allocated per UE and used for address assignment by > SLAAC or DHCPv6. >=20 > Is Figure 4 supposed to be the Next Hop or the Destination? I assumed > it was Next Hop because it has the TEID encoded in it. However, some > of the above paragraph leads me to believe it is about the UE's user > plane IP address. >=20 The figure 4 illustrates UE's prefix so it shows the destination.=20 Encoding TEID is just a seed to create UE's prefix in the stateless-pd = manner. We hasn't illustrate yet how to encode the TEID in next-hop.=20 But as we mentioned in the document, we expect BGP remote next-hop as = the way to encode it in the sub-TLV of the remote next-hop attribute. cheers, --satoru From alper.yegin@yegin.org Tue Jul 16 03:31:06 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0746711E80A5 for ; Tue, 16 Jul 2013 03:31:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.35 X-Spam-Level: X-Spam-Status: No, score=-102.35 tagged_above=-999 required=5 tests=[AWL=0.249, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SY59XeLwp6HU for ; Tue, 16 Jul 2013 03:31:01 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 9017011E8195 for ; Tue, 16 Jul 2013 03:31:01 -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 0Lmrp6-1UVVc43F1w-00hAbl; Tue, 16 Jul 2013 06:31:00 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Alper Yegin In-Reply-To: <24C0F3E22276D9438D6F366EB89FAEA8103223DB@xmb-rcd-x03.cisco.com> Date: Tue, 16 Jul 2013 13:30:59 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <24C0F3E22276D9438D6F366EB89FAEA8103223DB@xmb-rcd-x03.cisco.com> To: Sri Gundavelli (sgundave) X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:duKjSk4xYphN92V0GrNhzgRqJ2kZKlBNJ0+G8iOOoNO vnD5YOkmnqNQ2SCNb+QPPAGvUoqKfRmTGY/fMdD4rM40NGX8a1 zcctZLMA++U4OP9ON8w2mEg69Pi8QnQUlZJZhDjit6olOF4vQ7 35F3OphFVVCeSojUYZ5dWTj0o/g2xKRh+ZSpTE5Jx841FOSbrz h2cm2HlWPasCt1G59gbBKj9uD65KO+l98pMmmAFXz1UGTG3zf9 vyTYFspsUz/iNt2+KO1YZ82IWr0ID3kaBBLF7SSeUuIFJ9BSXn BPWdKFfu7uN2U9tyuGnhPAdInADw/HI506nrRDHC+pjU/UN03a fmw/1BbuLmt1fks9qMZbNKaffG2zTYn+QDYXUCajNtbHDGd5ih r/VGV19YMFcFw== Cc: "dmm@ietf.org" Subject: Re: [DMM] Two new drafts X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 10:31:06 -0000 Hi Sri, On Jul 9, 2013, at 8:22 AM, Sri Gundavelli (sgundave) wrote: > Hi Alper, >=20 > Thanks for sharing the documents. >=20 Thank you for the feedback. > I did a quick review of the dmm-ondemand draft. This is inline with my > thinking as well. IMO, the following base semantics will allow us to > realize some of the DMM deployment models. >=20 > - Prefix Coloring/ Coloring of IP addresses based on the properties >=20 > - Delivering the properties as meta-data in address assignment = procedures > (ND, DHCP ..) > - Evolving the source address selection Rules, allowing application to > pick source address based on the requirements >=20 > With these semantics, a UE can obtain multiple IP addresses with = different > properties, bind applications to those addresses based on the = application > requirements, roam within the network loosing some local addresses and > generating some new ones ... >=20 >=20 Yes, we are on the same page. > Slides from 2010 I think ..? >=20 > = http://www.psg.com/~charliep/txt/ietf81/alt_mext/Evolving-The-SAS-Rules-fo= r > -Mobility-Awareness-2.pdf >=20 >=20 > Good to see this. Hope we make progress on these base work such as = prefix > coloring =8Awhich are the enablers .. >=20 > http://www.ietf.org/id/draft-korhonen-6man-prefix-properties-01.txt > http://datatracker.ietf.org/doc/draft-bhandari-dhc-class-based-prefix/ >=20 >=20 > Your proposal can leverage the above work. >=20 >=20 Our work and the above work are different parts of the same puzzle. = Above work describes how the different types of IP addresses can be = configured on the nodes, and our work describes how the applications = running on the nodes can pick among those IP addresses.=20 =20 Cheers, Alper >=20 > Regards > Sri >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On 7/8/13 8:30 AM, "Alper Yegin" wrote: >=20 >> Hello dear DMM folks, >>=20 >> We published the following two new drafts which relate to the DMM WG. >>=20 >> http://www.ietf.org/id/draft-yegin-dmm-cnet-homing-00.txt >>=20 >> http://www.ietf.org/id/draft-yegin-dmm-ondemand-mobility-00.txt >>=20 >> We'd appreciate if you can read and share your comments. >>=20 >> (Related IPR statements will be posted on the IETF site soon) >>=20 >> Cheers, >>=20 >> Alper >>=20 >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >=20 From danny.moses@intel.com Tue Jul 16 06:39:26 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A84B121F84AF for ; Tue, 16 Jul 2013 06:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Re5JL7YVs259 for ; Tue, 16 Jul 2013 06:39:22 -0700 (PDT) Received: from mga03.intel.com (mga03.intel.com [143.182.124.21]) by ietfa.amsl.com (Postfix) with ESMTP id 42D7221F9A4B for ; Tue, 16 Jul 2013 06:39:22 -0700 (PDT) Received: from azsmga002.ch.intel.com ([10.2.17.35]) by azsmga101.ch.intel.com with ESMTP; 16 Jul 2013 06:39:20 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.89,677,1367996400"; d="scan'208";a="268985453" Received: from fmsmsx104.amr.corp.intel.com ([10.19.9.35]) by AZSMGA002.ch.intel.com with ESMTP; 16 Jul 2013 06:39:20 -0700 Received: from hasmsx104.ger.corp.intel.com (10.184.198.13) by FMSMSX104.amr.corp.intel.com (10.19.9.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 16 Jul 2013 06:39:20 -0700 Received: from hasmsx106.ger.corp.intel.com ([169.254.2.62]) by HASMSX104.ger.corp.intel.com ([169.254.4.177]) with mapi id 14.03.0123.003; Tue, 16 Jul 2013 16:39:17 +0300 From: "Moses, Danny" To: Alper Yegin , Sri Gundavelli Thread-Topic: [DMM] Two new drafts Thread-Index: AQHOe/BXwyTG+pcEkku7M+ylJERhv5lbnoSAgAtWcICAAGP+UA== Date: Tue, 16 Jul 2013 13:39:17 +0000 Message-ID: References: <24C0F3E22276D9438D6F366EB89FAEA8103223DB@xmb-rcd-x03.cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.184.70.12] Content-Type: text/plain; charset="iso-8859-2" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Cc: "dmm@ietf.org" Subject: Re: [DMM] Two new drafts X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 13:39:26 -0000 Hi Alper, Yes, we also were thinking in the same terms of enabling applications to se= lect the appropriate IP address type to handle the use-case of a mobile nod= e invoking applications that require long flows (hence requiring IP session= continuity) and short flows (hence using the closest mobility anchor for I= P address allocation). See scenario number 6 in section 4.2 of draft-aliahm= ed-dmm-anchor-selection. In that scenario, there are cases where a mobility anchor that is not the t= opologically closest to the base-station might be the best candidate to be = the service anchor for applications that require IP session continuity, but= is not optimal for applications that do not require it (or actually even w= orse). Using different IP addresses (provided by different mobility anchors= ) resolve this conflict. Let's discuss it further in Berlin. Regards, /Danny -----Original Message----- From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of Alper= Yegin Sent: Tuesday, July 16, 2013 13:31 To: Sri Gundavelli Cc: dmm@ietf.org Subject: Re: [DMM] Two new drafts Hi Sri, On Jul 9, 2013, at 8:22 AM, Sri Gundavelli (sgundave) wrote: > Hi Alper, > = > Thanks for sharing the documents. > = Thank you for the feedback. > I did a quick review of the dmm-ondemand draft. This is inline with my = > thinking as well. IMO, the following base semantics will allow us to = > realize some of the DMM deployment models. > = > - Prefix Coloring/ Coloring of IP addresses based on the properties > = > - Delivering the properties as meta-data in address assignment = > procedures (ND, DHCP ..) > - Evolving the source address selection Rules, allowing application to = > pick source address based on the requirements > = > With these semantics, a UE can obtain multiple IP addresses with = > different properties, bind applications to those addresses based on = > the application requirements, roam within the network loosing some = > local addresses and generating some new ones ... > = > = Yes, we are on the same page. > Slides from 2010 I think ..? > = > http://www.psg.com/~charliep/txt/ietf81/alt_mext/Evolving-The-SAS-Rule > s-for > -Mobility-Awareness-2.pdf > = > = > Good to see this. Hope we make progress on these base work such as = > prefix coloring =A9which are the enablers .. > = > http://www.ietf.org/id/draft-korhonen-6man-prefix-properties-01.txt > http://datatracker.ietf.org/doc/draft-bhandari-dhc-class-based-prefix/ > = > = > Your proposal can leverage the above work. > = > = Our work and the above work are different parts of the same puzzle. Above w= ork describes how the different types of IP addresses can be configured on = the nodes, and our work describes how the applications running on the nodes= can pick among those IP addresses. = = Cheers, Alper > = > Regards > Sri > = > = > = > = > = > = > = > On 7/8/13 8:30 AM, "Alper Yegin" wrote: > = >> Hello dear DMM folks, >> = >> We published the following two new drafts which relate to the DMM WG. >> = >> http://www.ietf.org/id/draft-yegin-dmm-cnet-homing-00.txt >> = >> http://www.ietf.org/id/draft-yegin-dmm-ondemand-mobility-00.txt >> = >> We'd appreciate if you can read and share your comments. >> = >> (Related IPR statements will be posted on the IETF site soon) >> = >> Cheers, >> = >> Alper >> = >> = >> _______________________________________________ >> 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 --------------------------------------------------------------------- A member of the Intel Corporation group of companies This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. From Peter.McCann@huawei.com Tue Jul 16 07:28:44 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38E8D21F9CB1 for ; Tue, 16 Jul 2013 07:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8qP08VhSCcWJ for ; Tue, 16 Jul 2013 07:28:38 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id ACCDA21F9D17 for ; Tue, 16 Jul 2013 07:28:04 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATM50504; Tue, 16 Jul 2013 14:27:51 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 16 Jul 2013 15:26:49 +0100 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 16 Jul 2013 15:27:24 +0100 Received: from dfweml512-mbx.china.huawei.com ([169.254.1.163]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.007; Tue, 16 Jul 2013 07:27:17 -0700 From: Peter McCann To: Satoru Matsushima Thread-Topic: [DMM] Fwd: New Version Notification for draft-matsushima-stateless-uplane-vepc-00.txt Thread-Index: AQHOgfW26nXicJERUkyx1u+nahA+K5lnXOCQ Date: Tue, 16 Jul 2013 14:27:16 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE716F4F609@dfweml512-mbx.china.huawei.com> References: <20130710160944.11064.6824.idtracker@ietfa.amsl.com> <724A5F78-33A4-4608-82B9-231DC2AAE2F6@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716F4F1E8@dfweml512-mbx.china.huawei.com> <504A19F8-3C16-4821-86A5-3C3BCA96FE78@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716F4F44C@dfweml512-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.179] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dmm@ietf.org" Subject: Re: [DMM] Fwd: New Version Notification for draft-matsushima-stateless-uplane-vepc-00.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 14:28:44 -0000 Satoru Matsushima wrote: > Hi Peter, >=20 > On 2013/07/16, at 3:49, Peter McCann wrote: >> I guess I don't understand the "PDN Prefix" and "subnet ID" fields >> that you have in Figure 4. You state: >>=20 >> Each PDN is assumed to have single or several prefixes (called PDN >> prefix) used to generate UE's address. Followed by the PDN prefix in >> Figure 4, there is 16-bit TEID assigned for a UE's session at SGW on >> the control plane. TEID is 16 bits identifier in GTP header to >> distinguish each bearer. The remaining bits are filled by subnet ID. >> The prefix is allocated per UE and used for address assignment by >> SLAAC or DHCPv6. >> Is Figure 4 supposed to be the Next Hop or the Destination? I assumed >> it was Next Hop because it has the TEID encoded in it. However, some >> of the above paragraph leads me to believe it is about the UE's user >> plane IP address. >>=20 >=20 > The figure 4 illustrates UE's prefix so it shows the destination. > Encoding TEID is just a seed to create UE's prefix in the stateless-pd > manner. Doesn't the TEID change on every eNB handover? I thought the UE's prefix should remain constant across handovers. > We hasn't illustrate yet how to encode the TEID in next-hop. > But as we mentioned in the document, we expect BGP remote next-hop as > the way to encode it in the sub-TLV of the remote next-hop attribute. I would think that the Next-Hop would change on mobility events, but the Destination would remain the same (UE prefix). Why is this not the case? > cheers, > --satoru >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From bruno.mongazon-cazavet@alcatel-lucent.com Tue Jul 16 08:10:37 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0006B21F9C78 for ; Tue, 16 Jul 2013 08:10:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KMmb0lJtX-cV for ; Tue, 16 Jul 2013 08:10:31 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 7966111E80E9 for ; Tue, 16 Jul 2013 08:10:31 -0700 (PDT) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id r6GFASBh018884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 16 Jul 2013 10:10:30 -0500 (CDT) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id r6GFARTH028409 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 16 Jul 2013 17:10:28 +0200 Received: from [172.27.204.25] (135.239.27.40) by FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) with Microsoft SMTP Server (TLS) id 14.2.247.3; Tue, 16 Jul 2013 17:10:28 +0200 Message-ID: <51E56263.9030302@alcatel-lucent.com> Date: Tue, 16 Jul 2013 17:10:27 +0200 From: Bruno Mongazon-Cazavet User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: References: <20130710160944.11064.6824.idtracker@ietfa.amsl.com> <724A5F78-33A4-4608-82B9-231DC2AAE2F6@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716F4F1E8@dfweml512-mbx.china.huawei.com> <504A19F8-3C16-4821-86A5-3C3BCA96FE78@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716F4F44C@dfweml512-mbx.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE716F4F609@dfweml512-mbx.china.huawei.com> In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716F4F609@dfweml512-mbx.china.huawei.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 8bit X-Originating-IP: [135.239.27.40] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: Re: [DMM] Fwd: New Version Notification for draft-matsushima-stateless-uplane-vepc-00.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 15:10:37 -0000 Le 16/07/2013 16:27, Peter McCann a écrit : > Satoru Matsushima wrote: >> Hi Peter, >> >> On 2013/07/16, at 3:49, Peter McCann wrote: >>> I guess I don't understand the "PDN Prefix" and "subnet ID" fields >>> that you have in Figure 4. You state: >>> >>> Each PDN is assumed to have single or several prefixes (called PDN >>> prefix) used to generate UE's address. Followed by the PDN prefix in >>> Figure 4, there is 16-bit TEID assigned for a UE's session at SGW on >>> the control plane. TEID is 16 bits identifier in GTP header to >>> distinguish each bearer. The remaining bits are filled by subnet ID. >>> The prefix is allocated per UE and used for address assignment by >>> SLAAC or DHCPv6. >>> Is Figure 4 supposed to be the Next Hop or the Destination? I assumed >>> it was Next Hop because it has the TEID encoded in it. However, some >>> of the above paragraph leads me to believe it is about the UE's user >>> plane IP address. >>> >> The figure 4 illustrates UE's prefix so it shows the destination. >> Encoding TEID is just a seed to create UE's prefix in the stateless-pd >> manner. > Doesn't the TEID change on every eNB handover? I thought the UE's prefix > should remain constant across handovers. Yes TEID changes on handover and when UE exits Idle-Mode (it has previously entered). > >> We hasn't illustrate yet how to encode the TEID in next-hop. >> But as we mentioned in the document, we expect BGP remote next-hop as >> the way to encode it in the sub-TLV of the remote next-hop attribute. > I would think that the Next-Hop would change on mobility events, but the > Destination would remain the same (UE prefix). Why is this not the case? > > >> cheers, >> --satoru >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm > > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > From satoru.matsushima@gmail.com Tue Jul 16 09:09:58 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D26821F9ED8 for ; Tue, 16 Jul 2013 09:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BBUcogAuGHhd for ; Tue, 16 Jul 2013 09:09:56 -0700 (PDT) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 3BCE021F9EA3 for ; Tue, 16 Jul 2013 09:09:56 -0700 (PDT) Received: by mail-la0-f51.google.com with SMTP id fq12so677544lab.24 for ; Tue, 16 Jul 2013 09:09:55 -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=YQpz88o4r5IJvdx1SrCMkPh+2hSbke7BZAsxmBQvwRs=; b=JYb1awezK8BjoIv9SHcgQUZPLvWKmOLSHKCFnyYvTcWGeCcA1PKJNl1j17NoKRcisg rscKB2T70P2A4P97bSpeJteSKXUuc6fW7hzFVzNC2teZ2BXgf1/jZBvUdF3vM9iCexL3 hXw1Q5SxLvmXweEaMRIuRvWCSa72wmPVnLHrn34Vttvx7kFq/x6lFxhGnNCdeK/5JTf1 5uUJTEIwLXYT+LNtCSBxotiZuyI/hy/YxXLLNoEzKnbHqfSlQ9glbYQgRkMfISOBUorg YVZIBwkEetx1WakjRh7Bnphs00YXEJNilo2WEGnyOlMow7utTUQpUN6FfcWwHax2hibH U41w== MIME-Version: 1.0 X-Received: by 10.112.211.167 with SMTP id nd7mr1407720lbc.59.1373990995059; Tue, 16 Jul 2013 09:09:55 -0700 (PDT) Received: by 10.112.167.169 with HTTP; Tue, 16 Jul 2013 09:09:54 -0700 (PDT) In-Reply-To: <51E56263.9030302@alcatel-lucent.com> References: <20130710160944.11064.6824.idtracker@ietfa.amsl.com> <724A5F78-33A4-4608-82B9-231DC2AAE2F6@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716F4F1E8@dfweml512-mbx.china.huawei.com> <504A19F8-3C16-4821-86A5-3C3BCA96FE78@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716F4F44C@dfweml512-mbx.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE716F4F609@dfweml512-mbx.china.huawei.com> <51E56263.9030302@alcatel-lucent.com> Date: Wed, 17 Jul 2013 01:09:54 +0900 Message-ID: From: Satoru Matsushima To: Bruno Mongazon-Cazavet Content-Type: multipart/alternative; boundary=001a11c3d7142f697d04e1a3357a Cc: dmm Subject: Re: [DMM] Fwd: New Version Notification for draft-matsushima-stateless-uplane-vepc-00.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jul 2013 16:09:58 -0000 --001a11c3d7142f697d04e1a3357a Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jul 17, 2013 at 12:10 AM, Bruno Mongazon-Cazavet < bruno.mongazon-cazavet@alcatel-lucent.com> wrote: > Le 16/07/2013 16:27, Peter McCann a =E9crit : > > Satoru Matsushima wrote: >> >>> Hi Peter, >>> >>> On 2013/07/16, at 3:49, Peter McCann wrote: >>> >>>> I guess I don't understand the "PDN Prefix" and "subnet ID" fields >>>> that you have in Figure 4. You state: >>>> >>>> Each PDN is assumed to have single or several prefixes (called PDN >>>> prefix) used to generate UE's address. Followed by the PDN prefix = in >>>> Figure 4, there is 16-bit TEID assigned for a UE's session at SGW o= n >>>> the control plane. TEID is 16 bits identifier in GTP header to >>>> distinguish each bearer. The remaining bits are filled by subnet I= D. >>>> The prefix is allocated per UE and used for address assignment by >>>> SLAAC or DHCPv6. >>>> Is Figure 4 supposed to be the Next Hop or the Destination? I assumed >>>> it was Next Hop because it has the TEID encoded in it. However, some >>>> of the above paragraph leads me to believe it is about the UE's user >>>> plane IP address. >>>> >>>> The figure 4 illustrates UE's prefix so it shows the destination. >>> Encoding TEID is just a seed to create UE's prefix in the stateless-pd >>> manner. >>> >> Doesn't the TEID change on every eNB handover? I thought the UE's prefi= x >> should remain constant across handovers. >> > > If you use stateless-pd rule for UE's prefix generation, the embedded TEID is SGW assigned one. So the delegated prefix is stable during across eNB handover. Please see the section 3.3 in update version of the draft. Anycast routing no longer requires hand-over between SGW in virtualized EPC= . > Yes TEID changes on handover and when UE exits Idle-Mode (it has > previously entered). Thanks, we haven't mention about in the case of Idle-Mode exit. will update with it in a next version. It would be in control-plane awareness section. > > >> We hasn't illustrate yet how to encode the TEID in next-hop. >>> But as we mentioned in the document, we expect BGP remote next-hop as >>> the way to encode it in the sub-TLV of the remote next-hop attribute. >>> >> I would think that the Next-Hop would change on mobility events, but the >> Destination would remain the same (UE prefix). Why is this not the case= ? >> > Yes, exactly. cheers, --satoru --001a11c3d7142f697d04e1a3357a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
On W= ed, Jul 17, 2013 at 12:10 AM, Bruno Mongazon-Cazavet <= bruno.mongazon-cazavet@alcatel-lucent.com> wrote:
Le 16/07/2013 16:27, Peter McCann a =E9crit :

Satoru Matsushima wrote:
Hi Peter,

On 2013/07/16, at 3:49, Peter McCann <Peter.McCann@huawei.com> wrote:
I guess I don't understand the "PDN Prefix" and "subnet = ID" fields
that you have in Figure 4. =A0You state:

=A0 =A0Each PDN is assumed to have single or several prefixes (called PDN =A0 =A0prefix) used to generate UE's address. =A0Followed by the PDN pr= efix in
=A0 =A0Figure 4, there is 16-bit TEID assigned for a UE's session at SG= W on
=A0 =A0the control plane. =A0TEID is 16 bits identifier in GTP header to =A0 =A0distinguish each bearer. =A0The remaining bits are filled by subnet = ID.
=A0 =A0The prefix is allocated per UE and used for address assignment by =A0 =A0SLAAC or DHCPv6.
Is Figure 4 supposed to be the Next Hop or the Destination? =A0I assumed it was Next Hop because it has the TEID encoded in it. =A0However, some
of the above paragraph leads me to believe it is about the UE's user plane IP address.

The figure 4 illustrates UE's prefix so it shows the destination.
Encoding TEID is just a seed to create UE's prefix in the stateless-pd<= br> manner.
Doesn't the TEID change on every eNB handover? =A0I thought the UE'= s prefix
should remain constant across handovers.


If you use stateless-pd rule for= UE's prefix generation, the embedded TEID is SGW assigned one. So the = delegated prefix is stable during across eNB handover. Please see the secti= on 3.3 in update version of the draft. Anycast routing no longer requires h= and-over between SGW in virtualized EPC.

=A0=A0
Yes TEID changes on handover and when UE exits Idle-Mode (it has previously= entered).

Thanks, we haven't men= tion about in the case of Idle-Mode exit. will update with it in a next ver= sion. It would be in control-plane awareness section.


=



We hasn't illustrate yet how to encode the TEID in next-hop.
But as we mentioned in the document, we expect BGP remote next-hop as
the way to encode it in the sub-TLV of the remote next-hop attribute.
I would think that the Next-Hop would change on mobility events, but the Destination would remain the same (UE prefix). =A0Why is this not the case?=

Yes, ex= actly.=A0

cheers,
--sa= toru

--001a11c3d7142f697d04e1a3357a-- From jouni.nospam@gmail.com Wed Jul 17 01:42:22 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75D1521F9A43 for ; Wed, 17 Jul 2013 01:42:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WZCkPBcnKJUU for ; Wed, 17 Jul 2013 01:42:22 -0700 (PDT) Received: from mail-bk0-x233.google.com (mail-bk0-x233.google.com [IPv6:2a00:1450:4008:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id 96B1021F9A2E for ; Wed, 17 Jul 2013 01:42:21 -0700 (PDT) Received: by mail-bk0-f51.google.com with SMTP id ji1so622805bkc.10 for ; Wed, 17 Jul 2013 01:42:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version:x-mailer; bh=ec3q1p0HTZrW2mcqw5pNRo1nu07TVCMbOeaVDuQj6wM=; b=mWUkoyKxrPBNt9VlRfa5RqoMjeibyW8B+jdEAFQnq60U4aAc67jkKNQxFzCnvUlfmC Q9YZquSGnoIUtgZPYYfTLzSL71f+BcUbKoo2xWFnrgrx2IH3t1LrAM0e0ZdxMyUTfIzD QHDPZtXY78r3KfnfqMEC9szDjsDoqseXDdpKt2zD+NQCsfMFY/BJz0oMXQ+zP3o1wijY z2Jm74P9+GxOGFLmUyVphkFH1oL9m3qIQgi8A4Dpx/MiCAw701mQSeFDkC8FxpLkMHRA iVt9JyaAjTrjKS1ER3w3ihmvR2TvNhV+G5bXEUc1rwYFBed8nxAy/W2ixgmvXqHINrIh EfrQ== X-Received: by 10.204.183.16 with SMTP id ce16mr826041bkb.172.1374050539482; Wed, 17 Jul 2013 01:42:19 -0700 (PDT) Received: from host-109-204-179-26.tp-fne.tampereenpuhelin.net (host-109-204-179-26.tp-fne.tampereenpuhelin.net. [109.204.179.26]) by mx.google.com with ESMTPSA id if11sm1593234bkc.15.2013.07.17.01.42.18 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 17 Jul 2013 01:42:19 -0700 (PDT) From: Jouni Korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <5E593887-9FD9-452D-AB07-08D2A36F47C8@gmail.com> Date: Wed, 17 Jul 2013 11:42:17 +0300 To: "dmm@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [DMM] draft agenda update.. X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 08:42:22 -0000 The latest revision is available here: http://www.ietf.org/proceedings/87/agenda/agenda-87-dmm Note that all the available time is used up now, which means we also use 10 min break time for stimulating presentations and powerpoint exercise. - Jouni & Julien From Marco.Liebsch@neclab.eu Wed Jul 17 03:19:45 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9524221F9A1B for ; Wed, 17 Jul 2013 03:19:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORbj6crmzrGf for ; Wed, 17 Jul 2013 03:19:41 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 2E4B821F9A51 for ; Wed, 17 Jul 2013 03:19:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 75618104B98; Wed, 17 Jul 2013 12:19:03 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vFtmdxR5QOJ6; Wed, 17 Jul 2013 12:19:03 +0200 (CEST) Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) by mailer1.neclab.eu (Postfix) with ESMTP id 5B1C3104B97; Wed, 17 Jul 2013 12:18:53 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.153]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.01.0323.003; Wed, 17 Jul 2013 12:18:20 +0200 From: Marco Liebsch To: Liu Dapeng , dmm Thread-Topic: [DMM] I-D Action: draft-liu-sdn-mobility-00.txt Thread-Index: AQHOfgUyLSLtOTr4PECAlGmHl5h4MplosBqg Date: Wed, 17 Jul 2013 10:18:20 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D553095B4@DAPHNIS.office.hd> References: In-Reply-To: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [DMM] I-D Action: draft-liu-sdn-mobility-00.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 10:19:45 -0000 Hi Dapeng, even though the draft is not specific to the DMM problem space, I agree wit= h taking SDN into account to tackle some issues in DMM. Mainly I see SDN as technolo= gy to support indirection of user traffic after anchor relocation to enable IP address continuity. This allows more optimal paths to the mobile's curre= nt mobility anchor. Which parts of such solution can be handled in the IETF is a different stor= y, but I think that even IETF-based solutions should consider inter-working with SDN to enable optimized solutions. That's one message of our DMM frame= work draft. Thanks for posting the draft. Best regards, marco >-----Original Message----- >From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of Liu >Dapeng >Sent: Donnerstag, 11. Juli 2013 09:06 >To: dmm >Subject: [DMM] I-D Action: draft-liu-sdn-mobility-00.txt > >Hi all, > >We submit a SDN mobility draft. The purpose is to trigger discussions on = the >topic of SDN mobility. Your comments are appreciated. > >Thanks, >Dapeng Liu >________________________________ > >A New Internet-Draft is available from the on-line Internet-Drafts directo= ries. > > >Title : Mobility Support in Software Defined Networking >Author(s) : Dapeng Liu > Hui Deng >Filename : draft-liu-sdn-mobility-00.txt >Pages : 6 >Date : 2013-07-08 > >Abstract: > This document discusses the SDN mobility problem and potential > solutions. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-liu-sdn-mobility > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-liu-sdn-mobility-00 > > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > > >-- > >------ >Best Regards, >Dapeng Liu >_______________________________________________ >dmm mailing list >dmm@ietf.org >https://www.ietf.org/mailman/listinfo/dmm From pthubert@cisco.com Wed Jul 17 03:45:23 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CB4F21F995B for ; Wed, 17 Jul 2013 03:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.543 X-Spam-Level: X-Spam-Status: No, score=-10.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cGEMee8T87kD for ; Wed, 17 Jul 2013 03:45:18 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 6628421F965B for ; Wed, 17 Jul 2013 03:45:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2586; q=dns/txt; s=iport; t=1374057914; x=1375267514; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=SVRL8caVJHEolHirMV+RLXE/GIDt2XSurjUDoIFUCeY=; b=PCyBImSU6hqW/zE2Vip41Qrgo4q7GZEfhI440AtZEWPUENsjdAR9cqwP st1X0VOEVbq7zkkac/WFbsl/fBz0gTqPr/wZcV2IYKlsVNw6+acCU450P +DqR/p5w0AEusx0EO2l/7xyjFTz0L088tNv9wqRM4AlDRHypxjBb7MvPt o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgkFAIh05lGtJV2b/2dsb2JhbABagwY0T8JLgQ8WdIIjAQEBBAEBATc0FwQCAQgRBAEBCwsJCQcnCxQJCAIEARIIE4d1DLVJjz04BgSDAm4DmQWQJIMSgig X-IronPort-AV: E=Sophos;i="4.89,683,1367971200"; d="scan'208";a="235891552" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-3.cisco.com with ESMTP; 17 Jul 2013 10:45:14 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r6HAjDqg005576 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Jul 2013 10:45:13 GMT Received: from xmb-rcd-x01.cisco.com ([169.254.1.35]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.02.0318.004; Wed, 17 Jul 2013 05:45:13 -0500 From: "Pascal Thubert (pthubert)" To: Marco Liebsch , Liu Dapeng , dmm Thread-Topic: [DMM] I-D Action: draft-liu-sdn-mobility-00.txt Thread-Index: AQHOfgUyLSLtOTr4PECAlGmHl5h4MplosBqggAAIeCA= Date: Wed, 17 Jul 2013 10:45:12 +0000 Deferred-Delivery: Wed, 17 Jul 2013 10:44:00 +0000 Message-ID: References: <69756203DDDDE64E987BC4F70B71A26D553095B4@DAPHNIS.office.hd> In-Reply-To: <69756203DDDDE64E987BC4F70B71A26D553095B4@DAPHNIS.office.hd> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.163.156] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [DMM] I-D Action: draft-liu-sdn-mobility-00.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 10:45:23 -0000 Hello Dapeng, I hipe you're doing good these days; I like the concept, I'm a bit more confused with the addition of SDN vs. fo= r instance PCE? Cheers, Pascal -----Original Message----- From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of Marco= Liebsch Sent: mercredi 17 juillet 2013 12:18 To: Liu Dapeng; dmm Subject: Re: [DMM] I-D Action: draft-liu-sdn-mobility-00.txt Hi Dapeng, even though the draft is not specific to the DMM problem space, I agree wit= h taking SDN into account to tackle some issues in DMM. Mainly I see SDN as= technology to support indirection of user traffic after anchor relocation = to enable IP address continuity. This allows more optimal paths to the mobi= le's current mobility anchor. Which parts of such solution can be handled in the IETF is a different stor= y, but I think that even IETF-based solutions should consider inter-working= with SDN to enable optimized solutions. That's one message of our DMM fram= ework draft. Thanks for posting the draft. Best regards, marco >-----Original Message----- >From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of=20 >Liu Dapeng >Sent: Donnerstag, 11. Juli 2013 09:06 >To: dmm >Subject: [DMM] I-D Action: draft-liu-sdn-mobility-00.txt > >Hi all, > >We submit a SDN mobility draft. The purpose is to trigger discussions=20 >on the topic of SDN mobility. Your comments are appreciated. > >Thanks, >Dapeng Liu >________________________________ > >A New Internet-Draft is available from the on-line Internet-Drafts directo= ries. > > >Title : Mobility Support in Software Defined Networking >Author(s) : Dapeng Liu > Hui Deng >Filename : draft-liu-sdn-mobility-00.txt >Pages : 6 >Date : 2013-07-08 > >Abstract: > This document discusses the SDN mobility problem and potential > solutions. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-liu-sdn-mobility > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-liu-sdn-mobility-00 > > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > > >-- > >------ >Best Regards, >Dapeng Liu >_______________________________________________ >dmm mailing list >dmm@ietf.org >https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm From pierrick.seite@orange.com Wed Jul 17 04:46:56 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B99A21F9E6E for ; Wed, 17 Jul 2013 04:46:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RnAMtt7qs2az for ; Wed, 17 Jul 2013 04:46:52 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 23B7021F9D4A for ; Wed, 17 Jul 2013 04:46:51 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 2555118C7D3; Wed, 17 Jul 2013 13:46:50 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 0A2A04C056; Wed, 17 Jul 2013 13:46:50 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Wed, 17 Jul 2013 13:46:49 +0200 From: To: Marco Liebsch , Liu Dapeng , dmm Thread-Topic: [DMM] I-D Action: draft-liu-sdn-mobility-00.txt Thread-Index: AQHOfgUyLSLtOTr4PECAlGmHl5h4MplosBqggAAYtgA= Date: Wed, 17 Jul 2013 11:46:49 +0000 Message-ID: <13953_1374061610_51E6842A_13953_2783_1_81C77F07008CA24F9783A98CFD706F7110F769@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <69756203DDDDE64E987BC4F70B71A26D553095B4@DAPHNIS.office.hd> In-Reply-To: <69756203DDDDE64E987BC4F70B71A26D553095B4@DAPHNIS.office.hd> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.7.17.85416 Subject: Re: [DMM] I-D Action: draft-liu-sdn-mobility-00.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 11:46:56 -0000 Hi, I agree with Marco. Besides, I think that SDN could be used to provide sepa= ration between data and control planes of mobility protocols. It applies t= o DMM, but not only. BR, Pierrick -----Message d'origine----- De=A0: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] De la part de Mar= co Liebsch Envoy=E9=A0: mercredi 17 juillet 2013 12:18 =C0=A0: Liu Dapeng; dmm Objet=A0: Re: [DMM] I-D Action: draft-liu-sdn-mobility-00.txt Hi Dapeng, even though the draft is not specific to the DMM problem space, I agree wit= h taking SDN into account to tackle some issues in DMM. Mainly I see SDN as= technology to support indirection of user traffic after anchor relocation = to enable IP address continuity. This allows more optimal paths to the mobi= le's current mobility anchor. Which parts of such solution can be handled in the IETF is a different stor= y, but I think that even IETF-based solutions should consider inter-working= with SDN to enable optimized solutions. That's one message of our DMM fram= ework draft. Thanks for posting the draft. Best regards, marco >-----Original Message----- >From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of=20 >Liu Dapeng >Sent: Donnerstag, 11. Juli 2013 09:06 >To: dmm >Subject: [DMM] I-D Action: draft-liu-sdn-mobility-00.txt > >Hi all, > >We submit a SDN mobility draft. The purpose is to trigger discussions=20 >on the topic of SDN mobility. Your comments are appreciated. > >Thanks, >Dapeng Liu >________________________________ > >A New Internet-Draft is available from the on-line Internet-Drafts directo= ries. > > >Title : Mobility Support in Software Defined Networking >Author(s) : Dapeng Liu > Hui Deng >Filename : draft-liu-sdn-mobility-00.txt >Pages : 6 >Date : 2013-07-08 > >Abstract: > This document discusses the SDN mobility problem and potential > solutions. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-liu-sdn-mobility > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-liu-sdn-mobility-00 > > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > > >-- > >------ >Best Regards, >Dapeng Liu >_______________________________________________ >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 ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From alper.yegin@yegin.org Wed Jul 17 07:48:35 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C63BE21F99DA for ; Wed, 17 Jul 2013 07:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.516 X-Spam-Level: X-Spam-Status: No, score=-102.516 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9AfAN8mq3e5b for ; Wed, 17 Jul 2013 07:48:31 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id B087721F9E47 for ; Wed, 17 Jul 2013 07:48:29 -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 0M7ZVP-1UBdcj2Ku7-00xJaA; Wed, 17 Jul 2013 10:48:25 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_0DA7307B-2D05-4737-9C8B-F0C26EC29C8B" From: Alper Yegin In-Reply-To: Date: Wed, 17 Jul 2013 17:48:21 +0300 Message-Id: <28407EEF-BFB9-47A2-A562-DCEF8BCDC1CF@yegin.org> References: To: Liu Dapeng X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:6/eCZwRvFMBI6xP+ub1PLZtcgYAUvrH7yntYbxriCCD szQN1UQlLRxnQSDK2/6Ck6NIrV3RcT281IuNMtnrJQe/uilF4u rrsC/FLuKSfb3SwLGPvowk6lHoRo9gRbuhRHk9P8k3W1TQUd3d w+GM1v+/WNPoTWkoP0OZmKSi1g4qFYv8I6NpKocewCtZBtN44H QUEVurUO8fPsc3VyX/RTmdxyGmnrDq5rYVR1dbwYawKtl9hdtd RG4qp1u9H1X4uVYMHZo2uEJ6rIE75gdd6vAAdnamhuiisRH/hh Qh0RvL8cjQQGv8DJeK3ZNwsvV+VAihqUf03bk4ap49x8F8yFIN cw6agqSY4hnuGoM+dSt57gN646eCn4eOHxp57SI6FLl0cOKPkE UBPj4kOA2psIg== Cc: dmm Subject: Re: [DMM] FW: New Version Notification for draft-ietf-dmm-best-practices-gap-analysis-01.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 14:48:35 -0000 --Apple-Mail=_0DA7307B-2D05-4737-9C8B-F0C26EC29C8B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello Dapeng, Here are me few comments: It is typically the role of a connection manager to distinguish application capabilities and trigger the mobility support accordingly. =20 and Multiple IP address management: ability of the mobile node to simultaneously use multiple IP addresses and select the best one (from an anchoring point of view) to use on a per-session/ application/service basis. Depending on the mobile node support, this functionality might require more or less support from the network side. This is typically the role of a connection manager. I'm not sure if this is really a connection manager issue. This is more = of a source address selection issue. Mobility management and traffic redirection should only be triggered due to IP mobility reasons, that is when the MN moves from the point of attachment where the IP flow was originally initiated. Mobility management and traffic redirection may also be triggered due to = load balancing. Maybe we should acknowledge such non-mobility related = triggers, and state that they are outside the scope of this document. Should we described the terms IP session continuity and IP address = reachability? This document is solely focusing on the former, we should = state that. When doing the gap analysis, we better break down the benefits we are = seeking and evaluate existing solutions with respect to them (e.g., = signaling reduction, use of most direct data-path, etc. ). For example, = regular use of HMIP helps with the former, but not the latter. But, = using RCoA as source address helps with both (but it has other issues -- = when MN moves outside the local domain). Alper On Jun 27, 2013, at 1:48 PM, Liu Dapeng wrote: > Hello folks: >=20 > To make good progress in Berlin meeting, it is better for us to start > discussion and resolve comments in the list now. Please help to review > and feel free to send comments. >=20 > quick summary of the draft: > ----- > Section 4 'DMM practice' mainly analyses the mobility deployment > practice in WLAN and 3GPP network. Both client-based and network-based > mobility protocols are discussed. >=20 > Section 5 'Gap analysis' tentatively discusses the gaps. Please have a > look whether you agree on those gaps and whether you want to propose > any new ones. Any input from the group will be welcomed. >=20 > Thanks, > Dapeng Liu >=20 > 2013/6/17 Zuniga, Juan Carlos : >> Hi all, >>=20 >> We have posted an updated version of the current practices and gap = analysis draft. We would like to make one more update before Berlin, so = your comments and feedback are very welcome. >>=20 >> Regards, >>=20 >> Juan Carlos et al. >>=20 >> -----Original Message----- >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> Sent: Monday, June 17, 2013 11:07 AM >> To: Carlos J. Bernardos; H Anthony Chan; Zuniga, Juan Carlos; Anthony = Chan; Dapeng Liu; Zuniga, Juan Carlos; Pierrick Seite >> Subject: New Version Notification = fordraft-ietf-dmm-best-practices-gap-analysis-01.txt >>=20 >>=20 >> A new version of I-D, = draft-ietf-dmm-best-practices-gap-analysis-01.txt >> has been successfully submitted by Dapeng Liu and posted to the >> IETF repository. >>=20 >> Filename: draft-ietf-dmm-best-practices-gap-analysis >> Revision: 01 >> Title: Distributed Mobility Management: Current practices = and gap analysis >> Creation date: 2013-06-17 >> Group: dmm >> Number of pages: 21 >> URL: = http://www.ietf.org/internet-drafts/draft-ietf-dmm-best-practices-gap-anal= ysis-01.txt >> Status: = http://datatracker.ietf.org/doc/draft-ietf-dmm-best-practices-gap-analysis= >> Htmlized: = http://tools.ietf.org/html/draft-ietf-dmm-best-practices-gap-analysis-01 >> Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dmm-best-practices-gap-analy= sis-01 >>=20 >> Abstract: >> The present document analyses deplyment practices of existing >> mobility protocols in a distributed mobility management = environment. >> It also identifies some limitations compared to the expected >> functionality of a fully distributed mobility management system. = The >> comparison is made taking into account the identified DMM >> requirements. >>=20 >>=20 >>=20 >>=20 >> The IETF Secretariat >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >=20 >=20 >=20 > --=20 >=20 > ------ > Best Regards, > Dapeng Liu > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm --Apple-Mail=_0DA7307B-2D05-4737-9C8B-F0C26EC29C8B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hello = Dapeng,

Here are me few = comments:

       It is = typically the role of a connection
       manager = to distinguish application capabilities and trigger the

and

      simultaneously use multiple = IP addresses and select the best one
      (from an = anchoring point of view) to use on a per-session/
      this functionality might = require more or less support from the
      network = side.  This is typically the role of a connection = manager.

I'm not sure if this is really a = connection manager issue. This is more of a source address selection = issue.


      =  Mobility management and traffic redirection should only = be
       from the point of = attachment where the IP flow was originally
       = initiated.

Mobility management and traffic = redirection may also be triggered due to load balancing. Maybe we should = acknowledge such non-mobility related triggers, and state that they are = outside the scope of this document.




When doing the gap analysis, = we better break down the benefits we are seeking and evaluate existing = solutions with respect to them (e.g., signaling reduction, use of most = direct data-path, etc. ). For example, regular use of HMIP helps with = the former, but not the latter. But, using RCoA as source address helps = with both (but it has other issues -- when MN moves outside the local = domain).

Alper
















On Jun = 27, 2013, at 1:48 PM, Liu Dapeng wrote:

Hello = folks:

To make good progress in Berlin meeting, it is better for = us to start
discussion and resolve comments in the list now. Please = help to review
and feel free to send comments.

quick summary = of the draft:
-----
Section 4 'DMM practice' mainly analyses the = mobility deployment
practice in WLAN and 3GPP network. Both = client-based and network-based
mobility protocols are = discussed.

Section 5 'Gap analysis' tentatively discusses the = gaps. Please have a
look whether you agree on those gaps and whether = you want to propose
any new ones. Any input from the group will be = welcomed.

Thanks,
Dapeng Liu

2013/6/17 Zuniga, Juan = Carlos <JuanCarlos.Zuniga@inter= digital.com>:
Hi = all,

We have posted = an updated version of the current practices and gap analysis draft. We = would like to make one more update before Berlin, so your comments and = feedback are very welcome.

Regards,

Juan Carlos et = al.

-----Original Message-----
From: internet-drafts@ietf.org = [mailto:internet-drafts@ietf.org]
Sent: Monday, June 17, 2013 11:07 = AM
To: Carlos J. Bernardos; H = Anthony Chan; Zuniga, Juan Carlos; Anthony Chan; Dapeng Liu; Zuniga, = Juan Carlos; Pierrick Seite
Subject: New Version Notification = fordraft-ietf-dmm-best-practices-gap-analysis-01.txt


A new version = of I-D, = draft-ietf-dmm-best-practices-gap-analysis-01.txt
has been successfully submitted by Dapeng Liu and = posted to the
IETF = repository.

Filename: =        draft-ietf-dmm-best-practices-ga= p-analysis
Revision: =        01
Title: =           Distributed = Mobility Management: Current practices and gap = analysis
Creation date: =   2013-06-17
Group: =           dmm
Number of pages: = 21
URL: =             http://www.ietf.org/internet-drafts/draft-ietf-dmm-be= st-practices-gap-analysis-01.txt
Status: =          http://datatracker.ietf.org/doc/draft-ietf-dmm-best-practices-ga= p-analysis
Htmlized: =        http://tools.ietf.org/html/draft-ietf-dmm-best-practices-gap-analy= sis-01
Diff: =            http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dmm-best-pra= ctices-gap-analysis-01

Abstract:
=   The present document analyses deplyment practices of = existing
  mobility = protocols in a distributed mobility management = environment.
  It = also identifies some limitations compared to the = expected
=   functionality of a fully distributed mobility management = system.  The
=   comparison is made taking into account the identified = DMM
=   requirements.




The IETF = Secretariat

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



-- =

------
Best Regards,
Dapeng = Liu
_______________________________________________
dmm mailing = list
dmm@ietf.org
https://www.ietf.org/mail= man/listinfo/dmm

= --Apple-Mail=_0DA7307B-2D05-4737-9C8B-F0C26EC29C8B-- From Peter.McCann@huawei.com Wed Jul 17 10:12:46 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0009421F91CB for ; Wed, 17 Jul 2013 10:12:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kOPof-NJuKIU for ; Wed, 17 Jul 2013 10:12:40 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E3CB421F8FF3 for ; Wed, 17 Jul 2013 10:12:39 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATN58454; Wed, 17 Jul 2013 17:12:38 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 17 Jul 2013 18:11:07 +0100 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 17 Jul 2013 18:11:45 +0100 Received: from dfweml512-mbx.china.huawei.com ([169.254.1.163]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.007; Wed, 17 Jul 2013 10:11:43 -0700 From: Peter McCann To: Satoru Matsushima , Bruno Mongazon-Cazavet Thread-Topic: [DMM] Fwd: New Version Notification for draft-matsushima-stateless-uplane-vepc-00.txt Thread-Index: AQHOgj7y6nXicJERUkyx1u+nahA+K5lpHC7g Date: Wed, 17 Jul 2013 17:11:42 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE716F4F97F@dfweml512-mbx.china.huawei.com> References: <20130710160944.11064.6824.idtracker@ietfa.amsl.com> <724A5F78-33A4-4608-82B9-231DC2AAE2F6@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716F4F1E8@dfweml512-mbx.china.huawei.com> <504A19F8-3C16-4821-86A5-3C3BCA96FE78@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716F4F44C@dfweml512-mbx.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE716F4F609@dfweml512-mbx.china.huawei.com> <51E56263.9030302@alcatel-lucent.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.125.156] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: dmm Subject: Re: [DMM] Fwd: New Version Notification for draft-matsushima-stateless-uplane-vepc-00.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jul 2013 17:12:46 -0000 Hi, Satoru, Satoru Matsushima wrote: > On Wed, Jul 17, 2013 at 12:10 AM, Bruno Mongazon-Cazavet=20 > wrote: >=20 >=20 > Le 16/07/2013 16:27, Peter McCann a =E9crit : >=20 >=20 > Satoru Matsushima wrote: >=20 >=20 > Hi Peter, >=20 > On 2013/07/16, at 3:49, Peter McCann wrote: >=20 >=20 > I guess I don't understand the "PDN Prefix" and "subnet ID" fields > that you have in Figure 4. You state: >=20 > Each PDN is assumed to have single or several prefixes (called > PDN prefix) used to generate UE's address. Followed by the PDN > prefix in Figure 4, there is 16-bit TEID assigned for a UE's > session at SGW on the control plane. TEID is 16 bits identifier > in GTP header to distinguish each bearer. The remaining bits are > filled by subnet ID. The prefix is allocated per UE and used for > address assignment by SLAAC or DHCPv6. Is Figure 4 supposed > to be the Next Hop or the Destination? I assumed it was Next Hop > because it has the TEID encoded in it. However, some of the above > paragraph leads me to believe it is about the UE's user plane IP > address. >=20 >=20 >=20 > The figure 4 illustrates UE's prefix so it shows the destination. > Encoding TEID is just a seed to create UE's prefix in the > stateless-pd manner. >=20 >=20 > Doesn't the TEID change on every eNB handover? I thought the UE's > prefix should remain constant across handovers. >=20 >=20 >=20 >=20 > If you use stateless-pd rule for UE's prefix generation, the embedded=20 > TEID is SGW assigned one. So the delegated prefix is stable during=20 > across eNB handover. Please see the section 3.3 in update version of=20 > the draft. Anycast routing no longer requires hand-over between SGW in=20 > virtualized EPC. >=20 >=20 >=20 > Yes TEID changes on handover and when UE exits Idle-Mode (it has=20 > previously entered). >=20 >=20 > Thanks, we haven't mention about in the case of Idle-Mode exit. will=20 > update with it in a next version. It would be in control-plane=20 > awareness section. I think taken together, these facts would mean that the TEID space is shared across all EPC-E devices (they all have the same anycast address) and also that a TEID would need to remain allocated even to idle UEs. Would you eventually run out of TEID space? > We hasn't illustrate yet how to encode the TEID in next-hop. But > as we mentioned in the document, we expect BGP remote next-hop as the > way to encode it in the sub-TLV of the remote next-hop attribute. >=20 >=20 > I would think that the Next-Hop would change on mobility events, but > the Destination would remain the same (UE prefix). Why is this not > the case? >=20 >=20 >=20 > Yes, exactly. Ok, so the Destination IPv6 address needs to remain the same during the lif= etime of a UE session, even across idle transitions and mobility events, right? -Pete From maxpassion@gmail.com Wed Jul 17 19:32:13 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A538121F99F6 for ; Wed, 17 Jul 2013 19:32:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.468 X-Spam-Level: X-Spam-Status: No, score=-2.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OV-bmFXNRwyP for ; Wed, 17 Jul 2013 19:32:10 -0700 (PDT) Received: from mail-vc0-x229.google.com (mail-vc0-x229.google.com [IPv6:2607:f8b0:400c:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 6C80F21F8C4C for ; Wed, 17 Jul 2013 19:32:10 -0700 (PDT) Received: by mail-vc0-f169.google.com with SMTP id ib11so201833vcb.14 for ; Wed, 17 Jul 2013 19:32:09 -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=zBEkr4PXF6gxWA5q6D5T9PPnPE/K1s6+dPUDtJsfPp0=; b=zzAeEdHByvRHT87b7evFHXIII/kUuWl8NVrRDmlm7LIRyL23xdiQaejcHFEdJ107pF veIBtNdkE7nbpDqHJRKP2eZHz/BxmQYJ7KpRw52c6o0Wrf9LznkkJqiXF4qXRIY6WaUQ WCBUR96conN3HvJfrL3way7WATOjOQWu/JsZNwTK/OpLLoBzaNfyEIvr1maPvQpw8vL8 azjubJSctnV2zzGY3djRWfJeb/czEVrOkGa2O17JN6+UCV1H3bokUeYKGpZ5prCB2JGy 6zVTQ49kmoyQmxPNQN9fHTFhs9aqpLUbzvfdu7GsH6EAZ6t9zRD//+r1aOfscZ6+Gfef ZlDA== MIME-Version: 1.0 X-Received: by 10.52.33.162 with SMTP id s2mr2728458vdi.37.1374114729700; Wed, 17 Jul 2013 19:32:09 -0700 (PDT) Received: by 10.221.65.2 with HTTP; Wed, 17 Jul 2013 19:32:09 -0700 (PDT) In-Reply-To: <28407EEF-BFB9-47A2-A562-DCEF8BCDC1CF@yegin.org> References: <28407EEF-BFB9-47A2-A562-DCEF8BCDC1CF@yegin.org> Date: Thu, 18 Jul 2013 10:32:09 +0800 Message-ID: From: Liu Dapeng To: Alper Yegin Content-Type: multipart/alternative; boundary=20cf307d066a5833dc04e1c00449 Cc: dmm Subject: Re: [DMM] FW: New Version Notification for draft-ietf-dmm-best-practices-gap-analysis-01.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 02:32:13 -0000 --20cf307d066a5833dc04e1c00449 Content-Type: text/plain; charset=ISO-8859-1 Hello Alper, Thanks for the good comments. please see my reply inline: 2013/7/17 Alper Yegin > Hello Dapeng, > > Here are me few comments: > > It is typically the role of a connection > manager to distinguish application capabilities and trigger the > mobility support accordingly. > > and > > Multiple IP address management: ability of the mobile node to > simultaneously use multiple IP addresses and select the best one > (from an anchoring point of view) to use on a per-session/ > application/service basis. Depending on the mobile node support, > this functionality might require more or less support from the > network side. This is typically the role of a connection manager. > > I'm not sure if this is really a connection manager issue. This is more of > a source address selection issue. > > [Dapeng] Yes, application and OS protocol stack can also take the role of choosing source IP address. We will update this statement accordingly. > > Mobility management and traffic redirection should only be > triggered due to IP mobility reasons, that is when the MN moves > from the point of attachment where the IP flow was originally > initiated. > > Mobility management and traffic redirection may also be triggered due to > load balancing. Maybe we should acknowledge such non-mobility related > triggers, and state that they are outside the scope of this document. > [Dapeng] I am not sure whether there is a case that mobility management is triggered due to load balancing. Could you help to give an example? > > > Should we described the terms IP session continuity and IP address > reachability? This document is solely focusing on the former, we should > state that. > > [Dapeng] For "IP address reachability", you mean the case that session is initiated from Internet toward to the MN? I am not sure whether it should be in the scope of mobility management. For example, RFC5555 does not discuss this case. > > When doing the gap analysis, we better break down the benefits we are > seeking and evaluate existing solutions with respect to them (e.g., > signaling reduction, use of most direct data-path, etc. ). For example, > regular use of HMIP helps with the former, but not the latter. But, using > RCoA as source address helps with both (but it has other issues -- when MN > moves outside the local domain). > [Dapeng] We already done that in section 5.2. Do you have more column want to add in table 1? Thanks, Dapeng Liu Alper > > > > > > > > > > > > > > > > > > > > > > On Jun 27, 2013, at 1:48 PM, Liu Dapeng wrote: > > Hello folks: > > To make good progress in Berlin meeting, it is better for us to start > discussion and resolve comments in the list now. Please help to review > and feel free to send comments. > > quick summary of the draft: > ----- > Section 4 'DMM practice' mainly analyses the mobility deployment > practice in WLAN and 3GPP network. Both client-based and network-based > mobility protocols are discussed. > > Section 5 'Gap analysis' tentatively discusses the gaps. Please have a > look whether you agree on those gaps and whether you want to propose > any new ones. Any input from the group will be welcomed. > > Thanks, > Dapeng Liu > > 2013/6/17 Zuniga, Juan Carlos : > > Hi all, > > > We have posted an updated version of the current practices and gap > analysis draft. We would like to make one more update before Berlin, so > your comments and feedback are very welcome. > > > Regards, > > > Juan Carlos et al. > > > -----Original Message----- > > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > > Sent: Monday, June 17, 2013 11:07 AM > > To: Carlos J. Bernardos; H Anthony Chan; Zuniga, Juan Carlos; Anthony > Chan; Dapeng Liu; Zuniga, Juan Carlos; Pierrick Seite > > Subject: New Version Notification > fordraft-ietf-dmm-best-practices-gap-analysis-01.txt > > > > A new version of I-D, draft-ietf-dmm-best-practices-gap-analysis-01.txt > > has been successfully submitted by Dapeng Liu and posted to the > > IETF repository. > > > Filename: draft-ietf-dmm-best-practices-gap-analysis > > Revision: 01 > > Title: Distributed Mobility Management: Current practices and > gap analysis > > Creation date: 2013-06-17 > > Group: dmm > > Number of pages: 21 > > URL: > http://www.ietf.org/internet-drafts/draft-ietf-dmm-best-practices-gap-analysis-01.txt > > Status: > http://datatracker.ietf.org/doc/draft-ietf-dmm-best-practices-gap-analysis > > Htmlized: > http://tools.ietf.org/html/draft-ietf-dmm-best-practices-gap-analysis-01 > > Diff: > http://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-best-practices-gap-analysis-01 > > > Abstract: > > The present document analyses deplyment practices of existing > > mobility protocols in a distributed mobility management environment. > > It also identifies some limitations compared to the expected > > functionality of a fully distributed mobility management system. The > > comparison is made taking into account the identified DMM > > requirements. > > > > > > The IETF Secretariat > > > _______________________________________________ > > dmm mailing list > > dmm@ietf.org > > https://www.ietf.org/mailman/listinfo/dmm > > > > > -- > > ------ > Best Regards, > Dapeng Liu > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > > > -- ------ Best Regards, Dapeng Liu --20cf307d066a5833dc04e1c00449 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Alper,

Thanks for the good = comments. please see my reply inline:

<= br>
2013/7/17 Alper Yegin <<= a href=3D"mailto:alper.yegin@yegin.org" target=3D"_blank">alper.yegin@yegin= .org>
Hello Da= peng,

Here are me few comments:

=A0 =A0 =A0 =A0It is typically the role of a connection
=A0=A0 =A0 =A0 manager to distinguish= application capabilities and trigger the
=A0=A0 =A0 =A0 mobility= support accordingly. =A0

and

=A0 =A0 =A0=A0Multiple IP address management: ability of the mobile node to=
=A0 =A0 =A0 simul= taneously use multiple IP addresses and select the best one
=A0 =A0 =A0 (from an an= choring point of view) to use on a per-session/
=A0 =A0 =A0 application/service basis.=A0 Depending on the mobile node supp= ort,
=A0 =A0 =A0 t= his functionality might require more or less support from the
=A0 =A0 =A0 network sid= e.=A0 This is typically the role of a connection manager.

I'm not s= ure if this is really a connection manager issue. This is more of a source = address selection issue.

<= /blockquote>
[Dapeng] Yes, application and OS protocol stack can = also take the role of choosing source IP address. We will update this=A0sta= tement accordingly.=A0

=A0 =A0 =A0 =A0Mobility= management and traffic redirection should only be
=A0=A0 =A0 =A0 triggered due to IP mobility reasons, that is when the MN mo= ves
=A0=A0 =A0 =A0= from the point of attachment where the IP flow was originally
=A0=A0 =A0 =A0 initiate= d.

Mobility mana= gement and traffic redirection may also be triggered due to load balancing.= Maybe we should acknowledge such non-mobility related triggers, and state = that they are outside the scope of this document.

[Dapeng] I am not sure w= hether there is a case that mobility=A0management is triggered=A0due to loa= d balancing. Could you help to give an example?
=A0

Should we des= cribed the terms IP session continuity and IP address reachability? This do= cument is solely focusing on the former, we should state that.

<= /blockquote>
[Dapeng] For "IP address reachability", yo= u mean the case that session is initiated from Internet toward to the MN? I= am not sure whether it should be in the scope of mobility management. For = example, RFC5555 does not discuss this case.

When doing the gap analysis, we better break down the benefits we are seeki= ng and evaluate existing solutions with respect to them (e.g., signaling re= duction, use of most direct data-path, etc. ). For example, regular use of = HMIP helps with the former, but not the latter. But, using RCoA as source a= ddress helps with both (but it has other issues -- when MN moves outside th= e local domain).
=A0
[Dapeng] We already done = that in section 5.2. Do you have more column want to add in table 1?
<= div style>
Thanks,
Dapeng Liu
=A0 =A0=A0

Alper





















On Jun 27, 2013, at 1:48 PM, Liu Dapeng wrote:

Hello folks:

To make good progress in Berlin meeting, it is bet= ter for us to start
discussion and resolve comments in the list now. Ple= ase help to review
and feel free to send comments.

quick summary = of the draft:
-----
Section 4 'DMM practice' mainly analyses the mobility depl= oyment
practice in WLAN and 3GPP network. Both client-based and network-= based
mobility protocols are discussed.

Section 5 'Gap analys= is' tentatively discusses the gaps. Please have a
look whether you agree on those gaps and whether you want to propose
any= new ones. Any input from the group will be welcomed.

Thanks,
Dap= eng Liu

2013/6/17 Zuniga, Juan Carlos <JuanCarlos.Zuniga@interdigita= l.com>:
Hi all,

We have posted an updated versi= on of the current practices and gap analysis draft. We would like to make o= ne more update before Berlin, so your comments and feedback are very welcom= e.

Regards,

=
Juan Carlos et al.

-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf= .org]
Sent: Monday, June 17, 2013 11:07 AM=
To: Carlos J. Bernardos; H Antho= ny Chan; Zuniga, Juan Carlos; Anthony Chan; Dapeng Liu; Zuniga, Juan Carlos= ; Pierrick Seite
Subject: New Version Notification fo= rdraft-ietf-dmm-best-practices-gap-analysis-01.txt


A new version of I-D, draft-ietf-dmm-best-practic= es-gap-analysis-01.txt
has been s= uccessfully submitted by Dapeng Liu and posted to the
IETF repository.

Filename: =A0=A0=A0=A0=A0=A0=A0draft-ietf-dmm-be= st-practices-gap-analysis
Revisio= n: =A0=A0=A0=A0=A0=A0=A001
Title: =A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0Distributed Mobility Management: Current practices and gap analysis
<= /blockquote>
Creation date: =A0=A02013-06-17
Group: =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0dmm
Number of pages: 21
URL= : =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0http://www.ietf.org/internet-drafts/draft-ietf-dmm-best-practices-gap-a= nalysis-01.txt
Status: =A0=A0=A0=A0=A0=A0=A0=A0=A0<= a href=3D"http://datatracker.ietf.org/doc/draft-ietf-dmm-best-practices-gap= -analysis" target=3D"_blank">http://datatracker.ietf.org/doc/draft-ietf-dmm= -best-practices-gap-analysis
Htmlized: =A0=A0=A0=A0=A0=A0=A0http://tools.ietf.org/html/draft-ietf-dmm-best-pract= ices-gap-analysis-01
Diff: =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0http://www.ietf.org/rfcdiff?url2=3Dd= raft-ietf-dmm-best-practices-gap-analysis-01

Abstract:
=A0=A0The prese= nt document analyses deplyment practices of existing
=A0=A0mobility protocols in a distributed mobility management environment.=
=A0=A0It also identifies some l= imitations compared to the expected
=A0=A0functionality of a fully distributed mobility management system. = =A0The
=A0=A0comparison is made taking int= o account the identified DMM
=A0= =A0requirements.




The IETF Secretariat<= br>

_______________________________________________
dmm mailing list
<= a href=3D"mailto:dmm@ietf.org" target=3D"_blank">dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm



--

------
Best Regards,
Dapeng Liu
_= ______________________________________________
dmm mailing list
dmm@i= etf.org
https://www.ietf.org/mailman/listinfo/dmm



=

--

------
Best Regards,
Dapeng Liu --20cf307d066a5833dc04e1c00449-- From maxpassion@gmail.com Wed Jul 17 20:11:38 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33BF721F9A3B for ; Wed, 17 Jul 2013 20:11:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.479 X-Spam-Level: X-Spam-Status: No, score=-2.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qrUIESN78rne for ; Wed, 17 Jul 2013 20:11:37 -0700 (PDT) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 3F82A21F9A16 for ; Wed, 17 Jul 2013 20:11:37 -0700 (PDT) Received: by mail-vc0-f177.google.com with SMTP id hv10so1949551vcb.36 for ; Wed, 17 Jul 2013 20:11:36 -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=u+J8bjiy6FQRcyjQGw2UvcoftiaT8GJTuVUuoHANSTE=; b=hb1XgzaouHU9NXF3yRzj4XzbjB8f24hhuwTXpnUTTnyceMlvKomkPejQeayuWJ2sFf gzaVEQo1FDfmH6kNJ4eJucUFM4SOZP4p8oKr2vHgF9jKkF8q0VxTbaOXqPjJrv/ICOuz e3HhA3Zi8nAwTrS8cMEc1zImxOngM12Dvs2HjGGi5e3crsIV3nkg/o4i1J2tQnrGJgdx AMmLKyuVzIj1Ox3CJD14rMacOpnUdYJ9JOFtnGQuVeDI9vWGpDjURRM1cAZanC/qh5No 7Y89QMtXGejNBgx1/fr5h4xGNUbj2QzxJQ7btuGOLPmBroZB5m2IvLLCMHAUXt0wZIhA OTUg== MIME-Version: 1.0 X-Received: by 10.52.92.240 with SMTP id cp16mr2637738vdb.80.1374117096672; Wed, 17 Jul 2013 20:11:36 -0700 (PDT) Received: by 10.221.65.2 with HTTP; Wed, 17 Jul 2013 20:11:36 -0700 (PDT) In-Reply-To: <69756203DDDDE64E987BC4F70B71A26D553095B4@DAPHNIS.office.hd> References: <69756203DDDDE64E987BC4F70B71A26D553095B4@DAPHNIS.office.hd> Date: Thu, 18 Jul 2013 11:11:36 +0800 Message-ID: From: Liu Dapeng To: Marco Liebsch Content-Type: multipart/alternative; boundary=20cf307f39c06d526f04e1c0919e Cc: dmm Subject: Re: [DMM] I-D Action: draft-liu-sdn-mobility-00.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 03:11:38 -0000 --20cf307f39c06d526f04e1c0919e Content-Type: text/plain; charset=ISO-8859-1 Hi Marco, Thanks for your valuable comment. Yes the draft's scope maybe more than DMM charter's scope. Let us discuss more in the meeting. Thanks, Regards, Dapeng Liu 2013/7/17 Marco Liebsch > Hi Dapeng, > > even though the draft is not specific to the DMM problem space, I agree > with taking > SDN into account to tackle some issues in DMM. Mainly I see SDN as > technology > to support indirection of user traffic after anchor relocation to enable > IP address continuity. This allows more optimal paths to the mobile's > current > mobility anchor. > > Which parts of such solution can be handled in the IETF is a different > story, > but I think that even IETF-based solutions should consider inter-working > with SDN to enable optimized solutions. That's one message of our DMM > framework draft. > > Thanks for posting the draft. > > Best regards, > marco > > > >-----Original Message----- > >From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of Liu > >Dapeng > >Sent: Donnerstag, 11. Juli 2013 09:06 > >To: dmm > >Subject: [DMM] I-D Action: draft-liu-sdn-mobility-00.txt > > > >Hi all, > > > >We submit a SDN mobility draft. The purpose is to trigger discussions on > the > >topic of SDN mobility. Your comments are appreciated. > > > >Thanks, > >Dapeng Liu > >________________________________ > > > >A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > > >Title : Mobility Support in Software Defined Networking > >Author(s) : Dapeng Liu > > Hui Deng > >Filename : draft-liu-sdn-mobility-00.txt > >Pages : 6 > >Date : 2013-07-08 > > > >Abstract: > > This document discusses the SDN mobility problem and potential > > solutions. > > > > > >The IETF datatracker status page for this draft is: > >https://datatracker.ietf.org/doc/draft-liu-sdn-mobility > > > >There's also a htmlized version available at: > >http://tools.ietf.org/html/draft-liu-sdn-mobility-00 > > > > > >Internet-Drafts are also available by anonymous FTP at: > >ftp://ftp.ietf.org/internet-drafts/ > > > > > >-- > > > >------ > >Best Regards, > >Dapeng Liu > >_______________________________________________ > >dmm mailing list > >dmm@ietf.org > >https://www.ietf.org/mailman/listinfo/dmm > -- ------ Best Regards, Dapeng Liu --20cf307f39c06d526f04e1c0919e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Marco,

Thanks for your=A0valuable=A0= comment.=A0
Yes the draft's scope maybe more than DMM charter= 's scope.
Let us discuss more in the meeting.

Thanks,
Regards,
Dapen= g Liu


2013/7/17 Marco Liebsch <Marco.Liebsch@neclab.eu><= br>
Hi Dapeng,

even though the draft is not specific to the DMM problem space, I agree wit= h taking
SDN into account to tackle some issues in DMM. Mainly I see SDN as technolo= gy
to support indirection of user traffic after anchor relocation to enable IP address continuity. This allows more optimal paths to the mobile's c= urrent
mobility anchor.

Which parts of such solution can be handled in the IETF is a different stor= y,
but I think that even IETF-based solutions should consider inter-working with SDN to enable optimized solutions. That's one message of our DMM f= ramework draft.

Thanks for posting the draft.

Best regards,
marco


>-----Original Message-----
>From: dmm-bounces@ietf.org = [mailto:dmm-bounces@ietf.org] O= n Behalf Of Liu
>Dapeng
>Sent: Donnerstag, 11. Juli 2013 09:06
>To: dmm
>Subject: [DMM] I-D Action: draft-liu-sdn-mobility-00.txt
>
>Hi all,
>
>We submit a SDN mobility draft. =A0The purpose is to trigger discussion= s on the
>topic of SDN mobility. Your comments are appreciated.
>
>Thanks,
>Dapeng Liu
>________________________________
>
>A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories.
>
>
>Title =A0 =A0 =A0 =A0 =A0 : Mobility Support in Software Defined Networ= king
>Author(s) =A0 =A0 =A0 : Dapeng Liu
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Hui Deng
>Filename =A0 =A0 =A0 =A0: draft-liu-sdn-mobility-00.txt
>Pages =A0 =A0 =A0 =A0 =A0 : 6
>Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-07-08
>
>Abstract:
> =A0 This document discusses the SDN mobility problem and potential
> =A0 solutions.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-liu-sdn-mobility<= br> >
>There's also a htmlized version available at:
>http://tools.ietf.org/html/draft-liu-sdn-mobility-00
>
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp:/= /ftp.ietf.org/internet-drafts/
>
>
>--
>
>------
>Best Regards,
>Dapeng Liu
>_______________________________________________
>dmm mailing list
>dmm@ietf.org
>https://www.ietf.org/mailman/listinfo/dmm



--

------Best Regards,
Dapeng Liu
--20cf307f39c06d526f04e1c0919e-- From maxpassion@gmail.com Wed Jul 17 20:17:11 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 964CB21F9B07 for ; Wed, 17 Jul 2013 20:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.488 X-Spam-Level: X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUfam5+zr+Qa for ; Wed, 17 Jul 2013 20:17:09 -0700 (PDT) Received: from mail-ve0-x236.google.com (mail-ve0-x236.google.com [IPv6:2607:f8b0:400c:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id EF4EB21F9A2E for ; Wed, 17 Jul 2013 20:17:08 -0700 (PDT) Received: by mail-ve0-f182.google.com with SMTP id ox1so2078393veb.41 for ; Wed, 17 Jul 2013 20:17:08 -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=fC2yZGkJbDxF/BSKS0oCtEN5poLndNgD0PaTVif0fw8=; b=jUq4xMR4WDfN4Ci3JOgDTSdu6j2DpCsGaKUXWKrwGkEEm88xzuFrLJlMEhBNIKjqkY sol4OxLFykmpZaL/6VtYlSfzxFS8fRwY2Hgit8/EzjmYmX8c7LTsWsgEpdmv8CKes8n7 qTBBfyDAsvYB3CUsceY2eSOrhExYTjJ5mNIaE0OT5f0leQFcYdhpFgMKY22gtOVA5tz6 V0WTREmzDHH0VcqFirxNF+AFUBYSjjp6FaQ/w6Iw8ev0GV0ZEx6JducKGTtt26EPwEBy KIK+4QkpZ++VGSKy0TYFVI6RHlogR5oa+JqV7FvkNqNlsVHYnrOLUpwN+YquMAawC0kQ RkdQ== MIME-Version: 1.0 X-Received: by 10.52.33.162 with SMTP id s2mr2770743vdi.37.1374117428343; Wed, 17 Jul 2013 20:17:08 -0700 (PDT) Received: by 10.221.65.2 with HTTP; Wed, 17 Jul 2013 20:17:08 -0700 (PDT) In-Reply-To: References: <69756203DDDDE64E987BC4F70B71A26D553095B4@DAPHNIS.office.hd> Date: Thu, 18 Jul 2013 11:17:08 +0800 Message-ID: From: Liu Dapeng To: "Pascal Thubert (pthubert)" Content-Type: multipart/alternative; boundary=20cf307d066a323ada04e1c0a513 Cc: dmm Subject: Re: [DMM] I-D Action: draft-liu-sdn-mobility-00.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 03:17:11 -0000 --20cf307d066a323ada04e1c0a513 Content-Type: text/plain; charset=ISO-8859-1 Hello Pascal, Thanks for the greeting :) In my understanding, SDN is a concept that separates the control and forwarding plane of IP appliance and it may have various types of implementation. PCE maybe is one of such implementations. Thanks, Regards, Dapeng Liu 2013/7/17 Pascal Thubert (pthubert) > Hello Dapeng, > > I hipe you're doing good these days; > > I like the concept, I'm a bit more confused with the addition of SDN vs. > for instance PCE? > > Cheers, > > Pascal > > -----Original Message----- > From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of > Marco Liebsch > Sent: mercredi 17 juillet 2013 12:18 > To: Liu Dapeng; dmm > Subject: Re: [DMM] I-D Action: draft-liu-sdn-mobility-00.txt > > Hi Dapeng, > > even though the draft is not specific to the DMM problem space, I agree > with taking SDN into account to tackle some issues in DMM. Mainly I see SDN > as technology to support indirection of user traffic after anchor > relocation to enable IP address continuity. This allows more optimal paths > to the mobile's current mobility anchor. > > Which parts of such solution can be handled in the IETF is a different > story, but I think that even IETF-based solutions should consider > inter-working with SDN to enable optimized solutions. That's one message of > our DMM framework draft. > > Thanks for posting the draft. > > Best regards, > marco > > > >-----Original Message----- > >From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of > >Liu Dapeng > >Sent: Donnerstag, 11. Juli 2013 09:06 > >To: dmm > >Subject: [DMM] I-D Action: draft-liu-sdn-mobility-00.txt > > > >Hi all, > > > >We submit a SDN mobility draft. The purpose is to trigger discussions > >on the topic of SDN mobility. Your comments are appreciated. > > > >Thanks, > >Dapeng Liu > >________________________________ > > > >A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > > > >Title : Mobility Support in Software Defined Networking > >Author(s) : Dapeng Liu > > Hui Deng > >Filename : draft-liu-sdn-mobility-00.txt > >Pages : 6 > >Date : 2013-07-08 > > > >Abstract: > > This document discusses the SDN mobility problem and potential > > solutions. > > > > > >The IETF datatracker status page for this draft is: > >https://datatracker.ietf.org/doc/draft-liu-sdn-mobility > > > >There's also a htmlized version available at: > >http://tools.ietf.org/html/draft-liu-sdn-mobility-00 > > > > > >Internet-Drafts are also available by anonymous FTP at: > >ftp://ftp.ietf.org/internet-drafts/ > > > > > >-- > > > >------ > >Best Regards, > >Dapeng Liu > >_______________________________________________ > >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 > -- ------ Best Regards, Dapeng Liu --20cf307d066a323ada04e1c0a513 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello Pascal,

Thanks for the gree= ting :)

In my understanding, SDN is a = concept that=A0separates the control and forwarding plane of IP appliance= =A0and it may have=A0various types of implementation. PCE maybe is one of s= uch implementations.

Thanks,
Regards,
Dapeng Liu


2013/7/17 Pascal Thubert (pthubert) <= pthubert@cisco.com<= /a>>
Hello Dapeng,

I hipe you're doing good these days;

I like the concept, I'm a bit more confused with the addition of SDN vs= . for instance PCE?

Cheers,

Pascal

-----Original Message-----
From: dmm-bounces@ietf.org [mai= lto:dmm-bounces@ietf.org] On Be= half Of Marco Liebsch
Sent: mercredi 17 juillet 2013 12:18
To: Liu Dapeng; dmm
Subject: Re: [DMM] I-D Action: draft-liu-sdn-mobility-00.txt

Hi Dapeng,

even though the draft is not specific to the DMM problem space, I agree wit= h taking SDN into account to tackle some issues in DMM. Mainly I see SDN as= technology to support indirection of user traffic after anchor relocation = to enable IP address continuity. This allows more optimal paths to the mobi= le's current mobility anchor.

Which parts of such solution can be handled in the IETF is a different stor= y, but I think that even IETF-based solutions should consider inter-working= with SDN to enable optimized solutions. That's one message of our DMM = framework draft.

Thanks for posting the draft.

Best regards,
marco


>-----Original Message-----
>From: dmm-bounces@ietf.org = [mailto:dmm-bounces@ietf.org] O= n Behalf Of
>Liu Dapeng
>Sent: Donnerstag, 11. Juli 2013 09:06
>To: dmm
>Subject: [DMM] I-D Action: draft-liu-sdn-mobility-00.txt
>
>Hi all,
>
>We submit a SDN mobility draft. =A0The purpose is to trigger discussion= s
>on the topic of SDN mobility. Your comments are appreciated.
>
>Thanks,
>Dapeng Liu
>________________________________
>
>A New Internet-Draft is available from the on-line Internet-Drafts dire= ctories.
>
>
>Title =A0 =A0 =A0 =A0 =A0 : Mobility Support in Software Defined Networ= king
>Author(s) =A0 =A0 =A0 : Dapeng Liu
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Hui Deng
>Filename =A0 =A0 =A0 =A0: draft-liu-sdn-mobility-00.txt
>Pages =A0 =A0 =A0 =A0 =A0 : 6
>Date =A0 =A0 =A0 =A0 =A0 =A0: 2013-07-08
>
>Abstract:
> =A0 This document discusses the SDN mobility problem and potential
> =A0 solutions.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-liu-sdn-mobility<= br> >
>There's also a htmlized version available at:
>http://tools.ietf.org/html/draft-liu-sdn-mobility-00
>
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp:/= /ftp.ietf.org/internet-drafts/
>
>
>--
>
>------
>Best Regards,
>Dapeng Liu
>_______________________________________________
>dmm mailing list
>dmm@ietf.org
>https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________
dmm mailing list
dmm@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/dmm



--
=
------
Best Regards,
Dapeng Liu
--20cf307d066a323ada04e1c0a513-- From alper.yegin@yegin.org Thu Jul 18 01:17:24 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2868E21F9FFB for ; Thu, 18 Jul 2013 01:17:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.536 X-Spam-Level: X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I2n67UkU4d8o for ; Thu, 18 Jul 2013 01:17:17 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id E71DD21E8090 for ; Thu, 18 Jul 2013 01:17:15 -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 0Lsl8b-1U1xzX2iHh-012bQP; Thu, 18 Jul 2013 04:16:40 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_44785ADF-1EA9-4E2F-B8DF-CA9321E791BA" From: Alper Yegin In-Reply-To: Date: Thu, 18 Jul 2013 11:16:32 +0300 Message-Id: <8CC62269-8458-4911-8AFC-B01314BAEC90@yegin.org> References: <28407EEF-BFB9-47A2-A562-DCEF8BCDC1CF@yegin.org> To: Liu Dapeng X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:YxVQuBnHd4xn+J+/qDAq5pNUn+Fu8Z9LM4kc65zlmF7 Jeql+XBfuV/n9EHeWAgH9cHvhzl4EFFRIRt6z96KIFF8AMZJjc 1wlkoINAoEV8fY9tRKH9aH6ruTvNiWysL50QCDdR04tOwA0x7M 54ymJoVfBVNPuL12d4lq8wtMTicL3KZc46HtqveOvRL4kx7Uxr lsgeQF57XdwxeaChPPVRolRXTbGjFc3ctZoElJdgeiUnvO883/ vzt0MNmQZC7KXKLnIigUpD90UJYfE4cVM8rvElndZ2OVYeZyPt bvMQePcNEdEdVMatHvc0NocAptBmrzcSFOVqHxgiSunrHTMj7Y Q5Z3zDBxDniAbbF58xn3fBBAC6nCgwQ9RxYG0uSRIjCdEcVy3/ Y56sLz6kPV1Jg== Cc: dmm Subject: Re: [DMM] New Version Notification for draft-ietf-dmm-best-practices-gap-analysis-01.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 08:17:24 -0000 --Apple-Mail=_44785ADF-1EA9-4E2F-B8DF-CA9321E791BA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi Dapeng, > Multiple IP address management: ability of the mobile node to > simultaneously use multiple IP addresses and select the best one > (from an anchoring point of view) to use on a per-session/ > application/service basis. Depending on the mobile node = support, > this functionality might require more or less support from the > network side. This is typically the role of a connection = manager. >=20 > I'm not sure if this is really a connection manager issue. This is = more of a source address selection issue. >=20 > [Dapeng] Yes, application and OS protocol stack can also take the role = of choosing source IP address. We will update this statement = accordingly.=20 Alper> OK. But I still don't think connection manager does that. As far = as I know, connection manager deals with choosing which network the IP = stack should connect. Does it also control which one of the multiple IP = addresses available on the IP stack is chosen by the applications when = they connect()/sendmsg(), etc.? >=20 > Mobility management and traffic redirection should only be > triggered due to IP mobility reasons, that is when the MN moves > from the point of attachment where the IP flow was originally > initiated. >=20 > Mobility management and traffic redirection may also be triggered due = to load balancing. Maybe we should acknowledge such non-mobility related = triggers, and state that they are outside the scope of this document. >=20 > [Dapeng] I am not sure whether there is a case that mobility = management is triggered due to load balancing. Could you help to give an = example? Alper> I was referring to forcing the MN to change its HA when the = currently used HA is overloaded.=20 > =20 >=20 > Should we described the terms IP session continuity and IP address = reachability? This document is solely focusing on the former, we should = state that. >=20 > [Dapeng] For "IP address reachability", you mean the case that session = is initiated from Internet toward to the MN? Alper> Yes. > I am not sure whether it should be in the scope of mobility = management. For example, RFC5555 does not discuss this case. Alper> It's part of "mobility management". Mobile IP and its variants = support that.=20 The case where it is not supported is when the home address keeps = changing (e.g., dynamically anchoring and re-anchoring) -- in which case = the MN does not have stable IP address to stay "reachable".=20 >=20 > When doing the gap analysis, we better break down the benefits we are = seeking and evaluate existing solutions with respect to them (e.g., = signaling reduction, use of most direct data-path, etc. ). For example, = regular use of HMIP helps with the former, but not the latter. But, = using RCoA as source address helps with both (but it has other issues -- = when MN moves outside the local domain). > =20 > [Dapeng] We already done that in section 5.2. Do you have more column = want to add in table 1? Alper> Dapeng, I don't see section 5.2 or table 1 in = http://www.ietf.org/id/draft-ietf-dmm-best-practices-gap-analysis-01.txt Alper >=20 > Thanks, > Dapeng Liu > =20 >=20 > Alper >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > On Jun 27, 2013, at 1:48 PM, Liu Dapeng wrote: >=20 >> Hello folks: >>=20 >> To make good progress in Berlin meeting, it is better for us to start >> discussion and resolve comments in the list now. Please help to = review >> and feel free to send comments. >>=20 >> quick summary of the draft: >> ----- >> Section 4 'DMM practice' mainly analyses the mobility deployment >> practice in WLAN and 3GPP network. Both client-based and = network-based >> mobility protocols are discussed. >>=20 >> Section 5 'Gap analysis' tentatively discusses the gaps. Please have = a >> look whether you agree on those gaps and whether you want to propose >> any new ones. Any input from the group will be welcomed. >>=20 >> Thanks, >> Dapeng Liu >>=20 >> 2013/6/17 Zuniga, Juan Carlos : >>> Hi all, >>>=20 >>> We have posted an updated version of the current practices and gap = analysis draft. We would like to make one more update before Berlin, so = your comments and feedback are very welcome. >>>=20 >>> Regards, >>>=20 >>> Juan Carlos et al. >>>=20 >>> -----Original Message----- >>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>> Sent: Monday, June 17, 2013 11:07 AM >>> To: Carlos J. Bernardos; H Anthony Chan; Zuniga, Juan Carlos; = Anthony Chan; Dapeng Liu; Zuniga, Juan Carlos; Pierrick Seite >>> Subject: New Version Notification = fordraft-ietf-dmm-best-practices-gap-analysis-01.txt >>>=20 >>>=20 >>> A new version of I-D, = draft-ietf-dmm-best-practices-gap-analysis-01.txt >>> has been successfully submitted by Dapeng Liu and posted to the >>> IETF repository. >>>=20 >>> Filename: draft-ietf-dmm-best-practices-gap-analysis >>> Revision: 01 >>> Title: Distributed Mobility Management: Current practices = and gap analysis >>> Creation date: 2013-06-17 >>> Group: dmm >>> Number of pages: 21 >>> URL: = http://www.ietf.org/internet-drafts/draft-ietf-dmm-best-practices-gap-anal= ysis-01.txt >>> Status: = http://datatracker.ietf.org/doc/draft-ietf-dmm-best-practices-gap-analysis= >>> Htmlized: = http://tools.ietf.org/html/draft-ietf-dmm-best-practices-gap-analysis-01 >>> Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dmm-best-practices-gap-analy= sis-01 >>>=20 >>> Abstract: >>> The present document analyses deplyment practices of existing >>> mobility protocols in a distributed mobility management = environment. >>> It also identifies some limitations compared to the expected >>> functionality of a fully distributed mobility management system. = The >>> comparison is made taking into account the identified DMM >>> requirements. >>>=20 >>>=20 >>>=20 >>>=20 >>> The IETF Secretariat >>>=20 >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm >>=20 >>=20 >>=20 >> --=20 >>=20 >> ------ >> Best Regards, >> Dapeng Liu >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >=20 >=20 >=20 >=20 > --=20 >=20 > ------ > Best Regards, > Dapeng Liu --Apple-Mail=_44785ADF-1EA9-4E2F-B8DF-CA9321E791BA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1 Hi = Dapeng,

      = Multiple IP address management: ability of the mobile node to
      = simultaneously use multiple IP addresses and select the best one
      = (from an anchoring point of view) to use on a per-session/
      application/service basis.  Depending on the = mobile node support,
      = this functionality might require more or less support from the
      = network side.  This is typically the role of a connection = manager.

I'm not sure if this is = really a connection manager issue. This is more of a source address = selection issue.

[Dapeng] = Yes, application and OS protocol stack can also take the role of = choosing source IP address. We will update this statement = accordingly. 


Alper> OK. But I still don't think connection manager = does that. As far as I know, connection manager deals with choosing = which network the IP stack should connect. Does it also control which = one of the multiple IP addresses available on the IP stack is chosen by = the applications when they connect()/sendmsg(), = etc.?



      =  Mobility management and traffic redirection should only = be
       triggered due to IP mobility reasons, that is = when the MN moves
     =   from the point of attachment where the IP flow was = originally
     =   initiated.

Mobility management and = traffic redirection may also be triggered due to load balancing. Maybe = we should acknowledge such non-mobility related triggers, and state that = they are outside the scope of this document.

[Dapeng] I am = not sure whether there is a case that mobility management is = triggered due to load balancing. Could you help to give an = example?

Alper>= I was referring to forcing the MN to change its HA when the currently = used HA is overloaded. 


 

Should we described the = terms IP session continuity and IP address reachability? This document = is solely focusing on the former, we should state that.

[Dapeng] For = "IP address reachability", you mean the case that session is initiated = from Internet toward to the MN? =

Alper> = Yes.

I am = not sure whether it should be in the scope of mobility management. For = example, RFC5555 does not discuss this = case.

Alper> = It's part of "mobility management". Mobile IP and its variants support = that. 
The case where it is not supported is when the = home address keeps changing (e.g., dynamically anchoring and = re-anchoring) -- in which case the MN does not have stable IP address to = stay "reachable". 


When doing the gap analysis, we better break down the benefits we are = seeking and evaluate existing solutions with respect to them (e.g., = signaling reduction, use of most direct data-path, etc. ). For example, = regular use of HMIP helps with the former, but not the latter. But, = using RCoA as source address helps with both (but it has other issues -- = when MN moves outside the local domain).
 
[Dapeng] We = already done that in section 5.2. Do you have more column want to add in = table = 1?

Alper> = Dapeng, I don't see section 5.2 or table 1 in http://www.ietf.org/id/draft-ietf-dmm-best-practices-gap-analysis-= 01.txt

Alper



Thanks,
Dapeng Liu
    

Alper





















On = Jun 27, 2013, at 1:48 PM, Liu Dapeng wrote:

Hello folks:

To make good progress in Berlin meeting, it is = better for us to start
discussion and resolve comments in the list = now. Please help to review
and feel free to send = comments.

quick summary of the draft:
-----
Section 4 'DMM practice' mainly analyses the mobility = deployment
practice in WLAN and 3GPP network. Both client-based and = network-based
mobility protocols are discussed.

Section 5 'Gap = analysis' tentatively discusses the gaps. Please have a
look whether you agree on those gaps and whether you want to = propose
any new ones. Any input from the group will be = welcomed.

Thanks,
Dapeng Liu

2013/6/17 Zuniga, Juan = Carlos <JuanCarlos.Zuniga@interdigital.com>:
Hi all,

We have posted = an updated version of the current practices and gap analysis draft. We = would like to make one more update before Berlin, so your comments and = feedback are very welcome.

Regards,

Juan Carlos et = al.

-----Original = Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Monday, June 17, 2013 11:07 = AM
To: Carlos J. Bernardos; H = Anthony Chan; Zuniga, Juan Carlos; Anthony Chan; Dapeng Liu; Zuniga, = Juan Carlos; Pierrick Seite
Subject: New Version Notification = fordraft-ietf-dmm-best-practices-gap-analysis-01.txt


A new version of I-D, = draft-ietf-dmm-best-practices-gap-analysis-01.txt
has been successfully submitted by Dapeng Liu and = posted to the
IETF repository.

Filename: =        draft-ietf-dmm-best-practices-ga= p-analysis
Revision: =        01
Title: =           Distributed = Mobility Management: Current practices and gap = analysis
Creation date: =   2013-06-17
Group: =           dmm
Number of pages: = 21
URL: =             http://www.ietf.org/internet-drafts/draft-ietf-dmm-best-= practices-gap-analysis-01.txt
Status: =          http://datatracker.ietf.org/doc/draft-ietf-dmm-best-prac= tices-gap-analysis
Htmlized: =        http://tools.ietf.org/html/draft-ietf-dmm-best-practices= -gap-analysis-01
Diff: =            http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dmm-best-p= ractices-gap-analysis-01

Abstract:
=   The present document analyses deplyment practices of = existing
  mobility protocols in a distributed mobility management = environment.
  It = also identifies some limitations compared to the = expected
=   functionality of a fully distributed mobility management = system.  The
  comparison is made = taking into account the identified DMM
  requirements.




The IETF = Secretariat

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



--

------
Best Regards,
Dapeng = Liu
_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
<= /blockquote>




--

------
Best = Regards,
Dapeng Liu
= --Apple-Mail=_44785ADF-1EA9-4E2F-B8DF-CA9321E791BA-- From satoru.matsushima@gmail.com Thu Jul 18 03:40:36 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27FE221E80D9 for ; Thu, 18 Jul 2013 03:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r886EJTEWZt1 for ; Thu, 18 Jul 2013 03:40:35 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 36EA621E80D7 for ; Thu, 18 Jul 2013 03:40:34 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id 13so2431431lba.30 for ; Thu, 18 Jul 2013 03:40:33 -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=jVmynSYri8ukhjqhIfIbicE7xt4pxO9VhDZ7wvfjABo=; b=GliQUVpxbEpm87V2nYBK0/En8cLPimxZ7eoNp+VLooSbZjw7FCtq8iy8WcDcnXeP92 IShbFHb0vhO5Ua3K5EVE/FOFn2aAiYQr9fRtNVefDPIHyvQ2JiRcQgn1CQ24TJBBxXI2 O4qLrgnWfZDMKeP4TE4vQQB1szKD+dx2x+09n5SKW6nu6cTl2mxHI+P2nvbEomRCs1NK MKwnQAzFMeRuwtpzSxfV6ID4ae/Fu/YL/vn5ysShRT33pKk36LHt7odvfsuHGkUPLWHI OAl6Lx9coWI8dYm18MGMlVBpcdp/jskbLwZDidJeTQWgnGX0THYj93baskBa956xpGE+ U8Ow== MIME-Version: 1.0 X-Received: by 10.112.144.35 with SMTP id sj3mr5166914lbb.4.1374144032993; Thu, 18 Jul 2013 03:40:32 -0700 (PDT) Received: by 10.112.167.169 with HTTP; Thu, 18 Jul 2013 03:40:32 -0700 (PDT) In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716F4F97F@dfweml512-mbx.china.huawei.com> References: <20130710160944.11064.6824.idtracker@ietfa.amsl.com> <724A5F78-33A4-4608-82B9-231DC2AAE2F6@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716F4F1E8@dfweml512-mbx.china.huawei.com> <504A19F8-3C16-4821-86A5-3C3BCA96FE78@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716F4F44C@dfweml512-mbx.china.huawei.com> <5963DDF1F751474D8DEEFDCDBEE43AE716F4F609@dfweml512-mbx.china.huawei.com> <51E56263.9030302@alcatel-lucent.com> <5963DDF1F751474D8DEEFDCDBEE43AE716F4F97F@dfweml512-mbx.china.huawei.com> Date: Thu, 18 Jul 2013 19:40:32 +0900 Message-ID: From: Satoru Matsushima To: Peter McCann Content-Type: multipart/alternative; boundary=047d7b3432bef4f85304e1c6d6b2 Cc: dmm Subject: Re: [DMM] Fwd: New Version Notification for draft-matsushima-stateless-uplane-vepc-00.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jul 2013 10:40:36 -0000 --047d7b3432bef4f85304e1c6d6b2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Pete, On Thu, Jul 18, 2013 at 2:11 AM, Peter McCann wrot= e: > Hi, Satoru, > > Satoru Matsushima wrote: > > On Wed, Jul 17, 2013 at 12:10 AM, Bruno Mongazon-Cazavet > > wrote: > > > > > > Le 16/07/2013 16:27, Peter McCann a =E9crit : > > > > > > Satoru Matsushima wrote: > > > > > > Hi Peter, > > > > On 2013/07/16, at 3:49, Peter McCann < > Peter.McCann@huawei.com> wrote: > > > > > > I guess I don't understand the "PDN > Prefix" and "subnet ID" fields > > that you have in Figure 4. You state: > > > > Each PDN is assumed to have single or > several prefixes (called > > PDN prefix) used to generate UE's address. > Followed by the PDN > > prefix in Figure 4, there is 16-bit TEID > assigned for a UE's > > session at SGW on the control plane. > TEID is 16 bits identifier > > in GTP header to distinguish each > bearer. The remaining bits are > > filled by subnet ID. The prefix is allocate= d > per UE and used for > > address assignment by SLAAC or > DHCPv6. Is Figure 4 supposed > > to be the Next Hop or the Destination? I assumed > it was Next Hop > > because it has the TEID encoded in it. However, some > of the above > > paragraph leads me to believe it is about the UE's user > plane IP > > address. > > > > > > > > The figure 4 illustrates UE's prefix so it shows > the destination. > > Encoding TEID is just a seed to create UE's prefi= x > in the > > stateless-pd manner. > > > > > > Doesn't the TEID change on every eNB handover? I thought > the UE's > > prefix should remain constant across handovers. > > > > > > > > > > If you use stateless-pd rule for UE's prefix generation, the embedded > > TEID is SGW assigned one. So the delegated prefix is stable during > > across eNB handover. Please see the section 3.3 in update version of > > the draft. Anycast routing no longer requires hand-over between SGW in > > virtualized EPC. > > > > > > > > Yes TEID changes on handover and when UE exits Idle-Mode (it has > > previously entered). > > > > > > Thanks, we haven't mention about in the case of Idle-Mode exit. will > > update with it in a next version. It would be in control-plane > > awareness section. > > I think taken together, these facts would mean that the TEID space is > shared across all EPC-E devices (they all have the same anycast address) > and also that a TEID would need to remain allocated even to idle UEs. > > Would you eventually run out of TEID space? > To be honest, I'm not sure whether the 32bits space of TEID could be exhausted in almost deployment cases. :) But when any logical(TEID, etc.,) or physical(bandwidth, etc.,) resources are exhausted, you can build additional set of EPC-Es which share another anycast address. Please see section 4 of the draft. > > > We hasn't illustrate yet how to encode the TEID i= n > next-hop. But > > as we mentioned in the document, we expect BGP remote next-hop as > the > > way to encode it in the sub-TLV of the remote next-hop attribute. > > > > > > I would think that the Next-Hop would change on mobility > events, but > > the Destination would remain the same (UE prefix). Why is > this not > > the case? > > > > > > > > Yes, exactly. > > Ok, so the Destination IPv6 address needs to remain the same during the > lifetime > of a UE session, even across idle transitions and mobility events, right? > Right. regards, --satoru --047d7b3432bef4f85304e1c6d6b2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Pete,


On Thu, Jul 18, 2013 at 2:11 AM, Peter McCann <Peter.McC= ann@huawei.com> wrote:
Hi, Satoru,

Satoru Matsushima wrote:
> On Wed, Jul 17, 2013 at 12:10 AM, Bruno M= ongazon-Cazavet
> <bruno= .mongazon-cazavet@alcatel-lucent.com> wrote:
>
>
> =A0 =A0 =A0 Le 16/07/2013 16:27, Peter McCann a =E9crit :
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 Satoru Matsushima wrote:
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Hi Peter,
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 On 2013/07/16, at 3:49, Pe= ter McCann <Peter.McCann@huaw= ei.com> wrote:
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 I guess I = don't understand the "PDN Prefix" and "subnet ID" f= ields
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 that you h= ave in Figure 4. =A0You state:
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Eac= h PDN is assumed to have single or several prefixes (called
> PDN =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0prefix)= used to generate UE's address. Followed by the PDN
> prefix in =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0Figure 4, there is 16-bit TEID assigned for a UE's
> session at SGW on =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0the control plane. =A0TEID is 16 bits identifier
> in GTP header to =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 distinguish each bearer. =A0The remaining bits are
> filled by subnet ID. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 The prefix is allocated per UE and used for
> address assignment by =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0SLAAC or DHCPv6. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0 =A0 =A0 =A0 =A0 Is Figure 4 supposed
> to be the Next Hop or the Destination? =A0I assumed =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 it was Next Hop
> because it has the TEID encoded in it. =A0However, some =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 of the above
> paragraph leads me to believe it is about the UE's user =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 plane IP
> address.
>
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 The figure 4 illustrates U= E's prefix so it shows the destination.
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Encoding TEID is just a se= ed to create UE's prefix in the
> stateless-pd =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0manner.
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 Doesn't the TEID change on every eNB h= andover? =A0I thought the UE's
> prefix =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0should remain constant across ha= ndovers.
>
>
>
>
> If you use stateless-pd rule for UE's prefix generation, the embed= ded
> TEID is SGW assigned one. So the delegated prefix is stable during
> across eNB handover. Please see the section 3.3 in update version of > the draft. Anycast routing no longer requires hand-over between SGW in=
> virtualized EPC.
>
>
>
> =A0 =A0 =A0 Yes TEID changes on handover and when UE exits Idle-Mode (= it has
> previously entered).
>
>
> Thanks, we haven't mention about in the case of Idle-Mode exit. wi= ll
> update with it in a next version. It would be in control-plane
> awareness section.

I think taken together, these facts would mean that the TEID sp= ace is
shared across all EPC-E devices (they all have the same anycast address) and also that a TEID would need to remain allocated even to idle UEs.

Would you eventually run out of TEID space?

=
To be honest, I'm not sure whether the 32bits space of TEID = could be exhausted in almost deployment cases. :)
But when = any logical(TEID, etc.,) or physical(bandwidth, etc.,) resources are exhaus= ted, you can build additional set of EPC-Es which share another anycast add= ress. Please see section 4 of the draft.

=A0

> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 We hasn't illustrate y= et how to encode the TEID in next-hop. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0But
> as we mentioned in the document, we expect BGP remote next-hop as =A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 the
> way to encode it in the sub-TLV of the remote next-hop attribute.
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 I would think that the Next-Hop would chan= ge on mobility events, but
> the =A0 =A0 =A0 =A0 =A0 Destination would remain the same (UE prefix).= =A0Why is this not
> the case?
>
>
>
> Yes, exactly.

Ok, so the Destination IPv6 address needs to remain the same during t= he lifetime
of a UE session, even across idle transitions and mobility events, right?

Right.

regards,
--satoru
--047d7b3432bef4f85304e1c6d6b2-- From maxpassion@gmail.com Thu Jul 18 19:17:49 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C85BE21E8148 for ; Thu, 18 Jul 2013 19:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.496 X-Spam-Level: X-Spam-Status: No, score=-2.496 tagged_above=-999 required=5 tests=[AWL=0.103, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cmg1XNCwg5XC for ; Thu, 18 Jul 2013 19:17:47 -0700 (PDT) Received: from mail-vc0-x231.google.com (mail-vc0-x231.google.com [IPv6:2607:f8b0:400c:c03::231]) by ietfa.amsl.com (Postfix) with ESMTP id 0508711E824E for ; Thu, 18 Jul 2013 19:17:46 -0700 (PDT) Received: by mail-vc0-f177.google.com with SMTP id ia10so732650vcb.36 for ; Thu, 18 Jul 2013 19:17:45 -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=z8DfoEwJxVwFyP9HIAR71GjhgKMrvToDFuHqPq55PSU=; b=xrlvIPGJH4dy7vJOpELr56kyIM6b1vvSoD9868LjVk4zA2Pdi3+oYVStJpZ7aDpbSk UndMbYbi25+KCLvvVU/Ly/56sxQ14+Cglm+V9mm4EEqC21B0+zJ6W+tEi8cM96gUpeyo CRZiyBI3lHyu11mU71BwjwGaRqU/eY5x28VNix+LFhqk4/FJXRjYbyapeaGmQFJ3HO+j VcQ35WBQ/U+gptlbF0rPOAgHHuINiVKxfiptywTjRiKd5835WI++QcMKYyzPVW2xL6EZ 3FExq7Mb584jUH34HwlYoe8guiPUZoUHMQ7Nu1fcGq7ghfCUUMiiecG6arQNJtVZqjhZ sJQw== MIME-Version: 1.0 X-Received: by 10.52.33.162 with SMTP id s2mr4333930vdi.37.1374200265330; Thu, 18 Jul 2013 19:17:45 -0700 (PDT) Received: by 10.221.65.2 with HTTP; Thu, 18 Jul 2013 19:17:45 -0700 (PDT) In-Reply-To: <8CC62269-8458-4911-8AFC-B01314BAEC90@yegin.org> References: <28407EEF-BFB9-47A2-A562-DCEF8BCDC1CF@yegin.org> <8CC62269-8458-4911-8AFC-B01314BAEC90@yegin.org> Date: Fri, 19 Jul 2013 10:17:45 +0800 Message-ID: From: Liu Dapeng To: Alper Yegin Content-Type: multipart/alternative; boundary=20cf307d066aaa556904e1d3eeec Cc: dmm Subject: Re: [DMM] New Version Notification for draft-ietf-dmm-best-practices-gap-analysis-01.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 02:17:49 -0000 --20cf307d066aaa556904e1d3eeec Content-Type: text/plain; charset=ISO-8859-1 2013/7/18 Alper Yegin > Hi Dapeng, > > Multiple IP address management: ability of the mobile node to >> simultaneously use multiple IP addresses and select the best one >> (from an anchoring point of view) to use on a per-session/ >> application/service basis. Depending on the mobile node support, >> this functionality might require more or less support from the >> network side. This is typically the role of a connection manager. >> >> I'm not sure if this is really a connection manager issue. This is more >> of a source address selection issue. >> >> [Dapeng] Yes, application and OS protocol stack can also take the role of > choosing source IP address. We will update this statement accordingly. > > > > Alper> OK. But I still don't think connection manager does that. As far as > I know, connection manager deals with choosing which network the IP stack > should connect. Does it also control which one of the multiple IP addresses > available on the IP stack is chosen by the applications when they > connect()/sendmsg(), etc.? > [Dapeng] Yes, most connection manager today does not do that. We will consider to remove the connection manager part. > >> Mobility management and traffic redirection should only be >> triggered due to IP mobility reasons, that is when the MN moves >> from the point of attachment where the IP flow was originally >> initiated. >> >> Mobility management and traffic redirection may also be triggered due to >> load balancing. Maybe we should acknowledge such non-mobility related >> triggers, and state that they are outside the scope of this document. >> > > [Dapeng] I am not sure whether there is a case that mobility management is > triggered due to load balancing. Could you help to give an example? > > > Alper> I was referring to forcing the MN to change its HA when the > currently used HA is overloaded. > [Dapeng] OK, That is the HA redirection case. How about changing the word "should only" to "normally"? > >> > >> Should we described the terms IP session continuity and IP address >> reachability? This document is solely focusing on the former, we should >> state that. >> >> [Dapeng] For "IP address reachability", you mean the case that session is > initiated from Internet toward to the MN? > > > Alper> Yes. > > I am not sure whether it should be in the scope of mobility management. > For example, RFC5555 does not discuss this case. > > > Alper> It's part of "mobility management". Mobile IP and its variants > support that. > The case where it is not supported is when the home address keeps changing > (e.g., dynamically anchoring and re-anchoring) -- in which case the MN does > not have stable IP address to stay "reachable". > [Dapeng] The DMM charter says: "Although the maintenance of stable home address(es) and/or prefix(es) and upper level sessions is a desirable goal when mobile hosts/routers change their point of attachment to the Internet, it is not a strict requirement" So IP address reachability may not in the scope. > > >> When doing the gap analysis, we better break down the benefits we are >> seeking and evaluate existing solutions with respect to them (e.g., >> signaling reduction, use of most direct data-path, etc. ). For example, >> regular use of HMIP helps with the former, but not the latter. But, using >> RCoA as source address helps with both (but it has other issues -- when MN >> moves outside the local domain). >> > > [Dapeng] We already done that in section 5.2. Do you have more column want > to add in table 1? > > > Alper> Dapeng, I don't see section 5.2 or table 1 in > http://www.ietf.org/id/draft-ietf-dmm-best-practices-gap-analysis-01.txt > > [Dapeng] It is in the 00 version ( http://tools.ietf.org/html/draft-ietf-dmm-best-practices-gap-analysis-00#section-5.1.2). In this update version, the table is not included yet. We can include it if folks believe it is useful. But we need have consensus on the conclusion of the table. Thanks for your valuable comments. Dapeng Liu > Alper > > > > Thanks, > Dapeng Liu > > > Alper >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Jun 27, 2013, at 1:48 PM, Liu Dapeng wrote: >> >> Hello folks: >> >> To make good progress in Berlin meeting, it is better for us to start >> discussion and resolve comments in the list now. Please help to review >> and feel free to send comments. >> >> quick summary of the draft: >> ----- >> Section 4 'DMM practice' mainly analyses the mobility deployment >> practice in WLAN and 3GPP network. Both client-based and network-based >> mobility protocols are discussed. >> >> Section 5 'Gap analysis' tentatively discusses the gaps. Please have a >> look whether you agree on those gaps and whether you want to propose >> any new ones. Any input from the group will be welcomed. >> >> Thanks, >> Dapeng Liu >> >> 2013/6/17 Zuniga, Juan Carlos : >> >> Hi all, >> >> >> We have posted an updated version of the current practices and gap >> analysis draft. We would like to make one more update before Berlin, so >> your comments and feedback are very welcome. >> >> >> Regards, >> >> >> Juan Carlos et al. >> >> >> -----Original Message----- >> >> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >> >> Sent: Monday, June 17, 2013 11:07 AM >> >> To: Carlos J. Bernardos; H Anthony Chan; Zuniga, Juan Carlos; Anthony >> Chan; Dapeng Liu; Zuniga, Juan Carlos; Pierrick Seite >> >> Subject: New Version Notification >> fordraft-ietf-dmm-best-practices-gap-analysis-01.txt >> >> >> >> A new version of I-D, draft-ietf-dmm-best-practices-gap-analysis-01.txt >> >> has been successfully submitted by Dapeng Liu and posted to the >> >> IETF repository. >> >> >> Filename: draft-ietf-dmm-best-practices-gap-analysis >> >> Revision: 01 >> >> Title: Distributed Mobility Management: Current practices and >> gap analysis >> >> Creation date: 2013-06-17 >> >> Group: dmm >> >> Number of pages: 21 >> >> URL: >> http://www.ietf.org/internet-drafts/draft-ietf-dmm-best-practices-gap-analysis-01.txt >> >> Status: >> http://datatracker.ietf.org/doc/draft-ietf-dmm-best-practices-gap-analysis >> >> Htmlized: >> http://tools.ietf.org/html/draft-ietf-dmm-best-practices-gap-analysis-01 >> >> Diff: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-best-practices-gap-analysis-01 >> >> >> Abstract: >> >> The present document analyses deplyment practices of existing >> >> mobility protocols in a distributed mobility management environment. >> >> It also identifies some limitations compared to the expected >> >> functionality of a fully distributed mobility management system. The >> >> comparison is made taking into account the identified DMM >> >> requirements. >> >> >> >> >> >> The IETF Secretariat >> >> >> _______________________________________________ >> >> dmm mailing list >> >> dmm@ietf.org >> >> https://www.ietf.org/mailman/listinfo/dmm >> >> >> >> >> -- >> >> ------ >> Best Regards, >> Dapeng Liu >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >> >> >> > > > -- > > ------ > Best Regards, > Dapeng Liu > > > -- ------ Best Regards, Dapeng Liu --20cf307d066aaa556904e1d3eeec Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



2013/7/18 Alper Yegin <alper.yegin@yegin.org>
Hi Dapeng,

=A0 =A0 =A0 Multiple IP address management: ability of the mobile node to
=A0 =A0 = =A0 simultaneously use multiple IP addresses and select the best one
=A0 =A0 =A0 (= from an anchoring point of view) to use on a per-session/
=A0 =A0 =A0 application/service basis.=A0 Depending on the mobile node supp= ort,
=A0= =A0 =A0 this functionality might require more or less support from the
=A0 =A0 =A0 n= etwork side.=A0 This is typically the role of a connection manager.

I&#= 39;m not sure if this is really a connection manager issue. This is more of= a source address selection issue.

[Dapeng] Yes, application and OS protocol stack = can also take the role of choosing source IP address. We will update this= =A0statement accordingly.=A0


Alp= er> OK. But I still don't think connection manager does that. As far= as I know, connection manager deals with choosing which network the IP sta= ck should connect. Does it also control which one of the multiple IP addres= ses available on the IP stack is chosen by the applications when they conne= ct()/sendmsg(), etc.?


[Dapeng] = Yes, most connection manager today does not do that. We will consider to re= move the connection manager part.=A0

=A0 =A0 =A0 = =A0Mobility management and traffic redirection should only be
=A0=A0 =A0 =A0 triggered due to IP mobility reasons, that is when the MN mo= ves
=A0= =A0 =A0 =A0 from the point of attachment where the IP flow was originally
=A0=A0 =A0 = =A0 initiated.

Mob= ility management and traffic redirection may also be triggered due to load = balancing. Maybe we should acknowledge such non-mobility related triggers, = and state that they are outside the scope of this document.

[Dapeng] I am not sure whether= there is a case that mobility=A0management is triggered=A0due to load bala= ncing. Could you help to give an example?

Alper> I was referring to forcing the MN to ch= ange its HA when the currently used HA is overloaded.=A0
<= /div>


[Dapeng] OK, That is t= he HA redirection case. =A0How about changing the word "should only&qu= ot; to "normally"?
<= blockquote type=3D"cite">
=A0

Sho= uld we described the terms IP session continuity and IP address reachabilit= y? This document is solely focusing on the former, we should state that.

[Dapeng] For "IP address reachability"= , you mean the case that session is initiated from Internet toward to the M= N?

Alper> Yes.

I am not sure whether it should be in= the scope of mobility management. For example, RFC5555 does not discuss th= is case.

Alper> It's= part of "mobility management". Mobile IP and its variants suppor= t that.=A0
The case where it is not supported is when the home ad= dress keeps changing (e.g., dynamically anchoring and re-anchoring) -- in w= hich case the MN does not have stable IP address to stay "reachable&qu= ot;.=A0

[Dapeng= ] The DMM charter says:=A0

=A0"Although t= he maintenance of stable home address(es) and/or prefix(es)=A0
and uppe= r level sessions is a desirable goal when mobile hosts/routers=A0 change t= heir point of attachment to the Internet, it is not a strict=A0
requirem= ent"=A0

So IP address reachability may not in the scope.
=A0

When doing the gap analysis, we better break down the benefits we are seeki= ng and evaluate existing solutions with respect to them (e.g., signaling re= duction, use of most direct data-path, etc. ). For example, regular use of = HMIP helps with the former, but not the latter. But, using RCoA as source a= ddress helps with both (but it has other issues -- when MN moves outside th= e local domain).
=A0
[Dapeng] We already done that i= n section 5.2. Do you have more column want to add in table 1?
<= /div>

Alper> Dapeng, I don&#= 39;t see section 5.2 or table 1 in=A0http://www= .ietf.org/id/draft-ietf-dmm-best-practices-gap-analysis-01.txt


[Dapeng] It is in the 00 version (= http://tools.ietf.org/html/draft-ietf-dmm-best-prac= tices-gap-analysis-00#section-5.1.2). In this update version, the table= is not included yet. We can include it if folks believe it is useful. But = we need have=A0consensus on the=A0conclusion=A0of the table.=A0=A0

Thanks for your valuable comments.

Dapeng Liu
=A0
Alper



Thanks,
Dapeng Liu
=A0 =A0=A0

Alper











On Jun 27, 2013, at 1:48 PM, Liu Dapeng wrote:

Hello folks:

To make good progress in Berlin meeting, it is bet= ter for us to start
discussion and resolve comments in the list now. Ple= ase help to review
and feel free to send comments.

quick summary = of the draft:
-----
Section 4 'DMM practice' mainly analyses the mobility depl= oyment
practice in WLAN and 3GPP network. Both client-based and network-= based
mobility protocols are discussed.

Section 5 'Gap analys= is' tentatively discusses the gaps. Please have a
look whether you agree on those gaps and whether you want to propose
any= new ones. Any input from the group will be welcomed.

Thanks,
Dap= eng Liu

2013/6/17 Zuniga, Juan Carlos <JuanCarlos.Zuniga@interdigita= l.com>:
Hi all,

We have posted an updated versi= on of the current practices and gap analysis draft. We would like to make o= ne more update before Berlin, so your comments and feedback are very welcom= e.

Regards,

=
Juan Carlos et al.

-----Original Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf= .org]
Sent: Monday, June 17, 2013 11:07 AM=
To: Carlos J. Bernardos; H Antho= ny Chan; Zuniga, Juan Carlos; Anthony Chan; Dapeng Liu; Zuniga, Juan Carlos= ; Pierrick Seite
Subject: New Version Notification fo= rdraft-ietf-dmm-best-practices-gap-analysis-01.txt


A new version of I-D, draft-ietf-dmm-best-practic= es-gap-analysis-01.txt
has been s= uccessfully submitted by Dapeng Liu and posted to the
IETF repository.

Filename: =A0=A0=A0=A0=A0=A0=A0draft-ietf-dmm-be= st-practices-gap-analysis
Revisio= n: =A0=A0=A0=A0=A0=A0=A001
Title: =A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0Distributed Mobility Management: Current practices and gap analysis
<= /blockquote>
Creation date: =A0=A02013-06-17
Group: =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0dmm
Number of pages: 21
URL= : =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0http://www.ietf.org/internet-drafts/draft-ietf-dmm-best-practices-gap-a= nalysis-01.txt
Status: =A0=A0=A0=A0=A0=A0=A0=A0=A0<= a href=3D"http://datatracker.ietf.org/doc/draft-ietf-dmm-best-practices-gap= -analysis" target=3D"_blank">http://datatracker.ietf.org/doc/draft-ietf-dmm= -best-practices-gap-analysis
Htmlized: =A0=A0=A0=A0=A0=A0=A0http://tools.ietf.org/html/draft-ietf-dmm-best-pract= ices-gap-analysis-01
Diff: =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0http://www.ietf.org/rfcdiff?url2=3Dd= raft-ietf-dmm-best-practices-gap-analysis-01

Abstract:
=A0=A0The prese= nt document analyses deplyment practices of existing
=A0=A0mobility protocols in a distributed mobility management environment.=
=A0=A0It also identifies some l= imitations compared to the expected
=A0=A0functionality of a fully distributed mobility management system. = =A0The
=A0=A0comparison is made taking int= o account the identified DMM
=A0= =A0requirements.




The IETF Secretariat<= br>

_______________________________________________
dmm mailing list
<= a href=3D"mailto:dmm@ietf.org" target=3D"_blank">dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm



--

------
Best Regards,
Dapeng Liu
_= ______________________________________________
dmm mailing list
dmm@i= etf.org
https://www.ietf.org/mailman/listinfo/dmm



=

--

------
Best Regards,
Dapeng Liu




--

------
Best Regards,
Dapeng Li= u --20cf307d066aaa556904e1d3eeec-- From alper.yegin@yegin.org Fri Jul 19 00:01:53 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA0C221E80B5 for ; Fri, 19 Jul 2013 00:01:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.549 X-Spam-Level: X-Spam-Status: No, score=-102.549 tagged_above=-999 required=5 tests=[AWL=0.049, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cWonnUKGYDUT for ; Fri, 19 Jul 2013 00:01:44 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 3CBAD21E809E for ; Fri, 19 Jul 2013 00:01:44 -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 0M8eMt-1UEJjS1eXz-00vQRK; Fri, 19 Jul 2013 03:01:39 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_9678955B-2484-44D1-851C-DEA429A7D8AC" From: Alper Yegin In-Reply-To: Date: Fri, 19 Jul 2013 10:01:31 +0300 Message-Id: <9E1C1DEC-DD24-42C2-965A-3294BDE43BAB@yegin.org> References: <28407EEF-BFB9-47A2-A562-DCEF8BCDC1CF@yegin.org> <8CC62269-8458-4911-8AFC-B01314BAEC90@yegin.org> To: Liu Dapeng X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:0mXMiLOIrBYfEwS48S5gJipBGlAGVIa4o3za609qtUu VxTeUIcx7BmR2lN4XtbDRzH9l+I9HtmW6I7xNa+St+LbR+W4ww /vbv69akeDY6AshNT/r/skSZkfQxvpej10EVi0MVSePs+vEE13 DkPqZcmpfa4LlT4lmjxFu7B3SZVVl9zaNvyzkdDzDguClP6dxV ZrAgUGFtvwgi9jhYYqtyWiZPgwuBdb5c97i0pyToiPU9FbjTGH PqYHeoFxUfojDbtz7t6EpzPl5JqZ4B7vyiWVmlpO5QHjAYidAv lIqKcic6zZoSbS/SmrtvPbbe+9EEyUl1GVNtKjzX8Bwy8Mu4o5 BGkDE/627dxfw7pmoLrwJdHJG1TMIy9q8eQtbhU0HPgAintJB9 jVW5usS2eR/4Q== Cc: dmm Subject: Re: [DMM] New Version Notification for draft-ietf-dmm-best-practices-gap-analysis-01.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 07:01:54 -0000 --Apple-Mail=_9678955B-2484-44D1-851C-DEA429A7D8AC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Dapeng, >>=20 >> Mobility management and traffic redirection should only be >> triggered due to IP mobility reasons, that is when the MN = moves >> from the point of attachment where the IP flow was originally >> initiated. >>=20 >> Mobility management and traffic redirection may also be triggered due = to load balancing. Maybe we should acknowledge such non-mobility related = triggers, and state that they are outside the scope of this document. >>=20 >> [Dapeng] I am not sure whether there is a case that mobility = management is triggered due to load balancing. Could you help to give an = example? >=20 > Alper> I was referring to forcing the MN to change its HA when the = currently used HA is overloaded.=20 >=20 >=20 > [Dapeng] OK, That is the HA redirection case. How about changing the = word "should only" to "normally"? I'd recommend something like this: This document considers use of mobility management and traffic = redirection=20 only within the context of IP mobility, that is when the MN moves from the point of attachment where the IP flow was originally initiated. >> =20 >>=20 >> Should we described the terms IP session continuity and IP address = reachability? This document is solely focusing on the former, we should = state that. >>=20 >> [Dapeng] For "IP address reachability", you mean the case that = session is initiated from Internet toward to the MN? >=20 > Alper> Yes. >=20 >> I am not sure whether it should be in the scope of mobility = management. For example, RFC5555 does not discuss this case. >=20 > Alper> It's part of "mobility management". Mobile IP and its variants = support that.=20 > The case where it is not supported is when the home address keeps = changing (e.g., dynamically anchoring and re-anchoring) -- in which case = the MN does not have stable IP address to stay "reachable".=20 >=20 > [Dapeng] The DMM charter says:=20 >=20 > "Although the maintenance of stable home address(es) and/or = prefix(es)=20 > and upper level sessions is a desirable goal when mobile hosts/routers=20= > change their point of attachment to the Internet, it is not a strict=20= > requirement"=20 >=20 > So IP address reachability may not in the scope. Even though IP address reachability is within the scope of "mobility = management" concept in general, DMM WG charter does not mandate it be = handled in its solutions. Yes. > =20 >>=20 >> When doing the gap analysis, we better break down the benefits we are = seeking and evaluate existing solutions with respect to them (e.g., = signaling reduction, use of most direct data-path, etc. ). For example, = regular use of HMIP helps with the former, but not the latter. But, = using RCoA as source address helps with both (but it has other issues -- = when MN moves outside the local domain). >> =20 >> [Dapeng] We already done that in section 5.2. Do you have more column = want to add in table 1? >=20 > Alper> Dapeng, I don't see section 5.2 or table 1 in = http://www.ietf.org/id/draft-ietf-dmm-best-practices-gap-analysis-01.txt >=20 >=20 > [Dapeng] It is in the 00 version = (http://tools.ietf.org/html/draft-ietf-dmm-best-practices-gap-analysis-00#= section-5.1.2). In this update version, the table is not included yet. = We can include it if folks believe it is useful. But we need have = consensus on the conclusion of the table. =20 >=20 > Thanks for your valuable comments. >=20 Cheers, Alper > Dapeng Liu > =20 > Alper >=20 >=20 >>=20 >> Thanks, >> Dapeng Liu >> =20 >>=20 >> Alper >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> On Jun 27, 2013, at 1:48 PM, Liu Dapeng wrote: >>=20 >>> Hello folks: >>>=20 >>> To make good progress in Berlin meeting, it is better for us to = start >>> discussion and resolve comments in the list now. Please help to = review >>> and feel free to send comments. >>>=20 >>> quick summary of the draft: >>> ----- >>> Section 4 'DMM practice' mainly analyses the mobility deployment >>> practice in WLAN and 3GPP network. Both client-based and = network-based >>> mobility protocols are discussed. >>>=20 >>> Section 5 'Gap analysis' tentatively discusses the gaps. Please have = a >>> look whether you agree on those gaps and whether you want to propose >>> any new ones. Any input from the group will be welcomed. >>>=20 >>> Thanks, >>> Dapeng Liu >>>=20 >>> 2013/6/17 Zuniga, Juan Carlos : >>>> Hi all, >>>>=20 >>>> We have posted an updated version of the current practices and gap = analysis draft. We would like to make one more update before Berlin, so = your comments and feedback are very welcome. >>>>=20 >>>> Regards, >>>>=20 >>>> Juan Carlos et al. >>>>=20 >>>> -----Original Message----- >>>> From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >>>> Sent: Monday, June 17, 2013 11:07 AM >>>> To: Carlos J. Bernardos; H Anthony Chan; Zuniga, Juan Carlos; = Anthony Chan; Dapeng Liu; Zuniga, Juan Carlos; Pierrick Seite >>>> Subject: New Version Notification = fordraft-ietf-dmm-best-practices-gap-analysis-01.txt >>>>=20 >>>>=20 >>>> A new version of I-D, = draft-ietf-dmm-best-practices-gap-analysis-01.txt >>>> has been successfully submitted by Dapeng Liu and posted to the >>>> IETF repository. >>>>=20 >>>> Filename: draft-ietf-dmm-best-practices-gap-analysis >>>> Revision: 01 >>>> Title: Distributed Mobility Management: Current practices = and gap analysis >>>> Creation date: 2013-06-17 >>>> Group: dmm >>>> Number of pages: 21 >>>> URL: = http://www.ietf.org/internet-drafts/draft-ietf-dmm-best-practices-gap-anal= ysis-01.txt >>>> Status: = http://datatracker.ietf.org/doc/draft-ietf-dmm-best-practices-gap-analysis= >>>> Htmlized: = http://tools.ietf.org/html/draft-ietf-dmm-best-practices-gap-analysis-01 >>>> Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dmm-best-practices-gap-analy= sis-01 >>>>=20 >>>> Abstract: >>>> The present document analyses deplyment practices of existing >>>> mobility protocols in a distributed mobility management = environment. >>>> It also identifies some limitations compared to the expected >>>> functionality of a fully distributed mobility management system. = The >>>> comparison is made taking into account the identified DMM >>>> requirements. >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> The IETF Secretariat >>>>=20 >>>> _______________________________________________ >>>> dmm mailing list >>>> dmm@ietf.org >>>> https://www.ietf.org/mailman/listinfo/dmm >>>=20 >>>=20 >>>=20 >>> --=20 >>>=20 >>> ------ >>> Best Regards, >>> Dapeng Liu >>> _______________________________________________ >>> dmm mailing list >>> dmm@ietf.org >>> https://www.ietf.org/mailman/listinfo/dmm >>=20 >>=20 >>=20 >>=20 >> --=20 >>=20 >> ------ >> Best Regards, >> Dapeng Liu >=20 >=20 >=20 >=20 > --=20 >=20 > ------ > Best Regards, > Dapeng Liu --Apple-Mail=_9678955B-2484-44D1-851C-DEA429A7D8AC Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

    =    Mobility management and traffic redirection should only = be
       triggered due to IP mobility reasons, that is = when the MN moves
   =     from the point of attachment where the IP flow was = originally
   =     initiated.

Mobility = management and traffic redirection may also be triggered due to load = balancing. Maybe we should acknowledge such non-mobility related = triggers, and state that they are outside the scope of this = document.

[Dapeng] I am not sure = whether there is a case that mobility management is = triggered due to load balancing. Could you help to give an = example?

Alper> I was referring to forcing the MN to = change its HA when the currently used HA is = overloaded. 

=
[Dapeng] OK, That is the HA redirection case.  How = about changing the word "should only" to = "normally"?

I'd recommend something like = this:

  =      This document considers use of mobility management = and traffic redirection 
  =      only within the context of IP mobility, that is = when the MN moves
       = from the point of attachment where the IP flow was originally
       = initiated.


 

Should we = described the terms IP session continuity and IP address reachability? = This document is solely focusing on the former, we should state = that.

=
[Dapeng] For "IP address reachability", you mean = the case that session is initiated from Internet toward to the MN? =

Alper> = Yes.

I am not sure = whether it should be in the scope of mobility management. For example, = RFC5555 does not discuss this case.

Alper> It's = part of "mobility management". Mobile IP and its variants support = that. 
The case where it is not supported is when the = home address keeps changing (e.g., dynamically anchoring and = re-anchoring) -- in which case the MN does not have stable IP address to = stay "reachable". 

[Dapeng] The DMM charter says: 

 "Although = the maintenance of stable home address(es) and/or prefix(es) 
and upper = level sessions is a desirable goal when mobile = hosts/routers 
change = their point of attachment to the Internet, it is not a = strict 
requirement<= /span>" 

So IP address reachability may not in the = scope.

Even though = IP address reachability is within the scope of "mobility management" = concept in general, DMM WG charter does not mandate it be handled in its = solutions. = Yes.




=
 

When doing the gap analysis, we better break down the benefits we are = seeking and evaluate existing solutions with respect to them (e.g., = signaling reduction, use of most direct data-path, etc. ). For example, = regular use of HMIP helps with the former, but not the latter. But, = using RCoA as source address helps with both (but it has other issues -- = when MN moves outside the local domain).
 
[Dapeng] We already done = that in section 5.2. Do you have more column want to add in table = 1?

Alper>= Dapeng, I don't see section 5.2 or table 1 in http://www.ietf.org/id/draft-ietf-dmm-best-practices-gap= -analysis-01.txt


[Dapeng] It is in the 00 version (http://tools.ietf.org/html/draft-ietf-dmm-best-pract= ices-gap-analysis-00#section-5.1.2). In this update version, the = table is not included yet. We can include it if folks believe it is = useful. But we need have consensus on the conclusion of = the table.  

Thanks for your valuable = comments.


Ch= eers,

Alper


Dapeng = Liu
 
Alper
=


Thanks,
Dapeng Liu
    

Alper





















<= div>On Jun 27, 2013, at 1:48 PM, Liu Dapeng wrote:

Hello folks:

To make good progress in Berlin meeting, it is = better for us to start
discussion and resolve comments in the list = now. Please help to review
and feel free to send = comments.

quick summary of the draft:
-----
Section 4 'DMM practice' mainly analyses the mobility = deployment
practice in WLAN and 3GPP network. Both client-based and = network-based
mobility protocols are discussed.

Section 5 'Gap = analysis' tentatively discusses the gaps. Please have a
look whether you agree on those gaps and whether you want to = propose
any new ones. Any input from the group will be = welcomed.

Thanks,
Dapeng Liu

2013/6/17 Zuniga, Juan = Carlos <JuanCarlos.Zuniga@interdigital.com>:
Hi all,

We have posted = an updated version of the current practices and gap analysis draft. We = would like to make one more update before Berlin, so your comments and = feedback are very welcome.

Regards,

Juan Carlos et = al.

-----Original = Message-----
From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]
Sent: Monday, June 17, 2013 11:07 = AM
To: Carlos J. Bernardos; H = Anthony Chan; Zuniga, Juan Carlos; Anthony Chan; Dapeng Liu; Zuniga, = Juan Carlos; Pierrick Seite
Subject: New Version Notification = fordraft-ietf-dmm-best-practices-gap-analysis-01.txt


A new version of I-D, = draft-ietf-dmm-best-practices-gap-analysis-01.txt
has been successfully submitted by Dapeng Liu and = posted to the
IETF repository.

Filename: =        draft-ietf-dmm-best-practices-ga= p-analysis
Revision: =        01
Title: =           Distributed = Mobility Management: Current practices and gap = analysis
Creation date: =   2013-06-17
Group: =           dmm
Number of pages: = 21
URL: =             http://www.ietf.org/internet-drafts/draft-ietf-dmm-best-= practices-gap-analysis-01.txt
Status: =          http://datatracker.ietf.org/doc/draft-ietf-dmm-best-prac= tices-gap-analysis
Htmlized: =        http://tools.ietf.org/html/draft-ietf-dmm-best-practices= -gap-analysis-01
Diff: =            http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dmm-best-p= ractices-gap-analysis-01

Abstract:
=   The present document analyses deplyment practices of = existing
  mobility protocols in a distributed mobility management = environment.
  It = also identifies some limitations compared to the = expected
=   functionality of a fully distributed mobility management = system.  The
  comparison is made = taking into account the identified DMM
  requirements.




The IETF = Secretariat

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



--

------
Best Regards,
Dapeng = Liu
_______________________________________________
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm
<= /blockquote>




--

------
Best = Regards,
Dapeng Liu
=




--

------
Best = Regards,
Dapeng Liu
= --Apple-Mail=_9678955B-2484-44D1-851C-DEA429A7D8AC-- From shin02.park@samsung.com Fri Jul 19 00:19:38 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73EB721E80CA for ; Fri, 19 Jul 2013 00:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.604 X-Spam-Level: X-Spam-Status: No, score=-9.604 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, RELAY_IS_203=0.994] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XbaNcqYVF2d for ; Fri, 19 Jul 2013 00:19:32 -0700 (PDT) Received: from mailout2.samsung.com (mailout2.samsung.com [203.254.224.25]) by ietfa.amsl.com (Postfix) with ESMTP id 715FE21E8083 for ; Fri, 19 Jul 2013 00:19:31 -0700 (PDT) Received: from epcpsbgr1.samsung.com (u141.gpu120.samsung.co.kr [203.254.230.141]) by mailout2.samsung.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0MQ6003A19O13LM0@mailout2.samsung.com> for dmm@ietf.org; Fri, 19 Jul 2013 16:19:30 +0900 (KST) Received: from epcpsbgm2.samsung.com ( [172.20.52.113]) by epcpsbgr1.samsung.com (EPCPMTA) with SMTP id 03.A2.17404.188E8E15; Fri, 19 Jul 2013 16:19:30 +0900 (KST) X-AuditID: cbfee68d-b7f096d0000043fc-a4-51e8e8811892 Received: from epmmp1.local.host ( [203.254.227.16]) by epcpsbgm2.samsung.com (EPCPMTA) with SMTP id 1D.A9.31505.188E8E15; Fri, 19 Jul 2013 16:19:29 +0900 (KST) Received: from NOSHIN02PAR04 ([168.219.195.111]) by mmp1.samsung.com (Oracle Communications Messaging Server 7u4-24.01 (7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPA id <0MQ6007BY9OH9180@mmp1.samsung.com>; Fri, 19 Jul 2013 16:19:29 +0900 (KST) From: "Park, Jungshin" To: 'Alper Yegin' , 'Liu Dapeng' References: <28407EEF-BFB9-47A2-A562-DCEF8BCDC1CF@yegin.org> <8CC62269-8458-4911-8AFC-B01314BAEC90@yegin.org> <9E1C1DEC-DD24-42C2-965A-3294BDE43BAB@yegin.org> In-reply-to: <9E1C1DEC-DD24-42C2-965A-3294BDE43BAB@yegin.org> Date: Fri, 19 Jul 2013 16:21:57 +0900 Message-id: <019801ce8450$a7231f30$f5695d90$@samsung.com> MIME-version: 1.0 Content-type: multipart/alternative; boundary="----=_NextPart_000_0199_01CE849C.17101E60" X-Mailer: Microsoft Outlook 14.0 Thread-index: AQGd5LNloWri55/9dSohE/wbYB1TawJVUQ15Ai0nIA8CGt1r1QJwcjNLAaTOP44B4sYkuZloKYqg Content-language: en-us X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMIsWRmVeSWpSXmKPExsWyRsSkULfpxYtAg2e32S3+7r/MbnH/UY3F 4+OHWByYPXbOusvusWTJTyaP+2fOsAQwR3HZpKTmZJalFunbJXBlHLkTXPD5PFNF+51P7A2M c1cxdTFyckgImEg0HexlhLDFJC7cW8/WxcjFISSwlFFiz4LrbDBFWyc3sILYQgKLGCXaO+Mh ihqYJKaumg5WxCZgIPFhfTc7iC0i4Cfx4cERsAZmAQmJSyt7WCCadzJLbNqkDmJzCthK7Fiw AaxGWCBZYlfvBbA5LAKqEqea1oHZvAKWEn2/9zJD2IISPybfY4GYGS2xe9N5VojjFCR2nH3N CLE3RmJmzzqoGnGJSQ8esoMcKiFwjV2i/+YDZogFAhLfJh8CKuIASshKbDrADDFHUuLgihss ExjFZyFZNwvJullIxs4C6mYW0JNo28gIEZaX2P52DjOErSvx/zmMrS2xbOFr5gWM7KsYRVML kguKk9KLDPWKE3OLS/PS9ZLzczcxAmP29L9nvTsYbx+wPsRYBXThRGYp0eR8YMznlcQbGpsZ WZiamBobmVuaUUVYSZxXrcU6UEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAMjx7/+bEVVG/bp tinRJx0vWv/ccexU222nCVb2+QmK5yxUOT9EJ3hI+vrdL79y4ecHdof115Od5T8V3TK179rE UpK+gbVaXjnkq/DjUr7ZheGLHDYfNVh65HLNKY2P5n0eqg94hX9tOnS1ZGn638rGzruFVuWc T1tOTBc/f3HPkuv9nXzVTZJKLMUZiYZazEXFiQDrRKqzBgMAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrAKsWRmVeSWpSXmKPExsVy+t9jAd3GFy8CDXovmVv83X+Z3eL+oxqL x8cPsTgwe+ycdZfdY8mSn0we98+cYQlgjmpgtMlITUxJLVJIzUvOT8nMS7dV8g6Od443NTMw 1DW0tDBXUshLzE21VXLxCdB1y8wB2qSkUJaYUwoUCkgsLlbSt8M0ITTETdcCpjFC1zckCK7H yAANJKxhzDhyJ7jg83mmivY7n9gbGOeuYupi5OSQEDCR2Dq5gRXCFpO4cG89G4gtJLCIUaK9 M76LkQvIbmCSmLpqOliCTcBA4sP6bnYQW0TAT+LDgyNgzcwCEhKXVvawQDTvZJbYtEkdxOYU sJXYsWADWI2wQLLErt4LYHNYBFQlTjWtA7N5BSwl+n7vZYawBSV+TL7HAjEzWmL3pvNQxylI 7Dj7mhFib4zEzJ51UDXiEpMePGSfwCg4C0n7LCTts5CUzWLkALL1JNo2MkKE5SW2v53DDGHr Svx/DmNrSyxb+Jp5ASP7KkbR1ILkguKk9FwjveLE3OLSvHS95PzcTYzghPBMegfjqgaLQ4wC HIxKPLwPvjwPFGJNLCuuzD3EKMHBrCTC+yv5RaAQb0piZVVqUX58UWlOavEhxipgAExklhJN zgcmq7ySeENjEzMjSyNzQwsjY3OqCCuJ8x5stQ4UEkhPLEnNTk0tSC2CWc7EwSnVwKh3NvHF 5Rn7+gXzex4Z3JQIL9yetelyWG5tdv5G6xtKTz5ezT69tLde8xDfwjWHJjzPWMu2xTn185x4 Zdbfy9M3vHhYd8pHY6/czlkrr/gJqAlcmLPKOf1hxEwOfZHtlv3PN5ux31OIkHa5a/dExrqm elepecodAwW2OlmTu5UOpW8XRszNSFRiKc5INNRiLipOBAD+rpC+YwMAAA== DLP-Filter: Pass X-MTR: 20000000000000000@CPGS X-CFilter-Loop: Reflected Cc: 'dmm' Subject: Re: [DMM] New Version Notification for draft-ietf-dmm-best-practices-gap-analysis-01.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 07:19:38 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0199_01CE849C.17101E60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Guys, Sorry to jump in. Will it be safe saying that ". only within the context of IP mobility, that is when the MN moves from the point of attachment where the IP flow was originally initiated" ? It sounds like we are going to handle only the first movement of MN for each flow. I'd like to double-check if it is our agreement. Regards, Jungshin From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of Alper Yegin Sent: Friday, July 19, 2013 4:02 PM To: Liu Dapeng Cc: dmm Subject: Re: [DMM] New Version Notification for draft-ietf-dmm-best-practices-gap-analysis-01.txt Dapeng, Mobility management and traffic redirection should only be triggered due to IP mobility reasons, that is when the MN moves from the point of attachment where the IP flow was originally initiated. Mobility management and traffic redirection may also be triggered due to load balancing. Maybe we should acknowledge such non-mobility related triggers, and state that they are outside the scope of this document. [Dapeng] I am not sure whether there is a case that mobility management is triggered due to load balancing. Could you help to give an example? Alper> I was referring to forcing the MN to change its HA when the currently used HA is overloaded. [Dapeng] OK, That is the HA redirection case. How about changing the word "should only" to "normally"? I'd recommend something like this: This document considers use of mobility management and traffic redirection only within the context of IP mobility, that is when the MN moves from the point of attachment where the IP flow was originally initiated. Should we described the terms IP session continuity and IP address reachability? This document is solely focusing on the former, we should state that. [Dapeng] For "IP address reachability", you mean the case that session is initiated from Internet toward to the MN? Alper> Yes. I am not sure whether it should be in the scope of mobility management. For example, RFC5555 does not discuss this case. Alper> It's part of "mobility management". Mobile IP and its variants support that. The case where it is not supported is when the home address keeps changing (e.g., dynamically anchoring and re-anchoring) -- in which case the MN does not have stable IP address to stay "reachable". [Dapeng] The DMM charter says: "Although the maintenance of stable home address(es) and/or prefix(es) and upper level sessions is a desirable goal when mobile hosts/routers change their point of attachment to the Internet, it is not a strict requirement" So IP address reachability may not in the scope. Even though IP address reachability is within the scope of "mobility management" concept in general, DMM WG charter does not mandate it be handled in its solutions. Yes. When doing the gap analysis, we better break down the benefits we are seeking and evaluate existing solutions with respect to them (e.g., signaling reduction, use of most direct data-path, etc. ). For example, regular use of HMIP helps with the former, but not the latter. But, using RCoA as source address helps with both (but it has other issues -- when MN moves outside the local domain). [Dapeng] We already done that in section 5.2. Do you have more column want to add in table 1? Alper> Dapeng, I don't see section 5.2 or table 1 in http://www.ietf.org/id/draft-ietf-dmm-best-practices-gap-analysis-01.txt [Dapeng] It is in the 00 version (http://tools.ietf.org/html/draft-ietf-dmm-best-practices-gap-analysis-00#se ction-5.1.2). In this update version, the table is not included yet. We can include it if folks believe it is useful. But we need have consensus on the conclusion of the table. Thanks for your valuable comments. Cheers, Alper Dapeng Liu Alper Thanks, Dapeng Liu Alper On Jun 27, 2013, at 1:48 PM, Liu Dapeng wrote: Hello folks: To make good progress in Berlin meeting, it is better for us to start discussion and resolve comments in the list now. Please help to review and feel free to send comments. quick summary of the draft: ----- Section 4 'DMM practice' mainly analyses the mobility deployment practice in WLAN and 3GPP network. Both client-based and network-based mobility protocols are discussed. Section 5 'Gap analysis' tentatively discusses the gaps. Please have a look whether you agree on those gaps and whether you want to propose any new ones. Any input from the group will be welcomed. Thanks, Dapeng Liu 2013/6/17 Zuniga, Juan Carlos : Hi all, We have posted an updated version of the current practices and gap analysis draft. We would like to make one more update before Berlin, so your comments and feedback are very welcome. Regards, Juan Carlos et al. -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] Sent: Monday, June 17, 2013 11:07 AM To: Carlos J. Bernardos; H Anthony Chan; Zuniga, Juan Carlos; Anthony Chan; Dapeng Liu; Zuniga, Juan Carlos; Pierrick Seite Subject: New Version Notification fordraft-ietf-dmm-best-practices-gap-analysis-01.txt A new version of I-D, draft-ietf-dmm-best-practices-gap-analysis-01.txt has been successfully submitted by Dapeng Liu and posted to the IETF repository. Filename: draft-ietf-dmm-best-practices-gap-analysis Revision: 01 Title: Distributed Mobility Management: Current practices and gap analysis Creation date: 2013-06-17 Group: dmm Number of pages: 21 URL: http://www.ietf.org/internet-drafts/draft-ietf-dmm-best-practices-gap-analys is-01.txt Status: http://datatracker.ietf.org/doc/draft-ietf-dmm-best-practices-gap-analysis Htmlized: http://tools.ietf.org/html/draft-ietf-dmm-best-practices-gap-analysis-01 Diff: http://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-best-practices-gap-analysis- 01 Abstract: The present document analyses deplyment practices of existing mobility protocols in a distributed mobility management environment. It also identifies some limitations compared to the expected functionality of a fully distributed mobility management system. The comparison is made taking into account the identified DMM requirements. The IETF Secretariat _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm -- ------ Best Regards, Dapeng Liu _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm -- ------ Best Regards, Dapeng Liu -- ------ Best Regards, Dapeng Liu ------=_NextPart_000_0199_01CE849C.17101E60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi = Guys,

 

Sorry = to jump in.

Will = it be safe saying that “… only within = the context of IP mobility, that is when the MN = moves = from the = point of attachment where the IP flow was originally initiated<= span lang=3DEN-US style=3D'font-size:10.0pt;font-family:"Malgun = Gothic";color:black'>” ?

It = sounds like we are going to handle only the first movement of MN for = each flow.

I’d like to double-check if it is our = agreement.

 

Regards,

Jungshin

 

From:= = dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of = Alper Yegin
Sent: Friday, July 19, 2013 4:02 = PM
To: Liu Dapeng
Cc: dmm
Subject: Re: = [DMM] New Version Notification for = draft-ietf-dmm-best-practices-gap-analysis-01.txt

 

Dapeng,

 

 

      =  Mobility management and traffic redirection should only = be

   =     triggered due to IP mobility reasons, that is when the MN = moves

   =     from the point of attachment where the IP flow was = originally

   =     initiated.

 

Mobility management and = traffic redirection may also be triggered due to load balancing. Maybe = we should acknowledge such non-mobility related triggers, and state that = they are outside the scope of this = document.

 

[Dapeng] I am not sure whether = there is a case that mobility management is triggered due to = load balancing. Could you help to give an = example?

<= p class=3DMsoNormal> 

Alper> I was referring to = forcing the MN to change its HA when the currently used HA is = overloaded. 

 

 

[Dapeng] OK, That is the HA = redirection case.  How about changing the word "should = only" to = "normally"?

 

 

I'd recommend something like = this:

 

  =      This document considers use of mobility management = and traffic redirection 

  =      only within the context of IP mobility, that is = when the MN moves

  =     from the point of attachment where the IP flow was = originally

  =     initiated.

 



 

 

Should we described the = terms IP session continuity and IP address reachability? This document = is solely focusing on the former, we should state = that.

 

[Dapeng] For "IP address reachability", you mean = the case that session is initiated from Internet toward to the MN? =

 

Alper> = Yes.



I am not sure whether it should be = in the scope of mobility management. For example, RFC5555 does not = discuss this case.

 

Alper> It's part of = "mobility management". Mobile IP and its variants support = that. 

The case where it is not supported is when the home address = keeps changing (e.g., dynamically anchoring and re-anchoring) -- in = which case the MN does not have stable IP address to stay = "reachable". 

 

[Dapeng] The DMM charter = says: 

 

 "A= lthough the maintenance of stable home address(es) and/or = prefix(es) 

a= nd upper level sessions is a desirable goal when mobile = hosts/routers 
change their point of attachment to the Internet, = it is not a strict 
requirement" 

 

So IP address reachability may not = in the scope.

 

Even though IP address reachability = is within the scope of "mobility management" concept in = general, DMM WG charter does not mandate it be handled in its solutions. = Yes.

 

 

 



 

 

When doing the gap = analysis, we better break down the benefits we are seeking and evaluate = existing solutions with respect to them (e.g., signaling reduction, use = of most direct data-path, etc. ). For example, regular use of HMIP helps = with the former, but not the latter. But, using RCoA as source address = helps with both (but it has other issues -- when MN moves outside the = local = domain).

 

[Dapeng] We already done that in = section 5.2. Do you have more column want to add in table = 1?

 

Alper> Dapeng, I don't see = section 5.2 or table 1 in http://www.ietf.org/id/draft-ietf-dmm-best-practices-ga= p-analysis-01.txt

 

 

[Dapeng] It is in the 00 version = (http://tools.ietf.org/html/draft-ietf-dmm-best-pra= ctices-gap-analysis-00#section-5.1.2). In this update version, the = table is not included yet. We can include it if folks believe it is = useful. But we need have consensus on the conclusion of = the table.  

 

Thanks for your valuable = comments.

 

 

Cheers,

 

Alper

 

 



Dapeng = Liu

 

Alper

<= p class=3DMsoNormal> 



 

Thanks,

Dapeng = Liu

    

 

Alper

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

On Jun 27, = 2013, at 1:48 PM, Liu Dapeng wrote:



Hello folks:

To make good = progress in Berlin meeting, it is better for us to start
discussion = and resolve comments in the list now. Please help to review
and feel = free to send comments.

quick summary of the = draft:
-----
Section 4 'DMM practice' mainly analyses the mobility = deployment
practice in WLAN and 3GPP network. Both client-based and = network-based
mobility protocols are discussed.

Section 5 'Gap = analysis' tentatively discusses the gaps. Please have a
look whether = you agree on those gaps and whether you want to propose
any new ones. = Any input from the group will be welcomed.

Thanks,
Dapeng = Liu

2013/6/17 Zuniga, Juan Carlos <JuanCarlos.Zuniga@interdigital.com>:

Hi = all,

 

We have posted an updated version = of the current practices and gap analysis draft. We would like to make = one more update before Berlin, so your comments and feedback are very = welcome.

 

Regards,

 

Juan Carlos et = al.

 

-----Original = Message-----

From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]

Sent: Monday, June 17, 2013 11:07 = AM

To: Carlos J. Bernardos; H Anthony = Chan; Zuniga, Juan Carlos; Anthony Chan; Dapeng Liu; Zuniga, Juan = Carlos; Pierrick Seite

Subject: New Version Notification = fordraft-ietf-dmm-best-practices-gap-analysis-01.txt

 

 

A new version of I-D, = draft-ietf-dmm-best-practices-gap-analysis-01.txt

has been successfully submitted by = Dapeng Liu and posted to = the

IETF = repository.

 

Filename: =        draft-ietf-dmm-best-practices-g= ap-analysis

Revision: =        01

Title: =           Distributed = Mobility Management: Current practices and gap = analysis

Creation date: =   2013-06-17

Group: =           dmm

Number of pages: = 21

URL: =             <= a = href=3D"http://www.ietf.org/internet-drafts/draft-ietf-dmm-best-practices= -gap-analysis-01.txt" = target=3D"_blank">http://www.ietf.org/internet-drafts/draft-ietf-dmm-best= -practices-gap-analysis-01.txt

Status: =          http://datatracker.ietf.org/doc/draft-ietf-dmm-best-pra= ctices-gap-analysis

Htmlized: =        http://tools.ietf.org/html/draft-ietf-dmm-best-practice= s-gap-analysis-01

Diff: =            http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dmm-best-= practices-gap-analysis-01

 

Abstract:

  The present document = analyses deplyment practices of = existing

  mobility protocols in a = distributed mobility management = environment.

  It also identifies some = limitations compared to the = expected

  functionality of a = fully distributed mobility management system. =  The

  comparison is made = taking into account the identified = DMM

  requirements.

=

 

 

 

 

The IETF = Secretariat

 

_______________________________________________

dmm mailing = list

dmm@ietf.org

https://www.ietf.org/mailman/listinfo/dmm




--

------
Best Regards,
Dapeng = Liu
_______________________________________________
dmm mailing = list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

 



 

--

------
Best = Regards,
Dapeng Liu =

 

<= p class=3DMsoNormal>

 

--

------
Best = Regards,
Dapeng Liu

 

------=_NextPart_000_0199_01CE849C.17101E60-- From pierrick.seite@orange.com Fri Jul 19 01:32:27 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 565BC21E810A for ; Fri, 19 Jul 2013 01:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 92E8gJDf29EV for ; Fri, 19 Jul 2013 01:32:22 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id ED19921E80C2 for ; Fri, 19 Jul 2013 01:32:21 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 16F1426443C; Fri, 19 Jul 2013 10:32:20 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id F0B264C024; Fri, 19 Jul 2013 10:32:19 +0200 (CEST) Received: from PEXCVZYM12.corporate.adroot.infra.ftgroup ([fe80::81f:1640:4749:5d13]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Fri, 19 Jul 2013 10:32:19 +0200 From: To: Alper Yegin , Liu Dapeng Thread-Topic: [DMM] New Version Notification for draft-ietf-dmm-best-practices-gap-analysis-01.txt Thread-Index: AQHOg49FVM0MQTZoZkKUa1Q61U2vcJlrpsHQ Date: Fri, 19 Jul 2013 08:32:18 +0000 Message-ID: <25729_1374222740_51E8F994_25729_930_1_81C77F07008CA24F9783A98CFD706F7110FFE6@PEXCVZYM12.corporate.adroot.infra.ftgroup> References: <28407EEF-BFB9-47A2-A562-DCEF8BCDC1CF@yegin.org> <8CC62269-8458-4911-8AFC-B01314BAEC90@yegin.org> In-Reply-To: <8CC62269-8458-4911-8AFC-B01314BAEC90@yegin.org> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.3] Content-Type: multipart/alternative; boundary="_000_81C77F07008CA24F9783A98CFD706F7110FFE6PEXCVZYM12corpora_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.6.28.101520 Cc: dmm Subject: Re: [DMM] New Version Notification for draft-ietf-dmm-best-practices-gap-analysis-01.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 08:32:27 -0000 --_000_81C77F07008CA24F9783A98CFD706F7110FFE6PEXCVZYM12corpora_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Please see comments inline. BR, Pierrick De : dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] De la part de Alper= Yegin Envoy=E9 : jeudi 18 juillet 2013 10:17 =C0 : Liu Dapeng Cc : dmm Objet : Re: [DMM] New Version Notification for draft-ietf-dmm-best-practice= s-gap-analysis-01.txt Hi Dapeng, Multiple IP address management: ability of the mobile node to simultaneously use multiple IP addresses and select the best one (from an anchoring point of view) to use on a per-session/ application/service basis. Depending on the mobile node support, this functionality might require more or less support from the network side. This is typically the role of a connection manager. I'm not sure if this is really a connection manager issue. This is more of = a source address selection issue. [Dapeng] Yes, application and OS protocol stack can also take the role of c= hoosing source IP address. We will update this statement accordingly. Alper> OK. But I still don't think connection manager does that. As far as = I know, connection manager deals with choosing which network the IP stack s= hould connect. Does it also control which one of the multiple IP addresses = available on the IP stack is chosen by the applications when they connect()= /sendmsg(), etc.? [Pierrick] Actually, the connection manager does not select the source addr= ess but is expected to configure/manage the source address selection mechan= isms of the IP stack. Anyway, you're right, most of current connection mana= ger doesn't manage IP source selection. However, these connection managers = do not deal with DMM use-cases... Mobility management and traffic redirection should only be triggered due to IP mobility reasons, that is when the MN moves from the point of attachment where the IP flow was originally initiated. Mobility management and traffic redirection may also be triggered due to lo= ad balancing. Maybe we should acknowledge such non-mobility related trigger= s, and state that they are outside the scope of this document. [Dapeng] I am not sure whether there is a case that mobility management is = triggered due to load balancing. Could you help to give an example? Alper> I was referring to forcing the MN to change its HA when the currentl= y used HA is overloaded. [Pierrick] I agree, various events can trigger mobility. Maybe we can rewor= d as s/when the MN moves from the point of attachment/ when the MN changes = the point of attachment Should we described the terms IP session continuity and IP address reachabi= lity? This document is solely focusing on the former, we should state that. [Dapeng] For "IP address reachability", you mean the case that session is i= nitiated from Internet toward to the MN? Alper> Yes. I am not sure whether it should be in the scope of mobility management. For= example, RFC5555 does not discuss this case. Alper> It's part of "mobility management". Mobile IP and its variants suppo= rt that. The case where it is not supported is when the home address keeps changing = (e.g., dynamically anchoring and re-anchoring) -- in which case the MN does= not have stable IP address to stay "reachable". When doing the gap analysis, we better break down the benefits we are seeki= ng and evaluate existing solutions with respect to them (e.g., signaling re= duction, use of most direct data-path, etc. ). For example, regular use of = HMIP helps with the former, but not the latter. But, using RCoA as source a= ddress helps with both (but it has other issues -- when MN moves outside th= e local domain). [Dapeng] We already done that in section 5.2. Do you have more column want = to add in table 1? Alper> Dapeng, I don't see section 5.2 or table 1 in http://www.ietf.org/id= /draft-ietf-dmm-best-practices-gap-analysis-01.txt Alper Thanks, Dapeng Liu Alper On Jun 27, 2013, at 1:48 PM, Liu Dapeng wrote: Hello folks: To make good progress in Berlin meeting, it is better for us to start discussion and resolve comments in the list now. Please help to review and feel free to send comments. quick summary of the draft: ----- Section 4 'DMM practice' mainly analyses the mobility deployment practice in WLAN and 3GPP network. Both client-based and network-based mobility protocols are discussed. Section 5 'Gap analysis' tentatively discusses the gaps. Please have a look whether you agree on those gaps and whether you want to propose any new ones. Any input from the group will be welcomed. Thanks, Dapeng Liu 2013/6/17 Zuniga, Juan Carlos >: Hi all, We have posted an updated version of the current practices and gap analysis= draft. We would like to make one more update before Berlin, so your commen= ts and feedback are very welcome. Regards, Juan Carlos et al. -----Original Message----- From: internet-drafts@ietf.org [mailto:int= ernet-drafts@ietf.org] Sent: Monday, June 17, 2013 11:07 AM To: Carlos J. Bernardos; H Anthony Chan; Zuniga, Juan Carlos; Anthony Chan;= Dapeng Liu; Zuniga, Juan Carlos; Pierrick Seite Subject: New Version Notification fordraft-ietf-dmm-best-practices-gap-anal= ysis-01.txt A new version of I-D, draft-ietf-dmm-best-practices-gap-analysis-01.txt has been successfully submitted by Dapeng Liu and posted to the IETF repository. Filename: draft-ietf-dmm-best-practices-gap-analysis Revision: 01 Title: Distributed Mobility Management: Current practices and gap= analysis Creation date: 2013-06-17 Group: dmm Number of pages: 21 URL: http://www.ietf.org/internet-drafts/draft-ietf-dmm-best-pr= actices-gap-analysis-01.txt Status: http://datatracker.ietf.org/doc/draft-ietf-dmm-best-practi= ces-gap-analysis Htmlized: http://tools.ietf.org/html/draft-ietf-dmm-best-practices-g= ap-analysis-01 Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dmm-best-pra= ctices-gap-analysis-01 Abstract: The present document analyses deplyment practices of existing mobility protocols in a distributed mobility management environment. It also identifies some limitations compared to the expected functionality of a fully distributed mobility management system. The comparison is made taking into account the identified DMM requirements. The IETF Secretariat _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm -- ------ Best Regards, Dapeng Liu _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm -- ------ Best Regards, Dapeng Liu ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_81C77F07008CA24F9783A98CFD706F7110FFE6PEXCVZYM12corpora_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 <= /p>

Please see= comments inline.

 = ;

BR,

Pierrick

 = ;

De : dmm-= bounces@ietf.org [mailto:dmm-bounces@ietf.org] De la part de Alper Yegin
Envoy=E9 : jeudi 18 juillet 2013 10:17
=C0 : Liu Dapeng
Cc : dmm
Objet : Re: [DMM] New Version Notification for draft-ietf-dmm-b= est-practices-gap-analysis-01.txt

 

Hi Dapeng,

 

      Multiple IP address management: ability of the mobile= node to

      simultaneously use multiple IP addresses and select t= he best one

      (from an anchoring point of view) to use on a per-ses= sion/

      application/service basis.  Depending on the mob= ile node support,

      this functionality might require more or less support= from the

      network side.  This is typically the role of a c= onnection manager.

 

I'm not sure if this is really a connection manager issue. This is more of= a source address selection issue.

 

[Dapeng] Yes, application and OS protocol stack can = also take the role of choosing source IP address. We will update this = statement accordingly. 

 

 

Alper> OK. But I still don't think connection man= ager does that. As far as I know, connection manager deals with choosing wh= ich network the IP stack should connect. Does it also control which one of = the multiple IP addresses available on the IP stack is chosen by the applications when they connect()/sendmsg(), = etc.?

 

[Pierri= ck] Actually, the connection manager does not select the source address but= is expected to configure/manage the source address selection mechanisms of= the IP stack. Anyway, you’re right, most of current connection manager doesn’t manage IP source selection. Ho= wever, these connection managers do not deal with DMM use-cases…

 

       Mobility management and traffic = redirection should only be

       triggered due to IP mobility rea= sons, that is when the MN moves

       from the point of attachment where the IP flow = was originally

       initiated.

 

Mobility management and traffic redirection may also be triggered due to l= oad balancing. Maybe we should acknowledge such non-mobility related trigge= rs, and state that they are outside the scope of this document.

 

[Dapeng] I am not sure whether there is a case that = mobility management is triggered due to load balancing. Could you= help to give an example?

 

Alper> I was referring to forcing the MN to chang= e its HA when the currently used HA is overloaded. 

 

[Pierri= ck] I agree, various events can trigger mobility. Maybe we can reword as s/= = when the MN moves from the point of attachment/ when the MN changes the point of attachment

=

 

 

Should we described the terms IP session continuity and IP = address reachability? This document is solely focusing on the former, we should state= that.

 

[Dapeng] For "IP address reachability", yo= u mean the case that session is initiated from Internet toward to the MN?

 

Alper> Yes.



I am not sure whether it should be in the scope of m= obility management. For example, RFC5555 does not discuss this case.

 

Alper> It's part of "mobility management&quo= t;. Mobile IP and its variants support that. 

The case where it is not supported is when the home = address keeps changing (e.g., dynamically anchoring and re-anchoring) -- in= which case the MN does not have stable IP address to stay "reachable&= quot;. 



 

When doing the gap analysis, we better break down the benefits we are seek= ing and evaluate existing solutions with respect to them (e.g., signaling r= eduction, use of most direct data-path, etc. ). For example, regular use of HMIP helps with the former, but not th= e latter. But, using RCoA as source address helps with both (but it has oth= er issues -- when MN moves outside the local domain).

 

[Dapeng] We already done that in section 5.2. Do you= have more column want to add in table 1?

 

Alper> Dapeng, I don't see section 5.2 or table 1= in http://www.ietf.org/id/draft-ietf-dmm-best-practices-gap= -analysis-01.txt

 

Alper

 



 

Thanks,

Dapeng Liu

    

 

Alper

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

On Jun 27, 2013, at 1:48 PM, Liu Dapeng wrote:<= /o:p>



Hello folks:

To make good progress in Berlin meeting, it is better for us to start
discussion and resolve comments in the list now. Please help to review
and feel free to send comments.

quick summary of the draft:
-----
Section 4 'DMM practice' mainly analyses the mobility deployment
practice in WLAN and 3GPP network. Both client-based and network-based
mobility protocols are discussed.

Section 5 'Gap analysis' tentatively discusses the gaps. Please have a
look whether you agree on those gaps and whether you want to propose
any new ones. Any input from the group will be welcomed.

Thanks,
Dapeng Liu

2013/6/17 Zuniga, Juan Carlos <JuanCarlos.Zuniga@interdigital.com>:<= br>

Hi all,

 

We have posted an updated version of the current pra= ctices and gap analysis draft. We would like to make one more update before= Berlin, so your comments and feedback are very welcome.

 

Regards,

 

Juan Carlos et al.

 

-----Original Message-----

From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]

Sent: Monday, June 17, 2013 11:07 AM

To: Carlos J. Bernardos; H Anthony Chan; Zuniga, Jua= n Carlos; Anthony Chan; Dapeng Liu; Zuniga, Juan Carlos; Pierrick Seite

Subject: New Version Notification fordraft-ietf-dmm-= best-practices-gap-analysis-01.txt

 

 

A new version of I-D, draft-ietf-dmm-best-practices-= gap-analysis-01.txt

has been successfully submitted by Dapeng Liu and po= sted to the

IETF repository.

 

Filename:        = draft-ietf-dmm-best-practices-gap-analysis

Revision:        = 01

Title:        &nb= sp;  Distributed Mobility Management: Current practices and gap a= nalysis

Creation date:   2013-06-17

Group:        &nb= sp;  dmm

Number of pages: 21

URL:         = ;    http://ww= w.ietf.org/internet-drafts/draft-ietf-dmm-best-practices-gap-analysis-01.tx= t

Status:        &n= bsp; http://datatracker.ietf.org/doc/dra= ft-ietf-dmm-best-practices-gap-analysis

Htmlized:        = http://tools.ietf.org/html/draft-ietf-dmm-best-= practices-gap-analysis-01

Diff:        &nbs= p;   http://www.ietf.org= /rfcdiff?url2=3Ddraft-ietf-dmm-best-practices-gap-analysis-01

 

Abstract:

  The present document analyses deplyment = practices of existing

  mobility protocols in a distributed mobi= lity management environment.

  It also identifies some limitations comp= ared to the expected

  functionality of a fully distributed mob= ility management system.  The

  comparison is made taking into account t= he identified DMM

  requirements.

 

 

 

 

The IETF Secretariat

 

_______________________________________________=

dmm mailing list

dm= m@ietf.org

https://www.ietf.org/mailman/listinfo/dmm




--

------
Best Regards,
Dapeng Liu
_______________________________________________
dmm mailing list
dmm@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/dmm

 



 

--

------
Best Regards,
Dapeng Liu

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_81C77F07008CA24F9783A98CFD706F7110FFE6PEXCVZYM12corpora_-- From alper.yegin@yegin.org Fri Jul 19 04:56:37 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E36311E8105 for ; Fri, 19 Jul 2013 04:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4uTFYg21USvu for ; Fri, 19 Jul 2013 04:56:32 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id 21A1911E810E for ; Fri, 19 Jul 2013 04:56:32 -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=mrus4) with ESMTP (Nemesis) id 0M8lzI-1UqD813DTA-00Ct55; Fri, 19 Jul 2013 07:56:30 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_2D6A7ED6-1422-4A6E-8BB5-A032D1959EF8" From: Alper Yegin In-Reply-To: <019801ce8450$a7231f30$f5695d90$@samsung.com> Date: Fri, 19 Jul 2013 14:56:24 +0300 Message-Id: <941832E9-5F36-485B-9A8F-1F1963A26541@yegin.org> References: <28407EEF-BFB9-47A2-A562-DCEF8BCDC1CF@yegin.org> <8CC62269-8458-4911-8AFC-B01314BAEC90@yegin.org> <9E1C1DEC-DD24-42C2-965A-3294BDE43BAB@yegin.org> <019801ce8450$a7231f30$f5695d90$@samsung.com> To: "Park, Jungshin" X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:PDNjTxHlm8w2aEoQgpOBJErIMjhE4o5Qkr59rKwLxQY R7T0zikvU4wdjb6sn/2mjUdus9iDf9IgPQAUQMJ7Y3Fa8woOjS Vo4BPyAZCTRA4obvK6vXK9F3J0CYsEJ4uXyezU31xPMtgvBcaG 7A+KGiDlJvsSobebBtf2OOQS6SD6Ar05BSswm/GguK1/COoOIu GxWN5oRTl5gbyYg06mjEmCQfOGAOsgrXsQBmTrMFJoT3WEeSko kE1YULQ9ozzIpJ/K5dsIblHQnQTkub7/EvH9ewMAFgl/N/nPYL ZEX/XpY+WYDriMIp0Fv8lYogNX51WZHTgXsZNyMJ2wk3n/yBEn DRM9PUDR6PFyaiGlr1+fgAxrUK1uQOU3v1Bnsf/YBwTMfj72Q+ X14Fv5KBR1jew== Cc: 'dmm' Subject: Re: [DMM] New Version Notification for draft-ietf-dmm-best-practices-gap-analysis-01.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jul 2013 11:56:37 -0000 --Apple-Mail=_2D6A7ED6-1422-4A6E-8BB5-A032D1959EF8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Jungshin, Yes, you are right. That language is somewhat limiting. In fact, I'd say we don't even need to define the term "IP mobility" in = this document. I.e., let's remove the part that starts with "that is=85." Or, give a reference to where that term is defined. (it must be = somewhere, after so many years of working on it and so many RFCs = floating around :-) Alper On Jul 19, 2013, at 10:21 AM, Park, Jungshin wrote: > Hi Guys, > =20 > Sorry to jump in. > Will it be safe saying that =93=85 only within the context of IP = mobility, that is when the MN movesfrom the point of attachment where = the IP flow was originally initiated=94 ? > It sounds like we are going to handle only the first movement of MN = for each flow. > I=92d like to double-check if it is our agreement. > =20 > Regards, > Jungshin > =20 > From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of = Alper Yegin > Sent: Friday, July 19, 2013 4:02 PM > To: Liu Dapeng > Cc: dmm > Subject: Re: [DMM] New Version Notification for = draft-ietf-dmm-best-practices-gap-analysis-01.txt > =20 > Dapeng, > =20 > =20 > Mobility management and traffic redirection should only be > triggered due to IP mobility reasons, that is when the MN moves > from the point of attachment where the IP flow was originally > initiated. > =20 > Mobility management and traffic redirection may also be triggered due = to load balancing. Maybe we should acknowledge such non-mobility related = triggers, and state that they are outside the scope of this document. > =20 > [Dapeng] I am not sure whether there is a case that mobility = management is triggered due to load balancing. Could you help to give an = example? > =20 > Alper> I was referring to forcing the MN to change its HA when the = currently used HA is overloaded.=20 > =20 > =20 > [Dapeng] OK, That is the HA redirection case. How about changing the = word "should only" to "normally"? > =20 > =20 > I'd recommend something like this: > =20 > This document considers use of mobility management and traffic = redirection=20 > only within the context of IP mobility, that is when the MN = moves > from the point of attachment where the IP flow was originally > initiated. > =20 >=20 >=20 > =20 > =20 > Should we described the terms IP session continuity and IP address = reachability? This document is solely focusing on the former, we should = state that. > =20 > [Dapeng] For "IP address reachability", you mean the case that session = is initiated from Internet toward to the MN? > =20 > Alper> Yes. >=20 >=20 > I am not sure whether it should be in the scope of mobility = management. For example, RFC5555 does not discuss this case. > =20 > Alper> It's part of "mobility management". Mobile IP and its variants = support that.=20 > The case where it is not supported is when the home address keeps = changing (e.g., dynamically anchoring and re-anchoring) -- in which case = the MN does not have stable IP address to stay "reachable".=20 > =20 > [Dapeng] The DMM charter says:=20 > =20 > "Although the maintenance of stable home address(es) and/or = prefix(es)=20 > and upper level sessions is a desirable goal when mobile hosts/routers=20= > change their point of attachment to the Internet, it is not a strict=20= > requirement"=20 > =20 > So IP address reachability may not in the scope. > =20 > Even though IP address reachability is within the scope of "mobility = management" concept in general, DMM WG charter does not mandate it be = handled in its solutions. Yes. > =20 > =20 > =20 >=20 >=20 > =20 > =20 > When doing the gap analysis, we better break down the benefits we are = seeking and evaluate existing solutions with respect to them (e.g., = signaling reduction, use of most direct data-path, etc. ). For example, = regular use of HMIP helps with the former, but not the latter. But, = using RCoA as source address helps with both (but it has other issues -- = when MN moves outside the local domain). > =20 > [Dapeng] We already done that in section 5.2. Do you have more column = want to add in table 1? > =20 > Alper> Dapeng, I don't see section 5.2 or table 1 in = http://www.ietf.org/id/draft-ietf-dmm-best-practices-gap-analysis-01.txt > =20 > =20 > [Dapeng] It is in the 00 version = (http://tools.ietf.org/html/draft-ietf-dmm-best-practices-gap-analysis-00#= section-5.1.2). In this update version, the table is not included yet. = We can include it if folks believe it is useful. But we need have = consensus on the conclusion of the table. =20 > =20 > Thanks for your valuable comments. > =20 > =20 > Cheers, > =20 > Alper > =20 > =20 >=20 >=20 > Dapeng Liu > =20 > Alper > =20 >=20 >=20 > =20 > Thanks, > Dapeng Liu > =20 > =20 > Alper > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > On Jun 27, 2013, at 1:48 PM, Liu Dapeng wrote: >=20 >=20 > Hello folks: >=20 > To make good progress in Berlin meeting, it is better for us to start > discussion and resolve comments in the list now. Please help to review > and feel free to send comments. >=20 > quick summary of the draft: > ----- > Section 4 'DMM practice' mainly analyses the mobility deployment > practice in WLAN and 3GPP network. Both client-based and network-based > mobility protocols are discussed. >=20 > Section 5 'Gap analysis' tentatively discusses the gaps. Please have a > look whether you agree on those gaps and whether you want to propose > any new ones. Any input from the group will be welcomed. >=20 > Thanks, > Dapeng Liu >=20 > 2013/6/17 Zuniga, Juan Carlos : >=20 > Hi all, > =20 > We have posted an updated version of the current practices and gap = analysis draft. We would like to make one more update before Berlin, so = your comments and feedback are very welcome. > =20 > Regards, > =20 > Juan Carlos et al. > =20 > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Monday, June 17, 2013 11:07 AM > To: Carlos J. Bernardos; H Anthony Chan; Zuniga, Juan Carlos; Anthony = Chan; Dapeng Liu; Zuniga, Juan Carlos; Pierrick Seite > Subject: New Version Notification = fordraft-ietf-dmm-best-practices-gap-analysis-01.txt > =20 > =20 > A new version of I-D, = draft-ietf-dmm-best-practices-gap-analysis-01.txt > has been successfully submitted by Dapeng Liu and posted to the > IETF repository. > =20 > Filename: draft-ietf-dmm-best-practices-gap-analysis > Revision: 01 > Title: Distributed Mobility Management: Current practices = and gap analysis > Creation date: 2013-06-17 > Group: dmm > Number of pages: 21 > URL: = http://www.ietf.org/internet-drafts/draft-ietf-dmm-best-practices-gap-anal= ysis-01.txt > Status: = http://datatracker.ietf.org/doc/draft-ietf-dmm-best-practices-gap-analysis= > Htmlized: = http://tools.ietf.org/html/draft-ietf-dmm-best-practices-gap-analysis-01 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dmm-best-practices-gap-analy= sis-01 > =20 > Abstract: > The present document analyses deplyment practices of existing > mobility protocols in a distributed mobility management environment. > It also identifies some limitations compared to the expected > functionality of a fully distributed mobility management system. = The > comparison is made taking into account the identified DMM > requirements. > =20 > =20 > =20 > =20 > The IETF Secretariat > =20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm >=20 >=20 >=20 > --=20 >=20 > ------ > Best Regards, > Dapeng Liu > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > =20 >=20 >=20 > =20 > --=20 >=20 > ------ > Best Regards, > Dapeng Liu > =20 >=20 >=20 > =20 > --=20 >=20 > ------ > Best Regards, > Dapeng Liu --Apple-Mail=_2D6A7ED6-1422-4A6E-8BB5-A032D1959EF8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 Hi Jungshin,

Yes, you are right. = That language is somewhat limiting.

In fact, = I'd say we don't even need to define the term "IP mobility" in this = document. I.e., let's remove the part that starts with "that = is=85."
Or, give a reference to where that term is defined. = (it must be somewhere, after so many years of working on it and so many = RFCs floating around = :-)

Alper




On Jul 19, 2013, at 10:21 AM, Park, = Jungshin wrote:

Will it be safe saying that =93=85   the MN movesfrom the point of = attachment where the IP flow was  i=94 = ?
From: dmm-bounces@ietf.org = [mailto:dmm-bounces@ietf.org] On Behalf Of Alper = Yegin
Sent: Friday, July 19, 2013 4:02 = PM
To: Liu = Dapeng
Cc: dmm
Subject: Re: [DMM] New Version = Notification for = draft-ietf-dmm-best-practices-gap-analysis-01.txt
<= /div>
 
Dapeng,
 
  =      Mobility management and traffic redirection should = only be
     =   triggered due to IP mobility reasons, that is when the MN = moves
     =   from the point of attachment where the IP flow was = originally
 
Mobility management and traffic redirection may = also be triggered due to load balancing. Maybe we should acknowledge = such non-mobility related triggers, and state that they are outside the = scope of this = document.
 
[Dapeng] I am not sure whether = there is a case that mobility management is triggered due to = load balancing. Could you help to give an = example?
=
 
Alper> I was referring to = forcing the MN to change its HA when the currently used HA is = overloaded. 
 
 
[Dapeng] OK, That is the HA = redirection case.  How about changing the word "should only" to = "normally"?
 
 
I'd recommend something like = this:
 
      =  This document considers use of mobility management and traffic = redirection 
      =  only within the context of IP mobility, that is when the MN = moves
     =   initiated.
 


 
Should = we described the terms IP session continuity and IP address = reachability? This document is solely focusing on the former, we should = state that.
[Dapeng] For "IP address = reachability", you mean the case that session is initiated from Internet = toward to the = MN?
 
Alper> = Yes.


I am not sure whether it should be = in the scope of mobility management. For example, RFC5555 does not = discuss this = case.
 
Alper> It's part of "mobility = management". Mobile IP and its variants support = that. 
The case where it is not supported is when the home = address keeps changing (e.g., dynamically anchoring and re-anchoring) -- = in which case the MN does not have stable IP address to stay = "reachable". 
 
[Dapeng] The DMM charter = says: 
 
 "
and upper level sessions is a desirable goal when mobile = hosts/routers 
change their point of attachment to the Internet, = it is not a strict 
requirement" 
 
So IP address reachability may not = in the scope.
 
Even though IP address = reachability is within the scope of "mobility management" concept in = general, DMM WG charter does not mandate it be handled in its solutions. = Yes.
 
 
 


 
 
When doing the gap analysis, we better break = down the benefits we are seeking and evaluate existing solutions with = respect to them (e.g., signaling reduction, use of most direct = data-path, etc. ). For example, regular use of HMIP helps with the = former, but not the latter. But, using RCoA as source address helps with = both (but it has other issues -- when MN moves outside the local = domain).
 
[Dapeng] We already done that in = section 5.2. Do you have more column want to add in table = 1?
 
Alper> Dapeng, I don't see = section 5.2 or table 1 in http://www.ietf.org/id/draft-ietf-dmm-best-practices-gap-analysis-01.txt=
 
[Dapeng] It is in the 00 version = ( 






 
<= /blockquote>
has been successfully submitted by = Dapeng Liu and posted to = the
 
Abstract:
  The present document analyses deplyment = practices of existing
  mobility protocols in a distributed mobility = management environment.
  It also identifies some limitations compared = to the expected
  functionality of a fully distributed mobility = management system. =  The
  comparison is made taking into account the = identified DMM
  requirements.
 
 
 
 
The IETF = Secretariat
 
_______________________________________________<= /span>
dmm mailing = list





= = --Apple-Mail=_2D6A7ED6-1422-4A6E-8BB5-A032D1959EF8-- From alper.yegin@yegin.org Mon Jul 22 05:28:11 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEC0821F9D87 for ; Mon, 22 Jul 2013 05:28:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KRmSY4T+MCQb for ; Mon, 22 Jul 2013 05:28:05 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id CE95721F96A7 for ; Mon, 22 Jul 2013 05:27:59 -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 0MNJAX-1V3C5r46sD-0070PR; Mon, 22 Jul 2013 08:27:57 -0400 From: Alper Yegin Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_D78CDCE0-46A0-483A-9B86-BA2F23DA59D6" Date: Mon, 22 Jul 2013 15:27:53 +0300 In-Reply-To: <20130711204304.11650.60921.idtracker@ietfa.amsl.com> To: dmm References: <20130711204304.11650.60921.idtracker@ietfa.amsl.com> Message-Id: <2291EFAE-06D5-4E04-B0C8-81355519C46C@yegin.org> X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:z5xu5oRkHoVWGKqBd4aci/f7lmyPs4QIMh+WC/9GQwW 1CwdDCvehIir5bwX+U1JTjrFu68/IX6jQ/oP7A0vSgurLZF5u0 R6pxCUa5jRHNCDG6xXvt10hUrAAAzKgTNmJW7OPrCzUxMWan9u DBk9ChDon55N5W+JIpA+OU9imbb8JpKvPsnUIl0jyOZJh5KfJD 1SGE8j4HWAzrAtsQlcTbvQS1ig8cQ3bnNfp75LfXmyNxj6oKgS QhW9AzOxK1SnMIKAJyQsQXYwMr6eTUuSbDxmrWzwFSOXxvc4jD gTWgWHIqAyPPp0rsXGxx52GspM6w+j2Nnh5v7rsP7dMQzzEO/g bR8aV5z1eCpl1Wc3kMRxWBpD+qlPjLQLFOuMU5IHuUca7ssAz6 +pyT9s4FMAzkg== Subject: Re: [DMM] I-D Action: draft-bernardos-dmm-pmip-02.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 12:28:11 -0000 --Apple-Mail=_D78CDCE0-46A0-483A-9B86-BA2F23DA59D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello folks, Few comments on this I-D: For next MN's movements the process is repeated except for the number of P-MAARs involved, that rises accordingly to the number of prefixes that the MN wishes to maintain. Indeed, once the CMD receives the first PBU from the new S-MAAR, it forwards copies of the PBU to all the P-MAARs indicated in the BCE as current P-CoA (i.e., the MAAR prior to handover) and in the P-MAARs list. They reply with a PBA to the CMD, which aggregates them into a single one to notify the S-MAAR, that finally can establish the tunnels with the P-MAARs. Why not let the CMD send PBAs as it receives them from P-MAARs? That way a delayed (or even dead!) P-MAAR would not be holding up other = P-MAAR operations. In "CMD as MAAR locator" case, the P-MAAR sends PBAs to CMD and S-MAAR = separately. This could lead to some state inconsistency issue, right? = S-MAAR and CMD may land on a different state if the result of their = processing is different. In "CMD as MAAR proxy" case, CMD responds to S-MAAR before P-MAAR = processes and responds to the CMD. If the P-MAAR rejects the PBU, then = this would lead to state inconsistency in the system. Cheers, Alper --Apple-Mail=_D78CDCE0-46A0-483A-9B86-BA2F23DA59D6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hello = folks,

Few comments on this = I-D:


   For next MN's = movements the process is repeated except for the number
   that the MN wishes to = maintain.  Indeed, once the CMD receives the
   the P-MAARs indicated in the BCE as = current P-CoA (i.e., the MAAR
   prior to handover) and = in the P-MAARs list.  They reply with a PBA to
   S-MAAR, that finally can establish = the tunnels with the P-MAARs.


Why = not let the CMD send PBAs as it receives them from P-MAARs?
That = way a delayed (or even dead!) P-MAAR would not be holding up other = P-MAAR operations.

In "CMD as MAAR locator" case, the = P-MAAR sends PBAs to CMD and S-MAAR separately. This could lead to some = state inconsistency issue, right? S-MAAR and CMD may land on a different = state if the result of their processing is different.
In "CMD as MAAR proxy" case, CMD responds to = S-MAAR before P-MAAR processes and responds to the CMD. If the P-MAAR = rejects the PBU, then this would lead to state inconsistency in the = system.

Cheers,
Alper
To: "'Alper Yegin'" References: <20130711204304.11650.60921.idtracker@ietfa.amsl.com> <2291EFAE-06D5-4E04-B0C8-81355519C46C@yegin.org> In-Reply-To: <2291EFAE-06D5-4E04-B0C8-81355519C46C@yegin.org> Date: Mon, 22 Jul 2013 19:36:51 +0200 Message-ID: <00a701ce8702$0d4c9490$27e5bdb0$@giust@imdea.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A8_01CE8712.D0D56490" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac6G1vHoLq6bJlvtTD6wzTuPA+dL+gAKPPBA Content-Language: es Cc: 'dmm' Subject: Re: [DMM] I-D Action: draft-bernardos-dmm-pmip-02.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jul 2013 17:37:18 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_00A8_01CE8712.D0D56490 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Alper and all, Thanks for your feedback on the draft. Please see some considerations inline. Best, Fabio From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of Alper Yegin Sent: lunes, 22 de julio de 2013 14:28 To: dmm Subject: Re: [DMM] I-D Action: draft-bernardos-dmm-pmip-02.txt Hello folks, Few comments on this I-D: For next MN's movements the process is repeated except for the number of P-MAARs involved, that rises accordingly to the number of prefixes that the MN wishes to maintain. Indeed, once the CMD receives the first PBU from the new S-MAAR, it forwards copies of the PBU to all the P-MAARs indicated in the BCE as current P-CoA (i.e., the MAAR prior to handover) and in the P-MAARs list. They reply with a PBA to the CMD, which aggregates them into a single one to notify the S-MAAR, that finally can establish the tunnels with the P-MAARs. Why not let the CMD send PBAs as it receives them from P-MAARs? That way a delayed (or even dead!) P-MAAR would not be holding up other P-MAAR operations. [FG:] This observation was indeed raised in the -00 draft version, and then removed to keep the document simpler. The fastest way to proceed would be what you suggest: the CMD sends the PBAs as it receives them from the P-MAARs. However, this method incurs in additional control messages. A possible solution that mitigates the number of control messages could be saving the PBAs in a buffer and then sending them in a batch at regular (or incremental) intervals In "CMD as MAAR locator" case, the P-MAAR sends PBAs to CMD and S-MAAR separately. This could lead to some state inconsistency issue, right? S-MAAR and CMD may land on a different state if the result of their processing is different. [FG:] In general by breaking the classic update/ack scheme we can have inconsistent states in the CMD and MAARs. The draft at the moment does not deal with how to recover from such situation. However, the periodic signaling sent by the S-MAAR to refresh the binding state can be exploited to detect and fix such problem. In "CMD as MAAR proxy" case, CMD responds to S-MAAR before P-MAAR processes and responds to the CMD. If the P-MAAR rejects the PBU, then this would lead to state inconsistency in the system. [FG:] The CMD waits for a PBA from the P-MAAR, so if the PBU is rejected, the CMD eventually finds out the inconsistency and can take the appropriate action. The draft could be extended defining such action (for instance a PBU to the S-MAAR to notify the correct state). In all cases, if a P-MAAR rejects the PBU, then no mobility support can be provided to the MN's old sessions, both if the states in the MAARs are consistent or not. Cheers, Alper ------=_NextPart_000_00A8_01CE8712.D0D56490 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Alper and all,

 

Thanks for your feedback on the draft. Please see some considerations = inline.

 

Best,

Fabio

 

From:= = dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of = Alper Yegin
Sent: lunes, 22 de julio de 2013 = 14:28
To: dmm
Subject: Re: [DMM] I-D Action: = draft-bernardos-dmm-pmip-02.txt

 

Hello = folks,

 

Few comments on this I-D:

 

 

   For next = MN's movements the process is repeated except for the = number

   of P-MAARs = involved, that rises accordingly to the number of = prefixes

   that the MN = wishes to maintain.  Indeed, once the CMD receives = the

   first PBU = from the new S-MAAR, it forwards copies of the PBU to = all

   the P-MAARs = indicated in the BCE as current P-CoA (i.e., the = MAAR

   prior to = handover) and in the P-MAARs list.  They reply with a PBA = to

   the CMD, = which aggregates them into a single one to notify = the

   S-MAAR, that = finally can establish the tunnels with the = P-MAARs.

 

 

Why not let the CMD send = PBAs as it receives them from = P-MAARs?

That way a delayed (or = even dead!) P-MAAR would not be holding up other P-MAAR = operations.

 

[FG:] This observation was indeed raised in the –00 draft = version, and then removed to keep the document simpler. = The fastest way to proceed would be what you suggest: the CMD sends = the PBAs as it receives them from the = P-MAARs.

However, this method incurs in additional control messages. A = possible solution that mitigates the number of control messages could be = saving the PBAs in a buffer and then sending them in a batch at regular = (or incremental) intervals

 

 

In "CMD as MAAR = locator" case, the P-MAAR sends PBAs to CMD and S-MAAR separately. = This could lead to some state inconsistency issue, right? S-MAAR and CMD = may land on a different state if the result of their processing is = different.

 

[FG:] In general by breaking the classic update/ack scheme we can = have inconsistent states in the CMD and MAARs. = The draft at the moment does not deal with how to recover from such = situation. However, the periodic signaling sent by the S-MAAR to refresh = the binding state can be exploited to detect and fix such = problem.

 

In "CMD = as MAAR proxy" case, CMD responds to S-MAAR before P-MAAR processes = and responds to the CMD. If the P-MAAR rejects the = PBU, then this would lead to state inconsistency in the = system.

 

[FG:] The CMD waits for a PBA from the P-MAAR, so if the PBU is rejected, = the CMD eventually  finds out the inconsistency and can take the = appropriate action. The draft could be extended defining such action = (for instance a PBU to the S-MAAR to notify the correct state). In all = cases, if a P-MAAR rejects the PBU, then no mobility support can be = provided to the MN’s old sessions, both if the states in the MAARs = are consistent or not.

 

Cheers,<= /p>

 

Alper

 

------=_NextPart_000_00A8_01CE8712.D0D56490-- From jouni.nospam@gmail.com Tue Jul 23 15:02:42 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9344111E8289 for ; Tue, 23 Jul 2013 15:02:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSDIzlRDxqTN for ; Tue, 23 Jul 2013 15:02:42 -0700 (PDT) Received: from mail-bk0-x233.google.com (mail-bk0-x233.google.com [IPv6:2a00:1450:4008:c01::233]) by ietfa.amsl.com (Postfix) with ESMTP id CC3B011E811B for ; Tue, 23 Jul 2013 15:02:41 -0700 (PDT) Received: by mail-bk0-f51.google.com with SMTP id ji1so3177137bkc.38 for ; Tue, 23 Jul 2013 15:02:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version:x-mailer; bh=LXcM3W5Wf7enDnltQgNYIc3RAlh4LVnCcJ+XJs2YK+k=; b=bmNm3dKqDVjS9n8+2NfDjEbm15N9yRvx0hAFpcu0IMb74qeqpEnc0KTE1NwVOasDzP N/UqEnAtwTzMcs9+erZHNMmo5G+5Emh3whdrSzHpvruDy0vTUkvTyvl8+aDur5ziSrx8 HaHe0RTlpNPCIejYbEqdpBoIwqGJv9x2ALKIovhishN+DI5NSE/huVZ9M5BE/w4hs1q6 /6NLPB2BlgvtcK3d/gBVAANjN+noa9t5aTucrY4Hxqm22amOMBZQnee9EtUM1Na0j5jF 6bLcI0Fi4NESGevGpst8SM66UgU7JgjJt4u00WW3ctJwkz8T6wEpACFihnQSGl4OYJDm /ifw== X-Received: by 10.204.53.200 with SMTP id n8mr4830676bkg.97.1374616960862; Tue, 23 Jul 2013 15:02:40 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:5c1a:6cb3:3a6f:2dd7? ([2001:1bc8:101:f101:5c1a:6cb3:3a6f:2dd7]) by mx.google.com with ESMTPSA id fc7sm8771223bkc.3.2013.07.23.15.02.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 23 Jul 2013 15:02:40 -0700 (PDT) From: Jouni Korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 24 Jul 2013 01:02:38 +0300 Message-Id: To: "dmm@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [DMM] issue tracker and the requirements draft X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jul 2013 22:02:42 -0000 Folks, The requirements draft still seems to have 11 open tickets: = http://tools.ietf.org/wg/dmm/trac/query?status=3Dnew&status=3Dassigned&sta= tus=3Dreopened&component=3Drequirements Those who recorded the issues should check whether -05 addresses them. - Jouni=20= From jouni.nospam@gmail.com Wed Jul 24 01:32:53 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C547A11E83A5 for ; Wed, 24 Jul 2013 01:32:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYVHWnP24hGV for ; Wed, 24 Jul 2013 01:32:52 -0700 (PDT) Received: from mail-la0-x229.google.com (mail-la0-x229.google.com [IPv6:2a00:1450:4010:c03::229]) by ietfa.amsl.com (Postfix) with ESMTP id 4902711E83AF for ; Wed, 24 Jul 2013 01:32:52 -0700 (PDT) Received: by mail-la0-f41.google.com with SMTP id fn20so93194lab.28 for ; Wed, 24 Jul 2013 01:32:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version:x-mailer; bh=5ZRcDNlOkSeJx8MBt9OOjUpd0fpVveH5px2WqlWcGuk=; b=vlvF/rEEnIVQyzMKLQIAJ6yBdIbIAmPN46cxRRiHRes0IYt6jqNH2e7d+UNlALWBDd 2JCz2ZLEu1/1aukJyJQvdLpoCwAN+ghOP/krtYgkvcv09eWnXawsmrSHmDOCkiLerVRN 5AQBO89tyJFGvOEgWLeLf7TIDP29wa2tO34kw6M0aR+sYzYJwPPzu/+NeQ4NdpErZkN2 e5d2+dBeHV5S4iwT3/e0EyJa+4eQoa5nUSUDpg1SJTXmA1Mxpdu8tUkWFe7b2UV/fb2K lmC5TaBD1gZ/BelGUY0sGi1C9kvzG7lfMxgM4I8vM0MKWZN3wl69TgQtZQJJuao3dgeb Hmbg== X-Received: by 10.112.164.164 with SMTP id yr4mr16089597lbb.88.1374654768745; Wed, 24 Jul 2013 01:32:48 -0700 (PDT) Received: from [192.168.250.198] ([194.100.71.98]) by mx.google.com with ESMTPSA id 8sm14153652lbq.4.2013.07.24.01.32.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Jul 2013 01:32:47 -0700 (PDT) From: Jouni Korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <315CD997-1396-423F-8355-0C17A133FA42@gmail.com> Date: Wed, 24 Jul 2013 11:32:40 +0300 To: "dmm@ietf.org" , Alper Yegin Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [DMM] comments/questions on draft-yegin-dmm-ondemand-mobility-00 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 08:32:53 -0000 Alper, I read the draft and have few quick comments and questions. Interesting draft by the way. In Section 3.1. it says: "- Access Network Anchored Address This type of IP address provides IP session continuity but not IP address reachability." Why is that? What makes IP(v6) address unreachable (I assume from Internet side)? I would like to see the rationale described here for this reachability assertion. Then later in Section 3.1. it says: "The IP address is allocated by a serving IP gateway. When the mobile" I cannot find a proper description what a "serving IP gateway" is and what kind of functions it is supposed to posses. In Section 3.4. there are few things. First, it says: "available set of IP addresses when selecting an address. According to the proposed solution, if the requested type IP address is not available at the time of the request, then the IP stack shall make an attempt to configure one such IP address. The selected IP address" Assuming the address configuration as per SLAAC or DHCPv6 has already taken place within the stack, how the "attempt to configure one such IP address" should be understood? Would it imply signaling towards network or creation of tunnels or what? This is quite unclear to me after reading the draft. Second, it says: "shall be compliant with the requested IP address type, whether it is selected among available addresses or dynamically configured. In the absence of a matching type (because it is not available and not configurable on demand), the source address selection algorithm shall return an empty set." I read this as a change proposal to RFC6724 algorithm.. which part and which rule you intend to modify/add? Since you aim to standards track this part should be described in detail. Last, there is no discussion how the stack/host knows what address in unanchored/access anchored/home anchored. I would like to see some technical discussion how that is accomplished and possibly pointers to existing work on that area if there is some. - Jouni From jouni.nospam@gmail.com Wed Jul 24 01:56:45 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9B3111E83DC for ; Wed, 24 Jul 2013 01:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wSikfVCzcmlI for ; Wed, 24 Jul 2013 01:56:45 -0700 (PDT) Received: from mail-lb0-x22d.google.com (mail-lb0-x22d.google.com [IPv6:2a00:1450:4010:c04::22d]) by ietfa.amsl.com (Postfix) with ESMTP id CDCBC11E83E1 for ; Wed, 24 Jul 2013 01:56:44 -0700 (PDT) Received: by mail-lb0-f173.google.com with SMTP id v1so271541lbd.32 for ; Wed, 24 Jul 2013 01:56:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version:x-mailer; bh=BiuhxmCCMziqxfPQPpaj7BpxU5EAJ7UH1dtGxKpEJS8=; b=i4bmQj87y2/FgiBepcubgKFeJQLxPqHXeTwUcixbJ25JwOgQKKQ6vemmJHaf5pGD/+ 7hR6v+RdVBVaS6NQMfRaT1M1GOJKhv0KAnxW+gphou0tczvZR1gfTkzpwDfoPrav9o2K nKus5BOfMPGb4mz6nWF7XUJbqDsbWLl3F7iLPxPTYkdqPgHLV7BTD0JlhVtgl+czWipS X2icFQNYLTuOzKUX0PU3xbNE6eAngOwo9duW0nS8R3BsvBmj5ntLfibz06/AgXI1bZvA uX7DZmd/1xGqFusMsZwZuU98ulEEbV1t3SxQk5MuRWFl7uUdaZpKIdxFYsZGS33zqa1X sMOA== X-Received: by 10.152.170.197 with SMTP id ao5mr16792889lac.35.1374656203705; Wed, 24 Jul 2013 01:56:43 -0700 (PDT) Received: from [192.168.250.198] ([194.100.71.98]) by mx.google.com with ESMTPSA id 6sm14172024lbu.13.2013.07.24.01.56.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Jul 2013 01:56:43 -0700 (PDT) From: Jouni Korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: Date: Wed, 24 Jul 2013 11:56:42 +0300 To: "dmm@ietf.org" , Alper Yegin Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [DMM] comments/questions of draft-yegin-dmm-cnet-homing-00 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 08:56:45 -0000 Alper, authors, In Section 3. is states: "CHA may be co-located with the CN, or located in the same site as the CN, or located in an ISP serving that site. Not all CNs may be served by a CHA. In case there is no CHA serving the CN, the MN and the CN may communicate using the HoA via the HA. It is expected that CHAs would be deployed for dominant content sites on the Internet (e.g., YouTube, Facebook, Netflix, etc.)" What would be the motivation or business reason for a service/content provider to start offering a mobility anchoring service? High bandwidth sites as listed above would need invest quite much for such a platform. I also started thinking that in general this solution (and quite many other) seem to assume the CN is more or less stationary. How would the CHA concept be affected if the CN is also mobile? Would it allow any benefits over the legacy MIP variants? How would the CHA discovery work in this case? The examples in Sections 3. and 4. show DNS as the discovery mechanism for the CHA. However, there is no real description how the discovery is actually carried out (except conceptual CHA domain name referred in Section 3. Figure 1 step 2). Have you considered other discovery mechanisms than DNS? - Jouni From jouni.nospam@gmail.com Wed Jul 24 05:54:41 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7F1211E80F1 for ; Wed, 24 Jul 2013 05:54:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PKyipNf-xJNg for ; Wed, 24 Jul 2013 05:54:40 -0700 (PDT) Received: from mail-bk0-x236.google.com (mail-bk0-x236.google.com [IPv6:2a00:1450:4008:c01::236]) by ietfa.amsl.com (Postfix) with ESMTP id 3C17611E80E6 for ; Wed, 24 Jul 2013 05:54:39 -0700 (PDT) Received: by mail-bk0-f54.google.com with SMTP id it19so162161bkc.27 for ; Wed, 24 Jul 2013 05:54:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version:x-mailer; bh=ZxwEt75E3ZS4S6WYAiHl9WFO0eIDFQnY92WJCuTXtWY=; b=KdS9BQ7ToaFCgLIgXGKdiQ9njSQ8Slhig7/Q5srfCSQB7godOEmO2cb0AKWikueCNt ZQcFfcmuNZbVemKTAWIquI4arIABi7QmEUyoENbBDVk/4cDNdZ2u5BOJWdvoH0FFrcpP 9sEcGv8t+TXziPjEJhcVAyaF5/pLn43TnZHqF8sytUsIR0lYyw7kl35GG1s1U4+/3o5B U1neKZacH9fyRbgryHxSATxdc6G85rAwm9PbXH6dI9xQvKXZIHcSvCavlXFlLv6TCtlb jZfN8R/OPSeZuhPSs8n+CsMeYsZKOAaK99HdbqBAP7YB3N1Fi9eL/cVEyTtN5h+QV1at saPA== X-Received: by 10.204.54.206 with SMTP id r14mr5426905bkg.120.1374670478655; Wed, 24 Jul 2013 05:54:38 -0700 (PDT) Received: from [188.117.15.108] ([188.117.15.108]) by mx.google.com with ESMTPSA id eu16sm9570509bkc.0.2013.07.24.05.54.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Jul 2013 05:54:38 -0700 (PDT) From: Jouni Korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: <72EF3457-5B8A-4F5C-8BEA-2EDC5DBF850E@gmail.com> Date: Wed, 24 Jul 2013 15:54:36 +0300 To: "dmm@ietf.org" , Dapeng Liu , Juan Carlos Zuniga , "pierrick.seite@orange.com" , h chan , "cjbc@it.uc3m.es Cano" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [DMM] comments on draft-ietf-dmm-best-practices-gap-analysis-01 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 12:54:41 -0000 Authors, I finally read the draft and below are some comments to hopefully help completing and improving the draft. In Section 4.2. it is stated: "view using common and standardized protocols. Since WiFi is the most widely deployed wireless access technology nowadays, we take it as" Do you have some data/reference to backup your claim? In Section 4.2.1. it is stated: "at different point of attachment. However there is no mechanism specified to enable an efficient dynamic discovery of available" I would add a clarification here that there is no such mechanism=20 available within IETF specifications. Other SDOs do have such mechanism (e.g. 3GPP). Furthermore, around the bulleted list for the MIPv6 RO discussion, I = would mention that nothing prevents a MN to use its CoA directly when = communicating CNs on the same link or anywhere in the internet. Of course there is no mobility in that case but it is a valid scenario to mention IMHO (and = also part of our charter). I recon the HMIPv6 text mentions at least the use = of RCoA already. In Section 4.2.2. where the text describes RFC6463, I would also = reference to RFC6097 since that has quite a bit of text regarding the discovery = procedure of the LMA. While I found Section 4.2. good in general I was somehow expecting to = see=20 text regarding MOBIKE (RFC4555). We can safely assume MOBIKE is probably the most deployed client mobility enabling technology out there today. In Section 4.3. it says: "GPRS Tunnelling Protocol (GTP) [3GPP.29.060] is a network-based mobility protocol specified for 3GPP networks (S2a, S2b, S5 and S8 interfaces)." While 29.060 is about GTP, for the above referenced interfaces 29.281 and 29.274 are probably more appropriate. "A Local IP Access (LIPA) and Selected IP Traffic Offload (SIPTO) enabled network [3GPP.23.829] allows offloading some IP services at" I would say referencing to e.g. 23.401 on LIPA/SIPTO is more appropriate these days, since the TR23.829 is somewhat left behind and the = LIPA/SIPTO functionality is part of the main stage-2 specs already. I found Section 4 in general quite nice. However, I was somehow = expecting to see a bit of text of WiMAX. Or can we safely state that no IPv6 = deployments ever took place in WiMAX? Anyway, at least a reference to WiMAX would be nice, since they spent quite a bit of time developing both CMIPv6 and PMIPv6 functionality into their architecture. In Section 4.3. I would reference to 3GPP TS29.303 and say something about 3GPP's heavy use of DNS as the "gateway location database" and how that is used to discover gateways with both topological and gateway collocation in mind In Section 5. it is stated: "o The dynamic anchor relocation needs to ensure that IP address continuity is guaranteed for sessions that need it at the relocated anchor. This for example implies having the knowledge" Since our charter _allows_ solutions where mobility is used "when = needed" that fact should be reflected above. Even if there is mobility supported only locally within a limited area, it might meet the requirements from=20= the MN or the application point of view i.e. when the MN or the = application does not care about a "full longstanding mobility" to be provided. "o Dynamic discovery and selection of anchors. There might be more than one available anchor for a mobile node to use. Currently, there is no efficient mechanism that allows to dynamically discover the presence of nodes that can play the role of anchor, discover their capabilities and allow the selection of the most suitable one." Within 3GPP TS29.303 makes that possible and is deployed. In general the draft is heading to a good direction IMHO! Just complete it fast ;-) - Jouni From alper.yegin@yegin.org Wed Jul 24 06:17:15 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8955511E812C for ; Wed, 24 Jul 2013 06:17:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AXhQK-oBzTkY for ; Wed, 24 Jul 2013 06:17:09 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 5DCAB11E810A for ; Wed, 24 Jul 2013 06:17:09 -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 0Lk7wA-1UPu1n026E-00cBLu; Wed, 24 Jul 2013 09:17:05 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_084586BD-ACBD-4A41-9702-FB6854B798C9" From: Alper Yegin In-Reply-To: <315CD997-1396-423F-8355-0C17A133FA42@gmail.com> Date: Wed, 24 Jul 2013 16:16:57 +0300 Message-Id: <5CD750DD-D753-46B1-8A3A-DECE21EB63DC@yegin.org> References: <315CD997-1396-423F-8355-0C17A133FA42@gmail.com> To: Jouni Korhonen X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:7ZhAo0idJ/MCZqzwM1rxmz97YjGgxJ2YtlMos9k3GZX wwes8GlaZiZLDUH10WTtfLF6x6t4nzvHvFHDGOzNJ3zp5cJ6UP faHvqD+hw1mSopeg7rq8HW8Nh9e33QX2j0L5E1dxTWo8tTZBXm qSG6FjreEo5Urk/HWd2e7Zzg1OLDu8jNY5WxYOe2UQ1JmEbs9H 2y+JvdFq7h5aOJzk/dFuKvxNQZujACQxHYrmnsr827bk4fMKLg nzVoJ/I4IHxY8SxigrlzIejcVCzRhCzCVM7XmaoU29EeMXsyrt w94XF6ORHhDlu7GUhIT2Zx4VDRYRexBMmnpbxsUg7uq/nciP6q gbs2fiRFbWZG8/BsTbyNQFLcNF0ZRFxLflop4TYU2H54/sI3g6 mDmji2TPlcQjg== Cc: "dmm@ietf.org" Subject: Re: [DMM] comments/questions on draft-yegin-dmm-ondemand-mobility-00 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 13:17:15 -0000 --Apple-Mail=_084586BD-ACBD-4A41-9702-FB6854B798C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Jouni, Thanks for the review and comments. > Alper, >=20 > I read the draft and have few quick comments and questions. = Interesting > draft by the way. In Section 3.1. it says: >=20 > "- Access Network Anchored Address >=20 > This type of IP address provides IP session continuity but not IP > address reachability." >=20 > Why is that? What makes IP(v6) address unreachable (I assume from=20 > Internet side)? I would like to see the rationale described here > for this reachability assertion. >=20 IP Address Reachability is defined as follows: IP address reachability: The ability to maintain the same IP address for an extended period of time. The IP address shall stay the same across independent IP sessions, and even in the absence of any IP session. The IP address may be published in a long-term registry (e.g., DNS), and it shall be available for serving incoming (e.g., TCP) connections. IP address reachability is essential for mobile hosts to use specific/published IP addresses. > Then later in Section 3.1. it says: >=20 > "The IP address is allocated by a serving IP gateway. When the = mobile" >=20 > I cannot find a proper description what a "serving IP gateway" is and > what kind of functions it is supposed to posses. >=20 It's just the default IP gateway, the IP router serving the subnet.=20 > In Section 3.4. there are few things. First, it says: >=20 > "available set of IP addresses when selecting an address. According > to the proposed solution, if the requested type IP address is not > available at the time of the request, then the IP stack shall make = an > attempt to configure one such IP address. The selected IP address" >=20 > Assuming the address configuration as per SLAAC or DHCPv6 has already > taken place within the stack, how the "attempt to configure one such = IP > address" should be understood? Would it imply signaling towards = network > or creation of tunnels or what? Yes.=20 For example if a Home Anchored IP address is needed, but none is = available, then the IP stack would trigger Mobile IP to configure one. > This is quite unclear to me after reading > the draft. >=20 > Second, it says: >=20 > "shall be compliant with the requested IP address type, whether it is > selected among available addresses or dynamically configured. In = the > absence of a matching type (because it is not available and not > configurable on demand), the source address selection algorithm = shall > return an empty set." >=20 > I read this as a change proposal to RFC6724 algorithm.. which part and > which rule you intend to modify/add? Since you aim to standards track > this part should be described in detail. >=20 Rule 4.=20 > Last, there is no discussion how the stack/host knows what address in > unanchored/access anchored/home anchored. I would like to see some > technical discussion how that is accomplished and possibly pointers to > existing work on that area if there is some. >=20 We'd refer to prefix coloring drafts. (We'll add clarifications to the text in revision addressing your = questions.) Alper > - Jouni --Apple-Mail=_084586BD-ACBD-4A41-9702-FB6854B798C9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi = Jouni,

Thanks for the review and = comments.


Alper,

I read the draft and have few quick = comments and questions. Interesting
draft by the way. In Section 3.1. = it says:

 "- Access Network Anchored Address

=   This type of IP address provides IP session continuity but = not IP
  address reachability."

Why is that? What = makes IP(v6) address unreachable (I assume from
Internet side)? I = would like to see the rationale described here
for this reachability = assertion.



IP= Address Reachability is defined as = follows:

   IP =
address reachability: The ability to maintain the same IP address
   for an extended period of time.  The IP address shall stay the same
   across independent IP sessions, and even in the absence of any IP
   session.  The IP address may be published in a long-term registry
   (e.g., DNS), and it shall be available for serving incoming (e.g.,
   TCP) connections.  IP address reachability is essential for mobile
   hosts to use specific/published IP =
addresses.


Then later in Section 3.1. it says:

=  "The IP address is allocated by a serving IP gateway.  When = the mobile"

I cannot find a proper description what a "serving IP = gateway" is and
what kind of functions it is supposed to = posses.


It's just the = default IP gateway, the IP router serving the = subnet. 


In Section 3.4. there are few things. First, it = says:

 "available set of IP addresses when selecting an = address.  According
  to the proposed solution, if = the requested type IP address is not
  available at the = time of the request, then the IP stack shall make an
=   attempt to configure one such IP address.  The selected = IP address"

Assuming the address configuration as per SLAAC or = DHCPv6 has already
taken place within the stack, how the "attempt to = configure one such IP
address" should be understood? Would it imply = signaling towards network
or creation of tunnels or what? =

Yes. 
For example = if a Home Anchored IP address is needed, but none is available, then the = IP stack would trigger Mobile IP to configure = one.



This is quite unclear to me after reading
the = draft.

Second, it says:

 "shall be compliant with = the requested IP address type, whether it is
  selected = among available addresses or dynamically configured.  In the
=   absence of a matching type (because it is not available and = not
  configurable on demand), the source address = selection algorithm shall
  return an empty set."

I = read this as a change proposal to RFC6724 algorithm.. which part = and
which rule you intend to modify/add? Since you aim to standards = track
this part should be described in = detail.


Rule = 4. 


Last, = there is no discussion how the stack/host knows what address = in
unanchored/access anchored/home anchored. I would like to see = some
technical discussion how that is accomplished and possibly = pointers to
existing work on that area if there is = some.


We'd refer to prefix = coloring drafts.

(We'll add clarifications to = the text in revision addressing your = questions.)

Alper




- = Jouni

= --Apple-Mail=_084586BD-ACBD-4A41-9702-FB6854B798C9-- From alper.yegin@yegin.org Wed Jul 24 06:29:14 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDBA411E8210 for ; Wed, 24 Jul 2013 06:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PHwLV7vlwrig for ; Wed, 24 Jul 2013 06:29:09 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id D1C0811E80ED for ; Wed, 24 Jul 2013 06:29:08 -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 0LdHab-1UJbtW1vJh-00ijBI; Wed, 24 Jul 2013 09:28:50 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: Date: Wed, 24 Jul 2013 16:28:45 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <8B55D8AB-622D-42DF-A5BC-00BCC1DA9EC4@yegin.org> References: To: Jouni Korhonen X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:F0Zx0LOUsDFpplcIkdtt0pOOY+VuBSDpZhOGbYjDBWX 4D29kUyq2Q1qoZ+4rYk/ZV4f2xDlu8E7mBG79E7EzhXKnYZ/w/ IOkldVBj8cQlDBbrCll/jg5IGBW38aqB5jKkxnU+53e4yYNW+K lX9muXHprxxIo27vAQPle4UODOGWaEjZWHlrxxCL7CbWN5lFTI BejMRoFNj+V8oT/oWzUDj75YuoC39Pz45Unw/vIXvkdPNEZz6x HJS70Cc6oqUcsAFdFR3NixnQ3+2c2e6/2vbF8rIK0wjpVyFkxW zr+KE/KAvJNPi09LC+IfGYtf+hlJs7YIUpPU7rDnUptDpBz1/a ljYywGIGgbGV3cbP9P1VpdGPBsS8AEkvoLWjgU8d3ASDho/eDr /re4TsvN9633Q== Cc: "dmm@ietf.org" Subject: Re: [DMM] comments/questions of draft-yegin-dmm-cnet-homing-00 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 13:29:15 -0000 On Jul 24, 2013, at 11:56 AM, Jouni Korhonen wrote: > Alper, authors, >=20 > In Section 3. is states: >=20 > "CHA may be co-located with the CN, or located in the same site as = the > CN, or located in an ISP serving that site. Not all CNs may be > served by a CHA. In case there is no CHA serving the CN, the MN and > the CN may communicate using the HoA via the HA. It is expected = that > CHAs would be deployed for dominant content sites on the Internet > (e.g., YouTube, Facebook, Netflix, etc.)" >=20 > What would be the motivation or business reason for a service/content > provider to start offering a mobility anchoring service? High = bandwidth > sites as listed above would need invest quite much for such a = platform. >=20 Here's our thinking: - The direct benefit of this approach to the content provider is the = reduction of transmission latency due to elimination of the triangular = routes. This would enhance the their user experience. - Considering the overall system (w/o distinguishing between the MNO and = the content provider), providing anchoring/mobility near the CNet as = opposed to doing it at a corner of the Internet reduces the overall = cost. Given the savings, the involved parties can find a fair way to = deal with it (i.e., some business deal). On top of that, this can be provided by ISPs serving the content sites. = Such ISPs can also have a business deal with the MNO for taking over the = mobility management load. > I also started thinking that in general this solution (and quite many > other) seem to assume the CN is more or less stationary. How would the > CHA concept be affected if the CN is also mobile? Would it allow any > benefits over the legacy MIP variants? How would the CHA discovery=20 > work in this case? >=20 We didn't consider mobile CNs. We are going after the major sources of = mobile traffic, which is stemming from fixed sites. > The examples in Sections 3. and 4. show DNS as the discovery mechanism > for the CHA. However, there is no real description how the discovery > is actually carried out (except conceptual CHA domain name referred > in Section 3. It's just a matter of storing cha. in DNS and looking it up. We can add some more verbiage, if this is not clear. > Figure 1 step 2). Have you considered other discovery > mechanisms than DNS? >=20 We did some but this one seemed to be the most straightforward.=20 Any specific recommendations? Alper > - Jouni >=20 >=20 >=20 >=20 >=20 From jouni.nospam@gmail.com Wed Jul 24 06:35:45 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97FAB11E80F7 for ; Wed, 24 Jul 2013 06:35:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2cmzB90Yzur for ; Wed, 24 Jul 2013 06:35:44 -0700 (PDT) Received: from mail-bk0-x22b.google.com (mail-bk0-x22b.google.com [IPv6:2a00:1450:4008:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 9AC7611E80F1 for ; Wed, 24 Jul 2013 06:35:44 -0700 (PDT) Received: by mail-bk0-f43.google.com with SMTP id jm19so91115bkc.2 for ; Wed, 24 Jul 2013 06:35:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=9X1WbKjQc8smTCX99SrqKkGVhs1APBG+YN+gj1twKgI=; b=OEKvoAOR3biZr/VZGJ4LTial7EqF5yt9zFXlzlZFV7a7Ghr/gr7ggtI2uSN9f0QZXs fZ2uk7sdCCoo3gxw0L3U2Ia0LhcCO1PaMjtv/Xb2R2FlwUQHeOH8UsM1Sl8coFnwAJ74 w5QbT10DZrhEPPeSYAhu7fgnCl6u7SAJEGHgV2rKHCN9xfHAnjSE43bFipiwWytsmOM4 m6zZBLUE5rOW77SaiuNuoi6FcQujJ2jhP1xT4ahSP0AIdSfRHkc/F/2IFyx+KSxyOQsw rcUk2vtoGZiYDK79Z21Qsov7GDZdspuqa15yJpUrIsZq5Q3eAqkV3Sz2KcjlpceNG6VH tP7Q== X-Received: by 10.205.113.205 with SMTP id ex13mr5408247bkc.104.1374672943686; Wed, 24 Jul 2013 06:35:43 -0700 (PDT) Received: from ?IPv6:2001:1bc8:101:f101:48cf:a62d:d740:cb1d? ([2001:1bc8:101:f101:48cf:a62d:d740:cb1d]) by mx.google.com with ESMTPSA id qw6sm9657105bkb.4.2013.07.24.06.35.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 24 Jul 2013 06:35:41 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jouni Korhonen In-Reply-To: <5CD750DD-D753-46B1-8A3A-DECE21EB63DC@yegin.org> Date: Wed, 24 Jul 2013 16:35:40 +0300 Content-Transfer-Encoding: 7bit Message-Id: References: <315CD997-1396-423F-8355-0C17A133FA42@gmail.com> <5CD750DD-D753-46B1-8A3A-DECE21EB63DC@yegin.org> To: Alper Yegin X-Mailer: Apple Mail (2.1508) Cc: "dmm@ietf.org" Subject: Re: [DMM] comments/questions on draft-yegin-dmm-ondemand-mobility-00 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 13:35:45 -0000 Alper, On Jul 24, 2013, at 4:16 PM, Alper Yegin wrote: > Hi Jouni, > > Thanks for the review and comments. > > >> Alper, >> >> I read the draft and have few quick comments and questions. Interesting >> draft by the way. In Section 3.1. it says: >> >> "- Access Network Anchored Address >> >> This type of IP address provides IP session continuity but not IP >> address reachability." >> >> Why is that? What makes IP(v6) address unreachable (I assume from >> Internet side)? I would like to see the rationale described here >> for this reachability assertion. >> > > > IP Address Reachability is defined as follows: > > IP address reachability: The ability to maintain the same IP address > for an extended period of time. The IP address shall stay the same > across independent IP sessions, and even in the absence of any IP > session. The IP address may be published in a long-term registry > (e.g., DNS), and it shall be available for serving incoming (e.g., > TCP) connections. IP address reachability is essential for mobile > hosts to use specific/published IP addresses. I can read that from the draft but it still does not answer my question. Say, I get an ANAA and the either the MN or the AN does dynamic DNS update. Assuming the AN does not intentionally block incoming connections for ANAAs the MN can be reachable. What is the rationale to rule out incoming connections? I recon you also mix the "IP address shall stay the same across independent IP sessions" with your definition but IMHO that has very little to do with reachability. - Jouni From Peter.McCann@huawei.com Wed Jul 24 06:56:05 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A37211E8216 for ; Wed, 24 Jul 2013 06:56:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ZpsAc9HFLPz for ; Wed, 24 Jul 2013 06:55:32 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7C36311E810A for ; Wed, 24 Jul 2013 06:55:17 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVJ60291; Wed, 24 Jul 2013 13:55:02 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 24 Jul 2013 14:54:04 +0100 Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 24 Jul 2013 14:55:00 +0100 Received: from dfweml512-mbx.china.huawei.com ([169.254.1.163]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.007; Wed, 24 Jul 2013 06:54:56 -0700 From: Peter McCann To: Jouni Korhonen , Alper Yegin Thread-Topic: [DMM] comments/questions on draft-yegin-dmm-ondemand-mobility-00 Thread-Index: AQHOiHK7A8UNP9Ymnk2Yoa+O4V+HZplz1i5g Date: Wed, 24 Jul 2013 13:54:55 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE716F50653@dfweml512-mbx.china.huawei.com> References: <315CD997-1396-423F-8355-0C17A133FA42@gmail.com> <5CD750DD-D753-46B1-8A3A-DECE21EB63DC@yegin.org> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.125.91] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dmm@ietf.org" Subject: Re: [DMM] comments/questions on draft-yegin-dmm-ondemand-mobility-00 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 13:56:05 -0000 Hi, Alper, Jouni, Jouni Korhonen wrote: > Alper, >=20 > On Jul 24, 2013, at 4:16 PM, Alper Yegin wrote: >=20 >> Hi Jouni, >>=20 >> Thanks for the review and comments. >>=20 >>=20 >>> Alper, >>>=20 >>> I read the draft and have few quick comments and questions. >>> Interesting draft by the way. In Section 3.1. it says: >>>=20 >>> "- Access Network Anchored Address >>> This type of IP address provides IP session continuity but not IP >>> address reachability." >>> Why is that? What makes IP(v6) address unreachable (I assume from >>> Internet side)? I would like to see the rationale described here >>> for this reachability assertion. >>>=20 >>=20 >>=20 >> IP Address Reachability is defined as follows: >>=20 >> IP address reachability: The ability to maintain the same IP address >> for an extended period of time. The IP address shall stay the same >> across independent IP sessions, and even in the absence of any IP >> session. The IP address may be published in a long-term registry >> (e.g., DNS), and it shall be available for serving incoming (e.g., >> TCP) connections. IP address reachability is essential for mobile >> hosts to use specific/published IP addresses. >=20 >=20 > I can read that from the draft but it still does not answer my question. > Say, I get an ANAA and the either the MN or the AN does dynamic DNS > update. Assuming the AN does not intentionally block incoming > connections for ANAAs the MN can be reachable. What is the rationale to > rule out incoming connections? I recon you also mix the "IP address > shall stay the same across independent IP sessions" with your definition > but IMHO that has very little to do with reachability. I see Jouni's point, and I think the distinctions between different types of addresses and their capabilities is a bit artificial in both the Yegin draft and the prefix coloring approaches. I think that any given address may change its type and function over its lifetime. An address that was originally assigned as "Unanchored" could be promoted to "Access Network Anchored" if needed by the MN, and as Jouni notes an "Access Network Anchored" address could be registered in DNS to provide reachability, and then you just need to make sure you maintain that address for as long as the DNS entry exists + TTL. A static coloring of prefixes at the time they are assigned is not good enough. We really need to know how many references to an address are outstanding everywhere in the system, and garbage collect old addresses when these reference counts go to zero. Of course, we cannot hope to keep track of all the places throughout the Internet that have cached a given IP address associat= ed to an MN, but we can at least attempt to provide an approximation to this abstract idea. Also, I take issue with the use of "anchored" to distinguish address types. It is possible for an address to be persistently assigned without being "anchored" on any one given endpoint, especially if we use routing instead of tunneling to maintain the connectivity. -Pete From alper.yegin@yegin.org Wed Jul 24 13:58:49 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD6EC11E8285 for ; Wed, 24 Jul 2013 13:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2yFOoKA8eK7x for ; Wed, 24 Jul 2013 13:58:42 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id BF5B111E8119 for ; Wed, 24 Jul 2013 13:58:34 -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 0LqyUd-1UPRSw1pv1-00ecz0; Wed, 24 Jul 2013 16:58:33 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Alper Yegin In-Reply-To: Date: Wed, 24 Jul 2013 23:58:28 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <6BC3491A-80F1-4DB2-82C5-6C3801E6C66D@yegin.org> References: <315CD997-1396-423F-8355-0C17A133FA42@gmail.com> <5CD750DD-D753-46B1-8A3A-DECE21EB63DC@yegin.org> To: Jouni Korhonen X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:RDUW7xMk7eK/JWKNYwgzpjQrZGofbmzsBFAZiK/HA2k 2iCGk4nsb6wh8YIgopLiUjogM1iqZA6gBRXyvecZ1KP1s8ggS8 kX/Tn6D9H/jkiQylC3Ijmr+vv/o1nHaUUqCA62GbrsRJxy+iGd MqXBEMSwAIKjq4B0BEt8x1rm+BThZGomjxwPmjfDPdMR48gPVA aKEc65AbPMSjUE8D6KILGTbWZPkjxJXSoAUgyWE+TFW86oNszx zqwg8TTnooRauqaxK/ds6hypxppUJoNPK5OWl9lhcdxvIsfn/+ 3ps988K78TAlP+I6Dv0uZuCkuWE0xTkjAwAmjdG20yKxDu1HzG YXd0Y5B6gQCtbeeOnw9m30Og8FUHrMh2QsNaDrCCaqq+Pt8hmU +ozByjKyIhyOg== Cc: "dmm@ietf.org" Subject: Re: [DMM] comments/questions on draft-yegin-dmm-ondemand-mobility-00 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 20:58:49 -0000 Jouni, >>=20 >>> Alper, >>>=20 >>> I read the draft and have few quick comments and questions. = Interesting >>> draft by the way. In Section 3.1. it says: >>>=20 >>> "- Access Network Anchored Address >>>=20 >>> This type of IP address provides IP session continuity but not IP >>> address reachability." >>>=20 >>> Why is that? What makes IP(v6) address unreachable (I assume from=20 >>> Internet side)? I would like to see the rationale described here >>> for this reachability assertion. >>>=20 >>=20 >>=20 >> IP Address Reachability is defined as follows: >>=20 >> IP address reachability: The ability to maintain the same IP = address >> for an extended period of time. The IP address shall stay the same >> across independent IP sessions, and even in the absence of any IP >> session. The IP address may be published in a long-term registry >> (e.g., DNS), and it shall be available for serving incoming (e.g., >> TCP) connections. IP address reachability is essential for mobile >> hosts to use specific/published IP addresses. >=20 >=20 > I can read that from the draft but it still does not answer my = question. > Say, I get an ANAA and the either the MN or the AN does dynamic DNS = update. > Assuming the AN does not intentionally block incoming connections for=20= > ANAAs the MN can be reachable. What is the rationale to rule out = incoming > connections? I recon you also mix the "IP address shall stay the same > across independent IP sessions" with your definition but IMHO that has > very little to do with reachability. >=20 Yes, in the case of dynamic DNS there's "reachability". But we need to understand *what* is reachable. When HNAA is used: The IP address stays reachable.=20 When we let the IP address change but keep using dynamic DNS: The FQDN = stays reachable. These are two different types of reachability.=20 And they are not equivalent. The latter has issues: Cannot converge fast, and does not work all the = time (remote hosts do not keep querying the DNS just in case their peers = have changed IP address=85 They cache DNS results=85) Alper =20 > - Jouni >=20 From alper.yegin@yegin.org Wed Jul 24 14:06:52 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F408911E810C for ; Wed, 24 Jul 2013 14:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dG-HI0mq9OCj for ; Wed, 24 Jul 2013 14:06:46 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id DC83A11E80DE for ; Wed, 24 Jul 2013 14:06:45 -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 0LZzGf-1UNrRB2vzJ-00m1UX; Wed, 24 Jul 2013 17:06:41 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Alper Yegin In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716F50653@dfweml512-mbx.china.huawei.com> Date: Thu, 25 Jul 2013 00:06:35 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <40C982AA-70F5-4059-A728-8194FA82D150@yegin.org> References: <315CD997-1396-423F-8355-0C17A133FA42@gmail.com> <5CD750DD-D753-46B1-8A3A-DECE21EB63DC@yegin.org> <5963DDF1F751474D8DEEFDCDBEE43AE716F50653@dfweml512-mbx.china.huawei.com> To: Peter McCann X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:5p9cbuYZnp4xz1XIeUfBRTfXGz9F1uIILQP7MZP06Cl NNFmV3BfbSQH6c1ZXl6nfq5eUcSEzpe39PHYFPYLKeGbYcl/1c K5AHRn/6lflC4sHZ7GaC2xR3okysMoVEcMDP8yWBkJ2bIbDsPn UCHR19mBsOr3YNFkyBx9iO3XtCUlUhf+2lSzByi5cNblGVbILc YO9HXHhEqdQU6dPetxyjMXVS/m8RiyVBYd5AxpTrZ8jYTJCM/8 YMcRkiekVbVjXFPdQ1863HC8E57+QkPcY+KlrQbk+wi0Cdw/a+ 0bx+cGN5T/x/LVr1hBRctMTb7S2ahFyrY4U40yLU5eRAgXfl+N 5y6IMhAPwMW+QZELpZiayHpAbhNlrzchSmFvcwVdcBApZfmaq6 WngxAR9TPTK8g== Cc: "dmm@ietf.org" Subject: Re: [DMM] comments/questions on draft-yegin-dmm-ondemand-mobility-00 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 21:06:52 -0000 Hi Pete, >>>> Alper, >>>>=20 >>>> I read the draft and have few quick comments and questions. >>>> Interesting draft by the way. In Section 3.1. it says: >>>>=20 >>>> "- Access Network Anchored Address >>>> This type of IP address provides IP session continuity but not IP >>>> address reachability." >>>> Why is that? What makes IP(v6) address unreachable (I assume from >>>> Internet side)? I would like to see the rationale described here >>>> for this reachability assertion. >>>>=20 >>>=20 >>>=20 >>> IP Address Reachability is defined as follows: >>>=20 >>> IP address reachability: The ability to maintain the same IP = address >>> for an extended period of time. The IP address shall stay the = same >>> across independent IP sessions, and even in the absence of any IP >>> session. The IP address may be published in a long-term registry >>> (e.g., DNS), and it shall be available for serving incoming (e.g., >>> TCP) connections. IP address reachability is essential for mobile >>> hosts to use specific/published IP addresses. >>=20 >>=20 >> I can read that from the draft but it still does not answer my = question. >> Say, I get an ANAA and the either the MN or the AN does dynamic DNS >> update. Assuming the AN does not intentionally block incoming >> connections for ANAAs the MN can be reachable. What is the rationale = to >> rule out incoming connections? I recon you also mix the "IP address >> shall stay the same across independent IP sessions" with your = definition >> but IMHO that has very little to do with reachability. >=20 > I see Jouni's point, and I think the distinctions between different = types > of addresses and their capabilities is a bit artificial in both the = Yegin > draft and the prefix coloring approaches. >=20 > I think that any given address may change its type and function over = its > lifetime. An address that was originally assigned as "Unanchored" = could > be promoted to "Access Network Anchored" if needed by the MN, That's right. But that's the only transition possible. > and as Jouni > notes an "Access Network Anchored" address could be registered in DNS = to > provide reachability, and then you just need to make sure you maintain > that address for as long as the DNS entry exists + TTL. It's a different type of reachability, with very distinct = characteristic. Please see my response to Jouni. > A static coloring > of prefixes at the time they are assigned is not good enough. We = really > need to know how many references to an address are outstanding = everywhere > in the system, and garbage collect old addresses when these reference > counts go to zero. Of course, we cannot hope to keep track of all the > places throughout the Internet that have cached a given IP address = associated > to an MN, but we can at least attempt to provide an approximation to = this > abstract idea. >=20 > Also, I take issue with the use of "anchored" to distinguish address = types. > It is possible for an address to be persistently assigned without = being > "anchored" on any one given endpoint, especially if we use routing = instead > of tunneling to maintain the connectivity. >=20 If one can propagate host routes across the Internet, then the anchor = aspect disappears.=20 Alper > -Pete >=20 >=20 >=20 From Peter.McCann@huawei.com Wed Jul 24 14:24:44 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66F2B11E8143 for ; Wed, 24 Jul 2013 14:24:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHA9d58KKUSc for ; Wed, 24 Jul 2013 14:24:34 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 4C93A11E80FA for ; Wed, 24 Jul 2013 14:24:29 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATT40119; Wed, 24 Jul 2013 21:24:28 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 24 Jul 2013 22:23:28 +0100 Received: from DFWEML407-HUB.china.huawei.com (10.193.5.132) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 24 Jul 2013 22:24:25 +0100 Received: from dfweml512-mbx.china.huawei.com ([169.254.1.163]) by dfweml407-hub.china.huawei.com ([10.193.5.132]) with mapi id 14.01.0323.007; Wed, 24 Jul 2013 14:24:22 -0700 From: Peter McCann To: Alper Yegin Thread-Topic: [DMM] comments/questions on draft-yegin-dmm-ondemand-mobility-00 Thread-Index: AQHOiHK7A8UNP9Ymnk2Yoa+O4V+HZplz1i5ggADxoYD//4scYA== Date: Wed, 24 Jul 2013 21:24:21 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE716F50828@dfweml512-mbx.china.huawei.com> References: <315CD997-1396-423F-8355-0C17A133FA42@gmail.com> <5CD750DD-D753-46B1-8A3A-DECE21EB63DC@yegin.org> <5963DDF1F751474D8DEEFDCDBEE43AE716F50653@dfweml512-mbx.china.huawei.com> <40C982AA-70F5-4059-A728-8194FA82D150@yegin.org> In-Reply-To: <40C982AA-70F5-4059-A728-8194FA82D150@yegin.org> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.193.125.91] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dmm@ietf.org" Subject: Re: [DMM] comments/questions on draft-yegin-dmm-ondemand-mobility-00 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jul 2013 21:24:44 -0000 Hi, Alper, Alper Yegin wrote: > Hi Pete, >=20 >>>>> Alper, >>>>>=20 >>>>> I read the draft and have few quick comments and questions. >>>>> Interesting draft by the way. In Section 3.1. it says: >>>>>=20 >>>>> "- Access Network Anchored Address This type of IP address >>>>> provides IP session continuity but not IP address reachability." >>>>> Why is that? What makes IP(v6) address unreachable (I assume from >>>>> Internet side)? I would like to see the rationale described here >>>>> for this reachability assertion. >>>>>=20 >>>>=20 >>>>=20 >>>> IP Address Reachability is defined as follows: >>>>=20 >>>> IP address reachability: The ability to maintain the same IP >>>> address for an extended period of time. The IP address shall stay >>>> the same across independent IP sessions, and even in the absence of >>>> any IP session. The IP address may be published in a long-term >>>> registry (e.g., DNS), and it shall be available for serving >>>> incoming (e.g., TCP) connections. IP address reachability is >>>> essential for mobile hosts to use specific/published IP addresses. >>>=20 >>>=20 >>> I can read that from the draft but it still does not answer my >>> question. Say, I get an ANAA and the either the MN or the AN does >>> dynamic DNS update. Assuming the AN does not intentionally block >>> incoming connections for ANAAs the MN can be reachable. What is the >>> rationale to rule out incoming connections? I recon you also mix the >>> "IP address shall stay the same across independent IP sessions" with >>> your definition but IMHO that has very little to do with reachability. >>=20 >> I see Jouni's point, and I think the distinctions between different >> types of addresses and their capabilities is a bit artificial in >> both the Yegin draft and the prefix coloring approaches. >>=20 >> I think that any given address may change its type and function over >> its lifetime. An address that was originally assigned as "Unanchored" >> could be promoted to "Access Network Anchored" if needed by the MN, >=20 > That's right. > But that's the only transition possible. Depending on how you define these terms, you are right. But I am saying that the hard distinctions you make in the draft may not be that intellectually useful. >> and as Jouni >> notes an "Access Network Anchored" address could be registered in >> DNS to provide reachability, and then you just need to make sure you >> maintain that address for as long as the DNS entry exists + TTL. >=20 > It's a different type of reachability, with very distinct > characteristic. Please see my response to Jouni. Sure, but maybe reachability of an IP address is not what's needed here. Reachability of the host from nodes that don't yet know its IP address is what counts. >> A static coloring >> of prefixes at the time they are assigned is not good enough. We >> really need to know how many references to an address are outstanding >> everywhere in the system, and garbage collect old addresses when these >> reference counts go to zero. Of course, we cannot hope to keep track >> of all the places throughout the Internet that have cached a given IP >> address associated to an MN, but we can at least attempt to provide an >> approximation to this abstract idea. >>=20 >> Also, I take issue with the use of "anchored" to distinguish address >> types. It is possible for an address to be persistently assigned >> without being "anchored" on any one given endpoint, especially if we >> use routing instead of tunneling to maintain the connectivity. >>=20 >=20 > If one can propagate host routes across the Internet, then the anchor > aspect disappears. Maybe you need an anchor after you have moved a certain distance in the Internet topology, but not before. And there is no need for that anchor to be the same as the first access router that assigned the address. An MN should be able, at any time, to get a fresh IP address (in general, we should be talking about a prefix) that is topologically matched to its=20 current attachment point. That prefix will be routable over a certain set of other attachment points by network-based means, and some mechanism should be provided to inform the MN whether the prefix is still on-link at any new attachment point (perhaps as simple as an RA, or something more optimal could be developed for specific link technologies). If the address is no longer on-link, the MN should be able to get a new prefix and set up a tunnel from an HA to its current attachment point. The HA and the HA-MN security association should be established simultaneously with the assignment of the original prefix (this step is optional if the network that originally assigned the prefix doesn't want to provide global mobility for that prefix). The MN thus maintains a pool of prefixes, and should be able to renew its lease on any prefix remotely from wherever it happens to be currently attached. It is entirely up to the MN to decide of which prefixes it needs to maintain ownership, whether to register any of these addresses in DNS, and to decide which prefixes are no longer needed by any applications and=20 can be returned to the network(s) that assigned them. It's possible that one or more of these addresses are "permanently" assigne= d to the MN (for some definition of "permanent") and provide the "reachabilit= y" property that you defined in the draft. However, that's merely a configura= tion and deployment consideration. -Pete From alper.yegin@yegin.org Thu Jul 25 00:03:55 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACCE221F99FA for ; Thu, 25 Jul 2013 00:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 75M482+2bJ4j for ; Thu, 25 Jul 2013 00:03:49 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id A513121F99FB for ; Thu, 25 Jul 2013 00:03: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=mrus1) with ESMTP (Nemesis) id 0MA7ph-1Uvwzy3MSX-00B0Fy; Thu, 25 Jul 2013 03:03:44 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=windows-1252 From: Alper Yegin In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716F50828@dfweml512-mbx.china.huawei.com> Date: Thu, 25 Jul 2013 10:03:37 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <315CD997-1396-423F-8355-0C17A133FA42@gmail.com> <5CD750DD-D753-46B1-8A3A-DECE21EB63DC@yegin.org> <5963DDF1F751474D8DEEFDCDBEE43AE716F50653@dfweml512-mbx.china.huawei.com> <40C982AA-70F5-4059-A728-8194FA82D150@yegin.org> <5963DDF1F751474D8DEEFDCDBEE43AE716F50828@dfweml512-mbx.china.huawei.com> To: Peter McCann X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:qOoe7Amg2Y5LA13blxZTdMwxjtrQR8tOGfokiiJ7HZV gCqKyrwnEyUIA6cOMENdo60jmsTsX6CDXZ3VIMMNor6NZG5qbf BzkLX4ouhNBmtZci8yJc/2ejAQR60rk9ntPZg3iJ/ZA970qQ26 DsfKSYa/bGXlsD5u3HDRHWvhDkO9Upj/D90XM1dMWiIctCKwj3 6gu6Jm6hKvAx9FwBxGmpg3Tdn498uOlI/na39xGlS/dy+DthnW hcG3dmon47caW24Abd+KyhMAj//snYHo7AtKKfbYBAb4a37mPG 7jtpd46UZ1s1Li+QVpPBGBeJy9P7K845eDMsT1QI2Qu+PsoJxN rGrX8FPlMC0xMELoeyOuy68HSOVfPERsA3OHXcFvqoFWrMyhPv GchfpViaAB+aQ== Cc: "dmm@ietf.org" Subject: Re: [DMM] comments/questions on draft-yegin-dmm-ondemand-mobility-00 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 07:03:55 -0000 >>>>> IP Address Reachability is defined as follows: >>>>>=20 >>>>> IP address reachability: The ability to maintain the same IP >>>>> address for an extended period of time. The IP address shall = stay >>>>> the same across independent IP sessions, and even in the absence = of >>>>> any IP session. The IP address may be published in a long-term >>>>> registry (e.g., DNS), and it shall be available for serving >>>>> incoming (e.g., TCP) connections. IP address reachability is >>>>> essential for mobile hosts to use specific/published IP = addresses. >>>>=20 >>>>=20 >>>> I can read that from the draft but it still does not answer my >>>> question. Say, I get an ANAA and the either the MN or the AN does >>>> dynamic DNS update. Assuming the AN does not intentionally block >>>> incoming connections for ANAAs the MN can be reachable. What is the >>>> rationale to rule out incoming connections? I recon you also mix = the >>>> "IP address shall stay the same across independent IP sessions" = with >>>> your definition but IMHO that has very little to do with = reachability. >>>=20 >>> I see Jouni's point, and I think the distinctions between different >>> types of addresses and their capabilities is a bit artificial in >>> both the Yegin draft and the prefix coloring approaches. >>>=20 >>> I think that any given address may change its type and function over >>> its lifetime. An address that was originally assigned as = "Unanchored" >>> could be promoted to "Access Network Anchored" if needed by the MN, >>=20 >> That's right. >> But that's the only transition possible. >=20 > Depending on how you define these terms, you are right. But I am > saying that the hard distinctions you make in the draft may not be > that intellectually useful. >=20 Hmm, I still don't understand why you say so=85 At any point in time, a = given IP address falls in one of these three categories. >>> and as Jouni >>> notes an "Access Network Anchored" address could be registered in >>> DNS to provide reachability, and then you just need to make sure you >>> maintain that address for as long as the DNS entry exists + TTL. >>=20 >> It's a different type of reachability, with very distinct >> characteristic. Please see my response to Jouni. >=20 > Sure, but maybe reachability of an IP address is not what's needed = here. > Reachability of the host from nodes that don't yet know its IP address > is what counts. >=20 That's another level of reachability.=20 See, there's a chain of mapping: ID at app-level -> FQDN -> IP address = -> L2 address -> L1 address. I think you are referring to FQDN reachability. But in this MIP-land, we are concerned about IP address reachability = part of the problem. >>> A static coloring >>> of prefixes at the time they are assigned is not good enough. We >>> really need to know how many references to an address are = outstanding >>> everywhere in the system, and garbage collect old addresses when = these >>> reference counts go to zero. Of course, we cannot hope to keep = track >>> of all the places throughout the Internet that have cached a given = IP >>> address associated to an MN, but we can at least attempt to provide = an >>> approximation to this abstract idea. >>>=20 >>> Also, I take issue with the use of "anchored" to distinguish address >>> types. It is possible for an address to be persistently assigned >>> without being "anchored" on any one given endpoint, especially if we >>> use routing instead of tunneling to maintain the connectivity. >>>=20 >>=20 >> If one can propagate host routes across the Internet, then the anchor >> aspect disappears. >=20 > Maybe you need an anchor after you have moved a certain distance in = the > Internet topology, but not before. And there is no need for that = anchor > to be the same as the first access router that assigned the address. >=20 That statement would be true assuming again there's some kind of = host/prefix-specific route propagation. >=20 > An MN should be able, at any time, to get a fresh IP address (in = general, > we should be talking about a prefix) that is topologically matched to = its=20 > current attachment point. That prefix will be routable over a certain > set of other attachment points by network-based means, and some = mechanism > should be provided to inform the MN whether the prefix is still = on-link > at any new attachment point (perhaps as simple as an RA, or something > more optimal could be developed for specific link technologies). If = the > address is no longer on-link, the MN should be able to get a new = prefix > and set up a tunnel from an HA to its current attachment point. The = HA > and the HA-MN security association should be established = simultaneously > with the assignment of the original prefix (this step is optional if = the > network that originally assigned the prefix doesn't want to provide = global > mobility for that prefix). >=20 > The MN thus maintains a pool of prefixes, and should be able to renew = its > lease on any prefix remotely from wherever it happens to be currently > attached. It is entirely up to the MN to decide of which prefixes it = needs > to maintain ownership, whether to register any of these addresses in = DNS, > and to decide which prefixes are no longer needed by any applications = and=20 > can be returned to the network(s) that assigned them. >=20 > It's possible that one or more of these addresses are "permanently" = assigned > to the MN (for some definition of "permanent") and provide the = "reachability" > property that you defined in the draft. However, that's merely a = configuration > and deployment consideration. >=20 These above makes sense to me. Alper > -Pete >=20 From alper.yegin@yegin.org Thu Jul 25 01:03:47 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7548121F99F7 for ; Thu, 25 Jul 2013 01:03:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.448 X-Spam-Level: X-Spam-Status: No, score=-102.448 tagged_above=-999 required=5 tests=[AWL=-0.150, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8a2WUPPl90nT for ; Thu, 25 Jul 2013 01:03:42 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 840AE21F999E for ; Thu, 25 Jul 2013 01:03:42 -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 0MF4yZ-1Us63E1CbT-00GL4d; Thu, 25 Jul 2013 04:03:30 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_4A187A45-296C-4903-8061-5D4BF2086F88" From: Alper Yegin X-Priority: 3 In-Reply-To: <18f82da.eed8.14010f95ad8.Coremail.liumin@ict.ac.cn> Date: Thu, 25 Jul 2013 11:03:21 +0300 Message-Id: <5F48E87A-BDBD-48F3-9035-B69087B63D8F@yegin.org> References: <8B55D8AB-622D-42DF-A5BC-00BCC1DA9EC4@yegin.org> <18f82da.eed8.14010f95ad8.Coremail.liumin@ict.ac.cn> To: =?utf-8?B?5YiY5pWP?= X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:kgjRa2PcaAchuNZfsvz/iVT3iQUFENUrZlwQG74xQb1 zIaIdLcBdPTF45AlNDh0P5XuxX+7rOAMfIVnKVCk/cb6Ce6yOU g3pntEKx0humufyDq3iWTMHEmeTL20zgPB+PanDPpH57MpYoRG EEJlDOEpwqX08CEjUViIn/Dw7BBi8/v0M82fR+Crxo54HTfOC1 NIgiHm10sd2aX9EcmkiICy7VBKeV5lJqIREYa2wS5tNRos21mA 1OByIdQ6I/r+HSCMPvzCT/RXvhZxx6CdIODCyLJYgKmOzu5Cym d5V3mgUybLD5YyT5PSxIVaDh3bwe35L80iNXjj7Ku/KlrpZr11 F4h56HLJQ55uUKscvIS0Lqxl72nAhLHfNcMvDsgAqWIm90/ZVQ ZNzyPvNV5NS3w== Cc: "dmm@ietf.org" Subject: Re: [DMM] comments/questions of draft-yegin-dmm-cnet-homing-00 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 08:03:47 -0000 --Apple-Mail=_4A187A45-296C-4903-8061-5D4BF2086F88 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Liu, Yes it seems like we are approaching the DMM problem in the same way. At the technical detail level here are the essential differences between = two I-Ds: - The mobility agent in our case can even be outside the domain of CN.=20= - Your I-D has a very elaborate DHP discovery, with additional protocol = work, some even touching CN. Not sure why it is needed. We are simply = using DNS request for that. It becomes just a matter of putting the = right entry in the DNS. - Our I-D is not modifying Mobile IP protocol at all. You seem to define = new messaging for HoA discovery, and also extending BU. Again, not sure = why those extensions are needed. - " MN decides whether the service flow needs mobility support according = to the service type of the new connection request." This is not clear. = In our case the determination is transparent to the upper layers. If the = DNS returns an IP address for CHA, then CHA is used. - There's an assumption that MN has a HoA and CN knows that. Not sure = why this is needed. Overall, as you can see from our I-D, we believe dynamically anchoring = the IP address somewhere close to the CN can be achieved without any = protocol work. Alper On Jul 24, 2013, at 4:58 PM, =E5=88=98=E6=95=8F wrote: >=20 > Hi, Alper, > We submited a draft to DMM in March = (http://datatracker.ietf.org/doc/draft-liu-dmm-flows-distribution-and-hand= off/?include_text=3D1) and made a presentation in last IETF meeting in = Orlando. I think the main idea in your draft is almost the same with our = I-D. In our draft, we propose a new entity named Distributed Home-Proxy = (DHP) that is a router near CN, with the function for an extension of = the HA, to assign Distributed Home Address (DHoA) for the MN to = implement router optimization. In your draft, you propose a = Corresponding Home Agent (CHA) located near CNs to allocate a HoA to the = MN (Corresponding Home Address, CHoA). As I see it, the CHA is just the = DHP and CHoA is the same as DHoA. Could you please explain the new = contribution in your draft? >=20 >=20 > Min Liu >=20 > Institute of Computing Technology > Chinese Academy of Science >=20 > > ---------- > > Sender: "Alper Yegin" > > Receiver: "Jouni Korhonen" > > Copy: "dmm@ietf.org" > > Subject: Re: [DMM] comments/questions of = draft-yegin-dmm-cnet-homing-00 > >=20 > >=20 > > On Jul 24, 2013, at 11:56 AM, Jouni Korhonen wrote: > >=20 > > > Alper, authors, > > >=20 > > > In Section 3. is states: > > >=20 > > > "CHA may be co-located with the CN, or located in the same site = as the > > > CN, or located in an ISP serving that site. Not all CNs may be > > > served by a CHA. In case there is no CHA serving the CN, the MN = and > > > the CN may communicate using the HoA via the HA. It is expected = that > > > CHAs would be deployed for dominant content sites on the = Internet > > > (e.g., YouTube, Facebook, Netflix, etc.)" > > >=20 > > > What would be the motivation or business reason for a = service/content > > > provider to start offering a mobility anchoring service? High = bandwidth > > > sites as listed above would need invest quite much for such a = platform. > > >=20 > >=20 > > Here's our thinking: > >=20 > > - The direct benefit of this approach to the content provider is the = reduction of transmission latency due to elimination of the triangular = routes. This would enhance the their user experience. > >=20 > > - Considering the overall system (w/o distinguishing between the MNO = and the content provider), providing anchoring/mobility near the CNet as = opposed to doing it at a corner of the Internet reduces the overall = cost. Given the savings, the involved parties can find a fair way to = deal with it (i.e., some business deal). > >=20 > > On top of that, this can be provided by ISPs serving the content = sites. Such ISPs can also have a business deal with the MNO for taking = over the mobility management load. > >=20 > >=20 > > > I also started thinking that in general this solution (and quite = many > > > other) seem to assume the CN is more or less stationary. How would = the > > > CHA concept be affected if the CN is also mobile? Would it allow = any > > > benefits over the legacy MIP variants? How would the CHA discovery=20= > > > work in this case? > > >=20 > >=20 > > We didn't consider mobile CNs. We are going after the major sources = of mobile traffic, which is stemming from fixed sites. > >=20 > >=20 > > > The examples in Sections 3. and 4. show DNS as the discovery = mechanism > > > for the CHA. However, there is no real description how the = discovery > > > is actually carried out (except conceptual CHA domain name = referred > > > in Section 3. > >=20 > > It's just a matter of storing cha. in DNS and looking it = up. > > We can add some more verbiage, if this is not clear. > >=20 > > > Figure 1 step 2). Have you considered other discovery > > > mechanisms than DNS? > > >=20 > >=20 > > We did some but this one seemed to be the most straightforward.=20 > > Any specific recommendations? > >=20 > > Alper > >=20 > >=20 > >=20 > >=20 > > > - Jouni > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > >=20 > > _______________________________________________ > > dmm mailing list > > dmm@ietf.org > > https://www.ietf.org/mailman/listinfo/dmm >=20 >=20 >=20 --Apple-Mail=_4A187A45-296C-4903-8061-5D4BF2086F88 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi = Liu,

Yes it seems like we are approaching the DMM = problem in the same way.

At the technical = detail level here are the essential differences between two = I-Ds:

- The mobility agent in our case can even = be outside the domain of CN. 

- Your I-D = has a very elaborate DHP discovery, with additional protocol work, some = even touching CN. Not sure why it is needed. We are simply using DNS = request for that. It becomes just a matter of putting the right entry in = the DNS.

- Our I-D is not modifying Mobile IP = protocol at all. You seem to define new messaging for HoA discovery, and = also extending BU. Again, not sure why those extensions are = needed.

- " MN decides = whether the service flow needs mobility support according to the service type of the new connection request." This is = not clear. In our case the determination is transparent to the upper = layers. If the DNS returns an IP address for CHA, then CHA is = used.
- There's an = assumption that MN has a HoA and CN knows that. Not sure why this is = needed.
Overall, as = you can see from our I-D, we believe dynamically anchoring the IP = address somewhere close to the CN can be achieved without any protocol = work.




=




On = Jul 24, 2013, at 4:58 PM, =E5=88=98=E6=95=8F wrote:


Hi, = Alper,



> ----------
> Sender: "Alpe= r Yegin" <alper.yegin@yegin.org>
>= ; Receiver: "Jouni Korhonen" <jouni.nospam@gmail.com>
&= gt; Copy: "dmm@ietf.org" <dmm@ietf.org>
> Subject:&nb= sp;Re: [DMM] comments/questions of draft-yegin-dmm-cne= t-homing-00
> 
> 
> On Jul 24,&= nbsp;2013, at 11:56 AM, Jouni Korhonen wrote= :
> 
> > Alper, authors,
> &= gt; 
> > In Section 3. is stat= es:
> > 
> >  "CHA may&nbs= p;be co-located with the CN, or located = ;in the same site as the
> > &= nbsp; CN, or located in an ISP serving&= nbsp;that site.  Not all CNs may be
= > >   served by a CHA.  = ;In case there is no CHA serving the&nb= sp;CN, the MN and
> >   the&nb= sp;CN may communicate using the HoA via = ;the HA.  It is expected that
> &= gt;   CHAs would be deployed for d= ominant content sites on the Internet
>&nbs= p;>   (e.g., YouTube, Facebook, Netflix,&= nbsp;etc.)"
> > 
> > What would=  be the motivation or business reason f= or a service/content
> > provider to&nbs= p;start offering a mobility anchoring service?&nb= sp;High bandwidth
> > sites as listed&nb= sp;above would need invest quite much for&nb= sp;such a platform.
> > 
> 
>= ; Here's our thinking:
> 
> - Th= e direct benefit of this approach to th= e content provider is the reduction of = transmission latency due to elimination of t= he triangular routes. This would enhance the=  their user experience.
> 
> - C= onsidering the overall system (w/o distinguishing=  between the MNO and the content provid= er), providing anchoring/mobility near the CNet&n= bsp;as opposed to doing it at a corner&= nbsp;of the Internet reduces the overall cos= t. Given the savings, the involved parties&n= bsp;can find a fair way to deal with&nb= sp;it (i.e., some business deal).
> 
>= ; On top of that, this can be prov= ided by ISPs serving the content sites. = ;Such ISPs can also have a business dea= l with the MNO for taking over the = ;mobility management load.
> 
> 
>&n= bsp;> I also started thinking that in&nbs= p;general this solution (and quite many
>&n= bsp;> other) seem to assume the CN i= s more or less stationary. How would th= e
> > CHA concept be affected if&nb= sp;the CN is also mobile? Would it allo= w any
> > benefits over the legacy&= nbsp;MIP variants? How would the CHA discove= ry 
> > work in this case?
>&= nbsp;> 
> 
> We didn't consider&nb= sp;mobile CNs. We are going after the m= ajor sources of mobile traffic, which is&nbs= p;stemming from fixed sites.
> 
> > > The examples in Sections 3. = and 4. show DNS as the discovery mechan= ism
> > for the CHA. However, there=  is no real description how the discove= ry
> > is actually carried out (exc= ept conceptual CHA domain name referred
>&n= bsp;> in Section 3.
> 
> It's = ;just a matter of storing cha.<yourdomain>&= nbsp;in DNS and looking it up.
> We&nb= sp;can add some more verbiage, if this = is not clear.
> 
> > Figure 1=  step 2). Have you considered other dis= covery
> > mechanisms than DNS?
> = > 
> 
> We did some but = this one seemed to be the most straight= forward. 
> Any specific recommendations?
>= ; 
> Alper
> 
> 
> 
&g= t; 
> > - Jouni
> > 
&g= t; > 
> > 
> > 
>=  > 
> 
> ______________________________= _________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/ma= ilman/listinfo/dmm




= = --Apple-Mail=_4A187A45-296C-4903-8061-5D4BF2086F88-- From jouni.nospam@gmail.com Thu Jul 25 03:16:30 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B672C21F9A81 for ; Thu, 25 Jul 2013 03:16:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgWCV5mMcxZL for ; Thu, 25 Jul 2013 03:16:30 -0700 (PDT) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) by ietfa.amsl.com (Postfix) with ESMTP id ABC6221F9A80 for ; Thu, 25 Jul 2013 03:16:29 -0700 (PDT) Received: by mail-lb0-f172.google.com with SMTP id a16so1391471lbj.17 for ; Thu, 25 Jul 2013 03:16:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=f2IqeUsOMIeTwjoh/0FG7M5jhG3eqFoIRo0s50sqpRA=; b=UogU2tP8GGTMBlZFEEKUiSaHatEC7inS/2af60tqcN6rLQjC7uCmoB7b2XUH3ZO3ob JOk2leEflM7+4iz/w+kW/SRH+ZIYRqBJIq2KbVqhCKoQvHYVCPOINsycgAMyOK4Er+nh 2lvF9EAuHwBrdXgtbDcymZZNTDhcrSMoi/zUHX3JMS2rtC7ARdLSXEI8YDCX9ABjCb8I 6sTL8GRvi/aBP9e0Ba5Qn8TAKsejak6T6862xq4CAGNQrRFxuTkLm6IW17hI8p9UCfMJ rKYj8c6xN3gS74ty9z3ggT3x68Y7CFrAgFdsKco9QcsmO3Yo+izqm1xsTyJ5BJyTOAbS vZ+w== X-Received: by 10.152.18.229 with SMTP id z5mr2831527lad.84.1374747388615; Thu, 25 Jul 2013 03:16:28 -0700 (PDT) Received: from [192.168.250.152] ([194.100.71.98]) by mx.google.com with ESMTPSA id b8sm16129998lbr.12.2013.07.25.03.16.26 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 25 Jul 2013 03:16:26 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Jouni Korhonen In-Reply-To: <6BC3491A-80F1-4DB2-82C5-6C3801E6C66D@yegin.org> Date: Thu, 25 Jul 2013 13:16:25 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <315CD997-1396-423F-8355-0C17A133FA42@gmail.com> <5CD750DD-D753-46B1-8A3A-DECE21EB63DC@yegin.org> <6BC3491A-80F1-4DB2-82C5-6C3801E6C66D@yegin.org> To: Alper Yegin X-Mailer: Apple Mail (2.1508) Cc: "dmm@ietf.org" Subject: Re: [DMM] comments/questions on draft-yegin-dmm-ondemand-mobility-00 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 10:16:30 -0000 Alper, On Jul 24, 2013, at 11:58 PM, Alper Yegin wrote: > Jouni, >=20 >>>=20 >>>> Alper, >>>>=20 >>>> I read the draft and have few quick comments and questions. = Interesting >>>> draft by the way. In Section 3.1. it says: >>>>=20 >>>> "- Access Network Anchored Address >>>>=20 >>>> This type of IP address provides IP session continuity but not IP >>>> address reachability." >>>>=20 >>>> Why is that? What makes IP(v6) address unreachable (I assume from=20= >>>> Internet side)? I would like to see the rationale described here >>>> for this reachability assertion. >>>>=20 >>>=20 >>>=20 >>> IP Address Reachability is defined as follows: >>>=20 >>> IP address reachability: The ability to maintain the same IP = address >>> for an extended period of time. The IP address shall stay the same >>> across independent IP sessions, and even in the absence of any IP >>> session. The IP address may be published in a long-term registry >>> (e.g., DNS), and it shall be available for serving incoming (e.g., >>> TCP) connections. IP address reachability is essential for mobile >>> hosts to use specific/published IP addresses. >>=20 >>=20 >> I can read that from the draft but it still does not answer my = question. >> Say, I get an ANAA and the either the MN or the AN does dynamic DNS = update. >> Assuming the AN does not intentionally block incoming connections for=20= >> ANAAs the MN can be reachable. What is the rationale to rule out = incoming >> connections? I recon you also mix the "IP address shall stay the same >> across independent IP sessions" with your definition but IMHO that = has >> very little to do with reachability. >>=20 >=20 > Yes, in the case of dynamic DNS there's "reachability". > But we need to understand *what* is reachable. >=20 > When HNAA is used: The IP address stays reachable.=20 > When we let the IP address change but keep using dynamic DNS: The FQDN = stays reachable. I could argue that HNAA is not stable enough to be considered reachable as per how the draft describes it, especially in the case of mobile devices. One flap on the wireless connection and the address is likely to change. > These are two different types of reachability.=20 > And they are not equivalent. > The latter has issues: Cannot converge fast, and does not work all the = time (remote hosts do not keep querying the DNS just in case their peers = have changed IP address=85 They cache DNS results=85) IMHO the difference between the ANAA and HNAA reachability is=20 just the timescale. Even if the ANAA is likely to change more frequently, there should not be a reason to state that it is not reachable. I would rather focus on the "address stability" or alike when coming up with the terminology. Say, your MN is most of the time stationary (like most MNs are today) and gets and ANAA. As long as the movement of the MN is within a limited L2 area, its ANAA does not really differ from HNAA, from the reachability point of view. - Jouni >=20 >=20 > Alper >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >> - Jouni >>=20 >=20 From hassan.aliahmad@orange.com Thu Jul 25 06:24:40 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4930521F9AD2 for ; Thu, 25 Jul 2013 06:24:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMebh-OQRZLD for ; Thu, 25 Jul 2013 06:24:36 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) by ietfa.amsl.com (Postfix) with ESMTP id B41F421F9A23 for ; Thu, 25 Jul 2013 06:24:35 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 040F622D445; Thu, 25 Jul 2013 15:24:34 +0200 (CEST) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id DA7534C05D; Thu, 25 Jul 2013 15:24:33 +0200 (CEST) Received: from PEXCVZYM11.corporate.adroot.infra.ftgroup ([fe80::a441:e6a9:6143:6f0f]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.02.0328.009; Thu, 25 Jul 2013 15:24:33 +0200 From: To: 'Alper Yegin' , Peter McCann , 'Jouni Korhonen' Thread-Topic: [DMM] comments/questions on draft-yegin-dmm-ondemand-mobility-00 Thread-Index: AQHOiLGtmn4732MrMEiUyziGuNheyJl0NWiAgACh2ICAAIRkoA== Date: Thu, 25 Jul 2013 13:24:32 +0000 Message-ID: <6759_1374758673_51F12711_6759_72_1_C5B6A9A3D7D5C941A08B34159DEFE9020FF8534C@PEXCVZYM11.corporate.adroot.infra.ftgroup> References: <315CD997-1396-423F-8355-0C17A133FA42@gmail.com> <5CD750DD-D753-46B1-8A3A-DECE21EB63DC@yegin.org> <5963DDF1F751474D8DEEFDCDBEE43AE716F50653@dfweml512-mbx.china.huawei.com> <40C982AA-70F5-4059-A728-8194FA82D150@yegin.org> <5963DDF1F751474D8DEEFDCDBEE43AE716F50828@dfweml512-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, fr-FR Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.6.28.101520 Cc: "dmm@ietf.org" Subject: Re: [DMM] comments/questions on draft-yegin-dmm-ondemand-mobility-00 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 13:24:40 -0000 Hi Alper, Peter and Jouni, Sorry for jumping to this discussion, I have two comments below. Best regards, Hassan >-----Original Message----- >From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of Alper >Yegin >Sent: Thursday, July 25, 2013 9:04 AM >To: Peter McCann >Cc: dmm@ietf.org >Subject: Re: [DMM] comments/questions on draft-yegin-dmm-ondemand-mobility- >00 > >>>>>> IP Address Reachability is defined as follows: >>>>>> >>>>>> IP address reachability: The ability to maintain the same IP >>>>>> address for an extended period of time. The IP address shall stay >>>>>> the same across independent IP sessions, and even in the absence >>>>>> of any IP session. The IP address may be published in a >>>>>> long-term registry (e.g., DNS), and it shall be available for >>>>>> serving incoming (e.g., TCP) connections. IP address >>>>>> reachability is essential for mobile hosts to use specific/published >IP addresses. >>>>> >>>>> >>>>> I can read that from the draft but it still does not answer my >>>>> question. Say, I get an ANAA and the either the MN or the AN does >>>>> dynamic DNS update. Assuming the AN does not intentionally block >>>>> incoming connections for ANAAs the MN can be reachable. What is the >>>>> rationale to rule out incoming connections? I recon you also mix >>>>> the "IP address shall stay the same across independent IP sessions" >>>>> with your definition but IMHO that has very little to do with >reachability. >>>> >>>> I see Jouni's point, and I think the distinctions between different >>>> types of addresses and their capabilities is a bit artificial in >>>> both the Yegin draft and the prefix coloring approaches. >>>> >>>> I think that any given address may change its type and function over >>>> its lifetime. An address that was originally assigned as "Unanchored" >>>> could be promoted to "Access Network Anchored" if needed by the MN, >>> >>> That's right. >>> But that's the only transition possible. >> >> Depending on how you define these terms, you are right. But I am >> saying that the hard distinctions you make in the draft may not be >> that intellectually useful. >> > > >Hmm, I still don't understand why you say so... At any point in time, a gi= ven >IP address falls in one of these three categories. > >>>> and as Jouni >>>> notes an "Access Network Anchored" address could be registered in >>>> DNS to provide reachability, and then you just need to make sure you >>>> maintain that address for as long as the DNS entry exists + TTL. >>> >>> It's a different type of reachability, with very distinct >>> characteristic. Please see my response to Jouni. >> >> Sure, but maybe reachability of an IP address is not what's needed here. >> Reachability of the host from nodes that don't yet know its IP address >> is what counts. >> > > >That's another level of reachability. >See, there's a chain of mapping: ID at app-level -> FQDN -> IP address -> >L2 address -> L1 address. > >I think you are referring to FQDN reachability. >But in this MIP-land, we are concerned about IP address reachability part >of the problem. > [Hassan] Why we need IP address reachability? Can you please address some c= oncrete use-case scenarios.=20 Upper level reachability is sufficient for an incoming e.g. VoIP call or SM= S to a typical MN, and also even if we imagine an MN acting as a server and= hosting e.g. a website, no one memorize IP addresses. > >>>> A static coloring >>>> of prefixes at the time they are assigned is not good enough. We >>>> really need to know how many references to an address are >>>> outstanding everywhere in the system, and garbage collect old >>>> addresses when these reference counts go to zero. Of course, we >>>> cannot hope to keep track of all the places throughout the Internet >>>> that have cached a given IP address associated to an MN, but we can >>>> at least attempt to provide an approximation to this abstract idea. >>>> >>>> Also, I take issue with the use of "anchored" to distinguish address >>>> types. It is possible for an address to be persistently assigned >>>> without being "anchored" on any one given endpoint, especially if we >>>> use routing instead of tunneling to maintain the connectivity. >>>> >>> >>> If one can propagate host routes across the Internet, then the anchor >>> aspect disappears. >> >> Maybe you need an anchor after you have moved a certain distance in >> the Internet topology, but not before. And there is no need for that >> anchor to be the same as the first access router that assigned the >address. >> > >That statement would be true assuming again there's some kind of >host/prefix-specific route propagation. > >> >> An MN should be able, at any time, to get a fresh IP address (in >> general, we should be talking about a prefix) that is topologically >> matched to its current attachment point. That prefix will be routable >> over a certain set of other attachment points by network-based means, >> and some mechanism should be provided to inform the MN whether the >> prefix is still on-link at any new attachment point (perhaps as simple >> as an RA, or something more optimal could be developed for specific >> link technologies). If the address is no longer on-link, the MN >> should be able to get a new prefix and set up a tunnel from an HA to >> its current attachment point. The HA and the HA-MN security >> association should be established simultaneously with the assignment >> of the original prefix (this step is optional if the network that >> originally assigned the prefix doesn't want to provide global mobility >for that prefix). >> >> The MN thus maintains a pool of prefixes, and should be able to renew >> its lease on any prefix remotely from wherever it happens to be >> currently attached. It is entirely up to the MN to decide of which >> prefixes it needs to maintain ownership, whether to register any of >> these addresses in DNS, and to decide which prefixes are no longer >> needed by any applications and can be returned to the network(s) that >assigned them. >> >> It's possible that one or more of these addresses are "permanently" >> assigned to the MN (for some definition of "permanent") and provide the >"reachability" >> property that you defined in the draft. However, that's merely a >> configuration and deployment consideration. >> > >These above makes sense to me. [Hassan] I agree that it makes sense to keep one of the addresses permanent= (assuming we really need this). However, we will need one permanent anchor= and data packets of incoming sessions/calls should be routed through it an= d then tunneled to the MN. Similar issues to the ones addressed to current = IP mobility protocols in DMM problem statement will be raised, but only for= incoming sessions/calls.=20 In fact, I consider this approach as an integrated DMM--MIPv6 approach: MIP= v6 manages a permanent HA and HoA for MN's reachability at IP address level= for incoming sessions, and DMM for sessions initiated by the MN itself. Im= agine mobile CNs --> DMM will be used less and MIPv6 more. I don't like sem= i-solutions :) > >Alper > > > > >> -Pete >> > >_______________________________________________ >dmm mailing list >dmm@ietf.org >https://www.ietf.org/mailman/listinfo/dmm ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From liumin@ict.ac.cn Thu Jul 25 10:54:29 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE69821F995B for ; Thu, 25 Jul 2013 10:54:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.037 X-Spam-Level: *** X-Spam-Status: No, score=3.037 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RDNS_NONE=0.1, RELAY_IS_222=2.179] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25A-51FOIFOW for ; Thu, 25 Jul 2013 10:54:24 -0700 (PDT) Received: from cstnet.cn (smtp21.cstnet.cn [IPv6:2001:cc0:2fff:7::21]) by ietfa.amsl.com (Postfix) with ESMTP id 233C721F9929 for ; Thu, 25 Jul 2013 10:54:13 -0700 (PDT) Received: from LiuMinTHINK (unknown [222.128.182.99]) by app1 (Coremail) with SMTP id RgCowJDrwAI4ZvFRXIgAAA--.1599S7; Fri, 26 Jul 2013 01:54:03 +0800 (CST) From: "Liu Min" To: "'Alper Yegin'" References: <8B55D8AB-622D-42DF-A5BC-00BCC1DA9EC4@yegin.org> <18f82da.eed8.14010f95ad8.Coremail.liumin@ict.ac.cn> <5F48E87A-BDBD-48F3-9035-B69087B63D8F@yegin.org> In-Reply-To: <5F48E87A-BDBD-48F3-9035-B69087B63D8F@yegin.org> Date: Fri, 26 Jul 2013 01:54:13 +0800 Message-ID: <004001ce895f$f90b9f70$eb22de50$@ict.ac.cn> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0041_01CE89A3.073261E0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQK7KJs/+yaDrS2upKtY/bVzjOygpwE0Dw4UAjsE74wBtZySPJdzR0vA Content-Language: zh-cn X-CM-TRANSID: RgCowJDrwAI4ZvFRXIgAAA--.1599S7 X-Coremail-Antispam: 1UD129KBjvJXoW3XF1rtFyxKF4DWw47Gw13XFb_yoW3trWkpa yfKrsxCrykJryxAw1kuw48XF1FvFZ5tFW7GFyrtry8Z398CF1q9F1xKa1YkFZrArZayw1j vrW29r1DW3Z5ZFJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUU9m14x267AKxVW8JVW5JwAFc2x0x2IEx4CE42xK8VAvwI8IcIk0 rVWrJVCq3wAFIxvE14AKwVWUJVWUGwA2ocxC64kIII0Yj41l84ACjcxK6xIIjxv20xvE14 v26r1j6r1xM28EF7xvwVC0I7IYx2IY6xkF7I0E14v26r4j6F4UM28EF7xvwVC2z280aVAF wI0_Gr0_Cr1l84ACjcxK6I8E87Iv6xkF7I0E14v26r4j6r4UJwAS0I0E0xvYzxvE52x082 IY62kv0487Mc02F40Eb7x2x7xS6ryj6rWUMc02F40E57IF67AEF4xIwI1l5I8CrVAKz4kI r2xC04v26r1j6r4UMc02F40E42I26xC2a48xMcIj6xIIjxv20xvE14v26r1j6r18McIj6I 8E87Iv67AKxVWUJVW8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IYc2Ij64vIr41lF7xv r2IYc2Ij64vIr40E4x8a64kEw24lF7I21c0EjII2zVCS5cI20VAGYxC7MxkIecxEwVAFwV W8MxAIw28IcxkI7VAKI48JMI8I3I0E5I8CrVAFwI0_JrI_JrWlx2IqxVCjr7xvwVAFwI0_ JrI_JrWlx4CE17CEb7AF67AKxVWUAVWUtwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14 v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwCI42IY6xAIw20EY4v20xva j40_WFyUJVCq3wCI42IY6I8E87Iv67AKxVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r 1j6r4UYxBIdaVFxhVjvjDU0xZFpf9x0JUwL05UUUUU= X-CM-SenderInfo: 5olxzxnq6lu3wodfhubq/ Cc: dmm@ietf.org Subject: Re: [DMM] comments/questions of draft-yegin-dmm-cnet-homing-00 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jul 2013 17:54:29 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0041_01CE89A3.073261E0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi Alper, =20 >>Yes it seems like we are approaching the DMM problem in the same way. =20 So we have this consensus that the main idea and approach in your I-D = proposed in July 3, 2013 is the same as our I-D proposed in March 10, = 2013. =20 =20 >>At the technical detail level here are the essential differences = between two I-Ds: >>- The mobility agent in our case can even be outside the domain of CN. = =20 In our I-D, we define that "Distributed Home-Proxy (DHP) is a router = near CN". In this way, DHP doesn't have to be located in CN' domain. = However, we do recommend to find a DHP in CN's domain because choosing = DHP in other domains will not guarantee router optimization and thus = violating our original intention to introduce DHP. Choosing a mobility agent outside the domain of CN makes little sense = since our purpose is to implement router optimization by moving the = mobility agent close to CN. =20 >>- Your I-D has a very elaborate DHP discovery, with additional = protocol work, some even touching CN. Not sure why it is needed. We are = simply using DNS request for that. It becomes just a matter of putting = the right entry in the DNS. =20 In our I-D, we have provided several options for DHP discovery and DNS = request is also used. For example, "MN query the DNS to get the DHP = anycast address", "MN can use DNS to query the DHP management server = address." Actually, we assume there may exist more than one DHP in one = domain. MIPv6 also assumes there may exist more than one HA in one = domain. =20 >>- Our I-D is not modifying Mobile IP protocol at all. You seem to = define new messaging for HoA discovery, and also extending BU. Again, = not sure why those extensions are needed. =20 Our I-D is totally compatible with Mobile IP protocol. For DHP = discovery, as we mentioned in our I-D "This procedure is similar to = "dynamic home agent address discovery mechanism" in MIPv6". Besides, we = provide other options for performance optimization. =20 >>- " MN decides whether the service flow needs mobility support = according to the service type of the new connection request." This is = not clear. In our case the determination is transparent to the upper = layers. If the DNS returns an IP address for CHA, then CHA is used. =20 Router optimization is just one purpose of our I-D, besides that we also = support flow management and flow handoff for high level users. Of = course, users can choose not to use such functions, just as you = mentioned. =20 >>- There's an assumption that MN has a HoA and CN knows that. Not sure = why this is needed. =20 We don't have such an assumption. Maybe you mean this sentence in our = I-D "A notice is that, MN will use HoA to establish the connection with = CN if the DHP query is failed, which means no DHP is found to serve the = current MN. Later workflow is the same as that defined in MIPv6." As you = can see, it is only a complete consideration for exception.=20 =20 >>Overall, as you can see from our I-D, we believe dynamically anchoring = the IP address somewhere close to the CN can be achieved without any = protocol work. =20 Actually, I really don't believe we can implement protocol optimization = without doing any change to it. Actually, you definitely need to change = the implementation for MN in your I-D. =20 =20 Min =20 From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 Sent: Thursday, July 25, 2013 4:03 PM To: Min Liu Cc: Jouni Korhonen; dmm@ietf.org; wangyuwei@ict.ac.cn Subject: Re: [DMM] comments/questions of draft-yegin-dmm-cnet-homing-00 =20 Hi Liu, =20 Yes it seems like we are approaching the DMM problem in the same way. =20 At the technical detail level here are the essential differences between = two I-Ds: =20 - The mobility agent in our case can even be outside the domain of CN.=20 =20 - Your I-D has a very elaborate DHP discovery, with additional protocol = work, some even touching CN. Not sure why it is needed. We are simply = using DNS request for that. It becomes just a matter of putting the = right entry in the DNS. =20 - Our I-D is not modifying Mobile IP protocol at all. You seem to define = new messaging for HoA discovery, and also extending BU. Again, not sure = why those extensions are needed. =20 - " MN decides whether the service flow needs mobility support according = to the service type of the new connection request." This is not clear. = In our case the determination is transparent to the upper layers. If the = DNS returns an IP address for CHA, then CHA is used. - There's an assumption that MN has a HoA and CN knows that. Not sure = why this is needed. Overall, as you can see from our I-D, we believe dynamically anchoring = the IP address somewhere close to the CN can be achieved without any = protocol work. Alper =20 =20 =20 =20 =20 =20 =20 On Jul 24, 2013, at 4:58 PM, =E5=88=98=E6=95=8F wrote: Hi, Alper, We submited a draft to DMM in March = (http://datatracker.ietf.org/doc/draft-liu-dmm-flows-distribution-and-han= doff/?include_text=3D1) and made a presentation in last IETF meeting in = Orlando. I think the main idea in your draft is almost the same with our = I-D. In our draft, we propose a new entity named Distributed Home-Proxy = (DHP) that is a router near CN, with the function for an extension of = the HA, to assign Distributed Home Address (DHoA) for the MN to = implement router optimization. In your draft, you propose a = Corresponding Home Agent (CHA) located near CNs to allocate a HoA to the = MN (Corresponding Home Address, CHoA). As I see it, the CHA is just the = DHP and CHoA is the same as DHoA. Could you please explain the new = contribution in your draft? =20 =20 Min Liu Institute of Computing Technology Chinese Academy of Science > ---------- > Sender: "Alper Yegin" > Receiver: "Jouni Korhonen" > Copy: "dmm@ietf.org" > Subject: Re: [DMM] comments/questions of = draft-yegin-dmm-cnet-homing-00 >=20 >=20 > On Jul 24, 2013, at 11:56 AM, Jouni Korhonen wrote: >=20 > > Alper, authors, > >=20 > > In Section 3. is states: > >=20 > > "CHA may be co-located with the CN, or located in the same site as = the > > CN, or located in an ISP serving that site. Not all CNs may be > > served by a CHA. In case there is no CHA serving the CN, the MN = and > > the CN may communicate using the HoA via the HA. It is expected = that > > CHAs would be deployed for dominant content sites on the Internet > > (e.g., YouTube, Facebook, Netflix, etc.)" > >=20 > > What would be the motivation or business reason for a = service/content > > provider to start offering a mobility anchoring service? High = bandwidth > > sites as listed above would need invest quite much for such a = platform. > >=20 >=20 > Here's our thinking: >=20 > - The direct benefit of this approach to the content provider is the = reduction of transmission latency due to elimination of the triangular = routes. This would enhance the their user experience. >=20 > - Considering the overall system (w/o distinguishing between the MNO = and the content provider), providing anchoring/mobility near the CNet as = opposed to doing it at a corner of the Internet reduces the overall = cost. Given the savings, the involved parties can find a fair way to = deal with it (i.e., some business deal). >=20 > On top of that, this can be provided by ISPs serving the content = sites. Such ISPs can also have a business deal with the MNO for taking = over the mobility management load. >=20 >=20 > > I also started thinking that in general this solution (and quite = many > > other) seem to assume the CN is more or less stationary. How would = the > > CHA concept be affected if the CN is also mobile? Would it allow any > > benefits over the legacy MIP variants? How would the CHA discovery=20 > > work in this case? > >=20 >=20 > We didn't consider mobile CNs. We are going after the major sources of = mobile traffic, which is stemming from fixed sites. >=20 >=20 > > The examples in Sections 3. and 4. show DNS as the discovery = mechanism > > for the CHA. However, there is no real description how the discovery > > is actually carried out (except conceptual CHA domain name referred > > in Section 3. >=20 > It's just a matter of storing cha. in DNS and looking it = up. > We can add some more verbiage, if this is not clear. >=20 > > Figure 1 step 2). Have you considered other discovery > > mechanisms than DNS? > >=20 >=20 > We did some but this one seemed to be the most straightforward.=20 > Any specific recommendations? >=20 > Alper >=20 >=20 >=20 >=20 > > - Jouni > >=20 > >=20 > >=20 > >=20 > >=20 >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm =20 ------=_NextPart_000_0041_01CE89A3.073261E0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi Alper,

 

>>Yes it seems like we are approaching the DMM problem in the = same way.

 

So we have this consensus that the main idea and approach in your I-D = proposed in July 3, 2013 is the same as our I-D proposed in March 10, = 2013.

 

 

>>At the technical detail level here are the essential = differences between two I-Ds:

>>- The mobility agent in our case can even be outside the = domain of CN.

 

In our I-D, we define that "Distributed Home-Proxy (DHP)=C2=A0 = is a router near CN".=C2=A0 In this way, DHP doesn't have to be = located in CN' domain. However, we do recommend to find a DHP in CN's = domain because choosing DHP in other domains will not guarantee router = optimization and thus violating our original intention to introduce = DHP.

Choosing a mobility agent outside the domain of CN makes little sense = since our purpose is to implement router optimization by moving the = mobility agent close to CN.

 

>>- Your I-D has a very elaborate DHP discovery, with = additional protocol work, some even touching CN. Not sure why it is = needed. We are simply using DNS request for that. It becomes just a = matter of putting the right entry in the DNS.

 

In our I-D, we have provided several options for DHP discovery and = DNS request is also used. For example, "MN query the DNS to get the = DHP anycast address", "MN can use DNS to query the DHP = management server address."=C2=A0 Actually, we assume there may = exist more than one DHP in one domain. MIPv6 also assumes there may = exist more than one HA in one domain.

 

>>- Our I-D is not modifying Mobile IP protocol at all. You = seem to define new messaging for HoA discovery, and also extending BU. = Again, not sure why those extensions are needed.

 

Our I-D is totally compatible with Mobile IP protocol. For DHP = discovery, as we mentioned in our I-D "This procedure is similar to = "dynamic home agent address discovery mechanism" in = MIPv6". Besides, we provide other options for performance = optimization.

 

>>- " MN decides whether the service flow needs mobility = support according to the service type of the new connection = request." This is not clear. In our case the determination is = transparent to the upper layers. If the DNS returns an IP address for = CHA, then CHA is used.

 

Router optimization is just one purpose of our I-D, besides that we = also support flow management and flow handoff for high level users. Of = course, users can choose not to use such functions, just as you = mentioned.

 

>>- There's an assumption that MN has a HoA and CN knows that. = Not sure why this is needed.

 

We don't have such an assumption. Maybe you mean this sentence in our = I-D =C2=A0"A notice is that, MN will use HoA to establish the = connection with CN if the DHP query is failed, which means no DHP is = found to=C2=A0 serve the current MN. Later workflow is the same as that = defined in MIPv6." As you can see, it is only a complete = consideration for exception.

 

>>Overall, as you can see from our I-D, we believe dynamically = anchoring the IP address somewhere close to the CN can be achieved = without any protocol work.

 

Actually, I really don't believe we can implement protocol = optimization without doing any change to it. Actually, you definitely = need to change the implementation for MN in your = I-D.

 

 

Min

 

From:= Alper = Yegin [mailto:alper.yegin@yegin.org]
Sent: Thursday, July 25, = 2013 4:03 PM
To: Min Liu
Cc: Jouni Korhonen; = dmm@ietf.org; wangyuwei@ict.ac.cn
Subject: Re: [DMM] = comments/questions of = draft-yegin-dmm-cnet-homing-00

 

Hi = Liu,

 

Yes it seems like we are = approaching the DMM problem in the same = way.

 

At the technical detail level here = are the essential differences between two = I-Ds:

 

- The mobility agent in our case = can even be outside the domain of = CN. 

 

- Your I-D has a very elaborate DHP = discovery, with additional protocol work, some even touching CN. Not = sure why it is needed. We are simply using DNS request for that. It = becomes just a matter of putting the right entry in the = DNS.

 

- Our I-D is not modifying Mobile = IP protocol at all. You seem to define new messaging for HoA discovery, = and also extending BU. Again, not sure why those extensions are = needed.

 

- " MN decides whether the service flow = needs mobility support according to the service type of the new = connection request." This is not clear. In our case the = determination is transparent to the upper layers. If the DNS returns an = IP address for CHA, then CHA is used.



- There's an assumption that MN has = a HoA and CN knows that. Not sure why this is needed.



Overall, as you can see from our = I-D, we believe dynamically anchoring the IP address somewhere close to = the CN can be achieved without any protocol work.



Alper













 

 

 

 

 

 

 

On Jul 24, 2013, at 4:58 PM, = =E5=88=98=E6=95=8F = wrote:




Hi, Alper,

We submited a draft to DMM in March = (http://datatracker.ietf.org/doc/draft-liu-= dmm-flows-distribution-and-handoff/?include_text=3D1) and made a = presentation in last IETF meeting in Orlando. I think the main idea in = your draft is almost the same with our I-D. In our draft, we propose a = new entity named Distributed Home-Proxy (DHP) that is a router near CN, = with the function for an extension of the HA, to assign Distributed Home = Address (DHoA) for the MN to implement router optimization. In your = draft, you propose a Corresponding Home Agent (CHA) located near CNs to = allocate a HoA to the MN (Corresponding Home Address, CHoA). As I see = it, the CHA is just the DHP and CHoA is the same as DHoA. Could you = please explain the new contribution in your = draft?

 

 

Min Liu

Institute of Computing Te= chnology
Chinese Academy of Science


> ----------
> Sender: "Alp= er Yegin" <alper.yegin@yegin.org>
&g= t; Receiver: "Jouni Korhonen" <jouni.nospam@gmail.com>
= > Copy: "dmm@ietf.org" <dmm@ietf.org>
> Subject:&n= bsp;Re: [DMM] comments/questions of draft-yegin-dmm-c= net-homing-00
> 
> 
> On Jul 2= 4, 2013, at 11:56 AM, Jouni Korhonen w= rote:
> 
> > Alper, authors,
>&n= bsp;> 
> > In Section 3. is&nbs= p;states:
> > 
> >  "CHA&= nbsp;may be co-located with the CN, or = ;located in the same site as the
>&nb= sp;>   CN, or located in an IS= P serving that site.  Not all CNs = ;may be
> >   served by a&nbs= p;CHA.  In case there is no CHA s= erving the CN, the MN and
> > = ;  the CN may communicate using the&nb= sp;HoA via the HA.  It is expected&nbs= p;that
> >   CHAs would be de= ployed for dominant content sites on the&nb= sp;Internet
> >   (e.g., YouTube, = Facebook, Netflix, etc.)"
> > 
>&= nbsp;> What would be the motivation or&n= bsp;business reason for a service/content
>&nbs= p;> provider to start offering a mobilit= y anchoring service? High bandwidth
> >=  sites as listed above would need inve= st quite much for such a platform.
>&= nbsp;> 
> 
> Here's our thinking:=
> 
> - The direct benefit of&n= bsp;this approach to the content provider i= s the reduction of transmission latency due=  to elimination of the triangular routes.&n= bsp;This would enhance the their user exper= ience.
> 
> - Considering the overal= l system (w/o distinguishing between the MN= O and the content provider), providing anch= oring/mobility near the CNet as opposed to&= nbsp;doing it at a corner of the Inter= net reduces the overall cost. Given the&nbs= p;savings, the involved parties can find a&= nbsp;fair way to deal with it (i.e., s= ome business deal).
> 
> On top = ;of that, this can be provided by ISPs=  serving the content sites. Such ISPs = can also have a business deal with the=  MNO for taking over the mobility mana= gement load.
> 
> 
> > I&nb= sp;also started thinking that in general th= is solution (and quite many
> > ot= her) seem to assume the CN is more&nbs= p;or less stationary. How would the
> = ;> CHA concept be affected if the C= N is also mobile? Would it allow any> > benefits over the legacy MIP&nb= sp;variants? How would the CHA discovery > > work in this case?
> >=  
> 
> We didn't consider mobil= e CNs. We are going after the major&nb= sp;sources of mobile traffic, which is stem= ming from fixed sites.
> 
> 
>=  > The examples in Sections 3. and&= nbsp;4. show DNS as the discovery mechanism=
> > for the CHA. However, there&n= bsp;is no real description how the discover= y
> > is actually carried out (exc= ept conceptual CHA domain name referred
>&= nbsp;> in Section 3.
> 
> It's&nb= sp;just a matter of storing cha.<yourdomain&g= t; in DNS and looking it up.
> W= e can add some more verbiage, if this&= nbsp;is not clear.
> 
> > Figure&= nbsp;1 step 2). Have you considered other&n= bsp;discovery
> > mechanisms than DNS?
&g= t; > 
> 
> We did some = but this one seemed to be the most&nbs= p;straightforward. 
> Any specific recommendati= ons?
> 
> Alper
> 
> 
>=  
> 
> > - Jouni
> >= ; 
> > 
> > 
> >=  
> > 
> 
> _______________= ________________________________
> dmm mailing list<= br>> dmm@ietf.org
> https://www.ietf.org/m= ailman/listinfo/dmm


 

------=_NextPart_000_0041_01CE89A3.073261E0-- From alper.yegin@yegin.org Fri Jul 26 03:57:09 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE63721F8E2D for ; Fri, 26 Jul 2013 03:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.573 X-Spam-Level: X-Spam-Status: No, score=-102.573 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0aQ1V6ZD3vgO for ; Fri, 26 Jul 2013 03:57:05 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id C15E621F8C71 for ; Fri, 26 Jul 2013 03:57:04 -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 0Lb5jF-1UNKOn1bjt-00kuz9; Fri, 26 Jul 2013 06:56:56 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_48C2F119-993D-4269-9131-DE66AE0E4FF9" From: Alper Yegin In-Reply-To: <004001ce895f$f90b9f70$eb22de50$@ict.ac.cn> Date: Fri, 26 Jul 2013 13:56:46 +0300 Message-Id: <62E70EEB-8557-4E66-8763-C7231492FF4D@yegin.org> References: <8B55D8AB-622D-42DF-A5BC-00BCC1DA9EC4@yegin.org> <18f82da.eed8.14010f95ad8.Coremail.liumin@ict.ac.cn> <5F48E87A-BDBD-48F3-9035-B69087B63D8F@yegin.org> <004001ce895f$f90b9f70$eb22de50$@ict.ac.cn> To: Liu Min X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:Od4KC7h/jD/V2enb7LwvxeZRKgyI+dGYKVxSb61PSuZ ngZBxgdRCMVQ7Q+7wc/x8Eo7i1qRWOOm7U6NONQ0eDt4h6znSQ /ES14i3M5aCOcofuOm+WUSueMVlQCGclUqu+pqD5vdHVqLHBaA COPSbM1qfpY4f5IhDpa0PXPBU3BBqKhm1zO2tjCGKi6goCXj1b WVugJ4TAKBiR5YoeTdcwMXVcEobix2YMK3C3klUt+WhiSezqCQ sFbPfsfSgrgbAxtGjoPJdXgy7TopbdaoNOhVGU9TFNkI/qQOU8 bsFw/xZSoDa6qrJZEDCeccY12YE0lCBluLn6f8jWMEuwCLyp1z 6VtRZj6tqrI27bgdPDTmtKFyOM/8Q+SDUa2+8hnE4/Yg5CVkIr Kxc9uNfEuL/nw== Cc: dmm@ietf.org Subject: Re: [DMM] comments/questions of draft-yegin-dmm-cnet-homing-00 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 10:57:10 -0000 --Apple-Mail=_48C2F119-993D-4269-9131-DE66AE0E4FF9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Liu, On Jul 25, 2013, at 8:54 PM, Liu Min wrote: > Hi Alper, > =20 > >>Yes it seems like we are approaching the DMM problem in the same = way. > =20 > So we have this consensus that the main idea and approach in your I-D = proposed in July 3, 2013 is the same as our I-D proposed in March 10, = 2013. > =20 As you know, the legacy Mobile IP approach is based on locating a HA in = something called "home network". A number of DMM contributions are proposing to add a variant to that: = Locating HA in access network. What your and our I-D are proposing is to add yet another variant: A = third type of place for HA -- somewhere towards the CN. That's all I'm saying. (not the elaborate statement you made above :-) On the other hand exact location of HA, all the related protocol work to = make that happen are all seemingly different in your and our I-D, and = this is what we are discussing below. > =20 > >>At the technical detail level here are the essential differences = between two I-Ds: > >>- The mobility agent in our case can even be outside the domain of = CN. > =20 > In our I-D, we define that "Distributed Home-Proxy (DHP) is a router = near CN". In this way, DHP doesn't have to be located in CN' domain. = However, we do recommend to find a DHP in CN's domain because choosing = DHP in other domains will not guarantee router optimization and thus = violating our original intention to introduce DHP. > Choosing a mobility agent outside the domain of CN makes little sense = since our purpose is to implement router optimization by moving the = mobility agent close to CN. > =20 As long as the mobility agent stays on the most direct data-path between = the MN and CN, then it does not matter where exactly it is. Placing the mobility agent as close to the CN as possible increases that = chance. But that does not mean the CN site is the only place for the mobility = agent. The ISP serving the CN site is another natural place. And it'd work just fine. > >>- Your I-D has a very elaborate DHP discovery, with additional = protocol work, some even touching CN. Not sure why it is needed. We are = simply using DNS request for that. It becomes just a matter of putting = the right entry in the DNS. > =20 > In our I-D, we have provided several options for DHP discovery and DNS = request is also used. For example, "MN query the DNS to get the DHP = anycast address", "MN can use DNS to query the DHP management server = address." Actually, we assume there may exist more than one DHP in one = domain. MIPv6 also assumes there may exist more than one HA in one = domain. Maybe you'd consider down-selecting them. Not only too many, but still I = don't understand why a simple DNS-based lookup like we propose is not = sufficient.=20 > =20 > >>- Our I-D is not modifying Mobile IP protocol at all. You seem to = define new messaging for HoA discovery, and also extending BU. Again, = not sure why those extensions are needed. > =20 > Our I-D is totally compatible with Mobile IP protocol. For DHP = discovery, as we mentioned in our I-D "This procedure is similar to = "dynamic home agent address discovery mechanism" in MIPv6". Besides, we = provide other options for performance optimization. > =20 "Compatible" term needs expanding. What I mean is "we use Mobile IP as-is". We don't need to change, add, = extend anything on that. In other words, we do not require any "protocol = work". > >>- " MN decides whether the service flow needs mobility support = according to the service type of the new connection request." This is = not clear. In our case the determination is transparent to the upper = layers. If the DNS returns an IP address for CHA, then CHA is used. > =20 > Router optimization is just one purpose of our I-D, besides that we = also support flow management and flow handoff for high level users. Of = course, users can choose not to use such functions, just as you = mentioned. I thought your I-D did one thing, and it's explained in terms of = managing flows (with the CNs). Now that you are referring to two = separate things: "router optimization" and "flow management and flow = handoff" suggests that I'm missing one of the two things=E2=80=A6=20 Besides, coming back to my question: How does MN decide whether a = service flow needs mobility support? What are the service types? How are = they conveyed from the applications(?) to the IP stack. These are the = questions that arise when reading that statement in your I-D. > >>- There's an assumption that MN has a HoA and CN knows that. Not = sure why this is needed. > =20 > We don't have such an assumption. Maybe you mean this sentence in our = I-D "A notice is that, MN will use HoA to establish the connection with = CN if the DHP query is failed, which means no DHP is found to serve the = current MN. Later workflow is the same as that defined in MIPv6." As you = can see, it is only a complete consideration for exception. > =20 Your I-D says: This standard is compliant with standard MIPv6, which means MN still has HoA in home domain. When MN is initiating a new connection with DMIPv6, it will first apply for DHoA. According to MIPv6, MN's HoA is permanent during in its travelling, so CN always knows its HoA. > >>Overall, as you can see from our I-D, we believe dynamically = anchoring the IP address somewhere close to the CN can be achieved = without any protocol work. > =20 > Actually, I really don't believe we can implement protocol = optimization without doing any change to it. Actually, you definitely = need to change the implementation for MN in your I-D. > =20 There's implementation work to be applied to MN, yes.=20 The question is: Do we need to modify Mobile IP, or do we need to design = a new protocol?=20 Our I-D says no. Yours says yes.=20 That's also a difference, or a consequence of a number of differences = between the two I-Ds. Alper > =20 > Min > =20 > From: Alper Yegin [mailto:alper.yegin@yegin.org]=20 > Sent: Thursday, July 25, 2013 4:03 PM > To: Min Liu > Cc: Jouni Korhonen; dmm@ietf.org; wangyuwei@ict.ac.cn > Subject: Re: [DMM] comments/questions of = draft-yegin-dmm-cnet-homing-00 > =20 > Hi Liu, > =20 > Yes it seems like we are approaching the DMM problem in the same way. > =20 > At the technical detail level here are the essential differences = between two I-Ds: > =20 > - The mobility agent in our case can even be outside the domain of CN.=20= > =20 > - Your I-D has a very elaborate DHP discovery, with additional = protocol work, some even touching CN. Not sure why it is needed. We are = simply using DNS request for that. It becomes just a matter of putting = the right entry in the DNS. > =20 > - Our I-D is not modifying Mobile IP protocol at all. You seem to = define new messaging for HoA discovery, and also extending BU. Again, = not sure why those extensions are needed. > =20 > - " MN decides whether the service flow needs mobility support = according to the service type of the new connection request." This is = not clear. In our case the determination is transparent to the upper = layers. If the DNS returns an IP address for CHA, then CHA is used. >=20 >=20 > - There's an assumption that MN has a HoA and CN knows that. Not sure = why this is needed. >=20 >=20 > Overall, as you can see from our I-D, we believe dynamically anchoring = the IP address somewhere close to the CN can be achieved without any = protocol work. >=20 >=20 > Alper >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > =20 > =20 > =20 > =20 > =20 > =20 > =20 > On Jul 24, 2013, at 4:58 PM, =E5=88=98=E6=95=8F wrote: >=20 >=20 >=20 > Hi, Alper, > We submited a draft to DMM in March = (http://datatracker.ietf.org/doc/draft-liu-dmm-flows-distribution-and-hand= off/?include_text=3D1) and made a presentation in last IETF meeting in = Orlando. I think the main idea in your draft is almost the same with our = I-D. In our draft, we propose a new entity named Distributed Home-Proxy = (DHP) that is a router near CN, with the function for an extension of = the HA, to assign Distributed Home Address (DHoA) for the MN to = implement router optimization. In your draft, you propose a = Corresponding Home Agent (CHA) located near CNs to allocate a HoA to the = MN (Corresponding Home Address, CHoA). As I see it, the CHA is just the = DHP and CHoA is the same as DHoA. Could you please explain the new = contribution in your draft? > =20 > =20 > Min Liu >=20 > Institute of Computing Technology > Chinese Academy of Science >=20 > > ---------- > > Sender: "Alper Yegin" > > Receiver: "Jouni Korhonen" > > Copy: "dmm@ietf.org" > > Subject: Re: [DMM] comments/questions of = draft-yegin-dmm-cnet-homing-00 > >=20 > >=20 > > On Jul 24, 2013, at 11:56 AM, Jouni Korhonen wrote: > >=20 > > > Alper, authors, > > >=20 > > > In Section 3. is states: > > >=20 > > > "CHA may be co-located with the CN, or located in the same site = as the > > > CN, or located in an ISP serving that site. Not all CNs may be > > > served by a CHA. In case there is no CHA serving the CN, the MN = and > > > the CN may communicate using the HoA via the HA. It is expected = that > > > CHAs would be deployed for dominant content sites on the = Internet > > > (e.g., YouTube, Facebook, Netflix, etc.)" > > >=20 > > > What would be the motivation or business reason for a = service/content > > > provider to start offering a mobility anchoring service? High = bandwidth > > > sites as listed above would need invest quite much for such a = platform. > > >=20 > >=20 > > Here's our thinking: > >=20 > > - The direct benefit of this approach to the content provider is the = reduction of transmission latency due to elimination of the triangular = routes. This would enhance the their user experience. > >=20 > > - Considering the overall system (w/o distinguishing between the MNO = and the content provider), providing anchoring/mobility near the CNet as = opposed to doing it at a corner of the Internet reduces the overall = cost. Given the savings, the involved parties can find a fair way to = deal with it (i.e., some business deal). > >=20 > > On top of that, this can be provided by ISPs serving the content = sites. Such ISPs can also have a business deal with the MNO for taking = over the mobility management load. > >=20 > >=20 > > > I also started thinking that in general this solution (and quite = many > > > other) seem to assume the CN is more or less stationary. How would = the > > > CHA concept be affected if the CN is also mobile? Would it allow = any > > > benefits over the legacy MIP variants? How would the CHA discovery=20= > > > work in this case? > > >=20 > >=20 > > We didn't consider mobile CNs. We are going after the major sources = of mobile traffic, which is stemming from fixed sites. > >=20 > >=20 > > > The examples in Sections 3. and 4. show DNS as the discovery = mechanism > > > for the CHA. However, there is no real description how the = discovery > > > is actually carried out (except conceptual CHA domain name = referred > > > in Section 3. > >=20 > > It's just a matter of storing cha. in DNS and looking it = up. > > We can add some more verbiage, if this is not clear. > >=20 > > > Figure 1 step 2). Have you considered other discovery > > > mechanisms than DNS? > > >=20 > >=20 > > We did some but this one seemed to be the most straightforward.=20 > > Any specific recommendations? > >=20 > > Alper > >=20 > >=20 > >=20 > >=20 > > > - Jouni > > >=20 > > >=20 > > >=20 > > >=20 > > >=20 > >=20 > > _______________________________________________ > > dmm mailing list > > dmm@ietf.org > > https://www.ietf.org/mailman/listinfo/dmm >=20 >=20 >=20 --Apple-Mail=_48C2F119-993D-4269-9131-DE66AE0E4FF9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hi Liu,

On Jul 25, 2013, at 8:54 = PM, Liu Min wrote:

Hi Alper,
>>Yes it seems like we are approaching the DMM = problem in the same way.
 
So we have this = consensus that the main idea and approach in your I-D proposed in July = 3, 2013 is the same as our I-D proposed in March 10, = 2013.
 
A number of DMM contributions = are proposing to add a variant to that: Locating HA in access = network.
What your and our I-D are proposing is to add yet = another variant: A third type of place for HA -- somewhere towards the = CN.
That's all I'm saying. (not the elaborate statement you = made above :-)
On the other hand exact location of HA, all the = related protocol work to make that happen are all seemingly different in = your and our I-D, and this is what we are discussing = below.


 
>>At the technical = detail level here are the essential differences between two = I-Ds:
>>- The mobility agent in our case can even be = outside the domain of CN.
 
In our I-D, we define = that "Distributed Home-Proxy (DHP)  is a router near CN".  In = this way, DHP doesn't have to be located in CN' domain. However, we do = recommend to find a DHP in CN's domain because choosing DHP in other = domains will not guarantee router optimization and thus violating our = original intention to introduce DHP.
Choosing a mobility = agent outside the domain of CN makes little sense since our purpose is = to implement router optimization by moving the mobility agent close to = CN.
>>- Your I-D has a very elaborate DHP = discovery, with additional protocol work, some even touching CN. Not = sure why it is needed. We are simply using DNS request for that. It = becomes just a matter of putting the right entry in the = DNS.
 
In our I-D, we have = provided several options for DHP discovery and DNS request is also used. = For example, "MN query the DNS to get the DHP anycast address", "MN can = use DNS to query the DHP management server address."  Actually, we = assume there may exist more than one DHP in one domain. MIPv6 also = assumes there may exist more than one HA in one = domain.
 
>>- Our I-D is not = modifying Mobile IP protocol at all. You seem to define new messaging = for HoA discovery, and also extending BU. Again, not sure why those = extensions are needed.
 
Our I-D is totally = compatible with Mobile IP protocol. For DHP discovery, as we mentioned = in our I-D "This procedure is similar to "dynamic home agent address = discovery mechanism" in MIPv6". Besides, we provide other options for = performance optimization.
What I mean is = "we use Mobile IP as-is". We don't need to change, add, extend anything = on that. In other words, we do not require any "protocol = work".


>>- " MN decides whether the service flow = needs mobility support according to the service type of the new = connection request." This is not clear. In our case the determination is = transparent to the upper layers. If the DNS returns an IP address for = CHA, then CHA is used.
 
Router optimization is = just one purpose of our I-D, besides that we also support flow = management and flow handoff for high level users. Of course, users can = choose not to use such functions, just as you = mentioned.

Besides, coming back to = my question: How does MN decide whether a service flow needs mobility = support? What are the service types? How are they conveyed from the = applications(?) to the IP stack. These are the questions that arise when = reading that statement in your = I-D.



>>- = There's an assumption that MN has a HoA and CN knows that. Not sure why = this is needed.
 
We don't have such an = assumption. Maybe you mean this sentence in our I-D  "A notice is = that, MN will use HoA to establish the connection with CN if the DHP = query is failed, which means no DHP is found to  serve the current = MN. Later workflow is the same as that defined in MIPv6." As you can = see, it is only a complete consideration for = exception.
This standard is compliant with standard MIPv6, which = means MN still has HoA in home domain. When MN is initiating a new connection with DMIPv6, it will first apply for DHoA. According to MIPv6, MN's HoA is permanent during in its travelling, so CN always knows its = HoA.




>>Overall, as you = can see from our I-D, we believe dynamically anchoring the IP address = somewhere close to the CN can be achieved without any protocol = work.
 
Actually, I really don't = believe we can implement protocol optimization without doing any change = to it. Actually, you definitely need to change the implementation for MN = in your I-D.
Min
 
 Alper Yegin = [mailto:alper.yegin@yegin.org] 
Sent: Thursday, July 25, 2013 = 4:03 PM
To: Min Liu
Cc: Jouni Korhonen; dmm@ietf.org; wangyuwei@ict.ac.cn
Subject:=  Re: [DMM] = comments/questions of = draft-yegin-dmm-cnet-homing-00
 
Hi Liu,
 
Yes it seems like we are approaching the DMM = problem in the same way.
 
At the technical detail level here are the = essential differences between two = I-Ds:
 
- The mobility agent in our case can even be = outside the domain of CN. 
 
- Your I-D has a very elaborate DHP discovery, = with additional protocol work, some even touching CN. Not sure why it is = needed. We are simply using DNS request for that. It becomes just a = matter of putting the right entry in the = DNS.
 
- Our I-D is not modifying Mobile IP protocol at = all. You seem to define new messaging for HoA discovery, and also = extending BU. Again, not sure why those extensions are = needed.
 
- " MN decides whether the = service flow needs mobility support according to the service type of the = new connection request." This is not clear. In our case the = determination is transparent to the upper layers. If the DNS returns an = IP address for CHA, then CHA is used.


- There's an assumption that MN has a HoA and CN knows = that. Not sure why this is needed.


Overall, as you can see from our I-D, we believe = dynamically anchoring the IP address somewhere close to the CN can be = achieved without any protocol work.


Alper












 
 
 
 
 
 
 
On Jul 24, 2013, at 4:58 PM, =E5=88=98=E6=95=8F wrote:



Hi, Alper,
We submited a draft to DMM in March (http://datatracker.ietf.org/doc/draft-liu-dmm-flows-distribution-and-han= doff/?include_text=3D1) and made a presentation in last IETF meeting = in Orlando. I think the main idea in your draft is almost the same with = our I-D. In our draft, we propose a new entity named Distributed = Home-Proxy (DHP) that is a router near CN, with the function for an = extension of the HA, to assign Distributed Home Address (DHoA) for the = MN to implement router optimization. In your draft, you propose a = Corresponding Home Agent (CHA) located near CNs to allocate a HoA to the = MN (Corresponding Home Address, CHoA). As I see it, the CHA is just the = DHP and CHoA is the same as DHoA. Could you please explain the new = contribution in your draft?
 
 
Min Liu

Institute of Computing T= echnology
Chinese Academy of Science


> ----------
> Sender: "Alper&n= bsp;Yegin" <dmm@ietf.org" <> >   CN, or = ;located in an ISP serving that site. &= nbsp;Not all CNs may be
> >  &= nbsp;served by a CHA.  In case there&nb= sp;is no CHA serving the CN, the MN&nbs= p;and
> >   the CN may communi= cate using the HoA via the HA.  It=  is expected that
> >   CHAs&n= bsp;would be deployed for dominant content s= ites on the Internet
> >   (e.= g., YouTube, Facebook, Netflix, etc.)"
> &g= t; 
> > What would be the moti= vation or business reason for a service/cont= ent
> > provider to start offering = a mobility anchoring service? High bandwidth
&= gt; > sites as listed above would ne= ed invest quite much for such a platfor= m.
> > 
> 
> Here's our = ;thinking:
> 
> - The direct benefit&= nbsp;of this approach to the content provide= r is the reduction of transmission latency&n= bsp;due to elimination of the triangular rou= tes. This would enhance the their user = experience.
> 
> - Considering the ov= erall system (w/o distinguishing between the = ;MNO and the content provider), providing an= choring/mobility near the CNet as opposed to=  doing it at a corner of the Inter= net reduces the overall cost. Given the = ;savings, the involved parties can find a&nb= sp;fair way to deal with it (i.e., some=  business deal).
> 
> On top of&= nbsp;that, this can be provided by ISPs = ;serving the content sites. Such ISPs can&nb= sp;also have a business deal with the M= NO for taking over the mobility management&n= bsp;load.
> 
> 
> > I also&n= bsp;started thinking that in general this so= lution (and quite many
> > other) s= eem to assume the CN is more or le= ss stationary. How would the
> > CH= A concept be affected if the CN is = ;also mobile? Would it allow any
> >= ; benefits over the legacy MIP variants?&nbs= p;How would the CHA discovery 
> >&= nbsp;work in this case?
> > 
>&nbs= p;
> We didn't consider mobile CNs. We=  are going after the major sources of&n= bsp;mobile traffic, which is stemming from f= ixed sites.
> 
> 
> > The&nb= sp;examples in Sections 3. and 4. show = DNS as the discovery mechanism
> > = for the CHA. However, there is no real&= nbsp;description how the discovery
> > i= s actually carried out (except conceptual CH= A domain name referred
> > in Secti= on 3.
> 
> It's just a matter&nb= sp;of storing cha.<yourdomain> in DNS and&n= bsp;looking it up.
> We can add some&n= bsp;more verbiage, if this is not clear.
= > 
> > Figure 1 step 2). Ha= ve you considered other discovery
> >&nb= sp;mechanisms than DNS?
> > 
> > We did some but this one seemed&n= bsp;to be the most straightforward. 
> = ;Any specific recommendations?
> 
> Alper<= br>> 
> 
> 
> 
> >&= nbsp;- Jouni
> > 
> > 
>&= nbsp;> 
> > 
> > 
>&nb= sp;
> _______________________________________________
>&n= bsp;dmm mailing list
> dmm@ietf.org
> 


<= /body>= --Apple-Mail=_48C2F119-993D-4269-9131-DE66AE0E4FF9-- From alper.yegin@yegin.org Fri Jul 26 04:14:54 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9665321F9302 for ; Fri, 26 Jul 2013 04:14:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.577 X-Spam-Level: X-Spam-Status: No, score=-102.577 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V5nftpyMcy9j for ; Fri, 26 Jul 2013 04:14:49 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by ietfa.amsl.com (Postfix) with ESMTP id A314B21F8A64 for ; Fri, 26 Jul 2013 04:14: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=mrus3) with ESMTP (Nemesis) id 0Lm30z-1UTtOP0UGf-00ZtTm; Fri, 26 Jul 2013 07:14:43 -0400 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_21FD3803-9A13-42C4-909B-9231388731D7" From: Alper Yegin In-Reply-To: <6759_1374758673_51F12711_6759_72_1_C5B6A9A3D7D5C941A08B34159DEFE9020FF8534C@PEXCVZYM11.corporate.adroot.infra.ftgroup> Date: Fri, 26 Jul 2013 14:14:34 +0300 Message-Id: <2A3AF319-E618-4CF1-B4A8-63330822EC54@yegin.org> References: <315CD997-1396-423F-8355-0C17A133FA42@gmail.com> <5CD750DD-D753-46B1-8A3A-DECE21EB63DC@yegin.org> <5963DDF1F751474D8DEEFDCDBEE43AE716F50653@dfweml512-mbx.china.huawei.com> <40C982AA-70F5-4059-A728-8194FA82D150@yegin.org> <5963DDF1F751474D8DEEFDCDBEE43AE716F50828@dfweml512-mbx.china.huawei.com> <6759_1374758673_51F12711_6759_72_1_C5B6A9A3D7D5C941A08B34159DEFE9020FF8534C@PEXCVZYM11.corporate.adroot.infra.ftgroup> To: X-Mailer: Apple Mail (2.1283) X-Provags-ID: V02:K0:PWqSuGRMDv0B8NVfkAXj3vx0ukcDIco1wjYBBRNiG0I 0OcP9y5TTBNka493fpDyXX34O66D4/RW8z91tOd6juT8cipkek favaJrb8rf1MGva2bBDLuFP6O5psn+xaYFGoZrDMFFfVXS1G0h b2/biaZrF3m+mEc1piKBojtIiuVNHzGvwBIb2/LRCy4xyLpT5Q YpAf8cH23qo4aO6hJyZGHwPFrzMWJnk8knGo6wZxogsYJFGhFG 9xMKATRUlvRu3ZHY64/R5ytDgXmowKbbM0kT87wNUeHDhYqEth Gbz3rXQxg3033t/WDIhq/8hUM/wygmdekdXvl3lU7xNxik33ve uc9f8pJtJADXWIDMzFFpbcCAth+ZJ5ju7NJOuoGeYXEIQGPdZ0 v5P550SGgcgBA== Cc: Peter McCann , "dmm@ietf.org" Subject: Re: [DMM] comments/questions on draft-yegin-dmm-ondemand-mobility-00 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 11:14:54 -0000 --Apple-Mail=_21FD3803-9A13-42C4-909B-9231388731D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello Hassan, On Jul 25, 2013, at 4:24 PM, = wrote: > Hi Alper, Peter and Jouni, >=20 > Sorry for jumping to this discussion, I have two comments below. >=20 You are more than welcome :-) Please see below. >>=20 >> That's another level of reachability. >> See, there's a chain of mapping: ID at app-level -> FQDN -> IP = address -> >> L2 address -> L1 address. >>=20 >> I think you are referring to FQDN reachability. >> But in this MIP-land, we are concerned about IP address reachability = part >> of the problem. >>=20 >=20 > [Hassan] Why we need IP address reachability? Can you please address = some concrete use-case scenarios.=20 >=20 Providing a fixed/stable IP address to the MN is a rare, but existing = use case. Mobile servers need that. They cannot survive client communication if = their IP address changes. An enterprise user connecting to his company intranet via cellular = network gets an IP address out of his intranet. This is like a VLAN. Cellular operators are already marketing "fixed IP" as part of their = service.=20 > Upper level reachability is sufficient for an incoming e.g. VoIP call = or SMS to a typical MN, and also even if we imagine an MN acting as a = server and hosting e.g. a website, no one memorize IP addresses. >=20 Most of the time, yes, no one memorizes the IP addresses. They memorize = the DNS name. But once the DNS resolves a name to an IP address, they = stick to that IP address. So, that IP address better be stay the same, = otherwise the communication breaks.=20 >>=20 >>>>> A static coloring >>>>> of prefixes at the time they are assigned is not good enough. We >>>>> really need to know how many references to an address are >>>>> outstanding everywhere in the system, and garbage collect old >>>>> addresses when these reference counts go to zero. Of course, we >>>>> cannot hope to keep track of all the places throughout the = Internet >>>>> that have cached a given IP address associated to an MN, but we = can >>>>> at least attempt to provide an approximation to this abstract = idea. >>>>>=20 >>>>> Also, I take issue with the use of "anchored" to distinguish = address >>>>> types. It is possible for an address to be persistently assigned >>>>> without being "anchored" on any one given endpoint, especially if = we >>>>> use routing instead of tunneling to maintain the connectivity. >>>>>=20 >>>>=20 >>>> If one can propagate host routes across the Internet, then the = anchor >>>> aspect disappears. >>>=20 >>> Maybe you need an anchor after you have moved a certain distance in >>> the Internet topology, but not before. And there is no need for = that >>> anchor to be the same as the first access router that assigned the >> address. >>>=20 >>=20 >> That statement would be true assuming again there's some kind of >> host/prefix-specific route propagation. >>=20 >>>=20 >>> An MN should be able, at any time, to get a fresh IP address (in >>> general, we should be talking about a prefix) that is topologically >>> matched to its current attachment point. That prefix will be = routable >>> over a certain set of other attachment points by network-based = means, >>> and some mechanism should be provided to inform the MN whether the >>> prefix is still on-link at any new attachment point (perhaps as = simple >>> as an RA, or something more optimal could be developed for specific >>> link technologies). If the address is no longer on-link, the MN >>> should be able to get a new prefix and set up a tunnel from an HA to >>> its current attachment point. The HA and the HA-MN security >>> association should be established simultaneously with the assignment >>> of the original prefix (this step is optional if the network that >>> originally assigned the prefix doesn't want to provide global = mobility >> for that prefix). >>>=20 >>> The MN thus maintains a pool of prefixes, and should be able to = renew >>> its lease on any prefix remotely from wherever it happens to be >>> currently attached. It is entirely up to the MN to decide of which >>> prefixes it needs to maintain ownership, whether to register any of >>> these addresses in DNS, and to decide which prefixes are no longer >>> needed by any applications and can be returned to the network(s) = that >> assigned them. >>>=20 >>> It's possible that one or more of these addresses are "permanently" >>> assigned to the MN (for some definition of "permanent") and provide = the >> "reachability" >>> property that you defined in the draft. However, that's merely a >>> configuration and deployment consideration. >>>=20 >>=20 >> These above makes sense to me. >=20 > [Hassan] I agree that it makes sense to keep one of the addresses = permanent (assuming we really need this). However, we will need one = permanent anchor and data packets of incoming sessions/calls should be = routed through it and then tunneled to the MN. Similar issues to the = ones addressed to current IP mobility protocols in DMM problem statement = will be raised, but only for incoming sessions/calls.=20 >=20 > In fact, I consider this approach as an integrated DMM--MIPv6 = approach: MIPv6 manages a permanent HA and HoA for MN's reachability at = IP address level for incoming sessions, and DMM for sessions initiated = by the MN itself. Imagine mobile CNs --> DMM will be used less and MIPv6 = more. I don't like semi-solutions :) >=20 Oh, actually I'm not saying every MN shall have a Home Network Anchored = Address. I'm saying some need it, and only those shall get it. Alper >=20 >>=20 >> Alper >>=20 >>=20 >>=20 >>=20 >>> -Pete >>>=20 >>=20 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 --Apple-Mail=_21FD3803-9A13-42C4-909B-9231388731D7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hello = Hassan,

Hi Alper, Peter and Jouni,

Sorry for jumping = to this discussion, I have two comments = below.


You are more than = welcome :-)
Please see below.


That's= another level of reachability.
See, there's a chain of mapping: ID at app-level -> = FQDN -> IP address ->
L2 = address -> L1 address.

I think you are = referring to FQDN reachability.
But in this MIP-land, we are concerned about IP address = reachability part
of the = problem.


[Hassan] Why we need IP address = reachability? Can you please address some concrete use-case scenarios. =


Providing a fixed/stable = IP address to the MN is a rare, but existing use = case.

Mobile servers need that. They cannot = survive client communication if their IP address changes.
An = enterprise user connecting to his company intranet via cellular network = gets an IP address out of his intranet. This is like a = VLAN.
Cellular operators are already marketing "fixed IP" as = part of their = service. 



Upper level reachability is sufficient for an = incoming e.g. VoIP call or SMS to a typical MN, and also even if we = imagine an MN acting as a server and hosting e.g. a website, no one = memorize IP = addresses.


Most of the = time, yes, no one memorizes the IP addresses. They memorize the DNS = name. But once the DNS resolves a name to an IP address, they stick to = that IP address. So, that IP address better be stay the same, otherwise = the communication breaks. 



A static = coloring
of prefixes at the time they are = assigned is not good enough. =  We
really need to know how many = references to an address = are
outstanding everywhere in the = system, and garbage collect = old
addresses when these reference = counts go to zero.  Of course, = we
cannot hope to keep track of all = the places throughout the = Internet
that have cached a given IP = address associated to an MN, but we = can
at least attempt to provide an = approximation to this abstract = idea.

Also, I take issue with the use = of "anchored" to distinguish = address
types. It is possible for an = address to be persistently = assigned
without being "anchored" on any = one given endpoint, especially if = we
use routing instead of tunneling = to maintain the = connectivity.


If one = can propagate host routes across the Internet, then the = anchor
aspect = disappears.

Maybe you need an anchor after = you have moved a certain distance = in
the Internet topology, but not before.  And there is = no need for that
anchor to be the same as the = first access router that assigned = the
address.


That statement = would be true assuming again there's some kind = of
host/prefix-specific route = propagation.


An MN should be able, at any = time, to get a fresh IP address = (in
general, we should be talking about a prefix) that is = topologically
matched to its current = attachment point.  That prefix will be = routable
over a certain set of other = attachment points by network-based = means,
and some mechanism should be provided to inform the MN = whether the
prefix is still on-link at any = new attachment point (perhaps as = simple
as an RA, or something more optimal could be developed for = specific
link technologies).  If the = address is no longer on-link, the = MN
should be able to get a new prefix and set up a tunnel = from an HA to
its current attachment point. =  The HA and the HA-MN = security
association should be = established simultaneously with the = assignment
of the original prefix (this = step is optional if the network = that
originally assigned the prefix doesn't want to provide = global mobility
for= that prefix).

The MN thus maintains a pool of = prefixes, and should be able to = renew
its lease on any prefix remotely from wherever it happens = to be
currently attached.  It is entirely up to the MN to = decide of which
prefixes it needs to maintain = ownership, whether to register any = of
these addresses in DNS, and to decide which prefixes are = no longer
needed by any applications and = can be returned to the network(s) = that
assigned = them.

It's possible that one or more = of these addresses are = "permanently"
assigned to the MN (for some = definition of "permanent") and provide = the
"reachability"
property that you defined in the = draft.  However, that's merely = a
configuration and deployment = consideration.


These above = makes sense to me.

[Hassan] I agree that it makes = sense to keep one of the addresses permanent (assuming we really need = this). However, we will need one permanent anchor and data packets of = incoming sessions/calls should be routed through it and then tunneled to = the MN. Similar issues to the ones addressed to current IP mobility = protocols in DMM problem statement will be raised, but only for incoming = sessions/calls.

In fact, I consider this approach as an = integrated DMM--MIPv6 approach: MIPv6 manages a permanent HA and HoA for = MN's reachability at IP address level for incoming sessions, and DMM for = sessions initiated by the MN itself. Imagine mobile CNs --> DMM will = be used less and MIPv6 more. I don't like semi-solutions = :)


Oh, actually I'm not = saying every MN shall have a Home Network Anchored = Address.
I'm saying some need it, and only those shall get = it.

Alper






Alper




-Pete


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

_______________________________= __________________________________________________________________________= ________________

Ce message et ses pieces jointes peuvent = contenir des informations confidentielles ou privilegiees et ne doivent = donc
pas etre diffuses, exploites ou copies sans autorisation. Si = vous avez recu ce message par erreur, veuillez le signaler
a = l'expediteur et le detruire ainsi que les pieces jointes. Les messages = electroniques etant susceptibles d'alteration,
Orange decline toute = responsabilite si ce message a ete altere, deforme ou falsifie. = Merci.

This message and its attachments may contain confidential = or privileged information that may be protected by law;
they should = not be distributed, used or copied without authorisation.
If you have = received this email in error, please notify the sender and delete this = message and its attachments.
As emails may be altered, Orange is not = liable for messages that have been modified, changed or = falsified.
Thank = you.


= --Apple-Mail=_21FD3803-9A13-42C4-909B-9231388731D7-- From liumin@ict.ac.cn Fri Jul 26 13:10:09 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 95FBD21F9A3C for ; Fri, 26 Jul 2013 13:10:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.158 X-Spam-Level: X-Spam-Status: No, score=0.158 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9o5GhDH86x04 for ; Fri, 26 Jul 2013 13:10:05 -0700 (PDT) Received: from cstnet.cn (smtp17.cstnet.cn [IPv6:2001:cc0:2fff:7::17]) by ietfa.amsl.com (Postfix) with ESMTP id 139A021F9A43 for ; Fri, 26 Jul 2013 13:09:54 -0700 (PDT) Received: by ajax-webmail-app9 (Coremail) ; Sat, 27 Jul 2013 04:09:48 +0800 (GMT+08:00) Date: Sat, 27 Jul 2013 04:09:48 +0800 (GMT+08:00) From: =?utf-8?B?5YiY5pWP?= To: "Alper Yegin" Message-ID: <7c6584.25f2.1401c99fb65.Coremail.liumin@ict.ac.cn> In-Reply-To: <62E70EEB-8557-4E66-8763-C7231492FF4D@yegin.org> References: <8B55D8AB-622D-42DF-A5BC-00BCC1DA9EC4@yegin.org> <18f82da.eed8.14010f95ad8.Coremail.liumin@ict.ac.cn> <5F48E87A-BDBD-48F3-9035-B69087B63D8F@yegin.org> <004001ce895f$f90b9f70$eb22de50$@ict.ac.cn> <62E70EEB-8557-4E66-8763-C7231492FF4D@yegin.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_34110_27480896.1374869388131" X-Originating-IP: [217.227.1.135] X-Priority: 3 X-Mailer: Coremail Webmail Server Version XT2.1.10 dev build 20130508(22118.5358.5168) Copyright (c) 2002-2013 www.mailtech.cn cstnet X-SendMailWithSms: false X-CM-CTRLDATA: CfUyjmZvb3Rlcl9odG09Mzk0MDc6MTImZm9vdGVyX3R4dD0xMzY2Mjo2 X-CM-TRANSID: VgCowJBLr+2M1_JRkcoBAA--.1735W X-CM-SenderInfo: 5olxzxnq6lu3wodfhubq/1tbiAw8MEFD7NdZOmwAFsI X-Coremail-Antispam: 1Ur529EdanIXcx71UUUUU7IcSsGvfJ3iIAIbVAYjsxI4VWxJw CS07vEb4IE77IF4wCS07vE1I0E4x80FVAKz4kxMIAIbVAFxVCaYxvI4VCIwcAKzIAtYxBI daVFxhVjvjDU= Cc: dmm@ietf.org Subject: Re: [DMM] comments/questions of draft-yegin-dmm-cnet-homing-00 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 20:10:09 -0000 ------=_Part_34110_27480896.1374869388131 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: base64 SGkgQWxwZXIsCgogCgo+PkFzIGxvbmcgYXMgdGhlIG1vYmlsaXR5IGFnZW50IHN0YXlzIG9uIHRo ZSBtb3N0IGRpcmVjdCBkYXRhLXBhdGggYmV0d2VlbiB0aGUgTU4gYW5kIENOLCB0aGVuIGl0IGRv ZXMgbm90IG1hdHRlciB3aGVyZSBleGFjdGx5IGl0IGlzLgoKPj5QbGFjaW5nIHRoZSBtb2JpbGl0 eSBhZ2VudCBhcyBjbG9zZSB0byB0aGUgQ04gYXMgcG9zc2libGUgaW5jcmVhc2VzIHRoYXQgY2hh bmNlLgoKPj5CdXQgdGhhdCBkb2VzIG5vdCBtZWFuIHRoZSBDTiBzaXRlIGlzIHRoZSBvbmx5IHBs YWNlIGZvciB0aGUgbW9iaWxpdHkgYWdlbnQuCgo+PlRoZSBJU1Agc2VydmluZyB0aGUgQ04gc2l0 ZSBpcyBhbm90aGVyIG5hdHVyYWwgcGxhY2UuCgo+PkFuZCBpdCdkIHdvcmsganVzdCBmaW5lLgoK QXMgSSBtZW50aW9uZWQsIGluIG91ciBJLUQgd2UganVzdCBkZWZpbmUgdGhhdCAiRGlzdHJpYnV0 ZWQgSG9tZS1Qcm94eSAoREhQKSAgaXMgYSByb3V0ZXIgbmVhciBDTiIuIEluIHRoaXMgd2F5LCBE SFAgZG9lc24ndCBoYXZlIHRvIGJlIGxvY2F0ZWQgaW4gQ04nIGRvbWFpbi4gSG93ZXZlciwgd2Ug cmVjb21tZW5kIHRvIGZpbmQgYSBESFAgaW4gQ04ncyBkb21haW4gYmVjYXVzZSBjaG9vc2luZyBE SFAgaW4gb3RoZXIgZG9tYWlucyB3aWxsIG5vdCBndWFyYW50ZWUgcm91dGVyIG9wdGltaXphdGlv biBhbmQgaW5jcmVhc2UgdGhlIG1hbmFnZW1lbnQgYW5kIGRlcGxveW1lbnQgY29zdCBvZiBESFAu CgogCgoKPj4iQ29tcGF0aWJsZSIgdGVybSBuZWVkcyBleHBhbmRpbmcuCj4+V2hhdCBJIG1lYW4g aXMgIndlIHVzZSBNb2JpbGUgSVAgYXMtaXMiLiBXZSBkb24ndCBuZWVkIHRvIGNoYW5nZSwgYWRk LCBleHRlbmQgYW55dGhpbmcgb24gdGhhdC4gSW4gb3RoZXIgd29yZHMsIHdlIGRvIG5vdCByZXF1 aXJlIGFueSAicHJvdG9jb2wgd29yayIuCgpJIHJlYWxseSBkb24ndCB1bmRlcnN0YW5kIHlvdXIg ZGVmaW5pdGlvbiBvZiAicHJvdG9jb2wgd29yayIuIFlvdSBjaGFuZ2UgdGhlIGFyY2hpdGVjdHVy ZSwgdGhlIG9wZXJhdGlvbiBwcm9jZXNzIGFuZCB0aGUgaW1wbGVtZW50YXRpb24gb2YgTW9iaWxl IElQLCBidXQgeW91IHN0aWxsIHRoaW5rIHlvdSBkbyBub3QgcmVxdWlyZSBhbnkgInByb3RvY29s IHdvcmsiLiBBcyBJIHNlZSBpdCwgd2hhdCB5b3UgaGF2ZSBkb25lIGlzIGV4YWN0bHkgZXhwYW5k aW5nIHRvIE1vYmlsZSBJUC4KCgo+PllvdXIgSS1EIHNheXM6CiAgIFRoaXMgc3RhbmRhcmQgaXMg Y29tcGxpYW50IHdpdGggc3RhbmRhcmQgTUlQdjYsIHdoaWNoIG1lYW5zIE1OIHN0aWxsCiAgIGhh cyBIb0EgaW4gaG9tZSBkb21haW4uIFdoZW4gTU4gaXMgaW5pdGlhdGluZyBhIG5ldyBjb25uZWN0 aW9uIHdpdGgKICAgRE1JUHY2LCBpdCB3aWxsIGZpcnN0IGFwcGx5IGZvciBESG9BLiBBY2NvcmRp bmcgdG8gTUlQdjYsIE1OJ3MgSG9BIGlzCiAgIHBlcm1hbmVudCBkdXJpbmcgaW4gaXRzIHRyYXZl bGxpbmcsIHNvIENOIGFsd2F5cyBrbm93cyBpdHMgSG9BLgoKRE1JUHY2IGRvZXNuJ3QgZGVwZW5k IG9uIEhvQS4gV2UgZG9uJ3QgbmVlZCB0byB1c2UgSG9BIGluIERNSVB2Ni4gQnV0IGluIG9yZGVy IHRvIGtlZXAgY29tcGxpYW50IHdpdGggc3RhbmRhcmQgTUlQdjYsIHdlIGFzc3VtZSBNTiB3aWxs IHVzZSBNSVB2NiB0byBlc3RhYmxpc2ggdGhlIGNvbm5lY3Rpb24gd2l0aCBDTiBpZiB0aGUgREhQ IHF1ZXJ5IGFuZCBESG9BIGFsbG9jYXRpb24gZmFpbC4gSXQgaXMgb25seSBhIGNvbXBsZXRlIGNv bnNpZGVyYXRpb24gZm9yIGV4Y2VwdGlvbi4gSXQgaXMgTUlQdjYgdGhhdCBhc3N1bWVzIHRoYXQg TU4gaGFzIGEgSG9BLgogCj4+VGhlcmUncyBpbXBsZW1lbnRhdGlvbiB3b3JrIHRvIGJlIGFwcGxp ZWQgdG8gTU4sIHllcy4KCj4+VGhlIHF1ZXN0aW9uIGlzOiBEbyB3ZSBuZWVkIHRvIG1vZGlmeSBN b2JpbGUgSVAsIG9yIGRvIHdlIG5lZWQgdG8gZGVzaWduICBhIG5ldyBwcm90b2NvbD8KCj4+T3Vy IEktRCBzYXlzIG5vLgoKPj5Zb3VycyBzYXlzIHllcy4KCj4+VGhhdCdzIGFsc28gYSBkaWZmZXJl bmNlLCBvciBhIGNvbnNlcXVlbmNlIG9mIGEgbnVtYmVyIG9mIGRpZmZlcmVuY2VzIGJldHdlZW4g dGhlIHR3byBJLURzLgoKSW4gbXkgb3BpbmlvbiwgeW91IGRlZmluaXRlbHkgbmVlZCB0byBtb2Rp ZnkgTW9iaWxlIElQLiBKdXN0IGFzIEkgbWVudGlvbmVkIGFib3ZlLCB5b3UgY2hhbmdlIHRoZSBh cmNoaXRlY3R1cmUsIHRoZSBvcGVyYXRpb24gcHJvY2VzcyBhbmQgaW1wbGVtZW50YXRpb24gb2Yg TW9iaWxlIElQLiBBbGwgb2YgdGhlc2UgYXJlIGV4dGVuc2lvbnMgdG8gTW9iaWxlIElQLiBXZSBj YW4gZXZlbiBjYWxsIGl0IGEgbmV3IHByb3RvY29sIHN1Y2ggYXMgRS1NSVAuCgogCgpNaW4KCgoK Ci0tLS0tLS0tLS0KU2VuZGVyOiAiQWxwZXIgWWVnaW4iIDxhbHBlci55ZWdpbkB5ZWdpbi5vcmc+ ClJlY2VpdmVyOiAiTGl1IE1pbiIgPGxpdW1pbkBpY3QuYWMuY24+CkNvcHk6ICInSm91bmkgS29y aG9uZW4nIiA8am91bmkubm9zcGFtQGdtYWlsLmNvbT4sIGRtbUBpZXRmLm9yZywgd2FuZ3l1d2Vp QGljdC5hYy5jbgpTdWJqZWN0OiBSZTogW0RNTV0gY29tbWVudHMvcXVlc3Rpb25zIG9mIGRyYWZ0 LXllZ2luLWRtbS1jbmV0LWhvbWluZy0wMAoKSGkgTGl1LAoKCk9uIEp1bCAyNSwgMjAxMywgYXQg ODo1NCBQTSwgTGl1IE1pbiB3cm90ZToKCgpIaSBBbHBlciwKIAo+PlllcyBpdCBzZWVtcyBsaWtl IHdlIGFyZSBhcHByb2FjaGluZyB0aGUgRE1NIHByb2JsZW0gaW4gdGhlIHNhbWUgd2F5LgogClNv IHdlIGhhdmUgdGhpcyBjb25zZW5zdXMgdGhhdCB0aGUgbWFpbiBpZGVhIGFuZCBhcHByb2FjaCBp biB5b3VyIEktRCBwcm9wb3NlZCBpbiBKdWx5IDMsIDIwMTMgaXMgdGhlIHNhbWUgYXMgb3VyIEkt RCBwcm9wb3NlZCBpbiBNYXJjaCAxMCwgMjAxMy4KIAoKCkFzIHlvdSBrbm93LCB0aGUgbGVnYWN5 IE1vYmlsZSBJUCBhcHByb2FjaCBpcyBiYXNlZCBvbiBsb2NhdGluZyBhIEhBIGluIHNvbWV0aGlu ZyBjYWxsZWQgImhvbWUgbmV0d29yayIuCkEgbnVtYmVyIG9mIERNTSBjb250cmlidXRpb25zIGFy ZSBwcm9wb3NpbmcgdG8gYWRkIGEgdmFyaWFudCB0byB0aGF0OiBMb2NhdGluZyBIQSBpbiBhY2Nl c3MgbmV0d29yay4KV2hhdCB5b3VyIGFuZCBvdXIgSS1EIGFyZSBwcm9wb3NpbmcgaXMgdG8gYWRk IHlldCBhbm90aGVyIHZhcmlhbnQ6IEEgdGhpcmQgdHlwZSBvZiBwbGFjZSBmb3IgSEEgLS0gc29t ZXdoZXJlIHRvd2FyZHMgdGhlIENOLgpUaGF0J3MgYWxsIEknbSBzYXlpbmcuIChub3QgdGhlIGVs YWJvcmF0ZSBzdGF0ZW1lbnQgeW91IG1hZGUgYWJvdmUgOi0pCk9uIHRoZSBvdGhlciBoYW5kIGV4 YWN0IGxvY2F0aW9uIG9mIEhBLCBhbGwgdGhlIHJlbGF0ZWQgcHJvdG9jb2wgd29yayB0byBtYWtl IHRoYXQgaGFwcGVuIGFyZSBhbGwgc2VlbWluZ2x5IGRpZmZlcmVudCBpbiB5b3VyIGFuZCBvdXIg SS1ELCBhbmQgdGhpcyBpcyB3aGF0IHdlIGFyZSBkaXNjdXNzaW5nIGJlbG93LgoKCgoKIAo+PkF0 IHRoZSB0ZWNobmljYWwgZGV0YWlsIGxldmVsIGhlcmUgYXJlIHRoZSBlc3NlbnRpYWwgZGlmZmVy ZW5jZXMgYmV0d2VlbiB0d28gSS1EczoKPj4tIFRoZSBtb2JpbGl0eSBhZ2VudCBpbiBvdXIgY2Fz ZSBjYW4gZXZlbiBiZSBvdXRzaWRlIHRoZSBkb21haW4gb2YgQ04uCiAKSW4gb3VyIEktRCwgd2Ug ZGVmaW5lIHRoYXQgIkRpc3RyaWJ1dGVkIEhvbWUtUHJveHkgKERIUCkgIGlzIGEgcm91dGVyIG5l YXIgQ04iLiAgSW4gdGhpcyB3YXksIERIUCBkb2Vzbid0IGhhdmUgdG8gYmUgbG9jYXRlZCBpbiBD TicgZG9tYWluLiBIb3dldmVyLCB3ZSBkbyByZWNvbW1lbmQgdG8gZmluZCBhIERIUCBpbiBDTidz IGRvbWFpbiBiZWNhdXNlIGNob29zaW5nIERIUCBpbiBvdGhlciBkb21haW5zIHdpbGwgbm90IGd1 YXJhbnRlZSByb3V0ZXIgb3B0aW1pemF0aW9uIGFuZCB0aHVzIHZpb2xhdGluZyBvdXIgb3JpZ2lu YWwgaW50ZW50aW9uIHRvIGludHJvZHVjZSBESFAuCkNob29zaW5nIGEgbW9iaWxpdHkgYWdlbnQg b3V0c2lkZSB0aGUgZG9tYWluIG9mIENOIG1ha2VzIGxpdHRsZSBzZW5zZSBzaW5jZSBvdXIgcHVy cG9zZSBpcyB0byBpbXBsZW1lbnQgcm91dGVyIG9wdGltaXphdGlvbiBieSBtb3ZpbmcgdGhlIG1v YmlsaXR5IGFnZW50IGNsb3NlIHRvIENOLgogCgoKCgpBcyBsb25nIGFzIHRoZSBtb2JpbGl0eSBh Z2VudCBzdGF5cyBvbiB0aGUgbW9zdCBkaXJlY3QgZGF0YS1wYXRoIGJldHdlZW4gdGhlIE1OIGFu ZCBDTiwgdGhlbiBpdCBkb2VzIG5vdCBtYXR0ZXIgd2hlcmUgZXhhY3RseSBpdCBpcy4KUGxhY2lu ZyB0aGUgbW9iaWxpdHkgYWdlbnQgYXMgY2xvc2UgdG8gdGhlIENOIGFzIHBvc3NpYmxlIGluY3Jl YXNlcyB0aGF0IGNoYW5jZS4KQnV0IHRoYXQgZG9lcyBub3QgbWVhbiB0aGUgQ04gc2l0ZSBpcyB0 aGUgb25seSBwbGFjZSBmb3IgdGhlIG1vYmlsaXR5IGFnZW50LgpUaGUgSVNQIHNlcnZpbmcgdGhl IENOIHNpdGUgaXMgYW5vdGhlciBuYXR1cmFsIHBsYWNlLgpBbmQgaXQnZCB3b3JrIGp1c3QgZmlu ZS4KCgoKCj4+LSBZb3VyIEktRCBoYXMgYSB2ZXJ5IGVsYWJvcmF0ZSBESFAgZGlzY292ZXJ5LCB3 aXRoIGFkZGl0aW9uYWwgcHJvdG9jb2wgd29yaywgc29tZSBldmVuIHRvdWNoaW5nIENOLiBOb3Qg c3VyZSB3aHkgaXQgaXMgbmVlZGVkLiBXZSBhcmUgc2ltcGx5IHVzaW5nIEROUyByZXF1ZXN0IGZv ciB0aGF0LiBJdCBiZWNvbWVzIGp1c3QgYSBtYXR0ZXIgb2YgcHV0dGluZyB0aGUgcmlnaHQgZW50 cnkgaW4gdGhlIEROUy4KIApJbiBvdXIgSS1ELCB3ZSBoYXZlIHByb3ZpZGVkIHNldmVyYWwgb3B0 aW9ucyBmb3IgREhQIGRpc2NvdmVyeSBhbmQgRE5TIHJlcXVlc3QgaXMgYWxzbyB1c2VkLiBGb3Ig ZXhhbXBsZSwgIk1OIHF1ZXJ5IHRoZSBETlMgdG8gZ2V0IHRoZSBESFAgYW55Y2FzdCBhZGRyZXNz IiwgIk1OIGNhbiB1c2UgRE5TIHRvIHF1ZXJ5IHRoZSBESFAgbWFuYWdlbWVudCBzZXJ2ZXIgYWRk cmVzcy4iICBBY3R1YWxseSwgd2UgYXNzdW1lIHRoZXJlIG1heSBleGlzdCBtb3JlIHRoYW4gb25l IERIUCBpbiBvbmUgZG9tYWluLiBNSVB2NiBhbHNvIGFzc3VtZXMgdGhlcmUgbWF5IGV4aXN0IG1v cmUgdGhhbiBvbmUgSEEgaW4gb25lIGRvbWFpbi4KCgpNYXliZSB5b3UnZCBjb25zaWRlciBkb3du LXNlbGVjdGluZyB0aGVtLiBOb3Qgb25seSB0b28gbWFueSwgYnV0IHN0aWxsIEkgZG9uJ3QgdW5k ZXJzdGFuZCB3aHkgYSBzaW1wbGUgRE5TLWJhc2VkIGxvb2t1cCBsaWtlIHdlIHByb3Bvc2UgaXMg bm90IHN1ZmZpY2llbnQuIAoKCiAKPj4tIE91ciBJLUQgaXMgbm90IG1vZGlmeWluZyBNb2JpbGUg SVAgcHJvdG9jb2wgYXQgYWxsLiBZb3Ugc2VlbSB0byBkZWZpbmUgbmV3IG1lc3NhZ2luZyBmb3Ig SG9BIGRpc2NvdmVyeSwgYW5kIGFsc28gZXh0ZW5kaW5nIEJVLiBBZ2Fpbiwgbm90IHN1cmUgd2h5 IHRob3NlIGV4dGVuc2lvbnMgYXJlIG5lZWRlZC4KIApPdXIgSS1EIGlzIHRvdGFsbHkgY29tcGF0 aWJsZSB3aXRoIE1vYmlsZSBJUCBwcm90b2NvbC4gRm9yIERIUCBkaXNjb3ZlcnksIGFzIHdlIG1l bnRpb25lZCBpbiBvdXIgSS1EICJUaGlzIHByb2NlZHVyZSBpcyBzaW1pbGFyIHRvICJkeW5hbWlj IGhvbWUgYWdlbnQgYWRkcmVzcyBkaXNjb3ZlcnkgbWVjaGFuaXNtIiBpbiBNSVB2NiIuIEJlc2lk ZXMsIHdlIHByb3ZpZGUgb3RoZXIgb3B0aW9ucyBmb3IgcGVyZm9ybWFuY2Ugb3B0aW1pemF0aW9u LgogCgoKIkNvbXBhdGlibGUiIHRlcm0gbmVlZHMgZXhwYW5kaW5nLgpXaGF0IEkgbWVhbiBpcyAi d2UgdXNlIE1vYmlsZSBJUCBhcy1pcyIuIFdlIGRvbid0IG5lZWQgdG8gY2hhbmdlLCBhZGQsIGV4 dGVuZCBhbnl0aGluZyBvbiB0aGF0LiBJbiBvdGhlciB3b3Jkcywgd2UgZG8gbm90IHJlcXVpcmUg YW55ICJwcm90b2NvbCB3b3JrIi4KCgoKCj4+LSAiIE1OIGRlY2lkZXMgd2hldGhlciB0aGUgc2Vy dmljZSBmbG93IG5lZWRzIG1vYmlsaXR5IHN1cHBvcnQgYWNjb3JkaW5nIHRvIHRoZSBzZXJ2aWNl IHR5cGUgb2YgdGhlIG5ldyBjb25uZWN0aW9uIHJlcXVlc3QuIiBUaGlzIGlzIG5vdCBjbGVhci4g SW4gb3VyIGNhc2UgdGhlIGRldGVybWluYXRpb24gaXMgdHJhbnNwYXJlbnQgdG8gdGhlIHVwcGVy IGxheWVycy4gSWYgdGhlIEROUyByZXR1cm5zIGFuIElQIGFkZHJlc3MgZm9yIENIQSwgdGhlbiBD SEEgaXMgdXNlZC4KIApSb3V0ZXIgb3B0aW1pemF0aW9uIGlzIGp1c3Qgb25lIHB1cnBvc2Ugb2Yg b3VyIEktRCwgYmVzaWRlcyB0aGF0IHdlIGFsc28gc3VwcG9ydCBmbG93IG1hbmFnZW1lbnQgYW5k IGZsb3cgaGFuZG9mZiBmb3IgaGlnaCBsZXZlbCB1c2Vycy4gT2YgY291cnNlLCB1c2VycyBjYW4g Y2hvb3NlIG5vdCB0byB1c2Ugc3VjaCBmdW5jdGlvbnMsIGp1c3QgYXMgeW91IG1lbnRpb25lZC4K CgpJIHRob3VnaHQgeW91ciBJLUQgZGlkIG9uZSB0aGluZywgYW5kIGl0J3MgZXhwbGFpbmVkIGlu IHRlcm1zIG9mIG1hbmFnaW5nIGZsb3dzICh3aXRoIHRoZSBDTnMpLiBOb3cgdGhhdCB5b3UgYXJl IHJlZmVycmluZyB0byB0d28gc2VwYXJhdGUgdGhpbmdzOiAicm91dGVyIG9wdGltaXphdGlvbiIg YW5kICJmbG93IG1hbmFnZW1lbnQgYW5kIGZsb3cgaGFuZG9mZiIgc3VnZ2VzdHMgdGhhdCBJJ20g bWlzc2luZyBvbmUgb2YgdGhlIHR3byB0aGluZ3PigKYgCgoKQmVzaWRlcywgY29taW5nIGJhY2sg dG8gbXkgcXVlc3Rpb246IEhvdyBkb2VzIE1OIGRlY2lkZSB3aGV0aGVyIGEgc2VydmljZSBmbG93 IG5lZWRzIG1vYmlsaXR5IHN1cHBvcnQ/IFdoYXQgYXJlIHRoZSBzZXJ2aWNlIHR5cGVzPyBIb3cg YXJlIHRoZXkgY29udmV5ZWQgZnJvbSB0aGUgYXBwbGljYXRpb25zKD8pIHRvIHRoZSBJUCBzdGFj ay4gVGhlc2UgYXJlIHRoZSBxdWVzdGlvbnMgdGhhdCBhcmlzZSB3aGVuIHJlYWRpbmcgdGhhdCBz dGF0ZW1lbnQgaW4geW91ciBJLUQuCgoKCgoKCj4+LSBUaGVyZSdzIGFuIGFzc3VtcHRpb24gdGhh dCBNTiBoYXMgYSBIb0EgYW5kIENOIGtub3dzIHRoYXQuIE5vdCBzdXJlIHdoeSB0aGlzIGlzIG5l ZWRlZC4KIApXZSBkb24ndCBoYXZlIHN1Y2ggYW4gYXNzdW1wdGlvbi4gTWF5YmUgeW91IG1lYW4g dGhpcyBzZW50ZW5jZSBpbiBvdXIgSS1EICAiQSBub3RpY2UgaXMgdGhhdCwgTU4gd2lsbCB1c2Ug SG9BIHRvIGVzdGFibGlzaCB0aGUgY29ubmVjdGlvbiB3aXRoIENOIGlmIHRoZSBESFAgcXVlcnkg aXMgZmFpbGVkLCB3aGljaCBtZWFucyBubyBESFAgaXMgZm91bmQgdG8gIHNlcnZlIHRoZSBjdXJy ZW50IE1OLiBMYXRlciB3b3JrZmxvdyBpcyB0aGUgc2FtZSBhcyB0aGF0IGRlZmluZWQgaW4gTUlQ djYuIiBBcyB5b3UgY2FuIHNlZSwgaXQgaXMgb25seSBhIGNvbXBsZXRlIGNvbnNpZGVyYXRpb24g Zm9yIGV4Y2VwdGlvbi4KIAoKCllvdXIgSS1EIHNheXM6CgoKICAgVGhpcyBzdGFuZGFyZCBpcyBj b21wbGlhbnQgd2l0aCBzdGFuZGFyZCBNSVB2Niwgd2hpY2ggbWVhbnMgTU4gc3RpbGwKICAgaGFz IEhvQSBpbiBob21lIGRvbWFpbi4gV2hlbiBNTiBpcyBpbml0aWF0aW5nIGEgbmV3IGNvbm5lY3Rp b24gd2l0aAogICBETUlQdjYsIGl0IHdpbGwgZmlyc3QgYXBwbHkgZm9yIERIb0EuIEFjY29yZGlu ZyB0byBNSVB2NiwgTU4ncyBIb0EgaXMKICAgcGVybWFuZW50IGR1cmluZyBpbiBpdHMgdHJhdmVs bGluZywgc28gQ04gYWx3YXlzIGtub3dzIGl0cyBIb0EuCgoKCgoKCgoKPj5PdmVyYWxsLCBhcyB5 b3UgY2FuIHNlZSBmcm9tIG91ciBJLUQsIHdlIGJlbGlldmUgZHluYW1pY2FsbHkgYW5jaG9yaW5n IHRoZSBJUCBhZGRyZXNzIHNvbWV3aGVyZSBjbG9zZSB0byB0aGUgQ04gY2FuIGJlIGFjaGlldmVk IHdpdGhvdXQgYW55IHByb3RvY29sIHdvcmsuCiAKQWN0dWFsbHksIEkgcmVhbGx5IGRvbid0IGJl bGlldmUgd2UgY2FuIGltcGxlbWVudCBwcm90b2NvbCBvcHRpbWl6YXRpb24gd2l0aG91dCBkb2lu ZyBhbnkgY2hhbmdlIHRvIGl0LiBBY3R1YWxseSwgeW91IGRlZmluaXRlbHkgbmVlZCB0byBjaGFu Z2UgdGhlIGltcGxlbWVudGF0aW9uIGZvciBNTiBpbiB5b3VyIEktRC4KIAoKClRoZXJlJ3MgaW1w bGVtZW50YXRpb24gd29yayB0byBiZSBhcHBsaWVkIHRvIE1OLCB5ZXMuIApUaGUgcXVlc3Rpb24g aXM6IERvIHdlIG5lZWQgdG8gbW9kaWZ5IE1vYmlsZSBJUCwgb3IgZG8gd2UgbmVlZCB0byBkZXNp Z24gIGEgbmV3IHByb3RvY29sPyAKT3VyIEktRCBzYXlzIG5vLgpZb3VycyBzYXlzIHllcy4gClRo YXQncyBhbHNvIGEgZGlmZmVyZW5jZSwgb3IgYSBjb25zZXF1ZW5jZSBvZiBhIG51bWJlciBvZiBk aWZmZXJlbmNlcyBiZXR3ZWVuIHRoZSB0d28gSS1Ecy4KCgpBbHBlcgoKCgoKCgogCk1pbgogCkZy b206IEFscGVyIFllZ2luIFttYWlsdG86YWxwZXIueWVnaW5AeWVnaW4ub3JnXSAKU2VudDogVGh1 cnNkYXksIEp1bHkgMjUsIDIwMTMgNDowMyBQTQpUbzogTWluIExpdQpDYzogSm91bmkgS29yaG9u ZW47IGRtbUBpZXRmLm9yZzsgd2FuZ3l1d2VpQGljdC5hYy5jbgpTdWJqZWN0OiBSZTogW0RNTV0g Y29tbWVudHMvcXVlc3Rpb25zIG9mIGRyYWZ0LXllZ2luLWRtbS1jbmV0LWhvbWluZy0wMAogCkhp IExpdSwKIApZZXMgaXQgc2VlbXMgbGlrZSB3ZSBhcmUgYXBwcm9hY2hpbmcgdGhlIERNTSBwcm9i bGVtIGluIHRoZSBzYW1lIHdheS4KIApBdCB0aGUgdGVjaG5pY2FsIGRldGFpbCBsZXZlbCBoZXJl IGFyZSB0aGUgZXNzZW50aWFsIGRpZmZlcmVuY2VzIGJldHdlZW4gdHdvIEktRHM6CiAKLSBUaGUg bW9iaWxpdHkgYWdlbnQgaW4gb3VyIGNhc2UgY2FuIGV2ZW4gYmUgb3V0c2lkZSB0aGUgZG9tYWlu IG9mIENOLiAKIAotIFlvdXIgSS1EIGhhcyBhIHZlcnkgZWxhYm9yYXRlIERIUCBkaXNjb3Zlcnks IHdpdGggYWRkaXRpb25hbCBwcm90b2NvbCB3b3JrLCBzb21lIGV2ZW4gdG91Y2hpbmcgQ04uIE5v dCBzdXJlIHdoeSBpdCBpcyBuZWVkZWQuIFdlIGFyZSBzaW1wbHkgdXNpbmcgRE5TIHJlcXVlc3Qg Zm9yIHRoYXQuIEl0IGJlY29tZXMganVzdCBhIG1hdHRlciBvZiBwdXR0aW5nIHRoZSByaWdodCBl bnRyeSBpbiB0aGUgRE5TLgogCi0gT3VyIEktRCBpcyBub3QgbW9kaWZ5aW5nIE1vYmlsZSBJUCBw cm90b2NvbCBhdCBhbGwuIFlvdSBzZWVtIHRvIGRlZmluZSBuZXcgbWVzc2FnaW5nIGZvciBIb0Eg ZGlzY292ZXJ5LCBhbmQgYWxzbyBleHRlbmRpbmcgQlUuIEFnYWluLCBub3Qgc3VyZSB3aHkgdGhv c2UgZXh0ZW5zaW9ucyBhcmUgbmVlZGVkLgogCi0gIiBNTiBkZWNpZGVzIHdoZXRoZXIgdGhlIHNl cnZpY2UgZmxvdyBuZWVkcyBtb2JpbGl0eSBzdXBwb3J0IGFjY29yZGluZyB0byB0aGUgc2Vydmlj ZSB0eXBlIG9mIHRoZSBuZXcgY29ubmVjdGlvbiByZXF1ZXN0LiIgVGhpcyBpcyBub3QgY2xlYXIu IEluIG91ciBjYXNlIHRoZSBkZXRlcm1pbmF0aW9uIGlzIHRyYW5zcGFyZW50IHRvIHRoZSB1cHBl ciBsYXllcnMuIElmIHRoZSBETlMgcmV0dXJucyBhbiBJUCBhZGRyZXNzIGZvciBDSEEsIHRoZW4g Q0hBIGlzIHVzZWQuCgoKCi0gVGhlcmUncyBhbiBhc3N1bXB0aW9uIHRoYXQgTU4gaGFzIGEgSG9B IGFuZCBDTiBrbm93cyB0aGF0LiBOb3Qgc3VyZSB3aHkgdGhpcyBpcyBuZWVkZWQuCgoKCk92ZXJh bGwsIGFzIHlvdSBjYW4gc2VlIGZyb20gb3VyIEktRCwgd2UgYmVsaWV2ZSBkeW5hbWljYWxseSBh bmNob3JpbmcgdGhlIElQIGFkZHJlc3Mgc29tZXdoZXJlIGNsb3NlIHRvIHRoZSBDTiBjYW4gYmUg YWNoaWV2ZWQgd2l0aG91dCBhbnkgcHJvdG9jb2wgd29yay4KCgoKQWxwZXIKCgoKCgoKCgoKCgoK CgoKCgoKIAogCiAKIAogCiAKIApPbiBKdWwgMjQsIDIwMTMsIGF0IDQ6NTggUE0sIOWImOaVjyB3 cm90ZToKCgoKCkhpLCBBbHBlciwKV2Ugc3VibWl0ZWQgYSBkcmFmdCB0byBETU0gaW4gTWFyY2gg KGh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtbGl1LWRtbS1mbG93cy1kaXN0 cmlidXRpb24tYW5kLWhhbmRvZmYvP2luY2x1ZGVfdGV4dD0xKSBhbmQgbWFkZSBhIHByZXNlbnRh dGlvbiBpbiBsYXN0IElFVEYgbWVldGluZyBpbiBPcmxhbmRvLiBJIHRoaW5rIHRoZSBtYWluIGlk ZWEgaW4geW91ciBkcmFmdCBpcyBhbG1vc3QgdGhlIHNhbWUgd2l0aCBvdXIgSS1ELiBJbiBvdXIg ZHJhZnQsIHdlIHByb3Bvc2UgYSBuZXcgZW50aXR5IG5hbWVkIERpc3RyaWJ1dGVkIEhvbWUtUHJv eHkgKERIUCkgdGhhdCBpcyBhIHJvdXRlciBuZWFyIENOLCB3aXRoIHRoZSBmdW5jdGlvbiBmb3Ig YW4gZXh0ZW5zaW9uIG9mIHRoZSBIQSwgdG8gYXNzaWduIERpc3RyaWJ1dGVkIEhvbWUgQWRkcmVz cyAoREhvQSkgZm9yIHRoZSBNTiB0byBpbXBsZW1lbnQgcm91dGVyIG9wdGltaXphdGlvbi4gSW4g eW91ciBkcmFmdCwgeW91IHByb3Bvc2UgYSBDb3JyZXNwb25kaW5nIEhvbWUgQWdlbnQgKENIQSkg bG9jYXRlZCBuZWFyIENOcyB0byBhbGxvY2F0ZSBhIEhvQSB0byB0aGUgTU4gKENvcnJlc3BvbmRp bmcgSG9tZSBBZGRyZXNzLCBDSG9BKS4gQXMgSSBzZWUgaXQsIHRoZSBDSEEgaXMganVzdCB0aGUg REhQIGFuZCBDSG9BIGlzIHRoZSBzYW1lIGFzIERIb0EuIENvdWxkIHlvdSBwbGVhc2UgZXhwbGFp biB0aGUgbmV3IGNvbnRyaWJ1dGlvbiBpbiB5b3VyIGRyYWZ0PwogCiAKTWluIExpdQoKSW5zdGl0 dXRlIG9mIENvbXB1dGluZyBUZWNobm9sb2d5CkNoaW5lc2UgQWNhZGVteSBvZiBTY2llbmNlCgoK PiAtLS0tLS0tLS0tCj4gU2VuZGVyOiAiQWxwZXIgWWVnaW4iIDxhbHBlci55ZWdpbkB5ZWdpbi5v cmc+Cj4gUmVjZWl2ZXI6ICJKb3VuaSBLb3Job25lbiIgPGpvdW5pLm5vc3BhbUBnbWFpbC5jb20+ Cj4gQ29weTogImRtbUBpZXRmLm9yZyIgPGRtbUBpZXRmLm9yZz4KPiBTdWJqZWN0OiBSZTogW0RN TV0gY29tbWVudHMvcXVlc3Rpb25zIG9mIGRyYWZ0LXllZ2luLWRtbS1jbmV0LWhvbWluZy0wMAo+ IAo+IAo+IE9uIEp1bCAyNCwgMjAxMywgYXQgMTE6NTYgQU0sIEpvdW5pIEtvcmhvbmVuIHdyb3Rl Ogo+IAo+ID4gQWxwZXIsIGF1dGhvcnMsCj4gPiAKPiA+IEluIFNlY3Rpb24gMy4gaXMgc3RhdGVz Ogo+ID4gCj4gPiAgIkNIQSBtYXkgYmUgY28tbG9jYXRlZCB3aXRoIHRoZSBDTiwgb3IgbG9jYXRl ZCBpbiB0aGUgc2FtZSBzaXRlIGFzIHRoZQo+ID4gICBDTiwgb3IgbG9jYXRlZCBpbiBhbiBJU1Ag c2VydmluZyB0aGF0IHNpdGUuICBOb3QgYWxsIENOcyBtYXkgYmUKPiA+ICAgc2VydmVkIGJ5IGEg Q0hBLiAgSW4gY2FzZSB0aGVyZSBpcyBubyBDSEEgc2VydmluZyB0aGUgQ04sIHRoZSBNTiBhbmQK PiA+ICAgdGhlIENOIG1heSBjb21tdW5pY2F0ZSB1c2luZyB0aGUgSG9BIHZpYSB0aGUgSEEuICBJ dCBpcyBleHBlY3RlZCB0aGF0Cj4gPiAgIENIQXMgd291bGQgYmUgZGVwbG95ZWQgZm9yIGRvbWlu YW50IGNvbnRlbnQgc2l0ZXMgb24gdGhlIEludGVybmV0Cj4gPiAgIChlLmcuLCBZb3VUdWJlLCBG YWNlYm9vaywgTmV0ZmxpeCwgZXRjLikiCj4gPiAKPiA+IFdoYXQgd291bGQgYmUgdGhlIG1vdGl2 YXRpb24gb3IgYnVzaW5lc3MgcmVhc29uIGZvciBhIHNlcnZpY2UvY29udGVudAo+ID4gcHJvdmlk ZXIgdG8gc3RhcnQgb2ZmZXJpbmcgYSBtb2JpbGl0eSBhbmNob3Jpbmcgc2VydmljZT8gSGlnaCBi YW5kd2lkdGgKPiA+IHNpdGVzIGFzIGxpc3RlZCBhYm92ZSB3b3VsZCBuZWVkIGludmVzdCBxdWl0 ZSBtdWNoIGZvciBzdWNoIGEgcGxhdGZvcm0uCj4gPiAKPiAKPiBIZXJlJ3Mgb3VyIHRoaW5raW5n Ogo+IAo+IC0gVGhlIGRpcmVjdCBiZW5lZml0IG9mIHRoaXMgYXBwcm9hY2ggdG8gdGhlIGNvbnRl bnQgcHJvdmlkZXIgaXMgdGhlIHJlZHVjdGlvbiBvZiB0cmFuc21pc3Npb24gbGF0ZW5jeSBkdWUg dG8gZWxpbWluYXRpb24gb2YgdGhlIHRyaWFuZ3VsYXIgcm91dGVzLiBUaGlzIHdvdWxkIGVuaGFu Y2UgdGhlIHRoZWlyIHVzZXIgZXhwZXJpZW5jZS4KPiAKPiAtIENvbnNpZGVyaW5nIHRoZSBvdmVy YWxsIHN5c3RlbSAody9vIGRpc3Rpbmd1aXNoaW5nIGJldHdlZW4gdGhlIE1OTyBhbmQgdGhlIGNv bnRlbnQgcHJvdmlkZXIpLCBwcm92aWRpbmcgYW5jaG9yaW5nL21vYmlsaXR5IG5lYXIgdGhlIENO ZXQgYXMgb3Bwb3NlZCB0byBkb2luZyBpdCBhdCBhIGNvcm5lciBvZiB0aGUgSW50ZXJuZXQgcmVk dWNlcyB0aGUgb3ZlcmFsbCBjb3N0LiBHaXZlbiB0aGUgc2F2aW5ncywgdGhlIGludm9sdmVkIHBh cnRpZXMgY2FuIGZpbmQgYSBmYWlyIHdheSB0byBkZWFsIHdpdGggaXQgKGkuZS4sIHNvbWUgYnVz aW5lc3MgZGVhbCkuCj4gCj4gT24gdG9wIG9mIHRoYXQsIHRoaXMgY2FuIGJlIHByb3ZpZGVkIGJ5 IElTUHMgc2VydmluZyB0aGUgY29udGVudCBzaXRlcy4gU3VjaCBJU1BzIGNhbiBhbHNvIGhhdmUg YSBidXNpbmVzcyBkZWFsIHdpdGggdGhlIE1OTyBmb3IgdGFraW5nIG92ZXIgdGhlIG1vYmlsaXR5 IG1hbmFnZW1lbnQgbG9hZC4KPiAKPiAKPiA+IEkgYWxzbyBzdGFydGVkIHRoaW5raW5nIHRoYXQg aW4gZ2VuZXJhbCB0aGlzIHNvbHV0aW9uIChhbmQgcXVpdGUgbWFueQo+ID4gb3RoZXIpIHNlZW0g dG8gYXNzdW1lIHRoZSBDTiBpcyBtb3JlIG9yIGxlc3Mgc3RhdGlvbmFyeS4gSG93IHdvdWxkIHRo ZQo+ID4gQ0hBIGNvbmNlcHQgYmUgYWZmZWN0ZWQgaWYgdGhlIENOIGlzIGFsc28gbW9iaWxlPyBX b3VsZCBpdCBhbGxvdyBhbnkKPiA+IGJlbmVmaXRzIG92ZXIgdGhlIGxlZ2FjeSBNSVAgdmFyaWFu dHM/IEhvdyB3b3VsZCB0aGUgQ0hBIGRpc2NvdmVyeSAKPiA+IHdvcmsgaW4gdGhpcyBjYXNlPwo+ ID4gCj4gCj4gV2UgZGlkbid0IGNvbnNpZGVyIG1vYmlsZSBDTnMuIFdlIGFyZSBnb2luZyBhZnRl ciB0aGUgbWFqb3Igc291cmNlcyBvZiBtb2JpbGUgdHJhZmZpYywgd2hpY2ggaXMgc3RlbW1pbmcg ZnJvbSBmaXhlZCBzaXRlcy4KPiAKPiAKPiA+IFRoZSBleGFtcGxlcyBpbiBTZWN0aW9ucyAzLiBh bmQgNC4gc2hvdyBETlMgYXMgdGhlIGRpc2NvdmVyeSBtZWNoYW5pc20KPiA+IGZvciB0aGUgQ0hB LiBIb3dldmVyLCB0aGVyZSBpcyBubyByZWFsIGRlc2NyaXB0aW9uIGhvdyB0aGUgZGlzY292ZXJ5 Cj4gPiBpcyBhY3R1YWxseSBjYXJyaWVkIG91dCAoZXhjZXB0IGNvbmNlcHR1YWwgQ0hBIGRvbWFp biBuYW1lIHJlZmVycmVkCj4gPiBpbiBTZWN0aW9uIDMuCj4gCj4gSXQncyBqdXN0IGEgbWF0dGVy IG9mIHN0b3JpbmcgY2hhLjx5b3VyZG9tYWluPiBpbiBETlMgYW5kIGxvb2tpbmcgaXQgdXAuCj4g V2UgY2FuIGFkZCBzb21lIG1vcmUgdmVyYmlhZ2UsIGlmIHRoaXMgaXMgbm90IGNsZWFyLgo+IAo+ ID4gRmlndXJlIDEgc3RlcCAyKS4gSGF2ZSB5b3UgY29uc2lkZXJlZCBvdGhlciBkaXNjb3ZlcnkK PiA+IG1lY2hhbmlzbXMgdGhhbiBETlM/Cj4gPiAKPiAKPiBXZSBkaWQgc29tZSBidXQgdGhpcyBv bmUgc2VlbWVkIHRvIGJlIHRoZSBtb3N0IHN0cmFpZ2h0Zm9yd2FyZC4gCj4gQW55IHNwZWNpZmlj IHJlY29tbWVuZGF0aW9ucz8KPiAKPiBBbHBlcgo+IAo+IAo+IAo+IAo+ID4gLSBKb3VuaQo+ID4g Cj4gPiAKPiA+IAo+ID4gCj4gPiAKPiAKPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXwo+IGRtbSBtYWlsaW5nIGxpc3QKPiBkbW1AaWV0Zi5vcmcKPiBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbQoKCgoKCgoKDQoNCg0K ------=_Part_34110_27480896.1374869388131 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PHA+SGkgQWxwZXIsPC9wPjxwPiZuYnNwOzwvcD48cD4mZ3Q7Jmd0O0FzIGxvbmcgYXMgdGhlIG1v YmlsaXR5IGFnZW50IHN0YXlzIG9uIHRoZSBtb3N0IGRpcmVjdCBkYXRhLXBhdGggYmV0d2VlbiB0 aGUgTU4gYW5kIENOLCB0aGVuIGl0IGRvZXMgbm90IG1hdHRlciB3aGVyZSBleGFjdGx5IGl0IGlz LjwvcD48cD4mZ3Q7Jmd0O1BsYWNpbmcgdGhlIG1vYmlsaXR5IGFnZW50IGFzIGNsb3NlIHRvIHRo ZSBDTiBhcyBwb3NzaWJsZSBpbmNyZWFzZXMgdGhhdCBjaGFuY2UuPC9wPjxwPiZndDsmZ3Q7QnV0 IHRoYXQgZG9lcyBub3QgbWVhbiB0aGUgQ04gc2l0ZSBpcyB0aGUgb25seSBwbGFjZSBmb3IgdGhl IG1vYmlsaXR5IGFnZW50LjwvcD48cD4mZ3Q7Jmd0O1RoZSBJU1Agc2VydmluZyB0aGUgQ04gc2l0 ZSBpcyBhbm90aGVyIG5hdHVyYWwgcGxhY2UuPC9wPjxwPiZndDsmZ3Q7QW5kIGl0J2Qgd29yayBq dXN0IGZpbmUuPC9wPjxwPkFzIEkgbWVudGlvbmVkLCBpbiBvdXIgSS1EIHdlIGp1c3QgZGVmaW5l IHRoYXQgIkRpc3RyaWJ1dGVkIEhvbWUtUHJveHkgKERIUCkmbmJzcDsgaXMgYSByb3V0ZXIgbmVh ciBDTiIuIEluIHRoaXMgd2F5LCBESFAgZG9lc24ndCBoYXZlIHRvIGJlIGxvY2F0ZWQgaW4gQ04n IGRvbWFpbi4gSG93ZXZlciwgd2UgcmVjb21tZW5kIHRvIGZpbmQgYSBESFAgaW4gQ04ncyBkb21h aW4gYmVjYXVzZSBjaG9vc2luZyBESFAgaW4gb3RoZXIgZG9tYWlucyB3aWxsIG5vdCBndWFyYW50 ZWUgcm91dGVyIG9wdGltaXphdGlvbiBhbmQgaW5jcmVhc2UgdGhlIG1hbmFnZW1lbnQgYW5kIGRl cGxveW1lbnQgY29zdCBvZiBESFAuIDwvcD48cD4mbmJzcDs8L3A+PHA+PGJyPiZndDsmZ3Q7IkNv bXBhdGlibGUiIHRlcm0gbmVlZHMgZXhwYW5kaW5nLjxicj4mZ3Q7Jmd0O1doYXQgSSBtZWFuIGlz ICJ3ZSB1c2UgTW9iaWxlIElQIGFzLWlzIi4gV2UgZG9uJ3QgbmVlZCB0byBjaGFuZ2UsIGFkZCwg ZXh0ZW5kIGFueXRoaW5nIG9uIHRoYXQuIEluIG90aGVyIHdvcmRzLCB3ZSBkbyBub3QgcmVxdWly ZSBhbnkgInByb3RvY29sIHdvcmsiLjwvcD48cD5JIHJlYWxseSBkb24ndCB1bmRlcnN0YW5kIHlv dXIgZGVmaW5pdGlvbiBvZiAicHJvdG9jb2wgd29yayIuIFlvdSBjaGFuZ2UgdGhlIGFyY2hpdGVj dHVyZSwgdGhlIG9wZXJhdGlvbiBwcm9jZXNzIGFuZCB0aGUgaW1wbGVtZW50YXRpb24gb2YgTW9i aWxlIElQLCBidXQgeW91IHN0aWxsIHRoaW5rIHlvdSBkbyBub3QgcmVxdWlyZSBhbnkgInByb3Rv Y29sIHdvcmsiLiBBcyBJIHNlZSBpdCwgd2hhdCB5b3UgaGF2ZSBkb25lIGlzIGV4YWN0bHkgZXhw YW5kaW5nIHRvIE1vYmlsZSBJUC48L3A+PHA+PGJyPiZndDsmZ3Q7WW91ciBJLUQgc2F5czo8YnI+ Jm5ic3A7Jm5ic3A7IFRoaXMgc3RhbmRhcmQgaXMgY29tcGxpYW50IHdpdGggc3RhbmRhcmQgTUlQ djYsIHdoaWNoIG1lYW5zIE1OIHN0aWxsPGJyPiZuYnNwOyZuYnNwOyBoYXMgSG9BIGluIGhvbWUg ZG9tYWluLiBXaGVuIE1OIGlzIGluaXRpYXRpbmcgYSBuZXcgY29ubmVjdGlvbiB3aXRoPGJyPiZu YnNwOyZuYnNwOyBETUlQdjYsIGl0IHdpbGwgZmlyc3QgYXBwbHkgZm9yIERIb0EuIEFjY29yZGlu ZyB0byBNSVB2NiwgTU4ncyBIb0EgaXM8YnI+Jm5ic3A7Jm5ic3A7IHBlcm1hbmVudCBkdXJpbmcg aW4gaXRzIHRyYXZlbGxpbmcsIHNvIENOIGFsd2F5cyBrbm93cyBpdHMgSG9BLjwvcD48cD5ETUlQ djYgZG9lc24ndCBkZXBlbmQgb24gSG9BLiBXZSBkb24ndCBuZWVkIHRvIHVzZSBIb0EgaW4gRE1J UHY2LiBCdXQgaW4gb3JkZXIgdG8ga2VlcCBjb21wbGlhbnQgd2l0aCBzdGFuZGFyZCBNSVB2Niwg d2UgYXNzdW1lIE1OIHdpbGwgdXNlIE1JUHY2IHRvIGVzdGFibGlzaCB0aGUgY29ubmVjdGlvbiB3 aXRoIENOIGlmIHRoZSBESFAgcXVlcnkgYW5kIERIb0EgYWxsb2NhdGlvbiBmYWlsLiBJdCBpcyBv bmx5IGEgY29tcGxldGUgY29uc2lkZXJhdGlvbiBmb3IgZXhjZXB0aW9uLiBJdCBpcyBNSVB2NiB0 aGF0IGFzc3VtZXMgdGhhdCBNTiBoYXMgYSBIb0EuPGJyPiZuYnNwOzxicj4mZ3Q7Jmd0O1RoZXJl J3MgaW1wbGVtZW50YXRpb24gd29yayB0byBiZSBhcHBsaWVkIHRvIE1OLCB5ZXMuIDwvcD48cD4m Z3Q7Jmd0O1RoZSBxdWVzdGlvbiBpczogRG8gd2UgbmVlZCB0byBtb2RpZnkgTW9iaWxlIElQLCBv ciBkbyB3ZSBuZWVkIHRvIGRlc2lnbiZuYnNwOyBhIG5ldyBwcm90b2NvbD8gPC9wPjxwPiZndDsm Z3Q7T3VyIEktRCBzYXlzIG5vLjwvcD48cD4mZ3Q7Jmd0O1lvdXJzIHNheXMgeWVzLiA8L3A+PHA+ Jmd0OyZndDtUaGF0J3MgYWxzbyBhIGRpZmZlcmVuY2UsIG9yIGEgY29uc2VxdWVuY2Ugb2YgYSBu dW1iZXIgb2YgZGlmZmVyZW5jZXMgYmV0d2VlbiB0aGUgdHdvIEktRHMuPC9wPjxwPkluIG15IG9w aW5pb24sIHlvdSBkZWZpbml0ZWx5IG5lZWQgdG8gbW9kaWZ5IE1vYmlsZSBJUC4gSnVzdCBhcyBJ IG1lbnRpb25lZCBhYm92ZSwgeW91IGNoYW5nZSB0aGUgYXJjaGl0ZWN0dXJlLCB0aGUgb3BlcmF0 aW9uIHByb2Nlc3MgYW5kIGltcGxlbWVudGF0aW9uIG9mIE1vYmlsZSBJUC4gQWxsIG9mIHRoZXNl IGFyZSBleHRlbnNpb25zIHRvIE1vYmlsZSBJUC4gV2UgY2FuIGV2ZW4gY2FsbCBpdCBhIG5ldyBw cm90b2NvbCBzdWNoIGFzIEUtTUlQLjwvcD48cD4mbmJzcDs8L3A+PHA+TWluPGJyPjxicj48YnI+ PC9wPjxibG9ja3F1b3RlIHN0eWxlPSJwYWRkaW5nLWxlZnQ6IDVweDsgbWFyZ2luLXJpZ2h0OiAw cHg7IG1hcmdpbi1sZWZ0OiA1cHg7IGJvcmRlci1sZWZ0LWNvbG9yOiByZ2IoMTgyLCAxODIsIDE4 Mik7IGJvcmRlci1sZWZ0LXdpZHRoOiAycHg7IGJvcmRlci1sZWZ0LXN0eWxlOiBzb2xpZDsiIG5h bWU9InJlcGx5Q29udGVudCI+LS0tLS0tLS0tLTxicj4KPGI+U2VuZGVyOjwvYj4gIkFscGVyIFll Z2luIiAmbHQ7YWxwZXIueWVnaW5AeWVnaW4ub3JnJmd0Ozxicj4KPGI+UmVjZWl2ZXI8L2I+PGI+ OjwvYj4gIkxpdSBNaW4iICZsdDtsaXVtaW5AaWN0LmFjLmNuJmd0Ozxicj4KPGI+Q29weTo8L2I+ ICInSm91bmkgS29yaG9uZW4nIiAmbHQ7am91bmkubm9zcGFtQGdtYWlsLmNvbSZndDssIGRtbUBp ZXRmLm9yZywgd2FuZ3l1d2VpQGljdC5hYy5jbjxicj4KPGI+U3ViamVjdDo8L2I+IFJlOiBbRE1N XSBjb21tZW50cy9xdWVzdGlvbnMgb2YgZHJhZnQteWVnaW4tZG1tLWNuZXQtaG9taW5nLTAwPGJy Pjxicj5IaSBMaXUsPGRpdj48YnI+PGRpdj48ZGl2Pk9uIEp1bCAyNSwgMjAxMywgYXQgODo1NCBQ TSwgTGl1IE1pbiB3cm90ZTo8L2Rpdj48YnIgY2xhc3M9IkFwcGxlLWludGVyY2hhbmdlLW5ld2xp bmUiPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuIGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFu IiBzdHlsZT0idGV4dC10cmFuc2Zvcm06IG5vbmU7IHRleHQtaW5kZW50OiAwcHg7IGxldHRlci1z cGFjaW5nOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyBi b3JkZXItY29sbGFwc2U6IHNlcGFyYXRlOyBvcnBoYW5zOiAyOyB3aWRvd3M6IDI7IC13ZWJraXQt dGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC1ib3JkZXItaG9yaXpvbnRhbC1zcGFjaW5n OiAwcHg7IC13ZWJraXQtYm9yZGVyLXZlcnRpY2FsLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0 LWRlY29yYXRpb25zLWluLWVmZmVjdDogbm9uZTsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDog MHB4OyI+PGRpdiBsYW5nPSJaSC1DTiIgdmxpbms9InB1cnBsZSIgbGluaz0iYmx1ZSI+PGRpdiBj bGFzcz0iV29yZFNlY3Rpb24xIiBzdHlsZT0icGFnZTogV29yZFNlY3Rpb24xOyI+PGRpdiBzdHls ZT0ibWFyZ2luOiAwY20gMGNtIDBwdDsgZm9udC1mYW1pbHk6IOWui+S9kzsgZm9udC1zaXplOiAx MnB0OyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsg Zm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTAuNXB0OyI+SGkg QWxwZXIsPG86cD48L286cD48L3NwYW4+PC9kaXY+PGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNt IDBwdDsgZm9udC1mYW1pbHk6IOWui+S9kzsgZm9udC1zaXplOiAxMnB0OyI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTAuNXB0OyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9kaXY+PGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDBwdDsgZm9udC1mYW1pbHk6IOWu i+S9kzsgZm9udC1zaXplOiAxMnB0OyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjog cmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQt c2l6ZTogMTAuNXB0OyI+Jmd0OyZndDtZZXMgaXQgc2VlbXMgbGlrZSB3ZSBhcmUgYXBwcm9hY2hp bmcgdGhlIERNTSBwcm9ibGVtIGluIHRoZSBzYW1lIHdheS48bzpwPjwvbzpwPjwvc3Bhbj48L2Rp dj48ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMHB0OyBmb250LWZhbWlseTog5a6L5L2TOyBm b250LXNpemU6IDEycHQ7Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiByZ2IoMzEs IDczLCAxMjUpOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAx MC41cHQ7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2Rpdj48ZGl2IHN0eWxlPSJtYXJnaW46 IDBjbSAwY20gMHB0OyBmb250LWZhbWlseTog5a6L5L2TOyBmb250LXNpemU6IDEycHQ7Ij48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBmb250LWZhbWls eTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMC41cHQ7Ij5TbyB3ZSBoYXZlIHRo aXMgY29uc2Vuc3VzIHRoYXQgdGhlIG1haW4gaWRlYSBhbmQgYXBwcm9hY2ggaW4geW91ciBJLUQg cHJvcG9zZWQgaW4gSnVseSAzLCAyMDEzIGlzIHRoZSBzYW1lIGFzIG91ciBJLUQgcHJvcG9zZWQg aW4gTWFyY2ggMTAsIDIwMTMuPG86cD48L286cD48L3NwYW4+PC9kaXY+PGRpdiBzdHlsZT0ibWFy Z2luOiAwY20gMGNtIDBwdDsgZm9udC1mYW1pbHk6IOWui+S9kzsgZm9udC1zaXplOiAxMnB0OyI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTAuNXB0OyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9kaXY+PGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDBwdDsgZm9u dC1mYW1pbHk6IOWui+S9kzsgZm9udC1zaXplOiAxMnB0OyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IGZvbnQtc2l6ZTogMTAuNXB0OyI+PC9zcGFuPjwvZGl2PjwvZGl2PjwvZGl2Pjwvc3Bh bj48L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9kaXY+PGRpdj5BcyB5b3Uga25vdywgdGhlIGxlZ2Fj eSBNb2JpbGUgSVAgYXBwcm9hY2ggaXMgYmFzZWQgb24gbG9jYXRpbmcgYSBIQSBpbiBzb21ldGhp bmcgY2FsbGVkICJob21lIG5ldHdvcmsiLjwvZGl2PjxkaXY+QSBudW1iZXIgb2YgRE1NIGNvbnRy aWJ1dGlvbnMgYXJlIHByb3Bvc2luZyB0byBhZGQgYSB2YXJpYW50IHRvIHRoYXQ6IExvY2F0aW5n IEhBIGluIGFjY2VzcyBuZXR3b3JrLjwvZGl2PjxkaXY+V2hhdCB5b3VyIGFuZCBvdXIgSS1EIGFy ZSBwcm9wb3NpbmcgaXMgdG8gYWRkIHlldCBhbm90aGVyIHZhcmlhbnQ6IEEgdGhpcmQgdHlwZSBv ZiBwbGFjZSBmb3IgSEEgLS0gc29tZXdoZXJlIHRvd2FyZHMgdGhlIENOLjwvZGl2PjxkaXY+VGhh dCdzIGFsbCBJJ20gc2F5aW5nLiAobm90IHRoZSBlbGFib3JhdGUgc3RhdGVtZW50IHlvdSBtYWRl IGFib3ZlIDotKTwvZGl2PjxkaXY+T24gdGhlIG90aGVyIGhhbmQgZXhhY3QgbG9jYXRpb24gb2Yg SEEsIGFsbCB0aGUgcmVsYXRlZCBwcm90b2NvbCB3b3JrIHRvIG1ha2UgdGhhdCBoYXBwZW4gYXJl IGFsbCBzZWVtaW5nbHkgZGlmZmVyZW50IGluIHlvdXIgYW5kIG91ciBJLUQsIGFuZCB0aGlzIGlz IHdoYXQgd2UgYXJlIGRpc2N1c3NpbmcgYmVsb3cuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGJyPjxi bG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuIGNsYXNzPSJBcHBsZS1zdHlsZS1zcGFuIiBzdHls ZT0idGV4dC10cmFuc2Zvcm06IG5vbmU7IHRleHQtaW5kZW50OiAwcHg7IGxldHRlci1zcGFjaW5n OiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyB3aGl0ZS1zcGFjZTogbm9ybWFsOyBib3JkZXIt Y29sbGFwc2U6IHNlcGFyYXRlOyBvcnBoYW5zOiAyOyB3aWRvd3M6IDI7IC13ZWJraXQtdGV4dC1z aXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC1ib3JkZXItaG9yaXpvbnRhbC1zcGFjaW5nOiAwcHg7 IC13ZWJraXQtYm9yZGVyLXZlcnRpY2FsLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10ZXh0LWRlY29y YXRpb25zLWluLWVmZmVjdDogbm9uZTsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4OyI+ PGRpdiBsYW5nPSJaSC1DTiIgdmxpbms9InB1cnBsZSIgbGluaz0iYmx1ZSI+PGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIiBzdHlsZT0icGFnZTogV29yZFNlY3Rpb24xOyI+PGRpdiBzdHlsZT0ibWFy Z2luOiAwY20gMGNtIDBwdDsgZm9udC1mYW1pbHk6IOWui+S9kzsgZm9udC1zaXplOiAxMnB0OyI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1m YW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTAuNXB0OyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9kaXY+PGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDBwdDsgZm9u dC1mYW1pbHk6IOWui+S9kzsgZm9udC1zaXplOiAxMnB0OyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IGZvbnQtc2l6ZTogMTAuNXB0OyI+Jmd0OyZndDtBdCB0aGUgdGVjaG5pY2FsIGRldGFp bCBsZXZlbCBoZXJlIGFyZSB0aGUgZXNzZW50aWFsIGRpZmZlcmVuY2VzIGJldHdlZW4gdHdvIEkt RHM6PG86cD48L286cD48L3NwYW4+PC9kaXY+PGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDBw dDsgZm9udC1mYW1pbHk6IOWui+S9kzsgZm9udC1zaXplOiAxMnB0OyI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6IENhbGlicmks IHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTAuNXB0OyI+Jmd0OyZndDstIFRoZSBtb2JpbGl0eSBh Z2VudCBpbiBvdXIgY2FzZSBjYW4gZXZlbiBiZSBvdXRzaWRlIHRoZSBkb21haW4gb2YgQ04uPG86 cD48L286cD48L3NwYW4+PC9kaXY+PGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDBwdDsgZm9u dC1mYW1pbHk6IOWui+S9kzsgZm9udC1zaXplOiAxMnB0OyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMt c2VyaWY7IGZvbnQtc2l6ZTogMTAuNXB0OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9kaXY+ PGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDBwdDsgZm9udC1mYW1pbHk6IOWui+S9kzsgZm9u dC1zaXplOiAxMnB0OyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3 MywgMTI1KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTAu NXB0OyI+SW4gb3VyIEktRCwgd2UgZGVmaW5lIHRoYXQgIkRpc3RyaWJ1dGVkIEhvbWUtUHJveHkg KERIUCkmbmJzcDsgaXMgYSByb3V0ZXIgbmVhciBDTiIuJm5ic3A7IEluIHRoaXMgd2F5LCBESFAg ZG9lc24ndCBoYXZlIHRvIGJlIGxvY2F0ZWQgaW4gQ04nIGRvbWFpbi4gSG93ZXZlciwgd2UgZG8g cmVjb21tZW5kIHRvIGZpbmQgYSBESFAgaW4gQ04ncyBkb21haW4gYmVjYXVzZSBjaG9vc2luZyBE SFAgaW4gb3RoZXIgZG9tYWlucyB3aWxsIG5vdCBndWFyYW50ZWUgcm91dGVyIG9wdGltaXphdGlv biBhbmQgdGh1cyB2aW9sYXRpbmcgb3VyIG9yaWdpbmFsIGludGVudGlvbiB0byBpbnRyb2R1Y2Ug REhQLjxvOnA+PC9vOnA+PC9zcGFuPjwvZGl2PjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAw cHQ7IGZvbnQtZmFtaWx5OiDlrovkvZM7IGZvbnQtc2l6ZTogMTJwdDsiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEwLjVwdDsiPkNob29zaW5nIGEgbW9iaWxpdHkgYWdl bnQgb3V0c2lkZSB0aGUgZG9tYWluIG9mIENOIG1ha2VzIGxpdHRsZSBzZW5zZSBzaW5jZSBvdXIg cHVycG9zZSBpcyB0byBpbXBsZW1lbnQgcm91dGVyIG9wdGltaXphdGlvbiBieSBtb3ZpbmcgdGhl IG1vYmlsaXR5IGFnZW50IGNsb3NlIHRvIENOLjxvOnA+PC9vOnA+PC9zcGFuPjwvZGl2PjxkaXYg c3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwcHQ7IGZvbnQtZmFtaWx5OiDlrovkvZM7IGZvbnQtc2l6 ZTogMTJwdDsiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IHJnYigzMSwgNzMsIDEy NSk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEwLjVwdDsi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZGl2PjwvZGl2PjwvZGl2Pjwvc3Bhbj48L2Jsb2Nr cXVvdGU+PGRpdj48YnI+PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5BcyBsb25nIGFzIHRoZSBt b2JpbGl0eSBhZ2VudCBzdGF5cyBvbiB0aGUgbW9zdCBkaXJlY3QgZGF0YS1wYXRoIGJldHdlZW4g dGhlIE1OIGFuZCBDTiwgdGhlbiBpdCBkb2VzIG5vdCBtYXR0ZXIgd2hlcmUgZXhhY3RseSBpdCBp cy48L2Rpdj48ZGl2PlBsYWNpbmcgdGhlIG1vYmlsaXR5IGFnZW50IGFzIGNsb3NlIHRvIHRoZSBD TiBhcyBwb3NzaWJsZSBpbmNyZWFzZXMgdGhhdCBjaGFuY2UuPC9kaXY+PGRpdj5CdXQgdGhhdCBk b2VzIG5vdCBtZWFuIHRoZSBDTiBzaXRlIGlzIHRoZSBvbmx5IHBsYWNlIGZvciB0aGUgbW9iaWxp dHkgYWdlbnQuPC9kaXY+PGRpdj5UaGUgSVNQIHNlcnZpbmcgdGhlIENOIHNpdGUgaXMgYW5vdGhl ciBuYXR1cmFsIHBsYWNlLjwvZGl2PjxkaXY+QW5kIGl0J2Qgd29yayBqdXN0IGZpbmUuPC9kaXY+ PGRpdj48YnI+PC9kaXY+PGJyPjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuIGNsYXNzPSJB cHBsZS1zdHlsZS1zcGFuIiBzdHlsZT0idGV4dC10cmFuc2Zvcm06IG5vbmU7IHRleHQtaW5kZW50 OiAwcHg7IGxldHRlci1zcGFjaW5nOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyB3aGl0ZS1z cGFjZTogbm9ybWFsOyBib3JkZXItY29sbGFwc2U6IHNlcGFyYXRlOyBvcnBoYW5zOiAyOyB3aWRv d3M6IDI7IC13ZWJraXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC1ib3JkZXItaG9y aXpvbnRhbC1zcGFjaW5nOiAwcHg7IC13ZWJraXQtYm9yZGVyLXZlcnRpY2FsLXNwYWNpbmc6IDBw eDsgLXdlYmtpdC10ZXh0LWRlY29yYXRpb25zLWluLWVmZmVjdDogbm9uZTsgLXdlYmtpdC10ZXh0 LXN0cm9rZS13aWR0aDogMHB4OyI+PGRpdiBsYW5nPSJaSC1DTiIgdmxpbms9InB1cnBsZSIgbGlu az0iYmx1ZSI+PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIiBzdHlsZT0icGFnZTogV29yZFNlY3Rp b24xOyI+PGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDBwdDsgZm9udC1mYW1pbHk6IOWui+S9 kzsgZm9udC1zaXplOiAxMnB0OyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjogcmdi KDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6 ZTogMTAuNXB0OyI+Jmd0OyZndDstIFlvdXIgSS1EIGhhcyBhIHZlcnkgZWxhYm9yYXRlIERIUCBk aXNjb3ZlcnksIHdpdGggYWRkaXRpb25hbCBwcm90b2NvbCB3b3JrLCBzb21lIGV2ZW4gdG91Y2hp bmcgQ04uIE5vdCBzdXJlIHdoeSBpdCBpcyBuZWVkZWQuIFdlIGFyZSBzaW1wbHkgdXNpbmcgRE5T IHJlcXVlc3QgZm9yIHRoYXQuIEl0IGJlY29tZXMganVzdCBhIG1hdHRlciBvZiBwdXR0aW5nIHRo ZSByaWdodCBlbnRyeSBpbiB0aGUgRE5TLjxvOnA+PC9vOnA+PC9zcGFuPjwvZGl2PjxkaXYgc3R5 bGU9Im1hcmdpbjogMGNtIDBjbSAwcHQ7IGZvbnQtZmFtaWx5OiDlrovkvZM7IGZvbnQtc2l6ZTog MTJwdDsiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7 IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEwLjVwdDsiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZGl2PjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAw cHQ7IGZvbnQtZmFtaWx5OiDlrovkvZM7IGZvbnQtc2l6ZTogMTJwdDsiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IGZvbnQtZmFtaWx5OiBDYWxpYnJp LCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEwLjVwdDsiPkluIG91ciBJLUQsIHdlIGhhdmUgcHJv dmlkZWQgc2V2ZXJhbCBvcHRpb25zIGZvciBESFAgZGlzY292ZXJ5IGFuZCBETlMgcmVxdWVzdCBp cyBhbHNvIHVzZWQuIEZvciBleGFtcGxlLCAiTU4gcXVlcnkgdGhlIEROUyB0byBnZXQgdGhlIERI UCBhbnljYXN0IGFkZHJlc3MiLCAiTU4gY2FuIHVzZSBETlMgdG8gcXVlcnkgdGhlIERIUCBtYW5h Z2VtZW50IHNlcnZlciBhZGRyZXNzLiImbmJzcDsgQWN0dWFsbHksIHdlIGFzc3VtZSB0aGVyZSBt YXkgZXhpc3QgbW9yZSB0aGFuIG9uZSBESFAgaW4gb25lIGRvbWFpbi4gTUlQdjYgYWxzbyBhc3N1 bWVzIHRoZXJlIG1heSBleGlzdCBtb3JlIHRoYW4gb25lIEhBIGluIG9uZSBkb21haW4uPG86cD48 L286cD48L3NwYW4+PC9kaXY+PGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDBwdDsgZm9udC1m YW1pbHk6IOWui+S9kzsgZm9udC1zaXplOiAxMnB0OyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2Vy aWY7IGZvbnQtc2l6ZTogMTAuNXB0OyI+PC9zcGFuPjwvZGl2PjwvZGl2PjwvZGl2Pjwvc3Bhbj48 L2Jsb2NrcXVvdGU+PGRpdj48YnI+PC9kaXY+PGRpdj5NYXliZSB5b3UnZCBjb25zaWRlciBkb3du LXNlbGVjdGluZyB0aGVtLiBOb3Qgb25seSB0b28gbWFueSwgYnV0IHN0aWxsIEkgZG9uJ3QgdW5k ZXJzdGFuZCB3aHkgYSBzaW1wbGUgRE5TLWJhc2VkIGxvb2t1cCBsaWtlIHdlIHByb3Bvc2UgaXMg bm90IHN1ZmZpY2llbnQuJm5ic3A7PC9kaXY+PGRpdj48YnI+PC9kaXY+PGJsb2NrcXVvdGUgdHlw ZT0iY2l0ZSI+PHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxlPSJ0ZXh0LXRyYW5z Zm9ybTogbm9uZTsgdGV4dC1pbmRlbnQ6IDBweDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgd29y ZC1zcGFjaW5nOiAwcHg7IHdoaXRlLXNwYWNlOiBub3JtYWw7IGJvcmRlci1jb2xsYXBzZTogc2Vw YXJhdGU7IG9ycGhhbnM6IDI7IHdpZG93czogMjsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBh dXRvOyAtd2Via2l0LWJvcmRlci1ob3Jpem9udGFsLXNwYWNpbmc6IDBweDsgLXdlYmtpdC1ib3Jk ZXItdmVydGljYWwtc3BhY2luZzogMHB4OyAtd2Via2l0LXRleHQtZGVjb3JhdGlvbnMtaW4tZWZm ZWN0OiBub25lOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij48ZGl2IGxhbmc9IlpI LUNOIiB2bGluaz0icHVycGxlIiBsaW5rPSJibHVlIj48ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi IHN0eWxlPSJwYWdlOiBXb3JkU2VjdGlvbjE7Ij48ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20g MHB0OyBmb250LWZhbWlseTog5a6L5L2TOyBmb250LXNpemU6IDEycHQ7Ij48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBmb250LWZhbWlseTogQ2FsaWJy aSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMC41cHQ7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L2Rpdj48ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMHB0OyBmb250LWZhbWlseTog5a6L 5L2TOyBmb250LXNpemU6IDEycHQ7Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiBy Z2IoMzEsIDczLCAxMjUpOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1z aXplOiAxMC41cHQ7Ij4mZ3Q7Jmd0Oy0gT3VyIEktRCBpcyBub3QgbW9kaWZ5aW5nIE1vYmlsZSBJ UCBwcm90b2NvbCBhdCBhbGwuIFlvdSBzZWVtIHRvIGRlZmluZSBuZXcgbWVzc2FnaW5nIGZvciBI b0EgZGlzY292ZXJ5LCBhbmQgYWxzbyBleHRlbmRpbmcgQlUuIEFnYWluLCBub3Qgc3VyZSB3aHkg dGhvc2UgZXh0ZW5zaW9ucyBhcmUgbmVlZGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvZGl2PjxkaXYg c3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwcHQ7IGZvbnQtZmFtaWx5OiDlrovkvZM7IGZvbnQtc2l6 ZTogMTJwdDsiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IHJnYigzMSwgNzMsIDEy NSk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEwLjVwdDsi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZGl2PjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBj bSAwcHQ7IGZvbnQtZmFtaWx5OiDlrovkvZM7IGZvbnQtc2l6ZTogMTJwdDsiPjxzcGFuIGxhbmc9 IkVOLVVTIiBzdHlsZT0iY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IGZvbnQtZmFtaWx5OiBDYWxp YnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEwLjVwdDsiPk91ciBJLUQgaXMgdG90YWxseSBj b21wYXRpYmxlIHdpdGggTW9iaWxlIElQIHByb3RvY29sLiBGb3IgREhQIGRpc2NvdmVyeSwgYXMg d2UgbWVudGlvbmVkIGluIG91ciBJLUQgIlRoaXMgcHJvY2VkdXJlIGlzIHNpbWlsYXIgdG8gImR5 bmFtaWMgaG9tZSBhZ2VudCBhZGRyZXNzIGRpc2NvdmVyeSBtZWNoYW5pc20iIGluIE1JUHY2Ii4g QmVzaWRlcywgd2UgcHJvdmlkZSBvdGhlciBvcHRpb25zIGZvciBwZXJmb3JtYW5jZSBvcHRpbWl6 YXRpb24uPG86cD48L286cD48L3NwYW4+PC9kaXY+PGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNt IDBwdDsgZm9udC1mYW1pbHk6IOWui+S9kzsgZm9udC1zaXplOiAxMnB0OyI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6IENhbGli cmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTAuNXB0OyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9kaXY+PC9kaXY+PC9kaXY+PC9zcGFuPjwvYmxvY2txdW90ZT48ZGl2Pjxicj48L2Rpdj48 ZGl2PiJDb21wYXRpYmxlIiB0ZXJtIG5lZWRzIGV4cGFuZGluZy48L2Rpdj48ZGl2PldoYXQgSSBt ZWFuIGlzICJ3ZSB1c2UgTW9iaWxlIElQIGFzLWlzIi4gV2UgZG9uJ3QgbmVlZCB0byBjaGFuZ2Us IGFkZCwgZXh0ZW5kIGFueXRoaW5nIG9uIHRoYXQuIEluIG90aGVyIHdvcmRzLCB3ZSBkbyBub3Qg cmVxdWlyZSBhbnkgInByb3RvY29sIHdvcmsiLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+PGJy PjwvZGl2PjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPjxzcGFuIGNsYXNzPSJBcHBsZS1zdHlsZS1z cGFuIiBzdHlsZT0idGV4dC10cmFuc2Zvcm06IG5vbmU7IHRleHQtaW5kZW50OiAwcHg7IGxldHRl ci1zcGFjaW5nOiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyB3aGl0ZS1zcGFjZTogbm9ybWFs OyBib3JkZXItY29sbGFwc2U6IHNlcGFyYXRlOyBvcnBoYW5zOiAyOyB3aWRvd3M6IDI7IC13ZWJr aXQtdGV4dC1zaXplLWFkanVzdDogYXV0bzsgLXdlYmtpdC1ib3JkZXItaG9yaXpvbnRhbC1zcGFj aW5nOiAwcHg7IC13ZWJraXQtYm9yZGVyLXZlcnRpY2FsLXNwYWNpbmc6IDBweDsgLXdlYmtpdC10 ZXh0LWRlY29yYXRpb25zLWluLWVmZmVjdDogbm9uZTsgLXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0 aDogMHB4OyI+PGRpdiBsYW5nPSJaSC1DTiIgdmxpbms9InB1cnBsZSIgbGluaz0iYmx1ZSI+PGRp diBjbGFzcz0iV29yZFNlY3Rpb24xIiBzdHlsZT0icGFnZTogV29yZFNlY3Rpb24xOyI+PGRpdiBz dHlsZT0ibWFyZ2luOiAwY20gMGNtIDBwdDsgZm9udC1mYW1pbHk6IOWui+S9kzsgZm9udC1zaXpl OiAxMnB0OyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1 KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTAuNXB0OyI+ Jmd0OyZndDstICIgTU4gZGVjaWRlcyB3aGV0aGVyIHRoZSBzZXJ2aWNlIGZsb3cgbmVlZHMgbW9i aWxpdHkgc3VwcG9ydCBhY2NvcmRpbmcgdG8gdGhlIHNlcnZpY2UgdHlwZSBvZiB0aGUgbmV3IGNv bm5lY3Rpb24gcmVxdWVzdC4iIFRoaXMgaXMgbm90IGNsZWFyLiBJbiBvdXIgY2FzZSB0aGUgZGV0 ZXJtaW5hdGlvbiBpcyB0cmFuc3BhcmVudCB0byB0aGUgdXBwZXIgbGF5ZXJzLiBJZiB0aGUgRE5T IHJldHVybnMgYW4gSVAgYWRkcmVzcyBmb3IgQ0hBLCB0aGVuIENIQSBpcyB1c2VkLjxvOnA+PC9v OnA+PC9zcGFuPjwvZGl2PjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwcHQ7IGZvbnQtZmFt aWx5OiDlrovkvZM7IGZvbnQtc2l6ZTogMTJwdDsiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0i Y29sb3I6IHJnYigzMSwgNzMsIDEyNSk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlm OyBmb250LXNpemU6IDEwLjVwdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZGl2PjxkaXYg c3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwcHQ7IGZvbnQtZmFtaWx5OiDlrovkvZM7IGZvbnQtc2l6 ZTogMTJwdDsiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IHJnYigzMSwgNzMsIDEy NSk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEwLjVwdDsi PlJvdXRlciBvcHRpbWl6YXRpb24gaXMganVzdCBvbmUgcHVycG9zZSBvZiBvdXIgSS1ELCBiZXNp ZGVzIHRoYXQgd2UgYWxzbyBzdXBwb3J0IGZsb3cgbWFuYWdlbWVudCBhbmQgZmxvdyBoYW5kb2Zm IGZvciBoaWdoIGxldmVsIHVzZXJzLiBPZiBjb3Vyc2UsIHVzZXJzIGNhbiBjaG9vc2Ugbm90IHRv IHVzZSBzdWNoIGZ1bmN0aW9ucywganVzdCBhcyB5b3UgbWVudGlvbmVkLjxvOnA+PC9vOnA+PC9z cGFuPjwvZGl2PjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwcHQ7IGZvbnQtZmFtaWx5OiDl rovkvZM7IGZvbnQtc2l6ZTogMTJwdDsiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6 IHJnYigzMSwgNzMsIDEyNSk7IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250 LXNpemU6IDEwLjVwdDsiPjwvc3Bhbj48L2Rpdj48L2Rpdj48L2Rpdj48L3NwYW4+PC9ibG9ja3F1 b3RlPjxkaXY+PGJyPjwvZGl2PjxkaXY+SSB0aG91Z2h0IHlvdXIgSS1EIGRpZCBvbmUgdGhpbmcs IGFuZCBpdCdzIGV4cGxhaW5lZCBpbiB0ZXJtcyBvZiBtYW5hZ2luZyBmbG93cyAod2l0aCB0aGUg Q05zKS4gTm93IHRoYXQgeW91IGFyZSByZWZlcnJpbmcgdG8gdHdvIHNlcGFyYXRlIHRoaW5nczog InJvdXRlciBvcHRpbWl6YXRpb24iIGFuZCAiZmxvdyBtYW5hZ2VtZW50IGFuZCBmbG93IGhhbmRv ZmYiIHN1Z2dlc3RzIHRoYXQgSSdtIG1pc3Npbmcgb25lIG9mIHRoZSB0d28gdGhpbmdz4oCmJm5i c3A7PC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5CZXNpZGVzLCBjb21pbmcgYmFjayB0byBteSBx dWVzdGlvbjogSG93IGRvZXMgTU4gZGVjaWRlIHdoZXRoZXIgYSBzZXJ2aWNlIGZsb3cgbmVlZHMg bW9iaWxpdHkgc3VwcG9ydD8gV2hhdCBhcmUgdGhlIHNlcnZpY2UgdHlwZXM/IEhvdyBhcmUgdGhl eSBjb252ZXllZCBmcm9tIHRoZSBhcHBsaWNhdGlvbnMoPykgdG8gdGhlIElQIHN0YWNrLiBUaGVz ZSBhcmUgdGhlIHF1ZXN0aW9ucyB0aGF0IGFyaXNlIHdoZW4gcmVhZGluZyB0aGF0IHN0YXRlbWVu dCBpbiB5b3VyIEktRC48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48YnI+PGJs b2NrcXVvdGUgdHlwZT0iY2l0ZSI+PHNwYW4gY2xhc3M9IkFwcGxlLXN0eWxlLXNwYW4iIHN0eWxl PSJ0ZXh0LXRyYW5zZm9ybTogbm9uZTsgbGluZS1oZWlnaHQ6IG5vcm1hbDsgdGV4dC1pbmRlbnQ6 IDBweDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgZm9udC1zdHlsZTogbm9ybWFsOyBmb250LXZh cmlhbnQ6IG5vcm1hbDsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgd29yZC1zcGFjaW5nOiAwcHg7IHdo aXRlLXNwYWNlOiBub3JtYWw7IGJvcmRlci1jb2xsYXBzZTogc2VwYXJhdGU7IG9ycGhhbnM6IDI7 IHdpZG93czogMjsgLXdlYmtpdC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LWJvcmRl ci1ob3Jpem9udGFsLXNwYWNpbmc6IDBweDsgLXdlYmtpdC1ib3JkZXItdmVydGljYWwtc3BhY2lu ZzogMHB4OyAtd2Via2l0LXRleHQtZGVjb3JhdGlvbnMtaW4tZWZmZWN0OiBub25lOyAtd2Via2l0 LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7Ij48ZGl2IGxhbmc9IlpILUNOIiB2bGluaz0icHVycGxl IiBsaW5rPSJibHVlIj48ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiIHN0eWxlPSJwYWdlOiBXb3Jk U2VjdGlvbjE7Ij48ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMHB0OyBmb250LWZhbWlseTog 5a6L5L2TOyBmb250LXNpemU6IDEycHQ7Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y OiByZ2IoMzEsIDczLCAxMjUpOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9u dC1zaXplOiAxMC41cHQ7Ij4mZ3Q7Jmd0Oy0gVGhlcmUncyBhbiBhc3N1bXB0aW9uIHRoYXQgTU4g aGFzIGEgSG9BIGFuZCBDTiBrbm93cyB0aGF0LiBOb3Qgc3VyZSB3aHkgdGhpcyBpcyBuZWVkZWQu PG86cD48L286cD48L3NwYW4+PC9kaXY+PGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDBwdDsg Zm9udC1mYW1pbHk6IOWui+S9kzsgZm9udC1zaXplOiAxMnB0OyI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNh bnMtc2VyaWY7IGZvbnQtc2l6ZTogMTAuNXB0OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9k aXY+PGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDBwdDsgZm9udC1mYW1pbHk6IOWui+S9kzsg Zm9udC1zaXplOiAxMnB0OyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjogcmdiKDMx LCA3MywgMTI1KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTog MTAuNXB0OyI+V2UgZG9uJ3QgaGF2ZSBzdWNoIGFuIGFzc3VtcHRpb24uIE1heWJlIHlvdSBtZWFu IHRoaXMgc2VudGVuY2UgaW4gb3VyIEktRCAmbmJzcDsiQSBub3RpY2UgaXMgdGhhdCwgTU4gd2ls bCB1c2UgSG9BIHRvIGVzdGFibGlzaCB0aGUgY29ubmVjdGlvbiB3aXRoIENOIGlmIHRoZSBESFAg cXVlcnkgaXMgZmFpbGVkLCB3aGljaCBtZWFucyBubyBESFAgaXMgZm91bmQgdG8mbmJzcDsgc2Vy dmUgdGhlIGN1cnJlbnQgTU4uIExhdGVyIHdvcmtmbG93IGlzIHRoZSBzYW1lIGFzIHRoYXQgZGVm aW5lZCBpbiBNSVB2Ni4iIEFzIHlvdSBjYW4gc2VlLCBpdCBpcyBvbmx5IGEgY29tcGxldGUgY29u c2lkZXJhdGlvbiBmb3IgZXhjZXB0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvZGl2PjxkaXYgc3R5 bGU9Im1hcmdpbjogMGNtIDBjbSAwcHQ7IGZvbnQtZmFtaWx5OiDlrovkvZM7IGZvbnQtc2l6ZTog MTJwdDsiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IHJnYigzMSwgNzMsIDEyNSk7 IGZvbnQtZmFtaWx5OiBDYWxpYnJpLCBzYW5zLXNlcmlmOyBmb250LXNpemU6IDEwLjVwdDsiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZGl2PjwvZGl2PjwvZGl2Pjwvc3Bhbj48L2Jsb2NrcXVv dGU+PGRpdj48YnI+PC9kaXY+PGRpdj5Zb3VyIEktRCBzYXlzOjwvZGl2PjxkaXY+PGJyPjwvZGl2 PjxkaXY+PHByZSBzdHlsZT0iY29sb3I6IHJnYigwLCAwLCAwKTsgdGV4dC10cmFuc2Zvcm06IG5v bmU7IGxpbmUtaGVpZ2h0OiBub3JtYWw7IHRleHQtaW5kZW50OiAwcHg7IGxldHRlci1zcGFjaW5n OiBub3JtYWw7IGZvbnQtc3R5bGU6IG5vcm1hbDsgZm9udC12YXJpYW50OiBub3JtYWw7IGZvbnQt d2VpZ2h0OiBub3JtYWw7IHdvcmQtc3BhY2luZzogMHB4OyB3aGl0ZS1zcGFjZTogcHJlLXdyYXA7 IC1tcy13b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IG9ycGhhbnM6IDI7IHdpZG93czogMjsgLXdlYmtp dC10ZXh0LXNpemUtYWRqdXN0OiBhdXRvOyAtd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7 Ij4gICBUaGlzIHN0YW5kYXJkIGlzIGNvbXBsaWFudCB3aXRoIHN0YW5kYXJkIE1JUHY2LCB3aGlj aCBtZWFucyBNTiBzdGlsbAogICBoYXMgSG9BIGluIGhvbWUgZG9tYWluLiBXaGVuIE1OIGlzIGlu aXRpYXRpbmcgYSBuZXcgY29ubmVjdGlvbiB3aXRoCiAgIERNSVB2NiwgaXQgd2lsbCBmaXJzdCBh cHBseSBmb3IgREhvQS4gQWNjb3JkaW5nIHRvIE1JUHY2LCBNTidzIEhvQSBpcwogICBwZXJtYW5l bnQgZHVyaW5nIGluIGl0cyB0cmF2ZWxsaW5nLCBzbyBDTiBhbHdheXMga25vd3MgaXRzIEhvQS48 L3ByZT48ZGl2Pjxicj48L2Rpdj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2Pjxicj48L2Rpdj48 YnI+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGRpdiBsYW5nPSJaSC1DTiIgdmxpbms9InB1cnBs ZSIgbGluaz0iYmx1ZSI+PGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIiBzdHlsZT0icGFnZTogV29y ZFNlY3Rpb24xOyI+PGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDBwdDsgZm9udC1mYW1pbHk6 IOWui+S9kzsgZm9udC1zaXplOiAxMnB0OyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv cjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZv bnQtc2l6ZTogMTAuNXB0OyI+Jmd0OyZndDtPdmVyYWxsLCBhcyB5b3UgY2FuIHNlZSBmcm9tIG91 ciBJLUQsIHdlIGJlbGlldmUgZHluYW1pY2FsbHkgYW5jaG9yaW5nIHRoZSBJUCBhZGRyZXNzIHNv bWV3aGVyZSBjbG9zZSB0byB0aGUgQ04gY2FuIGJlIGFjaGlldmVkIHdpdGhvdXQgYW55IHByb3Rv Y29sIHdvcmsuPG86cD48L286cD48L3NwYW4+PC9kaXY+PGRpdiBzdHlsZT0ibWFyZ2luOiAwY20g MGNtIDBwdDsgZm9udC1mYW1pbHk6IOWui+S9kzsgZm9udC1zaXplOiAxMnB0OyI+PHNwYW4gbGFu Zz0iRU4tVVMiIHN0eWxlPSJjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6IENh bGlicmksIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTAuNXB0OyI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9kaXY+PGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDBwdDsgZm9udC1mYW1pbHk6 IOWui+S9kzsgZm9udC1zaXplOiAxMnB0OyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xv cjogcmdiKDMxLCA3MywgMTI1KTsgZm9udC1mYW1pbHk6IENhbGlicmksIHNhbnMtc2VyaWY7IGZv bnQtc2l6ZTogMTAuNXB0OyI+QWN0dWFsbHksIEkgcmVhbGx5IGRvbid0IGJlbGlldmUgd2UgY2Fu IGltcGxlbWVudCBwcm90b2NvbCBvcHRpbWl6YXRpb24gd2l0aG91dCBkb2luZyBhbnkgY2hhbmdl IHRvIGl0LiBBY3R1YWxseSwgeW91IGRlZmluaXRlbHkgbmVlZCB0byBjaGFuZ2UgdGhlIGltcGxl bWVudGF0aW9uIGZvciBNTiBpbiB5b3VyIEktRC48bzpwPjwvbzpwPjwvc3Bhbj48L2Rpdj48ZGl2 IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMHB0OyBmb250LWZhbWlseTog5a6L5L2TOyBmb250LXNp emU6IDEycHQ7Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiByZ2IoMzEsIDczLCAx MjUpOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMC41cHQ7 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2Rpdj48L2Rpdj48L2Rpdj48L2Jsb2NrcXVvdGU+ PGRpdj48YnI+PC9kaXY+PGRpdj5UaGVyZSdzIGltcGxlbWVudGF0aW9uIHdvcmsgdG8gYmUgYXBw bGllZCB0byBNTiwgeWVzLiZuYnNwOzwvZGl2PjxkaXY+VGhlIHF1ZXN0aW9uIGlzOiBEbyB3ZSBu ZWVkIHRvIG1vZGlmeSBNb2JpbGUgSVAsIG9yIGRvIHdlIG5lZWQgdG8gZGVzaWduICZuYnNwO2Eg bmV3IHByb3RvY29sPyZuYnNwOzwvZGl2PjxkaXY+T3VyIEktRCBzYXlzIG5vLjwvZGl2PjxkaXY+ WW91cnMgc2F5cyB5ZXMuJm5ic3A7PC9kaXY+PGRpdj5UaGF0J3MgYWxzbyBhIGRpZmZlcmVuY2Us IG9yIGEgY29uc2VxdWVuY2Ugb2YgYSBudW1iZXIgb2YgZGlmZmVyZW5jZXMgYmV0d2VlbiB0aGUg dHdvIEktRHMuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5BbHBlcjwvZGl2PjxkaXY+PGJyPjwv ZGl2PjxkaXY+PGJyPjwvZGl2Pjxicj48YmxvY2txdW90ZSB0eXBlPSJjaXRlIj48ZGl2IGxhbmc9 IlpILUNOIiB2bGluaz0icHVycGxlIiBsaW5rPSJibHVlIj48ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiIHN0eWxlPSJwYWdlOiBXb3JkU2VjdGlvbjE7Ij48ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAw Y20gMHB0OyBmb250LWZhbWlseTog5a6L5L2TOyBmb250LXNpemU6IDEycHQ7Ij48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBmb250LWZhbWlseTogQ2Fs aWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMC41cHQ7Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L2Rpdj48ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMHB0OyBmb250LWZhbWlseTog 5a6L5L2TOyBmb250LXNpemU6IDEycHQ7Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9y OiByZ2IoMzEsIDczLCAxMjUpOyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9u dC1zaXplOiAxMC41cHQ7Ij5NaW48bzpwPjwvbzpwPjwvc3Bhbj48L2Rpdj48ZGl2IHN0eWxlPSJt YXJnaW46IDBjbSAwY20gMHB0OyBmb250LWZhbWlseTog5a6L5L2TOyBmb250LXNpemU6IDEycHQ7 Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyBmb250 LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsgZm9udC1zaXplOiAxMC41cHQ7Ij48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNh OyBmb250LXNpemU6IG1lZGl1bTsiPjxkaXYgc3R5bGU9ImJvcmRlci1zdHlsZTogc29saWQgbm9u ZSBub25lOyBwYWRkaW5nOiAzcHQgMGNtIDBjbTsgYm9yZGVyLXRvcC1jb2xvcjogcmdiKDE4MSwg MTk2LCAyMjMpOyBib3JkZXItdG9wLXdpZHRoOiAxcHQ7Ij48ZGl2IHN0eWxlPSJtYXJnaW46IDBj bSAwY20gMHB0OyBmb250LWZhbWlseTog5a6L5L2TOyBmb250LXNpemU6IDEycHQ7Ij48Yj48c3Bh biBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2VyaWY7IGZv bnQtc2l6ZTogMTBwdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtZmFtaWx5OiBUYWhvbWEsIHNhbnMtc2VyaWY7IGZvbnQtc2l6ZTogMTBwdDsiPjxzcGFu IGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj5BbHBlciBZZWdpbiBb bWFpbHRvOjxhIGhyZWY9Im1haWx0bzphbHBlci55ZWdpbkB5ZWdpbi5vcmciIHRhcmdldD0iX2Js YW5rIj5hbHBlci55ZWdpbkB5ZWdpbi5vcmc8L2E+XTxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+PGI+U2VudDo8L2I+PHNwYW4gY2xhc3M9IkFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPlRodXJzZGF5LCBKdWx5IDI1LCAyMDEzIDQ6 MDMgUE08YnI+PGI+VG86PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj5NaW4gTGl1PGJyPjxiPkNjOjwvYj48c3BhbiBjbGFzcz0iQXBwbGUtY29udmVy dGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+Sm91bmkgS29yaG9uZW47IDxhIGhyZWY9Im1haWx0bzpk bW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5kbW1AaWV0Zi5vcmc8L2E+OyA8YSBocmVmPSJt YWlsdG86d2FuZ3l1d2VpQGljdC5hYy5jbiIgdGFyZ2V0PSJfYmxhbmsiPndhbmd5dXdlaUBpY3Qu YWMuY248L2E+PGJyPjxiPlN1YmplY3Q6PC9iPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj5SZTogW0RNTV0gY29tbWVudHMvcXVlc3Rpb25zIG9mIGRyYWZ0 LXllZ2luLWRtbS1jbmV0LWhvbWluZy0wMDxvOnA+PC9vOnA+PC9zcGFuPjwvZGl2PjwvZGl2Pjwv ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwcHQ7IGZvbnQtZmFtaWx5OiDlrovkvZM7 IGZvbnQtc2l6ZTogMTJwdDsiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L2Rpdj48ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMHB0OyBmb250LWZhbWlseTog 5a6L5L2TOyBmb250LXNpemU6IDEycHQ7Ij48c3BhbiBsYW5nPSJFTi1VUyI+SGkgTGl1LDxvOnA+ PC9vOnA+PC9zcGFuPjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZv bnQtc2l6ZTogbWVkaXVtOyI+PGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDBwdDsgZm9udC1m YW1pbHk6IOWui+S9kzsgZm9udC1zaXplOiAxMnB0OyI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZGl2PjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBI ZWx2ZXRpY2E7IGZvbnQtc2l6ZTogbWVkaXVtOyI+PGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNt IDBwdDsgZm9udC1mYW1pbHk6IOWui+S9kzsgZm9udC1zaXplOiAxMnB0OyI+PHNwYW4gbGFuZz0i RU4tVVMiPlllcyBpdCBzZWVtcyBsaWtlIHdlIGFyZSBhcHByb2FjaGluZyB0aGUgRE1NIHByb2Js ZW0gaW4gdGhlIHNhbWUgd2F5LjxvOnA+PC9vOnA+PC9zcGFuPjwvZGl2PjwvZGl2PjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogbWVkaXVtOyI+PGRpdiBzdHls ZT0ibWFyZ2luOiAwY20gMGNtIDBwdDsgZm9udC1mYW1pbHk6IOWui+S9kzsgZm9udC1zaXplOiAx MnB0OyI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZGl2Pjwv ZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogbWVkaXVt OyI+PGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDBwdDsgZm9udC1mYW1pbHk6IOWui+S9kzsg Zm9udC1zaXplOiAxMnB0OyI+PHNwYW4gbGFuZz0iRU4tVVMiPkF0IHRoZSB0ZWNobmljYWwgZGV0 YWlsIGxldmVsIGhlcmUgYXJlIHRoZSBlc3NlbnRpYWwgZGlmZmVyZW5jZXMgYmV0d2VlbiB0d28g SS1Eczo8bzpwPjwvbzpwPjwvc3Bhbj48L2Rpdj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWls eTogSGVsdmV0aWNhOyBmb250LXNpemU6IG1lZGl1bTsiPjxkaXYgc3R5bGU9Im1hcmdpbjogMGNt IDBjbSAwcHQ7IGZvbnQtZmFtaWx5OiDlrovkvZM7IGZvbnQtc2l6ZTogMTJwdDsiPjxzcGFuIGxh bmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2Rpdj48L2Rpdj48ZGl2IHN0eWxl PSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IG1lZGl1bTsiPjxkaXYgc3R5bGU9 Im1hcmdpbjogMGNtIDBjbSAwcHQ7IGZvbnQtZmFtaWx5OiDlrovkvZM7IGZvbnQtc2l6ZTogMTJw dDsiPjxzcGFuIGxhbmc9IkVOLVVTIj4tIFRoZSBtb2JpbGl0eSBhZ2VudCBpbiBvdXIgY2FzZSBj YW4gZXZlbiBiZSBvdXRzaWRlIHRoZSBkb21haW4gb2YgQ04uJm5ic3A7PG86cD48L286cD48L3Nw YW4+PC9kaXY+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1z aXplOiBtZWRpdW07Ij48ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMHB0OyBmb250LWZhbWls eTog5a6L5L2TOyBmb250LXNpemU6IDEycHQ7Ij48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9kaXY+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZl dGljYTsgZm9udC1zaXplOiBtZWRpdW07Ij48ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMHB0 OyBmb250LWZhbWlseTog5a6L5L2TOyBmb250LXNpemU6IDEycHQ7Ij48c3BhbiBsYW5nPSJFTi1V UyI+LSBZb3VyIEktRCBoYXMgYSB2ZXJ5IGVsYWJvcmF0ZSBESFAgZGlzY292ZXJ5LCB3aXRoIGFk ZGl0aW9uYWwgcHJvdG9jb2wgd29yaywgc29tZSBldmVuIHRvdWNoaW5nIENOLiBOb3Qgc3VyZSB3 aHkgaXQgaXMgbmVlZGVkLiBXZSBhcmUgc2ltcGx5IHVzaW5nIEROUyByZXF1ZXN0IGZvciB0aGF0 LiBJdCBiZWNvbWVzIGp1c3QgYSBtYXR0ZXIgb2YgcHV0dGluZyB0aGUgcmlnaHQgZW50cnkgaW4g dGhlIEROUy48bzpwPjwvbzpwPjwvc3Bhbj48L2Rpdj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZh bWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IG1lZGl1bTsiPjxkaXYgc3R5bGU9Im1hcmdpbjog MGNtIDBjbSAwcHQ7IGZvbnQtZmFtaWx5OiDlrovkvZM7IGZvbnQtc2l6ZTogMTJwdDsiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2Rpdj48L2Rpdj48ZGl2IHN0 eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IG1lZGl1bTsiPjxkaXYgc3R5 bGU9Im1hcmdpbjogMGNtIDBjbSAwcHQ7IGZvbnQtZmFtaWx5OiDlrovkvZM7IGZvbnQtc2l6ZTog MTJwdDsiPjxzcGFuIGxhbmc9IkVOLVVTIj4tIE91ciBJLUQgaXMgbm90IG1vZGlmeWluZyBNb2Jp bGUgSVAgcHJvdG9jb2wgYXQgYWxsLiBZb3Ugc2VlbSB0byBkZWZpbmUgbmV3IG1lc3NhZ2luZyBm b3IgSG9BIGRpc2NvdmVyeSwgYW5kIGFsc28gZXh0ZW5kaW5nIEJVLiBBZ2Fpbiwgbm90IHN1cmUg d2h5IHRob3NlIGV4dGVuc2lvbnMgYXJlIG5lZWRlZC48bzpwPjwvbzpwPjwvc3Bhbj48L2Rpdj48 L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IG1lZGl1 bTsiPjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwcHQ7IGZvbnQtZmFtaWx5OiDlrovkvZM7 IGZvbnQtc2l6ZTogMTJwdDsiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L2Rpdj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250 LXNpemU6IG1lZGl1bTsiPjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwcHQ7IGZvbnQtZmFt aWx5OiDlrovkvZM7IGZvbnQtc2l6ZTogMTJwdDsiPjxzcGFuIGxhbmc9IkVOLVVTIj4tICI8L3Nw YW4+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6ICZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7OyI+PHNwYW4gY2xhc3M9IkFw cGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPk1OIGRlY2lkZXMgd2hldGhlciB0aGUg c2VydmljZSBmbG93IG5lZWRzIG1vYmlsaXR5IHN1cHBvcnQgYWNjb3JkaW5nIHRvIHRoZSBzZXJ2 aWNlIHR5cGUgb2YgdGhlIG5ldyBjb25uZWN0aW9uIHJlcXVlc3QuIiBUaGlzIGlzIG5vdCBjbGVh ci4gSW4gb3VyIGNhc2UgdGhlIGRldGVybWluYXRpb24gaXMgdHJhbnNwYXJlbnQgdG8gdGhlIHVw cGVyIGxheWVycy4gSWYgdGhlIEROUyByZXR1cm5zIGFuIElQIGFkZHJlc3MgZm9yIENIQSwgdGhl biBDSEEgaXMgdXNlZC48L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L2Rpdj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBm b250LXNpemU6IG1lZGl1bTsiPjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwcHQ7IGZvbnQt ZmFtaWx5OiDlrovkvZM7IGZvbnQtc2l6ZTogMTJwdDsiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6ICZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7OyI+PGJyPjxicj48L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvZGl2PjwvZGl2PjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogbWVkaXVtOyI+PGRpdiBzdHls ZT0ibWFyZ2luOiAwY20gMGNtIDBwdDsgZm9udC1mYW1pbHk6IOWui+S9kzsgZm9udC1zaXplOiAx MnB0OyI+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxzcGFuIGxhbmc9IkVOLVVTIiBz dHlsZT0iZm9udC1mYW1pbHk6ICZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7OyI+LSBUaGVyZSdzIGFu IGFzc3VtcHRpb24gdGhhdCBNTiBoYXMgYSBIb0EgYW5kIENOIGtub3dzIHRoYXQuIE5vdCBzdXJl IHdoeSB0aGlzIGlzIG5lZWRlZC48L3NwYW4+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpw PjwvbzpwPjwvc3Bhbj48L2Rpdj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0 aWNhOyBmb250LXNpemU6IG1lZGl1bTsiPjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwcHQ7 IGZvbnQtZmFtaWx5OiDlrovkvZM7IGZvbnQtc2l6ZTogMTJwdDsiPjxzcGFuIGxhbmc9IkVOLVVT IiBzdHlsZT0iZm9udC1mYW1pbHk6ICZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7OyI+PGJyPjxicj48 L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvZGl2PjwvZGl2Pjxk aXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogbWVkaXVtOyI+PGRp diBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDBwdDsgZm9udC1mYW1pbHk6IOWui+S9kzsgZm9udC1z aXplOiAxMnB0OyI+PHNwYW4gY2xhc3M9ImFwcGxlLXN0eWxlLXNwYW4iPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6ICZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7OyI+T3ZlcmFs bCwgYXMgeW91IGNhbiBzZWUgZnJvbSBvdXIgSS1ELCB3ZSBiZWxpZXZlIGR5bmFtaWNhbGx5IGFu Y2hvcmluZyB0aGUgSVAgYWRkcmVzcyBzb21ld2hlcmUgY2xvc2UgdG8gdGhlIENOIGNhbiBiZSBh Y2hpZXZlZCB3aXRob3V0IGFueSBwcm90b2NvbCB3b3JrLjwvc3Bhbj48L3NwYW4+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvZGl2PjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQt ZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogbWVkaXVtOyI+PGRpdiBzdHlsZT0ibWFyZ2lu OiAwY20gMGNtIDBwdDsgZm9udC1mYW1pbHk6IOWui+S9kzsgZm9udC1zaXplOiAxMnB0OyI+PHNw YW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTogJnF1b3Q7Q291cmllciBOZXcmcXVv dDs7Ij48YnI+PGJyPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+ PC9kaXY+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXpl OiBtZWRpdW07Ij48ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMHB0OyBmb250LWZhbWlseTog 5a6L5L2TOyBmb250LXNpemU6IDEycHQ7Ij48c3BhbiBjbGFzcz0iYXBwbGUtc3R5bGUtc3BhbiI+ PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTogJnF1b3Q7Q291cmllciBOZXcm cXVvdDs7Ij5BbHBlcjwvc3Bhbj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvZGl2PjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZv bnQtc2l6ZTogbWVkaXVtOyI+PGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDBwdDsgZm9udC1m YW1pbHk6IOWui+S9kzsgZm9udC1zaXplOiAxMnB0OyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxl PSJmb250LWZhbWlseTogJnF1b3Q7Q291cmllciBOZXcmcXVvdDs7Ij48YnI+PGJyPjwvc3Bhbj48 c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286cD48L3NwYW4+PC9kaXY+PC9kaXY+PGRpdiBzdHls ZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsgZm9udC1zaXplOiBtZWRpdW07Ij48ZGl2IHN0eWxl PSJtYXJnaW46IDBjbSAwY20gMHB0OyBmb250LWZhbWlseTog5a6L5L2TOyBmb250LXNpemU6IDEy cHQ7Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtZmFtaWx5OiAmcXVvdDtDb3VyaWVy IE5ldyZxdW90OzsiPjxicj48YnI+PC9zcGFuPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpw Pjwvc3Bhbj48L2Rpdj48L2Rpdj48ZGl2IHN0eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBm b250LXNpemU6IG1lZGl1bTsiPjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwcHQ7IGZvbnQt ZmFtaWx5OiDlrovkvZM7IGZvbnQtc2l6ZTogMTJwdDsiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1mYW1pbHk6ICZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7OyI+PGJyPjxicj48L3NwYW4+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvZGl2PjwvZGl2PjxkaXYgc3R5 bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogbWVkaXVtOyI+PGRpdiBzdHls ZT0ibWFyZ2luOiAwY20gMGNtIDBwdDsgZm9udC1mYW1pbHk6IOWui+S9kzsgZm9udC1zaXplOiAx MnB0OyI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LWZhbWlseTogJnF1b3Q7Q291cmll ciBOZXcmcXVvdDs7Ij48YnI+PGJyPjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyI+PG86cD48L286 cD48L3NwYW4+PC9kaXY+PC9kaXY+PGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6IEhlbHZldGljYTsg Zm9udC1zaXplOiBtZWRpdW07Ij48ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMHB0OyBmb250 LWZhbWlseTog5a6L5L2TOyBmb250LXNpemU6IDEycHQ7Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9ImZvbnQtZmFtaWx5OiAmcXVvdDtDb3VyaWVyIE5ldyZxdW90OzsiPjxicj48YnI+PC9zcGFu PjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L2Rpdj48L2Rpdj48ZGl2IHN0 eWxlPSJmb250LWZhbWlseTogSGVsdmV0aWNhOyBmb250LXNpemU6IG1lZGl1bTsiPjxkaXYgc3R5 bGU9Im1hcmdpbjogMGNtIDBjbSAwcHQ7IGZvbnQtZmFtaWx5OiDlrovkvZM7IGZvbnQtc2l6ZTog MTJwdDsiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iZm9udC1mYW1pbHk6ICZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7OyI+PGJyPjxicj48L3NwYW4+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+PC9v OnA+PC9zcGFuPjwvZGl2PjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7 IGZvbnQtc2l6ZTogbWVkaXVtOyI+PGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDBwdDsgZm9u dC1mYW1pbHk6IOWui+S9kzsgZm9udC1zaXplOiAxMnB0OyI+PHNwYW4gbGFuZz0iRU4tVVMiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZGl2PjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5 OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogbWVkaXVtOyI+PGRpdiBzdHlsZT0ibWFyZ2luOiAwY20g MGNtIDBwdDsgZm9udC1mYW1pbHk6IOWui+S9kzsgZm9udC1zaXplOiAxMnB0OyI+PHNwYW4gbGFu Zz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZGl2PjwvZGl2PjxkaXYgc3R5bGU9 ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogbWVkaXVtOyI+PGRpdiBzdHlsZT0i bWFyZ2luOiAwY20gMGNtIDBwdDsgZm9udC1mYW1pbHk6IOWui+S9kzsgZm9udC1zaXplOiAxMnB0 OyI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZGl2PjwvZGl2 PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogbWVkaXVtOyI+ PGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDBwdDsgZm9udC1mYW1pbHk6IOWui+S9kzsgZm9u dC1zaXplOiAxMnB0OyI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvZGl2PjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6 ZTogbWVkaXVtOyI+PGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDBwdDsgZm9udC1mYW1pbHk6 IOWui+S9kzsgZm9udC1zaXplOiAxMnB0OyI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvZGl2PjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFtaWx5OiBIZWx2ZXRp Y2E7IGZvbnQtc2l6ZTogbWVkaXVtOyI+PGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDBwdDsg Zm9udC1mYW1pbHk6IOWui+S9kzsgZm9udC1zaXplOiAxMnB0OyI+PHNwYW4gbGFuZz0iRU4tVVMi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZGl2PjwvZGl2PjxkaXYgc3R5bGU9ImZvbnQtZmFt aWx5OiBIZWx2ZXRpY2E7IGZvbnQtc2l6ZTogbWVkaXVtOyI+PGRpdiBzdHlsZT0ibWFyZ2luOiAw Y20gMGNtIDBwdDsgZm9udC1mYW1pbHk6IOWui+S9kzsgZm9udC1zaXplOiAxMnB0OyI+PHNwYW4g bGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZGl2PjxkaXY+PGRpdj48ZGl2 IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMHB0OyBmb250LWZhbWlseTog5a6L5L2TOyBmb250LXNp emU6IDEycHQ7Ij48c3BhbiBsYW5nPSJFTi1VUyI+T24gSnVsIDI0LCAyMDEzLCBhdCA0OjU4IFBN LDxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+ 5YiY5pWPPHNwYW4gbGFuZz0iRU4tVVMiPjxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3Bh Y2UiPiZuYnNwOzwvc3Bhbj53cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L2Rpdj48L2Rpdj48ZGl2 IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMHB0OyBmb250LWZhbWlseTog5a6L5L2TOyBmb250LXNp emU6IDEycHQ7Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPjxicj48bzpwPjwvbzpwPjwvc3Bhbj48 L2Rpdj48ZGl2IHN0eWxlPSJtYXJnaW46IDBjbSAwY20gMHB0OyBmb250LWZhbWlseTog5a6L5L2T OyBmb250LXNpemU6IDEycHQ7Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPkhpLCBBbHBlciw8bzpw PjwvbzpwPjwvc3Bhbj48L2Rpdj48ZGl2PjxkaXYgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAwcHQ7 IGZvbnQtZmFtaWx5OiDlrovkvZM7IGZvbnQtc2l6ZTogMTJwdDsiPjxzcGFuIGxhbmc9IkVOLVVT Ij5XZSBzdWJtaXRlZCBhIGRyYWZ0IHRvIERNTSBpbiBNYXJjaCAoPGEgc3R5bGU9ImNvbG9yOiBi bHVlOyB0ZXh0LWRlY29yYXRpb246IHVuZGVybGluZTsiIGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tl ci5pZXRmLm9yZy9kb2MvZHJhZnQtbGl1LWRtbS1mbG93cy1kaXN0cmlidXRpb24tYW5kLWhhbmRv ZmYvP2luY2x1ZGVfdGV4dD0xIiB0YXJnZXQ9Il9ibGFuayI+aHR0cDovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1saXUtZG1tLWZsb3dzLWRpc3RyaWJ1dGlvbi1hbmQtaGFuZG9mZi8/ aW5jbHVkZV90ZXh0PTE8L2E+KSBhbmQgbWFkZSBhIHByZXNlbnRhdGlvbiBpbiBsYXN0IElFVEYg bWVldGluZyBpbiBPcmxhbmRvLiBJIHRoaW5rIHRoZSBtYWluIGlkZWEgaW4geW91ciBkcmFmdCBp cyBhbG1vc3QgdGhlIHNhbWUgd2l0aCBvdXIgSS1ELiBJbiBvdXIgZHJhZnQsIHdlIHByb3Bvc2Ug YSBuZXcgZW50aXR5IG5hbWVkIERpc3RyaWJ1dGVkIEhvbWUtUHJveHkgKERIUCkgdGhhdCBpcyBh IHJvdXRlciBuZWFyIENOLCB3aXRoIHRoZSBmdW5jdGlvbiBmb3IgYW4gZXh0ZW5zaW9uIG9mIHRo ZSBIQSwgdG8gYXNzaWduIERpc3RyaWJ1dGVkIEhvbWUgQWRkcmVzcyAoREhvQSkgZm9yIHRoZSBN TiB0byBpbXBsZW1lbnQgcm91dGVyIG9wdGltaXphdGlvbi4gSW4geW91ciBkcmFmdCwgeW91IHBy b3Bvc2UgYSBDb3JyZXNwb25kaW5nIEhvbWUgQWdlbnQgKENIQSkgbG9jYXRlZCBuZWFyIENOcyB0 byBhbGxvY2F0ZSBhIEhvQSB0byB0aGUgTU4gKENvcnJlc3BvbmRpbmcgSG9tZSBBZGRyZXNzLCBD SG9BKS4gQXMgSSBzZWUgaXQsIHRoZSBDSEEgaXMganVzdCB0aGUgREhQIGFuZCBDSG9BIGlzIHRo ZSBzYW1lIGFzIERIb0EuIENvdWxkIHlvdSBwbGVhc2UgZXhwbGFpbiB0aGUgbmV3IGNvbnRyaWJ1 dGlvbiBpbiB5b3VyIGRyYWZ0PzxvOnA+PC9vOnA+PC9zcGFuPjwvZGl2PjwvZGl2PjxkaXY+PGRp diBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDBwdDsgZm9udC1mYW1pbHk6IOWui+S9kzsgZm9udC1z aXplOiAxMnB0OyI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv ZGl2PjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDBwdDsgZm9udC1mYW1p bHk6IOWui+S9kzsgZm9udC1zaXplOiAxMnB0OyI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvZGl2PjwvZGl2PjxkaXY+PGRpdiBzdHlsZT0ibWFyZ2luOiAwY20g MGNtIDBwdDsgZm9udC1mYW1pbHk6IOWui+S9kzsgZm9udC1zaXplOiAxMnB0OyI+PHNwYW4gbGFu Zz0iRU4tVVMiPk1pbiZuYnNwO0xpdTxicj48YnI+SW5zdGl0dXRlJm5ic3A7b2YmbmJzcDtDb21w dXRpbmcmbmJzcDtUZWNobm9sb2d5PGJyPkNoaW5lc2UmbmJzcDtBY2FkZW15Jm5ic3A7b2YmbmJz cDtTY2llbmNlPG86cD48L286cD48L3NwYW4+PC9kaXY+PC9kaXY+PHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbjogMGNtIDBjbSAxMnB0OyBmb250LWZhbWlseTog5a6L5L2TOyBmb250 LXNpemU6IDEycHQ7Ij48c3BhbiBsYW5nPSJFTi1VUyI+PGJyPiZndDsmbmJzcDstLS0tLS0tLS0t PGJyPiZndDsmbmJzcDtTZW5kZXI6Jm5ic3A7IkFscGVyJm5ic3A7WWVnaW4iJm5ic3A7Jmx0Ozxh IHN0eWxlPSJjb2xvcjogYmx1ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxpbmU7IiBocmVmPSJt YWlsdG86YWxwZXIueWVnaW5AeWVnaW4ub3JnIiB0YXJnZXQ9Il9ibGFuayI+YWxwZXIueWVnaW5A eWVnaW4ub3JnPC9hPiZndDs8YnI+Jmd0OyZuYnNwO1JlY2VpdmVyOiZuYnNwOyJKb3VuaSZuYnNw O0tvcmhvbmVuIiZuYnNwOyZsdDs8YSBzdHlsZT0iY29sb3I6IGJsdWU7IHRleHQtZGVjb3JhdGlv bjogdW5kZXJsaW5lOyIgaHJlZj0ibWFpbHRvOmpvdW5pLm5vc3BhbUBnbWFpbC5jb20iIHRhcmdl dD0iX2JsYW5rIj5qb3VuaS5ub3NwYW1AZ21haWwuY29tPC9hPiZndDs8YnI+Jmd0OyZuYnNwO0Nv cHk6Jm5ic3A7IjxhIHN0eWxlPSJjb2xvcjogYmx1ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxp bmU7IiBocmVmPSJtYWlsdG86ZG1tQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZG1tQGlldGYu b3JnPC9hPiImbmJzcDsmbHQ7PGEgc3R5bGU9ImNvbG9yOiBibHVlOyB0ZXh0LWRlY29yYXRpb246 IHVuZGVybGluZTsiIGhyZWY9Im1haWx0bzpkbW1AaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5k bW1AaWV0Zi5vcmc8L2E+Jmd0Ozxicj4mZ3Q7Jm5ic3A7U3ViamVjdDombmJzcDtSZTombmJzcDtb RE1NXSZuYnNwO2NvbW1lbnRzL3F1ZXN0aW9ucyZuYnNwO29mJm5ic3A7ZHJhZnQteWVnaW4tZG1t LWNuZXQtaG9taW5nLTAwPGJyPiZndDsmbmJzcDs8YnI+Jmd0OyZuYnNwOzxicj4mZ3Q7Jm5ic3A7 T24mbmJzcDtKdWwmbmJzcDsyNCwmbmJzcDsyMDEzLCZuYnNwO2F0Jm5ic3A7MTE6NTYmbmJzcDtB TSwmbmJzcDtKb3VuaSZuYnNwO0tvcmhvbmVuJm5ic3A7d3JvdGU6PGJyPiZndDsmbmJzcDs8YnI+ Jmd0OyZuYnNwOyZndDsmbmJzcDtBbHBlciwmbmJzcDthdXRob3JzLDxicj4mZ3Q7Jm5ic3A7Jmd0 OyZuYnNwOzxicj4mZ3Q7Jm5ic3A7Jmd0OyZuYnNwO0luJm5ic3A7U2VjdGlvbiZuYnNwOzMuJm5i c3A7aXMmbmJzcDtzdGF0ZXM6PGJyPiZndDsmbmJzcDsmZ3Q7Jm5ic3A7PGJyPiZndDsmbmJzcDsm Z3Q7Jm5ic3A7Jm5ic3A7IkNIQSZuYnNwO21heSZuYnNwO2JlJm5ic3A7Y28tbG9jYXRlZCZuYnNw O3dpdGgmbmJzcDt0aGUmbmJzcDtDTiwmbmJzcDtvciZuYnNwO2xvY2F0ZWQmbmJzcDtpbiZuYnNw O3RoZSZuYnNwO3NhbWUmbmJzcDtzaXRlJm5ic3A7YXMmbmJzcDt0aGU8YnI+Jmd0OyZuYnNwOyZn dDsmbmJzcDsmbmJzcDsmbmJzcDtDTiwmbmJzcDtvciZuYnNwO2xvY2F0ZWQmbmJzcDtpbiZuYnNw O2FuJm5ic3A7SVNQJm5ic3A7c2VydmluZyZuYnNwO3RoYXQmbmJzcDtzaXRlLiZuYnNwOyZuYnNw O05vdCZuYnNwO2FsbCZuYnNwO0NOcyZuYnNwO21heSZuYnNwO2JlPGJyPiZndDsmbmJzcDsmZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7c2VydmVkJm5ic3A7YnkmbmJzcDthJm5ic3A7Q0hBLiZuYnNwOyZu YnNwO0luJm5ic3A7Y2FzZSZuYnNwO3RoZXJlJm5ic3A7aXMmbmJzcDtubyZuYnNwO0NIQSZuYnNw O3NlcnZpbmcmbmJzcDt0aGUmbmJzcDtDTiwmbmJzcDt0aGUmbmJzcDtNTiZuYnNwO2FuZDxicj4m Z3Q7Jm5ic3A7Jmd0OyZuYnNwOyZuYnNwOyZuYnNwO3RoZSZuYnNwO0NOJm5ic3A7bWF5Jm5ic3A7 Y29tbXVuaWNhdGUmbmJzcDt1c2luZyZuYnNwO3RoZSZuYnNwO0hvQSZuYnNwO3ZpYSZuYnNwO3Ro ZSZuYnNwO0hBLiZuYnNwOyZuYnNwO0l0Jm5ic3A7aXMmbmJzcDtleHBlY3RlZCZuYnNwO3RoYXQ8 YnI+Jmd0OyZuYnNwOyZndDsmbmJzcDsmbmJzcDsmbmJzcDtDSEFzJm5ic3A7d291bGQmbmJzcDti ZSZuYnNwO2RlcGxveWVkJm5ic3A7Zm9yJm5ic3A7ZG9taW5hbnQmbmJzcDtjb250ZW50Jm5ic3A7 c2l0ZXMmbmJzcDtvbiZuYnNwO3RoZSZuYnNwO0ludGVybmV0PGJyPiZndDsmbmJzcDsmZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7KGUuZy4sJm5ic3A7WW91VHViZSwmbmJzcDtGYWNlYm9vaywmbmJzcDtO ZXRmbGl4LCZuYnNwO2V0Yy4pIjxicj4mZ3Q7Jm5ic3A7Jmd0OyZuYnNwOzxicj4mZ3Q7Jm5ic3A7 Jmd0OyZuYnNwO1doYXQmbmJzcDt3b3VsZCZuYnNwO2JlJm5ic3A7dGhlJm5ic3A7bW90aXZhdGlv biZuYnNwO29yJm5ic3A7YnVzaW5lc3MmbmJzcDtyZWFzb24mbmJzcDtmb3ImbmJzcDthJm5ic3A7 c2VydmljZS9jb250ZW50PGJyPiZndDsmbmJzcDsmZ3Q7Jm5ic3A7cHJvdmlkZXImbmJzcDt0byZu YnNwO3N0YXJ0Jm5ic3A7b2ZmZXJpbmcmbmJzcDthJm5ic3A7bW9iaWxpdHkmbmJzcDthbmNob3Jp bmcmbmJzcDtzZXJ2aWNlPyZuYnNwO0hpZ2gmbmJzcDtiYW5kd2lkdGg8YnI+Jmd0OyZuYnNwOyZn dDsmbmJzcDtzaXRlcyZuYnNwO2FzJm5ic3A7bGlzdGVkJm5ic3A7YWJvdmUmbmJzcDt3b3VsZCZu YnNwO25lZWQmbmJzcDtpbnZlc3QmbmJzcDtxdWl0ZSZuYnNwO211Y2gmbmJzcDtmb3ImbmJzcDtz dWNoJm5ic3A7YSZuYnNwO3BsYXRmb3JtLjxicj4mZ3Q7Jm5ic3A7Jmd0OyZuYnNwOzxicj4mZ3Q7 Jm5ic3A7PGJyPiZndDsmbmJzcDtIZXJlJ3MmbmJzcDtvdXImbmJzcDt0aGlua2luZzo8YnI+Jmd0 OyZuYnNwOzxicj4mZ3Q7Jm5ic3A7LSZuYnNwO1RoZSZuYnNwO2RpcmVjdCZuYnNwO2JlbmVmaXQm bmJzcDtvZiZuYnNwO3RoaXMmbmJzcDthcHByb2FjaCZuYnNwO3RvJm5ic3A7dGhlJm5ic3A7Y29u dGVudCZuYnNwO3Byb3ZpZGVyJm5ic3A7aXMmbmJzcDt0aGUmbmJzcDtyZWR1Y3Rpb24mbmJzcDtv ZiZuYnNwO3RyYW5zbWlzc2lvbiZuYnNwO2xhdGVuY3kmbmJzcDtkdWUmbmJzcDt0byZuYnNwO2Vs aW1pbmF0aW9uJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDt0cmlhbmd1bGFyJm5ic3A7cm91dGVzLiZu YnNwO1RoaXMmbmJzcDt3b3VsZCZuYnNwO2VuaGFuY2UmbmJzcDt0aGUmbmJzcDt0aGVpciZuYnNw O3VzZXImbmJzcDtleHBlcmllbmNlLjxicj4mZ3Q7Jm5ic3A7PGJyPiZndDsmbmJzcDstJm5ic3A7 Q29uc2lkZXJpbmcmbmJzcDt0aGUmbmJzcDtvdmVyYWxsJm5ic3A7c3lzdGVtJm5ic3A7KHcvbyZu YnNwO2Rpc3Rpbmd1aXNoaW5nJm5ic3A7YmV0d2VlbiZuYnNwO3RoZSZuYnNwO01OTyZuYnNwO2Fu ZCZuYnNwO3RoZSZuYnNwO2NvbnRlbnQmbmJzcDtwcm92aWRlciksJm5ic3A7cHJvdmlkaW5nJm5i c3A7YW5jaG9yaW5nL21vYmlsaXR5Jm5ic3A7bmVhciZuYnNwO3RoZSZuYnNwO0NOZXQmbmJzcDth cyZuYnNwO29wcG9zZWQmbmJzcDt0byZuYnNwO2RvaW5nJm5ic3A7aXQmbmJzcDthdCZuYnNwO2Em bmJzcDtjb3JuZXImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO0ludGVybmV0Jm5ic3A7cmVkdWNlcyZu YnNwO3RoZSZuYnNwO292ZXJhbGwmbmJzcDtjb3N0LiZuYnNwO0dpdmVuJm5ic3A7dGhlJm5ic3A7 c2F2aW5ncywmbmJzcDt0aGUmbmJzcDtpbnZvbHZlZCZuYnNwO3BhcnRpZXMmbmJzcDtjYW4mbmJz cDtmaW5kJm5ic3A7YSZuYnNwO2ZhaXImbmJzcDt3YXkmbmJzcDt0byZuYnNwO2RlYWwmbmJzcDt3 aXRoJm5ic3A7aXQmbmJzcDsoaS5lLiwmbmJzcDtzb21lJm5ic3A7YnVzaW5lc3MmbmJzcDtkZWFs KS48YnI+Jmd0OyZuYnNwOzxicj4mZ3Q7Jm5ic3A7T24mbmJzcDt0b3AmbmJzcDtvZiZuYnNwO3Ro YXQsJm5ic3A7dGhpcyZuYnNwO2NhbiZuYnNwO2JlJm5ic3A7cHJvdmlkZWQmbmJzcDtieSZuYnNw O0lTUHMmbmJzcDtzZXJ2aW5nJm5ic3A7dGhlJm5ic3A7Y29udGVudCZuYnNwO3NpdGVzLiZuYnNw O1N1Y2gmbmJzcDtJU1BzJm5ic3A7Y2FuJm5ic3A7YWxzbyZuYnNwO2hhdmUmbmJzcDthJm5ic3A7 YnVzaW5lc3MmbmJzcDtkZWFsJm5ic3A7d2l0aCZuYnNwO3RoZSZuYnNwO01OTyZuYnNwO2ZvciZu YnNwO3Rha2luZyZuYnNwO292ZXImbmJzcDt0aGUmbmJzcDttb2JpbGl0eSZuYnNwO21hbmFnZW1l bnQmbmJzcDtsb2FkLjxicj4mZ3Q7Jm5ic3A7PGJyPiZndDsmbmJzcDs8YnI+Jmd0OyZuYnNwOyZn dDsmbmJzcDtJJm5ic3A7YWxzbyZuYnNwO3N0YXJ0ZWQmbmJzcDt0aGlua2luZyZuYnNwO3RoYXQm bmJzcDtpbiZuYnNwO2dlbmVyYWwmbmJzcDt0aGlzJm5ic3A7c29sdXRpb24mbmJzcDsoYW5kJm5i c3A7cXVpdGUmbmJzcDttYW55PGJyPiZndDsmbmJzcDsmZ3Q7Jm5ic3A7b3RoZXIpJm5ic3A7c2Vl bSZuYnNwO3RvJm5ic3A7YXNzdW1lJm5ic3A7dGhlJm5ic3A7Q04mbmJzcDtpcyZuYnNwO21vcmUm bmJzcDtvciZuYnNwO2xlc3MmbmJzcDtzdGF0aW9uYXJ5LiZuYnNwO0hvdyZuYnNwO3dvdWxkJm5i c3A7dGhlPGJyPiZndDsmbmJzcDsmZ3Q7Jm5ic3A7Q0hBJm5ic3A7Y29uY2VwdCZuYnNwO2JlJm5i c3A7YWZmZWN0ZWQmbmJzcDtpZiZuYnNwO3RoZSZuYnNwO0NOJm5ic3A7aXMmbmJzcDthbHNvJm5i c3A7bW9iaWxlPyZuYnNwO1dvdWxkJm5ic3A7aXQmbmJzcDthbGxvdyZuYnNwO2FueTxicj4mZ3Q7 Jm5ic3A7Jmd0OyZuYnNwO2JlbmVmaXRzJm5ic3A7b3ZlciZuYnNwO3RoZSZuYnNwO2xlZ2FjeSZu YnNwO01JUCZuYnNwO3ZhcmlhbnRzPyZuYnNwO0hvdyZuYnNwO3dvdWxkJm5ic3A7dGhlJm5ic3A7 Q0hBJm5ic3A7ZGlzY292ZXJ5Jm5ic3A7PGJyPiZndDsmbmJzcDsmZ3Q7Jm5ic3A7d29yayZuYnNw O2luJm5ic3A7dGhpcyZuYnNwO2Nhc2U/PGJyPiZndDsmbmJzcDsmZ3Q7Jm5ic3A7PGJyPiZndDsm bmJzcDs8YnI+Jmd0OyZuYnNwO1dlJm5ic3A7ZGlkbid0Jm5ic3A7Y29uc2lkZXImbmJzcDttb2Jp bGUmbmJzcDtDTnMuJm5ic3A7V2UmbmJzcDthcmUmbmJzcDtnb2luZyZuYnNwO2FmdGVyJm5ic3A7 dGhlJm5ic3A7bWFqb3ImbmJzcDtzb3VyY2VzJm5ic3A7b2YmbmJzcDttb2JpbGUmbmJzcDt0cmFm ZmljLCZuYnNwO3doaWNoJm5ic3A7aXMmbmJzcDtzdGVtbWluZyZuYnNwO2Zyb20mbmJzcDtmaXhl ZCZuYnNwO3NpdGVzLjxicj4mZ3Q7Jm5ic3A7PGJyPiZndDsmbmJzcDs8YnI+Jmd0OyZuYnNwOyZn dDsmbmJzcDtUaGUmbmJzcDtleGFtcGxlcyZuYnNwO2luJm5ic3A7U2VjdGlvbnMmbmJzcDszLiZu YnNwO2FuZCZuYnNwOzQuJm5ic3A7c2hvdyZuYnNwO0ROUyZuYnNwO2FzJm5ic3A7dGhlJm5ic3A7 ZGlzY292ZXJ5Jm5ic3A7bWVjaGFuaXNtPGJyPiZndDsmbmJzcDsmZ3Q7Jm5ic3A7Zm9yJm5ic3A7 dGhlJm5ic3A7Q0hBLiZuYnNwO0hvd2V2ZXIsJm5ic3A7dGhlcmUmbmJzcDtpcyZuYnNwO25vJm5i c3A7cmVhbCZuYnNwO2Rlc2NyaXB0aW9uJm5ic3A7aG93Jm5ic3A7dGhlJm5ic3A7ZGlzY292ZXJ5 PGJyPiZndDsmbmJzcDsmZ3Q7Jm5ic3A7aXMmbmJzcDthY3R1YWxseSZuYnNwO2NhcnJpZWQmbmJz cDtvdXQmbmJzcDsoZXhjZXB0Jm5ic3A7Y29uY2VwdHVhbCZuYnNwO0NIQSZuYnNwO2RvbWFpbiZu YnNwO25hbWUmbmJzcDtyZWZlcnJlZDxicj4mZ3Q7Jm5ic3A7Jmd0OyZuYnNwO2luJm5ic3A7U2Vj dGlvbiZuYnNwOzMuPGJyPiZndDsmbmJzcDs8YnI+Jmd0OyZuYnNwO0l0J3MmbmJzcDtqdXN0Jm5i c3A7YSZuYnNwO21hdHRlciZuYnNwO29mJm5ic3A7c3RvcmluZyZuYnNwO2NoYS4mbHQ7eW91cmRv bWFpbiZndDsmbmJzcDtpbiZuYnNwO0ROUyZuYnNwO2FuZCZuYnNwO2xvb2tpbmcmbmJzcDtpdCZu YnNwO3VwLjxicj4mZ3Q7Jm5ic3A7V2UmbmJzcDtjYW4mbmJzcDthZGQmbmJzcDtzb21lJm5ic3A7 bW9yZSZuYnNwO3ZlcmJpYWdlLCZuYnNwO2lmJm5ic3A7dGhpcyZuYnNwO2lzJm5ic3A7bm90Jm5i c3A7Y2xlYXIuPGJyPiZndDsmbmJzcDs8YnI+Jmd0OyZuYnNwOyZndDsmbmJzcDtGaWd1cmUmbmJz cDsxJm5ic3A7c3RlcCZuYnNwOzIpLiZuYnNwO0hhdmUmbmJzcDt5b3UmbmJzcDtjb25zaWRlcmVk Jm5ic3A7b3RoZXImbmJzcDtkaXNjb3Zlcnk8YnI+Jmd0OyZuYnNwOyZndDsmbmJzcDttZWNoYW5p c21zJm5ic3A7dGhhbiZuYnNwO0ROUz88YnI+Jmd0OyZuYnNwOyZndDsmbmJzcDs8YnI+Jmd0OyZu YnNwOzxicj4mZ3Q7Jm5ic3A7V2UmbmJzcDtkaWQmbmJzcDtzb21lJm5ic3A7YnV0Jm5ic3A7dGhp cyZuYnNwO29uZSZuYnNwO3NlZW1lZCZuYnNwO3RvJm5ic3A7YmUmbmJzcDt0aGUmbmJzcDttb3N0 Jm5ic3A7c3RyYWlnaHRmb3J3YXJkLiZuYnNwOzxicj4mZ3Q7Jm5ic3A7QW55Jm5ic3A7c3BlY2lm aWMmbmJzcDtyZWNvbW1lbmRhdGlvbnM/PGJyPiZndDsmbmJzcDs8YnI+Jmd0OyZuYnNwO0FscGVy PGJyPiZndDsmbmJzcDs8YnI+Jmd0OyZuYnNwOzxicj4mZ3Q7Jm5ic3A7PGJyPiZndDsmbmJzcDs8 YnI+Jmd0OyZuYnNwOyZndDsmbmJzcDstJm5ic3A7Sm91bmk8YnI+Jmd0OyZuYnNwOyZndDsmbmJz cDs8YnI+Jmd0OyZuYnNwOyZndDsmbmJzcDs8YnI+Jmd0OyZuYnNwOyZndDsmbmJzcDs8YnI+Jmd0 OyZuYnNwOyZndDsmbmJzcDs8YnI+Jmd0OyZuYnNwOyZndDsmbmJzcDs8YnI+Jmd0OyZuYnNwOzxi cj4mZ3Q7Jm5ic3A7X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+Jmd0OyZuYnNwO2RtbSZuYnNwO21haWxpbmcmbmJzcDtsaXN0PGJyPiZndDsmbmJzcDs8 YSBzdHlsZT0iY29sb3I6IGJsdWU7IHRleHQtZGVjb3JhdGlvbjogdW5kZXJsaW5lOyIgaHJlZj0i bWFpbHRvOmRtbUBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmRtbUBpZXRmLm9yZzwvYT48YnI+ Jmd0OyZuYnNwOzxhIHN0eWxlPSJjb2xvcjogYmx1ZTsgdGV4dC1kZWNvcmF0aW9uOiB1bmRlcmxp bmU7IiBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2RtbSIgdGFy Z2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tPC9h Pjxicj48YnI+PGJyPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibWFyZ2luOiAwY20gMGNtIDBwdDsgZm9udC1mYW1pbHk6IOWui+S9kzsgZm9u dC1zaXplOiAxMnB0OyI+PHNwYW4gbGFuZz0iRU4tVVMiPjwvc3Bhbj48L3A+PC9kaXY+PC9kaXY+ PC9kaXY+PC9ibG9ja3F1b3RlPjwvZGl2Pjxicj48L2Rpdj48L2Jsb2NrcXVvdGU+PGJyPjxzcGFu Pjwvc3Bhbj48YnI+PGJyPjxicj4= ------=_Part_34110_27480896.1374869388131-- From bpatil1@gmail.com Fri Jul 26 14:06:17 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF66B11E815B for ; Fri, 26 Jul 2013 14:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.442 X-Spam-Level: X-Spam-Status: No, score=-2.442 tagged_above=-999 required=5 tests=[AWL=-0.158, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001, SARE_MILLIONSOF=0.315] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eKy7V-+C+XjB for ; Fri, 26 Jul 2013 14:06:17 -0700 (PDT) Received: from mail-ob0-x22d.google.com (mail-ob0-x22d.google.com [IPv6:2607:f8b0:4003:c01::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0BC11E8150 for ; Fri, 26 Jul 2013 14:06:16 -0700 (PDT) Received: by mail-ob0-f173.google.com with SMTP id er7so5289915obc.18 for ; Fri, 26 Jul 2013 14:06:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=T0Yy+0egbg3e/euW2XN4s2Ori1bAkmctU1UuGsRrzxE=; b=pdyQ42QsQvNp5Txlcmw0SqmfyNuQjWpxKRRSszoQkghwAg9efVrZvEkLEbG/K9AvYm N7qDsX1meXP9joZ9C0DGLF53+NuY4DMr0iCgFb/KKB46Kvi7LXVCnZOnqbIpmeQ2UfJc LHzTOu4ut/1uQ84wWC83ZZBv2hCVYH1CH2OsJjrm3wLQfh3i0tI4MdPCrzPBIHsob/r8 JJEzVUXGgrXOUR8oFc32QNRM1psHFrPgfK+KzYXYpSThCO4JUIxIaVT4Rla7XTU4PVbj ZQvcoZ6wQvSjALgZ70Opsk9/30S5DiXxB1iap9FcY+ez6RpYKfD5bHzfzVRBiuarw9WB 9tuQ== MIME-Version: 1.0 X-Received: by 10.182.130.228 with SMTP id oh4mr44321740obb.38.1374872775553; Fri, 26 Jul 2013 14:06:15 -0700 (PDT) Received: by 10.182.111.138 with HTTP; Fri, 26 Jul 2013 14:06:15 -0700 (PDT) Date: Fri, 26 Jul 2013 16:06:15 -0500 Message-ID: From: Basavaraj Patil To: dmm@ietf.org Content-Type: multipart/alternative; boundary=089e0115ed2665f62c04e27083a4 X-Mailman-Approved-At: Sat, 27 Jul 2013 01:09:37 -0700 Cc: draft-matsushima-stateless-uplane-vepc@tools.ietf.org Subject: [DMM] Comments on I-D: draft-matsushima-stateless-uplane-vepc X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jul 2013 21:06:17 -0000 --089e0115ed2665f62c04e27083a4 Content-Type: text/plain; charset=ISO-8859-1 Hi Ryuji, Good to see a new approach to mobility for the evolved packet core architecture. At the very high level it is using standard mobility signaling but then enabling seamless mobility (with session continuity etc.) without the need for tunnelling the user plane. Comments: - The benefits of moving the mobility functions (MME/SGW/PGW) to the cloud are very valid. Operators have a much greater degree of flexibility in terms of capacity and can add or shrink depending on the requirements and this allow for deployments that scale with growth of subscribers, traffic etc. It also allows operators to be decoupled from specific vendors of the mobility applicances (but instead will have to rely on vEPC providers). - I wonder if there are any examples or research papers showing the implementation of EPC functions such as MME, S/PGW on a hypervisor. - It is crtitical that the functions deployed in the NFV are interoperable and hence the need to have specifications. - The intent of using BGP for routing user plane traffic is interesting. How about the scalability aspect? Have you done any studies on this given that an EPC could be serving many millions of nodes. - What about the handover performance? Since the EPC-E router needs to be updated with the new address, does that affect HO performance for real-time applications? - Backward compatibility will be essential in order to allow for operators to deploy a new architecture like the vEPC while allowing the ability to interwork or roam in networks that do not have the same capability. The proposal looks promising and worth working on in the IETF. -Raj -- Basavaraj Patil --089e0115ed2665f62c04e27083a4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

Hi Ryuji,

Goo= d to see a new approach to mobility for the evolved packet core
a= rchitecture. At the very high level it is using standard mobility
signaling but then enabling seamless mobility (with session continuity
etc.) without the need for tunnelling the user plane. =A0
<= br>
Comments:

- The benefits of moving t= he mobility functions (MME/SGW/PGW) to the
=A0 cloud are very valid. Operators have a much greater degree of
=A0 flexibility in terms of capacity and can add or shrink depending = on
=A0 the requirements and this allow for deployments that scale= with
=A0 growth of subscribers, traffic etc. It also allows operators to be=
=A0 decoupled from specific vendors of the mobility applicances = (but
=A0 instead will have to rely on vEPC providers).
=
- I wonder if there are any examples or research papers showing = the
=A0 implementation of EPC functions such as MME, S/PGW on a h= ypervisor.

- It is crtitical that the functions de= ployed in the NFV are
=A0 interoperable and hence the need to have specifications.

- The intent of using BGP for routing user plane traffic is=
=A0 interesting. How about the scalability aspect? Have you done= any
=A0 studies on this given that an EPC could be serving many millions o= f
=A0 nodes.

- What about the handover p= erformance? Since the EPC-E router needs to
=A0 be updated with t= he new address, does that affect HO performance for
=A0 real-time applications?

- Backward compat= ibility will be essential in order to allow for
=A0 operators to = deploy a new architecture like the vEPC while allowing
=A0 the ab= ility to interwork or roam in networks that do not have the
=A0 same capability.=A0

The proposal looks pr= omising and worth working on in the IETF.

-Raj

--
Basavaraj Patil
--089e0115ed2665f62c04e27083a4-- From jouni.nospam@gmail.com Mon Jul 29 01:44:33 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71F6F21F9F6C for ; Mon, 29 Jul 2013 01:44:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bBECdls2PSUK for ; Mon, 29 Jul 2013 01:44:33 -0700 (PDT) Received: from mail-pb0-x229.google.com (mail-pb0-x229.google.com [IPv6:2607:f8b0:400e:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 6114221F963F for ; Mon, 29 Jul 2013 01:44:24 -0700 (PDT) Received: by mail-pb0-f41.google.com with SMTP id rp16so4400497pbb.14 for ; Mon, 29 Jul 2013 01:44:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:x-priority:subject:date :to:message-id:mime-version:x-mailer; bh=1k0sG/qS3ZSU/wDLuNhgROOHsKgLeN15p821wosEmOI=; b=cvefEKsj6enimYpRkkt1IkPFHy97Q8OIDelgzmMOEgEzFQN26Vu2rtOxRU/fJQWOrW l+5O7tk2b6WQgMYxqoN2ihLPgm09jHtBt4wogDU9Eok0UTAzEooxz23+p3uCE1LNmnbm lvRdZ+LSh6cFoUlu1OHRZKtwxQ2TcpkoVXLz8VGBYsv8hGp3VnuGxpAiJYibhzJkO6hh NwAChkwymOjpKZGiRks+Mv1wFg2XKLuOuPI4i+Zb7jJiWJmfqTm7vZosOpApWd+7U1Me uMNQEywt9E1AR657WgQBYfihag+73kbGLAuUHtbINzVUfd7paCZu5ai6TgHUypFDWRTr W/WA== X-Received: by 10.68.29.2 with SMTP id f2mr66601518pbh.184.1375087452567; Mon, 29 Jul 2013 01:44:12 -0700 (PDT) Received: from dhcp-54af.meeting.ietf.org (dhcp-54af.meeting.ietf.org. [130.129.84.175]) by mx.google.com with ESMTPSA id yj2sm75621679pbb.40.2013.07.29.01.44.10 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 29 Jul 2013 01:44:11 -0700 (PDT) From: Jouni Korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Priority: 1 Date: Mon, 29 Jul 2013 11:44:06 +0300 To: "dmm@ietf.org" Message-Id: <727635FC-81F2-4A4E-9FF3-5DA3E08FC999@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) X-Mailer: Apple Mail (2.1508) Subject: [DMM] IETF87 meeting logistics X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 08:44:33 -0000 Folks, Two things: 1) If you feel an urge to take meeting notes or do the jabber scribe, feel free to contact the chairs. 2) Those who are on the agenda, please send your slides to the chairs by Wednesday 11:30 AM (start of lunch break). - Jouni & Julien From cjbc@it.uc3m.es Mon Jul 29 03:55:31 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85B7A21F9D75; Mon, 29 Jul 2013 03:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXzQFZ8YaCLk; Mon, 29 Jul 2013 03:55:25 -0700 (PDT) Received: from smtp02.uc3m.es (smtp02.uc3m.es [163.117.176.132]) by ietfa.amsl.com (Postfix) with ESMTP id B5DC721F9D11; Mon, 29 Jul 2013 03:55:25 -0700 (PDT) Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id DC73E854DE5; Mon, 29 Jul 2013 12:55:23 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [130.129.85.5] (dhcp-5505.meeting.ietf.org [130.129.85.5]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp02.uc3m.es) by smtp02.uc3m.es (Postfix) with ESMTPSA id 6FCC0778A6A; Mon, 29 Jul 2013 12:55:22 +0200 (CEST) Message-ID: <1375095320.4497.3.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: dmm@ietf.org, netext@ietf.org, int-area@ietf.org Date: Mon, 29 Jul 2013 12:55:20 +0200 Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4-3 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-20044.006 X-TM-AS-Result: No--12.033-7.0-31-1 X-imss-scan-details: No--12.033-7.0-31-1 Subject: [DMM] Network-based DMM demo at IETF 87 (Tue 17:00 "Check" room) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 10:55:31 -0000 Dear all, (Apologies for the cross-posting). We will show a network-based DMM Linux implementation demo tomorrow (Tuesday, 30th July) at 17h, in "Check" room (2nd floor). The demo will showcase a particular use-case as an example of the advantages provided by DMM: Content Distribution Networking (CDN) and Distributed Mobility Management (DMM). The setup is composed of three "anchor routers", a "centralized LMA" for control plane, CDN cache nodes co-located with the anchor routers, some correspondent nodes (including a video server) and a legacy IPv6 mobile node. The implementation is based on the following two drafts: [1] http://tools.ietf.org/html/draft-bernardos-dmm-pmip [2] http://tools.ietf.org/html/draft-bernardos-dmm-distributed-anchoring The demo will take about 20 to 30 minutes. Looking forward to seeing you there and getting your feedback. Thanks, Carlos et al. From h.anthony.chan@huawei.com Mon Jul 29 05:35:02 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADF8621F9425 for ; Mon, 29 Jul 2013 05:34:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cXLzBHuncdIJ for ; Mon, 29 Jul 2013 05:34:42 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 84C4C21F9929 for ; Mon, 29 Jul 2013 05:34:05 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATW91710; Mon, 29 Jul 2013 12:33:59 +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.1.323.7; Mon, 29 Jul 2013 13:33:45 +0100 Received: from SZXEML405-HUB.china.huawei.com (10.82.67.60) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 29 Jul 2013 13:33:49 +0100 Received: from szxeml557-mbx.china.huawei.com ([169.254.5.42]) by szxeml405-hub.china.huawei.com ([::1]) with mapi id 14.01.0323.007; Mon, 29 Jul 2013 20:33:43 +0800 From: h chan To: Seil Jeon , "'Jouni Korhonen'" Thread-Topic: [DMM] requirements and the security considerations Thread-Index: AQIMqymg6+OjSDxRFUaXhLYdLk/TugIblnyHmLK9+rCAO74wUA== Date: Mon, 29 Jul 2013 12:33:42 +0000 Message-ID: <6E31144C030982429702B11D6746B98C37095079@szxeml557-mbx.china.huawei.com> References: <6E31144C030982429702B11D6746B98C370928A2@szxeml557-mbx.china.huawei.com> <000301ce6e7c$063bb760$12b32620$@av.it.pt> In-Reply-To: <000301ce6e7c$063bb760$12b32620$@av.it.pt> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.136.208] Content-Type: multipart/alternative; boundary="_000_6E31144C030982429702B11D6746B98C37095079szxeml557mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dmm@ietf.org" Subject: Re: [DMM] requirements and the security considerations X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 12:35:03 -0000 --_000_6E31144C030982429702B11D6746B98C37095079szxeml557mbxchi_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks and version 06 is being updated with this REQ7. H Anthony Chan From: Seil Jeon [mailto:seiljeon@av.it.pt] Sent: Friday, June 21, 2013 2:37 PM To: h chan; 'Jouni Korhonen' Cc: dmm@ietf.org; 'KIM, BYOUNG-JO J (BYOUNG-JO' Subject: RE: [DMM] requirements and the security considerations Hi, Anthony and all, Actually, when it comes to reviewing BJ's comment, it seems touching very f= undamental statement by mentioning the need of IP layer mobility support fo= r multicast session (if needed), though this requirement itself has implici= tly included it. But it's ok to me. @Jouni, we respond to the ticket #22 as well. As you know, we have tried to identify and discuss the meaning of flexible = distribution in the list. If we unfold the meaning hidden in the abstract w= ords, it would be fit to what you said. But the reworded sentences were mos= tly copied from "Motivation" paragraph and arranged. Overall, the Motivatio= n was reworded. By taking into account two comments, the revised text is as follows. REQ7: DMM SHOULD consider multicast early so that solutions can be developed not only to provide IP mobility to keep IP multicast sessions = when it is needed, but to avoid network inefficiency issues in multicast traffic delivery (such as duplicate multicast subscriptions towards the downstream tunnel entitiesy). The multicast solutions should therefore avoid restricting the management of all IP multicast traffic to a single host through a dedicated (tunnel) interface on multicast-capable access routers. Motivation: Existing multicast deployment have been introduced after comple= ting the design of the reference mobility protocol, then optimization and e= xtensions have been followed, by "patching-up" procedure, thus leading to n= etwork inefficiency and non-optimal routing. The multicast solutions should= therefore be required to consider efficiency nature in multicast traffic d= elivery. p.s. @Jouni, I remember #33 ticket was resolved by answering Charlie's comm= ent. Check it, please. Regards, Seil -----Original Message----- From: dmm-bounces@ietf.org [mailto:dmm-bounces= @ietf.org] On Behalf Of h chan Sent: Friday, June 21, 2013 1:26 AM To: Jouni Korhonen; dmm@ietf.org; KIM, BYOUNG-JO J (BY= OUNG-JO Cc: Jong-Hyouk Lee Subject: Re: [DMM] requirements and the security considerations Seil or Sergio, Can you reply to the following: The comments from Byoung-Jo Kim to REQ7 in version 4 is as follows: I suggest to drop this requirement or make a clearer statement like "DMM sh= ould allow multicast to survive IP layer mobility without packet loss", or = more modestly, "DMM should not foreclose multicast support during IP layer = mobility.", etc.. His suggested text is to replace REQ7 with something like the following: REQ7: DMM SHOULD enable multicast packet delivery during mobility event= s as needed. H Anthony Chan -----Original Message----- From: h chan Sent: Thursday, June 20, 2013 7:15 PM To: 'Jouni Korhonen'; dmm@ietf.org; 'KIM, BYOUNG-JO J = (BYOUNG-JO' Cc: 'Jong-Hyouk Lee' Subject: RE: [DMM] requirements and the security considerations The comments from Byoung-Jo Kim to REQ6 and Section 6 in version 4 were the= following: There are too much text in the security REQ6 that are vague and too wide. And Section 6. Security considerations should say "none", 'cause that's usu= ally the section that discusses security considerations related to the draf= t itself. Since this is a requirement draft, there is no such thing. There is a separate requirement earlier to cover security issues due to DMM= . REQ6: Security considerations DMM protocol solutions MUST consider security risks introduced by DMM into the network. Examples of such risks to be considered may include authentication and authorization mechanism= s that allow a mobile host/router to use the mobility support provided by the DMM solution; redirecting traffic to the wrong host when providing DMM support; signaling message protection for authentication, integrity and confidentiality. Motivation: Various attacks such as impersonation, denial of service, man-in-the-middle attacks, and so on, may become newly possible or easier to mount due to the introduction of DMM. Proo= f of possession of past and new IP addresses may be needed. H Anthony Chan -----Original Message----- From: dmm-bounces@ietf.org [mailto:dmm-bounces= @ietf.org] On Behalf Of Jouni Korhonen Sent: Tuesday, June 18, 2013 2:40 AM To: dmm@ietf.org Subject: [DMM] requirements and the security considerations Folks, I have been reading Section 6 Security Considerations: It is necessary to provide sufficient defense against possible security attacks, or to adopt existing security mechanisms and protocols to provide sufficient security protections. For instance, EAP-based authentication can be used for access network security, while IPsec can be used for end-to-end security. I think this text still deserves some tweaking. First, "provide sufficient = defense against possible security attacks".. against whom? Second, should the text say something that the DMM protocol itself must not= be usable as a tool to launch an attack by a malicious mobile node that ha= ppens to know that it is attached to a network implementing DMM and knows (= somehow) how the DMM protocol functions? - 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 --_000_6E31144C030982429702B11D6746B98C37095079szxeml557mbxchi_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks and version 06 = is being updated with this REQ7.  

 

H Anthony Chan

 

From: Seil Jeo= n [mailto:seiljeon@av.it.pt]
Sent: Friday, June 21, 2013 2:37 PM
To: h chan; 'Jouni Korhonen'
Cc: dmm@ietf.org; 'KIM, BYOUNG-JO J (BYOUNG-JO'
Subject: RE: [DMM] requirements and the security considerations=

 

Hi, Anthony and all,

 

Actually, when it comes to reviewing BJ's comment= , it seems touching very fundamental statement by mentioning the need of IP= layer mobility support for multicast session (if needed), though this requ= irement itself has implicitly included it. But it's ok to me.

 

@Jouni, we respond to the ticket #22 as well.

As you know, we have tried to identify and discus= s the meaning of flexible distribution in the list. If we unfold the meanin= g hidden in the abstract words, it would be fit to what you said. But the r= eworded sentences were mostly copied from “Motivation” paragraph and arranged. Overall, the Motivat= ion was reworded.

 

By taking into account two comments, the revised = text is as follows.

 

REQ7: DMM = SHOULD consider multicast early so that solutions can

be develop= ed not only to provide IP mobility to ke= ep IP multicast sessions when it is needed, but to avoid network inefficiency issues in multicast
traffic delivery (such as duplicate multicast subscriptions
towards the downstream tunnel entitiesy). The multica= st solutions
should therefore avoid restricting the management of all IP
multicast traffic to a single host through a dedicated
(tunnel) interface on multicast-capable access routers.

Motivation= : Existing multicast deployment have been introduced after completing the d= esign of the reference mobility protocol, then optimization and extensions = have been followed, by “patching-up” procedure, thus leading to network inefficiency and non-optimal routing. T= he multicast solutions should therefore be required to consider efficiency = nature in multicast traffic delivery.

 

p.s. @Jouni, I remember #33 ticket was resolved b= y answering Charlie’s comment. Check it, please.

 

 

Regards,

Seil

 

 

-----Original Message-----
From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Be= half Of h chan
Sent: Friday, June 21, 2013 1:26 AM
To: Jouni Korhonen; dmm@ietf.org; KIM, = BYOUNG-JO J (BYOUNG-JO
Cc: Jong-Hyouk Lee
Subject: Re: [DMM] requirements and the security considerations<= /p>

 

Seil or Sergio,

Can you reply to the following:

 

The comments from Byoung-Jo Kim to REQ7 in versio= n 4 is as follows:

 

I suggest to drop this requirement or make a clea= rer statement like "DMM should allow multicast to survive IP layer mob= ility without packet loss", or more modestly, "DMM should not for= eclose multicast support during IP layer mobility.", etc..

 

 

His suggested text is to replace REQ7 with someth= ing like the following:

 

   REQ7:  DMM SHOULD enable multic= ast packet delivery during mobility events as needed.

 

H Anthony Chan

 

 

-----Original Message-----

From: h chan

Sent: Thursday, June 20, 2013 7:15 PM<= /p>

To: 'Jouni Korhonen'; dmm@ietf.org; 'KIM, BYOUNG-JO J (BYOUNG-JO'

Cc: 'Jong-Hyouk Lee'

Subject: RE: [DMM] requirements and the security = considerations

 

The comments from Byoung-Jo Kim to REQ6 and Secti= on 6 in version 4 were the following:

There are too much text in the security REQ6 that= are vague and too wide.

 

And Section 6. Security considerations should say= "none", 'cause that's usually the section that discusses securit= y considerations related to the draft itself. Since this is a requirement d= raft, there is no such thing.

There is a separate requirement earlier to cover = security issues due to DMM.

 

REQ6:  Security considerations

 

        &= nbsp; DMM protocol solutions MUST consider security risks introduced

        &= nbsp; by DMM into the network.  Examples of such risks to be

        &= nbsp; considered may include authentication and authorization mechanisms

        &= nbsp; that allow a mobile host/router to use the mobility

        &= nbsp; support provided by the DMM solution; redirecting traffic to

        &= nbsp; the wrong host when providing DMM support; signaling message

        &= nbsp; protection for authentication, integrity and confidentiality.

 

        &= nbsp; Motivation: Various attacks such as impersonation, denial of

        &= nbsp; service, man-in-the-middle attacks, and so on, may become newly

        &= nbsp; possible or easier to mount due to the introduction of DMM. = ; Proof

        &= nbsp; of possession of past and new IP addresses may be needed.<= /p>

 

H Anthony Chan

 

 

-----Original Message-----

From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of Jouni Korhonen

Sent: Tuesday, June 18, 2013 2:40 AM

To: dmm@ietf.org

Subject: [DMM] requirements and the security cons= iderations

 

<no co-chair cap/bowler>

 

Folks,

 

I have been reading Section 6 Security Considerat= ions:

 

   It is necessary to provide sufficien= t defense against possible

   security attacks, or to adopt existi= ng security mechanisms and

   protocols to provide sufficient secu= rity protections.  For instance,

   EAP-based authentication can be used= for access network security,

   while IPsec can be used for end-to-e= nd security.

 

I think this text still deserves some tweaking. F= irst, "provide sufficient defense against possible security attacks&qu= ot;.. against whom?

 

Second, should the text say something that the DM= M protocol itself must not be usable as a tool to launch an attack by a mal= icious mobile node that happens to know that it is attached to a network im= plementing DMM and knows (somehow) how the DMM protocol functions?

 

- 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

--_000_6E31144C030982429702B11D6746B98C37095079szxeml557mbxchi_-- From h.anthony.chan@huawei.com Mon Jul 29 05:40:57 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5008221F942D for ; Mon, 29 Jul 2013 05:40:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ifwUFXGraNB0 for ; Mon, 29 Jul 2013 05:40:52 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5A57221F8447 for ; Mon, 29 Jul 2013 05:40:51 -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.5-GA FastPath queued) with ESMTP id AVN42096; Mon, 29 Jul 2013 12:40:50 +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.1.323.7; Mon, 29 Jul 2013 13:40:45 +0100 Received: from SZXEML462-HUB.china.huawei.com (10.82.67.205) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 29 Jul 2013 13:40:49 +0100 Received: from szxeml557-mbx.china.huawei.com ([169.254.5.42]) by szxeml462-hub.china.huawei.com ([10.82.67.205]) with mapi id 14.01.0323.007; Mon, 29 Jul 2013 20:37:34 +0800 From: h chan To: "KIM, BYOUNG-JO J (BYOUNG-JO" , "dmm@ietf.org" Thread-Topic: [DMM] requirements and the security considerations Thread-Index: AQHOb2Pi4vpViBL3DkqAuOix3+bylpl70P0Q Date: Mon, 29 Jul 2013 12:37:34 +0000 Message-ID: <6E31144C030982429702B11D6746B98C37095087@szxeml557-mbx.china.huawei.com> References: <6E31144C030982429702B11D6746B98C370928A2@szxeml557-mbx.china.huawei.com> <000301ce6e7c$063bb760$12b32620$@av.it.pt> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.136.208] Content-Type: multipart/alternative; boundary="_000_6E31144C030982429702B11D6746B98C37095087szxeml557mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [DMM] requirements and the security considerations X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 12:40:57 -0000 --_000_6E31144C030982429702B11D6746B98C37095087szxeml557mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QnlvdW5nLUpvLA0KQXJlIHlvdSBva2F5IHdpdGggdGhlIHJldmlzZWQgdGV4dCBmb3IgUkVRNiBw cm92aWRlZCBieSBKb25nLUh5b3VrPw0KDQpIIEFudGhvbnkgQ2hhbg0KDQpGcm9tOiBKb25nLUh5 b3VrIExlZSBbbWFpbHRvOmpvbmdoeW91a0BnbWFpbC5jb21dDQpTZW50OiBTYXR1cmRheSwgSnVu ZSAyMiwgMjAxMyA2OjE3IFBNDQpUbzogZG1tQGlldGYub3JnOyBoIGNoYW4NCkNjOiBKb3VuaSBL b3Job25lbg0KU3ViamVjdDogUmU6IFtETU1dIHJlcXVpcmVtZW50cyBhbmQgdGhlIHNlY3VyaXR5 IGNvbnNpZGVyYXRpb25zDQoNCkhpIGFsbCwNCg0KSGVyZSBpcyB0ZXh0IGZvciBzZWN1cml0eS4g QXBvbG9naXplIGZvciBiZWluZyBsYXRlLCBBbnRob255Lg0KDQo9PT09PT0NCjUuNi4gIFNlY3Vy aXR5DQoNClJFUTY6IERNTSBNVVNUIGJlIHByb3RlY3RlZCBieSBzZWN1cml0eSBtZWNoYW5pc21z L3Byb3RvY29scyBpbiB0ZXJtcyBvZiBuZXR3b3JrIGFjY2VzcyBzZWN1cml0eSBhbmQgZW5kLXRv LWVuZCBzZWN1cml0eS4gTmV0d29yayBhY2Nlc3Mgc2VjdXJpdHkgaXMgcmVxdWlyZWQgYmV0d2Vl biB0aGUgbW9iaWxlIGhvc3Qvcm91dGVyIGFuZCB0aGUgYWNjZXNzIG5ldHdvcmsgZGVwbG95aW5n IERNTSwgdG8gYWxsb3cgb25seSBhIGxlZ2l0aW1hdGUgbW9iaWxlIGhvc3Qvcm91dGVyIHRvIHVz ZSBETU0uIEVuZC10by1lbmQgc2VjdXJpdHkgaXMgcmVxdWlyZWQgYmV0d2VlbiBub2RlcyB0aGF0 IHBhcnRpY2lwYXRlIGluIERNTSwgdG8gcHJvdGVjdCBETU0gc2lnbmFsaW5nIG1lc3NhZ2VzLiBF eGlzdGluZyBzZWN1cml0eSBtZWNoYW5pc21zL3Byb3RvY29scyBNQVkgYmUgcG9zc2libGUgdG8g cHJvdmlkZSBzdWZmaWNpZW50IHNlY3VyaXR5IHByb3RlY3Rpb25zIHRvIERNTS4gRm9yIGluc3Rh bmNlLCBFQVAtYmFzZWQgYXV0aGVudGljYXRpb24gY2FuIGJlIHVzZWQgZm9yIG5ldHdvcmsgYWNj ZXNzIHNlY3VyaXR5LCB3aGlsZSBJUHNlYyBjYW4gYmUgdXNlZCBmb3IgZW5kLXRvLWVuZCBzZWN1 cml0eS4gTm90ZSB0aGF0IHdoZW4gdGhlIGV4aXN0aW5nIHNlY3VyaXR5IG1lY2hhbmlzbXMvcHJv dG9jb2xzIGFyZSBhcHBsaWVkIHRvIERNTSwgc2VjdXJpdHkgcmlza3MgdGhhdCBNQVkgYmUgaW50 cm9kdWNlZCBieSBETU0gTVVTVCBiZSBjb25zaWRlcmVkIHRvIGJlIGVsaW1pbmF0ZWQuDQoNCkEg c2VjdXJpdHkgbWVjaGFuaXNtL3Byb3RvY29sIHRoYXQgcHJvdmlkZXMgcHJvb2Ygb2YgcG9zc2Vz c2lvbiBvZiBwYXN0IGFuZCBuZXcgSVAgYWRkcmVzc2VzIG9mIGEgbW9iaWxlIGhvc3Qvcm91dGVy IE1BWSBiZSBuZWVkZWQuDQoNCk1vdGl2YXRpb246IFZhcmlvdXMgYXR0YWNrcyBzdWNoIGFzIGlt cGVyc29uYXRpb24sIGRlbmlhbCBvZiBzZXJ2aWNlLCBtYW4taW4tdGhlLW1pZGRsZSBhdHRhY2tz LCBhbmQgc28gb24sIE1BWSBiZSBsYXVuY2hlZCBhZ2FpbnN0IERNTS4gQWNjb3JkaW5nbHksIHNl Y3VyaXR5IG1lY2hhbmlzbXMvcHJvdG9jb2xzIHByb3ZpZGluZyBhY2Nlc3MgY29udHJvbCwgaW50 ZWdyaXR5LCBhdXRoZW50aWNhdGlvbiwgYXV0aG9yaXphdGlvbiwgY29uZmlkZW50aWFsaXR5LCBl dGMuIE1VU1QgYmUgcmVxdWlyZWQgdG8gcHJvdGVjdCBETU0uIEZvciBpbnN0YW5jZSwgYW4gaWxs ZWdpdGltYXRlIG5vZGUgYXR0ZW1wdHMgdG8gYWNjZXNzIGEgbmV0d29yayBwcm92aWRpbmcgRE1N LiBBbm90aGVyIGV4YW1wbGUgaXMgdGhhdCBhIG1hbGljaW91cyBub2RlIGNhbiBmb3JnZSBhIG51 bWJlciBvZiBzaWduYWxpbmcgbWVzc2FnZXMgdGh1cyByZWRpcmVjdGluZyB0cmFmZmljIGZyb20g aXRzIGxlZ2l0aW1hdGUgcGF0aC4gQ29uc2VxdWVudGx5LCB0aGUgc3BlY2lmaWMgbm9kZSBpcyB1 bmRlciBhIGRlbmlhbCBvZiBzZXJ2aWNlIGF0dGFjaywgd2hlcmVhcyBvdGhlciBub2RlcyBkbyBu b3QgcmVjZWl2ZSB0aGVpciB0cmFmZmljLiBBcyBzaWduYWxpbmcgbWVzc2FnZXMgTUFZIHRyYXZl bCBvdmVyIHRoZSBJbnRlcm5ldCwgdGhlIGVuZC10by1lbmQgc2VjdXJpdHkgYmV0d2VlbiBjb21t dW5pY2F0aW5nIG5vZGVzIE1VU1QgYmUgcmVxdWlyZWQuDQoNClRoaXMgcmVxdWlyZW1lbnQgYWRk cmVzc2VzIHRoZSBwcm9ibGVtcyBvZiBwb3RlbnRpYWxseSBpbnNlY3VyZSBtb2JpbGl0eSBtYW5h Z2VtZW50IHByb3RvY29scyB3aGljaCBtYWtlIGRlcGxveW1lbnQgaW5mZWFzaWJsZSBiZWNhdXNl IHBsYXRmb3JtcyBjb25mb3JtaW5nIHRvIHRoZSBwcm90b2NvbHMgYXJlIGF0IHJpc2sgZm9yIGRh dGEgbG9zcyBhbmQgbnVtZXJvdXMgb3RoZXIgZGFuZ2VycywgaW5jbHVkaW5nIGZpbmFuY2lhbCBo YXJtIHRvIHVzZXJzLiAoSSBsZWF2ZSBpdCB0byBiZSBtb2RpZmllZCBvciBpbXByb3ZlZCBieSBB bnRob255KQ0KDQo2LiAgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNCihOb3cgSSBkbyBub3QgdGhp bmsgd2UgbmVlZCB0byBwdXQgdGV4dCBoZXJlKQ0KPT09PT09DQoNCk9uIEZyaSwgSnVuIDIxLCAy MDEzIGF0IDk6MzYgUE0sIFNlaWwgSmVvbiA8c2VpbGplb25AYXYuaXQucHQ8bWFpbHRvOnNlaWxq ZW9uQGF2Lml0LnB0Pj4gd3JvdGU6DQoNCkhpLCBBbnRob255IGFuZCBhbGwsDQoNCg0KDQpBY3R1 YWxseSwgd2hlbiBpdCBjb21lcyB0byByZXZpZXdpbmcgQkoncyBjb21tZW50LCBpdCBzZWVtcyB0 b3VjaGluZyB2ZXJ5IGZ1bmRhbWVudGFsIHN0YXRlbWVudCBieSBtZW50aW9uaW5nIHRoZSBuZWVk IG9mIElQIGxheWVyIG1vYmlsaXR5IHN1cHBvcnQgZm9yIG11bHRpY2FzdCBzZXNzaW9uIChpZiBu ZWVkZWQpLCB0aG91Z2ggdGhpcyByZXF1aXJlbWVudCBpdHNlbGYgaGFzIGltcGxpY2l0bHkgaW5j bHVkZWQgaXQuIEJ1dCBpdCdzIG9rIHRvIG1lLg0KDQoNCg0KQEpvdW5pLCB3ZSByZXNwb25kIHRv IHRoZSB0aWNrZXQgIzIyIGFzIHdlbGwuDQoNCkFzIHlvdSBrbm93LCB3ZSBoYXZlIHRyaWVkIHRv IGlkZW50aWZ5IGFuZCBkaXNjdXNzIHRoZSBtZWFuaW5nIG9mIGZsZXhpYmxlIGRpc3RyaWJ1dGlv biBpbiB0aGUgbGlzdC4gSWYgd2UgdW5mb2xkIHRoZSBtZWFuaW5nIGhpZGRlbiBpbiB0aGUgYWJz dHJhY3Qgd29yZHMsIGl0IHdvdWxkIGJlIGZpdCB0byB3aGF0IHlvdSBzYWlkLiBCdXQgdGhlIHJl d29yZGVkIHNlbnRlbmNlcyB3ZXJlIG1vc3RseSBjb3BpZWQgZnJvbSDigJxNb3RpdmF0aW9u4oCd IHBhcmFncmFwaCBhbmQgYXJyYW5nZWQuIE92ZXJhbGwsIHRoZSBNb3RpdmF0aW9uIHdhcyByZXdv cmRlZC4NCg0KDQoNCkJ5IHRha2luZyBpbnRvIGFjY291bnQgdHdvIGNvbW1lbnRzLCB0aGUgcmV2 aXNlZCB0ZXh0IGlzIGFzIGZvbGxvd3MuDQoNCg0KDQpSRVE3OiBETU0gU0hPVUxEIGNvbnNpZGVy IG11bHRpY2FzdCBlYXJseSBzbyB0aGF0IHNvbHV0aW9ucyBjYW4NCg0KYmUgZGV2ZWxvcGVkIG5v dCBvbmx5IHRvIHByb3ZpZGUgSVAgbW9iaWxpdHkgdG8ga2VlcCBJUCBtdWx0aWNhc3Qgc2Vzc2lv bnMgd2hlbiBpdCBpcyBuZWVkZWQsIGJ1dCB0byBhdm9pZCBuZXR3b3JrIGluZWZmaWNpZW5jeSBp c3N1ZXMgaW4gbXVsdGljYXN0DQp0cmFmZmljIGRlbGl2ZXJ5IChzdWNoIGFzIGR1cGxpY2F0ZSBt dWx0aWNhc3Qgc3Vic2NyaXB0aW9ucw0KdG93YXJkcyB0aGUgZG93bnN0cmVhbSB0dW5uZWwgZW50 aXRpZXN5KS4gVGhlIG11bHRpY2FzdCBzb2x1dGlvbnMNCnNob3VsZCB0aGVyZWZvcmUgYXZvaWQg cmVzdHJpY3RpbmcgdGhlIG1hbmFnZW1lbnQgb2YgYWxsIElQDQptdWx0aWNhc3QgdHJhZmZpYyB0 byBhIHNpbmdsZSBob3N0IHRocm91Z2ggYSBkZWRpY2F0ZWQNCih0dW5uZWwpIGludGVyZmFjZSBv biBtdWx0aWNhc3QtY2FwYWJsZSBhY2Nlc3Mgcm91dGVycy4NCg0KTW90aXZhdGlvbjogRXhpc3Rp bmcgbXVsdGljYXN0IGRlcGxveW1lbnQgaGF2ZSBiZWVuIGludHJvZHVjZWQgYWZ0ZXIgY29tcGxl dGluZyB0aGUgZGVzaWduIG9mIHRoZSByZWZlcmVuY2UgbW9iaWxpdHkgcHJvdG9jb2wsIHRoZW4g b3B0aW1pemF0aW9uIGFuZCBleHRlbnNpb25zIGhhdmUgYmVlbiBmb2xsb3dlZCwgYnkg4oCccGF0 Y2hpbmctdXDigJ0gcHJvY2VkdXJlLCB0aHVzIGxlYWRpbmcgdG8gbmV0d29yayBpbmVmZmljaWVu Y3kgYW5kIG5vbi1vcHRpbWFsIHJvdXRpbmcuIFRoZSBtdWx0aWNhc3Qgc29sdXRpb25zIHNob3Vs ZCB0aGVyZWZvcmUgYmUgcmVxdWlyZWQgdG8gY29uc2lkZXIgZWZmaWNpZW5jeSBuYXR1cmUgaW4g bXVsdGljYXN0IHRyYWZmaWMgZGVsaXZlcnkuDQoNCg0KDQpwLnMuIEBKb3VuaSwgSSByZW1lbWJl ciAjMzMgdGlja2V0IHdhcyByZXNvbHZlZCBieSBhbnN3ZXJpbmcgQ2hhcmxpZeKAmXMgY29tbWVu dC4gQ2hlY2sgaXQsIHBsZWFzZS4NCg0KDQoNCg0KDQpSZWdhcmRzLA0KDQpTZWlsDQoNCg0KDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBkbW0tYm91bmNlc0BpZXRmLm9yZzxt YWlsdG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmc+IFttYWlsdG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmc8 bWFpbHRvOmRtbS1ib3VuY2VzQGlldGYub3JnPl0gT24gQmVoYWxmIE9mIGggY2hhbg0KU2VudDog RnJpZGF5LCBKdW5lIDIxLCAyMDEzIDE6MjYgQU0NClRvOiBKb3VuaSBLb3Job25lbjsgZG1tQGll dGYub3JnPG1haWx0bzpkbW1AaWV0Zi5vcmc+OyBLSU0sIEJZT1VORy1KTyBKIChCWU9VTkctSk8N CkNjOiBKb25nLUh5b3VrIExlZQ0KU3ViamVjdDogUmU6IFtETU1dIHJlcXVpcmVtZW50cyBhbmQg dGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zDQoNCg0KDQpTZWlsIG9yIFNlcmdpbywNCg0KQ2Fu IHlvdSByZXBseSB0byB0aGUgZm9sbG93aW5nOg0KDQoNCg0KVGhlIGNvbW1lbnRzIGZyb20gQnlv dW5nLUpvIEtpbSB0byBSRVE3IGluIHZlcnNpb24gNCBpcyBhcyBmb2xsb3dzOg0KDQoNCg0KSSBz dWdnZXN0IHRvIGRyb3AgdGhpcyByZXF1aXJlbWVudCBvciBtYWtlIGEgY2xlYXJlciBzdGF0ZW1l bnQgbGlrZSAiRE1NIHNob3VsZCBhbGxvdyBtdWx0aWNhc3QgdG8gc3Vydml2ZSBJUCBsYXllciBt b2JpbGl0eSB3aXRob3V0IHBhY2tldCBsb3NzIiwgb3IgbW9yZSBtb2Rlc3RseSwgIkRNTSBzaG91 bGQgbm90IGZvcmVjbG9zZSBtdWx0aWNhc3Qgc3VwcG9ydCBkdXJpbmcgSVAgbGF5ZXIgbW9iaWxp dHkuIiwgZXRjLi4NCg0KDQoNCg0KDQpIaXMgc3VnZ2VzdGVkIHRleHQgaXMgdG8gcmVwbGFjZSBS RVE3IHdpdGggc29tZXRoaW5nIGxpa2UgdGhlIGZvbGxvd2luZzoNCg0KDQoNCiAgIFJFUTc6ICBE TU0gU0hPVUxEIGVuYWJsZSBtdWx0aWNhc3QgcGFja2V0IGRlbGl2ZXJ5IGR1cmluZyBtb2JpbGl0 eSBldmVudHMgYXMgbmVlZGVkLg0KDQoNCg0KSCBBbnRob255IENoYW4NCg0KDQoNCg0KDQotLS0t LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KDQpGcm9tOiBoIGNoYW4NCg0KU2VudDogVGh1cnNkYXks IEp1bmUgMjAsIDIwMTMgNzoxNSBQTQ0KDQpUbzogJ0pvdW5pIEtvcmhvbmVuJzsgZG1tQGlldGYu b3JnPG1haWx0bzpkbW1AaWV0Zi5vcmc+OyAnS0lNLCBCWU9VTkctSk8gSiAoQllPVU5HLUpPJw0K DQpDYzogJ0pvbmctSHlvdWsgTGVlJw0KDQpTdWJqZWN0OiBSRTogW0RNTV0gcmVxdWlyZW1lbnRz IGFuZCB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMNCg0KDQoNClRoZSBjb21tZW50cyBmcm9t IEJ5b3VuZy1KbyBLaW0gdG8gUkVRNiBhbmQgU2VjdGlvbiA2IGluIHZlcnNpb24gNCB3ZXJlIHRo ZSBmb2xsb3dpbmc6DQoNClRoZXJlIGFyZSB0b28gbXVjaCB0ZXh0IGluIHRoZSBzZWN1cml0eSBS RVE2IHRoYXQgYXJlIHZhZ3VlIGFuZCB0b28gd2lkZS4NCg0KDQoNCkFuZCBTZWN0aW9uIDYuIFNl Y3VyaXR5IGNvbnNpZGVyYXRpb25zIHNob3VsZCBzYXkgIm5vbmUiLCAnY2F1c2UgdGhhdCdzIHVz dWFsbHkgdGhlIHNlY3Rpb24gdGhhdCBkaXNjdXNzZXMgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMg cmVsYXRlZCB0byB0aGUgZHJhZnQgaXRzZWxmLiBTaW5jZSB0aGlzIGlzIGEgcmVxdWlyZW1lbnQg ZHJhZnQsIHRoZXJlIGlzIG5vIHN1Y2ggdGhpbmcuDQoNClRoZXJlIGlzIGEgc2VwYXJhdGUgcmVx dWlyZW1lbnQgZWFybGllciB0byBjb3ZlciBzZWN1cml0eSBpc3N1ZXMgZHVlIHRvIERNTS4NCg0K DQoNClJFUTY6ICBTZWN1cml0eSBjb25zaWRlcmF0aW9ucw0KDQoNCg0KICAgICAgICAgIERNTSBw cm90b2NvbCBzb2x1dGlvbnMgTVVTVCBjb25zaWRlciBzZWN1cml0eSByaXNrcyBpbnRyb2R1Y2Vk DQoNCiAgICAgICAgICBieSBETU0gaW50byB0aGUgbmV0d29yay4gIEV4YW1wbGVzIG9mIHN1Y2gg cmlza3MgdG8gYmUNCg0KICAgICAgICAgIGNvbnNpZGVyZWQgbWF5IGluY2x1ZGUgYXV0aGVudGlj YXRpb24gYW5kIGF1dGhvcml6YXRpb24gbWVjaGFuaXNtcw0KDQogICAgICAgICAgdGhhdCBhbGxv dyBhIG1vYmlsZSBob3N0L3JvdXRlciB0byB1c2UgdGhlIG1vYmlsaXR5DQoNCiAgICAgICAgICBz dXBwb3J0IHByb3ZpZGVkIGJ5IHRoZSBETU0gc29sdXRpb247IHJlZGlyZWN0aW5nIHRyYWZmaWMg dG8NCg0KICAgICAgICAgIHRoZSB3cm9uZyBob3N0IHdoZW4gcHJvdmlkaW5nIERNTSBzdXBwb3J0 OyBzaWduYWxpbmcgbWVzc2FnZQ0KDQogICAgICAgICAgcHJvdGVjdGlvbiBmb3IgYXV0aGVudGlj YXRpb24sIGludGVncml0eSBhbmQgY29uZmlkZW50aWFsaXR5Lg0KDQoNCg0KICAgICAgICAgIE1v dGl2YXRpb246IFZhcmlvdXMgYXR0YWNrcyBzdWNoIGFzIGltcGVyc29uYXRpb24sIGRlbmlhbCBv Zg0KDQogICAgICAgICAgc2VydmljZSwgbWFuLWluLXRoZS1taWRkbGUgYXR0YWNrcywgYW5kIHNv IG9uLCBtYXkgYmVjb21lIG5ld2x5DQoNCiAgICAgICAgICBwb3NzaWJsZSBvciBlYXNpZXIgdG8g bW91bnQgZHVlIHRvIHRoZSBpbnRyb2R1Y3Rpb24gb2YgRE1NLiAgUHJvb2YNCg0KICAgICAgICAg IG9mIHBvc3Nlc3Npb24gb2YgcGFzdCBhbmQgbmV3IElQIGFkZHJlc3NlcyBtYXkgYmUgbmVlZGVk Lg0KDQoNCg0KSCBBbnRob255IENoYW4NCg0KDQoNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KDQpGcm9tOiBkbW0tYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86ZG1tLWJvdW5jZXNAaWV0 Zi5vcmc+IFttYWlsdG86ZG1tLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKb3VuaSBL b3Job25lbg0KDQpTZW50OiBUdWVzZGF5LCBKdW5lIDE4LCAyMDEzIDI6NDAgQU0NCg0KVG86IGRt bUBpZXRmLm9yZzxtYWlsdG86ZG1tQGlldGYub3JnPg0KDQpTdWJqZWN0OiBbRE1NXSByZXF1aXJl bWVudHMgYW5kIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9ucw0KDQoNCg0KPG5vIGNvLWNoYWly IGNhcC9ib3dsZXI+DQoNCg0KDQpGb2xrcywNCg0KDQoNCkkgaGF2ZSBiZWVuIHJlYWRpbmcgU2Vj dGlvbiA2IFNlY3VyaXR5IENvbnNpZGVyYXRpb25zOg0KDQoNCg0KICAgSXQgaXMgbmVjZXNzYXJ5 IHRvIHByb3ZpZGUgc3VmZmljaWVudCBkZWZlbnNlIGFnYWluc3QgcG9zc2libGUNCg0KICAgc2Vj dXJpdHkgYXR0YWNrcywgb3IgdG8gYWRvcHQgZXhpc3Rpbmcgc2VjdXJpdHkgbWVjaGFuaXNtcyBh bmQNCg0KICAgcHJvdG9jb2xzIHRvIHByb3ZpZGUgc3VmZmljaWVudCBzZWN1cml0eSBwcm90ZWN0 aW9ucy4gIEZvciBpbnN0YW5jZSwNCg0KICAgRUFQLWJhc2VkIGF1dGhlbnRpY2F0aW9uIGNhbiBi ZSB1c2VkIGZvciBhY2Nlc3MgbmV0d29yayBzZWN1cml0eSwNCg0KICAgd2hpbGUgSVBzZWMgY2Fu IGJlIHVzZWQgZm9yIGVuZC10by1lbmQgc2VjdXJpdHkuDQoNCg0KDQpJIHRoaW5rIHRoaXMgdGV4 dCBzdGlsbCBkZXNlcnZlcyBzb21lIHR3ZWFraW5nLiBGaXJzdCwgInByb3ZpZGUgc3VmZmljaWVu dCBkZWZlbnNlIGFnYWluc3QgcG9zc2libGUgc2VjdXJpdHkgYXR0YWNrcyIuLiBhZ2FpbnN0IHdo b20/DQoNCg0KDQpTZWNvbmQsIHNob3VsZCB0aGUgdGV4dCBzYXkgc29tZXRoaW5nIHRoYXQgdGhl IERNTSBwcm90b2NvbCBpdHNlbGYgbXVzdCBub3QgYmUgdXNhYmxlIGFzIGEgdG9vbCB0byBsYXVu Y2ggYW4gYXR0YWNrIGJ5IGEgbWFsaWNpb3VzIG1vYmlsZSBub2RlIHRoYXQgaGFwcGVucyB0byBr bm93IHRoYXQgaXQgaXMgYXR0YWNoZWQgdG8gYSBuZXR3b3JrIGltcGxlbWVudGluZyBETU0gYW5k IGtub3dzIChzb21laG93KSBob3cgdGhlIERNTSBwcm90b2NvbCBmdW5jdGlvbnM/DQoNCg0KDQot IEpvdW5pDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQoNCmRtbSBtYWlsaW5nIGxpc3QNCg0KZG1tQGlldGYub3JnPG1haWx0bzpkbW1AaWV0Zi5vcmc+ DQoNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tDQoNCl9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCmRtbSBtYWlsaW5nIGxp c3QNCg0KZG1tQGlldGYub3JnPG1haWx0bzpkbW1AaWV0Zi5vcmc+DQoNCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpkbW0gbWFpbGluZyBsaXN0DQpkbW1AaWV0Zi5vcmc8bWFp bHRvOmRtbUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v ZG1tDQoNCg0KDQotLQ0KUlNNIERlcGFydG1lbnQsIFRFTEVDT00gQnJldGFnbmUsIEZyYW5jZQ0K Sm9uZy1IeW91ayBMZWUsIGxpdmluZyBzb21ld2hlcmUgYmV0d2VlbiAvZGV2L251bGwgYW5kIC9k ZXYvcmFuZG9tDQoNCiNlbWFpbDogam9uZ2h5b3VrIChhdCkgZ21haWwgKGRvdCkgY29tDQojd2Vi cGFnZTogaHR0cDovL3NpdGVzLmdvb2dsZS5jb20vc2l0ZS9odXJyeW9uLw0K --_000_6E31144C030982429702B11D6746B98C37095087szxeml557mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5v c2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJc QFNpbVN1biI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0KcA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIiwic2VyaWYiO30NCnAuTXNvQWNldGF0ZSwgbGkuTXNv QWNldGF0ZSwgZGl2Lk1zb0FjZXRhdGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJCYWxsb29uIFRleHQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjguMHB0Ow0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJz YW5zLXNlcmlmIjt9DQpzcGFuLkJhbGxvb25UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiQmFs bG9vbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGlu azoiQmFsbG9vbiBUZXh0IjsNCglmb250LWZhbWlseToiVGFob21hIiwic2Fucy1zZXJpZiI7fQ0K c3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5O30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkJ5b3VuZy1Kbyw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29s b3I6IzFGNDk3RCI+QXJlIHlvdSBva2F5IHdpdGggdGhlIHJldmlzZWQgdGV4dCBmb3IgUkVRNiBw cm92aWRlZCBieSBKb25nLUh5b3VrPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6IzFGNDk3RCI+SCBBbnRob255IENoYW48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTomcXVvdDtUYWhvbWEmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90 OyI+IEpvbmctSHlvdWsgTGVlIFttYWlsdG86am9uZ2h5b3VrQGdtYWlsLmNvbV0NCjxicj4NCjxi PlNlbnQ6PC9iPiBTYXR1cmRheSwgSnVuZSAyMiwgMjAxMyA2OjE3IFBNPGJyPg0KPGI+VG86PC9i PiBkbW1AaWV0Zi5vcmc7IGggY2hhbjxicj4NCjxiPkNjOjwvYj4gSm91bmkgS29yaG9uZW48YnI+ DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtETU1dIHJlcXVpcmVtZW50cyBhbmQgdGhlIHNlY3VyaXR5 IGNvbnNpZGVyYXRpb25zPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5IaSBhbGwsPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5IZXJlIGlzIHRleHQgZm9yIHNlY3VyaXR5LiBBcG9sb2dpemUgZm9yIGJlaW5nIGxhdGUsIEFu dGhvbnkuPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PT09PT09PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj41LjYuICZuYnNwO1NlY3VyaXR5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJFUTY6IERNTSBNVVNUIGJlIHByb3RlY3RlZCBieSBzZWN1 cml0eSBtZWNoYW5pc21zL3Byb3RvY29scyBpbiB0ZXJtcyBvZiBuZXR3b3JrIGFjY2VzcyBzZWN1 cml0eSBhbmQgZW5kLXRvLWVuZCBzZWN1cml0eS4gTmV0d29yayBhY2Nlc3Mgc2VjdXJpdHkgaXMg cmVxdWlyZWQgYmV0d2VlbiB0aGUgbW9iaWxlIGhvc3Qvcm91dGVyIGFuZCB0aGUgYWNjZXNzIG5l dHdvcmsgZGVwbG95aW5nIERNTSwgdG8gYWxsb3cNCiBvbmx5IGEgbGVnaXRpbWF0ZSBtb2JpbGUg aG9zdC9yb3V0ZXIgdG8gdXNlIERNTS4gRW5kLXRvLWVuZCBzZWN1cml0eSBpcyByZXF1aXJlZCBi ZXR3ZWVuIG5vZGVzIHRoYXQgcGFydGljaXBhdGUgaW4gRE1NLCB0byBwcm90ZWN0IERNTSBzaWdu YWxpbmcgbWVzc2FnZXMuIEV4aXN0aW5nIHNlY3VyaXR5IG1lY2hhbmlzbXMvcHJvdG9jb2xzIE1B WSBiZSBwb3NzaWJsZSB0byBwcm92aWRlIHN1ZmZpY2llbnQgc2VjdXJpdHkgcHJvdGVjdGlvbnMg dG8NCiBETU0uIEZvciBpbnN0YW5jZSwgRUFQLWJhc2VkIGF1dGhlbnRpY2F0aW9uIGNhbiBiZSB1 c2VkIGZvciBuZXR3b3JrIGFjY2VzcyBzZWN1cml0eSwgd2hpbGUgSVBzZWMgY2FuIGJlIHVzZWQg Zm9yIGVuZC10by1lbmQgc2VjdXJpdHkuIE5vdGUgdGhhdCB3aGVuIHRoZSBleGlzdGluZyBzZWN1 cml0eSBtZWNoYW5pc21zL3Byb3RvY29scyBhcmUgYXBwbGllZCB0byBETU0sIHNlY3VyaXR5IHJp c2tzIHRoYXQgTUFZIGJlIGludHJvZHVjZWQgYnkgRE1NDQogTVVTVCBiZSBjb25zaWRlcmVkIHRv IGJlIGVsaW1pbmF0ZWQuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkEgc2VjdXJpdHkgbWVjaGFuaXNtL3Byb3RvY29sIHRoYXQgcHJv dmlkZXMgcHJvb2Ygb2YgcG9zc2Vzc2lvbiBvZiBwYXN0IGFuZCBuZXcgSVAgYWRkcmVzc2VzIG9m IGEgbW9iaWxlIGhvc3Qvcm91dGVyIE1BWSBiZSBuZWVkZWQuPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1vdGl2YXRpb246IFZhcmlvdXMgYXR0 YWNrcyBzdWNoIGFzIGltcGVyc29uYXRpb24sIGRlbmlhbCBvZiBzZXJ2aWNlLCBtYW4taW4tdGhl LW1pZGRsZSBhdHRhY2tzLCBhbmQgc28gb24sIE1BWSBiZSBsYXVuY2hlZCBhZ2FpbnN0IERNTS4g QWNjb3JkaW5nbHksIHNlY3VyaXR5IG1lY2hhbmlzbXMvcHJvdG9jb2xzIHByb3ZpZGluZyBhY2Nl c3MgY29udHJvbCwgaW50ZWdyaXR5LCBhdXRoZW50aWNhdGlvbiwgYXV0aG9yaXphdGlvbiwNCiBj b25maWRlbnRpYWxpdHksIGV0Yy4gTVVTVCBiZSByZXF1aXJlZCB0byBwcm90ZWN0IERNTS4gRm9y IGluc3RhbmNlLCBhbiBpbGxlZ2l0aW1hdGUgbm9kZSBhdHRlbXB0cyB0byBhY2Nlc3MgYSBuZXR3 b3JrIHByb3ZpZGluZyBETU0uIEFub3RoZXIgZXhhbXBsZSBpcyB0aGF0IGEgbWFsaWNpb3VzIG5v ZGUgY2FuIGZvcmdlIGEgbnVtYmVyIG9mIHNpZ25hbGluZyBtZXNzYWdlcyB0aHVzIHJlZGlyZWN0 aW5nIHRyYWZmaWMgZnJvbSBpdHMgbGVnaXRpbWF0ZQ0KIHBhdGguIENvbnNlcXVlbnRseSwgdGhl IHNwZWNpZmljIG5vZGUgaXMgdW5kZXIgYSBkZW5pYWwgb2Ygc2VydmljZSBhdHRhY2ssIHdoZXJl YXMgb3RoZXIgbm9kZXMgZG8gbm90IHJlY2VpdmUgdGhlaXIgdHJhZmZpYy4gQXMgc2lnbmFsaW5n IG1lc3NhZ2VzIE1BWSB0cmF2ZWwgb3ZlciB0aGUgSW50ZXJuZXQsIHRoZSBlbmQtdG8tZW5kIHNl Y3VyaXR5IGJldHdlZW4gY29tbXVuaWNhdGluZyBub2RlcyBNVVNUIGJlIHJlcXVpcmVkLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIHJl cXVpcmVtZW50IGFkZHJlc3NlcyB0aGUgcHJvYmxlbXMgb2YgcG90ZW50aWFsbHkgaW5zZWN1cmUg bW9iaWxpdHkgbWFuYWdlbWVudCBwcm90b2NvbHMgd2hpY2ggbWFrZSBkZXBsb3ltZW50IGluZmVh c2libGUgYmVjYXVzZSBwbGF0Zm9ybXMgY29uZm9ybWluZyB0byB0aGUgcHJvdG9jb2xzIGFyZSBh dCByaXNrIGZvciBkYXRhIGxvc3MgYW5kIG51bWVyb3VzIG90aGVyIGRhbmdlcnMsIGluY2x1ZGlu Zw0KIGZpbmFuY2lhbCBoYXJtIHRvIHVzZXJzLiAoSSBsZWF2ZSBpdCB0byBiZSBtb2RpZmllZCBv ciBpbXByb3ZlZCBieSBBbnRob255KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj42LiAmbmJzcDtTZWN1cml0eSBDb25zaWRlcmF0aW9uczxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+KE5vdyBJIGRv IG5vdCB0aGluayB3ZSBuZWVkIHRvIHB1dCB0ZXh0IGhlcmUpPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj49PT09PT08bzpwPjwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gRnJpLCBKdW4gMjEsIDIwMTMgYXQgOTozNiBQTSwg U2VpbCBKZW9uICZsdDs8YSBocmVmPSJtYWlsdG86c2VpbGplb25AYXYuaXQucHQiIHRhcmdldD0i X2JsYW5rIj5zZWlsamVvbkBhdi5pdC5wdDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXY+DQo8cD5IaSwgQW50aG9ueSBhbmQgYWxsLDxvOnA+PC9vOnA+PC9wPg0KPHA+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD5BY3R1YWxseSwgd2hlbiBpdCBjb21lcyB0byByZXZp ZXdpbmcgQkoncyBjb21tZW50LCBpdCBzZWVtcyB0b3VjaGluZyB2ZXJ5IGZ1bmRhbWVudGFsIHN0 YXRlbWVudCBieSBtZW50aW9uaW5nIHRoZSBuZWVkIG9mIElQIGxheWVyIG1vYmlsaXR5IHN1cHBv cnQgZm9yIG11bHRpY2FzdCBzZXNzaW9uIChpZiBuZWVkZWQpLCB0aG91Z2ggdGhpcyByZXF1aXJl bWVudCBpdHNlbGYgaGFzIGltcGxpY2l0bHkgaW5jbHVkZWQgaXQuIEJ1dCBpdCdzIG9rDQogdG8g bWUuPG86cD48L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPkBKb3VuaSwg d2UgcmVzcG9uZCB0byB0aGUgdGlja2V0ICMyMiBhcyB3ZWxsLjxvOnA+PC9vOnA+PC9wPg0KPHA+ QXMgeW91IGtub3csIHdlIGhhdmUgdHJpZWQgdG8gaWRlbnRpZnkgYW5kIGRpc2N1c3MgdGhlIG1l YW5pbmcgb2YgZmxleGlibGUgZGlzdHJpYnV0aW9uIGluIHRoZSBsaXN0LiBJZiB3ZSB1bmZvbGQg dGhlIG1lYW5pbmcgaGlkZGVuIGluIHRoZSBhYnN0cmFjdCB3b3JkcywgaXQgd291bGQgYmUgZml0 IHRvIHdoYXQgeW91IHNhaWQuIEJ1dCB0aGUgcmV3b3JkZWQgc2VudGVuY2VzIHdlcmUgbW9zdGx5 IGNvcGllZCBmcm9tIOKAnE1vdGl2YXRpb27igJ0NCiBwYXJhZ3JhcGggYW5kIGFycmFuZ2VkLiBP dmVyYWxsLCB0aGUgTW90aXZhdGlvbiB3YXMgcmV3b3JkZWQuPG86cD48L286cD48L3A+DQo8cD4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPkJ5IHRha2luZyBpbnRvIGFjY291bnQgdHdvIGNvbW1l bnRzLCB0aGUgcmV2aXNlZCB0ZXh0IGlzIGFzIGZvbGxvd3MuPG86cD48L286cD48L3A+DQo8cD4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIHN0eWxlPSJiYWNrZ3JvdW5kOiNGRkZGREQiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5SRVE3OiBETU0gU0hPVUxEIGNvbnNpZGVyIG11bHRp Y2FzdCBlYXJseSBzbyB0aGF0IHNvbHV0aW9ucyBjYW48L3NwYW4+PG86cD48L286cD48L3A+DQo8 cCBzdHlsZT0iYmFja2dyb3VuZDojRkZGRkREIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dCI+YmUgZGV2ZWxvcGVkIG5vdCBvbmx5IHRvDQo8c3BhbiBzdHlsZT0iY29sb3I6cmVkIj5wcm92 aWRlIElQIG1vYmlsaXR5IHRvIGtlZXAgSVAgbXVsdGljYXN0IHNlc3Npb25zIHdoZW4gaXQgaXMg bmVlZGVkPC9zcGFuPiwgYnV0IHRvIGF2b2lkIG5ldHdvcmsgaW5lZmZpY2llbmN5IGlzc3VlcyBp biBtdWx0aWNhc3Q8YnI+DQp0cmFmZmljIGRlbGl2ZXJ5IChzdWNoIGFzIGR1cGxpY2F0ZSBtdWx0 aWNhc3Qgc3Vic2NyaXB0aW9uczxicj4NCnRvd2FyZHMgdGhlIGRvd25zdHJlYW0gdHVubmVsIGVu dGl0PHNwYW4gc3R5bGU9ImNvbG9yOnJlZCI+aWVzPHM+eTwvcz48L3NwYW4+KS4gVGhlIG11bHRp Y2FzdCBzb2x1dGlvbjxzcGFuIHN0eWxlPSJjb2xvcjpyZWQiPnM8L3NwYW4+PGJyPg0Kc2hvdWxk IHRoZXJlZm9yZSBhdm9pZCByZXN0cmljdGluZyB0aGUgbWFuYWdlbWVudCBvZiBhbGwgSVA8YnI+ DQptdWx0aWNhc3QgdHJhZmZpYyB0byBhIHNpbmdsZSBob3N0IHRocm91Z2ggYSBkZWRpY2F0ZWQ8 YnI+DQoodHVubmVsKSBpbnRlcmZhY2Ugb24gbXVsdGljYXN0LWNhcGFibGUgYWNjZXNzIHJvdXRl cnMuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgc3R5bGU9ImJhY2tncm91bmQ6I0ZGRkZERCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPk1vdGl2YXRpb246IEV4aXN0aW5nIG11bHRp Y2FzdCBkZXBsb3ltZW50IGhhdmUgYmVlbiBpbnRyb2R1Y2VkIGFmdGVyIGNvbXBsZXRpbmcgdGhl IGRlc2lnbiBvZiB0aGUgcmVmZXJlbmNlIG1vYmlsaXR5IHByb3RvY29sLCB0aGVuIG9wdGltaXph dGlvbiBhbmQgZXh0ZW5zaW9ucyBoYXZlIGJlZW4gZm9sbG93ZWQsIGJ5IOKAnHBhdGNoaW5nLXVw 4oCdDQogcHJvY2VkdXJlLCB0aHVzIGxlYWRpbmcgdG8gbmV0d29yayBpbmVmZmljaWVuY3kgYW5k IG5vbi1vcHRpbWFsIHJvdXRpbmcuIFRoZSBtdWx0aWNhc3Qgc29sdXRpb25zIHNob3VsZCB0aGVy ZWZvcmUgYmUgcmVxdWlyZWQgdG8gY29uc2lkZXIgZWZmaWNpZW5jeSBuYXR1cmUgaW4gbXVsdGlj YXN0IHRyYWZmaWMgZGVsaXZlcnkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cD5wLnMuIEBKb3VuaSwgSSByZW1lbWJlciAjMzMgdGlja2V0IHdhcyBy ZXNvbHZlZCBieSBhbnN3ZXJpbmcgQ2hhcmxpZeKAmXMgY29tbWVudC4gQ2hlY2sgaXQsIHBsZWFz ZS48bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cD5SZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPHA+U2VpbDxvOnA+PC9v OnA+PC9wPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LTxicj4NCkZyb206IDxhIGhyZWY9Im1haWx0bzpkbW0tYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0 PSJfYmxhbmsiPmRtbS1ib3VuY2VzQGlldGYub3JnPC9hPiBbbWFpbHRvOjxhIGhyZWY9Im1haWx0 bzpkbW0tYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmRtbS1ib3VuY2VzQGlldGYu b3JnPC9hPl0gT24gQmVoYWxmIE9mIGggY2hhbjxicj4NClNlbnQ6IEZyaWRheSwgSnVuZSAyMSwg MjAxMyAxOjI2IEFNPGJyPg0KVG86IEpvdW5pIEtvcmhvbmVuOyA8YSBocmVmPSJtYWlsdG86ZG1t QGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+ZG1tQGlldGYub3JnPC9hPjsgS0lNLCBCWU9VTkct Sk8gSiAoQllPVU5HLUpPPGJyPg0KQ2M6IEpvbmctSHlvdWsgTGVlPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3ViamVjdDogUmU6IFtE TU1dIHJlcXVpcmVtZW50cyBhbmQgdGhlIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cD4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwPlNlaWwgb3IgU2VyZ2lvLDxvOnA+PC9vOnA+PC9wPg0KPHA+Q2FuIHlvdSByZXBs eSB0byB0aGUgZm9sbG93aW5nOjxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7PG86cD48L286cD48 L3A+DQo8cD5UaGUgY29tbWVudHMgZnJvbSBCeW91bmctSm8gS2ltIHRvIFJFUTcgaW4gdmVyc2lv biA0IGlzIGFzIGZvbGxvd3M6PG86cD48L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwPkkgc3VnZ2VzdCB0byBkcm9wIHRoaXMgcmVxdWlyZW1lbnQgb3IgbWFrZSBhIGNsZWFy ZXIgc3RhdGVtZW50IGxpa2UgJnF1b3Q7RE1NIHNob3VsZCBhbGxvdyBtdWx0aWNhc3QgdG8gc3Vy dml2ZSBJUCBsYXllciBtb2JpbGl0eSB3aXRob3V0IHBhY2tldCBsb3NzJnF1b3Q7LCBvciBtb3Jl IG1vZGVzdGx5LCAmcXVvdDtETU0gc2hvdWxkIG5vdCBmb3JlY2xvc2UgbXVsdGljYXN0IHN1cHBv cnQgZHVyaW5nIElQIGxheWVyIG1vYmlsaXR5LiZxdW90OywgZXRjLi48bzpwPjwvbzpwPjwvcD4N CjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD5I aXMgc3VnZ2VzdGVkIHRleHQgaXMgdG8gcmVwbGFjZSBSRVE3IHdpdGggc29tZXRoaW5nIGxpa2Ug dGhlIGZvbGxvd2luZzo8bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHA+Jm5ic3A7Jm5ic3A7IFJFUTc6Jm5ic3A7IERNTSBTSE9VTEQgZW5hYmxlIG11bHRpY2FzdCBw YWNrZXQgZGVsaXZlcnkgZHVyaW5nIG1vYmlsaXR5IGV2ZW50cyBhcyBuZWVkZWQuPG86cD48L286 cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPkggQW50aG9ueSBDaGFuPG86cD48 L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHA+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvcD4NCjxwPkZy b206IGggY2hhbiA8bzpwPjwvbzpwPjwvcD4NCjxwPlNlbnQ6IFRodXJzZGF5LCBKdW5lIDIwLCAy MDEzIDc6MTUgUE08bzpwPjwvbzpwPjwvcD4NCjxwPlRvOiAnSm91bmkgS29yaG9uZW4nOyA8YSBo cmVmPSJtYWlsdG86ZG1tQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNv bG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmRtbUBpZXRmLm9yZzwvc3Bhbj48 L2E+OyAnS0lNLCBCWU9VTkctSk8gSiAoQllPVU5HLUpPJzxvOnA+PC9vOnA+PC9wPg0KPHA+Q2M6 ICdKb25nLUh5b3VrIExlZSc8bzpwPjwvbzpwPjwvcD4NCjxwPlN1YmplY3Q6IFJFOiBbRE1NXSBy ZXF1aXJlbWVudHMgYW5kIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9uczxvOnA+PC9vOnA+PC9w Pg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD5UaGUgY29tbWVudHMgZnJvbSBCeW91bmct Sm8gS2ltIHRvIFJFUTYgYW5kIFNlY3Rpb24gNiBpbiB2ZXJzaW9uIDQgd2VyZSB0aGUgZm9sbG93 aW5nOjxvOnA+PC9vOnA+PC9wPg0KPHA+VGhlcmUgYXJlIHRvbyBtdWNoIHRleHQgaW4gdGhlIHNl Y3VyaXR5IFJFUTYgdGhhdCBhcmUgdmFndWUgYW5kIHRvbyB3aWRlLiA8bzpwPg0KPC9vOnA+PC9w Pg0KPHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD5BbmQgU2VjdGlvbiA2LiBTZWN1cml0eSBj b25zaWRlcmF0aW9ucyBzaG91bGQgc2F5ICZxdW90O25vbmUmcXVvdDssICdjYXVzZSB0aGF0J3Mg dXN1YWxseSB0aGUgc2VjdGlvbiB0aGF0IGRpc2N1c3NlcyBzZWN1cml0eSBjb25zaWRlcmF0aW9u cyByZWxhdGVkIHRvIHRoZSBkcmFmdCBpdHNlbGYuIFNpbmNlIHRoaXMgaXMgYSByZXF1aXJlbWVu dCBkcmFmdCwgdGhlcmUgaXMgbm8gc3VjaCB0aGluZy48bzpwPjwvbzpwPjwvcD4NCjxwPlRoZXJl IGlzIGEgc2VwYXJhdGUgcmVxdWlyZW1lbnQgZWFybGllciB0byBjb3ZlciBzZWN1cml0eSBpc3N1 ZXMgZHVlIHRvIERNTS48bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHA+UkVRNjombmJzcDsgU2VjdXJpdHkgY29uc2lkZXJhdGlvbnM8bzpwPjwvbzpwPjwvcD4NCjxw PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IERNTSBwcm90b2NvbCBzb2x1dGlvbnMgTVVTVCBjb25z aWRlciBzZWN1cml0eSByaXNrcyBpbnRyb2R1Y2VkPG86cD48L286cD48L3A+DQo8cD4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgYnkgRE1NIGlu dG8gdGhlIG5ldHdvcmsuJm5ic3A7IEV4YW1wbGVzIG9mIHN1Y2ggcmlza3MgdG8gYmU8bzpwPjwv bzpwPjwvcD4NCjxwPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBjb25zaWRlcmVkIG1heSBpbmNsdWRlIGF1dGhlbnRpY2F0aW9uIGFuZCBhdXRo b3JpemF0aW9uIG1lY2hhbmlzbXM8bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB0aGF0IGFsbG93IGEgbW9iaWxl IGhvc3Qvcm91dGVyIHRvIHVzZSB0aGUgbW9iaWxpdHk8bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzdXBwb3J0 IHByb3ZpZGVkIGJ5IHRoZSBETU0gc29sdXRpb247IHJlZGlyZWN0aW5nIHRyYWZmaWMgdG88bzpw PjwvbzpwPjwvcD4NCjxwPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyB0aGUgd3JvbmcgaG9zdCB3aGVuIHByb3ZpZGluZyBETU0gc3VwcG9ydDsg c2lnbmFsaW5nIG1lc3NhZ2U8bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBwcm90ZWN0aW9uIGZvciBhdXRoZW50 aWNhdGlvbiwgaW50ZWdyaXR5IGFuZCBjb25maWRlbnRpYWxpdHkuPG86cD48L286cD48L3A+DQo8 cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBNb3RpdmF0aW9uOiBWYXJpb3VzIGF0dGFja3Mgc3Vj aCBhcyBpbXBlcnNvbmF0aW9uLCBkZW5pYWwgb2Y8bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBzZXJ2aWNlLCBt YW4taW4tdGhlLW1pZGRsZSBhdHRhY2tzLCBhbmQgc28gb24sIG1heSBiZWNvbWUgbmV3bHkgPG86 cD4NCjwvbzpwPjwvcD4NCjxwPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO3Bvc3NpYmxlIG9yIGVhc2llciB0byBtb3VudCBkdWUgdG8g dGhlIGludHJvZHVjdGlvbiBvZiBETU0uJm5ic3A7IFByb29mPG86cD48L286cD48L3A+DQo8cD4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgb2Yg cG9zc2Vzc2lvbiBvZiBwYXN0IGFuZCBuZXcgSVAgYWRkcmVzc2VzIG1heSBiZSBuZWVkZWQuPG86 cD48L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPkggQW50aG9ueSBDaGFu PG86cD48L286cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHA+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08bzpwPjwvbzpwPjwvcD4N CjxwPkZyb206IDxhIGhyZWY9Im1haWx0bzpkbW0tYm91bmNlc0BpZXRmLm9yZyIgdGFyZ2V0PSJf YmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5kb3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25l Ij5kbW0tYm91bmNlc0BpZXRmLm9yZzwvc3Bhbj48L2E+IFs8YSBocmVmPSJtYWlsdG86ZG1tLWJv dW5jZXNAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93 dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+bWFpbHRvOmRtbS1ib3VuY2VzQGlldGYub3JnPC9z cGFuPjwvYT5dDQogT24gQmVoYWxmIE9mIEpvdW5pIEtvcmhvbmVuPG86cD48L286cD48L3A+DQo8 cD5TZW50OiBUdWVzZGF5LCBKdW5lIDE4LCAyMDEzIDI6NDAgQU08bzpwPjwvbzpwPjwvcD4NCjxw PlRvOiA8YSBocmVmPSJtYWlsdG86ZG1tQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4g c3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmRtbUBpZXRmLm9y Zzwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8cD5TdWJqZWN0OiBbRE1NXSByZXF1aXJlbWVu dHMgYW5kIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9uczxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cD4mbHQ7bm8gY28tY2hhaXIgY2FwL2Jvd2xlciZndDs8bzpw PjwvbzpwPjwvcD4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+Rm9sa3MsPG86cD48L286 cD48L3A+DQo8cD4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwPkkgaGF2ZSBiZWVuIHJlYWRpbmcg U2VjdGlvbiA2IFNlY3VyaXR5IENvbnNpZGVyYXRpb25zOjxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cD4mbmJzcDsmbmJzcDsgSXQgaXMgbmVjZXNzYXJ5IHRvIHBy b3ZpZGUgc3VmZmljaWVudCBkZWZlbnNlIGFnYWluc3QgcG9zc2libGU8bzpwPjwvbzpwPjwvcD4N CjxwPiZuYnNwOyZuYnNwOyBzZWN1cml0eSBhdHRhY2tzLCBvciB0byBhZG9wdCBleGlzdGluZyBz ZWN1cml0eSBtZWNoYW5pc21zIGFuZDxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7Jm5ic3A7IHBy b3RvY29scyB0byBwcm92aWRlIHN1ZmZpY2llbnQgc2VjdXJpdHkgcHJvdGVjdGlvbnMuJm5ic3A7 IEZvciBpbnN0YW5jZSw8bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOyZuYnNwOyBFQVAtYmFzZWQg YXV0aGVudGljYXRpb24gY2FuIGJlIHVzZWQgZm9yIGFjY2VzcyBuZXR3b3JrIHNlY3VyaXR5LDxv OnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7Jm5ic3A7IHdoaWxlIElQc2VjIGNhbiBiZSB1c2VkIGZv ciBlbmQtdG8tZW5kIHNlY3VyaXR5LjxvOnA+PC9vOnA+PC9wPg0KPHA+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cD5JIHRoaW5rIHRoaXMgdGV4dCBzdGlsbCBkZXNlcnZlcyBzb21lIHR3ZWFraW5n LiBGaXJzdCwgJnF1b3Q7cHJvdmlkZSBzdWZmaWNpZW50IGRlZmVuc2UgYWdhaW5zdCBwb3NzaWJs ZSBzZWN1cml0eSBhdHRhY2tzJnF1b3Q7Li4gYWdhaW5zdCB3aG9tPzxvOnA+PC9vOnA+PC9wPg0K PHA+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cD5TZWNvbmQsIHNob3VsZCB0aGUgdGV4dCBzYXkg c29tZXRoaW5nIHRoYXQgdGhlIERNTSBwcm90b2NvbCBpdHNlbGYgbXVzdCBub3QgYmUgdXNhYmxl IGFzIGEgdG9vbCB0byBsYXVuY2ggYW4gYXR0YWNrIGJ5IGEgbWFsaWNpb3VzIG1vYmlsZSBub2Rl IHRoYXQgaGFwcGVucyB0byBrbm93IHRoYXQgaXQgaXMgYXR0YWNoZWQgdG8gYSBuZXR3b3JrIGlt cGxlbWVudGluZyBETU0gYW5kIGtub3dzIChzb21laG93KSBob3cgdGhlIERNTSBwcm90b2NvbA0K IGZ1bmN0aW9ucz88bzpwPjwvbzpwPjwvcD4NCjxwPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHA+ LSBKb3VuaTxvOnA+PC9vOnA+PC9wPg0KPHA+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvcD4NCjxwPmRtbSBtYWlsaW5nIGxpc3Q8bzpw PjwvbzpwPjwvcD4NCjxwPjxhIGhyZWY9Im1haWx0bzpkbW1AaWV0Zi5vcmciIHRhcmdldD0iX2Js YW5rIj48c3BhbiBzdHlsZT0iY29sb3I6d2luZG93dGV4dDt0ZXh0LWRlY29yYXRpb246bm9uZSI+ ZG1tQGlldGYub3JnPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwvcD4NCjxwPjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tIiB0YXJnZXQ9Il9ibGFuayI+PHNw YW4gc3R5bGU9ImNvbG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vZG1tPC9zcGFuPjwvYT48bzpwPjwvbzpwPjwv cD4NCjxwPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86 cD48L286cD48L3A+DQo8cD5kbW0gbWFpbGluZyBsaXN0PG86cD48L286cD48L3A+DQo8cD48YSBo cmVmPSJtYWlsdG86ZG1tQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+PHNwYW4gc3R5bGU9ImNv bG9yOndpbmRvd3RleHQ7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPmRtbUBpZXRmLm9yZzwvc3Bhbj48 L2E+PG86cD48L286cD48L3A+DQo8cD48YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2RtbSIgdGFyZ2V0PSJfYmxhbmsiPjxzcGFuIHN0eWxlPSJjb2xvcjp3aW5k b3d0ZXh0O3RleHQtZGVjb3JhdGlvbjpub25lIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2RtbTwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQpkbW0gbWFpbGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOmRtbUBpZXRm Lm9yZyI+ZG1tQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vZG1tIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9kbW08L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxicj4NCjxiciBjbGVhcj0iYWxsIj4NCjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tLSA8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5SU00gRGVwYXJ0bWVudCwgVEVMRUNPTSBCcmV0YWduZSwgRnJhbmNlPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Kb25nLUh5 b3VrIExlZSwgbGl2aW5nIHNvbWV3aGVyZSBiZXR3ZWVuIC9kZXYvbnVsbCBhbmQgL2Rldi9yYW5k b208bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ I2VtYWlsOiZuYnNwO2pvbmdoeW91ayAoYXQpIGdtYWlsIChkb3QpIGNvbTxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+I3dlYnBhZ2U6IDxhIGhyZWY9 Imh0dHA6Ly9zaXRlcy5nb29nbGUuY29tL3NpdGUvaHVycnlvbi8iIHRhcmdldD0iX2JsYW5rIj4N Cmh0dHA6Ly9zaXRlcy5nb29nbGUuY29tL3NpdGUvaHVycnlvbi88L2E+PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_6E31144C030982429702B11D6746B98C37095087szxeml557mbxchi_-- From h.anthony.chan@huawei.com Mon Jul 29 06:00:55 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A241021F85B3 for ; Mon, 29 Jul 2013 06:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQa3L4lkY2JR for ; Mon, 29 Jul 2013 06:00:48 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 462C821F99F3 for ; Mon, 29 Jul 2013 06:00:33 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATW94018; Mon, 29 Jul 2013 13:00:25 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 29 Jul 2013 14:00:18 +0100 Received: from SZXEML460-HUB.china.huawei.com (10.82.67.203) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 29 Jul 2013 14:00:20 +0100 Received: from szxeml557-mbx.china.huawei.com ([169.254.5.42]) by szxeml460-hub.china.huawei.com ([10.82.67.203]) with mapi id 14.01.0323.007; Mon, 29 Jul 2013 21:00:15 +0800 From: h chan To: Jouni Korhonen Thread-Topic: [DMM] requirements and the security considerations Thread-Index: AQHOcd5YTvNdEYWWNEqbiO1RU3f4+Zl70jxg Date: Mon, 29 Jul 2013 13:00:14 +0000 Message-ID: <6E31144C030982429702B11D6746B98C3709508D@szxeml557-mbx.china.huawei.com> References: <6E31144C030982429702B11D6746B98C3709289C@szxeml557-mbx.china.huawei.com> <14AA4109-B449-4A00-9487-476086DD8540@gmail.com> In-Reply-To: <14AA4109-B449-4A00-9487-476086DD8540@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.136.208] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: Jong-Hyouk Lee , "dmm@ietf.org" Subject: Re: [DMM] requirements and the security considerations X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 13:00:55 -0000 It looks like the suggested text from Jong-Hyouk on the motivation section = of REQ6 has attempted to provide the security considerations in the DMM env= ironment.=20 H Anthony Chan -----Original Message----- From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 Sent: Tuesday, June 25, 2013 9:58 PM To: h chan Cc: dmm@ietf.org; KIM, BYOUNG-JO J (BYOUNG-JO; Jong-Hyouk Lee Subject: Re: [DMM] requirements and the security considerations On Jun 21, 2013, at 3:14 AM, h chan wrote: > The comments from Byoung-Jo Kim to REQ6 and Section 6 in version 4 were t= he following: > There are too much text in the security REQ6 that are vague and too wide.= =20 >=20 > And Section 6. Security considerations should say "none", 'cause that's u= sually the section that discusses security considerations related to the dr= aft itself. Since this is a requirement draft, there is no such thing. > There is a separate requirement earlier to cover security issues due to D= MM. In some recent requirements documents I have seen rather extensive Security= Consideration sections. What I would assume to see here, is a generic disc= ussion on the security considerations on distributed environment. That is n= ot about requirements itself per se. - JOuni (as an individual.. too hot here to wear any hat etc :) >=20 > REQ6: Security considerations >=20 > DMM protocol solutions MUST consider security risks introduced > by DMM into the network. Examples of such risks to be > considered may include authentication and authorization mechanis= ms > that allow a mobile host/router to use the mobility > support provided by the DMM solution; redirecting traffic to > the wrong host when providing DMM support; signaling message > protection for authentication, integrity and confidentiality. >=20 > Motivation: Various attacks such as impersonation, denial of > service, man-in-the-middle attacks, and so on, may become newly= =20 > possible or easier to mount due to the introduction of DMM. Pro= of > of possession of past and new IP addresses may be needed. >=20 > H Anthony Chan >=20 >=20 > -----Original Message----- > From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of=20 > Jouni Korhonen > Sent: Tuesday, June 18, 2013 2:40 AM > To: dmm@ietf.org > Subject: [DMM] requirements and the security considerations >=20 > >=20 > Folks, >=20 > I have been reading Section 6 Security Considerations: >=20 > It is necessary to provide sufficient defense against possible > security attacks, or to adopt existing security mechanisms and > protocols to provide sufficient security protections. For instance, > EAP-based authentication can be used for access network security, > while IPsec can be used for end-to-end security. >=20 > I think this text still deserves some tweaking. First, "provide sufficien= t defense against possible security attacks".. against whom? >=20 > Second, should the text say something that the DMM protocol itself must n= ot be usable as a tool to launch an attack by a malicious mobile node that = happens to know that it is attached to a network implementing DMM and knows= (somehow) how the DMM protocol functions? >=20 > - Jouni > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From h.anthony.chan@huawei.com Mon Jul 29 08:12:23 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B9A321F9D45 for ; Mon, 29 Jul 2013 08:12:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8LDwUqEtCPV0 for ; Mon, 29 Jul 2013 08:12:18 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 40E7121F9AE3 for ; Mon, 29 Jul 2013 08:12:12 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AVN54579; Mon, 29 Jul 2013 15:12:10 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 29 Jul 2013 16:11:59 +0100 Received: from SZXEML457-HUB.china.huawei.com (10.82.67.200) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 29 Jul 2013 16:12:04 +0100 Received: from szxeml557-mbx.china.huawei.com ([169.254.5.42]) by szxeml457-hub.china.huawei.com ([10.82.67.200]) with mapi id 14.01.0323.007; Mon, 29 Jul 2013 23:11:20 +0800 From: h chan To: Jouni Korhonen , "dmm@ietf.org" Thread-Topic: issue tracker and the requirements draft Thread-Index: AQHOh/BcdM6yLNWnYEK+yI9mHzgnu5l7yODg Date: Mon, 29 Jul 2013 15:11:20 +0000 Message-ID: <6E31144C030982429702B11D6746B98C370950F8@szxeml557-mbx.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.216.96] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [DMM] issue tracker and the requirements draft X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 15:12:23 -0000 As I go through the list, Issue #22 on multicast had already been satisfactorily addressed in email. = I am going to put the resolution in version 06 so that it can be closed wit= h version 06. Issue #29 on security had also been discussed in email. The revised text fr= om Jong-Hyeouk had tried to address the security requirement for DMM, and i= ncluded security consideration discussion in the motivation, so that a sepa= rate clause on Security consideration is no longer necessary. Alternatively= , the general security discussion for DMM in the motivation can move to the= Security consideration session, leaving a small part in the motivation tha= t is most relevant to the security requirement. Please continue to discuss = the resolution to this issue.=20 The remaining issues #33 to #40 also had already been discussed in email di= scussion and the recommended text had already been incorporated.=20 That is all the remaining issues I can see.=20 H Anthony Chan -----Original Message----- From: Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 Sent: Wednesday, July 24, 2013 12:03 AM To: dmm@ietf.org Cc: h chan Subject: issue tracker and the requirements draft Folks, The requirements draft still seems to have 11 open tickets: http://tools.ietf.org/wg/dmm/trac/query?status=3Dnew&status=3Dassigned&stat= us=3Dreopened&component=3Drequirements Those who recorded the issues should check whether -05 addresses them. - Jouni=20 From macsbug@research.att.com Mon Jul 29 08:33:04 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7842421F9E99 for ; Mon, 29 Jul 2013 08:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0jVLuy2TGwtr for ; Mon, 29 Jul 2013 08:32:59 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id DDA6721F9994 for ; Mon, 29 Jul 2013 08:32:58 -0700 (PDT) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id 2B1611204F3; Mon, 29 Jul 2013 11:32:55 -0400 (EDT) Received: from njfpsrvexg7.research.att.com (njfpsrvexg7.research.att.com [135.207.177.33]) by mail-blue.research.att.com (Postfix) with ESMTP id DA7B2F0367; Mon, 29 Jul 2013 11:32:57 -0400 (EDT) Received: from njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299]) by njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299%11]) with mapi; Mon, 29 Jul 2013 11:32:57 -0400 From: "KIM, BYOUNG-JO J (BYOUNG-JO)" To: h chan Date: Mon, 29 Jul 2013 11:32:48 -0400 Thread-Topic: [DMM] requirements and the security considerations Thread-Index: Ac6McOa9RPjDJS9ISHW9TuoxALR06Q== Message-ID: References: <6E31144C030982429702B11D6746B98C370928A2@szxeml557-mbx.china.huawei.com> <000301ce6e7c$063bb760$12b32620$@av.it.pt> <6E31144C030982429702B11D6746B98C37095087@szxeml557-mbx.china.huawei.com> In-Reply-To: <6E31144C030982429702B11D6746B98C37095087@szxeml557-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dmm@ietf.org" Subject: Re: [DMM] requirements and the security considerations X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 15:33:04 -0000 I suppose this is still related to my ticket #29 and now closed #27. http://trac.tools.ietf.org/wg/dmm/trac/ticket/29 As I commented there, REQ6 should concern only to risked added or amplified= by DMM. The new proposed text still talks about access network security which is a = separate issue, unless it means something else than commonly understood: ge= tting on the network.. which is not DMM's concern. As an optimization, DMM security and access network security can be tied, b= ut I don't think we are that far along yet. Also, End2End security is commonly understood as btw MN and CN, while here = I believe the authors mean MN and DMM entities in the network. Even then, f= ull IPsec may be overkill (with its mutual auth and all) and ephemeral secu= rity may be good enough to protect the service and the network. e.g., It states.. "Accordingly, security mechanisms/protocols providing acc= ess control, integrity, authentication, authorization, confidentiality, etc= . MUST be required to protect DMM" We cannot MUST "etc.", but that's just minor quibble. Access control/Authorization can be implicit, e.g., " if allowed on the net= work, you can use DMM" Authentication can be just to ensure the same MN is asking packet redirecti= on, without knowing identity. In short, security risks added or amplified by DMM can be discussed when we= have protocol specifics. There are too much specific countermeasures here = whose applicability is unknowable at this point. Bests. J. AT&T Labs - Research http://sites.google.com/site/macsbug/ On Jul 29, 2013, at 8:37 AM, h chan wrote: > Byoung-Jo, > Are you okay with the revised text for REQ6 provided by Jong-Hyouk? > =20 > H Anthony Chan > =20 > From: Jong-Hyouk Lee [mailto:jonghyouk@gmail.com]=20 > Sent: Saturday, June 22, 2013 6:17 PM > To: dmm@ietf.org; h chan > Cc: Jouni Korhonen > Subject: Re: [DMM] requirements and the security considerations > =20 > Hi all, > =20 > Here is text for security. Apologize for being late, Anthony. > =20 > =3D=3D=3D=3D=3D=3D > 5.6. Security > =20 > REQ6: DMM MUST be protected by security mechanisms/protocols in terms of = network access security and end-to-end security. Network access security is= required between the mobile host/router and the access network deploying D= MM, to allow only a legitimate mobile host/router to use DMM. End-to-end se= curity is required between nodes that participate in DMM, to protect DMM si= gnaling messages. Existing security mechanisms/protocols MAY be possible to= provide sufficient security protections to DMM. For instance, EAP-based au= thentication can be used for network access security, while IPsec can be us= ed for end-to-end security. Note that when the existing security mechanisms= /protocols are applied to DMM, security risks that MAY be introduced by DMM= MUST be considered to be eliminated.=20 > =20 > A security mechanism/protocol that provides proof of possession of past a= nd new IP addresses of a mobile host/router MAY be needed. > =20 > Motivation: Various attacks such as impersonation, denial of service, man= -in-the-middle attacks, and so on, MAY be launched against DMM. Accordingly= , security mechanisms/protocols providing access control, integrity, authen= tication, authorization, confidentiality, etc. MUST be required to protect = DMM. For instance, an illegitimate node attempts to access a network provid= ing DMM. Another example is that a malicious node can forge a number of sig= naling messages thus redirecting traffic from its legitimate path. Conseque= ntly, the specific node is under a denial of service attack, whereas other = nodes do not receive their traffic. As signaling messages MAY travel over t= he Internet, the end-to-end security between communicating nodes MUST be re= quired. > =20 > This requirement addresses the problems of potentially insecure mobility = management protocols which make deployment infeasible because platforms con= forming to the protocols are at risk for data loss and numerous other dange= rs, including financial harm to users. (I leave it to be modified or improv= ed by Anthony) > =20 > 6. Security Considerations > (Now I do not think we need to put text here) > =3D=3D=3D=3D=3D=3D > =20 >=20 > On Fri, Jun 21, 2013 at 9:36 PM, Seil Jeon wrote: > Hi, Anthony and all, >=20 > =20 >=20 > Actually, when it comes to reviewing BJ's comment, it seems touching very= fundamental statement by mentioning the need of IP layer mobility support = for multicast session (if needed), though this requirement itself has impli= citly included it. But it's ok to me. >=20 > =20 >=20 > @Jouni, we respond to the ticket #22 as well. >=20 > As you know, we have tried to identify and discuss the meaning of flexibl= e distribution in the list. If we unfold the meaning hidden in the abstract= words, it would be fit to what you said. But the reworded sentences were m= ostly copied from =93Motivation=94 paragraph and arranged. Overall, the Mot= ivation was reworded. >=20 > =20 >=20 > By taking into account two comments, the revised text is as follows. >=20 > =20 >=20 > REQ7: DMM SHOULD consider multicast early so that solutions can >=20 > be developed not only to provide IP mobility to keep IP multicast session= s when it is needed, but to avoid network inefficiency issues in multicast > traffic delivery (such as duplicate multicast subscriptions > towards the downstream tunnel entitiesy). The multicast solutions > should therefore avoid restricting the management of all IP > multicast traffic to a single host through a dedicated > (tunnel) interface on multicast-capable access routers. >=20 > Motivation: Existing multicast deployment have been introduced after comp= leting the design of the reference mobility protocol, then optimization and= extensions have been followed, by =93patching-up=94 procedure, thus leadin= g to network inefficiency and non-optimal routing. The multicast solutions = should therefore be required to consider efficiency nature in multicast tra= ffic delivery. >=20 > =20 >=20 > p.s. @Jouni, I remember #33 ticket was resolved by answering Charlie=92s = comment. Check it, please. >=20 > =20 >=20 > =20 >=20 > Regards, >=20 > Seil >=20 > =20 >=20 > =20 >=20 > -----Original Message----- > From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of h c= han > Sent: Friday, June 21, 2013 1:26 AM > To: Jouni Korhonen; dmm@ietf.org; KIM, BYOUNG-JO J (BYOUNG-JO > Cc: Jong-Hyouk Lee > Subject: Re: [DMM] requirements and the security considerations > =20 >=20 > Seil or Sergio, >=20 > Can you reply to the following: >=20 > =20 >=20 > The comments from Byoung-Jo Kim to REQ7 in version 4 is as follows: >=20 > =20 >=20 > I suggest to drop this requirement or make a clearer statement like "DMM = should allow multicast to survive IP layer mobility without packet loss", o= r more modestly, "DMM should not foreclose multicast support during IP laye= r mobility.", etc.. >=20 > =20 >=20 > =20 >=20 > His suggested text is to replace REQ7 with something like the following: >=20 > =20 >=20 > REQ7: DMM SHOULD enable multicast packet delivery during mobility eve= nts as needed. >=20 > =20 >=20 > H Anthony Chan >=20 > =20 >=20 > =20 >=20 > -----Original Message----- >=20 > From: h chan >=20 > Sent: Thursday, June 20, 2013 7:15 PM >=20 > To: 'Jouni Korhonen'; dmm@ietf.org; 'KIM, BYOUNG-JO J (BYOUNG-JO' >=20 > Cc: 'Jong-Hyouk Lee' >=20 > Subject: RE: [DMM] requirements and the security considerations >=20 > =20 >=20 > The comments from Byoung-Jo Kim to REQ6 and Section 6 in version 4 were t= he following: >=20 > There are too much text in the security REQ6 that are vague and too wide. >=20 > =20 >=20 > And Section 6. Security considerations should say "none", 'cause that's u= sually the section that discusses security considerations related to the dr= aft itself. Since this is a requirement draft, there is no such thing. >=20 > There is a separate requirement earlier to cover security issues due to D= MM. >=20 > =20 >=20 > REQ6: Security considerations >=20 > =20 >=20 > DMM protocol solutions MUST consider security risks introduced >=20 > by DMM into the network. Examples of such risks to be >=20 > considered may include authentication and authorization mechani= sms >=20 > that allow a mobile host/router to use the mobility >=20 > support provided by the DMM solution; redirecting traffic to >=20 > the wrong host when providing DMM support; signaling message >=20 > protection for authentication, integrity and confidentiality. >=20 > =20 >=20 > Motivation: Various attacks such as impersonation, denial of >=20 > service, man-in-the-middle attacks, and so on, may become newly >=20 > possible or easier to mount due to the introduction of DMM. Pr= oof >=20 > of possession of past and new IP addresses may be needed. >=20 > =20 >=20 > H Anthony Chan >=20 > =20 >=20 > =20 >=20 > -----Original Message----- >=20 > From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of Jou= ni Korhonen >=20 > Sent: Tuesday, June 18, 2013 2:40 AM >=20 > To: dmm@ietf.org >=20 > Subject: [DMM] requirements and the security considerations >=20 > =20 >=20 > >=20 > =20 >=20 > Folks, >=20 > =20 >=20 > I have been reading Section 6 Security Considerations: >=20 > =20 >=20 > It is necessary to provide sufficient defense against possible >=20 > security attacks, or to adopt existing security mechanisms and >=20 > protocols to provide sufficient security protections. For instance, >=20 > EAP-based authentication can be used for access network security, >=20 > while IPsec can be used for end-to-end security. >=20 > =20 >=20 > I think this text still deserves some tweaking. First, "provide sufficien= t defense against possible security attacks".. against whom? >=20 > =20 >=20 > Second, should the text say something that the DMM protocol itself must n= ot be usable as a tool to launch an attack by a malicious mobile node that = happens to know that it is attached to a network implementing DMM and knows= (somehow) how the DMM protocol functions? >=20 > =20 >=20 > - Jouni >=20 > _______________________________________________ >=20 > dmm mailing list >=20 > dmm@ietf.org >=20 > https://www.ietf.org/mailman/listinfo/dmm >=20 > _______________________________________________ >=20 > dmm mailing list >=20 > dmm@ietf.org >=20 > https://www.ietf.org/mailman/listinfo/dmm >=20 >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm >=20 >=20 >=20 > =20 > -- > RSM Department, TELECOM Bretagne, France > Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random > =20 > #email: jonghyouk (at) gmail (dot) com > #webpage: http://sites.google.com/site/hurryon/ From h.anthony.chan@huawei.com Mon Jul 29 09:31:13 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDDAC21E8090 for ; Mon, 29 Jul 2013 09:31:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LesBifusLwiV for ; Mon, 29 Jul 2013 09:31:00 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 501AB21F98AC for ; Mon, 29 Jul 2013 09:30:31 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATX10591; Mon, 29 Jul 2013 16:30:20 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 29 Jul 2013 17:29:11 +0100 Received: from SZXEML460-HUB.china.huawei.com (10.82.67.203) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 29 Jul 2013 17:29:16 +0100 Received: from szxeml557-mbx.china.huawei.com ([169.254.5.42]) by szxeml460-hub.china.huawei.com ([10.82.67.203]) with mapi id 14.01.0323.007; Tue, 30 Jul 2013 00:29:12 +0800 From: h chan To: "KIM, BYOUNG-JO J (BYOUNG-JO)" Thread-Topic: [DMM] requirements and the security considerations Thread-Index: Ac6McOa9RPjDJS9ISHW9TuoxALR06QABP+6g Date: Mon, 29 Jul 2013 16:29:11 +0000 Message-ID: <6E31144C030982429702B11D6746B98C37095120@szxeml557-mbx.china.huawei.com> References: <6E31144C030982429702B11D6746B98C370928A2@szxeml557-mbx.china.huawei.com> <000301ce6e7c$063bb760$12b32620$@av.it.pt> <6E31144C030982429702B11D6746B98C37095087@szxeml557-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.200.216.96] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dmm@ietf.org" Subject: Re: [DMM] requirements and the security considerations X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 16:31:14 -0000 When you say the DMM requirements should only be on the risks added or ampl= ified by DMM, my understanding is that such increased risks depend on the s= pecific DMM solution.=20 Then as I read the last sentence of the text from Jong Hyeouk: Existing security mechanisms/protocols MAY be possible to provide sufficien= t security protections to DMM. For instance, EAP-based authentication can b= e used for network access security, while IPsec can be used for end-to-end = security. Note that when the existing security mechanisms/protocols are app= lied to DMM, security risks that MAY be introduced by DMM MUST be considere= d to be eliminated. If I understand your intention correctly, one way to spell the requirement = on the DMM solution may be that the DMM solution MUST not introduce new ris= ks or amplify the existing risks in a manner that cannot be handled with th= e existing security mechanisms/protocols. If we rephrase the requirement so= mething along this line, does not capture your concern? The rest of the tex= t from Jong-Heouk (access network to DMM etc.) can be modified so as to sim= ply examples of these existing risks as well as some existing security meas= ures. The requirement is only not to introduce new risks other than these e= xisting ones.=20 If it is okay, the next question is whether we allow solution that does inc= rease/introduce more risks. If so, they must also provide the security meas= ures to handle them. I don't know whether we should allow this or not thoug= h.=20 H Anthony Chan -----Original Message----- From: KIM, BYOUNG-JO J (BYOUNG-JO) [mailto:macsbug@research.att.com]=20 Sent: Monday, July 29, 2013 5:33 PM To: h chan Cc: dmm@ietf.org; Jouni Korhonen Subject: Re: [DMM] requirements and the security considerations I suppose this is still related to my ticket #29 and now closed #27. http://trac.tools.ietf.org/wg/dmm/trac/ticket/29 As I commented there, REQ6 should concern only to risked added or amplified= by DMM. The new proposed text still talks about access network security which is a = separate issue, unless it means something else than commonly understood: ge= tting on the network.. which is not DMM's concern. As an optimization, DMM security and access network security can be tied, b= ut I don't think we are that far along yet. Also, End2End security is commonly understood as btw MN and CN, while here = I believe the authors mean MN and DMM entities in the network. Even then, f= ull IPsec may be overkill (with its mutual auth and all) and ephemeral secu= rity may be good enough to protect the service and the network. e.g., It states.. "Accordingly, security mechanisms/protocols providing acc= ess control, integrity, authentication, authorization, confidentiality, etc= . MUST be required to protect DMM" We cannot MUST "etc.", but that's just minor quibble. Access control/Authorization can be implicit, e.g., " if allowed on the net= work, you can use DMM" Authentication can be just to ensure the same MN is asking packet redirecti= on, without knowing identity. In short, security risks added or amplified by DMM can be discussed when we= have protocol specifics. There are too much specific countermeasures here = whose applicability is unknowable at this point. Bests. J. AT&T Labs - Research http://sites.google.com/site/macsbug/ On Jul 29, 2013, at 8:37 AM, h chan wrote: > Byoung-Jo, > Are you okay with the revised text for REQ6 provided by Jong-Hyouk? > =20 > H Anthony Chan > =20 > From: Jong-Hyouk Lee [mailto:jonghyouk@gmail.com] > Sent: Saturday, June 22, 2013 6:17 PM > To: dmm@ietf.org; h chan > Cc: Jouni Korhonen > Subject: Re: [DMM] requirements and the security considerations > =20 > Hi all, > =20 > Here is text for security. Apologize for being late, Anthony. > =20 > =3D=3D=3D=3D=3D=3D > 5.6. Security > =20 > REQ6: DMM MUST be protected by security mechanisms/protocols in terms of = network access security and end-to-end security. Network access security is= required between the mobile host/router and the access network deploying D= MM, to allow only a legitimate mobile host/router to use DMM. End-to-end se= curity is required between nodes that participate in DMM, to protect DMM si= gnaling messages. Existing security mechanisms/protocols MAY be possible to= provide sufficient security protections to DMM. For instance, EAP-based au= thentication can be used for network access security, while IPsec can be us= ed for end-to-end security. Note that when the existing security mechanisms= /protocols are applied to DMM, security risks that MAY be introduced by DMM= MUST be considered to be eliminated.=20 > =20 > A security mechanism/protocol that provides proof of possession of past a= nd new IP addresses of a mobile host/router MAY be needed. > =20 > Motivation: Various attacks such as impersonation, denial of service, man= -in-the-middle attacks, and so on, MAY be launched against DMM. Accordingly= , security mechanisms/protocols providing access control, integrity, authen= tication, authorization, confidentiality, etc. MUST be required to protect = DMM. For instance, an illegitimate node attempts to access a network provid= ing DMM. Another example is that a malicious node can forge a number of sig= naling messages thus redirecting traffic from its legitimate path. Conseque= ntly, the specific node is under a denial of service attack, whereas other = nodes do not receive their traffic. As signaling messages MAY travel over t= he Internet, the end-to-end security between communicating nodes MUST be re= quired. > =20 > This requirement addresses the problems of potentially insecure=20 > mobility management protocols which make deployment infeasible because=20 > platforms conforming to the protocols are at risk for data loss and=20 > numerous other dangers, including financial harm to users. (I leave it=20 > to be modified or improved by Anthony) > =20 > 6. Security Considerations > (Now I do not think we need to put text here) =3D=3D=3D=3D=3D=3D > =20 >=20 > On Fri, Jun 21, 2013 at 9:36 PM, Seil Jeon wrote: > Hi, Anthony and all, >=20 > =20 >=20 > Actually, when it comes to reviewing BJ's comment, it seems touching very= fundamental statement by mentioning the need of IP layer mobility support = for multicast session (if needed), though this requirement itself has impli= citly included it. But it's ok to me. >=20 > =20 >=20 > @Jouni, we respond to the ticket #22 as well. >=20 > As you know, we have tried to identify and discuss the meaning of flexibl= e distribution in the list. If we unfold the meaning hidden in the abstract= words, it would be fit to what you said. But the reworded sentences were m= ostly copied from "Motivation" paragraph and arranged. Overall, the Motivat= ion was reworded. >=20 > =20 >=20 > By taking into account two comments, the revised text is as follows. >=20 > =20 >=20 > REQ7: DMM SHOULD consider multicast early so that solutions can >=20 > be developed not only to provide IP mobility to keep IP multicast=20 > sessions when it is needed, but to avoid network inefficiency issues=20 > in multicast traffic delivery (such as duplicate multicast=20 > subscriptions towards the downstream tunnel entitiesy). The multicast=20 > solutions should therefore avoid restricting the management of all IP=20 > multicast traffic to a single host through a dedicated > (tunnel) interface on multicast-capable access routers. >=20 > Motivation: Existing multicast deployment have been introduced after comp= leting the design of the reference mobility protocol, then optimization and= extensions have been followed, by "patching-up" procedure, thus leading to= network inefficiency and non-optimal routing. The multicast solutions shou= ld therefore be required to consider efficiency nature in multicast traffic= delivery. >=20 > =20 >=20 > p.s. @Jouni, I remember #33 ticket was resolved by answering Charlie's co= mment. Check it, please. >=20 > =20 >=20 > =20 >=20 > Regards, >=20 > Seil >=20 > =20 >=20 > =20 >=20 > -----Original Message----- > From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of=20 > h chan > Sent: Friday, June 21, 2013 1:26 AM > To: Jouni Korhonen; dmm@ietf.org; KIM, BYOUNG-JO J (BYOUNG-JO > Cc: Jong-Hyouk Lee > Subject: Re: [DMM] requirements and the security considerations > =20 >=20 > Seil or Sergio, >=20 > Can you reply to the following: >=20 > =20 >=20 > The comments from Byoung-Jo Kim to REQ7 in version 4 is as follows: >=20 > =20 >=20 > I suggest to drop this requirement or make a clearer statement like "DMM = should allow multicast to survive IP layer mobility without packet loss", o= r more modestly, "DMM should not foreclose multicast support during IP laye= r mobility.", etc.. >=20 > =20 >=20 > =20 >=20 > His suggested text is to replace REQ7 with something like the following: >=20 > =20 >=20 > REQ7: DMM SHOULD enable multicast packet delivery during mobility eve= nts as needed. >=20 > =20 >=20 > H Anthony Chan >=20 > =20 >=20 > =20 >=20 > -----Original Message----- >=20 > From: h chan >=20 > Sent: Thursday, June 20, 2013 7:15 PM >=20 > To: 'Jouni Korhonen'; dmm@ietf.org; 'KIM, BYOUNG-JO J (BYOUNG-JO' >=20 > Cc: 'Jong-Hyouk Lee' >=20 > Subject: RE: [DMM] requirements and the security considerations >=20 > =20 >=20 > The comments from Byoung-Jo Kim to REQ6 and Section 6 in version 4 were t= he following: >=20 > There are too much text in the security REQ6 that are vague and too wide. >=20 > =20 >=20 > And Section 6. Security considerations should say "none", 'cause that's u= sually the section that discusses security considerations related to the dr= aft itself. Since this is a requirement draft, there is no such thing. >=20 > There is a separate requirement earlier to cover security issues due to D= MM. >=20 > =20 >=20 > REQ6: Security considerations >=20 > =20 >=20 > DMM protocol solutions MUST consider security risks=20 > introduced >=20 > by DMM into the network. Examples of such risks to be >=20 > considered may include authentication and authorization=20 > mechanisms >=20 > that allow a mobile host/router to use the mobility >=20 > support provided by the DMM solution; redirecting traffic to >=20 > the wrong host when providing DMM support; signaling message >=20 > protection for authentication, integrity and confidentiality. >=20 > =20 >=20 > Motivation: Various attacks such as impersonation, denial of >=20 > service, man-in-the-middle attacks, and so on, may become=20 > newly >=20 > possible or easier to mount due to the introduction of DMM. =20 > Proof >=20 > of possession of past and new IP addresses may be needed. >=20 > =20 >=20 > H Anthony Chan >=20 > =20 >=20 > =20 >=20 > -----Original Message----- >=20 > From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of=20 > Jouni Korhonen >=20 > Sent: Tuesday, June 18, 2013 2:40 AM >=20 > To: dmm@ietf.org >=20 > Subject: [DMM] requirements and the security considerations >=20 > =20 >=20 > >=20 > =20 >=20 > Folks, >=20 > =20 >=20 > I have been reading Section 6 Security Considerations: >=20 > =20 >=20 > It is necessary to provide sufficient defense against possible >=20 > security attacks, or to adopt existing security mechanisms and >=20 > protocols to provide sufficient security protections. For=20 > instance, >=20 > EAP-based authentication can be used for access network security, >=20 > while IPsec can be used for end-to-end security. >=20 > =20 >=20 > I think this text still deserves some tweaking. First, "provide sufficien= t defense against possible security attacks".. against whom? >=20 > =20 >=20 > Second, should the text say something that the DMM protocol itself must n= ot be usable as a tool to launch an attack by a malicious mobile node that = happens to know that it is attached to a network implementing DMM and knows= (somehow) how the DMM protocol functions? >=20 > =20 >=20 > - Jouni >=20 > _______________________________________________ >=20 > dmm mailing list >=20 > dmm@ietf.org >=20 > https://www.ietf.org/mailman/listinfo/dmm >=20 > _______________________________________________ >=20 > dmm mailing list >=20 > dmm@ietf.org >=20 > https://www.ietf.org/mailman/listinfo/dmm >=20 >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm >=20 >=20 >=20 > =20 > -- > RSM Department, TELECOM Bretagne, France Jong-Hyouk Lee, living=20 > somewhere between /dev/null and /dev/random > =20 > #email: jonghyouk (at) gmail (dot) com > #webpage: http://sites.google.com/site/hurryon/ From h.anthony.chan@huawei.com Mon Jul 29 10:53:02 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15CF021E8092 for ; Mon, 29 Jul 2013 10:53:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GXjjLXvn-5Ow for ; Mon, 29 Jul 2013 10:52:54 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id A0FE721E8086 for ; Mon, 29 Jul 2013 10:52:53 -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.5-GA FastPath queued) with ESMTP id AVN65206; Mon, 29 Jul 2013 17:52:52 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 29 Jul 2013 18:52:45 +0100 Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Mon, 29 Jul 2013 18:52:49 +0100 Received: from szxeml557-mbx.china.huawei.com ([169.254.5.42]) by szxeml420-hub.china.huawei.com ([10.82.67.159]) with mapi id 14.01.0323.007; Tue, 30 Jul 2013 01:52:43 +0800 From: h chan To: "KIM, BYOUNG-JO J (BYOUNG-JO)" Thread-Topic: [DMM] requirements and the security considerations Thread-Index: Ac6McOa9RPjDJS9ISHW9TuoxALR06QABP+6gAAJ1GNA= Date: Mon, 29 Jul 2013 17:52:43 +0000 Message-ID: <6E31144C030982429702B11D6746B98C37095159@szxeml557-mbx.china.huawei.com> References: <6E31144C030982429702B11D6746B98C370928A2@szxeml557-mbx.china.huawei.com> <000301ce6e7c$063bb760$12b32620$@av.it.pt> <6E31144C030982429702B11D6746B98C37095087@szxeml557-mbx.china.huawei.com> <6E31144C030982429702B11D6746B98C37095120@szxeml557-mbx.china.huawei.com> In-Reply-To: <6E31144C030982429702B11D6746B98C37095120@szxeml557-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.131.97] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dmm@ietf.org" Subject: Re: [DMM] requirements and the security considerations X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 17:53:02 -0000 Byoung-Jo, Let me try to phrase your comment into the security requirement as follows.= Please check and feel free to correct.=20 REQ6: Security considerations A DMM solution MUST not introduce new security risks or amplified existing = security risks against which the existing security mechanisms/protocols can= not offer sufficient protection.=20 Motivation:=20 Various attacks such as impersonation, denial of service, man-in-the-middle= attacks, and so on, may be launched in a DMM deployment. For instance, an = illegitimate node may attempt to access a network providing DMM. Another ex= ample is that a malicious node can forge a number of signaling messages thu= s redirecting traffic from its legitimate path. Consequently, the specific= node is under a denial of service attack, whereas other nodes do not recei= ve their traffic.=20 Accordingly, security mechanisms/protocols providing access control, integr= ity, authentication, authorization, confidentiality, etc. can be used to pr= otect the DMM entities as they are already used to protect against existing= networks and existing mobility protocols defined in IETF. In addition, end= -to-end security measures between communicating nodes may already be used w= hen deploying existing mobility protocols where the signaling messages trav= el over the Internet. For instance, EAP-based authentication can be used fo= r network access security, while IPsec can be used for end-to-end security.= When these existing security mechanisms/protocols are applied to protect t= he DMM entities, the security risks that May be introduced by DMM MUST be c= onsidered to be eliminated. Else the security protection would be degraded = in DMM versus in existing mobility protocols.=20 This requirement prevents a DMM solution to introduce uncontrollable proble= ms of potentially insecure mobility management protocols which make deploym= ent infeasible because platforms conforming to the protocols are at risk fo= r data loss and numerous other dangers, including financial harm to users.= =20 H Anthony Chan -----Original Message----- From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of h cha= n Sent: Monday, July 29, 2013 6:29 PM To: KIM, BYOUNG-JO J (BYOUNG-JO) Cc: dmm@ietf.org Subject: Re: [DMM] requirements and the security considerations When you say the DMM requirements should only be on the risks added or ampl= ified by DMM, my understanding is that such increased risks depend on the s= pecific DMM solution.=20 Then as I read the last sentence of the text from Jong Hyeouk: Existing security mechanisms/protocols MAY be possible to provide sufficien= t security protections to DMM. For instance, EAP-based authentication can b= e used for network access security, while IPsec can be used for end-to-end = security. Note that when the existing security mechanisms/protocols are app= lied to DMM, security risks that MAY be introduced by DMM MUST be considere= d to be eliminated. If I understand your intention correctly, one way to spell the requirement = on the DMM solution may be that the DMM solution MUST not introduce new ris= ks or amplify the existing risks in a manner that cannot be handled with th= e existing security mechanisms/protocols. If we rephrase the requirement so= mething along this line, does not capture your concern? The rest of the tex= t from Jong-Heouk (access network to DMM etc.) can be modified so as to sim= ply examples of these existing risks as well as some existing security meas= ures. The requirement is only not to introduce new risks other than these e= xisting ones.=20 If it is okay, the next question is whether we allow solution that does inc= rease/introduce more risks. If so, they must also provide the security meas= ures to handle them. I don't know whether we should allow this or not thoug= h.=20 H Anthony Chan -----Original Message----- From: KIM, BYOUNG-JO J (BYOUNG-JO) [mailto:macsbug@research.att.com] Sent: Monday, July 29, 2013 5:33 PM To: h chan Cc: dmm@ietf.org; Jouni Korhonen Subject: Re: [DMM] requirements and the security considerations I suppose this is still related to my ticket #29 and now closed #27. http://trac.tools.ietf.org/wg/dmm/trac/ticket/29 As I commented there, REQ6 should concern only to risked added or amplified= by DMM. The new proposed text still talks about access network security which is a = separate issue, unless it means something else than commonly understood: ge= tting on the network.. which is not DMM's concern. As an optimization, DMM security and access network security can be tied, b= ut I don't think we are that far along yet. Also, End2End security is commonly understood as btw MN and CN, while here = I believe the authors mean MN and DMM entities in the network. Even then, f= ull IPsec may be overkill (with its mutual auth and all) and ephemeral secu= rity may be good enough to protect the service and the network. e.g., It states.. "Accordingly, security mechanisms/protocols providing acc= ess control, integrity, authentication, authorization, confidentiality, etc= . MUST be required to protect DMM" We cannot MUST "etc.", but that's just minor quibble. Access control/Authorization can be implicit, e.g., " if allowed on the net= work, you can use DMM" Authentication can be just to ensure the same MN is asking packet redirecti= on, without knowing identity. In short, security risks added or amplified by DMM can be discussed when we= have protocol specifics. There are too much specific countermeasures here = whose applicability is unknowable at this point. Bests. J. AT&T Labs - Research http://sites.google.com/site/macsbug/ On Jul 29, 2013, at 8:37 AM, h chan wrote: > Byoung-Jo, > Are you okay with the revised text for REQ6 provided by Jong-Hyouk? > =20 > H Anthony Chan > =20 > From: Jong-Hyouk Lee [mailto:jonghyouk@gmail.com] > Sent: Saturday, June 22, 2013 6:17 PM > To: dmm@ietf.org; h chan > Cc: Jouni Korhonen > Subject: Re: [DMM] requirements and the security considerations > =20 > Hi all, > =20 > Here is text for security. Apologize for being late, Anthony. > =20 > =3D=3D=3D=3D=3D=3D > 5.6. Security > =20 > REQ6: DMM MUST be protected by security mechanisms/protocols in terms of = network access security and end-to-end security. Network access security is= required between the mobile host/router and the access network deploying D= MM, to allow only a legitimate mobile host/router to use DMM. End-to-end se= curity is required between nodes that participate in DMM, to protect DMM si= gnaling messages. Existing security mechanisms/protocols MAY be possible to= provide sufficient security protections to DMM. For instance, EAP-based au= thentication can be used for network access security, while IPsec can be us= ed for end-to-end security. Note that when the existing security mechanisms= /protocols are applied to DMM, security risks that MAY be introduced by DMM= MUST be considered to be eliminated.=20 > =20 > A security mechanism/protocol that provides proof of possession of past a= nd new IP addresses of a mobile host/router MAY be needed. > =20 > Motivation: Various attacks such as impersonation, denial of service, man= -in-the-middle attacks, and so on, MAY be launched against DMM. Accordingly= , security mechanisms/protocols providing access control, integrity, authen= tication, authorization, confidentiality, etc. MUST be required to protect = DMM. For instance, an illegitimate node attempts to access a network provid= ing DMM. Another example is that a malicious node can forge a number of sig= naling messages thus redirecting traffic from its legitimate path. Conseque= ntly, the specific node is under a denial of service attack, whereas other = nodes do not receive their traffic. As signaling messages MAY travel over t= he Internet, the end-to-end security between communicating nodes MUST be re= quired. > =20 > This requirement addresses the problems of potentially insecure=20 > mobility management protocols which make deployment infeasible because=20 > platforms conforming to the protocols are at risk for data loss and=20 > numerous other dangers, including financial harm to users. (I leave it=20 > to be modified or improved by Anthony) > =20 > 6. Security Considerations > (Now I do not think we need to put text here) =3D=3D=3D=3D=3D=3D > =20 >=20 > On Fri, Jun 21, 2013 at 9:36 PM, Seil Jeon wrote: > Hi, Anthony and all, >=20 > =20 >=20 > Actually, when it comes to reviewing BJ's comment, it seems touching very= fundamental statement by mentioning the need of IP layer mobility support = for multicast session (if needed), though this requirement itself has impli= citly included it. But it's ok to me. >=20 > =20 >=20 > @Jouni, we respond to the ticket #22 as well. >=20 > As you know, we have tried to identify and discuss the meaning of flexibl= e distribution in the list. If we unfold the meaning hidden in the abstract= words, it would be fit to what you said. But the reworded sentences were m= ostly copied from "Motivation" paragraph and arranged. Overall, the Motivat= ion was reworded. >=20 > =20 >=20 > By taking into account two comments, the revised text is as follows. >=20 > =20 >=20 > REQ7: DMM SHOULD consider multicast early so that solutions can >=20 > be developed not only to provide IP mobility to keep IP multicast=20 > sessions when it is needed, but to avoid network inefficiency issues=20 > in multicast traffic delivery (such as duplicate multicast=20 > subscriptions towards the downstream tunnel entitiesy). The multicast=20 > solutions should therefore avoid restricting the management of all IP=20 > multicast traffic to a single host through a dedicated > (tunnel) interface on multicast-capable access routers. >=20 > Motivation: Existing multicast deployment have been introduced after comp= leting the design of the reference mobility protocol, then optimization and= extensions have been followed, by "patching-up" procedure, thus leading to= network inefficiency and non-optimal routing. The multicast solutions shou= ld therefore be required to consider efficiency nature in multicast traffic= delivery. >=20 > =20 >=20 > p.s. @Jouni, I remember #33 ticket was resolved by answering Charlie's co= mment. Check it, please. >=20 > =20 >=20 > =20 >=20 > Regards, >=20 > Seil >=20 > =20 >=20 > =20 >=20 > -----Original Message----- > From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of=20 > h chan > Sent: Friday, June 21, 2013 1:26 AM > To: Jouni Korhonen; dmm@ietf.org; KIM, BYOUNG-JO J (BYOUNG-JO > Cc: Jong-Hyouk Lee > Subject: Re: [DMM] requirements and the security considerations > =20 >=20 > Seil or Sergio, >=20 > Can you reply to the following: >=20 > =20 >=20 > The comments from Byoung-Jo Kim to REQ7 in version 4 is as follows: >=20 > =20 >=20 > I suggest to drop this requirement or make a clearer statement like "DMM = should allow multicast to survive IP layer mobility without packet loss", o= r more modestly, "DMM should not foreclose multicast support during IP laye= r mobility.", etc.. >=20 > =20 >=20 > =20 >=20 > His suggested text is to replace REQ7 with something like the following: >=20 > =20 >=20 > REQ7: DMM SHOULD enable multicast packet delivery during mobility eve= nts as needed. >=20 > =20 >=20 > H Anthony Chan >=20 > =20 >=20 > =20 >=20 > -----Original Message----- >=20 > From: h chan >=20 > Sent: Thursday, June 20, 2013 7:15 PM >=20 > To: 'Jouni Korhonen'; dmm@ietf.org; 'KIM, BYOUNG-JO J (BYOUNG-JO' >=20 > Cc: 'Jong-Hyouk Lee' >=20 > Subject: RE: [DMM] requirements and the security considerations >=20 > =20 >=20 > The comments from Byoung-Jo Kim to REQ6 and Section 6 in version 4 were t= he following: >=20 > There are too much text in the security REQ6 that are vague and too wide. >=20 > =20 >=20 > And Section 6. Security considerations should say "none", 'cause that's u= sually the section that discusses security considerations related to the dr= aft itself. Since this is a requirement draft, there is no such thing. >=20 > There is a separate requirement earlier to cover security issues due to D= MM. >=20 > =20 >=20 > REQ6: Security considerations >=20 > =20 >=20 > DMM protocol solutions MUST consider security risks=20 > introduced >=20 > by DMM into the network. Examples of such risks to be >=20 > considered may include authentication and authorization=20 > mechanisms >=20 > that allow a mobile host/router to use the mobility >=20 > support provided by the DMM solution; redirecting traffic to >=20 > the wrong host when providing DMM support; signaling message >=20 > protection for authentication, integrity and confidentiality. >=20 > =20 >=20 > Motivation: Various attacks such as impersonation, denial of >=20 > service, man-in-the-middle attacks, and so on, may become=20 > newly >=20 > possible or easier to mount due to the introduction of DMM. =20 > Proof >=20 > of possession of past and new IP addresses may be needed. >=20 > =20 >=20 > H Anthony Chan >=20 > =20 >=20 > =20 >=20 > -----Original Message----- >=20 > From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of=20 > Jouni Korhonen >=20 > Sent: Tuesday, June 18, 2013 2:40 AM >=20 > To: dmm@ietf.org >=20 > Subject: [DMM] requirements and the security considerations >=20 > =20 >=20 > >=20 > =20 >=20 > Folks, >=20 > =20 >=20 > I have been reading Section 6 Security Considerations: >=20 > =20 >=20 > It is necessary to provide sufficient defense against possible >=20 > security attacks, or to adopt existing security mechanisms and >=20 > protocols to provide sufficient security protections. For=20 > instance, >=20 > EAP-based authentication can be used for access network security, >=20 > while IPsec can be used for end-to-end security. >=20 > =20 >=20 > I think this text still deserves some tweaking. First, "provide sufficien= t defense against possible security attacks".. against whom? >=20 > =20 >=20 > Second, should the text say something that the DMM protocol itself must n= ot be usable as a tool to launch an attack by a malicious mobile node that = happens to know that it is attached to a network implementing DMM and knows= (somehow) how the DMM protocol functions? >=20 > =20 >=20 > - Jouni >=20 > _______________________________________________ >=20 > dmm mailing list >=20 > dmm@ietf.org >=20 > https://www.ietf.org/mailman/listinfo/dmm >=20 > _______________________________________________ >=20 > dmm mailing list >=20 > dmm@ietf.org >=20 > https://www.ietf.org/mailman/listinfo/dmm >=20 >=20 > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm >=20 >=20 >=20 > =20 > -- > RSM Department, TELECOM Bretagne, France Jong-Hyouk Lee, living=20 > somewhere between /dev/null and /dev/random > =20 > #email: jonghyouk (at) gmail (dot) com > #webpage: http://sites.google.com/site/hurryon/ _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm From macsbug@research.att.com Mon Jul 29 11:17:50 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 00D1021E8097 for ; Mon, 29 Jul 2013 11:17:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tdsw+F5uEKzm for ; Mon, 29 Jul 2013 11:17:43 -0700 (PDT) Received: from mail-pink.research.att.com (mail-pink.research.att.com [192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id C3FA711E8119 for ; Mon, 29 Jul 2013 11:17:29 -0700 (PDT) Received: from mail-green.research.att.com (unknown [135.207.178.10]) by mail-pink.research.att.com (Postfix) with ESMTP id 41A5D1205B4; Mon, 29 Jul 2013 14:17:23 -0400 (EDT) Received: from njfpsrvexg7.research.att.com (njfpsrvexg7.research.att.com [135.207.177.33]) by mail-green.research.att.com (Postfix) with ESMTP id 49B1DE0182; Mon, 29 Jul 2013 14:16:54 -0400 (EDT) Received: from njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299]) by njfpsrvexg7.research.att.com ([fe80::3598:75fe:b400:9299%11]) with mapi; Mon, 29 Jul 2013 14:17:26 -0400 From: "KIM, BYOUNG-JO J (BYOUNG-JO)" To: h chan Date: Mon, 29 Jul 2013 14:17:25 -0400 Thread-Topic: [DMM] requirements and the security considerations Thread-Index: Ac6Mh+DPIpfir8ABTzCS5H/3WiamJw== Message-ID: <12B7B927-300C-4E5C-A287-8A100EB78F37@research.att.com> References: <6E31144C030982429702B11D6746B98C370928A2@szxeml557-mbx.china.huawei.com> <000301ce6e7c$063bb760$12b32620$@av.it.pt> <6E31144C030982429702B11D6746B98C37095087@szxeml557-mbx.china.huawei.com> <6E31144C030982429702B11D6746B98C37095120@szxeml557-mbx.china.huawei.com> <6E31144C030982429702B11D6746B98C37095159@szxeml557-mbx.china.huawei.com> In-Reply-To: <6E31144C030982429702B11D6746B98C37095159@szxeml557-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dmm@ietf.org" Subject: Re: [DMM] requirements and the security considerations X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jul 2013 18:17:50 -0000 Happy as a clam.. Will close the ticket. Best. J. p.s. a typo.. "amplify" instead of 'amplified'. On Jul 29, 2013, at 1:52 PM, h chan wrote: > Byoung-Jo, > Let me try to phrase your comment into the security requirement as follow= s. Please check and feel free to correct. > > REQ6: Security considerations > A DMM solution MUST not introduce new security risks or amplified existin= g security risks against which the existing security mechanisms/protocols c= annot offer sufficient protection. > > Motivation: > Various attacks such as impersonation, denial of service, man-in-the-midd= le attacks, and so on, may be launched in a DMM deployment. For instance, a= n illegitimate node may attempt to access a network providing DMM. Another = example is that a malicious node can forge a number of signaling messages t= hus redirecting traffic from its legitimate path. Consequently, the specif= ic node is under a denial of service attack, whereas other nodes do not rec= eive their traffic. > Accordingly, security mechanisms/protocols providing access control, inte= grity, authentication, authorization, confidentiality, etc. can be used to = protect the DMM entities as they are already used to protect against existi= ng networks and existing mobility protocols defined in IETF. In addition, e= nd-to-end security measures between communicating nodes may already be used= when deploying existing mobility protocols where the signaling messages tr= avel over the Internet. For instance, EAP-based authentication can be used = for network access security, while IPsec can be used for end-to-end securit= y. When these existing security mechanisms/protocols are applied to protect= the DMM entities, the security risks that May be introduced by DMM MUST be= considered to be eliminated. Else the security protection would be degrade= d in DMM versus in existing mobility protocols. > > This requirement prevents a DMM solution to introduce uncontrollable prob= lems of potentially insecure mobility management protocols which make deplo= yment infeasible because platforms conforming to the protocols are at risk = for data loss and numerous other dangers, including financial harm to users= . > > H Anthony Chan > > -----Original Message----- > From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of h c= han > Sent: Monday, July 29, 2013 6:29 PM > To: KIM, BYOUNG-JO J (BYOUNG-JO) > Cc: dmm@ietf.org > Subject: Re: [DMM] requirements and the security considerations > > When you say the DMM requirements should only be on the risks added or am= plified by DMM, my understanding is that such increased risks depend on the= specific DMM solution. > > Then as I read the last sentence of the text from Jong Hyeouk: > Existing security mechanisms/protocols MAY be possible to provide suffici= ent security protections to DMM. For instance, EAP-based authentication can= be used for network access security, while IPsec can be used for end-to-en= d security. Note that when the existing security mechanisms/protocols are a= pplied to DMM, security risks that MAY be introduced by DMM MUST be conside= red to be eliminated. > > If I understand your intention correctly, one way to spell the requiremen= t on the DMM solution may be that the DMM solution MUST not introduce new r= isks or amplify the existing risks in a manner that cannot be handled with = the existing security mechanisms/protocols. If we rephrase the requirement = something along this line, does not capture your concern? The rest of the t= ext from Jong-Heouk (access network to DMM etc.) can be modified so as to s= imply examples of these existing risks as well as some existing security me= asures. The requirement is only not to introduce new risks other than these= existing ones. > > If it is okay, the next question is whether we allow solution that does i= ncrease/introduce more risks. If so, they must also provide the security me= asures to handle them. I don't know whether we should allow this or not tho= ugh. > > H Anthony Chan > > > -----Original Message----- > From: KIM, BYOUNG-JO J (BYOUNG-JO) [mailto:macsbug@research.att.com] > Sent: Monday, July 29, 2013 5:33 PM > To: h chan > Cc: dmm@ietf.org; Jouni Korhonen > Subject: Re: [DMM] requirements and the security considerations > > I suppose this is still related to my ticket #29 and now closed #27. > http://trac.tools.ietf.org/wg/dmm/trac/ticket/29 > > As I commented there, REQ6 should concern only to risked added or amplifi= ed by DMM. > > The new proposed text still talks about access network security which is = a separate issue, unless it means something else than commonly understood: = getting on the network.. which is not DMM's concern. > As an optimization, DMM security and access network security can be tied,= but I don't think we are that far along yet. > > Also, End2End security is commonly understood as btw MN and CN, while her= e I believe the authors mean MN and DMM entities in the network. Even then,= full IPsec may be overkill (with its mutual auth and all) and ephemeral se= curity may be good enough to protect the service and the network. > > e.g., It states.. "Accordingly, security mechanisms/protocols providing a= ccess control, integrity, authentication, authorization, confidentiality, e= tc. MUST be required to protect DMM" > > We cannot MUST "etc.", but that's just minor quibble. > Access control/Authorization can be implicit, e.g., " if allowed on the n= etwork, you can use DMM" > Authentication can be just to ensure the same MN is asking packet redirec= tion, without knowing identity. > > In short, security risks added or amplified by DMM can be discussed when = we have protocol specifics. There are too much specific countermeasures her= e whose applicability is unknowable at this point. > > Bests. > > J. > AT&T Labs - Research > http://sites.google.com/site/macsbug/ > > On Jul 29, 2013, at 8:37 AM, h chan wrote: > >> Byoung-Jo, >> Are you okay with the revised text for REQ6 provided by Jong-Hyouk? >> >> H Anthony Chan >> >> From: Jong-Hyouk Lee [mailto:jonghyouk@gmail.com] >> Sent: Saturday, June 22, 2013 6:17 PM >> To: dmm@ietf.org; h chan >> Cc: Jouni Korhonen >> Subject: Re: [DMM] requirements and the security considerations >> >> Hi all, >> >> Here is text for security. Apologize for being late, Anthony. >> >> =3D=3D=3D=3D=3D=3D >> 5.6. Security >> >> REQ6: DMM MUST be protected by security mechanisms/protocols in terms of= network access security and end-to-end security. Network access security i= s required between the mobile host/router and the access network deploying = DMM, to allow only a legitimate mobile host/router to use DMM. End-to-end s= ecurity is required between nodes that participate in DMM, to protect DMM s= ignaling messages. Existing security mechanisms/protocols MAY be possible t= o provide sufficient security protections to DMM. For instance, EAP-based a= uthentication can be used for network access security, while IPsec can be u= sed for end-to-end security. Note that when the existing security mechanism= s/protocols are applied to DMM, security risks that MAY be introduced by DM= M MUST be considered to be eliminated. >> >> A security mechanism/protocol that provides proof of possession of past = and new IP addresses of a mobile host/router MAY be needed. >> >> Motivation: Various attacks such as impersonation, denial of service, ma= n-in-the-middle attacks, and so on, MAY be launched against DMM. Accordingl= y, security mechanisms/protocols providing access control, integrity, authe= ntication, authorization, confidentiality, etc. MUST be required to protect= DMM. For instance, an illegitimate node attempts to access a network provi= ding DMM. Another example is that a malicious node can forge a number of si= gnaling messages thus redirecting traffic from its legitimate path. Consequ= ently, the specific node is under a denial of service attack, whereas other= nodes do not receive their traffic. As signaling messages MAY travel over = the Internet, the end-to-end security between communicating nodes MUST be r= equired. >> >> This requirement addresses the problems of potentially insecure >> mobility management protocols which make deployment infeasible because >> platforms conforming to the protocols are at risk for data loss and >> numerous other dangers, including financial harm to users. (I leave it >> to be modified or improved by Anthony) >> >> 6. Security Considerations >> (Now I do not think we need to put text here) =3D=3D=3D=3D=3D=3D >> >> >> On Fri, Jun 21, 2013 at 9:36 PM, Seil Jeon wrote: >> Hi, Anthony and all, >> >> >> >> Actually, when it comes to reviewing BJ's comment, it seems touching ver= y fundamental statement by mentioning the need of IP layer mobility support= for multicast session (if needed), though this requirement itself has impl= icitly included it. But it's ok to me. >> >> >> >> @Jouni, we respond to the ticket #22 as well. >> >> As you know, we have tried to identify and discuss the meaning of flexib= le distribution in the list. If we unfold the meaning hidden in the abstrac= t words, it would be fit to what you said. But the reworded sentences were = mostly copied from "Motivation" paragraph and arranged. Overall, the Motiva= tion was reworded. >> >> >> >> By taking into account two comments, the revised text is as follows. >> >> >> >> REQ7: DMM SHOULD consider multicast early so that solutions can >> >> be developed not only to provide IP mobility to keep IP multicast >> sessions when it is needed, but to avoid network inefficiency issues >> in multicast traffic delivery (such as duplicate multicast >> subscriptions towards the downstream tunnel entitiesy). The multicast >> solutions should therefore avoid restricting the management of all IP >> multicast traffic to a single host through a dedicated >> (tunnel) interface on multicast-capable access routers. >> >> Motivation: Existing multicast deployment have been introduced after com= pleting the design of the reference mobility protocol, then optimization an= d extensions have been followed, by "patching-up" procedure, thus leading t= o network inefficiency and non-optimal routing. The multicast solutions sho= uld therefore be required to consider efficiency nature in multicast traffi= c delivery. >> >> >> >> p.s. @Jouni, I remember #33 ticket was resolved by answering Charlie's c= omment. Check it, please. >> >> >> >> >> >> Regards, >> >> Seil >> >> >> >> >> >> -----Original Message----- >> From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of >> h chan >> Sent: Friday, June 21, 2013 1:26 AM >> To: Jouni Korhonen; dmm@ietf.org; KIM, BYOUNG-JO J (BYOUNG-JO >> Cc: Jong-Hyouk Lee >> Subject: Re: [DMM] requirements and the security considerations >> >> >> Seil or Sergio, >> >> Can you reply to the following: >> >> >> >> The comments from Byoung-Jo Kim to REQ7 in version 4 is as follows: >> >> >> >> I suggest to drop this requirement or make a clearer statement like "DMM= should allow multicast to survive IP layer mobility without packet loss", = or more modestly, "DMM should not foreclose multicast support during IP lay= er mobility.", etc.. >> >> >> >> >> >> His suggested text is to replace REQ7 with something like the following: >> >> >> >> REQ7: DMM SHOULD enable multicast packet delivery during mobility eve= nts as needed. >> >> >> >> H Anthony Chan >> >> >> >> >> >> -----Original Message----- >> >> From: h chan >> >> Sent: Thursday, June 20, 2013 7:15 PM >> >> To: 'Jouni Korhonen'; dmm@ietf.org; 'KIM, BYOUNG-JO J (BYOUNG-JO' >> >> Cc: 'Jong-Hyouk Lee' >> >> Subject: RE: [DMM] requirements and the security considerations >> >> >> >> The comments from Byoung-Jo Kim to REQ6 and Section 6 in version 4 were = the following: >> >> There are too much text in the security REQ6 that are vague and too wide= . >> >> >> >> And Section 6. Security considerations should say "none", 'cause that's = usually the section that discusses security considerations related to the d= raft itself. Since this is a requirement draft, there is no such thing. >> >> There is a separate requirement earlier to cover security issues due to = DMM. >> >> >> >> REQ6: Security considerations >> >> >> >> DMM protocol solutions MUST consider security risks >> introduced >> >> by DMM into the network. Examples of such risks to be >> >> considered may include authentication and authorization >> mechanisms >> >> that allow a mobile host/router to use the mobility >> >> support provided by the DMM solution; redirecting traffic to >> >> the wrong host when providing DMM support; signaling message >> >> protection for authentication, integrity and confidentiality. >> >> >> >> Motivation: Various attacks such as impersonation, denial of >> >> service, man-in-the-middle attacks, and so on, may become >> newly >> >> possible or easier to mount due to the introduction of DMM. >> Proof >> >> of possession of past and new IP addresses may be needed. >> >> >> >> H Anthony Chan >> >> >> >> >> >> -----Original Message----- >> >> From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of >> Jouni Korhonen >> >> Sent: Tuesday, June 18, 2013 2:40 AM >> >> To: dmm@ietf.org >> >> Subject: [DMM] requirements and the security considerations >> >> >> >> >> >> >> >> Folks, >> >> >> >> I have been reading Section 6 Security Considerations: >> >> >> >> It is necessary to provide sufficient defense against possible >> >> security attacks, or to adopt existing security mechanisms and >> >> protocols to provide sufficient security protections. For >> instance, >> >> EAP-based authentication can be used for access network security, >> >> while IPsec can be used for end-to-end security. >> >> >> >> I think this text still deserves some tweaking. First, "provide sufficie= nt defense against possible security attacks".. against whom? >> >> >> >> Second, should the text say something that the DMM protocol itself must = not be usable as a tool to launch an attack by a malicious mobile node that= happens to know that it is attached to a network implementing DMM and know= s (somehow) how the DMM protocol functions? >> >> >> >> - 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 >> >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >> >> >> >> >> -- >> RSM Department, TELECOM Bretagne, France Jong-Hyouk Lee, living >> somewhere between /dev/null and /dev/random >> >> #email: jonghyouk (at) gmail (dot) com >> #webpage: http://sites.google.com/site/hurryon/ > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From maxpassion@gmail.com Tue Jul 30 01:46:11 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52D2721E80BF for ; Tue, 30 Jul 2013 01:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id szc87wvDp7fw for ; Tue, 30 Jul 2013 01:46:09 -0700 (PDT) Received: from mail-vb0-x231.google.com (mail-vb0-x231.google.com [IPv6:2607:f8b0:400c:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 5AE6E21F9C40 for ; Tue, 30 Jul 2013 01:45:20 -0700 (PDT) Received: by mail-vb0-f49.google.com with SMTP id w15so3501148vbb.8 for ; Tue, 30 Jul 2013 01:45:19 -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=BwQooBinr6Ws6ikTU6XSzCF0+fg27VKEkqLISTqe5qk=; b=RBO4irZO58BOB9L8pGVJtaDwvSuSbo4Er0qNF7DgpHOpncpu4BR6tQsjX5dWSgXeh3 b1omidmfCXUCIdWuaDymZIX0g1RDLxQJv3r8t15+TQrgCIPHyqpBzdqbzeoPJAoh1v1M jbnSHAUwvDRdkLp7o086dkiI62U+rFKIikcSXiLN9dyKUZ227aw8K5gOmz1Zb8ZmcfNC IlnnZVuibVshSef3n0TuBSVSwJ8aDBhakYZqCnQhEYPKo20aI2L6zN7GrTLAX4wbRUyC A4/x0nyckoMcCVAXIEfrNnndfc37eXUAZFeZt4K3Iu6UWRG4mhudVTt0gFO7Wzk8c7f4 SE6g== MIME-Version: 1.0 X-Received: by 10.58.236.70 with SMTP id us6mr26985062vec.89.1375173919632; Tue, 30 Jul 2013 01:45:19 -0700 (PDT) Received: by 10.220.142.130 with HTTP; Tue, 30 Jul 2013 01:45:19 -0700 (PDT) In-Reply-To: <72EF3457-5B8A-4F5C-8BEA-2EDC5DBF850E@gmail.com> References: <72EF3457-5B8A-4F5C-8BEA-2EDC5DBF850E@gmail.com> Date: Tue, 30 Jul 2013 16:45:19 +0800 Message-ID: From: Liu Dapeng To: Jouni Korhonen Content-Type: multipart/alternative; boundary=047d7bd6a906fc118c04e2b6a033 Cc: Dapeng Liu , "dmm@ietf.org" Subject: Re: [DMM] comments on draft-ietf-dmm-best-practices-gap-analysis-01 X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 08:46:11 -0000 --047d7bd6a906fc118c04e2b6a033 Content-Type: text/plain; charset=ISO-8859-1 Hi Jouni, Thanks for the comments. 2013/7/24 Jouni Korhonen > Authors, > > I finally read the draft and below are some comments to hopefully help > completing and improving the draft. > > In Section 4.2. it is stated: > > "view using common and standardized protocols. Since WiFi is the most > widely deployed wireless access technology nowadays, we take it as" > > Do you have some data/reference to backup your claim? > [Dapeng] Maybe we can change the wording a little bit. e.g. remove 'most'. > In Section 4.2.1. it is stated: > > "at different point of attachment. However there is no mechanism > specified to enable an efficient dynamic discovery of available" > > I would add a clarification here that there is no such mechanism > available within IETF specifications. Other SDOs do have such mechanism > (e.g. 3GPP). > [Dapeng] OK. > Furthermore, around the bulleted list for the MIPv6 RO discussion, I would > mention that nothing prevents a MN to use its CoA directly when > communicating > CNs on the same link or anywhere in the internet. Of course there is no > mobility in that case but it is a valid scenario to mention IMHO (and also > part of our charter). I recon the HMIPv6 text mentions at least the use of > RCoA already. > > [Dapeng] Agree. > In Section 4.2.2. where the text describes RFC6463, I would also reference > to > RFC6097 since that has quite a bit of text regarding the discovery > procedure > of the LMA. > [Dapeng] OK. > While I found Section 4.2. good in general I was somehow expecting to see > text regarding MOBIKE (RFC4555). We can safely assume MOBIKE is probably > the most deployed client mobility enabling technology out there today. > [Dapeng] We can add MOBIKE there. > In Section 4.3. it says: > > "GPRS Tunnelling Protocol (GTP) [3GPP.29.060] is a network-based > mobility protocol specified for 3GPP networks (S2a, S2b, S5 and S8 > interfaces)." > > While 29.060 is about GTP, for the above referenced interfaces 29.281 > and 29.274 are probably more appropriate. > [Dapeng] We will add those reference. "A Local IP Access (LIPA) and Selected IP Traffic Offload (SIPTO) > enabled network [3GPP.23.829] allows offloading some IP services at" > > I would say referencing to e.g. 23.401 on LIPA/SIPTO is more appropriate > these days, since the TR23.829 is somewhat left behind and the LIPA/SIPTO > functionality is part of the main stage-2 specs already. > [Dapeng] We will update this reference. > > I found Section 4 in general quite nice. However, I was somehow expecting > to see a bit of text of WiMAX. Or can we safely state that no IPv6 > deployments > ever took place in WiMAX? Anyway, at least a reference to WiMAX would be > nice, since they spent quite a bit of time developing both CMIPv6 and > PMIPv6 functionality into their architecture. > [Dapeng] OK. > In Section 4.3. I would reference to 3GPP TS29.303 and say something > about 3GPP's heavy use of DNS as the "gateway location database" and > how that is used to discover gateways with both topological and gateway > collocation in mind > [Dapeng] OK. > In Section 5. it is stated: > > "o The dynamic anchor relocation needs to ensure that IP address > continuity is guaranteed for sessions that need it at the > relocated anchor. This for example implies having the knowledge" > > Since our charter _allows_ solutions where mobility is used "when needed" > that fact should be reflected above. Even if there is mobility supported > only locally within a limited area, it might meet the requirements from > the MN or the application point of view i.e. when the MN or the application > does not care about a "full longstanding mobility" to be provided. > [Dapeng] We can change the wording here. > "o Dynamic discovery and selection of anchors. There might be more > than one available anchor for a mobile node to use. Currently, > there is no efficient mechanism that allows to dynamically > discover the presence of nodes that can play the role of anchor, > discover their capabilities and allow the selection of the most > suitable one." > > Within 3GPP TS29.303 makes that possible and is deployed. > > [Dapeng] We can scope the statement in IETF? > In general the draft is heading to a good direction IMHO! Just complete > it fast ;-) > [Dapeng] Thanks for the valuable comments. We will update the draft according to the comments soon. Dapeng - Jouni > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm > -- ------ Best Regards, Dapeng Liu --047d7bd6a906fc118c04e2b6a033 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Jouni,

Thanks for the comments.
<= div class=3D"gmail_extra">

2013/7/24 Joun= i Korhonen <jouni.nospam@gmail.com>
Authors,

I finally read the draft and below are some comments to hopefully help
completing and improving the draft.

In Section 4.2. it is stated:

=A0 "view using common and standardized protocols. =A0Since WiFi is th= e most
=A0 =A0widely deployed wireless access technology nowadays, we take it as&q= uot;

Do you have some data/reference to backup your claim?
=
[Dapeng] Maybe we can change the wording a little bit.= e.g. remove 'most'.
=A0
In Section 4.2.1. it is stated:

=A0 "at different point of attachment. =A0However there is no mechanis= m
=A0 =A0specified to enable an efficient dynamic discovery of available"= ;

I would add a clarification here that there is no such mechanism
available within IETF specifications. Other SDOs do have such mechanism
(e.g. 3GPP).

[Dapeng] OK.
=A0
Furthermore, around the bulleted list for the MIPv6 RO discussion, I would<= br> mention that nothing prevents a MN to use its CoA directly when communicati= ng
CNs on the same link or anywhere in the internet. Of course there is no
mobility in that case but it is a valid scenario to mention IMHO (and also<= br> part of our charter). I recon the HMIPv6 text mentions at least the use of<= br> RCoA already.

[Dapeng] Agree.
=A0
In Section 4.2.2. where the text describes RFC6463, I would also reference = to
RFC6097 since that has quite a bit of text regarding the discovery procedur= e
of the LMA.

[Dapeng] OK.
=A0
While I found Section 4.2. good in general I was somehow expecting to see text regarding MOBIKE (RFC4555). We can safely assume MOBIKE is probably the most deployed client mobility enabling technology out there today.
<= /blockquote>

[Dapeng] We can add MOBIKE there.
=A0
In Section 4.3. it says:

=A0 "GPRS Tunnelling Protocol (GTP) [3GPP.29.060] is a network-based =A0 =A0mobility protocol specified for 3GPP networks (S2a, S2b, S5 and S8 =A0 =A0interfaces)."

While 29.060 is about GTP, for the above referenced interfaces 29.281
and 29.274 are probably more appropriate.

[Dapeng] We will =A0add those reference.

=A0 "A Local IP Access (LIPA) and Selected IP Traffic Offload (SIPTO)<= br> =A0 =A0enabled network [3GPP.23.829] allows offloading some IP services at&= quot;

I would say referencing to e.g. 23.401 on LIPA/SIPTO is more appropriate these days, since the TR23.829 is somewhat left behind and the LIPA/SIPTO functionality is part of the main stage-2 specs already.

[Dapeng] We will update this reference.=A0

I found Section 4 in general quite nice. However, I was somehow expecting to see a bit of text of WiMAX. Or can we safely state that no IPv6 deployme= nts
ever took place in WiMAX? Anyway, at least a reference to WiMAX would be nice, since they spent quite a bit of time developing both CMIPv6 and
PMIPv6 functionality into their architecture.

[Dapeng] OK.
=A0
In Section 4.3. I would reference to 3GPP TS29.303 and say something
about 3GPP's heavy use of DNS as the "gateway location database&qu= ot; and
how that is used to discover gateways with both topological and gateway
collocation in mind

[Dapeng] OK.<= /div>
=A0
In Section 5. it is stated:

=A0 "o =A0The dynamic anchor relocation needs to ensure that IP addres= s
=A0 =A0 =A0 continuity is guaranteed for sessions that need it at the
=A0 =A0 =A0 relocated anchor. =A0This for example implies having the knowle= dge"

Since our charter _allows_ solutions where mobility is used "when need= ed"
that fact should be reflected above. Even if there is mobility supported only locally within a limited area, it might meet the requirements from
the MN or the application point of view i.e. when the MN or the application=
does not care about a "full longstanding mobility" to be provided= .

[Dapeng] We can change the word= ing here.
=A0
=A0 "o =A0Dynamic discovery and selection of anchors. =A0There might b= e more
=A0 =A0 =A0 than one available anchor for a mobile node to use. =A0Currentl= y,
=A0 =A0 =A0 there is no efficient mechanism that allows to dynamically
=A0 =A0 =A0 discover the presence of nodes that can play the role of anchor= ,
=A0 =A0 =A0 discover their capabilities and allow the selection of the most=
=A0 =A0 =A0 suitable one."

Within 3GPP TS29.303 makes that possible and is deployed.

[Dapeng] We can scope the statement in IETF?
=A0
In general the draft is heading to a good direction IMHO! Just complete
it fast ;-)

[Dapeng] Thanks for t= he=A0valuable comments. We will update the draft according to the comments = soon.

Dapeng

- Jouni

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



--

------Best Regards,
Dapeng Liu
--047d7bd6a906fc118c04e2b6a033-- From internet-drafts@ietf.org Tue Jul 30 02:16:44 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64F5C21F9E48; Tue, 30 Jul 2013 02:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.53 X-Spam-Level: X-Spam-Status: No, score=-102.53 tagged_above=-999 required=5 tests=[AWL=0.070, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mYrwIKSRXBQd; Tue, 30 Jul 2013 02:16:43 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D1C021F860B; Tue, 30 Jul 2013 02:12:08 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130730091200.615.14892.idtracker@ietfa.amsl.com> Date: Tue, 30 Jul 2013 02:12:00 -0700 Cc: dmm@ietf.org Subject: [DMM] I-D Action: draft-ietf-dmm-requirements-06.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 09:16:44 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Distributed Mobility Management Working G= roup of the IETF. Title : Requirements for Distributed Mobility Management Author(s) : H Anthony Chan Dapeng Liu Pierrick Seite Hidetoshi Yokota Jouni Korhonen Filename : draft-ietf-dmm-requirements-06.txt Pages : 19 Date : 2013-07-30 Abstract: This document defines the requirements for Distributed Mobility Management (DMM) in IPv6 deployments. The hierarchical structure in traditional wireless networks has led to deployment models which are in practice centralized. Mobility management with logically centralized mobility anchoring in current mobile networks is prone to suboptimal routing and raises scalability issues. Such centralized functions can lead to single points of failure and inevitably introduce longer delays and higher signaling loads for network operations related to mobility management. The objective is to enhance mobility management in order to meet the primary goals in network evolution, i.e., improve scalability, avoid single points of failure, enable transparent mobility support to upper layers only when needed, and so on. Distributed mobility management must be secure and may co-exist with existing network deployments and end hosts. 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-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dmm-requirements-06 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 Peter.McCann@huawei.com Tue Jul 30 04:09:28 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1759121F99A4 for ; Tue, 30 Jul 2013 04:09:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZffQTHOgyoE6 for ; Tue, 30 Jul 2013 04:09:22 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id DA0FB11E814F for ; Tue, 30 Jul 2013 04:09:21 -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.5-GA FastPath queued) with ESMTP id AVO33757; Tue, 30 Jul 2013 11:09:18 +0000 (GMT) Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 30 Jul 2013 12:09:07 +0100 Received: from DFWEML405-HUB.china.huawei.com (10.193.5.102) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 30 Jul 2013 12:09:14 +0100 Received: from dfweml512-mbx.china.huawei.com ([169.254.1.163]) by dfweml405-hub.china.huawei.com ([10.193.5.102]) with mapi id 14.01.0323.007; Tue, 30 Jul 2013 04:09:10 -0700 From: Peter McCann To: "dmm@ietf.org" Thread-Topic: Elements of a DMM Solution Thread-Index: Ac6NFTnvNwdJkIljSBKhE1ur31iYxg== Date: Tue, 30 Jul 2013 11:09:10 +0000 Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE716F5138A@dfweml512-mbx.china.huawei.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.246.84] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [DMM] Elements of a DMM Solution X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 11:09:28 -0000 I think that the DMM work can be subdivided into a small number of "modules= ", each of which can be implemented in a number of different ways. I. Limited-scope (localized) network-based mobility scheme This is probably what most people have in mind when they think of a DMM "protocol". This is the mechanism that gets packets to the current point of attachment. We have seen the following proposed as options for this module: A. Something based on PMIP B. Something based on GTP C. Something based on a routing protocol (e.g., BGP) D. Something based on SDN We should be able to "plug in" any of the above solutions to an overall=20 DMM framework. This module needs to be signaled when an MN attaches or cha= nges=20 its point of attachment. An identifier of the MN and an identifier of the attachment point should be provided in this signal. This module needs to i= nteract=20 with the address allocation/management module to obtain the set of IP prefi= xes currently in use by the mobile node, so that redirection/tunneling of packets destine= d to=20 those prefixes can be set up. This may require a network-queryable databas= e of prefixes that can be indexed by mobile node identifier. This database coul= d be stored in something like an HSS or in a DNS server. II. Address allocation/management This module lives in both the MN and the network. The MN maintains a pool = of addresses, each one topologically related to the point of attachment at the= time it was assigned. The MN should be made aware of which of its addresses are= =20 currently on-link at its current attachment point, courtesy of Module I. T= he MN should maintain information about how it is using each address so that u= nused addresses can be released and in-use addresses can have their leases renewe= d at the appropriate times. Address allocation/deallocation should NOT be coupl= ed to node mobility. It should be possible to have a mobility event without allo= cating a new address (to avoid excessive numbers of addresses being allocated) and= even if Module I cannot provide network-based relocation of a prefix, mobility t= o an attachment point where an address is not on-link SHOULD NOT trigger dealloc= ation of the address, because the MN might have a client-based mobility scheme th= at enables it to continue using the address (Module III). Some mechanism to r= enew the lease on the address from a remote location should be provided, such as= obtaining a global unicast IP address of a DHCP server. Security considerations for = such=20 remote renewal need to be investigated and addressed. Module I must be provided with a list of prefixes currently allocated to th= e MN. The database storing this information could be updated by the network eleme= nt that allocates the address (e.g., DHCP server) or could be updated by the MN. A= network element initiated update may be more appropriate for an HSS-stored database= , whereas an MN-initiated update may be more appropriate for a DNS-based database. III. An optional global, client-based mobility scheme Any network-based mobility scheme will necessarily have a limited scope. T= his=20 is especially true in the DMM case because the Internet attachment points a= re by definition close to the MN in the access (visited) network. Consider a roaming mobile node with home network H that attaches to visited network V1= . It obtains DMM service from V1, obtaining an IP address topologically route= d from the Internet directly to V1. Now consider this MN performing a handof= f from V1 to another visited network V2. V2 has a roaming agreement with H (= otherwise the MN would not be able to get service) but has absolutely no business arr= angement with V1. Therefore, it is impossible for the network-based mobility scheme= to=20 support re-routing or tunneling the packets destined to the original V1 add= ress to network V2. We must therefore support fall-back to a client-based OTT g= lobal mobility scheme, using the fact that both V1 and V2 offer connectivity to t= he same Internet, if the MN wants to keep using the address it got while conne= cted to V1. Allocation of a global mobility anchor should be coupled to allocation of t= he address for which global mobility is needed. There are already DHCP extens= ions to carry HA IP addresses which could be used for this purpose. The MN-HA=20 security association should also be bootstrapped at this time, so that the establishment of security does not add latency at the time the global mobil= ity service is invoked. We need to investigate whether the current DHCP extens= ion provides the right kind of HA identifier to the MN or whether a DNS name wo= uld be more helpful in bootstrapping security. The global mobility anchor may invoke Module I to get the HoA-addressed pac= kets=20 delivered to itself before tunneling them to the MN's CoA. The MN should m= ake use=20 of Module I for its CoA in its new visited network to minimize the number o= f global=20 mobility location update messages it needs to send to the anchor point. IV. Security Module I depends on a secure network access control protocol to provide an authenticated MN identity. Similarly, Module III requires bootstrapping a security association between MN and HA. So far, the AAA suite of protocols have been used for this purpose. However, it may be possible to further optimize this process and unify the credentials used by the various nodes if new solutions are investigated. Eliminating the round-trip to the home AAA server would dramatically improve the performance of network attachment and MN-HA SA establishment. Making use of DNS-based public key credentials that can be locally cached may allow the elimination of this round-trip and improve the scalability of home network infrastructure. These enhancements to security can be decoupled from the rest of the architecture and investigated separately. I think it's important for the DMM working group to investigate all 4 of th= e above solution components, even though most people in the group are probabl= y focused on Module I for now. We need to understand how the pieces will fit= =20 together into an overall system. To the extent we need to make changes to= =20 MN implementation practices, we should publish advice in Informational RFCs= . To the extent we need to modify protocols that are outside the scope of DMM= , we should send requirements to other working groups and encourage the work = to get done. -- Peter J. McCann Huawei Technologies (USA) Peter.McCann@Huawei.com +1 908 541 3563 Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ 08807-2863 U= SA From cjbc@it.uc3m.es Tue Jul 30 07:04:46 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2E2E21F9E12; Tue, 30 Jul 2013 07:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HtW5qxSOdqkm; Tue, 30 Jul 2013 07:04:38 -0700 (PDT) Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) by ietfa.amsl.com (Postfix) with ESMTP id A7D2E21F9BF0; Tue, 30 Jul 2013 07:04:38 -0700 (PDT) Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 178EF11C0C01; Tue, 30 Jul 2013 16:04:37 +0200 (CEST) X-uc3m-safe: yes X-uc3m-safe: yes Received: from [130.129.20.223] (dhcp-14df.meeting.ietf.org [130.129.20.223]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp03.uc3m.es) by smtp03.uc3m.es (Postfix) with ESMTPSA id 2850B11C0C00; Tue, 30 Jul 2013 16:04:36 +0200 (CEST) Message-ID: <1375193074.4549.4.camel@acorde.it.uc3m.es> From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano To: dmm@ietf.org, int-area@ietf.org, netext@ietf.amsl.com Date: Tue, 30 Jul 2013 16:04:34 +0200 In-Reply-To: <1375095320.4497.3.camel@acorde.it.uc3m.es> References: <1375095320.4497.3.camel@acorde.it.uc3m.es> Organization: Universidad Carlos III de Madrid Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.4.4-3 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.0.0.1014-20046.007 X-TM-AS-Result: No--18.594-7.0-31-1 X-imss-scan-details: No--18.594-7.0-31-1 Subject: Re: [DMM] Network-based DMM demo at IETF 87 (Tue 17:00 "Check" room) X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: cjbc@it.uc3m.es List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jul 2013 14:04:47 -0000 Hi, Please note that today's DMM demo at 17h is in the "Check" room, 2nd floor. If you don't know how to find, please look at the floor plans: http://www.ietf.org/meeting/87/floor-plans.pdf Thanks, Carlos On Mon, 2013-07-29 at 12:55 +0200, Carlos Jesús Bernardos Cano wrote: > Dear all, > > (Apologies for the cross-posting). > > We will show a network-based DMM Linux implementation demo tomorrow > (Tuesday, 30th July) at 17h, in "Check" room (2nd floor). > > The demo will showcase a particular use-case as an example of the > advantages provided by DMM: Content Distribution Networking (CDN) and > Distributed Mobility Management (DMM). > > The setup is composed of three "anchor routers", a "centralized LMA" for > control plane, CDN cache nodes co-located with the anchor routers, some > correspondent nodes (including a video server) and a legacy IPv6 mobile > node. The implementation is based on the following two drafts: > > [1] http://tools.ietf.org/html/draft-bernardos-dmm-pmip > > [2] http://tools.ietf.org/html/draft-bernardos-dmm-distributed-anchoring > > The demo will take about 20 to 30 minutes. > > Looking forward to seeing you there and getting your feedback. > > Thanks, > > Carlos et al. From h.anthony.chan@huawei.com Wed Jul 31 02:09:25 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1AD721F969F for ; Wed, 31 Jul 2013 02:09:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0-La5sNhxTK for ; Wed, 31 Jul 2013 02:09:18 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 87ACE21F9C4F for ; Wed, 31 Jul 2013 01:57:45 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id ATY62481; Wed, 31 Jul 2013 08:57:29 +0000 (GMT) Received: from LHREML406-HUB.china.huawei.com (10.201.5.243) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 31 Jul 2013 09:57:19 +0100 Received: from SZXEML420-HUB.china.huawei.com (10.82.67.159) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.1.323.7; Wed, 31 Jul 2013 09:57:28 +0100 Received: from szxeml557-mbx.china.huawei.com ([169.254.5.42]) by szxeml420-hub.china.huawei.com ([10.82.67.159]) with mapi id 14.01.0323.007; Wed, 31 Jul 2013 16:57:25 +0800 From: h chan To: "KIM, BYOUNG-JO J (BYOUNG-JO)" Thread-Topic: [DMM] requirements and the security considerations Thread-Index: Ac6Mh+DPIpfir8ABTzCS5H/3WiamJwBQ/AUQ Date: Wed, 31 Jul 2013 08:57:23 +0000 Message-ID: <6E31144C030982429702B11D6746B98C37095311@szxeml557-mbx.china.huawei.com> References: <6E31144C030982429702B11D6746B98C370928A2@szxeml557-mbx.china.huawei.com> <000301ce6e7c$063bb760$12b32620$@av.it.pt> <6E31144C030982429702B11D6746B98C37095087@szxeml557-mbx.china.huawei.com> <6E31144C030982429702B11D6746B98C37095120@szxeml557-mbx.china.huawei.com> <6E31144C030982429702B11D6746B98C37095159@szxeml557-mbx.china.huawei.com> <12B7B927-300C-4E5C-A287-8A100EB78F37@research.att.com> In-Reply-To: <12B7B927-300C-4E5C-A287-8A100EB78F37@research.att.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.130.178] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Cc: "dmm@ietf.org" Subject: Re: [DMM] requirements and the security considerations X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 09:09:25 -0000 Thanks and I have corrected the typo in version -06, which was uploaded yes= terday.=20 H Anthony Chan -----Original Message----- From: KIM, BYOUNG-JO J (BYOUNG-JO) [mailto:macsbug@research.att.com]=20 Sent: Monday, July 29, 2013 8:17 PM To: h chan Cc: dmm@ietf.org Subject: Re: [DMM] requirements and the security considerations Happy as a clam.. Will close the ticket. Best. J. p.s. a typo.. "amplify" instead of 'amplified'. On Jul 29, 2013, at 1:52 PM, h chan wrote: > Byoung-Jo, > Let me try to phrase your comment into the security requirement as follow= s. Please check and feel free to correct. > > REQ6: Security considerations > A DMM solution MUST not introduce new security risks or amplified existin= g security risks against which the existing security mechanisms/protocols c= annot offer sufficient protection. > > Motivation: > Various attacks such as impersonation, denial of service, man-in-the-midd= le attacks, and so on, may be launched in a DMM deployment. For instance, a= n illegitimate node may attempt to access a network providing DMM. Another = example is that a malicious node can forge a number of signaling messages t= hus redirecting traffic from its legitimate path. Consequently, the specif= ic node is under a denial of service attack, whereas other nodes do not rec= eive their traffic. > Accordingly, security mechanisms/protocols providing access control, inte= grity, authentication, authorization, confidentiality, etc. can be used to = protect the DMM entities as they are already used to protect against existi= ng networks and existing mobility protocols defined in IETF. In addition, e= nd-to-end security measures between communicating nodes may already be used= when deploying existing mobility protocols where the signaling messages tr= avel over the Internet. For instance, EAP-based authentication can be used = for network access security, while IPsec can be used for end-to-end securit= y. When these existing security mechanisms/protocols are applied to protect= the DMM entities, the security risks that May be introduced by DMM MUST be= considered to be eliminated. Else the security protection would be degrade= d in DMM versus in existing mobility protocols. > > This requirement prevents a DMM solution to introduce uncontrollable prob= lems of potentially insecure mobility management protocols which make deplo= yment infeasible because platforms conforming to the protocols are at risk = for data loss and numerous other dangers, including financial harm to users= . > > H Anthony Chan > > -----Original Message----- > From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of=20 > h chan > Sent: Monday, July 29, 2013 6:29 PM > To: KIM, BYOUNG-JO J (BYOUNG-JO) > Cc: dmm@ietf.org > Subject: Re: [DMM] requirements and the security considerations > > When you say the DMM requirements should only be on the risks added or am= plified by DMM, my understanding is that such increased risks depend on the= specific DMM solution. > > Then as I read the last sentence of the text from Jong Hyeouk: > Existing security mechanisms/protocols MAY be possible to provide suffici= ent security protections to DMM. For instance, EAP-based authentication can= be used for network access security, while IPsec can be used for end-to-en= d security. Note that when the existing security mechanisms/protocols are a= pplied to DMM, security risks that MAY be introduced by DMM MUST be conside= red to be eliminated. > > If I understand your intention correctly, one way to spell the requiremen= t on the DMM solution may be that the DMM solution MUST not introduce new r= isks or amplify the existing risks in a manner that cannot be handled with = the existing security mechanisms/protocols. If we rephrase the requirement = something along this line, does not capture your concern? The rest of the t= ext from Jong-Heouk (access network to DMM etc.) can be modified so as to s= imply examples of these existing risks as well as some existing security me= asures. The requirement is only not to introduce new risks other than these= existing ones. > > If it is okay, the next question is whether we allow solution that does i= ncrease/introduce more risks. If so, they must also provide the security me= asures to handle them. I don't know whether we should allow this or not tho= ugh. > > H Anthony Chan > > > -----Original Message----- > From: KIM, BYOUNG-JO J (BYOUNG-JO) [mailto:macsbug@research.att.com] > Sent: Monday, July 29, 2013 5:33 PM > To: h chan > Cc: dmm@ietf.org; Jouni Korhonen > Subject: Re: [DMM] requirements and the security considerations > > I suppose this is still related to my ticket #29 and now closed #27. > http://trac.tools.ietf.org/wg/dmm/trac/ticket/29 > > As I commented there, REQ6 should concern only to risked added or amplifi= ed by DMM. > > The new proposed text still talks about access network security which is = a separate issue, unless it means something else than commonly understood: = getting on the network.. which is not DMM's concern. > As an optimization, DMM security and access network security can be tied,= but I don't think we are that far along yet. > > Also, End2End security is commonly understood as btw MN and CN, while her= e I believe the authors mean MN and DMM entities in the network. Even then,= full IPsec may be overkill (with its mutual auth and all) and ephemeral se= curity may be good enough to protect the service and the network. > > e.g., It states.. "Accordingly, security mechanisms/protocols providing a= ccess control, integrity, authentication, authorization, confidentiality, e= tc. MUST be required to protect DMM" > > We cannot MUST "etc.", but that's just minor quibble. > Access control/Authorization can be implicit, e.g., " if allowed on the n= etwork, you can use DMM" > Authentication can be just to ensure the same MN is asking packet redirec= tion, without knowing identity. > > In short, security risks added or amplified by DMM can be discussed when = we have protocol specifics. There are too much specific countermeasures her= e whose applicability is unknowable at this point. > > Bests. > > J. > AT&T Labs - Research > http://sites.google.com/site/macsbug/ > > On Jul 29, 2013, at 8:37 AM, h chan wrote: > >> Byoung-Jo, >> Are you okay with the revised text for REQ6 provided by Jong-Hyouk? >> >> H Anthony Chan >> >> From: Jong-Hyouk Lee [mailto:jonghyouk@gmail.com] >> Sent: Saturday, June 22, 2013 6:17 PM >> To: dmm@ietf.org; h chan >> Cc: Jouni Korhonen >> Subject: Re: [DMM] requirements and the security considerations >> >> Hi all, >> >> Here is text for security. Apologize for being late, Anthony. >> >> =3D=3D=3D=3D=3D=3D >> 5.6. Security >> >> REQ6: DMM MUST be protected by security mechanisms/protocols in terms of= network access security and end-to-end security. Network access security i= s required between the mobile host/router and the access network deploying = DMM, to allow only a legitimate mobile host/router to use DMM. End-to-end s= ecurity is required between nodes that participate in DMM, to protect DMM s= ignaling messages. Existing security mechanisms/protocols MAY be possible t= o provide sufficient security protections to DMM. For instance, EAP-based a= uthentication can be used for network access security, while IPsec can be u= sed for end-to-end security. Note that when the existing security mechanism= s/protocols are applied to DMM, security risks that MAY be introduced by DM= M MUST be considered to be eliminated. >> >> A security mechanism/protocol that provides proof of possession of past = and new IP addresses of a mobile host/router MAY be needed. >> >> Motivation: Various attacks such as impersonation, denial of service, ma= n-in-the-middle attacks, and so on, MAY be launched against DMM. Accordingl= y, security mechanisms/protocols providing access control, integrity, authe= ntication, authorization, confidentiality, etc. MUST be required to protect= DMM. For instance, an illegitimate node attempts to access a network provi= ding DMM. Another example is that a malicious node can forge a number of si= gnaling messages thus redirecting traffic from its legitimate path. Consequ= ently, the specific node is under a denial of service attack, whereas other= nodes do not receive their traffic. As signaling messages MAY travel over = the Internet, the end-to-end security between communicating nodes MUST be r= equired. >> >> This requirement addresses the problems of potentially insecure=20 >> mobility management protocols which make deployment infeasible=20 >> because platforms conforming to the protocols are at risk for data=20 >> loss and numerous other dangers, including financial harm to users.=20 >> (I leave it to be modified or improved by Anthony) >> >> 6. Security Considerations >> (Now I do not think we need to put text here) =3D=3D=3D=3D=3D=3D >> >> >> On Fri, Jun 21, 2013 at 9:36 PM, Seil Jeon wrote: >> Hi, Anthony and all, >> >> >> >> Actually, when it comes to reviewing BJ's comment, it seems touching ver= y fundamental statement by mentioning the need of IP layer mobility support= for multicast session (if needed), though this requirement itself has impl= icitly included it. But it's ok to me. >> >> >> >> @Jouni, we respond to the ticket #22 as well. >> >> As you know, we have tried to identify and discuss the meaning of flexib= le distribution in the list. If we unfold the meaning hidden in the abstrac= t words, it would be fit to what you said. But the reworded sentences were = mostly copied from "Motivation" paragraph and arranged. Overall, the Motiva= tion was reworded. >> >> >> >> By taking into account two comments, the revised text is as follows. >> >> >> >> REQ7: DMM SHOULD consider multicast early so that solutions can >> >> be developed not only to provide IP mobility to keep IP multicast=20 >> sessions when it is needed, but to avoid network inefficiency issues=20 >> in multicast traffic delivery (such as duplicate multicast=20 >> subscriptions towards the downstream tunnel entitiesy). The multicast=20 >> solutions should therefore avoid restricting the management of all IP=20 >> multicast traffic to a single host through a dedicated >> (tunnel) interface on multicast-capable access routers. >> >> Motivation: Existing multicast deployment have been introduced after com= pleting the design of the reference mobility protocol, then optimization an= d extensions have been followed, by "patching-up" procedure, thus leading t= o network inefficiency and non-optimal routing. The multicast solutions sho= uld therefore be required to consider efficiency nature in multicast traffi= c delivery. >> >> >> >> p.s. @Jouni, I remember #33 ticket was resolved by answering Charlie's c= omment. Check it, please. >> >> >> >> >> >> Regards, >> >> Seil >> >> >> >> >> >> -----Original Message----- >> From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of=20 >> h chan >> Sent: Friday, June 21, 2013 1:26 AM >> To: Jouni Korhonen; dmm@ietf.org; KIM, BYOUNG-JO J (BYOUNG-JO >> Cc: Jong-Hyouk Lee >> Subject: Re: [DMM] requirements and the security considerations >> >> >> Seil or Sergio, >> >> Can you reply to the following: >> >> >> >> The comments from Byoung-Jo Kim to REQ7 in version 4 is as follows: >> >> >> >> I suggest to drop this requirement or make a clearer statement like "DMM= should allow multicast to survive IP layer mobility without packet loss", = or more modestly, "DMM should not foreclose multicast support during IP lay= er mobility.", etc.. >> >> >> >> >> >> His suggested text is to replace REQ7 with something like the following: >> >> >> >> REQ7: DMM SHOULD enable multicast packet delivery during mobility eve= nts as needed. >> >> >> >> H Anthony Chan >> >> >> >> >> >> -----Original Message----- >> >> From: h chan >> >> Sent: Thursday, June 20, 2013 7:15 PM >> >> To: 'Jouni Korhonen'; dmm@ietf.org; 'KIM, BYOUNG-JO J (BYOUNG-JO' >> >> Cc: 'Jong-Hyouk Lee' >> >> Subject: RE: [DMM] requirements and the security considerations >> >> >> >> The comments from Byoung-Jo Kim to REQ6 and Section 6 in version 4 were = the following: >> >> There are too much text in the security REQ6 that are vague and too wide= . >> >> >> >> And Section 6. Security considerations should say "none", 'cause that's = usually the section that discusses security considerations related to the d= raft itself. Since this is a requirement draft, there is no such thing. >> >> There is a separate requirement earlier to cover security issues due to = DMM. >> >> >> >> REQ6: Security considerations >> >> >> >> DMM protocol solutions MUST consider security risks=20 >> introduced >> >> by DMM into the network. Examples of such risks to be >> >> considered may include authentication and authorization=20 >> mechanisms >> >> that allow a mobile host/router to use the mobility >> >> support provided by the DMM solution; redirecting traffic to >> >> the wrong host when providing DMM support; signaling message >> >> protection for authentication, integrity and confidentiality. >> >> >> >> Motivation: Various attacks such as impersonation, denial of >> >> service, man-in-the-middle attacks, and so on, may become=20 >> newly >> >> possible or easier to mount due to the introduction of DMM. >> Proof >> >> of possession of past and new IP addresses may be needed. >> >> >> >> H Anthony Chan >> >> >> >> >> >> -----Original Message----- >> >> From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of=20 >> Jouni Korhonen >> >> Sent: Tuesday, June 18, 2013 2:40 AM >> >> To: dmm@ietf.org >> >> Subject: [DMM] requirements and the security considerations >> >> >> >> >> >> >> >> Folks, >> >> >> >> I have been reading Section 6 Security Considerations: >> >> >> >> It is necessary to provide sufficient defense against possible >> >> security attacks, or to adopt existing security mechanisms and >> >> protocols to provide sufficient security protections. For=20 >> instance, >> >> EAP-based authentication can be used for access network security, >> >> while IPsec can be used for end-to-end security. >> >> >> >> I think this text still deserves some tweaking. First, "provide sufficie= nt defense against possible security attacks".. against whom? >> >> >> >> Second, should the text say something that the DMM protocol itself must = not be usable as a tool to launch an attack by a malicious mobile node that= happens to know that it is attached to a network implementing DMM and know= s (somehow) how the DMM protocol functions? >> >> >> >> - 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 >> >> >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >> >> >> >> >> -- >> RSM Department, TELECOM Bretagne, France Jong-Hyouk Lee, living=20 >> somewhere between /dev/null and /dev/random >> >> #email: jonghyouk (at) gmail (dot) com >> #webpage: http://sites.google.com/site/hurryon/ > > _______________________________________________ > dmm mailing list > dmm@ietf.org > https://www.ietf.org/mailman/listinfo/dmm From charliep@computer.org Wed Jul 31 05:30:58 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D14B21F9C8E for ; Wed, 31 Jul 2013 05:30:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mze0a8Na-vmu for ; Wed, 31 Jul 2013 05:30:46 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id 25BFE11E8190 for ; Wed, 31 Jul 2013 05:29:51 -0700 (PDT) Received: from [130.129.16.71] by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from ) id 1V4VXF-0000aP-QJ for dmm@ietf.org; Wed, 31 Jul 2013 08:29:45 -0400 Message-ID: <51F9032F.6050900@computer.org> Date: Wed, 31 Jul 2013 05:29:35 -0700 From: "Charles E. Perkins" Organization: Saratoga Blue Skies User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "dmm@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad86c557a884abe772186a6efeb72dc589c7350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 130.129.16.71 Subject: [DMM] Closing issues in the issue tracker X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 12:31:00 -0000 Hello folks, I think it would be advantageous for several reasons if the issue tracker were updated with suggested resolutions of issues that have been raised. In other words, if the document is revised to resolve an issue, the issue tracker should show the text that is supposed to resolve the issue. Otherwise, it can be difficult for the person originally submitting an issue ticket to the Issue Tracker to know whether the issue has really been resolved. Moreover, the issue tracker "ought" to provide a record of the progress of the document as issues are resolved. Without showing the revised text, there isn't really any record of what happened or why certain decisions were made. -- Regards, Charlie P. From sat.usui@gmail.com Wed Jul 31 06:35:06 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37A8E21F9ED1 for ; Wed, 31 Jul 2013 06:35:06 -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=-2.599, J_CHICKENPOX_12=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A2CiGdTxLPdh for ; Wed, 31 Jul 2013 06:35:05 -0700 (PDT) Received: from mail-oa0-x242.google.com (mail-oa0-x242.google.com [IPv6:2607:f8b0:4003:c02::242]) by ietfa.amsl.com (Postfix) with ESMTP id BE03411E818F for ; Wed, 31 Jul 2013 06:34:59 -0700 (PDT) Received: by mail-oa0-f66.google.com with SMTP id i4so439628oah.5 for ; Wed, 31 Jul 2013 06:34:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc:content-type; bh=EUF+hR3/57hCSelIyij4Nn6yL8Ci1zHHbCnJsvXnW9s=; b=tTTRmbfz6BmftcsTGz62w1oBLdGLqLBM3xe98JVonCHshBZWvpLtJ0FePi7Qlyublk HWx9uq6GOcUgfELrg0VYbS5vHq+APMgCOALdrCTvHpkIfX2fWT+37LCTQE5sUe/gc5Q1 0ce0XWNQe3ldtu84YjYlqScc14efG4QXoKSvwpEUiaSbj+GKAJStBFNX7v3eev8arM7Z t239HGaBnJK9SSDqWl2l1LRHvYfT+pUmjPzDkFKS6hliI17oJU9bV0EG2cnkxABDWQFr PEYVVVN4cfZxQ4g6EiZmmOI6utnvqx73qACiEenw0RpsOwUXDBPC9wh3nciys3lsy3Oc zp/A== X-Received: by 10.60.98.41 with SMTP id ef9mr66178402oeb.68.1375277699237; Wed, 31 Jul 2013 06:34:59 -0700 (PDT) MIME-Version: 1.0 Received: by 10.60.69.37 with HTTP; Wed, 31 Jul 2013 06:34:19 -0700 (PDT) From: Sat Usui Date: Wed, 31 Jul 2013 15:34:19 +0200 Message-ID: To: Ryuji Wakikawa Content-Type: text/plain; charset=ISO-8859-1 Cc: dmm@ietf.org Subject: Re: [DMM] Fwd: New Version Notification for draft-matsushima-stateless-uplane-vepc-00.txt X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 13:35:06 -0000 Hi Ryuji, Thank you for submitting this draft. This approach is very interesting to me. I read the draft, and I have some comments: - It couldn't be found how to handle one and the other APNs simultaneously. Is it considered only for a default APN? - I'm confused about a SGW interface address. In section 4.2, you state: "vEPC must use a S1-U address that is different from anycast address assigned to EPC-Es." On the other hand you state in section 3.3: "When an operator needs to increase virtualized instances to cope with just signaling overload, the operator should use the existing S1-U address (i.e. EPC-E anycast address) for the new instances." Does the latter mean not a SGW interface address but a transport address in S1AP? - As already discussed on list, the S1-U SGW TEID might change during the X2 handover from idle-mode and from LTE to 3G (vice versa). I also think that the UE's prefix should remain constant during handovers even if using stateless u-plane or not. So, it might be good to use the PGW TEID or something constant for the UE's prefix rather than the S1-U SGW TEID. - If PGW sends IPv6 RAs periodically, a MN will have multiple IPv6 addresses. If it is not expected, RAs from PGW should be discarded, or PGW should not send RAs. - On fallback to the legacy EPC, I would think that it is not possible to use a handover procedure, because UE's prefix assignment must change from EPC-E to PGW. If the PGW TEID is used for UE's prefix and assigned by PGW, it is possible to use a handover procedure. - How does a handover between multiple EPC-Es sets? I think it is not possible by the one SGW. The other SGW might be needed. I'm looking forward to your presentation tomorrow. Regards, Satoshi Usui From ietf-secretariat-reply@ietf.org Wed Jul 31 06:47:44 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8DD21F9F5C for ; Wed, 31 Jul 2013 06:47:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.522 X-Spam-Level: X-Spam-Status: No, score=-102.522 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6caMwFKRb9YF for ; Wed, 31 Jul 2013 06:47:44 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 42E3821E80EB for ; Wed, 31 Jul 2013 06:47:43 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable To: dmm@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.60p1 Message-ID: <20130731134743.6675.95222.idtracker@ietfa.amsl.com> Date: Wed, 31 Jul 2013 06:47:43 -0700 From: IETF Secretariat X-Mailman-Approved-At: Wed, 31 Jul 2013 06:52:33 -0700 Subject: [DMM] Milestones changed for dmm WG X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 13:47:44 -0000 Changed milestone "Submit I-D 'Mobile IPv6 Vendor Specific Option' to IESG for publication as a Proposed Standard", set due date to October 2007 from October 2007. Changed milestone "Submit I-D 'Mobile IPv6 Experimental Allocations' to IESG for publication as a Proposed Standard", set due date to December 2007 from December 2007. Changed milestone "Submit I-D 'Mobile IPv6 Dual-Stack Operation' to IESG for publication as a Proposed Standard.", set due date to December 2007 from December 2007. Changed milestone "Submit I-D 'Motivation for Authentication I-D' to IESG for publication as Informational.", set due date to December 2007 from December 2007. Changed milestone "Submit Multiple CoA Registration to IESG", set due date to December 2007 from December 2007. Changed milestone "Submit I-D 'Goals for AAA HA Interface' to IESG for publication as Informational.", set due date to February 2008 from February 2008. Changed milestone "Submit -00 draft on Route Optimization Needs for Automobile and Highway Deployments", set due date to February 2008 from February 2008. Changed milestone "Submit -00 draft on Route Optimization Needs for Aircraft and Spacecraft Deployments", set due date to February 2008 from February 2008. Changed milestone "Submit final doc on Route Optimization Needs for Aircraft and Spacecraft Deployments, for Informational", set due date to May 2008 from May 2008. Changed milestone "Submit the final doc on MIB for NEMO Basic Support to the IESG, for Proposed Standard", set due date to August 2008 from August 2008. Changed milestone "Submit draft on Binding Revocation to IESG", set due date to October 2008 from October 2008. Changed milestone "Submit I-D(s) related to specific updates and corrections of RFC 3775 to IESG for publication as Proposed Standard.", set due date to December 2010 from December 2010. Changed milestone "Submit the final doc on Prefix Delegation for NEMO to the IESG, for Proposed Standard", set due date to December 2010 from December 2010. Changed milestone "Submit I-D 'Solution Requirements' as a working group document. To be Informational RFC.", set due date to August 2012 from August 2012, resolved as "Done". Changed milestone "Submit I-D 'Practices and Gap Analysis' as a working group document. To be Informational RFC.", resolved as "Done". Changed milestone "Submit I-D 'Solution Requirements' to the IESG for consideration as an Informational RFC.", set due date to January 2013 from January 2013. Deleted milestone "Submit I-D 'Practices ' to the IESG for consideration as an Informational RFC.". Changed milestone "Submit I-D 'Gap Analysis' to the IESG for consideration as an Informational RFC.", set due date to March 2013 from March 2013. URL: http://datatracker.ietf.org/wg/dmm/charter/ From Marco.Liebsch@neclab.eu Wed Jul 31 16:06:19 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12D8F21F8948 for ; Wed, 31 Jul 2013 16:06:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id et9+GUbWPQ3M for ; Wed, 31 Jul 2013 16:06:12 -0700 (PDT) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) by ietfa.amsl.com (Postfix) with ESMTP id 2D53021F9A30 for ; Wed, 31 Jul 2013 16:06:12 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 2058E1050F0; Thu, 1 Aug 2013 01:05:26 +0200 (CEST) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6JJRGpXa7HQW; Thu, 1 Aug 2013 01:05:26 +0200 (CEST) Received: from METHONE.office.hd (methone.office.hd [192.168.24.54]) by mailer1.neclab.eu (Postfix) with ESMTP id 0434E1050EE; Thu, 1 Aug 2013 01:05:16 +0200 (CEST) Received: from DAPHNIS.office.hd ([169.254.2.153]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.01.0323.003; Thu, 1 Aug 2013 01:05:40 +0200 From: Marco Liebsch To: Peter McCann , "dmm@ietf.org" Thread-Topic: Elements of a DMM Solution Thread-Index: Ac6NFTnvNwdJkIljSBKhE1ur31iYxgBKeN3g Date: Wed, 31 Jul 2013 23:05:39 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26D55310296@DAPHNIS.office.hd> References: <5963DDF1F751474D8DEEFDCDBEE43AE716F5138A@dfweml512-mbx.china.huawei.com> In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716F5138A@dfweml512-mbx.china.huawei.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.7.0.202] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [DMM] Elements of a DMM Solution X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 31 Jul 2013 23:06:19 -0000 Hi Pete, I support your proposal. Please see (so far brief) feedback inline. >-----Original Message----- >From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of >Peter McCann >Sent: Dienstag, 30. Juli 2013 13:09 >To: dmm@ietf.org >Subject: [DMM] Elements of a DMM Solution > >I think that the DMM work can be subdivided into a small number of "module= s", >each of which can be implemented in a number of different ways. > > >I. Limited-scope (localized) network-based mobility scheme > >This is probably what most people have in mind when they think of a DMM >"protocol". This is the mechanism that gets packets to the current point = of >attachment. We have seen the following proposed as options for this >module: > > A. Something based on PMIP > B. Something based on GTP > C. Something based on a routing protocol (e.g., BGP) > D. Something based on SDN > >We should be able to "plug in" any of the above solutions to an overall DM= M >framework. This module needs to be signaled when an MN attaches or change= s >its point of attachment. An identifier of the MN and an identifier of the >attachment point should be provided in this signal. This module needs to >interact with the address allocation/management module to obtain the set o= f IP >prefixes currently in use by the mobile node, so that redirection/tunnelin= g of >packets destined to those prefixes can be set up. This may require a netw= ork- >queryable database of prefixes that can be indexed by mobile node identifi= er. >This database could be stored in something like an HSS or in a DNS server. Yes, or an IP mobility anchor control plane function, or a registry associa= ted with an SDN controller, or.. something that can treat the MN's IP address (prefix) as identifier and sel= ect an appropriate routable locator IP address. I fully support that view that any DMM solutio= n should consider hooks to external (non-mobility) protocols to optimize (D)MM operation and = is well aligned with the methodology in our framework draft. > > >II. Address allocation/management > >This module lives in both the MN and the network. The MN maintains a pool= of >addresses, each one topologically related to the point of attachment at th= e time >it was assigned. The MN should be made aware of which of its addresses ar= e >currently on-link at its current attachment point, courtesy of Module I. = The MN >should maintain information about how it is using each address so that unu= sed >addresses can be released and in-use addresses can have their leases renew= ed >at the appropriate times. Address allocation/deallocation should NOT be >coupled to node mobility. It should be possible to have a mobility event = without >allocating a new address (to avoid excessive numbers of addresses being >allocated) and even if Module I cannot provide network-based relocation of= a >prefix, mobility to an attachment point where an address is not on-link SH= OULD >NOT trigger deallocation of the address, because the MN might have a clien= t- >based mobility scheme that enables it to continue using the address (Modul= e III). >Some mechanism to renew the lease on the address from a remote location >should be provided, such as obtaining a global unicast IP address of a DHC= P >server. Security considerations for such remote renewal need to be invest= igated >and addressed. So, on-link addresses are routable addresses associated with the MN's curre= nt anchor, whereas other addresses (off-link?) are associated with the previou= s anchor (or point of attachment) and considered deprecated. Correct? Dependent on t= he solution for DMM, this IP address is not routable anymore if imported to the current anchor to enable IP address continuity or remains routable through the MN's previous anchor. In the latter case the MN may have multiple anchors which may have to be added to the address management module, at least in case of client-based mobility. > >Module I must be provided with a list of prefixes currently allocated to t= he MN. >The database storing this information could be updated by the network elem= ent >that allocates the address (e.g., DHCP server) or could be updated by the = MN. A >network element initiated update may be more appropriate for an HSS-stored >database, whereas an MN-initiated update may be more appropriate for a DNS= - >based database. Well, in general this is about a dynamic binding in a database between one = or more IP addresses of the MN and associated locator(s). Important is that this ca= n be something else than what is provided by Mobile IP protocols. And this makes= sense, as it applies to the routing space above mobility anchor level (southbound to MM U-Plane fun= ction, or attachment point according to your terminology). Who updates the database is up to a particular solution. =20 > > >III. An optional global, client-based mobility scheme > >Any network-based mobility scheme will necessarily have a limited scope. = This >is especially true in the DMM case because the Internet attachment points = are >by definition close to the MN in the access (visited) network. Consider a >roaming mobile node with home network H that attaches to visited network V= 1. >It obtains DMM service from V1, obtaining an IP address topologically rout= ed >from the Internet directly to V1. Now consider this MN performing a hando= ff >from V1 to another visited network V2. V2 has a roaming agreement with H >(otherwise the MN would not be able to get service) but has absolutely no >business arrangement with V1. Therefore, it is impossible for the network= -based >mobility scheme to support re-routing or tunneling the packets destined to= the >original V1 address to network V2. We must therefore support fall-back to= a >client-based OTT global mobility scheme, using the fact that both V1 and V= 2 >offer connectivity to the same Internet, if the MN wants to keep using the >address it got while connected to V1. > >Allocation of a global mobility anchor should be coupled to allocation of = the >address for which global mobility is needed. There are already DHCP exten= sions >to carry HA IP addresses which could be used for this purpose. The MN-HA >security association should also be bootstrapped at this time, so that the >establishment of security does not add latency at the time the global mobi= lity >service is invoked. We need to investigate whether the current DHCP exten= sion >provides the right kind of HA identifier to the MN or whether a DNS name w= ould >be more helpful in bootstrapping security. > >The global mobility anchor may invoke Module I to get the HoA-addressed >packets delivered to itself before tunneling them to the MN's CoA. The MN >should make use of Module I for its CoA in its new visited network to mini= mize >the number of global mobility location update messages it needs to send to= the >anchor point. > > >IV. Security > >Module I depends on a secure network access control protocol to provide an >authenticated MN identity. Similarly, Module III requires bootstrapping a >security association between MN and HA. So far, the AAA suite of protocol= s >have been used for this purpose. However, it may be possible to further >optimize this process and unify the credentials used by the various nodes = if new >solutions are investigated. Eliminating the round-trip to the home AAA se= rver >would dramatically improve the performance of network attachment and MN- >HA SA establishment. Making use of DNS-based public key credentials that = can >be locally cached may allow the elimination of this round-trip and improve= the >scalability of home network infrastructure. > >These enhancements to security can be decoupled from the rest of the >architecture and investigated separately. > > > > >I think it's important for the DMM working group to investigate all 4 of t= he >above solution components, even though most people in the group are probab= ly >focused on Module I for now. We need to understand how the pieces will fi= t >together into an overall system. To the extent we need to make changes to= MN >implementation practices, we should publish advice in Informational RFCs. >To the extent we need to modify protocols that are outside the scope of DM= M, >we should send requirements to other working groups and encourage the work >to get done. Makes sense to me.=20 marco > > >-- >Peter J. McCann >Huawei Technologies (USA) >Peter.McCann@Huawei.com >+1 908 541 3563 >Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ 08807-2863 = USA > > >_______________________________________________ >dmm mailing list >dmm@ietf.org >https://www.ietf.org/mailman/listinfo/dmm From karagian@cs.utwente.nl Wed Jul 31 22:48:06 2013 Return-Path: X-Original-To: dmm@ietfa.amsl.com Delivered-To: dmm@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D84D721F9D45 for ; Wed, 31 Jul 2013 22:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.503 X-Spam-Level: X-Spam-Status: No, score=-0.503 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3+g3B0HkvQhB for ; Wed, 31 Jul 2013 22:47:59 -0700 (PDT) Received: from EXEDGE01.ad.utwente.nl (exedge01.ad.utwente.nl [130.89.5.48]) by ietfa.amsl.com (Postfix) with ESMTP id E5DDC21F8F63 for ; Wed, 31 Jul 2013 22:47:49 -0700 (PDT) Received: from EXHUB01.ad.utwente.nl (130.89.4.228) by EXEDGE01.ad.utwente.nl (130.89.5.48) with Microsoft SMTP Server (TLS) id 14.2.328.9; Thu, 1 Aug 2013 07:47:55 +0200 Received: from EXMBX23.ad.utwente.nl ([169.254.3.13]) by EXHUB01.ad.utwente.nl ([130.89.4.228]) with mapi id 14.02.0328.009; Thu, 1 Aug 2013 07:47:48 +0200 From: To: , Thread-Topic: Elements of a DMM Solution Thread-Index: Ac6NFTnvNwdJkIljSBKhE1ur31iYxgBZTWnsAAAPbJc= Date: Thu, 1 Aug 2013 05:47:47 +0000 Message-ID: References: <5963DDF1F751474D8DEEFDCDBEE43AE716F5138A@dfweml512-mbx.china.huawei.com> In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716F5138A@dfweml512-mbx.china.huawei.com> Accept-Language: nl-NL, en-US Content-Language: nl-NL X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mimectl: Produced By Microsoft Exchange V14.2.247.1 x-originating-ip: [87.193.195.90] Content-Type: multipart/alternative; boundary="_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F3BB00DEXMBX23adutwent_" MIME-Version: 1.0 Subject: Re: [DMM] Elements of a DMM Solution X-BeenThere: dmm@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Distributed Mobility Management Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Aug 2013 05:48:07 -0000 --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F3BB00DEXMBX23adutwent_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Peter, I agree with the main message of your email, which I am translating into: *) Define protocol agnostic Functional Framework to build DMM solutions aro= und existing mobility protocols: o) can apply to solutions that are solely based on existing IP mobility = protocols o) can apply to solutions which get support from non mobility protocols Best regards, Georgios ________________________________ Van: dmm-bounces@ietf.org [dmm-bounces@ietf.org] namens Peter McCann [Peter= .McCann@huawei.com] Verzonden: dinsdag 30 juli 2013 13:09 To: dmm@ietf.org Onderwerp: [DMM] Elements of a DMM Solution I think that the DMM work can be subdivided into a small number of "modules= ", each of which can be implemented in a number of different ways. I. Limited-scope (localized) network-based mobility scheme This is probably what most people have in mind when they think of a DMM "protocol". This is the mechanism that gets packets to the current point of attachment. We have seen the following proposed as options for this module: A. Something based on PMIP B. Something based on GTP C. Something based on a routing protocol (e.g., BGP) D. Something based on SDN We should be able to "plug in" any of the above solutions to an overall DMM framework. This module needs to be signaled when an MN attaches or cha= nges its point of attachment. An identifier of the MN and an identifier of the attachment point should be provided in this signal. This module needs to i= nteract with the address allocation/management module to obtain the set of IP prefi= xes currently in use by the mobile node, so that redirection/tunneling of packets destine= d to those prefixes can be set up. This may require a network-queryable databas= e of prefixes that can be indexed by mobile node identifier. This database coul= d be stored in something like an HSS or in a DNS server. II. Address allocation/management This module lives in both the MN and the network. The MN maintains a pool = of addresses, each one topologically related to the point of attachment at the= time it was assigned. The MN should be made aware of which of its addresses are currently on-link at its current attachment point, courtesy of Module I. T= he MN should maintain information about how it is using each address so that u= nused addresses can be released and in-use addresses can have their leases renewe= d at the appropriate times. Address allocation/deallocation should NOT be coupl= ed to node mobility. It should be possible to have a mobility event without allo= cating a new address (to avoid excessive numbers of addresses being allocated) and= even if Module I cannot provide network-based relocation of a prefix, mobility t= o an attachment point where an address is not on-link SHOULD NOT trigger dealloc= ation of the address, because the MN might have a client-based mobility scheme th= at enables it to continue using the address (Module III). Some mechanism to r= enew the lease on the address from a remote location should be provided, such as= obtaining a global unicast IP address of a DHCP server. Security considerations for = such remote renewal need to be investigated and addressed. Module I must be provided with a list of prefixes currently allocated to th= e MN. The database storing this information could be updated by the network eleme= nt that allocates the address (e.g., DHCP server) or could be updated by the MN. A= network element initiated update may be more appropriate for an HSS-stored database= , whereas an MN-initiated update may be more appropriate for a DNS-based database. III. An optional global, client-based mobility scheme Any network-based mobility scheme will necessarily have a limited scope. T= his is especially true in the DMM case because the Internet attachment points a= re by definition close to the MN in the access (visited) network. Consider a roaming mobile node with home network H that attaches to visited network V1= . It obtains DMM service from V1, obtaining an IP address topologically route= d from the Internet directly to V1. Now consider this MN performing a handof= f from V1 to another visited network V2. V2 has a roaming agreement with H (= otherwise the MN would not be able to get service) but has absolutely no business arr= angement with V1. Therefore, it is impossible for the network-based mobility scheme= to support re-routing or tunneling the packets destined to the original V1 add= ress to network V2. We must therefore support fall-back to a client-based OTT g= lobal mobility scheme, using the fact that both V1 and V2 offer connectivity to t= he same Internet, if the MN wants to keep using the address it got while conne= cted to V1. Allocation of a global mobility anchor should be coupled to allocation of t= he address for which global mobility is needed. There are already DHCP extens= ions to carry HA IP addresses which could be used for this purpose. The MN-HA security association should also be bootstrapped at this time, so that the establishment of security does not add latency at the time the global mobil= ity service is invoked. We need to investigate whether the current DHCP extens= ion provides the right kind of HA identifier to the MN or whether a DNS name wo= uld be more helpful in bootstrapping security. The global mobility anchor may invoke Module I to get the HoA-addressed pac= kets delivered to itself before tunneling them to the MN's CoA. The MN should m= ake use of Module I for its CoA in its new visited network to minimize the number o= f global mobility location update messages it needs to send to the anchor point. IV. Security Module I depends on a secure network access control protocol to provide an authenticated MN identity. Similarly, Module III requires bootstrapping a security association between MN and HA. So far, the AAA suite of protocols have been used for this purpose. However, it may be possible to further optimize this process and unify the credentials used by the various nodes if new solutions are investigated. Eliminating the round-trip to the home AAA server would dramatically improve the performance of network attachment and MN-HA SA establishment. Making use of DNS-based public key credentials that can be locally cached may allow the elimination of this round-trip and improve the scalability of home network infrastructure. These enhancements to security can be decoupled from the rest of the architecture and investigated separately. I think it's important for the DMM working group to investigate all 4 of th= e above solution components, even though most people in the group are probabl= y focused on Module I for now. We need to understand how the pieces will fit together into an overall system. To the extent we need to make changes to MN implementation practices, we should publish advice in Informational RFCs= . To the extent we need to modify protocols that are outside the scope of DMM= , we should send requirements to other working groups and encourage the work = to get done. -- Peter J. McCann Huawei Technologies (USA) Peter.McCann@Huawei.com +1 908 541 3563 Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ 08807-2863 U= SA _______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm --_000_FF1A9612A94D5C4A81ED7DE1039AB80F4F3BB00DEXMBX23adutwent_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable

Hi Peter,

 

I agree with the main message of your email, which I am translating= into:

 

*) Define protocol agnostic Functional Framework to build DMM solutions = around existing mobility protocols:
   o) can apply to solutions that are solely based on existing IP= mobility protocols
   o) can apply to solutions which get support from non mobility = protocols

 

Best regards,

Georgios

Van: dmm-bounces@ietf.org [dmm-bounces@ietf.org] namens Peter Mc= Cann [Peter.McCann@huawei.com]
Verzonden: dinsdag 30 juli 2013 13:09
To: dmm@ietf.org
Onderwerp: [DMM] Elements of a DMM Solution

I think that the DMM work can be subdivided into a= small number of "modules",
each of which can be implemented in a number of different ways.


I. Limited-scope (localized) network-based mobility scheme

This is probably what most people have in mind when they think of a DMM
"protocol".  This is the mechanism that gets packets to the = current point
of attachment.  We have seen the following proposed as options for thi= s
module:

   A. Something based on PMIP
   B. Something based on GTP
   C. Something based on a routing protocol (e.g., BGP)
   D. Something based on SDN

We should be able to "plug in" any of the above solutions to an o= verall
DMM framework.  This module needs to be signaled when an MN attaches o= r changes
its point of attachment.  An identifier of the MN and an identifier of= the
attachment point should be provided in this signal.  This module needs= to interact
with the address allocation/management module to obtain the set of IP prefi= xes currently
in use by the mobile node, so that redirection/tunneling of packets destine= d to
those prefixes can be set up.  This may require a network-queryable da= tabase of
prefixes that can be indexed by mobile node identifier.  This database= could be
stored in something like an HSS or in a DNS server.


II. Address allocation/management

This module lives in both the MN and the network.  The MN maintains a = pool of
addresses, each one topologically related to the point of attachment at the= time
it was assigned.  The MN should be made aware of which of its addresse= s are
currently on-link at its current attachment point, courtesy of Module I.&nb= sp; The
MN should maintain information about how it is using each address so that u= nused
addresses can be released and in-use addresses can have their leases renewe= d at
the appropriate times.  Address allocation/deallocation should NOT be = coupled to
node mobility.  It should be possible to have a mobility event without= allocating
a new address (to avoid excessive numbers of addresses being allocated) and= even
if Module I cannot provide network-based relocation of a prefix, mobility t= o an
attachment point where an address is not on-link SHOULD NOT trigger dealloc= ation
of the address, because the MN might have a client-based mobility scheme th= at
enables it to continue using the address (Module III).  Some mechanism= to renew
the lease on the address from a remote location should be provided, such as= obtaining
a global unicast IP address of a DHCP server.  Security considerations= for such
remote renewal need to be investigated and addressed.

Module I must be provided with a list of prefixes currently allocated to th= e MN.
The database storing this information could be updated by the network eleme= nt that
allocates the address (e.g., DHCP server) or could be updated by the MN.&nb= sp; A network
element initiated update may be more appropriate for an HSS-stored database= , whereas
an MN-initiated update may be more appropriate for a DNS-based database.

III. An optional global, client-based mobility scheme

Any network-based mobility scheme will necessarily have a limited scope.&nb= sp; This
is especially true in the DMM case because the Internet attachment points a= re
by definition close to the MN in the access (visited) network.  Consid= er a
roaming mobile node with home network H that attaches to visited network V1= .
It obtains DMM service from V1, obtaining an IP address topologically route= d
from the Internet directly to V1.  Now consider this MN performing a h= andoff
from V1 to another visited network V2.  V2 has a roaming agreement wit= h H (otherwise
the MN would not be able to get service) but has absolutely no business arr= angement
with V1.  Therefore, it is impossible for the network-based mobility s= cheme to
support re-routing or tunneling the packets destined to the original V1 add= ress
to network V2.  We must therefore support fall-back to a client-based = OTT global
mobility scheme, using the fact that both V1 and V2 offer connectivity to t= he
same Internet, if the MN wants to keep using the address it got while conne= cted
to V1.

Allocation of a global mobility anchor should be coupled to allocation of t= he
address for which global mobility is needed.  There are already DHCP e= xtensions
to carry HA IP addresses which could be used for this purpose.  The MN= -HA
security association should also be bootstrapped at this time, so that the<= br> establishment of security does not add latency at the time the global mobil= ity
service is invoked.  We need to investigate whether the current DHCP e= xtension
provides the right kind of HA identifier to the MN or whether a DNS name wo= uld
be more helpful in bootstrapping security.

The global mobility anchor may invoke Module I to get the HoA-addressed pac= kets
delivered to itself before tunneling them to the MN's CoA.  The MN sho= uld make use
of Module I for its CoA in its new visited network to minimize the number o= f global
mobility location update messages it needs to send to the anchor point.


IV. Security

Module I depends on a secure network access control protocol to provide an<= br> authenticated MN identity.  Similarly, Module III requires bootstrappi= ng a
security association between MN and HA.  So far, the AAA suite of prot= ocols
have been used for this purpose.  However, it may be possible to furth= er
optimize this process and unify the credentials used by the various nodes if new solutions are investigated.  Eliminating the round-trip to the = home
AAA server would dramatically improve the performance of network attachment=
and MN-HA SA establishment.  Making use of DNS-based public key creden= tials
that can be locally cached may allow the elimination of this round-trip and=
improve the scalability of home network infrastructure.

These enhancements to security can be decoupled from the rest of the
architecture and investigated separately.




I think it's important for the DMM working group to investigate all 4 of th= e
above solution components, even though most people in the group are probabl= y
focused on Module I for now.  We need to understand how the pieces wil= l fit
together into an overall system.  To the extent we need to make change= s to
MN implementation practices, we should publish advice in Informational RFCs= .
To the extent we need to modify protocols that are outside the scope of DMM= ,
we should send requirements to other working groups and encourage the work = to
get done.


--
Peter J. McCann
Huawei Technologies (USA)
Peter.McCann@Huawei.com
+1 908 541 3563
Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ  08807-28= 63  USA


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