From nobody Fri May 2 14:36:52 2014 Return-Path: X-Original-To: aeon@ietfa.amsl.com Delivered-To: aeon@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 28FAF1A6F38 for ; Fri, 2 May 2014 14:36:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.151 X-Spam-Level: X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W5jWfkRab2sg for ; Fri, 2 May 2014 14:36:47 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 5B6491A0A7B for ; Fri, 2 May 2014 14:36:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3739; q=dns/txt; s=iport; t=1399066605; x=1400276205; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=fdy5hIFAL52aIUgX0uNHgtS6U4LdzPAomsSbdc5zy7c=; b=FfLD9RF6WeIGVqje/HsZViDyYJFxpaGTicHCtiP04bEI8onaMBhAvjNn t/G3Awo5fxPq7C33jrXNiKnQ/y7BqQyhvVQ6Fk/eDXAVcQETxqHVw53KV cj/CRhmDgcXHmVlUio5BNXyr3p2Q0AwfUNpPaGSjdHmLlRL3iIRMZ1AcX k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUMAOIOZFOtJA2B/2dsb2JhbABZgkJET1iEBcBIgQ8WdIIlAQEBBIEJAgEIBAoDAwECKAchERQJCAIEARIJiCQDEQ3DcQ2GRBeMO4FGAQE+GIQ5BJc+gXKNFIVbgzRtgQk5 X-IronPort-AV: E=Sophos;i="4.97,974,1389744000"; d="scan'208,217";a="322061108" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-6.cisco.com with ESMTP; 02 May 2014 21:36:44 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s42LaiDh001489 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 2 May 2014 21:36:44 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.148]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.03.0123.003; Fri, 2 May 2014 16:36:44 -0500 From: "Charles Eckel (eckelcu)" To: Rong Zhang , "aeon@ietf.org" Thread-Topic: [Aeon] COllaborative NETwork vs AEON? Thread-Index: AQHPYiIfSItL6wB6l0mtXnh0e1H/d5stt2sA Date: Fri, 2 May 2014 21:36:43 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.154.176.77] Content-Type: multipart/alternative; boundary="_000_CF895D52276D6eckelcuciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/51eZjjf2PipIAW2t8LAw_zx8xxs Subject: Re: [Aeon] COllaborative NETwork vs AEON? X-BeenThere: aeon@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Enabled Open Networking \(AEON\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 May 2014 21:36:49 -0000 --_000_CF895D52276D6eckelcuciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Rong, Sorry for the delay in responding. I am not sure I understand what you are = asking for here, but perhaps this previous thread will be of help: http://www.ietf.org/mail-archive/web/aeon/current/msg00033.html Cheers, Charles From: Rong Zhang > Date: Sunday, April 27, 2014 at 7:07 AM To: "aeon@ietf.org" > Subject: [Aeon] COllaborative NETwork vs AEON? Hello all, I have been observing the comments here, it seems that some operators are d= iscussing the current problems about COllaborative NETwork and how current = 3GPP Rx is not sufficient, and also some requirements and gap analysis. But for Aeon's case, we haven't seen any operators illustrating how they ar= e similarl between COllaborative NETwork and AEON's problem. Can anybody fr= om AEON kindly help to elaborate more here? cheers, Rong Zhang --_000_CF895D52276D6eckelcuciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Rong,

Sorry for the delay in responding. I am not sure I understand what you= are asking for here, but perhaps this previous thread will be of help:
http://www.ietf.org/mail-archive/web/aeon/current/msg00033.html

Cheers,
Charles

From: Rong Zhang <rzhang.ietf@gmail.com>
Date: Sunday, April 27, 2014 at 7:0= 7 AM
To: "aeon@ietf.org" <aeon@i= etf.org>
Subject: [Aeon] COllaborative NETwo= rk vs AEON?

Hello all,
 
I have been observing the comments here, it seems that some operators = are discussing the current problems about COllaborative NETwork and how cur= rent 3GPP Rx is not sufficient, and also some requirements and gap analysis= .
 
But for Aeon's case, we haven't seen any operators illustrating how th= ey are similarl between COllaborative NETwork and AEON's problem. Can anybo= dy from AEON kindly help to elaborate more here?
 
cheers,
 
Rong Zhang
 --_000_CF895D52276D6eckelcuciscocom_-- From nobody Sat May 3 20:06:13 2014 Return-Path: X-Original-To: aeon@ietfa.amsl.com Delivered-To: aeon@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4101A0144 for ; Sat, 3 May 2014 20:06:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kdDIX-OBFXKu for ; Sat, 3 May 2014 20:06:09 -0700 (PDT) Received: from mail-oa0-x244.google.com (mail-oa0-x244.google.com [IPv6:2607:f8b0:4003:c02::244]) by ietfa.amsl.com (Postfix) with ESMTP id 2A6581A0142 for ; Sat, 3 May 2014 20:06:09 -0700 (PDT) Received: by mail-oa0-f68.google.com with SMTP id i7so402555oag.11 for ; Sat, 03 May 2014 20:06:06 -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=UV4i402kfVsy2wni7xYyVY9vuxkwLuCV824T2ELbz6o=; b=NAorXVYr5bhoEcnhMidhEamdnOCXs7680L9kop0tZ3sHx7QRAGbMpO2Pz5Z1+MzVp2 kVvWF0ivRKxLitbYAFdcSsmFuTgSUUj6waWBzUX3ET6JAXh2qAsMJ3yi5Lh5INQ14jwh 5+pGX1qmhFy/fnX4V51JgxHFdv7Kh9yW3kIZshIpMYikNLXeKX7baEyjrxQNx6p/oPbr ydARJNABCNEEHpp5aLZfwAIa6rEs0zXx0808in44iWfuvWCpZR96IeHiIq+eAc1L+cai +m1Q/VgICcPasB2U0mZwr4b9m3tGOIBl9qsM1VdsX99PtC8Wr6w61mYIhVTeyWCAwep+ Japg== MIME-Version: 1.0 X-Received: by 10.60.37.99 with SMTP id x3mr25671151oej.2.1399172766189; Sat, 03 May 2014 20:06:06 -0700 (PDT) Received: by 10.76.0.108 with HTTP; Sat, 3 May 2014 20:06:06 -0700 (PDT) In-Reply-To: References: Date: Sun, 4 May 2014 11:06:06 +0800 Message-ID: From: Rong Zhang To: "Charles Eckel (eckelcu)" Content-Type: multipart/alternative; boundary=089e01176279b54bf804f88a4b0e Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/35DM9q_KhRrYYVQQkuXMmsCzDxI Cc: "aeon@ietf.org" Subject: Re: [Aeon] COllaborative NETwork vs AEON? X-BeenThere: aeon@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Enabled Open Networking \(AEON\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 May 2014 03:06:11 -0000 --089e01176279b54bf804f88a4b0e Content-Type: text/plain; charset=UTF-8 Hi Charles, What I mean is that draft-eckel-aeon-problem-statement-01 have too many use cases and solutions related content, but I see: http://www.ietf.org/id/draft-fan-intarea-conet-ps-uc-00.txt quite focus on problem statement, so I would like to suggest that we start from second draft about PS, some of your draft could be merged into that draft. and then we could have seperate requirement draft( which maybe from AEON PS), and another gap analsysis draft. cheers. Rong Zhang On Sat, May 3, 2014 at 5:36 AM, Charles Eckel (eckelcu) wrote: > Hi Rong, > > Sorry for the delay in responding. I am not sure I understand what you > are asking for here, but perhaps this previous thread will be of help: > http://www.ietf.org/mail-archive/web/aeon/current/msg00033.html > > Cheers, > Charles > > From: Rong Zhang > Date: Sunday, April 27, 2014 at 7:07 AM > To: "aeon@ietf.org" > Subject: [Aeon] COllaborative NETwork vs AEON? > > Hello all, > > I have been observing the comments here, it seems that some operators are > discussing the current problems about COllaborative NETwork and how current > 3GPP Rx is not sufficient, and also some requirements and gap analysis. > > But for Aeon's case, we haven't seen any operators illustrating how they > are similarl between COllaborative NETwork and AEON's problem. Can anybody > from AEON kindly help to elaborate more here? > > cheers, > > Rong Zhang > > --089e01176279b54bf804f88a4b0e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Charles,
=C2=A0
What I mean is that
= draft-eckel-aeon-problem-statement-01 have too many use cases and solutions= related content,
=C2=A0
but I see:
http://www.ietf.org/id/draft-= fan-intarea-conet-ps-uc-00.txt=C2=A0quite focus on problem state= ment,
=C2=A0
so I would like to suggest that we= start from second draft about PS, some of your draft could be merged into = that draft.
and then we could have seperate requirem= ent draft( which maybe from AEON PS), and another gap analsysis draft.
=C2=A0
cheers.
=C2=A0
Rong Zhang


On Sat, May 3, 2014 at 5:36 AM, Charles Eckel (eckelcu) <eckelcu= @cisco.com> wrote:
Hi Rong,

Sorry for the delay in responding. I am not sure I understand what you= are asking for here, but perhaps this previous thread will be of help:

Cheers,
Charles

From: Rong Zhang <rzhang.ietf@gmail.com><= br> Date: Sunday, April 27, 2014 at 7:0= 7 AM
To: "aeon@ietf.org" <aeon@ietf.org>
Subject: [Aeon] COllaborative NETwo= rk vs AEON?

Hello all,
=C2=A0
I have been observing the comments here, it seems that some operators = are discussing the current problems about COllaborative NETwork and how cur= rent 3GPP Rx is not sufficient, and also some requirements and gap analysis= .
=C2=A0
But for Aeon's case, we haven't seen any operators illustratin= g how they are similarl between COllaborative NETwork and AEON's proble= m. Can anybody from AEON kindly help to=C2=A0elaborate more here?
=C2=A0
cheers,
=C2=A0
Rong Zhang

--089e01176279b54bf804f88a4b0e-- From nobody Thu May 8 11:48:37 2014 Return-Path: X-Original-To: aeon@ietfa.amsl.com Delivered-To: aeon@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 348541A00D3 for ; Thu, 8 May 2014 11:48:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.151 X-Spam-Level: X-Spam-Status: No, score=-10.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nZZNRLsEPgzJ for ; Thu, 8 May 2014 11:48:33 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 132DC1A00D8 for ; Thu, 8 May 2014 11:48:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8032; q=dns/txt; s=iport; t=1399574908; x=1400784508; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=+oipCyDQPF/iVIqqjSbswwTWHYfF2rLr8sgcjKinsrM=; b=EcKvCJeP5lzg5c1BlFBaAjpFEcVDGcCrE/v3jq/SO3x4lj1I08qtajg2 uyCjctsBk5P8y9vWjYA8MhViy1Cv1YhrboWi/T0arEQFXy9ix+B3mD5Db MK6vS850m7LgQ4repTTdqft0be9PbzJVNLbQtsM1+ZhtM7azPUa3/pfIg Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiUFAH/Qa1OtJV2b/2dsb2JhbABZgkJET1jFYQGBExZ0giUBAQEEeRACAQgOAwMBAigHIREUCQgCBA4FCRKIEgMRDclxDYYvF4w7gUYBAT4RB4Q/BJdGgXKNGoVhgzZtgQk5 X-IronPort-AV: E=Sophos;i="4.97,1012,1389744000"; d="scan'208,217";a="42210075" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-8.cisco.com with ESMTP; 08 May 2014 18:48:28 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s48ImSx9001202 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 8 May 2014 18:48:28 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.148]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Thu, 8 May 2014 13:48:27 -0500 From: "Charles Eckel (eckelcu)" To: Rong Zhang Thread-Topic: [Aeon] COllaborative NETwork vs AEON? Thread-Index: AQHPYiIfSItL6wB6l0mtXnh0e1H/d5stt2sAgAJjtgCABttDgA== Date: Thu, 8 May 2014 18:48:27 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.154.176.26] Content-Type: multipart/alternative; boundary="_000_CF911A2D27AE8eckelcuciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/aeZ7bJfZCVH2QJtHac_CkJvHhkA Cc: "aeon@ietf.org" Subject: Re: [Aeon] COllaborative NETwork vs AEON? X-BeenThere: aeon@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Enabled Open Networking \(AEON\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 May 2014 18:48:35 -0000 --_000_CF911A2D27AE8eckelcuciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Rong, Thanks for clarifying. There are pros and cons between combining topics int= o a single document vs. having several smaller documents. It would be relat= ively straightforward to divide the drafts as you suggest, and it would pro= bably simplify merging information in the AEON and CONET drafts as well. Cheers, Charles From: Rong Zhang > Date: Saturday, May 3, 2014 at 8:06 PM To: Charles Eckel > Cc: "aeon@ietf.org" > Subject: Re: [Aeon] COllaborative NETwork vs AEON? Hi Charles, What I mean is that draft-eckel-aeon-problem-statement-01 have too many use cases and solutions= related content, but I see: http://www.ietf.org/id/draft-fan-intarea-conet-ps-uc-00.txt quite focus on = problem statement, so I would like to suggest that we start from second draft about PS, some o= f your draft could be merged into that draft. and then we could have seperate requirement draft( which maybe from AEON PS= ), and another gap analsysis draft. cheers. Rong Zhang On Sat, May 3, 2014 at 5:36 AM, Charles Eckel (eckelcu) > wrote: Hi Rong, Sorry for the delay in responding. I am not sure I understand what you are = asking for here, but perhaps this previous thread will be of help: http://www.ietf.org/mail-archive/web/aeon/current/msg00033.html Cheers, Charles From: Rong Zhang > Date: Sunday, April 27, 2014 at 7:07 AM To: "aeon@ietf.org" > Subject: [Aeon] COllaborative NETwork vs AEON? Hello all, I have been observing the comments here, it seems that some operators are d= iscussing the current problems about COllaborative NETwork and how current = 3GPP Rx is not sufficient, and also some requirements and gap analysis. But for Aeon's case, we haven't seen any operators illustrating how they ar= e similarl between COllaborative NETwork and AEON's problem. Can anybody fr= om AEON kindly help to elaborate more here? cheers, Rong Zhang --_000_CF911A2D27AE8eckelcuciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi Rong,

Thanks for clarifying. There are pros and cons between combining topic= s into a single document vs. having several smaller documents. It would be = relatively straightforward to divide the drafts as you suggest, and it woul= d probably simplify merging information in the AEON and CONET drafts as well.

Cheers,
Charles
 
From: Rong Zhang <rzhang.ietf@gmail.com>
Date: Saturday, May 3, 2014 at 8:06= PM
To: Charles Eckel <eckelcu@cisco.com>
Cc: "aeon@ietf.org" <aeon@i= etf.org>
Subject: Re: [Aeon] COllaborative N= ETwork vs AEON?

Hi Charles,
 
What I mean is that
draft-eckel-aeon-problem-statement-01 have too many use cases and solu= tions related content,
 
but I see:
 
so I would like to suggest that we start from second draft about= PS, some of your draft could be merged into that draft.
and then we could have seperate requirement draft( which maybe f= rom AEON PS), and another gap analsysis draft.
 
cheers.
 
Rong Zhang


On Sat, May 3, 2014 at 5:36 AM, Charles Eckel (e= ckelcu) <eckelcu@cisco.co= m> wrote:
Hi Rong,

Sorry for the delay in responding. I am not sure I understand what you= are asking for here, but perhaps this previous thread will be of help:

Cheers,
Charles

From: Rong Zhang <rzhang.ietf@gmail.com><= br> Date: Sunday, April 27, 2014 at 7:0= 7 AM
To: "aeon@ietf.org" <aeon@ietf.org>
Subject: [Aeon] COllaborative NETwo= rk vs AEON?

Hello all,
 
I have been observing the comments here, it seems that some operators = are discussing the current problems about COllaborative NETwork and how cur= rent 3GPP Rx is not sufficient, and also some requirements and gap analysis= .
 
But for Aeon's case, we haven't seen any operators illustrating how th= ey are similarl between COllaborative NETwork and AEON's problem. Can anybo= dy from AEON kindly help to elaborate more here?
 
cheers,
 
