From jouni.nospam@gmail.com  Thu May  2 01:56:57 2013
Return-Path: <jouni.nospam@gmail.com>
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 5B4A421F9945 for <dmm@ietfa.amsl.com>; Thu,  2 May 2013 01:56:57 -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=1.120,  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 lzNkUAkYGOwO for <dmm@ietfa.amsl.com>; Thu,  2 May 2013 01:56:52 -0700 (PDT)
Received: from mail-ee0-f50.google.com (mail-ee0-f50.google.com [74.125.83.50]) by ietfa.amsl.com (Postfix) with ESMTP id A998A21F97D8 for <dmm@ietf.org>; Thu,  2 May 2013 01:56:11 -0700 (PDT)
Received: by mail-ee0-f50.google.com with SMTP id e50so155265eek.37 for <dmm@ietf.org>; Thu, 02 May 2013 01:56:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to:x-mailer; bh=B7ZBg8tmnIb16P+POx0fMwoSlul8GkmYw1+3TauuOCI=; b=hCkhz8UnALnocItEEsRs5y/C7uPjQuBH1hjwTFY6UPgxSy7/TVd0qILdNzbAAUv3kO fOJelRTgTYz9b3KVDrrHZER3qbk37vDpuBi/7LWjHJyeguxYpPrhuiWncNGef/2xrxmt FZoofP0tBS2sJz/gAHTtHsjJ27GMa3AqJ+wnXYhOZjeWin0rDh6qhs89nxt3KlYTDeqJ LQce8rWumlFufd7SzfBlSa3BcFeA5JoitFypiyoaT5nwntdo63lmNCRKgdy1+r0XNbCy H6/05hW6Y7fjBzHGgFVAVdcaAjubjyHnLCszZyJ0gmG9luQbfAezjwPyb3USXMewTMEp dAoQ==
X-Received: by 10.14.194.70 with SMTP id l46mr17222164een.28.1367484970749; Thu, 02 May 2013 01:56:10 -0700 (PDT)
Received: from ?IPv6:2001:1bc8:101:f101:883f:3df4:1943:952c? ([2001:1bc8:101:f101:883f:3df4:1943:952c]) by mx.google.com with ESMTPSA id k43sm8303378een.2.2013.05.02.01.56.06 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 May 2013 01:56:08 -0700 (PDT)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Jouni Korhonen <jouni.nospam@gmail.com>
In-Reply-To: <8D38716F0C1A444BA0CD7E96454366C23F43CDD5@szxeml511-mbx.china.huawei.com>
Date: Thu, 2 May 2013 11:56:25 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <E2E10B6E-AC3C-4AE5-A4D1-7665AA0E99C0@gmail.com>
References: <A2B5D1EE-764B-4136-9742-83AF5C89CF75@gmail.com>, <49AA4160-5EE5-4E6F-A4C7-ED9D1FE82D07@gmail.com> <FF1A9612A94D5C4A81ED7DE1039AB80F4F37E921@EXMBX23.ad.utwente.nl> <8D38716F0C1A444BA0CD7E96454366C23F43CDD5@szxeml511-mbx.china.huawei.com>
To: "dmm@ietf.org" <dmm@ietf.org>, draft-ietf-dmm-requirements@tools.ietf.org
X-Mailer: Apple Mail (2.1503)
Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 02 May 2013 08:56:57 -0000

Folks,

We have now got a number of reviews and specifically comments put into =
issue tracker. I am pleased to find out that the discussion on some of =
the posted comments has already started.=20

The next thing is to solve the issues recorded in the issue tracker and =
close them one by one. Some of them are purely editorial. Some might =
need a bit more WG work. I encourage submitting intermediate version =
quite frequently once non-overlapping issues have been solved. That =
helps keeping track where we go.

The faster we get the document updates done, the better.. obviously.

- Jouni & Julien



On Apr 24, 2013, at 8:17 PM, Konstantinos Pentikousis =
<k.pentikousis@huawei.com> wrote:

> | I am happy with the current version of the DMM draft!=20
> | So I think that the draft can proceed with the further IETF review =
process!
> |=20
> | Best regards,
> | Georgios
> =20
> I second Georgios' assessment. I think that most of the comments =
related to editorial aspects, and thus it's time to move this draft =
forward in the process.
>=20
> Best regards,
>=20
> Kostas
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm


From internet-drafts@ietf.org  Tue May  7 23:13:32 2013
Return-Path: <internet-drafts@ietf.org>
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 890EC21F8F5C; Tue,  7 May 2013 23:13:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level: 
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 oSwxG928AZNg; Tue,  7 May 2013 23:13:32 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 601C921F8F0D; Tue,  7 May 2013 23:13:30 -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.44.p7
Message-ID: <20130508061330.4339.12566.idtracker@ietfa.amsl.com>
Date: Tue, 07 May 2013 23:13:30 -0700
Cc: dmm@ietf.org
Subject: [DMM] I-D Action: draft-ietf-dmm-requirements-04.txt
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 May 2013 06:13:32 -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-04.txt
	Pages           : 19
	Date            : 2013-05-07

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-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dmm-requirements-04


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From sgundave@cisco.com  Thu May 16 22:42:46 2013
Return-Path: <sgundave@cisco.com>
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 20DFA21F901B for <dmm@ietfa.amsl.com>; Thu, 16 May 2013 22:42:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.299
X-Spam-Level: 
X-Spam-Status: No, score=-8.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_FORM=2.3, 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 g4S3YhMXsml4 for <dmm@ietfa.amsl.com>; Thu, 16 May 2013 22:42:41 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 434ED21F9007 for <dmm@ietf.org>; Thu, 16 May 2013 22:42:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2611; q=dns/txt; s=iport; t=1368769361; x=1369978961; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=oswtKxlxEKJSJ1GQq8pm1CZlUemtV4POi1cxS9C+ibk=; b=W4g0V39JVmy6x9pyBHmdiVyti4cOCfMcbqzeCVSJQuEpcnX58c6bNOI+ z6gYDhvSHU5PRObDBz60GyRvkmkJN0bQnYNuvZKhKv7vWwi6QSWZnm8A1 B6sMizSB6nVykU+6vHNuvI9xWtt+X9kFl7y9N4rAppwoalIpopTW4UHFm c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AikFAMvClVGtJV2d/2dsb2JhbABbgwg3wVp+FnSCHwEBAQMBAQEBawQHBQ0BCBIGCksLFw4CBAENBQgTh2sGDLxcBI1cgRIxB4J0YQOoeIMQgiY
X-IronPort-AV: E=Sophos;i="4.87,690,1363132800"; d="scan'208";a="211419739"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 17 May 2013 05:42:40 +0000
Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r4H5ge70013531 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 17 May 2013 05:42:40 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.159]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.02.0318.004; Fri, 17 May 2013 00:42:40 -0500
From: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
To: Alper Yegin <alper.yegin@yegin.org>, "Charles E. Perkins" <charliep@computer.org>
Thread-Topic: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03
Thread-Index: AQHOUsFXHSVwrEMav0+4NP1W/j/J3g==
Date: Fri, 17 May 2013 05:42:40 +0000
Message-ID: <24C0F3E22276D9438D6F366EB89FAEA81028E99A@xmb-aln-x03.cisco.com>
In-Reply-To: <87ECA3CB-AC73-4981-BCB0-9ED2A7F5DB65@yegin.org>
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.214]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <6ACBC14735F0164FAA2D311DF1D450CD@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dmm@ietf.org" <dmm@ietf.org>
Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 May 2013 05:42:46 -0000

> Distributed solution: Take IP traffic directly from access router to the
>Internet.




Counter argument.


It implies, LI, Charging, DPI =8Aetc on each of the distributed nodes.
Implies more "CAPEX and OPEX" ?


I'm not against distributed models and 6909 is the proof point. But, IMO,
it will hard to draw relation to cost models, based on traffic exit
points. You may need mobility hierarchy in the network for "n" number of
reasons and a centralized models for "m" number of reasons. It more about
deployment choice, dependent on many parameters.




Sri






On 4/29/13 5:29 AM, "Alper Yegin" <alper.yegin@yegin.org> wrote:

