Re: [Aeon] Comments and next step proposal

Hui Deng <denghui02@gmail.com> Wed, 23 April 2014 14:42 UTC

Return-Path: <denghui02@gmail.com>
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 6F4631A03D6 for <aeon@ietfa.amsl.com>; Wed, 23 Apr 2014 07:42:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.749
X-Spam-Level:
X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ypjeCPWMq2U for <aeon@ietfa.amsl.com>; Wed, 23 Apr 2014 07:42:37 -0700 (PDT)
Received: from mail-ve0-x22a.google.com (mail-ve0-x22a.google.com [IPv6:2607:f8b0:400c:c01::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 0357E1A03C0 for <aeon@ietf.org>; Wed, 23 Apr 2014 07:42:36 -0700 (PDT)
Received: by mail-ve0-f170.google.com with SMTP id pa12so1276344veb.1 for <aeon@ietf.org>; Wed, 23 Apr 2014 07:42:31 -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=7eIcx69H6J8A/UryofRzvKGTm3wJwnM0GATf/roscNI=; b=kTV1JEEHoh8bY9vlw+9lk9/VzbW4juX1XRVo4cAyb2zzv/Fqzp1UEBsKCIZL7K3Y4r A83Pj/E/67NK3Jy2rE5ksBfhZ8CBpu8FL5ZeAJHTJIFgqt2Fa+tnXDeqhqUW1T7W9Ekb hzKP8zIh+bHcK/3Rs/uvUK1Ba3ARKbFRWxpX6se+hFjjIGiOWmDq8EO5CieI9KLrWEdl mFZ3cakmcdpS26YqgVpkDA9+6epk/B9DvyuW8wEY2ZlFqrLzDz+p/fBhcGJh+A6UoMHf zDuUQYIeP2yK3bmiZIxojNEGP72uhNpHtGUFuaNLZeg1clJJXhonTCyXSSrDOp/Z1fgE clsg==
MIME-Version: 1.0
X-Received: by 10.52.165.235 with SMTP id zb11mr277918vdb.82.1398264151073; Wed, 23 Apr 2014 07:42:31 -0700 (PDT)
Received: by 10.220.252.132 with HTTP; Wed, 23 Apr 2014 07:42:31 -0700 (PDT)
In-Reply-To: <CABYVfykV1KfgE2_9F+wtO-=Qqqkqi+9tNwc-J0LanZ8-x6mpNg@mail.gmail.com>
References: <CABYVfykV1KfgE2_9F+wtO-=Qqqkqi+9tNwc-J0LanZ8-x6mpNg@mail.gmail.com>
Date: Wed, 23 Apr 2014 22:42:31 +0800
Message-ID: <CANF0JMBdUJFm6FDoa4K5++xuhHNvVS-6wn81jFxVCz_vKmDwcw@mail.gmail.com>
From: Hui Deng <denghui02@gmail.com>
To: Rong Zhang <rzhang.ietf@gmail.com>
Content-Type: multipart/alternative; boundary="001a11c28c7006e9d004f7b6be8c"
Archived-At: http://mailarchive.ietf.org/arch/msg/aeon/5eZUCmqzWMBE_HGhQBh2_gMJfX4
Cc: "aeon@ietf.org" <aeon@ietf.org>, "BARI, FAROOQ (ATTSI)" <fb5431@att.com>, "Fan, Peng" <fanpeng@chinamobile.com>, Sheng Jiang <jiangsheng@huawei.com>
Subject: Re: [Aeon] Comments and next step proposal
X-BeenThere: aeon@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Application Enabled Open Networking \(AEON\)" <aeon.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/aeon>, <mailto:aeon-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/aeon/>
List-Post: <mailto:aeon@ietf.org>
List-Help: <mailto:aeon-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/aeon>, <mailto:aeon-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Apr 2014 14:42:39 -0000

Hi Rong,

Thanks for your feedback, I guess that you raised one of key point that
3GPP may also consider today about interaction between operators and OTT, I
guess that today Rx interface are still diameter based, they may consider
other high layer protocols as well in the future. but in that case, I think
that they are more focusing on server side negotiation without involvement
client information, for example, client is sitting behind of NAT. and some
other granularity information.

I am cc to Farooq who is quite expert in this field.

Best regards,

-Hui



2014-04-23 16:11 GMT+08:00 Rong Zhang <rzhang.ietf@gmail.com>:

> Hi all,
>
> Speaking as the operator, I do see this trend that OTT are working with
> operators today which will help to improve the mobile internet user
> experience dramatically.
>
> I have one basic comment that current documents have n't talked about 3GPP
> PCRF Rx interface which will allow OTT to work with today's mobile
> operator, I will work with Sheng to write the gap analysis document by
> including how IETF work could be a complimentary to 3GPP's specificaiton.
>
> I am planning to attend next IETF meeting, and hope BoF will happen, I
> personally feel it is more Intarea scope than transport.
>
> Cheers.
>
> -Rong ZHANG
>
>
> On Wed, Apr 23, 2014 at 11:31 AM, Sheng Jiang <jiangsheng@huawei.com>wrote:
>
>>  Hi, all,
>>
>>
>>
>> This is a real requirement from network operation perspective. Both ISPs
>> and ICPs can benefit from this advance collaborative network model.
>>
>>
>>
>> Rong Zhang and I are working on an gap analysis document, which we hope
>> to share publically early next week.
>>
>>
>>
>> Best regards,
>>
>>
>>
>> Sheng
>>
>>
>>
>> *From:* Aeon [mailto:aeon-bounces@ietf.org] *On Behalf Of *Fan, Peng
>> *Sent:* Tuesday, April 22, 2014 7:48 PM
>>
>> *To:* aeon@ietf.org
>> *Subject:* [Aeon] Comments and next step proposal
>>
>>
>>
>> Hello all,
>>
>>
>>
>> Based on our operational experience, we have submitted a draft:
>> http://datatracker.ietf.org/doc/draft-fan-intarea-conet-ps-uc/
>>
>> The purposes of this draft are to encourage less DPI in the network and
>> propose more cooperation between OTT and Operators. Please kindly help to
>> review the draft and comment here.
>>
>>
>>
>> I have also reviewed the draft:
>>
>> http://datatracker.ietf.org/doc/draft-eckel-aeon-problem-statement/,
>>
>> My comments are:
>>
>> 1)      Shall we consider to split the section 4 into an independent gap
>> analysis document?
>>
>> 2)      For the requirements section, we agree Req. 1, 2, and 7, and
>> just want to clarify:
>>
>> a)       Req. 3 and 4, do you expect the interaction between network
>> node and host here before the real traffic start?
>>
>> b)       Req. 5 and 8 are not quite clear to us.
>>
>> c)        I guess that it not always mandatory to apply Diffserv here,
>> it could be optional?
>>
>> 3)      If you read our draft, we have more experience about the
>> limitation of current DPI/DFI in section 3.
>>
>> 4)      Analysis of other existing solutions like ACL configuration can
>> also be added in section 3.
>>
>>
>>
>> Also for the draft:
>>
>> http://datatracker.ietf.org/doc/draft-eckel-aeon-use-cases/
>>
>> Here I feel that too many use cases are listed here. You may consider
>> narrowing down to a few use cases for which we have strong and specific
>> needs, in order to get work further progressed.
>>
>>
>>
>> After reading the current work proposed here, we are wondering whether
>> two groups of people could work together to propose a BoF in the coming
>> IETF meeting. To do that, we probably can:
>>
>> 1)      Merge the PS draft into one document.
>>
>> 2)      Write an independent use case document.
>>
>> 3)      Write an gap analysis document.
>>
>> Once all three documents have finished, we could talk to ADs from both
>> Internet and Transport area about the next step?
>>
>>
>>
>> Thanks a lot for your consideration.
>>
>>
>>
>> Best regards,
>>
>> Peng
>>
>> _______________________________________________
>> 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
>
>