Rong Zhang

 --_000_CF911A2D27AE8eckelcuciscocom_-- From nobody Thu May 8 21:00:14 2014 Return-Path: X-Original-To: aeon@ietfa.amsl.com Delivered-To: aeon@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D65F11A01BB for ; Thu, 8 May 2014 21:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZyKc8dvRnNsY for ; Thu, 8 May 2014 21:00:10 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3661A0196 for ; Thu, 8 May 2014 21:00:09 -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.7-GA FastPath queued) with ESMTP id BDY86188; Fri, 09 May 2014 04:00:04 +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.3.158.1; Fri, 9 May 2014 04:58:21 +0100 Received: from NKGEML402-HUB.china.huawei.com (10.98.56.33) by lhreml406-hub.china.huawei.com (10.201.5.243) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 9 May 2014 05:00:02 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.206]) by nkgeml402-hub.china.huawei.com ([10.98.56.33]) with mapi id 14.03.0158.001; Fri, 9 May 2014 11:59:58 +0800 From: Sheng Jiang To: "aeon@ietf.org" Thread-Topic: New Version Notification for draft-jiang-intarea-conet-gap-analysis-00.txt Thread-Index: AQHPazk6oYvLJI1BoEmQF4ap7BNXMZs3nbTQ Date: Fri, 9 May 2014 03:59:57 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AE45940@nkgeml512-mbx.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/RgRwjkOgaQ-DIOGYDHA5OA3sfXc Cc: "zhangr@gsta.com" Subject: [Aeon] FW: New Version Notification for draft-jiang-intarea-conet-gap-analysis-00.txt X-BeenThere: aeon@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Enabled Open Networking \(AEON\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 04:00:13 -0000 SGksIGFsbCwNCg0KV2UgaGF2ZSBqdXN0IHN1Ym1pdHRlZCBhIGdhcCBhbmFseXNpcyBmb3IgQ09s bGFib3JhdGl2ZSBORVR3b3JrIChDT05FVCkuDQoNCkFic3RyYWN0Og0KICAgSW4gb3JkZXIgdG8g ZWZmaWNpZW50bHkgZGlzdGluZ3Vpc2ggSUNQcycgdHJhZmZpYywgYSBuZXcgbmV0d29yaw0KICAg b3BlcmF0aW9uIG1vZGVsIC0gQ09sbGFib3JhdGl2ZSBORVR3b3JrIGlzIHByb3Bvc2VkLiAgVGhl IHRyYWZmaWMNCiAgIHJlY29nbml6YXRpb24gaXMgYmFzZWQgb24gdHJhZmZpYyBvZiBJQ1BzJyBw cm9kdWN0cyBhY3RpdmVseSBjYXJyaWVzDQogICBjb2xsYWJvcmF0aXZlIGlkZW50aWZpZXJzIHRo YXQgYm90aCBJU1BzIGFuZCBJQ1BzIHJlYWNoIGNvbnNlbnN1cyBpbg0KICAgYSBjb29yZGluYXRp b24gd2F5LiAgVGhpcyBkb2N1bWVudCBhbmFseXplcyB0aGUgdGVjbmljYWwgZ2FwIGJldHdlZW4N CiAgIHRoZSBjdXJyZW50IG5ldHdvcmsgZnVuY3Rpb25zIGFuZCByZXF1aXJlZCBuZXR3b3JrIGNh cGFiaWxpdHkgdG8NCiAgIHN1cHBvcnQgQ09sbGFib3JhdGl2ZSBORVR3b3JrLg0KDQpDb3VsZCB5 b3UgcGxlYXNlIHJlYWQgYW5kIGNvbW1lbnRzPyBBbnkgZmVlZGJhY2sgd291bGQgYmUgYXBwcmVj aWF0ZWQuDQoNCkJlc3QgcmVnYXJkcywNCg0KU2hlbmcgKyBSb25nDQoNCj4tLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPkZyb206IGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10NCj5TZW50OiBGcmlkYXksIE1heSAwOSwgMjAxNCAxMTo0 NiBBTQ0KPlRvOiBTaGVuZyBKaWFuZzsgUm9uZyBaaGFuZzsgU2hlbmcgSmlhbmc7IFJvbmcgWmhh bmcNCj5TdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+ZHJhZnQtamlhbmct aW50YXJlYS1jb25ldC1nYXAtYW5hbHlzaXMtMDAudHh0DQo+DQo+DQo+QSBuZXcgdmVyc2lvbiBv ZiBJLUQsIGRyYWZ0LWppYW5nLWludGFyZWEtY29uZXQtZ2FwLWFuYWx5c2lzLTAwLnR4dA0KPmhh cyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgU2hlbmcgSmlhbmcgYW5kIHBvc3RlZCB0 byB0aGUNCj5JRVRGIHJlcG9zaXRvcnkuDQo+DQo+TmFtZToJCWRyYWZ0LWppYW5nLWludGFyZWEt Y29uZXQtZ2FwLWFuYWx5c2lzDQo+UmV2aXNpb246CTAwDQo+VGl0bGU6CQlDT2xsYWJvcmF0aXZl IE5FVHdvcmsgKENPTkVUKSBHYXAgQW5hbHlzaXMNCj5Eb2N1bWVudCBkYXRlOgkyMDE0LTA1LTA5 DQo+R3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj5QYWdlczoJCTEwDQo+VVJMOg0KPmh0 dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWppYW5nLWludGFyZWEtY29u ZXQtZ2FwLWFuYWx5c2lzLTANCj4wLnR4dA0KPlN0YXR1czoNCj5odHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1qaWFuZy1pbnRhcmVhLWNvbmV0LWdhcC1hbmFseXNpcy8NCj5I dG1saXplZDoNCj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1qaWFuZy1pbnRhcmVh LWNvbmV0LWdhcC1hbmFseXNpcy0wMA0KPg0KPg0KPkFic3RyYWN0Og0KPiAgIEluIG9yZGVyIHRv IGVmZmljaWVudGx5IGRpc3Rpbmd1aXNoIElDUHMnIHRyYWZmaWMsIGEgbmV3IG5ldHdvcmsNCj4g ICBvcGVyYXRpb24gbW9kZWwgLSBDT2xsYWJvcmF0aXZlIE5FVHdvcmsgaXMgcHJvcG9zZWQuICBU aGUgdHJhZmZpYw0KPiAgIHJlY29nbml6YXRpb24gaXMgYmFzZWQgb24gdHJhZmZpYyBvZiBJQ1Bz JyBwcm9kdWN0cyBhY3RpdmVseSBjYXJyaWVzDQo+ICAgY29sbGFib3JhdGl2ZSBpZGVudGlmaWVy cyB0aGF0IGJvdGggSVNQcyBhbmQgSUNQcyByZWFjaCBjb25zZW5zdXMgaW4NCj4gICBhIGNvb3Jk aW5hdGlvbiB3YXkuICBUaGlzIGRvY3VtZW50IGFuYWx5emVzIHRoZSB0ZWNuaWNhbCBnYXAgYmV0 d2Vlbg0KPiAgIHRoZSBjdXJyZW50IG5ldHdvcmsgZnVuY3Rpb25zIGFuZCByZXF1aXJlZCBuZXR3 b3JrIGNhcGFiaWxpdHkgdG8NCj4gICBzdXBwb3J0IENPbGxhYm9yYXRpdmUgTkVUd29yay4NCj4N Cj4NCj4NCj4NCj5QbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0 ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQo+dW50aWwgdGhlIGh0bWxpemVkIHZlcnNp b24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4NCj5UaGUgSUVU RiBTZWNyZXRhcmlhdA0KDQo= From nobody Thu May 8 22:44:46 2014 Return-Path: X-Original-To: aeon@ietfa.amsl.com Delivered-To: aeon@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B18D51A01E7 for ; Thu, 8 May 2014 22:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.151 X-Spam-Level: X-Spam-Status: No, score=-10.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MWXmzzXUjyxx for ; Thu, 8 May 2014 22:44:41 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id 8C8C61A01E5 for ; Thu, 8 May 2014 22:44:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20567; q=dns/txt; s=iport; t=1399614277; x=1400823877; h=from:to:cc:subject:date:message-id:mime-version; bh=XY9LcOqauJ140pw2D3E+xRL+Utymej2swHXN60YLTfM=; b=KJXa1y45CjuJue00QZPvZ8OMuIl4p75USe+R0AFJ9jMW3HqV70mPMrD2 D2i3LpuXMzrZVP1dmed8gEi2OxboDTUE7bI6SCjIQMjub6FdLL8Tu02UP gBHf8muokV9sQgSq19+M+CxAQxjnd+MINoiDtL7GHv1f/3Zjm0ANenfMN Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FADdqbFOtJV2d/2dsb2JhbABZgkJET1i8Ooh+AYEVFnSCJQEBAQQtTBIBCBEDAQEBCxYHKBEUCQkBBAENBQgBEogSAxENyiQNhjMXjDuBRgEBHiARBoMsgRUEl1CDLotfhWGDNm2BCTk X-IronPort-AV: E=Sophos;i="4.97,1016,1389744000"; d="scan'208,217";a="42361802" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-7.cisco.com with ESMTP; 09 May 2014 05:44:36 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s495iamt011630 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 9 May 2014 05:44:36 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.104]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Fri, 9 May 2014 00:44:35 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "Charles Eckel (eckelcu)" , Rong Zhang Thread-Topic: [Aeon] COllaborative NETwork vs AEON? Thread-Index: Ac9rSbzwsPjvRU3uSQaPZ1uDZX4qZA== Date: Fri, 9 May 2014 05:44:34 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A24324321@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.60.206] Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A24324321xmbrcdx10ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/I-vqUKzxhFfNCO2GmqHHvGgxTSM Cc: "aeon@ietf.org" Subject: Re: [Aeon] COllaborative NETwork vs AEON? X-BeenThere: aeon@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Enabled Open Networking \(AEON\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 05:44:44 -0000 --_000_913383AAA69FF945B8F946018B75898A24324321xmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable draft-fan-intarea-conet-ps-uc-00 is specific to Mobile Networks where it ha= s tie-up with third party content providers. It's very similar to use case= described in http://tools.ietf.org/html/draft-eckel-aeon-use-cases-01#sect= ion-2.5. draft-eckel-aeon-problem-statement is not discussing any use cases= and but the limitations with existing solutions and requirements for solvi= ng the problem. It can be updated to include the requirement to solve the p= roblem of identifying over-the-top services which is a problem even in Ente= rprise networks. -Tiru From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Charles Eckel (eckel= cu) Sent: Friday, May 09, 2014 12:18 AM To: Rong Zhang Cc: aeon@ietf.org Subject: Re: [Aeon] COllaborative NETwork vs AEON? Hi Rong, Thanks for clarifying. There are pros and cons between combining topics int= o a single document vs. having several smaller documents. It would be relat= ively straightforward to divide the drafts as you suggest, and it would pro= bably simplify merging information in the AEON and CONET drafts as well. Cheers, Charles From: Rong Zhang > Date: Saturday, May 3, 2014 at 8:06 PM To: Charles Eckel > Cc: "aeon@ietf.org" > Subject: Re: [Aeon] COllaborative NETwork vs AEON? Hi Charles, What I mean is that draft-eckel-aeon-problem-statement-01 have too many use cases and solutions= related content, but I see: http://www.ietf.org/id/draft-fan-intarea-conet-ps-uc-00.txt quite focus on = problem statement, so I would like to suggest that we start from second draft about PS, some o= f your draft could be merged into that draft. and then we could have seperate requirement draft( which maybe from AEON PS= ), and another gap analsysis draft. cheers. Rong Zhang On Sat, May 3, 2014 at 5:36 AM, Charles Eckel (eckelcu) > wrote: Hi Rong, Sorry for the delay in responding. I am not sure I understand what you are = asking for here, but perhaps this previous thread will be of help: http://www.ietf.org/mail-archive/web/aeon/current/msg00033.html Cheers, Charles From: Rong Zhang > Date: Sunday, April 27, 2014 at 7:07 AM To: "aeon@ietf.org" > Subject: [Aeon] COllaborative NETwork vs AEON? Hello all, I have been observing the comments here, it seems that some operators are d= iscussing the current problems about COllaborative NETwork and how current = 3GPP Rx is not sufficient, and also some requirements and gap analysis. But for Aeon's case, we haven't seen any operators illustrating how they ar= e similarl between COllaborative NETwork and AEON's problem. Can anybody fr= om AEON kindly help to elaborate more here? cheers, Rong Zhang --_000_913383AAA69FF945B8F946018B75898A24324321xmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

draft-fan-intarea-conet-ps-= uc-00 is specific to Mobile Networks where it has tie-up with third party c= ontent providers.  It’s very similar to use case described in http://tools.ietf.org/html/draft-eckel-aeon-use-cases-01#section-2.5. d= raft-eckel-aeon-problem-statement is not discussing any use cases and but t= he limitations with existing solutions and requirements for solving the pro= blem. It can be updated to include the requirement to solve the problem of identifying over-the-top services = which is a problem even in Enterprise networks.

 

-Tiru

 <= /p>

From: Aeon [ma= ilto:aeon-bounces@ietf.org] On Behalf Of Charles Eckel (eckelcu)
Sent: Friday, May 09, 2014 12:18 AM
To: Rong Zhang
Cc: aeon@ietf.org
Subject: Re: [Aeon] COllaborative NETwork vs AEON?=

 

Hi Rong,<= /p>

 

Thanks for clarifying. Ther= e are pros and cons between combining topics into a single document vs. hav= ing several smaller documents. It would be relatively straightforward to divide the drafts as you suggest, and it would probably simplify mergin= g information in the AEON and CONET drafts as well.

 

Cheers,

Charles

 

From: Rong Zhang <rzhang.ietf@gmail.com>
Date: Saturday, May 3, 2014 at 8:06 PM
To: Charles Eckel <eckelcu@cisco.com>
Cc: "aeon@= ietf.org" <aeon@ietf.org>
Subject: Re: [Aeon] COllaborative NETwork vs AEON?=

 

Hi Charles,

 

What I mean is that

draft-eckel-aeon-problem-st= atement-01 have too many use cases and solutions related content,

 

but I see:

 

so I would like to suggest = that we start from second draft about PS, some of your draft could be merge= d into that draft.

and then we could have sepe= rate requirement draft( which maybe from AEON PS), and another gap analsysi= s draft.

 

cheers.

 

Rong Zhang

 

On Sat, May 3, 2014 at 5:36= AM, Charles Eckel (eckelcu) <eckelcu@cisco.com> wrote:

Hi Rong,<= /p>

 

Sorry for the delay in resp= onding. I am not sure I understand what you are asking for here, but perhap= s this previous thread will be of help:

 

Cheers,

Charles

 

From: Rong Zhang <rzhang.ietf@gmail.co= m>
Date: Sunday, April 27, 2014 at 7:07 AM
To: "= aeon@ietf.org" <aeon@i= etf.org>
Subject: [Aeon] COllaborative NETwork vs AEON?

 

Hello all,

 

I have been observing the c= omments here, it seems that some operators are discussing the current probl= ems about COllaborative NETwork and how current 3GPP Rx is not sufficient, and also some requirements and gap analysis.=

 

But for Aeon's case, we hav= en't seen any operators illustrating how they are similarl between COllabor= ative NETwork and AEON's problem. Can anybody from AEON kindly help to elaborate more here?

 

cheers,

 

Rong Zhang

 

--_000_913383AAA69FF945B8F946018B75898A24324321xmbrcdx10ciscoc_-- From nobody Fri May 9 07:49:22 2014 Return-Path: X-Original-To: aeon@ietfa.amsl.com Delivered-To: aeon@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34E531A001A for ; Fri, 9 May 2014 07:49:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kPKZMjDWh2pD for ; Fri, 9 May 2014 07:49:18 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id CAC4C1A0010 for ; Fri, 9 May 2014 07:49:17 -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.7-GA FastPath queued) with ESMTP id BDZ34741; Fri, 09 May 2014 14:49:12 +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.3.158.1; Fri, 9 May 2014 15:47:28 +0100 Received: from DFWEML702-CHM.china.huawei.com (10.193.5.72) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 9 May 2014 15:49:11 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.127]) by dfweml702-chm.china.huawei.com ([169.254.4.119]) with mapi id 14.03.0158.001; Fri, 9 May 2014 07:48:58 -0700 From: Linda Dunbar To: Sheng Jiang , "aeon@ietf.org" Thread-Topic: New Version Notification for draft-jiang-intarea-conet-gap-analysis-00.txt Thread-Index: AQHPazk6oYvLJI1BoEmQF4ap7BNXMZs3nbTQgAC28BA= Date: Fri, 9 May 2014 14:48:58 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645D0720F@dfweml701-chm.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AE45940@nkgeml512-mbx.china.huawei.com> In-Reply-To: <5D36713D8A4E7348A7E10DF7437A4B923AE45940@nkgeml512-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.192.11.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/dkcEoGq4aJYGHJntcMMzLd7l_Ps Cc: "zhangr@gsta.com" Subject: Re: [Aeon] New Version Notification for draft-jiang-intarea-conet-gap-analysis-00.txt X-BeenThere: aeon@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Enabled Open Networking \(AEON\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 May 2014 14:49:20 -0000 Sheng,=20 Can you elaborate a little more how this draft is related to the objectives= of AEON? Linda -----Original Message----- From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Sheng Jiang Sent: Thursday, May 08, 2014 11:00 PM To: aeon@ietf.org Cc: zhangr@gsta.com Subject: [Aeon] FW: New Version Notification for draft-jiang-intarea-conet-= gap-analysis-00.txt Hi, all, We have just submitted a gap analysis for COllaborative NETwork (CONET). Abstract: In order to efficiently distinguish ICPs' traffic, a new network operation model - COllaborative NETwork is proposed. The traffic recognization is based on traffic of ICPs' products actively carries collaborative identifiers that both ISPs and ICPs reach consensus in a coordination way. This document analyzes the tecnical gap between the current network functions and required network capability to support COllaborative NETwork. Could you please read and comments? Any feedback would be appreciated. Best regards, Sheng + Rong >-----Original Message----- >From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] >Sent: Friday, May 09, 2014 11:46 AM >To: Sheng Jiang; Rong Zhang; Sheng Jiang; Rong Zhang >Subject: New Version Notification for >draft-jiang-intarea-conet-gap-analysis-00.txt > > >A new version of I-D, draft-jiang-intarea-conet-gap-analysis-00.txt >has been successfully submitted by Sheng Jiang and posted to the IETF=20 >repository. > >Name: draft-jiang-intarea-conet-gap-analysis >Revision: 00 >Title: COllaborative NETwork (CONET) Gap Analysis >Document date: 2014-05-09 >Group: Individual Submission >Pages: 10 >URL: >http://www.ietf.org/internet-drafts/draft-jiang-intarea-conet-gap-analy >sis-0 >0.txt >Status: >https://datatracker.ietf.org/doc/draft-jiang-intarea-conet-gap-analysis >/ >Htmlized: >http://tools.ietf.org/html/draft-jiang-intarea-conet-gap-analysis-00 > > >Abstract: > In order to efficiently distinguish ICPs' traffic, a new network > operation model - COllaborative NETwork is proposed. The traffic > recognization is based on traffic of ICPs' products actively carries > collaborative identifiers that both ISPs and ICPs reach consensus in > a coordination way. This document analyzes the tecnical gap between > the current network functions and required network capability to > support COllaborative NETwork. > > > > >Please note that it may take a couple of minutes from the time of=20 >submission until the htmlized version and diff are available at tools.ietf= .org. > >The IETF Secretariat _______________________________________________ Aeon mailing list Aeon@ietf.org https://www.ietf.org/mailman/listinfo/aeon From nobody Sun May 11 23:00:18 2014 Return-Path: X-Original-To: aeon@ietfa.amsl.com Delivered-To: aeon@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43AF41A0401 for ; Sun, 11 May 2014 23:00:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lzKvlRa0JiCH for ; Sun, 11 May 2014 23:00:14 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 3316F1A03FD for ; Sun, 11 May 2014 23:00:13 -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.7-GA FastPath queued) with ESMTP id BEA93819; Mon, 12 May 2014 06:00:07 +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.3.158.1; Mon, 12 May 2014 06:58:35 +0100 Received: from nkgeml409-hub.china.huawei.com (10.98.56.40) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 12 May 2014 07:00:05 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.206]) by nkgeml409-hub.china.huawei.com ([10.98.56.40]) with mapi id 14.03.0158.001; Mon, 12 May 2014 13:59:53 +0800 From: Sheng Jiang To: Linda Dunbar , "aeon@ietf.org" Thread-Topic: New Version Notification for draft-jiang-intarea-conet-gap-analysis-00.txt Thread-Index: AQHPazk6oYvLJI1BoEmQF4ap7BNXMZs3nbTQgAC28BCABB44IA== Date: Mon, 12 May 2014 05:59:53 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AE47482@nkgeml512-mbx.china.huawei.com> References: <5D36713D8A4E7348A7E10DF7437A4B923AE45940@nkgeml512-mbx.china.huawei.com> <4A95BA014132FF49AE685FAB4B9F17F645D0720F@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645D0720F@dfweml701-chm.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/9mgTZpybiHUlqOntOfU2rT9-SVo Cc: "zhangr@gsta.com" Subject: Re: [Aeon] New Version Notification for draft-jiang-intarea-conet-gap-analysis-00.txt X-BeenThere: aeon@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Enabled Open Networking \(AEON\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 06:00:16 -0000 SGksIExpbmRhLA0KDQpGb3IgbXkgcGVyc29uYWwgdW5kZXJzdGFuZGluZywgYm90aCBBRU9OIGFu ZCBDT2xsYWJvcmF0aXZlIE5FVHdvcmsgYXJlIHRhcmdldGluZyB0byB0aGUgc2ltaWxhciBwcm9i bGVtIHNwYWNlcy4gQUVPTiBmb2N1c2VzIG9uIHNvbHV0aW9ucyBhbmQgZnJhbWV3b3JrLiBDb2xs YWJvcmF0aXZlIE5FVHdvcmsgaXMgaW5pdGlhdGVkIGJ5IHRoZSByZXF1aXJlbWVudHMgZnJvbSBu ZXR3b3JrIG9wZXJhdG9ycy4gVGhpcyBkcmFmdHMgaXMgYWltaW5nIHRvIGFuYWx5emUgdGhlIHJl cXVpcmVtZW50cyBhbmQgdGhlIHRlY2huaWNhbCBnYXBzLiBBRU9OIHdvdWxkIGJlIGEgY2FuZGlk YXRlIHRvIGZpbGwgdGhlc2UgZ2FwcyBvZiBDT2xsYWJvcmF0aXZlIE5FVHdvcmsuIEZvciBub3cs IHRoZSBtb3N0IGltcG9ydGFudCB3b3JrIGlzIHRvIHVuZGVyc3RhbmQgdGhlIHJlcXVpcmVtZW50 cy4NCg0KUmVnYXJkcywNCg0KU2hlbmcNCg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ RnJvbTogTGluZGEgRHVuYmFyDQo+U2VudDogRnJpZGF5LCBNYXkgMDksIDIwMTQgMTA6NDkgUE0N Cj5UbzogU2hlbmcgSmlhbmc7IGFlb25AaWV0Zi5vcmcNCj5DYzogemhhbmdyQGdzdGEuY29tDQo+ U3ViamVjdDogUkU6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj5kcmFmdC1qaWFuZy1p bnRhcmVhLWNvbmV0LWdhcC1hbmFseXNpcy0wMC50eHQNCj4NCj5TaGVuZywNCj4NCj5DYW4geW91 IGVsYWJvcmF0ZSBhIGxpdHRsZSBtb3JlIGhvdyB0aGlzIGRyYWZ0IGlzIHJlbGF0ZWQgdG8gdGhl IG9iamVjdGl2ZXMgb2YNCj5BRU9OPw0KPg0KPkxpbmRhDQo+DQo+LS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj5Gcm9tOiBBZW9uIFttYWlsdG86YWVvbi1ib3VuY2VzQGlldGYub3JnXSBPbiBC ZWhhbGYgT2YgU2hlbmcgSmlhbmcNCj5TZW50OiBUaHVyc2RheSwgTWF5IDA4LCAyMDE0IDExOjAw IFBNDQo+VG86IGFlb25AaWV0Zi5vcmcNCj5DYzogemhhbmdyQGdzdGEuY29tDQo+U3ViamVjdDog W0Flb25dIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yDQo+ZHJhZnQtamlhbmctaW50 YXJlYS1jb25ldC1nYXAtYW5hbHlzaXMtMDAudHh0DQo+DQo+SGksIGFsbCwNCj4NCj5XZSBoYXZl IGp1c3Qgc3VibWl0dGVkIGEgZ2FwIGFuYWx5c2lzIGZvciBDT2xsYWJvcmF0aXZlIE5FVHdvcmsg KENPTkVUKS4NCj4NCj5BYnN0cmFjdDoNCj4gICBJbiBvcmRlciB0byBlZmZpY2llbnRseSBkaXN0 aW5ndWlzaCBJQ1BzJyB0cmFmZmljLCBhIG5ldyBuZXR3b3JrDQo+ICAgb3BlcmF0aW9uIG1vZGVs IC0gQ09sbGFib3JhdGl2ZSBORVR3b3JrIGlzIHByb3Bvc2VkLiAgVGhlIHRyYWZmaWMNCj4gICBy ZWNvZ25pemF0aW9uIGlzIGJhc2VkIG9uIHRyYWZmaWMgb2YgSUNQcycgcHJvZHVjdHMgYWN0aXZl bHkgY2Fycmllcw0KPiAgIGNvbGxhYm9yYXRpdmUgaWRlbnRpZmllcnMgdGhhdCBib3RoIElTUHMg YW5kIElDUHMgcmVhY2ggY29uc2Vuc3VzIGluDQo+ICAgYSBjb29yZGluYXRpb24gd2F5LiAgVGhp cyBkb2N1bWVudCBhbmFseXplcyB0aGUgdGVjbmljYWwgZ2FwIGJldHdlZW4NCj4gICB0aGUgY3Vy cmVudCBuZXR3b3JrIGZ1bmN0aW9ucyBhbmQgcmVxdWlyZWQgbmV0d29yayBjYXBhYmlsaXR5IHRv DQo+ICAgc3VwcG9ydCBDT2xsYWJvcmF0aXZlIE5FVHdvcmsuDQo+DQo+Q291bGQgeW91IHBsZWFz ZSByZWFkIGFuZCBjb21tZW50cz8gQW55IGZlZWRiYWNrIHdvdWxkIGJlIGFwcHJlY2lhdGVkLg0K Pg0KPkJlc3QgcmVnYXJkcywNCj4NCj5TaGVuZyArIFJvbmcNCj4NCj4+LS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCj4+RnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIFttYWlsdG86aW50 ZXJuZXQtZHJhZnRzQGlldGYub3JnXQ0KPj5TZW50OiBGcmlkYXksIE1heSAwOSwgMjAxNCAxMTo0 NiBBTQ0KPj5UbzogU2hlbmcgSmlhbmc7IFJvbmcgWmhhbmc7IFNoZW5nIEppYW5nOyBSb25nIFpo YW5nDQo+PlN1YmplY3Q6IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3INCj4+ZHJhZnQtamlh bmctaW50YXJlYS1jb25ldC1nYXAtYW5hbHlzaXMtMDAudHh0DQo+Pg0KPj4NCj4+QSBuZXcgdmVy c2lvbiBvZiBJLUQsIGRyYWZ0LWppYW5nLWludGFyZWEtY29uZXQtZ2FwLWFuYWx5c2lzLTAwLnR4 dA0KPj5oYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFNoZW5nIEppYW5nIGFuZCBw b3N0ZWQgdG8gdGhlIElFVEYNCj4+cmVwb3NpdG9yeS4NCj4+DQo+Pk5hbWU6CQlkcmFmdC1qaWFu Zy1pbnRhcmVhLWNvbmV0LWdhcC1hbmFseXNpcw0KPj5SZXZpc2lvbjoJMDANCj4+VGl0bGU6CQlD T2xsYWJvcmF0aXZlIE5FVHdvcmsgKENPTkVUKSBHYXAgQW5hbHlzaXMNCj4+RG9jdW1lbnQgZGF0 ZToJMjAxNC0wNS0wOQ0KPj5Hcm91cDoJCUluZGl2aWR1YWwgU3VibWlzc2lvbg0KPj5QYWdlczoJ CTEwDQo+PlVSTDoNCj4+aHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQt amlhbmctaW50YXJlYS1jb25ldC1nYXAtYW5hbHkNCj4+c2lzLTANCj4+MC50eHQNCj4+U3RhdHVz Og0KPj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1qaWFuZy1pbnRhcmVh LWNvbmV0LWdhcC1hbmFseXNpcw0KPj4vDQo+Pkh0bWxpemVkOg0KPj5odHRwOi8vdG9vbHMuaWV0 Zi5vcmcvaHRtbC9kcmFmdC1qaWFuZy1pbnRhcmVhLWNvbmV0LWdhcC1hbmFseXNpcy0wMA0KPj4N Cj4+DQo+PkFic3RyYWN0Og0KPj4gICBJbiBvcmRlciB0byBlZmZpY2llbnRseSBkaXN0aW5ndWlz aCBJQ1BzJyB0cmFmZmljLCBhIG5ldyBuZXR3b3JrDQo+PiAgIG9wZXJhdGlvbiBtb2RlbCAtIENP bGxhYm9yYXRpdmUgTkVUd29yayBpcyBwcm9wb3NlZC4gIFRoZSB0cmFmZmljDQo+PiAgIHJlY29n bml6YXRpb24gaXMgYmFzZWQgb24gdHJhZmZpYyBvZiBJQ1BzJyBwcm9kdWN0cyBhY3RpdmVseSBj YXJyaWVzDQo+PiAgIGNvbGxhYm9yYXRpdmUgaWRlbnRpZmllcnMgdGhhdCBib3RoIElTUHMgYW5k IElDUHMgcmVhY2ggY29uc2Vuc3VzIGluDQo+PiAgIGEgY29vcmRpbmF0aW9uIHdheS4gIFRoaXMg ZG9jdW1lbnQgYW5hbHl6ZXMgdGhlIHRlY25pY2FsIGdhcCBiZXR3ZWVuDQo+PiAgIHRoZSBjdXJy ZW50IG5ldHdvcmsgZnVuY3Rpb25zIGFuZCByZXF1aXJlZCBuZXR3b3JrIGNhcGFiaWxpdHkgdG8N Cj4+ICAgc3VwcG9ydCBDT2xsYWJvcmF0aXZlIE5FVHdvcmsuDQo+Pg0KPj4NCj4+DQo+Pg0KPj5Q bGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUg dGltZSBvZg0KPj5zdWJtaXNzaW9uIHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZm IGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQo+Pg0KPj5UaGUgSUVURiBTZWNyZXRh cmlhdA0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+QWVvbiBtYWlsaW5nIGxpc3QNCj5BZW9uQGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9hZW9uDQo= From nobody Mon May 12 00:26:04 2014 Return-Path: X-Original-To: aeon@ietfa.amsl.com Delivered-To: aeon@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 578D21A0415 for ; Mon, 12 May 2014 00:26:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ltpne5AtIPOJ for ; Mon, 12 May 2014 00:26:01 -0700 (PDT) Received: from mail-ob0-x22f.google.com (mail-ob0-x22f.google.com [IPv6:2607:f8b0:4003:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id E1CEF1A040A for ; Mon, 12 May 2014 00:26:00 -0700 (PDT) Received: by mail-ob0-f175.google.com with SMTP id wo20so7667024obc.6 for ; Mon, 12 May 2014 00:25: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=3dw+HxjVKiZEpvQ9XEOqDv8+GsPZuM5KebvrjUt/Gqg=; b=aDAAT2Sl0PSImZ7tIB0nzTo9WCb6wef4QJB7/B0sem8Zvh+vtxBJqdMR0AyWZKzG1z lR72ojcCqqT3A/JxMM4k/ogZNk0VpIjqFYsOh7QLcFEXSsnxsV601EwGQ/WcTVhbKF6s yf9WEBOSWGp61oQAWBtMHh3hjQQPOdRoQgqR2mg87OdFMMyueNbjQRSEuYyJffpmbFjb cchdkQPRi1QenRpn6hiSp0tG534EYynoKp18prGY8iNZqvf2/N8d5c1RjN/jBWe7eAf1 5I4rvTvsiDO2fysSiFcscXTgYKAE/WiYAC4PTK5DvC4AerNP91h4rIKTWHKyJY/dGC37 5hwg== MIME-Version: 1.0 X-Received: by 10.182.74.234 with SMTP id x10mr30654348obv.1.1399879554965; Mon, 12 May 2014 00:25:54 -0700 (PDT) Received: by 10.76.0.109 with HTTP; Mon, 12 May 2014 00:25:54 -0700 (PDT) In-Reply-To: References: Date: Mon, 12 May 2014 15:25:54 +0800 Message-ID: From: Rong Zhang To: "Charles Eckel (eckelcu)" Content-Type: multipart/alternative; boundary=001a11c1ede69a25b804f92edb7e Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/ifnqTvb3UW8gsi4q6gePDGxb0LU Cc: "aeon@ietf.org" Subject: Re: [Aeon] COllaborative NETwork vs AEON? X-BeenThere: aeon@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Enabled Open Networking \(AEON\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 07:26:03 -0000 --001a11c1ede69a25b804f92edb7e Content-Type: text/plain; charset=UTF-8 Hi Charles, I also recommend the merging the work, here I would suggest to focus on limited use cases. Cheers. Rong Zhang On Fri, May 9, 2014 at 2:48 AM, Charles Eckel (eckelcu) wrote: > Hi Rong, > > Thanks for clarifying. There are pros and cons between combining topics > into a single document vs. having several smaller documents. It would be > relatively straightforward to divide the drafts as you suggest, and it > would probably simplify merging information in the AEON and CONET drafts as > well. > > Cheers, > Charles > > From: Rong Zhang > Date: Saturday, May 3, 2014 at 8:06 PM > To: Charles Eckel > Cc: "aeon@ietf.org" > Subject: Re: [Aeon] COllaborative NETwork vs AEON? > > Hi Charles, > > What I mean is that > draft-eckel-aeon-problem-statement-01 have too many use cases and > solutions related content, > > but I see: > http://www.ietf.org/id/draft-fan-intarea-conet-ps-uc-00.txt quite focus > on problem statement, > > so I would like to suggest that we start from second draft about PS, some > of your draft could be merged into that draft. > and then we could have seperate requirement draft( which maybe from AEON > PS), and another gap analsysis draft. > > cheers. > > Rong Zhang > > > On Sat, May 3, 2014 at 5:36 AM, Charles Eckel (eckelcu) > wrote: > >> Hi Rong, >> >> Sorry for the delay in responding. I am not sure I understand what you >> are asking for here, but perhaps this previous thread will be of help: >> http://www.ietf.org/mail-archive/web/aeon/current/msg00033.html >> >> Cheers, >> Charles >> >> From: Rong Zhang >> Date: Sunday, April 27, 2014 at 7:07 AM >> To: "aeon@ietf.org" >> Subject: [Aeon] COllaborative NETwork vs AEON? >> >> Hello all, >> >> I have been observing the comments here, it seems that some operators are >> discussing the current problems about COllaborative NETwork and how current >> 3GPP Rx is not sufficient, and also some requirements and gap analysis. >> >> But for Aeon's case, we haven't seen any operators illustrating how they >> are similarl between COllaborative NETwork and AEON's problem. Can anybody >> from AEON kindly help to elaborate more here? >> >> cheers, >> >> Rong Zhang >> >> > --001a11c1ede69a25b804f92edb7e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Charles,
=C2=A0
I also recommend the merging th= e work, here I would suggest to focus on limited use cases.
=C2= =A0
Cheers.
=C2=A0
Rong Zhang