>Hi Charlie,
>
>No, it should be less.
>
>Distributed solution: Take IP traffic directly from access router to the
>Internet.
>Centralized solution: Take IP traffic from access router to a core router
>to the Internet.
>
>The latter suggests more CAPEX and OPEX.
>
>Alper
>
>
>
>On Apr 27, 2013, at 3:44 AM, Charles E. Perkins wrote:
>
>>=20
>> Hello Alper,
>>=20
>> I agree with your point, but it means that the total cost of
>> the distributed solution is even more expensive.... right?
>>=20
>> Regards,
>> Charlie P.
>>=20
>> On 4/26/2013 12:56 AM, Alper Yegin wrote:
>>> Hi Charlie,
>>>=20
>>>> - It is claimed that a centralized architecture requires more
>>>>resources
>>>>  than a distributed architecture.  This is usually false.  For
>>>>instance,
>>>>  if a centralized node requires 100 units, and 100 distributed nodes
>>>>each
>>>>  require 1.03 units, the distributed architecture requires 3 more
>>>>units
>>>>  overall.
>>> This would be true for tasks that can be performed either on the
>>>distributed node or on the central node.
>>> But the essential task for DMM systems, IP forwarding, is not of that
>>>nature.
>>> In centralized architecture, that task needs to be performed *both* at
>>>the edge node and also at the central node (and in fact even in
>>>between) before the packets hit the Internet/mobile device.
>>>=20
>>>=20
>>>> Even so, the additional expense of the distributed architecture
>>>>  would often be a bargain for reasons of redundancy, resiliency, etc.
>>>=20
>>> Alper
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>> _______________________________________________
>>> dmm mailing list
>>> dmm@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dmm
>>>=20
>>=20
>>=20
>> --=20
>> Regards,
>> Charlie P.
>>=20
>
>_______________________________________________
>dmm mailing list
>dmm@ietf.org
>https://www.ietf.org/mailman/listinfo/dmm


From Peter.McCann@huawei.com  Fri May 17 06:05:02 2013
Return-Path: <Peter.McCann@huawei.com>
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 806DD21F93BD for <dmm@ietfa.amsl.com>; Fri, 17 May 2013 06:05:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level: 
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_FORM=2.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 0xxUNZk9xjfY for <dmm@ietfa.amsl.com>; Fri, 17 May 2013 06:04:58 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6560821F8D7A for <dmm@ietf.org>; Fri, 17 May 2013 06:04:57 -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 ASW90199; Fri, 17 May 2013 13:04:55 +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; Fri, 17 May 2013 14:04:12 +0100
Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 17 May 2013 14:04:50 +0100
Received: from dfweml512-mbx.china.huawei.com ([169.254.1.179]) by dfweml406-hub.china.huawei.com ([10.193.5.131]) with mapi id 14.01.0323.007; Fri, 17 May 2013 06:04:47 -0700
From: Peter McCann <Peter.McCann@huawei.com>
To: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>, Alper Yegin <alper.yegin@yegin.org>, "Charles E. Perkins" <charliep@computer.org>
Thread-Topic: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03
Thread-Index: AQHOUsFXHSVwrEMav0+4NP1W/j/J3pkJV//g
Date: Fri, 17 May 2013 13:04:46 +0000
Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE716ED0202@dfweml512-mbx.china.huawei.com>
References: <87ECA3CB-AC73-4981-BCB0-9ED2A7F5DB65@yegin.org> <24C0F3E22276D9438D6F366EB89FAEA81028E99A@xmb-aln-x03.cisco.com>
In-Reply-To: <24C0F3E22276D9438D6F366EB89FAEA81028E99A@xmb-aln-x03.cisco.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.156]
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "dmm@ietf.org" <dmm@ietf.org>
Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 May 2013 13:05:02 -0000

We shouldn't require all the traffic to pay the price of centralization
just because some small subset of the flow need it.  LI should be a very
small proportion of the traffic, and those flows can be directed to a
collection point as needed.  If you really need per-flow, per-application
charging, you can send meta-information about the flows to a charging
collection box.  No need to send the flows themselves.

-Pete


Sri Gundavelli (sgundave) wrote:
>=20
>> Distributed solution: Take IP traffic directly from access router to
>> the Internet.
>=20
>=20
>=20
>=20
> Counter argument.
>=20
>=20
> It implies, LI, Charging, DPI =A9etc on each of the distributed nodes.
> Implies more "CAPEX and OPEX" ?
>=20
>=20
> I'm not against distributed models and 6909 is the proof point. But,
> IMO, it will hard to draw relation to cost models, based on traffic
> exit points. You may need mobility hierarchy in the network for "n"
> number of reasons and a centralized models for "m" number of reasons.
> It more about deployment choice, dependent on many parameters.
>=20
>=20
>=20
>=20
> Sri
>=20
>=20
>=20
>=20
>=20
>=20
> On 4/29/13 5:29 AM, "Alper Yegin" <alper.yegin@yegin.org> wrote:
>=20
>> Hi Charlie,
>>=20
>> No, it should be less.
>>=20
>> Distributed solution: Take IP traffic directly from access router to
>> the Internet.
>> Centralized solution: Take IP traffic from access router to a core
>> router to the Internet.
>>=20
>> The latter suggests more CAPEX and OPEX.
>>=20
>> Alper
>>=20
>>=20
>>=20
>> On Apr 27, 2013, at 3:44 AM, Charles E. Perkins wrote:
>>=20
>>>=20
>>> Hello Alper,
>>>=20
>>> I agree with your point, but it means that the total cost of the
>>> distributed solution is even more expensive.... right?
>>>=20
>>> Regards,
>>> Charlie P.
>>>=20
>>> On 4/26/2013 12:56 AM, Alper Yegin wrote:
>>>> Hi Charlie,
>>>>=20
>>>>> - It is claimed that a centralized architecture requires more
>>>>> resources
>>>>>  than a distributed architecture.  This is usually false.  For
>>>>>  instance, if a centralized node requires 100 units, and 100
>>>>>  distributed nodes each require 1.03 units, the distributed
>>>>>  architecture requires 3 more units overall.
>>>> This would be true for tasks that can be performed either on the
>>>> distributed node or on the central node.
>>>> But the essential task for DMM systems, IP forwarding, is not of
>>>> that nature.
>>>> In centralized architecture, that task needs to be performed
>>>> *both* at the edge node and also at the central node (and in fact
>>>> even in
>>>> between) before the packets hit the Internet/mobile device.
>>>>=20
>>>>=20
>>>>> Even so, the additional expense of the distributed architecture
>>>>> would often be a bargain for reasons of redundancy, resiliency,
> etc.
>>>>=20
>>>> Alper
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> dmm mailing list
>>>> dmm@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dmm
>>>>=20
>>>=20
>>>=20
>>> --
>>> Regards,
>>> Charlie P.
>>>=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 macsbug@research.att.com  Fri May 17 07:23:55 2013
Return-Path: <macsbug@research.att.com>
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 32E9821F9080 for <dmm@ietfa.amsl.com>; Fri, 17 May 2013 07:23:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.299
X-Spam-Level: 
X-Spam-Status: No, score=-104.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_FORM=2.3, RCVD_IN_DNSWL_MED=-4, 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 bWMl6G8cwd+C for <dmm@ietfa.amsl.com>; Fri, 17 May 2013 07:23: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 AD62721F8C00 for <dmm@ietf.org>; Fri, 17 May 2013 07:23:43 -0700 (PDT)
Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id 27C341207F2; Fri, 17 May 2013 10:23:43 -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 3E658F0366; Fri, 17 May 2013 10:23:43 -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; Fri, 17 May 2013 10:23:43 -0400
From: "KIM, BYOUNG-JO J (BYOUNG-JO)" <macsbug@research.att.com>
To: Peter McCann <Peter.McCann@huawei.com>
Date: Fri, 17 May 2013 10:23:42 -0400
Thread-Topic: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03
Thread-Index: Ac5TCiG/DCVHBy43Tw24fWaY8tthtQ==
Message-ID: <BA8F04F6-4B33-4F0D-B430-2BC425C49F5E@research.att.com>
References: <87ECA3CB-AC73-4981-BCB0-9ED2A7F5DB65@yegin.org> <24C0F3E22276D9438D6F366EB89FAEA81028E99A@xmb-aln-x03.cisco.com> <5963DDF1F751474D8DEEFDCDBEE43AE716ED0202@dfweml512-mbx.china.huawei.com>
In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716ED0202@dfweml512-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" <dmm@ietf.org>
Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 May 2013 14:23:55 -0000

Very much agreed.

Also, distributed solutions can be concentrated as deployment needs dictate=
 using layer 2 means, as is done often in many present networks.

can't do the opposite with centralized solutions without a whole lot of acr=
obatics.

"J" Kim
AT&T Labs - Research
http://sites.google.com/site/macsbug/

On May 17, 2013, at 9:04 AM, Peter McCann wrote:

