Hello MED, Thank you for the comments.
See answer inline. On Jul 18, 2013, at 11:13 AM, <mohamed.boucad...@orange.com<mailto:mohamed.boucad...@orange.com>> wrote: 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. [AC ]We can definitely integrate a first set of use cases that help in understanding the value of flow characterisation to the network and who plays a role in producing those characteristics. I think we should both include SP and enterprise use cases as the question of trust in those two environments are solved in different ways. We did not include a draft on how to secure the flow characteristics as we felt more discussion was needed to get to a solid proposal including the aspect of single, multi-domain and transport specific vs transport independent security. In the framework and the encoding we envisioned being able to signal from both endpoints and/or network elements (potentially more than one). 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. [AC] As Charles mentioned application can opt to use or not metadata and will still work as before if they don't. What the application gain is accuracy and granularity in terms of the characterisation of its flows for differentiated treatment and visibility. 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). [AC] The encoding we discuss is transport independent that it is why it is referenced in the framework. The way we would like to present how flow characterisation works is shown below. The framework as you said defines the information model and the use cases. The encoding draft defines how to encode in a transport independent way tags signalled by applications and/or network elements. The transport specific draft maps the framework and the encoding to the protocol specific logic and messaging. The security draft would be meant to cover transport independent security but this is to be discussed. Hope that clarifies some of your concerns. Cheers Amine +-----------------------------+ +---------------------+ | +----------------------+ | | | | | | | | | | | | | | | | | | | | security +--+ | framework | | | | | | | | | | | | | | | | | | | | +---------------------+ | +----------------------+ | | | | | | +----------------------+ | | | | | | | | | | | | | | | encoding | | | | | | | | | | | +----------------------+ | ++------------+--------------++ +----------------------+ | +----------+-----------+ | +-----------------------+ | | | | | | | | | | | | | | | | | STUN +--+ | PCP | +-+ RSVP | | | | | | | | | | | | | +----------------------+ +----------------------+ +-----------------------+ Cheers, Med -----Message d'origine----- De : int-area-boun...@ietf.org<mailto:int-area-boun...@ietf.org> [mailto:int-area-boun...@ietf.org<mailto:area-boun...@ietf.org>] De la part de Charles Eckel (eckelcu) Envoyé : lundi 15 juillet 2013 23:07 À : int-area@ietf.org<mailto:int-area@ietf.org> 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: internet-dra...@ietf.org<mailto:internet-dra...@ietf.org> [mailto:internet-dra...@ietf.org<mailto:dra...@ietf.org>] 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 Int-area@ietf.org<mailto:Int-area@ietf.org> https://www.ietf.org/mailman/listinfo/int-area _______________________________________________ Int-area mailing list Int-area@ietf.org<mailto:Int-area@ietf.org> https://www.ietf.org/mailman/listinfo/int-area
_______________________________________________ Int-area mailing list Int-area@ietf.org https://www.ietf.org/mailman/listinfo/int-area