On Fri, May 9, 2014 at 2:48 AM, Charles Eckel (eckelcu) &= lt;eckelcu@cisco.com= > wrote:
Hi Rong,

Thanks for clarifying. There are pros and cons between combining topic= s into a single document vs. having several smaller documents. It would be = relatively straightforward to divide the drafts as you suggest, and it woul= d probably simplify merging information in the AEON and CONET drafts as well.

Cheers,
Charles
=C2=A0
From: Rong Zhang <rzhang.ietf@gmail.com><= br> Date: Saturday, May 3, 2014 at 8:06= PM
To: Charles Eckel <eckelcu@cisco.com>
Cc: "aeon@ietf.org" <aeon@ietf.org>
Subject: Re: [Aeon] COllaborative N= ETwork vs AEON?

Hi Charles,
=C2=A0
What I mean is that
draft-eckel-aeon-problem-statement-01 have too many use cases and solu= tions related content,
=C2=A0
but I see:
http://www.ietf.org/id/dra= ft-fan-intarea-conet-ps-uc-00.txt=C2=A0quite focus on problem st= atement,
=C2=A0
so I would like to suggest that we start from second draft about= PS, some of your draft could be merged into that draft.
and then we could have seperate requirement draft( which maybe f= rom AEON PS), and another gap analsysis draft.
=C2=A0
cheers.
=C2=A0
Rong Zhang


On Sat, May 3, 2014 at 5:36 AM, Charles Eckel (e= ckelcu) <eckelcu@cisco.co= m> wrote:
Hi Rong,

Sorry for the delay in responding. I am not sure I understand what you= are asking for here, but perhaps this previous thread will be of help:

Cheers,
Charles