> We shouldn't require all the traffic to pay the price of centralization
> just because some small subset of the flow need it.  LI should be a very
> small proportion of the traffic, and those flows can be directed to a
> collection point as needed.  If you really need per-flow, per-application
> charging, you can send meta-information about the flows to a charging
> collection box.  No need to send the flows themselves.
>=20
> -Pete
>=20
>=20
> Sri Gundavelli (sgundave) wrote:
>>=20
>>> Distributed solution: Take IP traffic directly from access router to
>>> the Internet.
>>=20
>>=20
>>=20
>>=20
>> Counter argument.
>>=20
>>=20
>> It implies, LI, Charging, DPI =8Aetc on each of the distributed nodes.
>> Implies more "CAPEX and OPEX" ?
>>=20
>>=20
>> I'm not against distributed models and 6909 is the proof point. But,
>> IMO, it will hard to draw relation to cost models, based on traffic
>> exit points. You may need mobility hierarchy in the network for "n"
>> number of reasons and a centralized models for "m" number of reasons.
>> It more about deployment choice, dependent on many parameters.
>>=20
>>=20
>>=20
>>=20
>> Sri
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>> On 4/29/13 5:29 AM, "Alper Yegin" <alper.yegin@yegin.org> wrote:
>>=20
>>> Hi Charlie,
>>>=20
>>> No, it should be less.
>>>=20
>>> Distributed solution: Take IP traffic directly from access router to
>>> the Internet.
>>> Centralized solution: Take IP traffic from access router to a core
>>> router to the Internet.
>>>=20
>>> The latter suggests more CAPEX and OPEX.
>>>=20
>>> Alper
>>>=20
>>>=20
>>>=20
>>> On Apr 27, 2013, at 3:44 AM, Charles E. Perkins wrote:
>>>=20
>>>>=20
>>>> Hello Alper,
>>>>=20
>>>> I agree with your point, but it means that the total cost of the
>>>> distributed solution is even more expensive.... right?
>>>>=20
>>>> Regards,
>>>> Charlie P.
>>>>=20
>>>> On 4/26/2013 12:56 AM, Alper Yegin wrote:
>>>>> Hi Charlie,
>>>>>=20
>>>>>> - It is claimed that a centralized architecture requires more
>>>>>> resources
>>>>>> than a distributed architecture.  This is usually false.  For
>>>>>> instance, if a centralized node requires 100 units, and 100
>>>>>> distributed nodes each require 1.03 units, the distributed
>>>>>> architecture requires 3 more units overall.
>>>>> This would be true for tasks that can be performed either on the
>>>>> distributed node or on the central node.
>>>>> But the essential task for DMM systems, IP forwarding, is not of
>>>>> that nature.
>>>>> In centralized architecture, that task needs to be performed
>>>>> *both* at the edge node and also at the central node (and in fact
>>>>> even in
>>>>> between) before the packets hit the Internet/mobile device.
>>>>>=20
>>>>>=20
>>>>>> Even so, the additional expense of the distributed architecture
>>>>>> would often be a bargain for reasons of redundancy, resiliency,
>> etc.
>>>>>=20
>>>>> Alper
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> dmm mailing list
>>>>> dmm@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/dmm
>>>>>=20
>>>>=20
>>>>=20
>>>> --
>>>> Regards,
>>>> Charlie P.
>>>>=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
>=20
>=20
>=20
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm


From h.anthony.chan@huawei.com  Fri May 17 14:07:38 2013
Return-Path: <h.anthony.chan@huawei.com>
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 5359221F969F for <dmm@ietfa.amsl.com>; Fri, 17 May 2013 14:07:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level: 
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_FORM=2.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 3bLDk6qsAEc7 for <dmm@ietfa.amsl.com>; Fri, 17 May 2013 14:07:33 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 93C7C21F96A4 for <dmm@ietf.org>; Fri, 17 May 2013 14:07:32 -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 ARM27735; Fri, 17 May 2013 21:07:30 +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; Fri, 17 May 2013 22:06:54 +0100
Received: from SZXEML414-HUB.china.huawei.com (10.82.67.153) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 17 May 2013 22:07:24 +0100
Received: from szxeml557-mbs.china.huawei.com ([169.254.6.136]) by SZXEML414-HUB.china.huawei.com ([10.82.67.153]) with mapi id 14.01.0323.007; Sat, 18 May 2013 05:07:12 +0800
From: h chan <h.anthony.chan@huawei.com>
To: "KIM, BYOUNG-JO J (BYOUNG-JO)" <macsbug@research.att.com>, Peter McCann <Peter.McCann@huawei.com>
Thread-Topic: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03
Thread-Index: AQHOUsFXHSVwrEMav0+4NP1W/j/J3pkJV//g//+QpQCAAPSl0A==
Date: Fri, 17 May 2013 21:07:12 +0000
Message-ID: <6E31144C030982429702B11D6746B98C37087D2A@szxeml557-mbs.china.huawei.com>
References: <87ECA3CB-AC73-4981-BCB0-9ED2A7F5DB65@yegin.org> <24C0F3E22276D9438D6F366EB89FAEA81028E99A@xmb-aln-x03.cisco.com> <5963DDF1F751474D8DEEFDCDBEE43AE716ED0202@dfweml512-mbx.china.huawei.com> <BA8F04F6-4B33-4F0D-B430-2BC425C49F5E@research.att.com>
In-Reply-To: <BA8F04F6-4B33-4F0D-B430-2BC425C49F5E@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.192.11.183]
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "dmm@ietf.org" <dmm@ietf.org>
Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 May 2013 21:07:39 -0000

The original comment was on "resources" in the following problem statement:

   PS3:  Low scalability of centralized tunnel management and mobility
         context maintenance

         Setting up tunnels through a central anchor and maintaining
         mobility context for each MN therein requires more resources in
         a centralized design, thus reducing scalability.  Distributing
         the tunnel maintenance function and the mobility context
         maintenance function among different network entities can
         increase scalability.

How about revising PS3 to the following and comparing resources:

   PS3:  Low scalability of centralized tunnel management and mobility
         context maintenance

         Setting up tunnels through a central anchor and maintaining
         mobility context for each MN in a centralized design increase
         the processing at the anchor as the number of MNs increases.
         Distributing the tunnel maintenance function and the mobility
         context maintenance function among different network entities
         with proper signaling protocol design can increase scalability.

H Anthony Chan

-----Original Message-----
From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of KIM, =
BYOUNG-JO J (BYOUNG-JO)
Sent: Friday, May 17, 2013 9:24 AM
To: Peter McCann
Cc: dmm@ietf.org
Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03

Very much agreed.

Also, distributed solutions can be concentrated as deployment needs dictate=
 using layer 2 means, as is done often in many present networks.

can't do the opposite with centralized solutions without a whole lot of acr=
obatics.

"J" Kim
AT&T Labs - Research
http://sites.google.com/site/macsbug/

On May 17, 2013, at 9:04 AM, Peter McCann wrote:

> We shouldn't require all the traffic to pay the price of=20
> centralization just because some small subset of the flow need it.  LI=20
> should be a very small proportion of the traffic, and those flows can=20
> be directed to a collection point as needed.  If you really need=20
> per-flow, per-application charging, you can send meta-information=20
> about the flows to a charging collection box.  No need to send the flows =
themselves.
>=20
> -Pete
>=20
>=20
> Sri Gundavelli (sgundave) wrote:
>>=20
>>> Distributed solution: Take IP traffic directly from access router to=20
>>> the Internet.
>>=20
>>=20
>>=20
>>=20
>> Counter argument.
>>=20
>>=20
>> It implies, LI, Charging, DPI =A9etc on each of the distributed nodes.
>> Implies more "CAPEX and OPEX" ?
>>=20
>>=20
>> I'm not against distributed models and 6909 is the proof point. But,=20
>> IMO, it will hard to draw relation to cost models, based on traffic=20
>> exit points. You may need mobility hierarchy in the network for "n"
>> number of reasons and a centralized models for "m" number of reasons.
>> It more about deployment choice, dependent on many parameters.
>>=20
>>=20
>>=20
>>=20
>> Sri
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>> On 4/29/13 5:29 AM, "Alper Yegin" <alper.yegin@yegin.org> wrote:
>>=20
>>> Hi Charlie,
>>>=20
>>> No, it should be less.
>>>=20
>>> Distributed solution: Take IP traffic directly from access router to=20
>>> the Internet.
>>> Centralized solution: Take IP traffic from access router to a core=20
>>> router to the Internet.
>>>=20
>>> The latter suggests more CAPEX and OPEX.
>>>=20
>>> Alper
>>>=20
>>>=20
>>>=20
>>> On Apr 27, 2013, at 3:44 AM, Charles E. Perkins wrote:
>>>=20
>>>>=20
>>>> Hello Alper,
>>>>=20
>>>> I agree with your point, but it means that the total cost of the=20
>>>> distributed solution is even more expensive.... right?
>>>>=20
>>>> Regards,
>>>> Charlie P.
>>>>=20
>>>> On 4/26/2013 12:56 AM, Alper Yegin wrote:
>>>>> Hi Charlie,
>>>>>=20
>>>>>> - It is claimed that a centralized architecture requires more=20
>>>>>> resources than a distributed architecture.  This is usually=20
>>>>>> false.  For instance, if a centralized node requires 100 units,=20
>>>>>> and 100 distributed nodes each require 1.03 units, the=20
>>>>>> distributed architecture requires 3 more units overall.
>>>>> This would be true for tasks that can be performed either on the=20
>>>>> distributed node or on the central node.
>>>>> But the essential task for DMM systems, IP forwarding, is not of=20
>>>>> that nature.
>>>>> In centralized architecture, that task needs to be performed
>>>>> *both* at the edge node and also at the central node (and in fact=20
>>>>> even in
>>>>> between) before the packets hit the Internet/mobile device.
>>>>>=20
>>>>>=20
>>>>>> Even so, the additional expense of the distributed architecture=20
>>>>>> would often be a bargain for reasons of redundancy, resiliency,
>> etc.
>>>>>=20
>>>>> Alper
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> dmm mailing list
>>>>> dmm@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/dmm
>>>>>=20
>>>>=20
>>>>=20
>>>> --
>>>> Regards,
>>>> Charlie P.
>>>>=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
>=20
>=20
>=20
> _______________________________________________
> 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 h.anthony.chan@huawei.com  Fri May 17 21:47:49 2013
Return-Path: <h.anthony.chan@huawei.com>
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 671BA21F95D0 for <dmm@ietfa.amsl.com>; Fri, 17 May 2013 21:47:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level: 
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_FORM=2.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 6erFRXAYnHRS for <dmm@ietfa.amsl.com>; Fri, 17 May 2013 21:47:45 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 7913721F95A0 for <dmm@ietf.org>; Fri, 17 May 2013 21:47:44 -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 ASX32065; Sat, 18 May 2013 04:47:42 +0000 (GMT)
Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sat, 18 May 2013 05:47:09 +0100
Received: from SZXEML452-HUB.china.huawei.com (10.82.67.195) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Sat, 18 May 2013 05:47:40 +0100
Received: from szxeml557-mbs.china.huawei.com ([169.254.6.136]) by szxeml452-hub.china.huawei.com ([10.82.67.195]) with mapi id 14.01.0323.007; Sat, 18 May 2013 12:47:29 +0800
From: h chan <h.anthony.chan@huawei.com>
To: "KIM, BYOUNG-JO J (BYOUNG-JO)" <macsbug@research.att.com>, Peter McCann <Peter.McCann@huawei.com>
Thread-Topic: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03
Thread-Index: AQHOUsFXHSVwrEMav0+4NP1W/j/J3pkJV//g//+QpQCAAPSl0IAAghPA
Date: Sat, 18 May 2013 04:47:28 +0000
Message-ID: <6E31144C030982429702B11D6746B98C37089D79@szxeml557-mbs.china.huawei.com>
References: <87ECA3CB-AC73-4981-BCB0-9ED2A7F5DB65@yegin.org> <24C0F3E22276D9438D6F366EB89FAEA81028E99A@xmb-aln-x03.cisco.com> <5963DDF1F751474D8DEEFDCDBEE43AE716ED0202@dfweml512-mbx.china.huawei.com> <BA8F04F6-4B33-4F0D-B430-2BC425C49F5E@research.att.com> <6E31144C030982429702B11D6746B98C37087D2A@szxeml557-mbs.china.huawei.com>
In-Reply-To: <6E31144C030982429702B11D6746B98C37087D2A@szxeml557-mbs.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.152.13]
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "dmm@ietf.org" <dmm@ietf.org>
Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 18 May 2013 04:47:49 -0000

