Subject: [alto] IPFIX Information Element in the ALTO protocol

From: Benoit Claise <[email-masked]>
Date: Thu, 10 May 2012 19:37:48 +0200

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  <http://www.iana.org/assignments/ipfix/ipfix.xml>.
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 usethe IPFIX I.E. IANA registry  <http://www.iana.org/assignments/ipfix/ipfix.xml>.

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 inthe IPFIX I.E. IANA registry  <http://www.iana.org/assignments/ipfix/ipfix.xml>  somewhere in your protocol.

Disclaimer: I have not read the protocol details

Regards, Benoit.

---

From: Richard Alimi <[email-masked]>
Date: Sun, 13 May 2012 00:38:57 -0700

On Thu, May 10, 2012 at 10:37 AM, Benoit Claise <[email-masked]> wrote:
> WhatI have in mind: the IPFIX I.E. IANA registry.
> 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?

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?

Thanks,
Rich

> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto
>

---

From: Benoit Claise <[email-masked]>
Date: Mon, 14 May 2012 15:34:49 +0200

Hi Richard,
> On Thu, May 10, 2012 at 10:37 AM, Benoit Claise<[email-masked]>  wrote:
>> Dear all,
>>
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 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 
<http://tools.ietf.org/html/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.

Regards, Benoit.

---

From: Richard Alimi <[email-masked]>
Date: Mon, 14 May 2012 12:36:45 -0700

On Mon, May 14, 2012 at 6:34 AM, Benoit Claise <[email-masked]> wrote:
> However, http://tools.ietf.org/html/draft-ietf-alto-protocol-11#section-10.3

Those are two different things in the protocol.  The former is for
identifying endpoints themselves, the latter is for properties
associated with those endpoints.

> It mentions: IANA through Expert Review [RFC2434]

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

---

From: Brian Trammell <[email-masked]>
Date: Tue, 15 May 2012 10:10:01 -0700

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.

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.

Best regards,

Brian