From: Rong Zhang <rzhang.ietf@gmail.com><= br> Date: Sunday, April 27, 2014 at 7:0= 7 AM
To: "aeon@ietf.org" <aeon@ietf.org>
Subject: [Aeon] COllaborative NETwo= rk vs AEON?

Hello all,
=C2=A0
I have been observing the comments here, it seems that some operators = are discussing the current problems about COllaborative NETwork and how cur= rent 3GPP Rx is not sufficient, and also some requirements and gap analysis= .
=C2=A0
But for Aeon's case, we haven't seen any operators illustratin= g how they are similarl between COllaborative NETwork and AEON's proble= m. Can anybody from AEON kindly help to=C2=A0elaborate more here?
=C2=A0
cheers,
=C2=A0
Rong Zhang

--001a11c1ede69a25b804f92edb7e-- From nobody Mon May 12 00:31:38 2014 Return-Path: X-Original-To: aeon@ietfa.amsl.com Delivered-To: aeon@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15D431A041A for ; Mon, 12 May 2014 00:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4OQC31Arfhdl for ; Mon, 12 May 2014 00:31:30 -0700 (PDT) Received: from mail-ob0-x230.google.com (mail-ob0-x230.google.com [IPv6:2607:f8b0:4003:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 4F0CA1A0416 for ; Mon, 12 May 2014 00:31:30 -0700 (PDT) Received: by mail-ob0-f176.google.com with SMTP id wo20so7622119obc.21 for ; Mon, 12 May 2014 00:31:24 -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=kMS6hHCfHjxpOTNlQ9dVMHaGfxVKkd0P+ol6DkXm8K8=; b=AeWrZG3f2Mx9srOR8RJq74K2TYyOIVdbLvYHKTeRSHzYAlhVjioxPOH369nG6Vd/QB G3PNm7rGxa3LXJctMZ1iZhv/XYv11V8X0c/UPvoCKkeNc9Yo9hkHwmqYW5XS6FtErUCq YuhHHk1MuWyHNg8usqc3yaE7Pa5Yq+aAzcsgpdQUz0Xdoz4AJgW+vTbTD0f/dBwyrqqW +dzPQDB/EkHGZjoh03PrE1h6ZH2dKlxPCj2pHTv0NWnF6VWF5IcacWLkTdOfh60zHX6h YvCNUb+rS+F+OEO/8O3fuKtRSHiEmI4jy9oo+m9cuUgbbgjQ4HFjZqz6+EVWYgkt6fU8 cjJQ== MIME-Version: 1.0 X-Received: by 10.182.70.39 with SMTP id j7mr31259961obu.55.1399879884421; Mon, 12 May 2014 00:31:24 -0700 (PDT) Received: by 10.76.0.109 with HTTP; Mon, 12 May 2014 00:31:24 -0700 (PDT) In-Reply-To: <913383AAA69FF945B8F946018B75898A24324321@xmb-rcd-x10.cisco.com> References: <913383AAA69FF945B8F946018B75898A24324321@xmb-rcd-x10.cisco.com> Date: Mon, 12 May 2014 15:31:24 +0800 Message-ID: From: Rong Zhang To: "Tirumaleswar Reddy (tireddy)" Content-Type: multipart/alternative; boundary=089e0158b2043d400404f92eef0b Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/Q8TRQPVLpB2-VyBRdl5oj-t_6ek Cc: "aeon@ietf.org" , "Charles Eckel \(eckelcu\)" Subject: Re: [Aeon] COllaborative NETwork vs AEON? X-BeenThere: aeon@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Enabled Open Networking \(AEON\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 07:31:33 -0000 --089e0158b2043d400404f92eef0b Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable For my reading, draft-fan is not only mobile broadband, but also cover fixed broadband, that's the reason why gap analysis does mention broadband forum. For my impress, draft-fan is more generic, and cover today's real use case and operators's requirement, draft-eckel is more enterprise related and less baking here. I am not the author of this two documents, but recommend to start with the operator driven and urgent requriement. The best way to move forward to have generic PS/Use case which cover mobile broadband, fixed broadband, enterprise network with limited use cases Cheers, Rong Zhang On Fri, May 9, 2014 at 1:44 PM, Tirumaleswar Reddy (tireddy) < tireddy@cisco.com> wrote: > draft-fan-intarea-conet-ps-uc-00 is specific to Mobile Networks where it > has tie-up with third party content providers. It=E2=80=99s very similar= to use > case described in > http://tools.ietf.org/html/draft-eckel-aeon-use-cases-01#section-2.5. > draft-eckel-aeon-problem-statement is not discussing any use cases and bu= t > the limitations with existing solutions and requirements for solving the > problem. It can be updated to include the requirement to solve the proble= m > of identifying over-the-top services which is a problem even in Enterpris= e > networks. > > > > -Tiru > > > > *From:* Aeon [mailto:aeon-bounces@ietf.org] *On Behalf Of *Charles Eckel > (eckelcu) > *Sent:* Friday, May 09, 2014 12:18 AM > *To:* Rong Zhang > *Cc:* aeon@ietf.org > > *Subject:* Re: [Aeon] COllaborative NETwork vs AEON? > > > > Hi Rong, > > > > Thanks for clarifying. There are pros and cons between combining topics > into a single document vs. having several smaller documents. It would be > relatively straightforward to divide the drafts as you suggest, and it > would probably simplify merging information in the AEON and CONET drafts = as > well. > > > > Cheers, > > Charles > > > > *From: *Rong Zhang > *Date: *Saturday, May 3, 2014 at 8:06 PM > *To: *Charles Eckel > *Cc: *"aeon@ietf.org" > *Subject: *Re: [Aeon] COllaborative NETwork vs AEON? > > > > Hi Charles, > > > > What I mean is that > > draft-eckel-aeon-problem-statement-01 have too many use cases and > solutions related content, > > > > but I see: > > http://www.ietf.org/id/draft-fan-intarea-conet-ps-uc-00.txt quite focus > on problem statement, > > > > so I would like to suggest that we start from second draft about PS, some > of your draft could be merged into that draft. > > and then we could have seperate requirement draft( which maybe from AEON > PS), and another gap analsysis draft. > > > > cheers. > > > > Rong Zhang > > > > On Sat, May 3, 2014 at 5:36 AM, Charles Eckel (eckelcu) > wrote: > > Hi Rong, > > > > Sorry for the delay in responding. I am not sure I understand what you ar= e > asking for here, but perhaps this previous thread will be of help: > > http://www.ietf.org/mail-archive/web/aeon/current/msg00033.html > > > > Cheers, > > Charles > > > > *From: *Rong Zhang > *Date: *Sunday, April 27, 2014 at 7:07 AM > *To: *"aeon@ietf.org" > *Subject: *[Aeon] COllaborative NETwork vs AEON? > > > > Hello all, > > > > I have been observing the comments here, it seems that some operators are > discussing the current problems about COllaborative NETwork and how curre= nt > 3GPP Rx is not sufficient, and also some requirements and gap analysis. > > > > But for Aeon's case, we haven't seen any operators illustrating how they > are similarl between COllaborative NETwork and AEON's problem. Can anybod= y > from AEON kindly help to elaborate more here? > > > > cheers, > > > > Rong Zhang > > > > --089e0158b2043d400404f92eef0b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
For my reading, draft-fan is not only mobile broadband, but also cover= fixed broadband, that's the reason why gap analysis does mention broad= band forum.=C2=A0=C2=A0
=C2=A0
For my impress, draft-fa= n is more generic, and cover today's real use case and operators's = requirement, draft-eckel is more enterprise related and less baking here.
=C2=A0
I am not the author of this two documents, but recomm= end to start with the operator driven and urgent requriement.
=C2= =A0
The best way to move forward to have generic PS/Use case whic= h cover mobile broadband, fixed broadband, enterprise network with limited = use cases
Cheers,
=C2=A0
Rong Zhang
On Fri, May 9, 2014 at 1:44 PM, Tirumaleswar Reddy (tired= dy) <tireddy@cisco.com> wrote:

draft-fan-intarea-conet-ps-= uc-00 is specific to Mobile Networks where it has tie-up with third party c= ontent providers.=C2=A0 It=E2=80=99s very similar to use case described in http://tools.ietf.org/html/draft-eckel-aeon-use-cases-01#section-2.5. d= raft-eckel-aeon-problem-statement is not discussing any use cases and but t= he limitations with existing solutions and requirements for solving the pro= blem. It can be updated to include the requirement to solve the problem of identifying over-the-top services = which is a problem even in Enterprise networks.

=C2=A0=

-Tiru<= /p>

=C2=A0=

From: Aeon [mailto= :aeon-bounces@ie= tf.org] On Behalf Of Charles Eckel (eckelcu)
Sent: Friday, May 09, 2014 12:18 AM
To: Rong Zhang
Cc: aeon@ietf.org=


Subject: Re: [Aeon] COllaborative NETwork vs AEON?

=C2=A0

Hi Rong,

=C2=A0=

Thanks for clarifying. Ther= e are pros and cons between combining topics into a single document vs. hav= ing several smaller documents. It would be relatively straightforward to divide the drafts as you suggest, and it would probably simplify mergin= g information in the AEON and CONET drafts as well.

=C2=A0=

Cheers,

Charles

=C2=A0=

From: Rong Zhang <rzhang.ietf@gmail.com>
Date: Saturday, May 3, 2014 at 8:06 PM
To: Charles Eckel <eckelcu@cisco.com>
Cc: "= aeon@ietf.org" <aeon@ietf.or= g>
Subject: Re: [Aeon] COllaborative NETwork vs AEON?

=C2=A0=

Hi Charles,

=C2=A0=

What I mean is that

draft-eckel-aeon-problem-st= atement-01 have too many use cases and solutions related content,=

=C2=A0=

but I see:

http://www.ietf.org/id/d= raft-fan-intarea-conet-ps-uc-00.txt=C2= =A0quite focus on problem statement,

=C2=A0=

so I would like to suggest = that we start from second draft about PS, some of your draft could be merge= d into that draft.

and then we could have sepe= rate requirement draft( which maybe from AEON PS), and another gap analsysi= s draft.

=C2=A0=

cheers.

=C2=A0=

Rong Zhang

On Sat, May 3, 2014 at 5:36= AM, Charles Eckel (eckelcu) <eckelcu@cisco.com> wrote:

Hi Rong,

=C2=A0=

Sorry for the delay in resp= onding. I am not sure I understand what you are asking for here, but perhap= s this previous thread will be of help:

=C2=A0=

Cheers,

Charles

=C2=A0=

From: Rong Zhang <rzhang.ietf@gmail.com>
Date: Sunday, April 27, 2014 at 7:07 AM
To: "= aeon@ietf.org" <aeon@ietf.or= g>
Subject: [Aeon] COllaborative NETwork vs AEON?<= /p>

=C2=A0=

Hello all,

=C2=A0=

I have been observing the c= omments here, it seems that some operators are discussing the current probl= ems about COllaborative NETwork and how current 3GPP Rx is not sufficient, and also some requirements and gap analysis.<= /u>

=C2=A0=

But for Aeon's case, we= haven't seen any operators illustrating how they are similarl between = COllaborative NETwork and AEON's problem. Can anybody from AEON kindly help to=C2=A0elaborate more here?

=C2=A0=

cheers,

=C2=A0=

Rong Zhang

=C2=A0=


--089e0158b2043d400404f92eef0b-- From nobody Mon May 12 03:05:23 2014 Return-Path: X-Original-To: aeon@ietfa.amsl.com Delivered-To: aeon@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 608A81A066D for ; Mon, 12 May 2014 03:05:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.152 X-Spam-Level: X-Spam-Status: No, score=-10.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4dfvB756xIS for ; Mon, 12 May 2014 03:05:18 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 30FAA1A0667 for ; Mon, 12 May 2014 03:05:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6122; q=dns/txt; s=iport; t=1399889112; x=1401098712; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=/wlt+LXz9DkbJNLyOu+TsTtPt6B5i3P8Yt6nVQKUWX8=; b=GGu89ARPWdbTOq/yOQtyR1AKbSzYUDFbrxBr3E9qyn5+xJb4NGOlfqwT pb+IPnOezka43rQw6vmqje1uZly6G8+7ud59jGqrO20NaewBNWDWyKtqj goAagsSToarsjSPJRZEMgoQBFj1phdu3HJhaoJEWpxwa2M8vX4SNo/kwB 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnUFACWccFOtJA2K/2dsb2JhbABZgwZPWIJnwwUBGYEAFnSCJQEBAQQjEUUSAQgOAwMBAQEDAgYdAwIEHxEUAQgJAQQOBQgBEogSAxENqkadQg2GHxeBKosRgT8HAQEGGBYbgnw2gRUEl1aDLotjhWiDNm2BAAEIFyI X-IronPort-AV: E=Sophos;i="4.97,1034,1389744000"; d="scan'208";a="43007933" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-6.cisco.com with ESMTP; 12 May 2014 10:05:11 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s4CA5BZi023979 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 12 May 2014 10:05:11 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.76]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Mon, 12 May 2014 05:05:10 -0500 From: "Tirumaleswar Reddy (tireddy)" To: Rong Zhang Thread-Topic: [Aeon] COllaborative NETwork vs AEON? Thread-Index: Ac9tyaUUyAKZQLPiSMyj+A12Trneyg== Date: Mon, 12 May 2014 10:05:10 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A243304FB@xmb-rcd-x10.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.67.182] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/xgcjb1OIsDhfzqBHCkJWyep5ICo Cc: "aeon@ietf.org" , "Charles Eckel \(eckelcu\)" Subject: Re: [Aeon] COllaborative NETwork vs AEON? X-BeenThere: aeon@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Enabled Open Networking \(AEON\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2014 10:05:20 -0000 ZHJhZnQtZmFuIGFuZCB0aGUgdXNlIGNhc2UgaW4gaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtZWNrZWwtYWVvbi11c2UtY2FzZXMtMDEjc2VjdGlvbi0yLjUgb25seSBhZGRyZXNzIG9u ZSBzZXQgb2YgcHJvYmxlbXMuIEl0IHdvdWxkIG5vdCBiZSBwb3NzaWJsZSBmb3IgYWxsIGNvbnRl bnQgcHJvdmlkZXJzIHRvIGhhdmUgdGllLXVwIHdpdGggSVNQLCBmb3IgZXhhbXBsZSBzdWJzY3Jp YmVyIGNvdWxkIGJlIHdhdGNoaW5nIG1vdmllIGZyb20gYSBjb250ZW50IHByb3ZpZGVyIHdobyBk b2VzIG5vdCBoYXZlIHRpZS11cCB3aXRoIElTUCwgZG93bmxvYWRpbmcgZmlsZXMgdXNpbmcgUDJQ IHByb3RvY29scyBsaWtlIEJpdFRvcnJlbnQsIGJhY2tpbmcgdXAgZGF0YSB0byBjbG91ZCBzdG9y YWdlIGxpa2UgQW1hem9uLCBwbGF5aW5nIG9uLWxpbmUgZ2FtZXMsICB1c2UgV2ViUlRDIHRvIG1h a2UgY2FsbHMgZXRjLiANCg0KSXQgaXMgbm90IHBvc3NpYmxlIGluIHNvbWUgb2YgdGhlIGFib3Zl IHNjZW5hcmlvcyB0aGF0IHRoZXJlIHdpbGwgYmUgYnVzaW5lc3MgYWdyZWVtZW50cyB3aXRoIElT UC4gVmFyaW91cyBuZXR3b3JrcyBpbmNsdWRpbmcgTW9iaWxlLCBIb21lIGFuZCBFbnRlcnByaXNl IG5ldHdvcmsgbmVlZCBhIG1lY2hhbmlzbSB0byBvZmZlciBkaWZmZXJlbnRpYXRlZCBzZXJ2aWNl cyBmb3IgdGhlIGFib3ZlIHRyYWZmaWMuIA0KDQotVGlydQ0KDQpGcm9tOiBSb25nIFpoYW5nIFtt YWlsdG86cnpoYW5nLmlldGZAZ21haWwuY29tXSANClNlbnQ6IE1vbmRheSwgTWF5IDEyLCAyMDE0 IDE6MDEgUE0NClRvOiBUaXJ1bWFsZXN3YXIgUmVkZHkgKHRpcmVkZHkpDQpDYzogQ2hhcmxlcyBF Y2tlbCAoZWNrZWxjdSk7IGFlb25AaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbQWVvbl0gQ09sbGFi b3JhdGl2ZSBORVR3b3JrIHZzIEFFT04/DQoNCkZvciBteSByZWFkaW5nLCBkcmFmdC1mYW4gaXMg bm90IG9ubHkgbW9iaWxlIGJyb2FkYmFuZCwgYnV0IGFsc28gY292ZXIgZml4ZWQgYnJvYWRiYW5k LCB0aGF0J3MgdGhlIHJlYXNvbiB3aHkgZ2FwIGFuYWx5c2lzIGRvZXMgbWVudGlvbiBicm9hZGJh bmQgZm9ydW0uwqDCoA0KwqANCkZvciBteSBpbXByZXNzLCBkcmFmdC1mYW4gaXMgbW9yZSBnZW5l cmljLCBhbmQgY292ZXIgdG9kYXkncyByZWFsIHVzZSBjYXNlIGFuZCBvcGVyYXRvcnMncyByZXF1 aXJlbWVudCwgZHJhZnQtZWNrZWwgaXMgbW9yZSBlbnRlcnByaXNlIHJlbGF0ZWQgYW5kIGxlc3Mg YmFraW5nIGhlcmUuDQrCoA0KSSBhbSBub3QgdGhlIGF1dGhvciBvZiB0aGlzIHR3byBkb2N1bWVu dHMsIGJ1dCByZWNvbW1lbmQgdG8gc3RhcnQgd2l0aCB0aGUgb3BlcmF0b3IgZHJpdmVuIGFuZCB1 cmdlbnQgcmVxdXJpZW1lbnQuDQrCoA0KVGhlIGJlc3Qgd2F5IHRvIG1vdmUgZm9yd2FyZCB0byBo YXZlIGdlbmVyaWMgUFMvVXNlIGNhc2Ugd2hpY2ggY292ZXIgbW9iaWxlIGJyb2FkYmFuZCwgZml4 ZWQgYnJvYWRiYW5kLCBlbnRlcnByaXNlIG5ldHdvcmsgd2l0aCBsaW1pdGVkIHVzZSBjYXNlcw0K Q2hlZXJzLA0KwqANClJvbmcgWmhhbmcNCk9uIEZyaSwgTWF5IDksIDIwMTQgYXQgMTo0NCBQTSwg VGlydW1hbGVzd2FyIFJlZGR5ICh0aXJlZGR5KSA8dGlyZWRkeUBjaXNjby5jb20+IHdyb3RlOg0K ZHJhZnQtZmFuLWludGFyZWEtY29uZXQtcHMtdWMtMDAgaXMgc3BlY2lmaWMgdG8gTW9iaWxlIE5l dHdvcmtzIHdoZXJlIGl0IGhhcyB0aWUtdXAgd2l0aCB0aGlyZCBwYXJ0eSBjb250ZW50IHByb3Zp ZGVycy7CoCBJdOKAmXMgdmVyeSBzaW1pbGFyIHRvIHVzZSBjYXNlIGRlc2NyaWJlZCBpbiBodHRw Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1lY2tlbC1hZW9uLXVzZS1jYXNlcy0wMSNzZWN0 aW9uLTIuNS4gZHJhZnQtZWNrZWwtYWVvbi1wcm9ibGVtLXN0YXRlbWVudCBpcyBub3QgZGlzY3Vz c2luZyBhbnkgdXNlIGNhc2VzIGFuZCBidXQgdGhlIGxpbWl0YXRpb25zIHdpdGggZXhpc3Rpbmcg c29sdXRpb25zIGFuZCByZXF1aXJlbWVudHMgZm9yIHNvbHZpbmcgdGhlIHByb2JsZW0uIEl0IGNh biBiZSB1cGRhdGVkIHRvIGluY2x1ZGUgdGhlIHJlcXVpcmVtZW50IHRvIHNvbHZlIHRoZSBwcm9i bGVtIG9mIGlkZW50aWZ5aW5nIG92ZXItdGhlLXRvcCBzZXJ2aWNlcyB3aGljaCBpcyBhIHByb2Js ZW0gZXZlbiBpbiBFbnRlcnByaXNlIG5ldHdvcmtzLg0KwqANCi1UaXJ1DQrCoA0KRnJvbTogQWVv biBbbWFpbHRvOmFlb24tYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIENoYXJsZXMgRWNr ZWwgKGVja2VsY3UpDQpTZW50OiBGcmlkYXksIE1heSAwOSwgMjAxNCAxMjoxOCBBTQ0KVG86IFJv bmcgWmhhbmcNCkNjOiBhZW9uQGlldGYub3JnDQoNClN1YmplY3Q6IFJlOiBbQWVvbl0gQ09sbGFi b3JhdGl2ZSBORVR3b3JrIHZzIEFFT04/DQrCoA0KSGkgUm9uZywNCsKgDQpUaGFua3MgZm9yIGNs YXJpZnlpbmcuIFRoZXJlIGFyZSBwcm9zIGFuZCBjb25zIGJldHdlZW4gY29tYmluaW5nIHRvcGlj cyBpbnRvIGEgc2luZ2xlIGRvY3VtZW50IHZzLiBoYXZpbmcgc2V2ZXJhbCBzbWFsbGVyIGRvY3Vt ZW50cy4gSXQgd291bGQgYmUgcmVsYXRpdmVseSBzdHJhaWdodGZvcndhcmQgdG8gZGl2aWRlIHRo ZSBkcmFmdHMgYXMgeW91IHN1Z2dlc3QsIGFuZCBpdCB3b3VsZCBwcm9iYWJseSBzaW1wbGlmeSBt ZXJnaW5nIGluZm9ybWF0aW9uIGluIHRoZSBBRU9OIGFuZCBDT05FVCBkcmFmdHMgYXMgd2VsbC4N CsKgDQpDaGVlcnMsDQpDaGFybGVzDQrCoA0KRnJvbTogUm9uZyBaaGFuZyA8cnpoYW5nLmlldGZA Z21haWwuY29tPg0KRGF0ZTogU2F0dXJkYXksIE1heSAzLCAyMDE0IGF0IDg6MDYgUE0NClRvOiBD aGFybGVzIEVja2VsIDxlY2tlbGN1QGNpc2NvLmNvbT4NCkNjOiAiYWVvbkBpZXRmLm9yZyIgPGFl b25AaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW0Flb25dIENPbGxhYm9yYXRpdmUgTkVUd29yayB2 cyBBRU9OPw0KwqANCkhpIENoYXJsZXMsDQrCoA0KV2hhdCBJIG1lYW4gaXMgdGhhdCANCmRyYWZ0 LWVja2VsLWFlb24tcHJvYmxlbS1zdGF0ZW1lbnQtMDEgaGF2ZSB0b28gbWFueSB1c2UgY2FzZXMg YW5kIHNvbHV0aW9ucyByZWxhdGVkIGNvbnRlbnQsDQrCoA0KYnV0IEkgc2VlOg0KaHR0cDovL3d3 dy5pZXRmLm9yZy9pZC9kcmFmdC1mYW4taW50YXJlYS1jb25ldC1wcy11Yy0wMC50eHTCoHF1aXRl IGZvY3VzIG9uIHByb2JsZW0gc3RhdGVtZW50LCANCsKgDQpzbyBJIHdvdWxkIGxpa2UgdG8gc3Vn Z2VzdCB0aGF0IHdlIHN0YXJ0IGZyb20gc2Vjb25kIGRyYWZ0IGFib3V0IFBTLCBzb21lIG9mIHlv dXIgZHJhZnQgY291bGQgYmUgbWVyZ2VkIGludG8gdGhhdCBkcmFmdC4NCmFuZCB0aGVuIHdlIGNv dWxkIGhhdmUgc2VwZXJhdGUgcmVxdWlyZW1lbnQgZHJhZnQoIHdoaWNoIG1heWJlIGZyb20gQUVP TiBQUyksIGFuZCBhbm90aGVyIGdhcCBhbmFsc3lzaXMgZHJhZnQuDQrCoA0KY2hlZXJzLg0KwqAN ClJvbmcgWmhhbmcNCsKgDQpPbiBTYXQsIE1heSAzLCAyMDE0IGF0IDU6MzYgQU0sIENoYXJsZXMg RWNrZWwgKGVja2VsY3UpIDxlY2tlbGN1QGNpc2NvLmNvbT4gd3JvdGU6DQpIaSBSb25nLA0KwqAN ClNvcnJ5IGZvciB0aGUgZGVsYXkgaW4gcmVzcG9uZGluZy4gSSBhbSBub3Qgc3VyZSBJIHVuZGVy c3RhbmQgd2hhdCB5b3UgYXJlIGFza2luZyBmb3IgaGVyZSwgYnV0IHBlcmhhcHMgdGhpcyBwcmV2 aW91cyB0aHJlYWQgd2lsbCBiZSBvZiBoZWxwOg0KaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFy Y2hpdmUvd2ViL2Flb24vY3VycmVudC9tc2cwMDAzMy5odG1sDQrCoA0KQ2hlZXJzLA0KQ2hhcmxl cw0KwqANCkZyb206IFJvbmcgWmhhbmcgPHJ6aGFuZy5pZXRmQGdtYWlsLmNvbT4NCkRhdGU6IFN1 bmRheSwgQXByaWwgMjcsIDIwMTQgYXQgNzowNyBBTQ0KVG86ICJhZW9uQGlldGYub3JnIiA8YWVv bkBpZXRmLm9yZz4NClN1YmplY3Q6IFtBZW9uXSBDT2xsYWJvcmF0aXZlIE5FVHdvcmsgdnMgQUVP Tj8NCsKgDQpIZWxsbyBhbGwsDQrCoA0KSSBoYXZlIGJlZW4gb2JzZXJ2aW5nIHRoZSBjb21tZW50 cyBoZXJlLCBpdCBzZWVtcyB0aGF0IHNvbWUgb3BlcmF0b3JzIGFyZSBkaXNjdXNzaW5nIHRoZSBj dXJyZW50IHByb2JsZW1zIGFib3V0IENPbGxhYm9yYXRpdmUgTkVUd29yayBhbmQgaG93IGN1cnJl bnQgM0dQUCBSeCBpcyBub3Qgc3VmZmljaWVudCwgYW5kIGFsc28gc29tZSByZXF1aXJlbWVudHMg YW5kIGdhcCBhbmFseXNpcy4NCsKgDQpCdXQgZm9yIEFlb24ncyBjYXNlLCB3ZSBoYXZlbid0IHNl ZW4gYW55IG9wZXJhdG9ycyBpbGx1c3RyYXRpbmcgaG93IHRoZXkgYXJlIHNpbWlsYXJsIGJldHdl ZW4gQ09sbGFib3JhdGl2ZSBORVR3b3JrIGFuZCBBRU9OJ3MgcHJvYmxlbS4gQ2FuIGFueWJvZHkg ZnJvbSBBRU9OIGtpbmRseSBoZWxwIHRvwqBlbGFib3JhdGUgbW9yZSBoZXJlPw0KwqANCmNoZWVy cywNCsKgDQpSb25nIFpoYW5nDQrCoA0KDQo= From nobody Tue May 13 09:12:18 2014 Return-Path: X-Original-To: aeon@ietfa.amsl.com Delivered-To: aeon@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF8051A0087 for ; Tue, 13 May 2014 09:12:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.151 X-Spam-Level: X-Spam-Status: No, score=-2.151 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QsGlUpym0sMw for ; Tue, 13 May 2014 09:12:05 -0700 (PDT) Received: from huecha.unizar.es (huecha.unizar.es [155.210.1.51]) by ietfa.amsl.com (Postfix) with ESMTP id 17C2A1A0135 for ; Tue, 13 May 2014 09:11:07 -0700 (PDT) Received: from usuarioPC (gtc1pc12.cps.unizar.es [155.210.158.17]) by huecha.unizar.es (8.13.8/8.13.8/Debian-3) with ESMTP id s4DGAmfp017834; Tue, 13 May 2014 18:10:49 +0200 From: "Jose Saldana" To: , Date: Tue, 13 May 2014 18:11:03 +0200 Message-ID: <00ce01cf6ec5$f0ccccc0$d2666640$@unizar.es> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CF_01CF6ED6.B4568720" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac9uxSPiI7SYpatcQFqjS1KFc69HDw== Content-Language: es X-Mail-Scanned: Criba 2.0 + Clamd & Bogofilter Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/BgS72IgGQK6YeYiJrMiK-W2digs Cc: aeon@ietf.org Subject: [Aeon] One question regarding the "Scavenger class" X-BeenThere: aeon@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Enabled Open Networking \(AEON\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 16:12:14 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00CF_01CF6ED6.B4568720 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I have been reading draft-eckel-aeon-use-cases-01, and I was wondering: is "Scavenger class" the same as "Less than best effort" traffic, as defined in [1]?: "The usual definition of the LBE service is the following: in the event of congestion, all LBE traffic must be discarded before any BE packet is dropped." Jose [1] Y. Hayel, D. Ros and B. Tuffin, "Less-than-Best-Effort Services: Pricing and Scheduling", IEEE Proc. of INFOCOM, 2004 (http://www.irisa.fr/dionysos/pages_perso/tuffin/Publis/scheduling_infocom.p df) ------=_NextPart_000_00CF_01CF6ED6.B4568720 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I have been reading = draft-eckel-aeon-use-cases-01, and I was wondering: is “Scavenger = class” the same as “Less than best effort” traffic, as = defined in [1]?:

 

“The usual = definition of the LBE service is the following: in the event of = congestion, all LBE traffic must be discarded before any BE packet is = dropped.”

 

 

Jose

 

[1] Y. Hayel, D. Ros and B. Tuffin, “Less-than-Best-Effort Services: = Pricing and Scheduling”, IEEE Proc. of INFOCOM, 2004 (http://www.irisa.fr/dionysos/pages_perso/tuffin/Publis/sche= duling_infocom.pdf)

 

 

------=_NextPart_000_00CF_01CF6ED6.B4568720-- From nobody Tue May 13 09:19:40 2014 Return-Path: X-Original-To: aeon@ietfa.amsl.com Delivered-To: aeon@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3D31A00B2 for ; Tue, 13 May 2014 09:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.652 X-Spam-Level: X-Spam-Status: No, score=-2.652 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XYLWTbyE5iOe for ; Tue, 13 May 2014 09:19:36 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) by ietfa.amsl.com (Postfix) with ESMTP id D24281A0087 for ; Tue, 13 May 2014 09:19:35 -0700 (PDT) Received: from [192.168.1.20] (cpe-024-211-197-136.nc.res.rr.com [24.211.197.136]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id s4DGJK6n020966 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 13 May 2014 12:19:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1399997961; bh=jF66bLi3gMDLnbIabaVq7X/2hAJM0uo9hB6OelNxrRQ=; h=From:To:Subject:Cc:Date:Content-Type:In-Reply-To:Message-Id: Mime-Version:Reply-To; b=OmJXcouTO7PMK2RqfvGk84Sv+zYux9NZ/78iKYk8Pi9iYCioc9LkzgUZH0ihW3r2K zs8wpkoDMvCexs0oBzmtgER4aotMbKImlAUz9SeSe/KZfiRi8oxJxipgOiZr1R8qEw ra05RpN+oJnyJsGGAoPrpZ9ctk5zQvkv5ToFGwV0= From: "Paul E. Jones" To: "Jose Saldana" , eckelcu@cisco.com, tireddy@cisco.com Date: Tue, 13 May 2014 16:19:36 +0000 Content-Type: multipart/alternative; boundary="------=_MBF522A02F-609D-4F0B-8038-042407F055FD" In-Reply-To: <00ce01cf6ec5$f0ccccc0$d2666640$@unizar.es> Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/6.0.20154.0 Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/grhGr1RRqpr3N-wDM7e0MmqNTi4 Cc: aeon@ietf.org Subject: Re: [Aeon] One question regarding the "Scavenger class" X-BeenThere: aeon@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Paul E. Jones" List-Id: "Application Enabled Open Networking \(AEON\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2014 16:19:38 -0000 --------=_MBF522A02F-609D-4F0B-8038-042407F055FD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 Yes, it's effectively less-than-best-effort. I think the term originated with=20 http://qos.internet2.edu/wg/wg-documents/qbss-definition.txt. Paul ------ Original Message ------ From: "Jose Saldana" To: eckelcu@cisco.com; tireddy@cisco.com Cc: aeon@ietf.org Sent: 5/13/2014 12:11:03 PM Subject: [Aeon] One question regarding the "Scavenger class" >Hi, > > > >I have been reading draft-eckel-aeon-use-cases-01, and I was wondering:= =20 >is =E2=80=9CScavenger class=E2=80=9D the same as =E2=80=9CLess than best= effort=E2=80=9D traffic, as=20 >defined in [1]?: > > > >=E2=80=9CThe usual definition of the LBE service is the following: in the= event=20 >of congestion, all LBE traffic must be discarded before any BE packet=20 >is dropped.=E2=80=9D > > > > > >Jose > > > >[1] Y. Hayel, D. Ros and B. Tuffin, =E2=80=9CLess-than-Best-Effort Service= s:=20 >Pricing and Scheduling=E2=80=9D, IEEE Proc. of INFOCOM, 2004=20 >(http://www.irisa.fr/dionysos/pages_perso/tuffin/Publis/scheduling_infocom= .pdf) > > > > > --------=_MBF522A02F-609D-4F0B-8038-042407F055FD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Yes, it's effectively less-than-best-effort.
 
 
Paul
 
------ Original Message ------
From: "Jose Saldana" <jsaldan= a@unizar.es>
Sent: 5/13/2014 12:11:03 PM
Subject: [Aeon] One question regarding the "Scavenger class"
 

Hi,

 

I have been reading draft-eckel-aeon-use-cases-01, and = I was wondering: is =E2=80=9CScavenger class=E2=80=9D the same as =E2=80= =9CLess than best effort=E2=80=9D traffic, as defined in [1]?:

 

=E2=80=9CThe usual definition of the LBE service is the= following: in the event of congestion, all LBE traffic must be discarded= before any BE packet is dropped.=E2=80=9D

 

 

Jose<= /o:p>

 = ;

[1] Y.= Hayel, D. Ros and B. Tuff= in, =E2=80=9CLess-than-Best-Effort Services: Pricing and Scheduling= =E2=80=9D, IEEE Proc. of INFOCOM, 2004 (http://www.irisa.fr/dionysos/pages_pers= o/tuffin/Publis/scheduling_infocom.pdf)

 = ;

=  

--------=_MBF522A02F-609D-4F0B-8038-042407F055FD-- From nobody Fri May 23 16:11:58 2014 Return-Path: X-Original-To: aeon@ietfa.amsl.com Delivered-To: aeon@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2BC91A017E for ; Fri, 23 May 2014 16:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.152 X-Spam-Level: X-Spam-Status: No, score=-15.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yih8xROpg_kb for ; Fri, 23 May 2014 16:11:55 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 099481A0178 for ; Fri, 23 May 2014 16:11:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2467; q=dns/txt; s=iport; t=1400886713; x=1402096313; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=pIS3qQ96vZE1tMVRxaf8i++LF0lFoQY+RVlLR+ArWPc=; b=kBm9hzPQbNPXJGDZrpu0SeyH+c+4h0nnDI0IQJJ8euqiJPLrgoTmh85e vmUvJkMGC4q1EMlqrtE0Oaq5C1bLrGgIHqmyCQDggZdmeV3Uz5KBSOp+2 xBjd49gM8pVGnXjrpU1Q+sLjqpm+GDnpbv1HengqnVeOn9bfvce6EqS9c Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAAvVf1OtJV2R/2dsb2JhbABagwdSWMF7AYEFFnSCJQEBAQQ6PRICAQg2EDIbAQYDAgQTCYg4DdgTF45ZhEAEmXKBPZFqgziCLw X-IronPort-AV: E=Sophos;i="4.98,896,1392163200"; d="scan'208";a="46763266" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-6.cisco.com with ESMTP; 23 May 2014 23:11:52 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s4NNBqS4026035 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 23 May 2014 23:11:52 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.9]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Fri, 23 May 2014 18:11:52 -0500 From: "Charles Eckel (eckelcu)" To: "aeon@ietf.org" Thread-Topic: New Version Notification for draft-conet-aeon-problem-statement-00.txt Thread-Index: AQHPdtuQqD2ZBTVI7EKTZI/ZuDsHO5tOqYOA Date: Fri, 23 May 2014 23:11:51 +0000 Message-ID: References: <20140523230557.13150.38727.idtracker@ietfa.amsl.com> In-Reply-To: <20140523230557.13150.38727.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [10.21.94.117] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/aW0gIzlg9ai4RQkXjZqlkXw0vr4 Subject: [Aeon] FW: New Version Notification for draft-conet-aeon-problem-statement-00.txt X-BeenThere: aeon@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Enabled Open Networking \(AEON\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 May 2014 23:11:57 -0000 The following draft is the result of merging the CoNET and AEON problem statement drafts discussed previously on this list. It is intended as a replacement for both of them, combining important aspects of both and addressing review comments received to date. Please review and share your comments. Cheers, Charles On 5/23/14, 4:05 PM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-conet-aeon-problem-statement-00.txt >has been successfully submitted by Charles Eckel and posted to the >IETF repository. > >Name: draft-conet-aeon-problem-statement >Revision: 00 >Title: Application Enabled Collaborative Networking: Problem Statement >and Requirements >Document date: 2014-05-21 >Group: Individual Submission >Pages: 11 >URL: =20 >http://www.ietf.org/internet-drafts/draft-conet-aeon-problem-statement-00. >txt >Status: =20 >https://datatracker.ietf.org/doc/draft-conet-aeon-problem-statement/ >Htmlized: =20 >http://tools.ietf.org/html/draft-conet-aeon-problem-statement-00 > > >Abstract: > Identification and treatment of application flows are important to > many application providers and network operators. They often rely on > these capabilities to deploy and/or support a wide range of > applications. These applications, and the packet flows they generate > and consume, may have specific connectivity requirements that can be > met if made known to the network. Historically, this functionality > has been implemented to the extent possible using heuristics, which > inspect and infer flow characteristics. Heuristics may be based on > port ranges, network separation (e.g. subnets or VLANs, Deep Flow > Inspection (DFI), or Deep Packet Inspection (DPI). But many > application flows in current usages are dynamic, adaptive, time- > bound, encrypted, peer-to-peer, asymmetric, used on multipurpose > devices, and have different priorities depending on direction of > flow, user preferences, and other factors. Any combination of these > properties renders heuristic based techniques less effective and may > result in compromises to application security or user privacy. > > =20 > =20 > > >Please note that it may take a couple of minutes from the time of >submission >until the htmlized version and diff are available at tools.ietf.org. > >The IETF Secretariat > From nobody Mon May 26 05:35:02 2014 Return-Path: X-Original-To: aeon@ietfa.amsl.com Delivered-To: aeon@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFFFA1A0146 for ; Mon, 26 May 2014 05:34:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.252 X-Spam-Level: X-Spam-Status: No, score=-13.252 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1oF7ZqTWrcqr for ; Mon, 26 May 2014 05:34:57 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D09061A0129 for ; Mon, 26 May 2014 05:34:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=40972; q=dns/txt; s=iport; t=1401107694; x=1402317294; h=from:to:subject:date:message-id:mime-version; bh=OtLJtuCMlHFR2/kMKIshnKoVJuQmNzc+xxjeLzL1spM=; b=cecdCQeRmZ3ERbd02gsYtvn4GWRrY3PHbcs4KhaMIlOm0yT41u2ACfsg Kerb+sduIq6IgxHnPiHVjMbcjnhpFwGkxWuiB7ZQA28tK+/o7FuVl7noH onZa9ntgw1gRqBxUolLtgMvHLg8a2j6uHKJimrjAmlAR+bv+Ba9uKC/OW c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAJY0g1OtJA2G/2dsb2JhbABZgkJFUljCEYEQFnSCLBpaFwFAAT8nBC6IJw2jTbR2EwSNb1+DNoEVBJUshEeTJ4M4gi8 X-IronPort-AV: E=Sophos; i="4.98,913,1392163200"; d="scan'208,217"; a="47276036" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-6.cisco.com with ESMTP; 26 May 2014 12:34:53 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s4QCYrgG009847 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 26 May 2014 12:34:53 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.164]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Mon, 26 May 2014 07:34:53 -0500 From: "Pal Martinsen (palmarti)" To: "aeon@ietf.org" Thread-Topic: Comments on draft-conet-aeon-problem-statement-00 Thread-Index: AQHPeN7kjo24K3rIxEOSwBWusZ+WyA== Date: Mon, 26 May 2014 12:34:52 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.154.69] Content-Type: multipart/alternative; boundary="_000_BEF8A9CDC3E74010B36A7AF1CF6DAA53ciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/L7ccv95lo1kASh5V88LacPcRsEk Subject: [Aeon] Comments on draft-conet-aeon-problem-statement-00 X-BeenThere: aeon@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Enabled Open Networking \(AEON\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 May 2014 12:35:00 -0000 --_000_BEF8A9CDC3E74010B36A7AF1CF6DAA53ciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi all, Thanks to the authors for writing this up. I think this is a huge step in t= he right direction. Fairly short and easy to read. Below are my comments. (I accidentally pulled the last version from https:/= /github.com/Draft-Mafia/IETF-drafts/tree/master/AEON-Problem-Statement, so = all my comments are to that version, not the 00 draft. But they are fairly = similar and I only have fairly general comments at this stage.) Abstract Identification and treatment of application flows are important to many application providers and network operators. They often rely on these capabilities to deploy and/or support a wide range of applications. These applications, and the packet flows they generate and consume, may have specific connectivity requirements that can be .. specific flow requirements, such as latency, bandwidth and so on that ca= n be .. To me connectivity is to vague, but might cover it. met if made known to the network. Historically, this functionality has been implemented to the extent possible using heuristics, which inspect and infer flow characteristics. Heuristics may be based on port ranges, network separation (e.g. subnets or VLANs, Deep Flow Inspection (DFI), or Deep Packet Inspection (DPI). But many application flows in current usages are dynamic, adaptive, time- bound, encrypted, peer-to-peer, asymmetric, used on multipurpose devices, and have different priorities depending on direction of flow, user preferences, and other factors. Any combination of these properties renders heuristic based techniques less effective and may result in compromises to application security or user privacy. Are we planning to cover feedback from network to application (Something EC= N like) as well? To me this is an equally important part as it enables clie= nts to adopt to changing network conditions. Thus maximising the usefulness= of the network. For example rate limiting mechanisms that exist today migh= t react in a much more precise and predictable way. I see that Req-4 covers somewhat covers that. I would like to add some word= ing regarding notification for changed network conditions or something simi= lar. Table of Contents 1. Introduction 2. Typical Workflows 3. Limitations of Heuristic Based Solutions 4. Limitations of Existing Signaling Mechanisms 5. Efforts in Progress 6. Requirements 7. Acknowledgements 8. Informative References Authors' Addresses 1. Introduction Networks today, whether public or private, are challenged with demands to support rapidly increasing amounts of traffic. New channels for creating and consuming rich media are deployed at a rapid pace. Pervasive video and access on demand are becoming second nature to consumers. Communication applications make extensive use of rich media, placing unprecedented quality of experience expectation on the underlying network. These trends present challenges for network forecast and planning operations. Now more so than ever before, identification and treatment of application flows are critical for the successful deployment and operation of a growing number of business and household applications. These applications are based on wide range of signaling protocols and deployed by a diverse set of application providers that is not necessarily affiliated with the network providers across which the applications are used. Should we mention the SDN trend here as well? This have the potential to ma= ke SDN networks more powerful and easier to manage for the controller. The = more exact flow information the SDN controller can chew on, the better the = result. Historically, identification of application flows has been accomplished using heuristics, which infer flow characteristics based on port ranges, network separation, or inspection of the flow itself. Inspection techniques include DPI, which matches against characteristic signatures (e.g. key string, binary sequence, etc.) and DFI, which analyzes statistical characteristics and connection behavior of flows. Each of these techniques suffers from a set of limitations, particularly in the face of the challenges on the network outlined previously. Again having ECN like information going back to the client would be nice. S= ome feedback regarding available bandwidth would also be nice. But not as a= =93hard=94 reservation as done with RSVP. Just getting a hint would make c= lients much more robust in selection an appropriate sending rate for sits m= edia. Heuristic-based approaches may not be efficient and require continuous updates of application signatures. Port based solutions suffer from port overloading and inconsistent port usage. Network separation techniques like IP subnetting are error prone and increase network management complexity. DPI and DFI are computationally expensive, prone to error, and become more challenging with greater adoption of encrypted signaling and secured media. An additional drawback of DPI and DFI is that any insights are not available, or need to be recomputed, at network nodes further down the application flow path. As the IETF establishes default behaviors that thwart pervasive surveillance (e.g. [RFC7258]), it will be important to provide mechanisms for applications that want to have the network provide differential flow treatment for their data. The intent is to have applications protect the contents of their flows, yet have the ability to opt-in to information exchanges that provide a more precise allocation of network resources and thus a better user experience. Yes. And it is important to standardise this to avoid unwanted information = leakage. We should probably add a sentence or two regarding that. 2. Typical Workflows Various heuristic based approaches are used prevalently and successfully for the following workflows: 1. Provide network operators with visibility of traffic usage and patterns for troubleshooting, capacity planning, and other off network workflows. This is done by exporting observed traffic analysis via standard protocols such as IPFIX [RFC7011] and SNMP [RFC3416]as well as by proprietary protocols and methods. 2. Provide network operators with visibility of application and data usage for accounting and billing. 3. Provide differentiated network services for specific traffic according to network operator defined policies, including traffic classification, policing and shaping (e.g. [RFC2475]), providing admission control (e.g. [RFC6601]), impacting routing, and permitting passage of specific traffic (e.g. firewall functions). 4. Provide network feedback to the client. This data can be used by the c= lient to improve rate adopting schemes, and might also provide better hints= on how much bandwidth a client can expect to send through the network. (RM= CAT WG might chime in here) 3. Limitations of Heuristic Based Solutions [cut] 4. Limitations of Existing Signaling Mechanisms The IETF has standardized several mechanisms involving explicit signaling between applications and the network that may be used to support visibility and differentiated network services workflows. Unfortunately, none of these has experienced widespread deployment success, nor are they well suited for the applications usages described previously. Existing signaling options include the following: o RSVP [RFC2205] is the original on-path signaling protocol standardized by the IETF. It is transported out-of-band and could be used to signal information about any transport protocol traffic (it currently supports TCP and UDP). Its original goal was to provide admission control. Its requirement for explicit reservation of resources end to end proved too heavy for most network environments. Its success was further impacted by its reliance on router-alert, which often leads to RSVP packets being filtered by intervening networks, and by its requirement for access to a raw socket, something that is generally not available to applications running in user space. To date, more lightweight signaling workflows utilizing RSVP have not been standardized within the IETF. o NSIS (next Steps in Signaling) [RFC5978] is the next iteration of RSVP-like signaling defined by the IETF. It focused on the same fundamental workflow as RSVP admission control as its main driver, and because it did not provide significant enough use-case benefits over RSVP, it has seen even less adoption than RSVP. o DiffServ [RFC4594] and VAN Tagging [IEEE-802.1Q] style packet marking can help provide QoS in some environments, but such markings are often modified or removed at various points in the network or when crossing network boundaries. There are additional limitations when using DiffServ with real-time communications applications, and the DART working group has been chartered to write a document that explains the limitations that exist with DiffServ when used with RTP in general as well in the specific RTCWeb use cases [I-D.ietf-rtcweb-use-cases-and-requirements]. And if we are doing network to client feedback. * ECN. Only works for TCP. Same problems as DSCP. Difficult for applicatio= ns to get access to information in the TCP header or IP header. 5. Efforts in Progress [cut] 6. Requirements Rather than encourage independent, protocol specific solutions to this problem, this document advocates a protocol and application independent information model and individual data models that can be applied in a consistent fashion across a variety of protocols to enable explicit communication between applications and the networks on which they are used. The requirements are: Req-1: Allow applications to explicitly signal their flow characteristics to the network. Req-2: Provide network nodes visibility to application flow characteristics. Req-3: Enable network nodes to contribute to application flow descriptions. Req-4: Allow applications to receive resulting flow descriptions as feedback from the network. Req-4b: Allow application to receive notifications regarding changing netwo= rk conditions? Req-5: Complement existing heuristic based mechanisms. Req-6: Provide differentiated service for both directions of a flow, including flows that cross administrative boundaries. Req-7: Provide mechanism to authenticate and authorize endpoints/ applications to signal flow characteristics, including 3rd party authentication and authorization for over-the-top (OTT) applications. Req-8: Provide mechanism for integrity protection and replay protection of messages exchanged between the application and the network. .-. P=E5l-Erik --_000_BEF8A9CDC3E74010B36A7AF1CF6DAA53ciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi all,

Thanks to the authors for writing this up. I think this is a huge step= in the right direction. Fairly short and easy to read. 

Below are my comments. (I accidentally pulled the last version from&nb= sp;https://github.com/Draft-Mafia/IETF-drafts/tree/master/AE= ON-Problem-Statement, so all my comments are to that version, not the 00 draft. But they are fairly similar and I o= nly have fairly general comments at this stage.)


Abstract

 &nbs= p; Identification and treatment of application flows are important to
 &nbs= p; many application providers and network operators.  They often rely = on
 &nbs= p; these capabilities to deploy and/or support a wide range of
 &nbs= p; applications.  These applications, and the packet flows they genera= te
 &nbs= p; and consume, may have specific connectivity requirements that can be

.. specific flow requirements, such as latency, bandwidth and so on that ca= n be .. 

To me connectivity is to vague, but might cover it. 

 &nbs= p; met if made known to the network.  Historically, this functionality=
 &nbs= p; has been implemented to the extent possible using heuristics, which
 &nbs= p; inspect and infer flow characteristics.  Heuristics may be based on=
 &nbs= p; port ranges, network separation (e.g. subnets or VLANs, Deep Flow
 &nbs= p; Inspection (DFI), or Deep Packet Inspection (DPI).  But many
 &nbs= p; application flows in current usages are dynamic, adaptive, time-
 &nbs= p; bound, encrypted, peer-to-peer, asymmetric, used on multipurpose
 &nbs= p; devices, and have different priorities depending on direction of
 &nbs= p; flow, user preferences, and other factors.  Any combination of thes= e
 &nbs= p; properties renders heuristic based techniques less effective and may
 &nbs= p; result in compromises to application security or user privacy.


Are we planning to cover feedback from network to application (Somethi= ng ECN like) as well? To me this is an equally important part as it enables= clients to adopt to changing network conditions. Thus maximising the usefu= lness of the network. For example rate limiting mechanisms that exist today might react in a much more preci= se and predictable way. 

I see that Req-4 covers somewhat covers that. I would like to add some= wording regarding notification for changed network conditions or something= similar.  


Table of C= ontents

 &nbs= p; 1.  Introduction
 &nbs= p; 2.  Typical Workflows
 &nbs= p; 3.  Limitations of Heuristic Based Solutions
 &nbs= p; 4.  Limitations of Existing Signaling Mechanisms
 &nbs= p; 5.  Efforts in Progress
 &nbs= p; 6.  Requirements
 &nbs= p; 7.  Acknowledgements
 &nbs= p; 8.  Informative References
 &nbs= p; Authors' Addresses

1.  I= ntroduction

 &nbs= p; Networks today, whether public or private, are challenged with
 &nbs= p; demands to support rapidly increasing amounts of traffic.  New
 &nbs= p; channels for creating and consuming rich media are deployed at a
 &nbs= p; rapid pace.  Pervasive video and access on demand are becoming seco= nd
 &nbs= p; nature to consumers.  Communication applications make extensive use=
 &nbs= p; of rich media, placing unprecedented quality of experience
 &nbs= p; expectation on the underlying network.  These trends present
 &nbs= p; challenges for network forecast and planning operations.

 &nbs= p; Now more so than ever before, identification and treatment of
 &nbs= p; application flows are critical for the successful deployment and
 &nbs= p; operation of a growing number of business and household applications.
 &nbs= p; These applications are based on wide range of signaling protocols and
 &nbs= p; deployed by a diverse set of application providers that is not
 &nbs= p; necessarily affiliated with the network providers across which the
 &nbs= p; applications are used.

Should we mention the SDN trend here as well? This have the potential = to make SDN networks more powerful and easier to manage for the controller.= The more exact flow information the SDN controller can chew on, the better= the result. 

 &nbs= p; Historically, identification of application flows has been
 &nbs= p; accomplished using heuristics, which infer flow characteristics based
 &nbs= p; on port ranges, network separation, or inspection of the flow itself.
 &nbs= p; Inspection techniques include DPI, which matches against
 &nbs= p; characteristic signatures (e.g. key string, binary sequence, etc.)
 &nbs= p; and DFI, which analyzes statistical characteristics and connection
 &nbs= p; behavior of flows.  Each of these techniques suffers from a set of<= /div>
 &nbs= p; limitations, particularly in the face of the challenges on the
 &nbs= p; network outlined previously.

Again having ECN like information going back to the client would be ni= ce. Some feedback regarding available bandwidth would also be nice. But not= as a =93hard=94 reservation as done with RSVP. Just getting a hint would m= ake clients much more robust in selection an appropriate sending rate for sits media. 

 &nbs= p; Heuristic-based approaches may not be efficient and require
 &nbs= p; continuous updates of application signatures.  Port based solutions=
 &nbs= p; suffer from port overloading and inconsistent port usage.  Network<= /div>
 &nbs= p; separation techniques like IP subnetting are error prone and increase
 &nbs= p; network management complexity.  DPI and DFI are computationally
 &nbs= p; expensive, prone to error, and become more challenging with greater
 &nbs= p; adoption of encrypted signaling and secured media.  An additional
 &nbs= p; drawback of DPI and DFI is that any insights are not available, or
 &nbs= p; need to be recomputed, at network nodes further down the application
 &nbs= p; flow path.

 &nbs= p; As the IETF establishes default behaviors that thwart pervasive
 &nbs= p; surveillance (e.g.  [RFC7258]), it will be important to provide
 &nbs= p; mechanisms for applications that want to have the network provide
 &nbs= p; differential flow treatment for their data.  The intent is to have<= /div>
 &nbs= p; applications protect the contents of their flows, yet have the
 &nbs= p; ability to opt-in to information exchanges that provide a more
 &nbs= p; precise allocation of network resources and thus a better user
 &nbs= p; experience.


Yes. And it is important to standardise this to avoid unwanted informa= tion leakage. We should probably add a sentence or two regarding that. = ;

2.  T= ypical Workflows

 &nbs= p; Various heuristic based approaches are used prevalently and
 &nbs= p; successfully for the following workflows:

 &nbs= p; 1.  Provide network operators with visibility of traffic usage and<= /div>
 &nbs= p;     patterns for troubleshooting, capacity planning, and other= off
 &nbs= p;     network workflows.  This is done by exporting observe= d traffic
 &nbs= p;     analysis via standard protocols such as IPFIX [RFC7011] an= d SNMP
 &nbs= p;     [RFC3416]as well as by proprietary protocols and methods.<= /div>

 &nbs= p; 2.  Provide network operators with visibility of application and da= ta
 &nbs= p;     usage for accounting and billing.

 &nbs= p; 3.  Provide differentiated network services for specific traffic
 &nbs= p;     according to network operator defined policies, including = traffic
 &nbs= p;     classification, policing and shaping (e.g.  [RFC2475]= ), providing
 &nbs= p;     admission control (e.g.  [RFC6601]), impacting routin= g, and
 &nbs= p;     permitting passage of specific traffic (e.g. firewall func= tions).

4.   Provide network feedback to the client. This data can be used by = the client to improve rate adopting schemes, and might also provide better = hints on how much bandwidth a client can expect to send through the network= . (RMCAT WG might chime in here)

3.  L= imitations of Heuristic Based Solutions
  
[cut]

4.  L= imitations of Existing Signaling Mechanisms

 &nbs= p; The IETF has standardized several mechanisms involving explicit
 &nbs= p; signaling between applications and the network that may be used to
 &nbs= p; support visibility and differentiated network services workflows.
 &nbs= p; Unfortunately, none of these has experienced widespread deployment
 &nbs= p; success, nor are they well suited for the applications usages
 &nbs= p; described previously.  Existing signaling options include the
 &nbs= p; following:

 &nbs= p; o  RSVP [RFC2205] is the original on-path signaling protocol
  &nb= sp;   standardized by the IETF.  It is transported out-of-band an= d could
  &nb= sp;   be used to signal information about any transport protocol traff= ic
  &nb= sp;   (it currently supports TCP and UDP).  Its original goal was= to
  &nb= sp;   provide admission control.  Its requirement for explicit
  &nb= sp;   reservation of resources end to end proved too heavy for most
  &nb= sp;   network environments.  Its success was further impacted by = its
  &nb= sp;   reliance on router-alert, which often leads to RSVP packets bein= g
  &nb= sp;   filtered by intervening networks, and by its requirement for
  &nb= sp;   access to a raw socket, something that is generally not availabl= e
  &nb= sp;   to applications running in user space.  To date, more light= weight
  &nb= sp;   signaling workflows utilizing RSVP have not been standardized
  &nb= sp;   within the IETF.

 &nbs= p; o  NSIS (next Steps in Signaling) [RFC5978] is the next iteration o= f
  &nb= sp;   RSVP-like signaling defined by the IETF.  It focused on the= same
  &nb= sp;   fundamental workflow as RSVP admission control as its main drive= r,
  &nb= sp;   and because it did not provide significant enough use-case
  &nb= sp;   benefits over RSVP, it has seen even less adoption than RSVP.

 &nbs= p; o  DiffServ [RFC4594] and VAN Tagging [IEEE-802.1Q] style packet
  &nb= sp;   marking can help provide QoS in some environments, but such
  &nb= sp;   markings are often modified or removed at various points in the<= /div>
  &nb= sp;   network or when crossing network boundaries.  There are add= itional
  &nb= sp;   limitations when using DiffServ with real-time communications
  &nb= sp;   applications, and the DART working group has been chartered to
  &nb= sp;   write a document that explains the limitations that exist with
  &nb= sp;   DiffServ when used with RTP in general as well in the specific
  &nb= sp;   RTCWeb use cases [I-D.ietf-rtcweb-use-cases-and-requirements].

And if we are doing network to client feedback.

 * ECN. Only works for TCP. Same problems as DSCP. Difficult for = applications to get access to information in the TCP header or IP header.
5.  E= fforts in Progress


[cut]

6.  R= equirements

 &nbs= p; Rather than encourage independent, protocol specific solutions to
 &nbs= p; this problem, this document advocates a protocol and application
 &nbs= p; independent information model and individual data models that can be
 &nbs= p; applied in a consistent fashion across a variety of protocols to
 &nbs= p; enable explicit communication between applications and the networks
 &nbs= p; on which they are used.  The requirements are:

 &nbs= p; Req-1:  Allow applications to explicitly signal their flow
  &nb= sp;   characteristics to the network.

 &nbs= p; Req-2:  Provide network nodes visibility to application flow
  &nb= sp;   characteristics.

 &nbs= p; Req-3:  Enable network nodes to contribute to application flow
  &nb= sp;   descriptions.

 &nbs= p; Req-4:  Allow applications to receive resulting flow descriptions a= s
  &nb= sp;   feedback from the network.

Req-4b: Allow application to receive notifications regarding changing = network conditions?

 &nbs= p; Req-5:  Complement existing heuristic based mechanisms.

 &nbs= p; Req-6:  Provide differentiated service for both directions of a flo= w,
  &nb= sp;   including flows that cross administrative boundaries.

 &nbs= p; Req-7:  Provide mechanism to authenticate and authorize endpoints/<= /div>
  &nb= sp;   applications to signal flow characteristics, including 3rd party=
  &nb= sp;   authentication and authorization for over-the-top (OTT)
  &nb= sp;   applications.

 &nbs= p; Req-8:  Provide mechanism for integrity protection and replay
  &nb= sp;   protection of messages exchanged between the application and the=
  &nb= sp;   network.


.-.
P=E5l-Erik

--_000_BEF8A9CDC3E74010B36A7AF1CF6DAA53ciscocom_-- From nobody Tue May 27 15:22:24 2014 Return-Path: X-Original-To: aeon@ietfa.amsl.com Delivered-To: aeon@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 322BC1A07A4 for ; Tue, 27 May 2014 15:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIO14y0SER9j for ; Tue, 27 May 2014 15:22:20 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80DA91A07A2 for ; Tue, 27 May 2014 15:22:20 -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.7-GA FastPath queued) with ESMTP id BEP47469; Tue, 27 May 2014 22:22:16 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 27 May 2014 23:21:48 +0100 Received: from DFWEML703-CHM.china.huawei.com (10.193.5.130) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 27 May 2014 23:22:15 +0100 Received: from DFWEML701-CHM.china.huawei.com ([169.254.1.64]) by dfweml703-chm.china.huawei.com ([169.254.5.144]) with mapi id 14.03.0158.001; Tue, 27 May 2014 15:22:02 -0700 From: Linda Dunbar To: "Charles Eckel (eckelcu)" , "aeon@ietf.org" Thread-Topic: New Version Notification for draft-conet-aeon-problem-statement-00.txt Thread-Index: AQHPdtuQqD2ZBTVI7EKTZI/ZuDsHO5tOqYOAgAZaNRA= Date: Tue, 27 May 2014 22:22:01 +0000 Message-ID: <4A95BA014132FF49AE685FAB4B9F17F645D265BF@dfweml701-chm.china.huawei.com> References: <20140523230557.13150.38727.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.47.153.227] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/ZASn7h3mytb_MQQqy1EUN703-5w Subject: Re: [Aeon] New Version Notification for draft-conet-aeon-problem-statement-00.txt X-BeenThere: aeon@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Enabled Open Networking \(AEON\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 22:22:23 -0000 Charles, et al:=20 Your Req-1 states "allow applications to explicitly signal their flow chara= cteristics to the networks".=20 Can you give a few examples of what those "flow characteristics" are? The draft also states that DPI can't be performed when the traffic is encry= pted. What kind of signals will the applications that encrypt their traffic= send to network?=20 Almost all End to End traffic are aggregated by network operators edge devi= ces (there could be many layers of operators). All the signals from end dev= ices are lost once entering provider domain. I think a more realistic appro= ach is to establish interface between applications to network controllers. Linda=20 -----Original Message----- From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Charles Eckel (eckel= cu) Sent: Friday, May 23, 2014 6:12 PM To: aeon@ietf.org Subject: [Aeon] FW: New Version Notification for draft-conet-aeon-problem-s= tatement-00.txt The following draft is the result of merging the CoNET and AEON problem sta= tement drafts discussed previously on this list. It is intended as a replac= ement for both of them, combining important aspects of both and addressing = review comments received to date. Please review and share your comments. Cheers, Charles On 5/23/14, 4:05 PM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-conet-aeon-problem-statement-00.txt >has been successfully submitted by Charles Eckel and posted to the IETF=20 >repository. > >Name: draft-conet-aeon-problem-statement >Revision: 00 >Title: Application Enabled Collaborative Networking: Problem Statement >and Requirements >Document date: 2014-05-21 >Group: Individual Submission >Pages: 11 >URL: =20 >http://www.ietf.org/internet-drafts/draft-conet-aeon-problem-statement-00. >txt >Status: =20 >https://datatracker.ietf.org/doc/draft-conet-aeon-problem-statement/ >Htmlized: =20 >http://tools.ietf.org/html/draft-conet-aeon-problem-statement-00 > > >Abstract: > Identification and treatment of application flows are important to > many application providers and network operators. They often rely on > these capabilities to deploy and/or support a wide range of > applications. These applications, and the packet flows they generate > and consume, may have specific connectivity requirements that can be > met if made known to the network. Historically, this functionality > has been implemented to the extent possible using heuristics, which > inspect and infer flow characteristics. Heuristics may be based on > port ranges, network separation (e.g. subnets or VLANs, Deep Flow > Inspection (DFI), or Deep Packet Inspection (DPI). But many > application flows in current usages are dynamic, adaptive, time- > bound, encrypted, peer-to-peer, asymmetric, used on multipurpose > devices, and have different priorities depending on direction of > flow, user preferences, and other factors. Any combination of these > properties renders heuristic based techniques less effective and may > result in compromises to application security or user privacy. > > =20 > =20 > > >Please note that it may take a couple of minutes from the time of=20 >submission until the htmlized version and diff are available at=20 >tools.ietf.org. > >The IETF Secretariat > _______________________________________________ Aeon mailing list Aeon@ietf.org https://www.ietf.org/mailman/listinfo/aeon From nobody Tue May 27 15:53:38 2014 Return-Path: X-Original-To: aeon@ietfa.amsl.com Delivered-To: aeon@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 046851A02B5 for ; Tue, 27 May 2014 15:53:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.643 X-Spam-Level: X-Spam-Status: No, score=-1.643 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qnAkU4JPg8KZ for ; Tue, 27 May 2014 15:53:35 -0700 (PDT) Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79EA01A029F for ; Tue, 27 May 2014 15:53:35 -0700 (PDT) Received: from [192.168.1.20] (cpe-024-211-197-136.nc.res.rr.com [24.211.197.136]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id s4RMqXZK002918 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 27 May 2014 18:52:33 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1401231154; bh=CXWVEW52/+E1dlAivk3kAzOQsmdFjDP6hIWffpWMA2A=; h=From:To:Subject:Date:Content-Transfer-Encoding:Content-Type: In-Reply-To:Message-Id:Mime-Version:Reply-To; b=J9c+5paporTaLCMv8LafxiN/SUfb5IBZ1Ho8skiOy9JvtFHr026nYCoPTMn8mqS10 U7wTssf+3bo82osYNfNVKWpO2Td5fmey2BflMyrt4Zx1wVQnYt5uy+SyUm59dPSXey wPFku5lh/yP0RMZJ0JuR4NPvSE9GDU7XsscSFvNY= From: "Paul E. Jones" To: "Linda Dunbar" , "Charles Eckel (eckelcu)" , "aeon@ietf.org" Date: Tue, 27 May 2014 22:52:41 +0000 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; format=flowed; charset=utf-8 In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645D265BF@dfweml701-chm.china.huawei.com> Message-Id: Mime-Version: 1.0 User-Agent: eM_Client/6.0.20154.0 Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/retDU_AE820gzvpFjq7l8Bnd15E Subject: Re: [Aeon] New Version Notification for draft-conet-aeon-problem-statement-00.txt X-BeenThere: aeon@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: "Paul E. Jones" List-Id: "Application Enabled Open Networking \(AEON\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 May 2014 22:53:37 -0000 Linda, I'd assume this is open for discussion, but I can imagine information=20 such as tolerance to loss, delay, and jitter are important. One piece of data I think would be useful to send into the network is=20 the Traffic Class Label (TCL), which identifies with some precision what= =20 the flow is. For example, is this a real-time gaming session, a=20 conversational voice/video session, bulk file transfer, or other? The=20 TCL would tell us this. Another piece of data might just be some kind of locally-determined=20 priority value. You're correct that traffic is aggregated, but it might be useful if=20 this information could somehow be conveyed end-to-end for the benefit of= =20 other carrier or enterprise networks. Paul ------ Original Message ------ From: "Linda Dunbar" To: "Charles Eckel (eckelcu)" ; "aeon@ietf.org"=20 Sent: 5/27/2014 6:22:01 PM Subject: Re: [Aeon] New Version Notification for=20 draft-conet-aeon-problem-statement-00.txt >Charles, et al: > >Your Req-1 states "allow applications to explicitly signal their flow=20 >characteristics to the networks". > >Can you give a few examples of what those "flow characteristics" are? > >The draft also states that DPI can't be performed when the traffic is=20 >encrypted. What kind of signals will the applications that encrypt=20 >their traffic send to network? > > >Almost all End to End traffic are aggregated by network operators edge=20 >devices (there could be many layers of operators). All the signals from= =20 >end devices are lost once entering provider domain. I think a more=20 >realistic approach is to establish interface between applications to=20 >network controllers. > > >Linda >-----Original Message----- >From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Charles Eckel=20 >(eckelcu) >Sent: Friday, May 23, 2014 6:12 PM >To: aeon@ietf.org >Subject: [Aeon] FW: New Version Notification for=20 >draft-conet-aeon-problem-statement-00.txt > >The following draft is the result of merging the CoNET and AEON problem= =20 >statement drafts discussed previously on this list. It is intended as a= =20 >replacement for both of them, combining important aspects of both and=20 >addressing review comments received to date. Please review and share=20 >your comments. > >Cheers, >Charles > >On 5/23/14, 4:05 PM, "internet-drafts@ietf.org"=20 > >wrote: > >> >>A new version of I-D, draft-conet-aeon-problem-statement-00.txt >>has been successfully submitted by Charles Eckel and posted to the=20 >>IETF >>repository. >> >>Name: draft-conet-aeon-problem-statement >>Revision: 00 >>Title: Application Enabled Collaborative Networking: Problem Statement >>and Requirements >>Document date: 2014-05-21 >>Group: Individual Submission >>Pages: 11 >>URL: >>http://www.ietf.org/internet-drafts/draft-conet-aeon-problem-statement-00= . >>txt >>Status: >>https://datatracker.ietf.org/doc/draft-conet-aeon-problem-statement/ >>Htmlized: >>http://tools.ietf.org/html/draft-conet-aeon-problem-statement-00 >> >> >>Abstract: >> Identification and treatment of application flows are important to >> many application providers and network operators. They often rely=20 >>on >> these capabilities to deploy and/or support a wide range of >> applications. These applications, and the packet flows they=20 >>generate >> and consume, may have specific connectivity requirements that can=20 >>be >> met if made known to the network. Historically, this functionality >> has been implemented to the extent possible using heuristics, which >> inspect and infer flow characteristics. Heuristics may be based on >> port ranges, network separation (e.g. subnets or VLANs, Deep Flow >> Inspection (DFI), or Deep Packet Inspection (DPI). But many >> application flows in current usages are dynamic, adaptive, time- >> bound, encrypted, peer-to-peer, asymmetric, used on multipurpose >> devices, and have different priorities depending on direction of >> flow, user preferences, and other factors. Any combination of these >> properties renders heuristic based techniques less effective and=20 >>may >> result in compromises to application security or user privacy. >> >> >> >> >> >>Please note that it may take a couple of minutes from the time of >>submission until the htmlized version and diff are available at >>tools.ietf.org. >> >>The IETF Secretariat >> > >_______________________________________________ >Aeon mailing list >Aeon@ietf.org >https://www.ietf.org/mailman/listinfo/aeon > >_______________________________________________ >Aeon mailing list >Aeon@ietf.org >https://www.ietf.org/mailman/listinfo/aeon From nobody Wed May 28 02:30:22 2014 Return-Path: X-Original-To: aeon@ietfa.amsl.com Delivered-To: aeon@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 062691A0899 for ; Wed, 28 May 2014 02:30:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.852 X-Spam-Level: X-Spam-Status: No, score=-12.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MANGLED_AVOID=2.3, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eZVrf9qOxUw0 for ; Wed, 28 May 2014 02:30:19 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 328341A089B for ; Wed, 28 May 2014 02:30:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6392; q=dns/txt; s=iport; t=1401269416; x=1402479016; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=kS9TbMF0LqyT4MhuaUemgbxId5yS8JbqL/SbuQnzxgc=; b=le3+t9cdwgQDoYpd4bOAncfkrB8gREB403R1V7rW7mS07HWGCznG03Sh SzHST3Yoh9g4ynfkDSVK5dTj5dbfeY5pzxKmbT/tjOSlaVHSpeG0AfPCw EHMdk1+c3qqFMJX16o779IshHwbLeTcIN9oA45AXcZsFE3Nw8J/YbKktp 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj4FACSshVOtJV2U/2dsb2JhbABZgwdSWLpohzoBgQsWdIIlAQEBAwEBAQFrCQIFBwQCAQgRBAEBAScHJwsUCQgCBA4FCRKIHwgN1WcXjgEBARwRIgcGgyWBFQSVLYRIgT2RaoF4gUCBdjk X-IronPort-AV: E=Sophos;i="4.98,927,1392163200"; d="scan'208";a="328469415" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-5.cisco.com with ESMTP; 28 May 2014 09:30:15 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s4S9UFjI003104 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 28 May 2014 09:30:15 GMT Received: from xmb-rcd-x06.cisco.com ([169.254.6.164]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Wed, 28 May 2014 04:30:14 -0500 From: "Pal Martinsen (palmarti)" To: Linda Dunbar Thread-Topic: [Aeon] New Version Notification for draft-conet-aeon-problem-statement-00.txt Thread-Index: AQHPdtuQqD2ZBTVI7EKTZI/ZuDsHO5tOqYOAgAZaNRCAARE+AA== Date: Wed, 28 May 2014 09:30:14 +0000 Message-ID: <438D87AD-3C55-44D7-9DDA-E530522E34CD@cisco.com> References: <20140523230557.13150.38727.idtracker@ietfa.amsl.com> <4A95BA014132FF49AE685FAB4B9F17F645D265BF@dfweml701-chm.china.huawei.com> In-Reply-To: <4A95BA014132FF49AE685FAB4B9F17F645D265BF@dfweml701-chm.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.154.69] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/xCwjj6g8E4zp6RFIGligmfWIwmE Cc: "aeon@ietf.org" , "Charles Eckel \(eckelcu\)" Subject: Re: [Aeon] New Version Notification for draft-conet-aeon-problem-statement-00.txt X-BeenThere: aeon@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Enabled Open Networking \(AEON\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 May 2014 09:30:21 -0000 On 28 May 2014, at 00:22, Linda Dunbar wrote: > Charles, et al:=20 >=20 > Your Req-1 states "allow applications to explicitly signal their flow cha= racteristics to the networks".=20 >=20 > Can you give a few examples of what those "flow characteristics" are? This needs to be discussed further, but my initial thought on this are that= we need to have simple and to the core values we can act upon. Thinks like= bandwidth usage, latency requirement, packet loss tolerance would be helpf= ul. Having a higher level of description like Audio, Video or application d= ata might be useful, but it all boils down to the =93core=94 flow character= istics. The characteristics must also be dynamic and expected to change dur= ing the lifetime of the stream. A video stream can be very =93elastic=94 in= its behavior dependant on how much movement there is in the picture and so= on.=20 >=20 > The draft also states that DPI can't be performed when the traffic is enc= rypted. What kind of signals will the applications that encrypt their traff= ic send to network?=20 >=20 For encrypted video streams is is possible to send unencrypted packets (For= example STUN) multiplexed in the same stream. Those packets can contain in= formation about the stream characteristics. But we need to make sure we do = not leak any unwanted information, so it is important that the characterist= ics we describe are standardised and well understood. (I would consider the= stream characteristics as =93envelope=94 information. Like an Air-mail sta= mp on an envelope) >=20 > Almost all End to End traffic are aggregated by network operators edge de= vices (there could be many layers of operators). All the signals from end d= evices are lost once entering provider domain. I think a more realistic app= roach is to establish interface between applications to network controllers= . >=20 Loss of information when crossing administrative domains is a big problem. = Having the application talk to each of the controllers in the different adm= inistrative domains is also going to be complicated. How do the client disc= over what controllers to speak to?=20 One thing we probably should mention in the problem statement draft is that= it is important that we come up with a solution that is easy for the clien= ts to implement and use. I think that is a key point if we want this to be = successful.=20 On approach we are playing with is described in: http://tools.ietf.org/html/draft-martinsen-tram-discuss-00 Think of this as DSCP, ECN and a bit of RSCP signalled using STUN messages = sent in-band in the flow. The edge device needs to pick up those STUN messa= ges. Code for doing that looks roughly as: bool stunlib_isStunMsg(const uint8_t *payload, uint16_t length) { /* first 2 bits must be 00, STUN header and magic cookie */ return (((*payload & STUN_PACKET_MASK) =3D=3D STUN_PACKET) && (length >=3D 20) && (memcmp(payload+4, (void *)StunCookie, StunCookieSize) =3D=3D 0= )); } This puts some stress on the devices that needs to detect those messages, b= ut should be much easier than doing DPI.=20 .-. P=E5l-Erik >=20 > Linda=20 > -----Original Message----- > From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Charles Eckel (eck= elcu) > Sent: Friday, May 23, 2014 6:12 PM > To: aeon@ietf.org > Subject: [Aeon] FW: New Version Notification for draft-conet-aeon-problem= -statement-00.txt >=20 > The following draft is the result of merging the CoNET and AEON problem s= tatement drafts discussed previously on this list. It is intended as a repl= acement for both of them, combining important aspects of both and addressin= g review comments received to date. Please review and share your comments. >=20 > Cheers, > Charles >=20 > On 5/23/14, 4:05 PM, "internet-drafts@ietf.org" > wrote: >=20 >>=20 >> A new version of I-D, draft-conet-aeon-problem-statement-00.txt >> has been successfully submitted by Charles Eckel and posted to the IETF= =20 >> repository. >>=20 >> Name: draft-conet-aeon-problem-statement >> Revision: 00 >> Title: Application Enabled Collaborative Networking: Problem Statement >> and Requirements >> Document date: 2014-05-21 >> Group: Individual Submission >> Pages: 11 >> URL: =20 >> http://www.ietf.org/internet-drafts/draft-conet-aeon-problem-statement-0= 0. >> txt >> Status: =20 >> https://datatracker.ietf.org/doc/draft-conet-aeon-problem-statement/ >> Htmlized: =20 >> http://tools.ietf.org/html/draft-conet-aeon-problem-statement-00 >>=20 >>=20 >> Abstract: >> Identification and treatment of application flows are important to >> many application providers and network operators. They often rely on >> these capabilities to deploy and/or support a wide range of >> applications. These applications, and the packet flows they generate >> and consume, may have specific connectivity requirements that can be >> met if made known to the network. Historically, this functionality >> has been implemented to the extent possible using heuristics, which >> inspect and infer flow characteristics. Heuristics may be based on >> port ranges, network separation (e.g. subnets or VLANs, Deep Flow >> Inspection (DFI), or Deep Packet Inspection (DPI). But many >> application flows in current usages are dynamic, adaptive, time- >> bound, encrypted, peer-to-peer, asymmetric, used on multipurpose >> devices, and have different priorities depending on direction of >> flow, user preferences, and other factors. Any combination of these >> properties renders heuristic based techniques less effective and may >> result in compromises to application security or user privacy. >>=20 >>=20 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of=20 >> submission until the htmlized version and diff are available at=20 >> tools.ietf.org. >>=20 >> The IETF Secretariat >>=20 >=20 > _______________________________________________ > Aeon mailing list > Aeon@ietf.org > https://www.ietf.org/mailman/listinfo/aeon >=20 > _______________________________________________ > Aeon mailing list > Aeon@ietf.org > https://www.ietf.org/mailman/listinfo/aeon From nobody Thu May 29 03:25:09 2014 Return-Path: X-Original-To: aeon@ietfa.amsl.com Delivered-To: aeon@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFCB81A08BF for ; Thu, 29 May 2014 03:25:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.852 X-Spam-Level: X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w3yq6Wv-4ujz for ; Thu, 29 May 2014 03:25:06 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BE061A08C1 for ; Thu, 29 May 2014 03:25:06 -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.7-GA FastPath queued) with ESMTP id BHK06867; Thu, 29 May 2014 10:25:01 +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.3.158.1; Thu, 29 May 2014 11:24:12 +0100 Received: from NKGEML410-HUB.china.huawei.com (10.98.56.41) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 29 May 2014 11:24:42 +0100 Received: from NKGEML512-MBX.china.huawei.com ([169.254.7.68]) by nkgeml410-hub.china.huawei.com ([10.98.56.41]) with mapi id 14.03.0158.001; Thu, 29 May 2014 18:24:39 +0800 From: Sheng Jiang To: "aeon@ietf.org" Thread-Topic: New Version Notification for draft-conet-aeon-gap-analysis-00.txt Thread-Index: AQHPeyEAGcIR0cP/c0SHOur0GedzQ5tXVxUw Date: Thu, 29 May 2014 10:24:39 +0000 Message-ID: <5D36713D8A4E7348A7E10DF7437A4B923AE85A1C@nkgeml512-mbx.china.huawei.com> Accept-Language: en-GB, zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.111.98.145] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/xpV2UkPFf2jF4L4tpZQQqKxz-x8 Subject: [Aeon] FW: New Version Notification for draft-conet-aeon-gap-analysis-00.txt X-BeenThere: aeon@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Enabled Open Networking \(AEON\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 10:25:08 -0000 SGksIGFsbCwNCg0KV2UgaGF2ZSByZXdyaXR0ZW4gdGhlIGdhcCBhbmFseXNpcyB3aXRoIHRoZSB3 aWRlciBzY29wZSwgaW5jbHVkaW5nIGJvdGggQ09ORVQgYW5kIEFFT04uIEh1aSBEZW5nLCBGYXJv b3EgQmFyaSBhbmQgU3VyZXNoIEtyaXNobmFuIGhhdmUgYWxzbyBqb2luZWQgd2l0aCBjb25jcmV0 ZWQgY29udHJpYnV0aW9ucy4NCg0KQmVzdCByZWdhcmRzLA0KDQpTaGVuZw0KDQo+LS0tLS1Pcmln aW5hbCBNZXNzYWdlLS0tLS0NCj5Gcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0 bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQo+U2VudDogVGh1cnNkYXksIE1heSAyOSwgMjAx NCA1OjMzIFBNDQo+VG86IEZhcm9vcSBCYXJpOyBTaGVuZyBKaWFuZzsgSHVpIERlbmc7IFN1cmVz aCBLcmlzaG5hbjsgRmFyb29xIEJhcmk7IFJvbmcNCj5aaGFuZzsgU3VyZXNoIEtyaXNobmFuOyBS b25nIFpoYW5nOyBTaGVuZyBKaWFuZzsgSHVpIERlbmcNCj5TdWJqZWN0OiBOZXcgVmVyc2lvbiBO b3RpZmljYXRpb24gZm9yIGRyYWZ0LWNvbmV0LWFlb24tZ2FwLWFuYWx5c2lzLTAwLnR4dA0KPg0K Pg0KPkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1jb25ldC1hZW9uLWdhcC1hbmFseXNpcy0w MC50eHQNCj5oYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFNoZW5nIEppYW5nIGFu ZCBwb3N0ZWQgdG8gdGhlDQo+SUVURiByZXBvc2l0b3J5Lg0KPg0KPk5hbWU6CQlkcmFmdC1jb25l dC1hZW9uLWdhcC1hbmFseXNpcw0KPlJldmlzaW9uOgkwMA0KPlRpdGxlOgkJQXBwbGljYXRpb24g RW5hYmxlZCBDT2xsYWJvcmF0aXZlIE5FVHdvcmtpbmcgR2FwIEFuYWx5c2lzDQo+RG9jdW1lbnQg ZGF0ZToJMjAxNC0wNS0yOQ0KPkdyb3VwOgkJSW5kaXZpZHVhbCBTdWJtaXNzaW9uDQo+UGFnZXM6 CQkxNQ0KPlVSTDoNCj5odHRwOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1j b25ldC1hZW9uLWdhcC1hbmFseXNpcy0wMC50eHQNCj5TdGF0dXM6DQo+aHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtY29uZXQtYWVvbi1nYXAtYW5hbHlzaXMvDQo+SHRtbGl6 ZWQ6DQo+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtY29uZXQtYWVvbi1nYXAtYW5h bHlzaXMtMDANCj4NCj4NCj5BYnN0cmFjdDoNCj4gICBJZGVudGlmaWNhdGlvbiBhbmQgdHJlYXRt ZW50IG9mIGFwcGxpY2F0aW9uIGZsb3dzIGhhdmUgYmVjb21lIG1vcmUNCj4gICBhbmQgbW9yZSBp bXBvcnRhbnQgZm9yIG5ldHdvcmsgb3BlcmF0b3JzLiAgSW4gb3JkZXIgdG8gZWZmaWNpZW50bHkN Cj4gICBkaXN0aW5ndWlzaCBJQ1BzJyB0cmFmZmljLCBjb29yZGluYXRpb24gYmV0d2VlbiBJU1Bz IGFuZCBJQ1BzIGlzDQo+ICAgcmVxdWlyZWQuICBJUCBmbG93IGlkZW50aWZpY2F0aW9uIGNhbiBi ZSBiYXNlZCBvbiBJQ1BzJyB0cmFmZmljDQo+ICAgY2Fycnlpbmcgc29tZSBtdXR1YWxseSBhZ3Jl ZWQgaWRlbnRpZmllcnMuICBUaGlzIGRvY3VtZW50IGFuYWx5emVzDQo+ICAgdGhlIHRlY2huaWNh bCBnYXAgYmV0d2VlbiB0aGUgY3VycmVudCBuZXR3b3JrIGZ1bmN0aW9ucyBhbmQgcmVxdWlyZWQN Cj4gICBuZXR3b3JrIGNhcGFiaWxpdHkgdG8gZW5hYmxlIHN1Y2ggZnVuY3Rpb25hbGl0eS4NCj4N Cj4NCj4NCj4NCj5QbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0 ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uDQo+dW50aWwgdGhlIGh0bWxpemVkIHZlcnNp b24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4NCj5UaGUgSUVU RiBTZWNyZXRhcmlhdA0KDQo= From nobody Thu May 29 04:02:03 2014 Return-Path: X-Original-To: aeon@ietfa.amsl.com Delivered-To: aeon@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 752EC1A08B2 for ; Thu, 29 May 2014 04:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.329 X-Spam-Level: X-Spam-Status: No, score=-0.329 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RELAY_IS_221=2.222, RP_MATCHES_RCVD=-0.651] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rTud7qr7aPM for ; Thu, 29 May 2014 04:01:56 -0700 (PDT) Received: from cmccmta.chinamobile.com (cmccmta.chinamobile.com [221.176.64.232]) by ietfa.amsl.com (Postfix) with SMTP id B69EF1A088D for ; Thu, 29 May 2014 04:01:55 -0700 (PDT) Received: from spf.mail.chinamobile.com (unknown[172.16.20.11]) by rmmx-oa_allagent01-12001 (RichMail) with SMTP id 2ee15387137a7b7-f47b7; Thu, 29 May 2014 19:01:14 +0800 (CST) X-RM-TRANSID: 2ee15387137a7b7-f47b7 Received: from adminPC (unknown[10.2.52.194]) by rmsmtp-oa_rmapp01-12001 (RichMail) with SMTP id 2ee153871379fac-b3a4b; Thu, 29 May 2014 19:01:14 +0800 (CST) X-RM-TRANSID: 2ee153871379fac-b3a4b From: "Fan, Peng" To: References: <20140529102929.21679.69336.idtracker@ietfa.amsl.com> In-Reply-To: <20140529102929.21679.69336.idtracker@ietfa.amsl.com> Date: Thu, 29 May 2014 19:01:32 +0800 Message-ID: <008f01cf7b2d$59f6b940$0de42bc0$@chinamobile.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQI3qxCrkPVsi0VLxa0HRqttzhhdc5qHAltA Content-Language: zh-cn Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/YZoopo5yEpz6eBW_wms5mZsHs5Q Subject: [Aeon] FW: New Version Notification for draft-conet-aeon-use-cases-00.txt X-BeenThere: aeon@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: "Application Enabled Open Networking \(AEON\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 May 2014 11:02:01 -0000 Hi all, The following is a merged work of AEON and CONET use cases with updates = reflecting reviews and comments. Please review it and share your = valuable comments. Best regards, Peng -----Original Message----- From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org]=20 Sent: Thursday, May 29, 2014 6:29 PM To: Peng Fan; Charles Eckel; Tirumaleswar Reddy; Charles Eckel; Peng = Fan; Wesley George; Tirumaleswar Reddy; Wesley George Subject: New Version Notification for draft-conet-aeon-use-cases-00.txt A new version of I-D, draft-conet-aeon-use-cases-00.txt has been = successfully submitted by Peng Fan and posted to the IETF repository. Name: draft-conet-aeon-use-cases Revision: 00 Title: Application Enabled Collaborative Networking Use Cases Document date: 2014-05-29 Group: Individual Submission Pages: 19 URL: = http://www.ietf.org/internet-drafts/draft-conet-aeon-use-cases-00.txt Status: = https://datatracker.ietf.org/doc/draft-conet-aeon-use-cases/ Htmlized: http://tools.ietf.org/html/draft-conet-aeon-use-cases-00 Abstract: This document describes application enabled collaborative networking use cases. Application enabled collaborative networking has applications explicitly signal their flow characteristics to the network. This provides network nodes with visibility of the application flow characteristics, which enables them to apply the correct flow treatment and provide feedback to applications. = =20 Please note that it may take a couple of minutes from the time of = submission until the htmlized version and diff are available at = tools.ietf.org. The IETF Secretariat