The original comment was on "resources" in the problem statement PS3:

How about revising PS3 to the following without comparing resources:

   PS3:  Low scalability of centralized tunnel management and mobility
         context maintenance

         Setting up tunnels through a central anchor and maintaining
         mobility context for each MN in a centralized design increase
         the processing at the anchor as the number of MNs increases.
         Distributing the tunnel maintenance function and the mobility
         context maintenance function among different network entities
         with proper signaling protocol design can increase scalability.

H Anthony Chan

-----Original Message-----
From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of KIM, =
BYOUNG-JO J (BYOUNG-JO)
Sent: Friday, May 17, 2013 9:24 AM
To: Peter McCann
Cc: dmm@ietf.org
Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03

Very much agreed.

Also, distributed solutions can be concentrated as deployment needs dictate=
 using layer 2 means, as is done often in many present networks.

can't do the opposite with centralized solutions without a whole lot of acr=
obatics.

"J" Kim
AT&T Labs - Research
http://sites.google.com/site/macsbug/

On May 17, 2013, at 9:04 AM, Peter McCann wrote:

> We shouldn't require all the traffic to pay the price of=20
> centralization just because some small subset of the flow need it.  LI=20
> should be a very small proportion of the traffic, and those flows can=20
> be directed to a collection point as needed.  If you really need=20
> per-flow, per-application charging, you can send meta-information=20
> about the flows to a charging collection box.  No need to send the flows =
themselves.
>=20
> -Pete
>=20
>=20
> Sri Gundavelli (sgundave) wrote:
>>=20
>>> Distributed solution: Take IP traffic directly from access router to=20
>>> the Internet.
>>=20
>>=20
>>=20
>>=20
>> Counter argument.
>>=20
>>=20
>> It implies, LI, Charging, DPI =A9etc on each of the distributed nodes.
>> Implies more "CAPEX and OPEX" ?
>>=20
>>=20
>> I'm not against distributed models and 6909 is the proof point. But,=20
>> IMO, it will hard to draw relation to cost models, based on traffic=20
>> exit points. You may need mobility hierarchy in the network for "n"
>> number of reasons and a centralized models for "m" number of reasons.
>> It more about deployment choice, dependent on many parameters.
>>=20
>>=20
>>=20
>>=20
>> Sri
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>> On 4/29/13 5:29 AM, "Alper Yegin" <alper.yegin@yegin.org> wrote:
>>=20
>>> Hi Charlie,
>>>=20
>>> No, it should be less.
>>>=20
>>> Distributed solution: Take IP traffic directly from access router to=20
>>> the Internet.
>>> Centralized solution: Take IP traffic from access router to a core=20
>>> router to the Internet.
>>>=20
>>> The latter suggests more CAPEX and OPEX.
>>>=20
>>> Alper
>>>=20
>>>=20
>>>=20
>>> On Apr 27, 2013, at 3:44 AM, Charles E. Perkins wrote:
>>>=20
>>>>=20
>>>> Hello Alper,
>>>>=20
>>>> I agree with your point, but it means that the total cost of the=20
>>>> distributed solution is even more expensive.... right?
>>>>=20
>>>> Regards,
>>>> Charlie P.
>>>>=20
>>>> On 4/26/2013 12:56 AM, Alper Yegin wrote:
>>>>> Hi Charlie,
>>>>>=20
>>>>>> - It is claimed that a centralized architecture requires more=20
>>>>>> resources than a distributed architecture.  This is usually=20
>>>>>> false.  For instance, if a centralized node requires 100 units,=20
>>>>>> and 100 distributed nodes each require 1.03 units, the=20
>>>>>> distributed architecture requires 3 more units overall.
>>>>> This would be true for tasks that can be performed either on the=20
>>>>> distributed node or on the central node.
>>>>> But the essential task for DMM systems, IP forwarding, is not of=20
>>>>> that nature.
>>>>> In centralized architecture, that task needs to be performed
>>>>> *both* at the edge node and also at the central node (and in fact=20
>>>>> even in
>>>>> between) before the packets hit the Internet/mobile device.
>>>>>=20
>>>>>=20
>>>>>> Even so, the additional expense of the distributed architecture=20
>>>>>> would often be a bargain for reasons of redundancy, resiliency,
>> etc.
>>>>>=20
>>>>> Alper
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> dmm mailing list
>>>>> dmm@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/dmm
>>>>>=20
>>>>=20
>>>>=20
>>>> --
>>>> Regards,
>>>> Charlie P.
>>>>=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
>=20
>=20
>=20
> _______________________________________________
> 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

From alper.yegin@yegin.org  Mon May 20 00:26:04 2013
Return-Path: <alper.yegin@yegin.org>
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 E3B6121F842F for <dmm@ietfa.amsl.com>; Mon, 20 May 2013 00:26:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.299
X-Spam-Level: 
X-Spam-Status: No, score=-100.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_FORM=2.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 3a1tNLqEwyAE for <dmm@ietfa.amsl.com>; Mon, 20 May 2013 00:25:56 -0700 (PDT)
Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by ietfa.amsl.com (Postfix) with ESMTP id 657F221F8EEA for <dmm@ietf.org>; Mon, 20 May 2013 00:25:14 -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 0MNqnj-1UY0f214Gp-0077hG; Mon, 20 May 2013 03:24:48 -0400
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: text/plain; charset=windows-1252
From: Alper Yegin <alper.yegin@yegin.org>
In-Reply-To: <24C0F3E22276D9438D6F366EB89FAEA81028E99A@xmb-aln-x03.cisco.com>
Date: Mon, 20 May 2013 10:24:41 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <BB2BFAC2-DF2E-4A33-BD40-FA85474E797E@yegin.org>
References: <24C0F3E22276D9438D6F366EB89FAEA81028E99A@xmb-aln-x03.cisco.com>
To: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
X-Mailer: Apple Mail (2.1283)
X-Provags-ID: V02:K0:qRVcJzeLEls3L6RKlZrivtEMWYSTWtIvzEwdbBozW+9 CLRROxIJua/J2nVQpKdlkCB5+7jR85mvE+8++bh/N3SzTfMOg7 tuZMBAMuBuWrs1gnASAtC7WdnT5Kqu3s1F8Vq59MOTFICDATHc UTuP5KtSnX9zR3RJ5E26BnMksxxx6Kvb8uHYQNQnLNjF2I2k+o DAKTH3qMeo3IUZzoiw75ENlwANuOLz7ElZRidy59WSU7lEFxpX +MU3UON48RXLVUVJRzXqnEKKQRRhIQXOtRuUgn5ONV1w5n3fMF HMgI3JcA/M1B5lcJObbt300m9u8lnNboFuJvtwR3AWgwN+s3Oq tS5ts9rapc9a5eTedTit9NfmWGw6c6OMkRbLkJ+r9DjNRre2Er DuCL1XG2r+tag==
Cc: "dmm@ietf.org" <dmm@ietf.org>
Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 May 2013 07:26:04 -0000

