Re: [Aeon] Comments and next step proposal

Hi Charles, Tiru,

Thanks for your kind reply and explanation.

Let's make a next step plan after this thread discussion has concluded.

Best regards,

Peng

From: Charles Eckel (eckelcu) [mailto:eckelcu@cisco.com] 
Sent: Wednesday, April 23, 2014 10:31 PM
To: Tirumaleswar Reddy (tireddy); Fan, Peng; aeon@ietf.org
Subject: Re: [Aeon] Comments and next step proposal

Please see addition comment inline.

From: "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>
Date: Tuesday, April 22, 2014 at 11:08 PM
To: "Fan, Peng" <fanpeng@chinamobile.com>om>, "aeon@ietf.org" <aeon@ietf.org>
Subject: Re: [Aeon] Comments and next step proposal

Hi Peng,

Please see inline [TR]

From: Aeon [mailto:aeon-bounces@ietf.org] On Behalf Of Fan, Peng
Sent: Tuesday, April 22, 2014 5:18 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?

[TR] The interaction between the network node and host could be before or
after the real traffic starts.

The flow descriptions could change over time due to changes in application
operation, and the network feedback could change as well as the network
conditions change.

b)         Req. 5 and 8 are not quite clear to us.

[TR] Req. 8 is saying that the flow characteristics signaled by the client
to the network should have protection against man-in-middle attacker
modifying the flow metadata.

Req 5 is about incremental deployability. Various heuristic based
mechanisms, including DPI, are being used with some success in many
networks. These should continue to work as portions of the applications and
network are enabled with the functionality proposed in AEON.

I guess that it not always mandatory to apply Diffserv here, it could be
optional?

[TR] Yes, Diffserv is optional.  FYI DART WG is recently formed
(https://www.ietf.org/mailman/listinfo/dart) to document the limitations of
Diffserv.

3)       If you read our draft, we have more experience about the limitation
of current DPI/DFI in section 3.

[TR] Yes,
http://tools.ietf.org/html/draft-eckel-aeon-use-cases-01#section-2.4.8 also
discusses similar problem and possible solution to address the problem.

4)       Analysis of other existing solutions like ACL configuration can
also be added in section 3.

Yes, good point.

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.

[TR] Agreed, we are updating the use case draft.

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. 

[TR] Sounds like a good plan to me.

Sounds good to me as well.

Cheers,

Charles

Cheers,

-Tiru

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