On Wed, Jun 13, 2012 at 5:36 AM, Brian Trammell <[email protected]> wrote: > 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?
ALTO may know information about the endpoint, but not observe data packets to/from it. (I interpreted 'observer' to be the entity that contains an Observation Point as defined in RFC5101.) > >> 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