On May 17, 2013, at 8:42 AM, Sri Gundavelli (sgundave) wrote:

>=20
>> Distributed solution: Take IP traffic directly from access router to =
the
>> Internet.
>=20
>=20
>=20
>=20
> Counter argument.
>=20
>=20
> It implies, LI, Charging, DPI =8Aetc on each of the distributed nodes.
> Implies more "CAPEX and OPEX" ?
>=20

If that were the case, then the operators wouldn't be offloading the =
subscriber IP traffic from WiFi to Internet.=20

Alper



>=20
> I'm not against distributed models and 6909 is the proof point. But, =
IMO,
> it will hard to draw relation to cost models, based on traffic exit
> points. You may need mobility hierarchy in the network for "n" number =
of
> reasons and a centralized models for "m" number of reasons. It more =
about
> deployment choice, dependent on many parameters.
>=20
>=20
>=20
>=20
> Sri
>=20
>=20
>=20
>=20
>=20
>=20
> On 4/29/13 5:29 AM, "Alper Yegin" <alper.yegin@yegin.org> wrote:
>=20
>> Hi Charlie,
>>=20
>> No, it should be less.
>>=20
>> Distributed solution: Take IP traffic directly from access router to =
the
>> Internet.
>> Centralized solution: Take IP traffic from access router to a core =
router
>> to the Internet.
>>=20
>> The latter suggests more CAPEX and OPEX.
>>=20
>> Alper
>>=20
>>=20
>>=20
>> On Apr 27, 2013, at 3:44 AM, Charles E. Perkins wrote:
>>=20
>>>=20
>>> Hello Alper,
>>>=20
>>> I agree with your point, but it means that the total cost of
>>> the distributed solution is even more expensive.... right?
>>>=20
>>> Regards,
>>> Charlie P.
>>>=20
>>> On 4/26/2013 12:56 AM, Alper Yegin wrote:
>>>> Hi Charlie,
>>>>=20
>>>>> - It is claimed that a centralized architecture requires more
>>>>> resources
>>>>> than a distributed architecture.  This is usually false.  For
>>>>> instance,
>>>>> if a centralized node requires 100 units, and 100 distributed =
nodes
>>>>> each
>>>>> require 1.03 units, the distributed architecture requires 3 more
>>>>> units
>>>>> overall.
>>>> This would be true for tasks that can be performed either on the
>>>> distributed node or on the central node.
>>>> But the essential task for DMM systems, IP forwarding, is not of =
that
>>>> nature.
>>>> In centralized architecture, that task needs to be performed *both* =
at
>>>> the edge node and also at the central node (and in fact even in
>>>> between) before the packets hit the Internet/mobile device.
>>>>=20
>>>>=20
>>>>> Even so, the additional expense of the distributed architecture
>>>>> would often be a bargain for reasons of redundancy, resiliency, =
etc.
>>>>=20
>>>> Alper
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> dmm mailing list
>>>> dmm@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dmm
>>>>=20
>>>=20
>>>=20
>>> --=20
>>> Regards,
>>> Charlie P.
>>>=20
>>=20
>> _______________________________________________
>> dmm mailing list
>> dmm@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmm
>=20


From sgundave@cisco.com  Mon May 20 10:27:32 2013
Return-Path: <sgundave@cisco.com>
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 8F04521F93B9 for <dmm@ietfa.amsl.com>; Mon, 20 May 2013 10:27:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.574
X-Spam-Level: 
X-Spam-Status: No, score=-8.574 tagged_above=-999 required=5 tests=[AWL=-0.875, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, MANGLED_FORM=2.3, 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 1He0uMFcaGGB for <dmm@ietfa.amsl.com>; Mon, 20 May 2013 10:27:27 -0700 (PDT)
Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9F721F9622 for <dmm@ietf.org>; Mon, 20 May 2013 10:27:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4506; q=dns/txt; s=iport; t=1369070847; x=1370280447; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=KCzSu7TfaNzHzS8RAQlmsRgfY22vwCKqt7AUqj/RRU4=; b=QYegwzS7CLqKZPQE5BKoa6HkthGTVDPv74y5l4hrk1H8ab2qg9Cwj1nz rq2jJRFP3lBFGL5MQX3L1AEgP/ize0Phpsu9IxXFj+40GfeXE6jIQhHMr +SK3Yec+g0eJdyEaavpIPYNwcYvpM0ZgFyv3tWg3v2liladPWa2earXS5 g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AuAFAHZbmlGtJV2Z/2dsb2JhbABagwgwwUGBAhZ0gh8BAQEDAQEBAWsEBwUNAQgSBgpLCxcOAgQBDQUIE4dsBgy8DwSNXoESMQcCgnFhA6h4gw+BaAc3
X-IronPort-AV: E=Sophos;i="4.87,709,1363132800"; d="scan'208";a="212732607"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 20 May 2013 17:27:27 +0000
Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r4KHRQVY002563 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 May 2013 17:27:27 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.219]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Mon, 20 May 2013 12:27:26 -0500
From: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
To: Peter McCann <Peter.McCann@huawei.com>, Alper Yegin <alper.yegin@yegin.org>, "Charles E. Perkins" <charliep@computer.org>
Thread-Topic: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03
Thread-Index: AQHOVX9Le7q8ZFo0+U6J/MIwGOCS8A==
Date: Mon, 20 May 2013 17:27:26 +0000
Message-ID: <24C0F3E22276D9438D6F366EB89FAEA8102A4409@xmb-aln-x03.cisco.com>
In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716ED0202@dfweml512-mbx.china.huawei.com>
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.214]
Content-Type: text/plain; charset="iso-8859-2"
Content-ID: <2BAA7549023AEA448EFCB82215B8AC44@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dmm@ietf.org" <dmm@ietf.org>
Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 May 2013 17:27:32 -0000

Pete,

> We shouldn't require all the traffic to pay the price of centralization

I'm not suggesting that. Split model, with partial subset of the flows
going through a central anchor and part of the other traffic breaking out
locally is fine. My comment is not tie "cost" as the only argument for
enabling LBO models. Its a deployment consideration that drives that
decision. It may be about the availability of internet peering points, or
many other considerations.



> LI should be a very small proportion of the traffic, and those flows can
>be directed to a collection point as needed.

You mean small set of subscribers, or small portion of a subscriber
traffic. ?=20
If its later, I assumed the Communication Content (CC) for intercept (in
general) is HTTP+SMTP traffic which in most cases maps to 100% of the
subscriber traffic.



Sri







On 5/17/13 6:04 AM, "Peter McCann" <Peter.McCann@huawei.com> wrote:

