Hi, Rich, all, On Jun 13, 2012, at 2:21 PM, Richard Alimi wrote:
> On Tue, May 15, 2012 at 10:10 AM, Brian Trammell > <[email protected]> wrote: >> Hi, Rich, all, >> >> The additions you're talking about seem on a first pass like they'd fit in >> the IPFIX information model. With respect to the definition of description >> of an Information Element, the emphasis on "flow" is really a historical >> thing. Basically, description should be specified to be human-readable and >> detailed enough that a reasonably expert person would know how to generate >> and/or interpret it. We'll remove references to flow from the definition of >> description in RFC 5102-bis. >> > > The text regarding it being information being available to the > observer would be too limiting for the ALTO case too. Hm... how can a device export information about something it can't observe / doesn't know? > If both of those requirements were removed, what are the guidelines on > new information elements that would be accepted into the information > element registry? http://tools.ietf.org/html/draft-ietf-ipfix-ie-doctors-03 mostly covers this, though it handles the case of applying the entire IPFIX protocol (see section 3) as opposed to just using the information model for a new application/protocol. Section 4 contains detailed guidelines for defining new Information Elements (summarized in Section 7 in checklist form), though again this is geared toward IEs for usage with the IPFIX protocol. >> There's a more subtle issue with potentially applying the IPFIX information >> model to ALTO: the possible need to specify an alternate encoding for IPFIX >> IEs represented in ALTO. Briefly: each IPFIX Information Element has a type >> (these cover address and time types as well as the basic primitives, >> strings, and raw octet arrays), and these specify encodings appropriate for >> using these types in IPFIX, as well: integers in big-endian binary, times as >> big-endian binary integers since the epoch or in NTP (era 0) format, and so >> on. As ALTO is JSON-based, these representations are somewhat less than >> appropriate. >> >> Indeed, this could probably be addressed with a single specification of >> representations of IPFIX data types in ALTO (or indeed, for textual >> protocols in general). This would probably not have any surprises (v4 >> addresses in dotted-quad, v6 addresses as per RFC 4291, timestamps as per >> RFC 3339, and so on); it would just need to be written. >> > > Thank you very much for the proposal for using this registry in ALTO. > My personal opinion is that using IPFIX information element registry > doesn't seem to be a great match to replace ALTO's endpoint property > registry. The win doesn't seem to be that great to me, and it also > requires writing a new spec to map the datatypes. Indeed; do let me know if I can be of any further assistance. For what it's worth, I suspect we'll define text-friendly representations for the IPFIX datatypes sooner or later anyway. Cheers, Brian > If others in the ALTO WG feel differently, then please speak up. > > Thanks, > Rich > >> Best regards, >> >> Brian >> >> On May 14, 2012, at 12:36 PM, Richard Alimi wrote: >> >>> On Mon, May 14, 2012 at 6:34 AM, Benoit Claise <[email protected]> wrote: >>>> Hi Richard, >>>> >>>> On Thu, May 10, 2012 at 10:37 AM, Benoit Claise <[email protected]> wrote: >>>> >>>> Dear all, >>>> >>>> I've been reviewing draft-ietf-alto-reqs-14 and the following requirement >>>> got me thinking: >>>> >>>> REQ. ARv14-5: An ALTO client protocol MUST be extensible to enable >>>> support of other host group descriptor types in future. An ALTO >>>> client protocol specification MUST define an appropriate procedure >>>> for adding new host group descriptor types, e.g., by establishing an >>>> IANA registry. >>>> >>>> Why don't you reuse an existing registry, in which you will have all the >>>> Information Elements already defined instead of defining a new one? >>>> WhatI have in mind: the IPFIX I.E. IANA registry. >>>> The piece of information I see in draft-ietf-alto-reqs-14 are IP address, >>>> prefix, BGP AS: they're in IANA. >>>> And many other IEs are already present, for future ALTO extensions, if >>>> required. >>>> >>>> This would not only save one registry (ALTO Endpoint Property in >>>> draft-ietf-alto-protocol-10), but offers a bigger advantage. >>>> Let me explain.... When you will control your applications with ALTO, you >>>> will anyway want to apply a flow measurement to monitor your changes, and >>>> to >>>> serve as a feedback loop for more optimizations. >>>> And the chances are high that you will using a NetFlow/IPFIX based >>>> mechanism. Both NetFlow and IPFIX use the IPFIX I.E. IANA registry. >>>> >>>> Therefore, it would make sense to have consistent data models between ALTO >>>> and IPFIX, and avoid a data model proxy if we want to compare the data. >>>> Proposal: reuse the ElementIDs found in the IPFIX I.E. IANA registry >>>> somewhere in your protocol. >>>> >>>> The suggested use case is in place of the Endpoint Property registry? >>>> >>>> I'm referring to the examples in >>>> http://tools.ietf.org/html/draft-ietf-alto-protocol-11#section-7.5.3 >>>> So I guess it's >>>> http://tools.ietf.org/html/draft-ietf-alto-protocol-11#section-10.3. >>>> However, >>>> http://tools.ietf.org/html/draft-ietf-alto-protocol-11#section-10.3 >>>> doesn't contain the initial series of values. >>> >>> Those are two different things in the protocol. The former is for >>> identifying endpoints themselves, the latter is for properties >>> associated with those endpoints. >>> >>>> >>>> >>>> Just to be sure I understand what would happen if we went that route, >>>> what are the restrictions for adding new information elements? >>>> Specifically, what kinds of elements are allowed or disallowed? >>>> >>>> Things that have been informally discussed in the ALTO WG so far have >>>> been things like load information and available network capacity. Do >>>> those fit within the ipfix model? >>>> >>>> The IANA considerations for new IPFIX IEs is in RFC5102, >>>> http://tools.ietf.org/html/rfc5102#section-7.1. >>>> It mentions: IANA through Expert Review [RFC2434] >>>> The most up to date document regarding IE allocation is >>>> http://tools.ietf.org/html/draft-ietf-ipfix-ie-doctors-02. >>>> I don't believe there are any limitations on for new IEs such as load >>>> information and available network capacity. >>>> Copying the IPFIX chairs and Brian Trammell. >>> >>> I think the main consideration here is whether IPFIX really is the >>> canonical source (and is planned to be in the future) for data >>> that an application (note: not only network operator) would want to >>> know about an endpoint. In particular, in the CDN use cases, an ALTO >>> map may be provided by a CDN to advertise costs to/from and properties >>> of various cache nodes. >>> >>>> From RFC5102, Section 2.1 I see that a registration seems to enforce >>> that the Information Element is derived from a flow or someone >>> observing the flow on the network: >>> >>> description - The semantics of this Information Element. Describes >>> how this Information Element is derived from the Flow or other >>> information available to the observer. >>> >>> To me, that seems too restrictive for the ALTO model which is >>> providing information to the application layer. >>> >>> Thanks, >>> Rich >>> >>>> >>>> Regards, Benoit. >>>> >>>> >>>> Thanks, >>>> Rich >>>> >>>> Disclaimer: I have not read the protocol details >>>> >>>> Regards, Benoit. >>>> >>>> >>>> _______________________________________________ >>>> alto mailing list >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/alto >>>> >>>> >>>> >> _______________________________________________ alto mailing list [email protected] https://www.ietf.org/mailman/listinfo/alto
