Re: [Int-area] FW: New Version Notification for draft-eckert-intarea-flow-metadata-framework-01.txt

[<[e-mail]>]

Dear Charles, all,

The idea of an application sending flow characterization messages to the network is interesting. This is an idea which is worth to be discussed and challenged. Thank you for writing this document.

The proposed framework makes sense in some contexts but I'm afraid it does not solve the limitations you listed in the document (e.g., avoid some classification functions in the network). The framework as it is won't simplify the network side since in addition to legacy tools, a new function to intercept the flow characterization messages will be needed. The benefit of the approach depends on the willing of application developers to signal the flow characteristic to the network. 

IMHO, it would be useful if the document elaborates on deployment aspects and what are the facilitators to ease adoption of such approach. For example, why an application relying on HTTPS would sent a non-encrypted flow characterization message for analytic purposes? What is the role of a CPE in such model? How to trust the data sent by an application? These are examples of points which should be further discussed in the document. 

If the purpose of the document is not to claim the limitations you identified will be mitigated but instead this framework is an additional tool at disposal for implementers/operators/etc to ease service ordering and delivery, then a note should be added to the draft. This will be helpful to avoid any confusion.

Personally, I'm not a fun of solutions which requires explicit resource invocation before making use of a subscribed service. This mode should not be generalized (it does make sense if a very few services rely on that mode). I understand there are deployment cases which would rely on such mode but this should be discussed in the document too. 

I didn't understood well why the encoding is discussed in this document. The focus should be on the information model not data models (which are protocol-specific).

Cheers,
Med

>-----Message d'origine-----
>De : [e-mail] [mailto:[e-mail]] De la
>part de Charles Eckel (eckelcu)
>Envoyé : lundi 15 juillet 2013 23:07
>À : [e-mail]
>Objet : [Int-area] FW: New Version Notification for draft-eckert-intarea-
>flow-metadata-framework-01.txt
>
>We have submitted and would appreciate comments on the following draft. It
>provides a framework for applications and network devices to communicate
>characteristics and service attributes for traffic flow. One aspect we
>anticipate to be of particular interest to this audience is the use of
>IPFIX in the information model we defined.
>
>Cheers,
>Charles
>
>-----Original Message-----
>From: [e-mail] [mailto:[e-mail]]
>Sent: Monday, July 15, 2013 1:41 PM
>To: Toerless Eckert (eckert); Amine Choukir (amchouki); Reinaldo Penno
>(repenno); Charles Eckel (eckelcu)
>Subject: New Version Notification for draft-eckert-intarea-flow-metadata-
>framework-01.txt
>
>
>A new version of I-D, draft-eckert-intarea-flow-metadata-framework-01.txt
>has been successfully submitted by Toerless Eckert and posted to the
>IETF repository.
>
>Filename:	 draft-eckert-intarea-flow-metadata-framework
>Revision:	 01
>Title:		 A Framework for Signaling Flow Characteristics between
>Applications and the Network
>Creation date:	 2013-07-15
>Group:		 Individual Submission
>Number of pages: 17
>URL:             http://www.ietf.org/internet-drafts/draft-eckert-intarea-
>flow-metadata-framework-01.txt
>Status:          http://datatracker.ietf.org/doc/draft-eckert-intarea-flow-
>metadata-framework
>Htmlized:        http://tools.ietf.org/html/draft-eckert-intarea-flow-
>metadata-framework-01
>Diff:            http://www.ietf.org/rfcdiff?url2=draft-eckert-intarea-
>flow-metadata-framework-01
>
>Abstract:
>   This document provides a framework for communicating information
>   elements (a.k.a. metadata) in a consistent manner between
>   applications and the network to provide better visibility of
>   application flows, thereby enabling differentiated treatment of those
>   flows.  These information elements can be conveyed using various
>   signaling protocols, including PCP, RSVP, and STUN.
>
>
>
>
>The IETF Secretariat
>
>_______________________________________________
>Int-area mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/int-area