>We shouldn't require all the traffic to pay the price of centralization
>just because some small subset of the flow need it.  LI should be a very
>small proportion of the traffic, and those flows can be directed to a
>collection point as needed.  If you really need per-flow, per-application
>charging, you can send meta-information about the flows to a charging
>collection box.  No need to send the flows themselves.
>
>-Pete
>
>
>Sri Gundavelli (sgundave) wrote:
>>=20
>>> Distributed solution: Take IP traffic directly from access router to
>>> the Internet.
>>=20
>>=20
>>=20
>>=20
>> Counter argument.
>>=20
>>=20
>> It implies, LI, Charging, DPI =A9etc on each of the distributed nodes.
>> Implies more "CAPEX and OPEX" ?
>>=20
>>=20
>> I'm not against distributed models and 6909 is the proof point. But,
>> IMO, it will hard to draw relation to cost models, based on traffic
>> exit points. You may need mobility hierarchy in the network for "n"
>> number of reasons and a centralized models for "m" number of reasons.
>> It more about deployment choice, dependent on many parameters.
>>=20
>>=20
>>=20
>>=20
>> Sri
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>> On 4/29/13 5:29 AM, "Alper Yegin" <alper.yegin@yegin.org> wrote:
>>=20
>>> Hi Charlie,
>>>=20
>>> No, it should be less.
>>>=20
>>> Distributed solution: Take IP traffic directly from access router to
>>> the Internet.
>>> Centralized solution: Take IP traffic from access router to a core
>>> router to the Internet.
>>>=20
>>> The latter suggests more CAPEX and OPEX.
>>>=20
>>> Alper
>>>=20
>>>=20
>>>=20
>>> On Apr 27, 2013, at 3:44 AM, Charles E. Perkins wrote:
>>>=20
>>>>=20
>>>> Hello Alper,
>>>>=20
>>>> I agree with your point, but it means that the total cost of the
>>>> distributed solution is even more expensive.... right?
>>>>=20
>>>> Regards,
>>>> Charlie P.
>>>>=20
>>>> On 4/26/2013 12:56 AM, Alper Yegin wrote:
>>>>> Hi Charlie,
>>>>>=20
>>>>>> - It is claimed that a centralized architecture requires more
>>>>>> resources
>>>>>>  than a distributed architecture.  This is usually false.  For
>>>>>>  instance, if a centralized node requires 100 units, and 100
>>>>>>  distributed nodes each require 1.03 units, the distributed
>>>>>>  architecture requires 3 more units overall.
>>>>> This would be true for tasks that can be performed either on the
>>>>> distributed node or on the central node.
>>>>> But the essential task for DMM systems, IP forwarding, is not of
>>>>> that nature.
>>>>> In centralized architecture, that task needs to be performed
>>>>> *both* at the edge node and also at the central node (and in fact
>>>>> even in
>>>>> between) before the packets hit the Internet/mobile device.
>>>>>=20
>>>>>=20
>>>>>> Even so, the additional expense of the distributed architecture
>>>>>> would often be a bargain for reasons of redundancy, resiliency,
>> etc.
>>>>>=20
>>>>> Alper
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> _______________________________________________
>>>>> dmm mailing list
>>>>> dmm@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/dmm
>>>>>=20
>>>>=20
>>>>=20
>>>> --
>>>> Regards,
>>>> Charlie P.
>>>>=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 sgundave@cisco.com  Mon May 20 10:30:02 2013
Return-Path: <sgundave@cisco.com>
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 88EF921F9632 for <dmm@ietfa.amsl.com>; Mon, 20 May 2013 10:30:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.732
X-Spam-Level: 
X-Spam-Status: No, score=-9.732 tagged_above=-999 required=5 tests=[AWL=0.867,  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 Y2Lojt3XmQ4p for <dmm@ietfa.amsl.com>; Mon, 20 May 2013 10:29:57 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id D9F7121F8A0C for <dmm@ietf.org>; Mon, 20 May 2013 10:29:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=814; q=dns/txt; s=iport; t=1369070997; x=1370280597; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=7HWBVPjKLU33Us/DHHhQi4O4myF6X4umd+OiDHEf518=; b=f9qPwbMimFg3KZ8ArJ266OYwELa5t5wV7PhNCH0zZ4Kl8jGEq+DVwGvF SeuY8Q5otz67S+HDquQSuEGeoC745mkmuwXAIbVUmExhzMWPBGCOl/ls/ VizD+nehGBcQaYDU0WHBqdGEAmlPzQXiYJmfZo9Xd6Z9qknHx3CX1emHo k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmIFAMBcmlGtJV2d/2dsb2JhbABagwiDJL5NgQIWdIIfAQEBAwF5BQ0BCBgKViUCBA4FCBOHbAa8Jo5wMQeCc2EDqHiDD4Im
X-IronPort-AV: E=Sophos;i="4.87,709,1363132800"; d="scan'208";a="212720987"
Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-8.cisco.com with ESMTP; 20 May 2013 17:29:55 +0000
Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r4KHTstD022911 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 20 May 2013 17:29:55 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.219]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.02.0318.004; Mon, 20 May 2013 12:29:54 -0500
From: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
To: Alper Yegin <alper.yegin@yegin.org>
Thread-Topic: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03
Thread-Index: AQHOVX+jAj8M+w0YU0qy7K5wZuE72w==
Date: Mon, 20 May 2013 17:29:53 +0000
Message-ID: <24C0F3E22276D9438D6F366EB89FAEA8102A4430@xmb-aln-x03.cisco.com>
In-Reply-To: <BB2BFAC2-DF2E-4A33-BD40-FA85474E797E@yegin.org>
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.214]
Content-Type: text/plain; charset="iso-8859-2"
Content-ID: <06931562E26DE541A7AEE4066DC33D50@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dmm@ietf.org" <dmm@ietf.org>
Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 May 2013 17:30:02 -0000

> If that were the case, then the operators wouldn't be offloading the
>subscriber IP traffic from WiFi to Internet.

Macro spectrum overload I though is a bigger consideration and off course
the use of cheaper access ..But, any ways as I'm saying split model is
fine and will be a dominant model.

Sri




On 5/20/13 12:24 AM, "Alper Yegin" <alper.yegin@yegin.org> wrote:

>
>On May 17, 2013, at 8:42 AM, Sri Gundavelli (sgundave) wrote:
>
>>>Distributed solution: Take IP traffic directly from access router to the
>>>Internet.
>>Counter argument.
>>It implies, LI, Charging, DPI =A9etc on each of the distributed nodes.
>>Implies more "CAPEX and OPEX" ?
>
>If that were the case, then the operators wouldn't be offloading the
>subscriber IP traffic from WiFi to Internet.
>
>Alper
>


From Peter.McCann@huawei.com  Mon May 20 16:29:27 2013
Return-Path: <Peter.McCann@huawei.com>
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 8C2EA21F9675 for <dmm@ietfa.amsl.com>; Mon, 20 May 2013 16:29:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.999
X-Spam-Level: 
X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, MANGLED_FORM=2.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 UZm0dDgNp9dq for <dmm@ietfa.amsl.com>; Mon, 20 May 2013 16:29:22 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 696C521F962E for <dmm@ietf.org>; Mon, 20 May 2013 16:29:21 -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 ARO31220; Mon, 20 May 2013 23:29:16 +0000 (GMT)
Received: from LHREML405-HUB.china.huawei.com (10.201.5.242) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 21 May 2013 00:29:07 +0100
Received: from DFWEML406-HUB.china.huawei.com (10.193.5.131) by lhreml405-hub.china.huawei.com (10.201.5.242) with Microsoft SMTP Server (TLS) id 14.1.323.7; Tue, 21 May 2013 00:29:13 +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; Mon, 20 May 2013 16:29:06 -0700
From: Peter McCann <Peter.McCann@huawei.com>
To: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>, Alper Yegin <alper.yegin@yegin.org>, "Charles E. Perkins" <charliep@computer.org>
Thread-Topic: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03
Thread-Index: AQHOUsFXHSVwrEMav0+4NP1W/j/J3pkJV//ggAV2bgD//+2okA==
Date: Mon, 20 May 2013 23:29:05 +0000
Message-ID: <5963DDF1F751474D8DEEFDCDBEE43AE716F460CF@dfweml512-mbx.china.huawei.com>
References: <5963DDF1F751474D8DEEFDCDBEE43AE716ED0202@dfweml512-mbx.china.huawei.com> <24C0F3E22276D9438D6F366EB89FAEA8102A4409@xmb-aln-x03.cisco.com>
In-Reply-To: <24C0F3E22276D9438D6F366EB89FAEA8102A4409@xmb-aln-x03.cisco.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.203]
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Cc: "dmm@ietf.org" <dmm@ietf.org>
Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 May 2013 23:29:27 -0000

Hi, Sri,

Sri Gundavelli (sgundave) wrote:
> Pete,
>=20
>> We shouldn't require all the traffic to pay the price of
>> centralization
>=20
> I'm not suggesting that. Split model, with partial subset of the flows
> going through a central anchor and part of the other traffic breaking
> out locally is fine. My comment is not tie "cost" as the only argument
> for enabling LBO models. Its a deployment consideration that drives
> that decision. It may be about the availability of internet peering
> points, or many other considerations.

Agree cost is not the only argument for local break-out.  But it is an
important one and I think it's appropriate to call it out in a requirements
document.

>> LI should be a very small proportion of the traffic, and those flows
>> can be directed to a collection point as needed.
>=20
> You mean small set of subscribers, or small portion of a subscriber
> traffic. ? If its later, I assumed the Communication Content (CC) for
> intercept (in general) is HTTP+SMTP traffic which in most cases maps to
> 100% of the subscriber traffic.

I meant a small number of subscribers.

Besides, as far as I know RFC 2804 is still IETF consensus.  Unless you wan=
t
to re-open the Raven discussions, we should not even be considering LI requ=
irements=20
in our work in IETF, let alone allowing them to drive us to an architecture=
 that is=20
grossly inefficient.

-Pete


