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

["Charles Eckel (eckelcu)" <[e-mail]>]

Hi Med,

Thank you for your review and corresponding comments. Please see inline.

> -----Original Message-----
> From: [e-mail]
> [mailto:[e-mail]]
> Sent: Thursday, July 18, 2013 5:11 AM
> To: Reinaldo Penno (repenno); Charles Eckel (eckelcu); [e-mail]
> Subject: RE: [Int-area] FW: New Version Notification for draft-eckert-intarea-
> flow-metadata-framework-01.txt
> 
> Hi Reinaldo,
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> >-----Message d'origine-----
> >De : Reinaldo Penno (repenno) [mailto:[e-mail]]
> >Envoyé : jeudi 18 juillet 2013 12:41
> >À : BOUCADAIR Mohamed OLNC/OLN; Charles Eckel (eckelcu); int-
> [e-mail]
> >Objet : Re: [Int-area] FW: New Version Notification for draft-eckert-
> >intarea-flow-metadata-framework-01.txt
> >
> >Hi Med,
> >
> >Thanks for your review. Inline with [RP]
> >
> >On 7/18/13 6:13 AM, "[e-mail]"
> ><[e-mail]> 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.
> >
> >[RP] Interception is only needed with some transports. We should certainly
> >highlight that.
> >
> >>The benefit of the approach depends on the willing of application
> >>developers to signal the flow characteristic to the network.
> >
> >
> >[RP] Yes. I believe this is somewhat a chicken and egg thing. Because such
> >functionality was never truly available in the network, there was no
> >incentive to applications developers.
> [Med] Makes sense. This is why I see this approach as a new tool in addition
> to existing ones rather than presenting it will remove immediately some of the
> limitations of current designs. This can be highlighted in the document.

[cue] Good point. We do not expect or require all applications and network elements to start using this mechanism in order for it provide value. As you suggest, this is one more tool in the toolset, and it may be used in combination with other existing tools. We can certainly add text to clarify this.
 
> 
> >
> >>
> >>
> >>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?
> >
> >
> >[RP] I believe the end-point making the request for flow characteristics
> >will be the CPE in many cases where the applications is not metadata
> >aware. In other words, the CPE makes the request on behalf of applications.
> [Med] I'm more interested in this CPE flavor (managed CPE) since it avoids
> relying on applications to benefit from the added value of this approach. This
> is worth be discussed in the document too.

[cue] Agreed. This is what we describe as "Proxy originated information" in section 3.1.4.1 (http://tools.ietf.org/html/draft-eckert-intarea-flow-metadata-framework-01#section-3.1.4.1). Does this address your concern?


> >
> >>How to trust the data sent by an application? These are examples of
> >>points which should be further discussed in the document.
> >
> >
> >[RP] I think this depends on the transport. Some transports like PCP or
> >STUN have some built-in authentication.
> [Med] The question is not whether a secure transport is used or not but to
> what extent the flow description is accurate (e.g., send fake flow description,
> systematically request treatment with higher priority, etc.).

[cue] Section 3.1.4.2 (http://tools.ietf.org/html/draft-eckert-intarea-flow-metadata-framework-01#section-3.1.4.2) touches on the authentication requirement, but we need to address authorization as well.   Applications may not be authorized to request network resources, but instead authorization has to first be obtained from a network element such as a call controller or policy element. We will add a discussion of this. As Reinaldo pointed out, the transport may provide some mechanisms, but we plan to have mechanisms provided within transport independent encoding as well (for additional details see http://tools.ietf.org/html/draft-choukir-tsvwg-flow-metadata-encoding-01#section-2.2.8).

Cheers,
Charles


> >>
> >>
> >>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.
> >
> >
> >[RP] Me neither. I was hoping the draft did not come as that. The idea
> >here is that any metadata could be send before or after connection is
> >established and reservation is not required at all. In other words,
> >applications will work as always have but could request metadata service
> >if they so desire. If request is denied, everything continues to work as
> >is.
> >
> >
> >>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