>=20
>=20
>=20
> Sri
>=20
>=20
>=20
>=20
>=20
>=20
>=20
> On 5/17/13 6:04 AM, "Peter McCann" <Peter.McCann@huawei.com> wrote:
>=20
>> We shouldn't require all the traffic to pay the price of centralization
>> just because some small subset of the flow need it.  LI should be a
>> very small proportion of the traffic, and those flows can be directed
>> to a collection point as needed.  If you really need per-flow,
>> per-application charging, you can send meta-information about the flows
>> to a charging collection box.  No need to send the flows themselves.
>>=20
>> -Pete
>>=20
>>=20
>> Sri Gundavelli (sgundave) wrote:
>>>=20
>>>> Distributed solution: Take IP traffic directly from access router to
>>>> the Internet.
>>>=20
>>>=20
>>>=20
>>>=20
>>> Counter argument.
>>>=20
>>>=20
>>> It implies, LI, Charging, DPI =A9etc on each of the distributed nodes.
>>> Implies more "CAPEX and OPEX" ?
>>>=20
>>>=20
>>> I'm not against distributed models and 6909 is the proof point. But,
>>> IMO, it will hard to draw relation to cost models, based on traffic
>>> exit points. You may need mobility hierarchy in the network for "n"
>>> number of reasons and a centralized models for "m" number of reasons.
>>> It more about deployment choice, dependent on many parameters.
>>>=20
>>>=20
>>>=20
>>>=20
>>> Sri
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>> On 4/29/13 5:29 AM, "Alper Yegin" <alper.yegin@yegin.org> wrote:
>>>=20
>>>> Hi Charlie,
>>>>=20
>>>> No, it should be less.
>>>>=20
>>>> Distributed solution: Take IP traffic directly from access router to
>>>> the Internet. Centralized solution: Take IP traffic from access
>>>> router to a core router to the Internet.
>>>>=20
>>>> The latter suggests more CAPEX and OPEX.
>>>>=20
>>>> Alper
>>>>=20
>>>>=20
>>>>=20
>>>> On Apr 27, 2013, at 3:44 AM, Charles E. Perkins wrote:
>>>>=20
>>>>>=20
>>>>> Hello Alper,
>>>>>=20
>>>>> I agree with your point, but it means that the total cost of the
>>>>> distributed solution is even more expensive.... right?
>>>>>=20
>>>>> Regards,
>>>>> Charlie P.
>>>>>=20
>>>>> On 4/26/2013 12:56 AM, Alper Yegin wrote:
>>>>>> Hi Charlie,
>>>>>>=20
>>>>>>> - It is claimed that a centralized architecture requires more
>>>>>>> resources  than a distributed architecture.  This is usually
>>>>>>> false.  For  instance, if a centralized node requires 100
>>>>>>> units, and 100  distributed nodes each require 1.03 units, the
>>>>>>> distributed  architecture requires 3 more units overall.
>>>>>> This would be true for tasks that can be performed either on the
>>>>>> distributed node or on the central node.
>>>>>> But the essential task for DMM systems, IP forwarding, is not of
>>>>>> that nature.
>>>>>> In centralized architecture, that task needs to be performed
>>>>>> *both* at the edge node and also at the central node (and in
>>>>>> fact even in
>>>>>> between) before the packets hit the Internet/mobile device.
>>>>>>=20
>>>>>>=20
>>>>>>> Even so, the additional expense of the distributed architecture
>>>>>>> would often be a bargain for reasons of redundancy, resiliency,
>>> etc.
>>>>>>=20
>>>>>> Alper
>>>>>>=20



From sgundave@cisco.com  Mon May 20 18:21:58 2013
Return-Path: <sgundave@cisco.com>
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 410BA21F960B for <dmm@ietfa.amsl.com>; Mon, 20 May 2013 18:21:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.999
X-Spam-Level: 
X-Spam-Status: No, score=-9.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_44=0.6, 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 QqZi4rHtz0yh for <dmm@ietfa.amsl.com>; Mon, 20 May 2013 18:21:52 -0700 (PDT)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 9517721F95F1 for <dmm@ietf.org>; Mon, 20 May 2013 18:21:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2059; q=dns/txt; s=iport; t=1369099312; x=1370308912; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=UZ9oALqeY3pFQWuRvfWHxKPRhjQ3aFfPqC4hpjozLcw=; b=iK41bsxLwrF2lVCMzKH82Crt0SvrhOsp/hnfj38IcsSHzBUpxTNiyQnT DioMdOFEarg42juUqpvfH4OgLdux6izksglUk7f1MTQAe6Kqujf4lYBHM iJ0+azHgrsSgXKlRudClEIIKj8dvwab1KfI36vtYlhKfWhjCwAq1xKuFM k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: At4FADDLmlGtJXHB/2dsb2JhbABagwgwwU+BBhZ0giEBBHkSAQgSEFYXDgIEAQ0FCIgFvFeNXoESMQeCc2EDqHiDD4Im
X-IronPort-AV: E=Sophos;i="4.87,711,1363132800"; d="scan'208";a="212847193"
Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-7.cisco.com with ESMTP; 21 May 2013 01:21:46 +0000
Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r4L1LkG1029870 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 21 May 2013 01:21:46 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.219]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.02.0318.004; Mon, 20 May 2013 20:21:46 -0500
From: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
To: Peter McCann <Peter.McCann@huawei.com>, Alper Yegin <alper.yegin@yegin.org>, "Charles E. Perkins" <charliep@computer.org>
Thread-Topic: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03
Thread-Index: AQHOVcGOQ9OiU0WyzUm8Qj9Ew08bGg==
Date: Tue, 21 May 2013 01:21:45 +0000
Message-ID: <24C0F3E22276D9438D6F366EB89FAEA8102A51D2@xmb-aln-x03.cisco.com>
In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716F460CF@dfweml512-mbx.china.huawei.com>
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.214]
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <9B66421E0955D8498528A0FD47F18B2E@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dmm@ietf.org" <dmm@ietf.org>
Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 May 2013 01:21:58 -0000

Hi Pete,


On 5/20/13 4:29 PM, "Peter McCann" <Peter.McCann@huawei.com> wrote:


>
>Agree cost is not the only argument for local break-out.  But it is an
>important one and I think it's appropriate to call it out in a
>requirements
>document.


Its fine. But, there is no data point to prove that one option is cheaper
than the other... :)



>
>>>LI should be a very small proportion of the traffic, and those flows
>>>can be directed to a collection point as needed.
>>You mean small set of subscribers, or small portion of a subscriber
>>traffic. ? If its later, I assumed the Communication Content (CC) for
>>intercept (in general) is HTTP+SMTP traffic which in most cases maps to
>>100% of the subscriber traffic.
>
>I meant a small number of subscribers.
>
>Besides, as far as I know RFC 2804 is still IETF consensus.  Unless you
>want
>to re-open the Raven discussions, we should not even be considering LI
>requirements
>in our work in IETF, let alone allowing them to drive us to an
>architecture that is
>grossly inefficient.


I don't want to re-open RFC-2804 discussions, at least for now and surely
not in this WG. As I commented in OPSAWG some time back, I completely
disagree with that document and IETF's past views on this topic. It surely
needs a review to check its applicability and relevance for the current
times. To me its a regulatory requirement that operators need to comply
with, else they cannot deploy that service.

Now, in the DMM context, it is relevant when we justify models based on
such parameters such as cost ..etc. We cannot forget the key services and
draw some random conclusions. BTW, the cost argument may turn out to be
true=8Abut we have insufficient data here. Better approach would be to
consider both the options, but not make claims using "cost" as the driver.

Any case, my entry into this discussion was more with a general comment.
I'm not asking for any changes in the Reqs document=8A



Regards
Sri


















>
>-Pete


From jouni.nospam@gmail.com  Sun May 26 08:37:06 2013
Return-Path: <jouni.nospam@gmail.com>
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 1A2D921F8E8F for <dmm@ietfa.amsl.com>; Sun, 26 May 2013 08:37:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.999
X-Spam-Level: 
X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[AWL=0.600,  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 rh1pmN6l3nov for <dmm@ietfa.amsl.com>; Sun, 26 May 2013 08:37:00 -0700 (PDT)
Received: from mail-ee0-f51.google.com (mail-ee0-f51.google.com [74.125.83.51]) by ietfa.amsl.com (Postfix) with ESMTP id 086E521F8B98 for <dmm@ietf.org>; Sun, 26 May 2013 08:36:59 -0700 (PDT)
Received: by mail-ee0-f51.google.com with SMTP id e51so3498080eek.10 for <dmm@ietf.org>; Sun, 26 May 2013 08:36:59 -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=iVxaSil2OMnVHNZJOZvqpLnkiWmKGcf9xM6FsRqucXM=; b=UQSB0dIT4aSSiA27N3Pq4hSYMoQN+rEp3o0C6KHOlBcjAVkp7oczo5GsNl3ax7rCbO NtWOb2Jf0m/At7ETqzyUAshqWS9FolqbDHXpSRcuBoozgu/JXWGxsD5gm76o1miMhMFw yy2LOH/ukEcjV9SLmpqKo5/iN/mrSsLUm+5FCBIJzpFCRNG4Cy0A500WG06yiHjIDMCR nvFroKXWkw7vJCUDTkfBgTINX8RksX0UxPVz2DQ7wAoLQk3QDQXUobXjKw7XXYz/RXfu UdzifZV6pzTn0nHSClsY4IHNHPCZQ/+/P13ud1qoKUTdfLt2gn9E8ZBiMZAasYPqMII/ r+VQ==
X-Received: by 10.14.87.9 with SMTP id x9mr50755145eee.3.1369582619163; Sun, 26 May 2013 08:36:59 -0700 (PDT)
Received: from [188.117.15.107] ([188.117.15.107]) by mx.google.com with ESMTPSA id bp51sm36082896eeb.5.2013.05.26.08.36.57 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 26 May 2013 08:36:58 -0700 (PDT)
From: Jouni <jouni.nospam@gmail.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Date: Sun, 26 May 2013 18:36:54 +0300
Message-Id: <16964F03-F728-4342-A2EF-7CF345C135FA@gmail.com>
To: dmm@ietf.org
Mime-Version: 1.0 (Apple Message framework v1283)
X-Mailer: Apple Mail (2.1283)
Cc: dmm-chairs@tools.ietf.org
Subject: [DMM] Call for agenda items for IETF#87 Berlin meeting
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 26 May 2013 15:37:06 -0000

Folks,

We have requested for two hour meeting slot. If you feel like
presenting your work (be that in the current charter or not),
send a request to the co-chairs. Obviously, chartered items
will be prioritized over other topics.

- Jouni & Julien


From charliep@computer.org  Wed May 29 14:42:14 2013
Return-Path: <charliep@computer.org>
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 290BA21F96D3 for <dmm@ietfa.amsl.com>; Wed, 29 May 2013 14:42:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.299
X-Spam-Level: 
X-Spam-Status: No, score=-0.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MANGLED_FORM=2.3]
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 s93vwZ+WIP4K for <dmm@ietfa.amsl.com>; Wed, 29 May 2013 14:42:09 -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 910BE21F975D for <dmm@ietf.org>; Wed, 29 May 2013 14:42:07 -0700 (PDT)
Received: from [107.1.141.74] (helo=[192.168.255.20]) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.67) (envelope-from <charliep@computer.org>) id 1Uho8B-0003PS-Uf; Wed, 29 May 2013 17:42:04 -0400
Message-ID: <51A67623.4040705@computer.org>
Date: Wed, 29 May 2013 14:41:55 -0700
From: "Charles E. Perkins" <charliep@computer.org>
Organization: Saratoga Blue Skies
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: h chan <h.anthony.chan@huawei.com>
References: <87ECA3CB-AC73-4981-BCB0-9ED2A7F5DB65@yegin.org> <24C0F3E22276D9438D6F366EB89FAEA81028E99A@xmb-aln-x03.cisco.com> <5963DDF1F751474D8DEEFDCDBEE43AE716ED0202@dfweml512-mbx.china.huawei.com> <BA8F04F6-4B33-4F0D-B430-2BC425C49F5E@research.att.com> <6E31144C030982429702B11D6746B98C37087D2A@szxeml557-mbs.china.huawei.com>
In-Reply-To: <6E31144C030982429702B11D6746B98C37087D2A@szxeml557-mbs.china.huawei.com>
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: 8bit
X-ELNK-Trace: 137d7d78656ed6919973fd6a8f21c4f2d780f4a490ca6956d5d4673fe7faad862428a6fbc565cc35fc56628f2a0d11c3350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 107.1.141.74
Cc: Peter McCann <Peter.McCann@huawei.com>, "dmm@ietf.org" <dmm@ietf.org>
Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 May 2013 21:42:14 -0000

Hello Anthony,

I think the new text is worthwhile, but "increase" should
be "increases".

Regards,
Charlie P.


On 5/17/2013 2:07 PM, h chan wrote:
> The original comment was on "resources" in the following problem statement:
>
>     PS3:  Low scalability of centralized tunnel management and mobility
>           context maintenance
>
>           Setting up tunnels through a central anchor and maintaining
>           mobility context for each MN therein requires more resources in
>           a centralized design, thus reducing scalability.  Distributing
>           the tunnel maintenance function and the mobility context
>           maintenance function among different network entities can
>           increase scalability.
>
> How about revising PS3 to the following and comparing resources:
>
>     PS3:  Low scalability of centralized tunnel management and mobility
>           context maintenance
>
>           Setting up tunnels through a central anchor and maintaining
>           mobility context for each MN in a centralized design increase
>           the processing at the anchor as the number of MNs increases.
>           Distributing the tunnel maintenance function and the mobility
>           context maintenance function among different network entities
>           with proper signaling protocol design can increase scalability.
>
> H Anthony Chan
>
> -----Original Message-----
> From: dmm-bounces@ietf.org [mailto:dmm-bounces@ietf.org] On Behalf Of KIM, BYOUNG-JO J (BYOUNG-JO)
> Sent: Friday, May 17, 2013 9:24 AM
> To: Peter McCann
> Cc: dmm@ietf.org
> Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03
>
> Very much agreed.
>
> Also, distributed solutions can be concentrated as deployment needs dictate using layer 2 means, as is done often in many present networks.
>
> can't do the opposite with centralized solutions without a whole lot of acrobatics.
>
> "J" Kim
> AT&T Labs - Research
> http://sites.google.com/site/macsbug/
>
> On May 17, 2013, at 9:04 AM, Peter McCann wrote:
>
>> We shouldn't require all the traffic to pay the price of
>> centralization just because some small subset of the flow need it.  LI
>> should be a very small proportion of the traffic, and those flows can
>> be directed to a collection point as needed.  If you really need
>> per-flow, per-application charging, you can send meta-information
>> about the flows to a charging collection box.  No need to send the flows themselves.
>>
>> -Pete
>>
>>
>> Sri Gundavelli (sgundave) wrote:
>>>> Distributed solution: Take IP traffic directly from access router to
>>>> the Internet.
>>>
>>>
>>>
>>> Counter argument.
>>>
>>>
>>> It implies, LI, Charging, DPI Šetc on each of the distributed nodes.
>>> Implies more "CAPEX and OPEX" ?
>>>
>>>
>>> I'm not against distributed models and 6909 is the proof point. But,
>>> IMO, it will hard to draw relation to cost models, based on traffic
>>> exit points. You may need mobility hierarchy in the network for "n"
>>> number of reasons and a centralized models for "m" number of reasons.
>>> It more about deployment choice, dependent on many parameters.
>>>
>>>
>>>
>>>
>>> Sri
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 4/29/13 5:29 AM, "Alper Yegin" <alper.yegin@yegin.org> wrote:
>>>
>>>> Hi Charlie,
>>>>
>>>> No, it should be less.
>>>>
>>>> Distributed solution: Take IP traffic directly from access router to
>>>> the Internet.
>>>> Centralized solution: Take IP traffic from access router to a core
>>>> router to the Internet.
>>>>
>>>> The latter suggests more CAPEX and OPEX.
>>>>
>>>> Alper
>>>>
>>>>
>>>>
>>>> On Apr 27, 2013, at 3:44 AM, Charles E. Perkins wrote:
>>>>
>>>>> Hello Alper,
>>>>>
>>>>> I agree with your point, but it means that the total cost of the
>>>>> distributed solution is even more expensive.... right?
>>>>>
>>>>> Regards,
>>>>> Charlie P.
>>>>>
>>>>> On 4/26/2013 12:56 AM, Alper Yegin wrote:
>>>>>> Hi Charlie,
>>>>>>
>>>>>>> - It is claimed that a centralized architecture requires more
>>>>>>> resources than a distributed architecture.  This is usually
>>>>>>> false.  For instance, if a centralized node requires 100 units,
>>>>>>> and 100 distributed nodes each require 1.03 units, the
>>>>>>> distributed architecture requires 3 more units overall.
>>>>>> This would be true for tasks that can be performed either on the
>>>>>> distributed node or on the central node.
>>>>>> But the essential task for DMM systems, IP forwarding, is not of
>>>>>> that nature.
>>>>>> In centralized architecture, that task needs to be performed
>>>>>> *both* at the edge node and also at the central node (and in fact
>>>>>> even in
>>>>>> between) before the packets hit the Internet/mobile device.
>>>>>>
>>>>>>
>>>>>>> Even so, the additional expense of the distributed architecture
>>>>>>> would often be a bargain for reasons of redundancy, resiliency,
>>> etc.
>>>>>> Alper
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> dmm mailing list
>>>>>> dmm@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/dmm
>>>>>>
>>>>>
>>>>> --
>>>>> Regards,
>>>>> Charlie P.
>>>>>
>>>> _______________________________________________
>>>> dmm mailing list
>>>> dmm@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/dmm
>>> _______________________________________________
>>> dmm mailing list
>>> dmm@ietf.org
>>> https://www.ietf.org/mailman/listinfo/dmm
>>
>>
>> _______________________________________________
>> dmm mailing list
>> dmm@ietf.org
>> https://www.ietf.org/mailman/listinfo/dmm
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
> _______________________________________________
> dmm mailing list
> dmm@ietf.org
> https://www.ietf.org/mailman/listinfo/dmm
>


-- 
Regards,
Charlie P.