Subject: [ippm] Update proposal for draf-ietf-ippm-storetraceroutes - adding arbitrary data

From: Antonin Kral <[email-masked]>
Date: Thu, 7 Jun 2007 07:12:15 +0200

Hello,

I am working on one project in CESNET (Czech NREN), this project is part
of PerfSonar project as well. We want to store more information than
only RTT for each hop. These values could contain information like
available bandwidth on particular link, or installed capacity, queue
load etc. These information are not fetched by traceroute itself, but
from other programs which are able to communicate with so called
Measurement Points. Our idea is to use XML schema proposed by you to
stored measured data. Unfortunately there is no way how to add new
attributes without schema modification in current RFC draft.

I would like to propose new attribute, which could contain arbitrary
(application-dependant) data. Support for semantic of particular
attribute will be optional (every application will have own set of
supported attributes and their meaning). My idea is something like
the following XML (not schema):

<AdditionalData>
  <Attribute name="installed_bw" dataType="Unsigned32">
    1000
  </Attribute>
  <Attribute name="available_bw" dataType="Unsigned32">
    900
  </Attribute>
  <Attribute name="queue_length" dataType="Unsigned32">
    12
  </Attribute>
  <Attribute name="ingest_interface_name" dataType="String">
    GigabitEthernet6/0/1
  </Attribute>
</AdditionalData>

<AdditionalData> attribute should be optional in measurement description
(complex type _Metadata) as well as measurement results (complex type
_Measurement).

If you like the proposed way, I will be happy to prepare relevant XML
schema for this.

Thank you, best regards,

    Antonin Kral

_______________________________________________
ippm mailing list
[email-masked] 
https://www1.ietf.org/mailman/listinfo/ippm

---

From: "Saverio Niccolini" <[email-masked]>
Date: Thu, 7 Jun 2007 20:41:36 +0200

Dear Antonin,

Thanks for this additional input, actually my only concern is:

you say you gather this additional data not using traceroute measurements, our draft actually focuses on traceroute measurements, then we (inside the IPPM group) need to decide if we want to broaden the scope of the draft of not.

If there is consensus on the fact that the scope can be broadened then we can discuss how to extend the schema and the draft.

Cheers,
Saverio

> -----Original Message-----
> From: Antonin Kral [mailto:[email-masked]]
> Sent: Thursday, June 07, 2007 7:12 AM
> To: [email-masked]
> Subject: [ippm] Update proposal for draf-ietf-ippm-storetraceroutes -
> addingarbitrary data
> 
> Hello,
>

---

From: Antonin Kral <[email-masked]>
Date: Thu, 7 Jun 2007 20:55:20 +0200

Dear Saverio,

* Saverio Niccolini <[email-masked]> [2007-06-07 20:45] wrote:
> you say you gather this additional data not using traceroute
> measurements, our draft actually focuses on traceroute measurements,
> then we (inside the IPPM group) need to decide if we want to broaden
> the scope of the draft of not.

Let me to clarify this a bit. Traceroute command is not directly used
for obtaining these information but measurement is tightly connected
with traceroute itself. We want to provide framework to support PERT
activities.

Measurement workflow:

  * goal is to figure out we could be located some network performance
    problem. We know destination IP address

  - issue 'traceroute to dstip', output is stored in proposed XML
  - output from the first stage is take by another program which will
    figure out which measurement points (MP) are assigned to particular
    hops along the path. Again information is stored in the XML (whit
    the extension data field proposed by us).
  - other application takes this output, which contains:
      - list of all hops along the path
      - list of particular MP for each hop

    This application issues predefined sets of available measurements,
    like check for available bandwidth or router interface queue state.
    Output of these tests/measurements are again stored in extended
    version of traceroutestore XML.

Finally we will end up with XML file which will not hold only list of
hops and information like RTT, but more hop-oriented/related metrics
like interface load. We believe that this could really help people to
figure out, where the problem is.

    Best regards,

        Antonin

---

From: Henk Uijterwaal <[email-masked]>
Date: Fri, 08 Jun 2007 15:58:37 +0200

Dear All,

(Personal opinion, not necessarily the opinion of the WG chairs)

> If there is consensus on the fact that the scope can be broadened then we can
> discuss how to extend the schema and the draft.

This seems something that I missed earlier this week.  I was under the
impression that Antonin's extensions filled the XML with information
obtained from traceroute.  After Saverio's comments, I realize that
this information from other sources and thus turns the draft more
into a schema for storing path information.

That is not the scope of this draft.  This draft is to store data
from traceroutes (most likely done to support other metrics).  I
don't particularly like the idea of changing the scope of a draft
that is almost finished.  I'd rather see this draft finished as
it is.  If there is a need for a more generic standard to store
path info, then we need a new draft.  (Which can include the
traceroute stuff).

Other opinions are welcome,

Henk

-- 
------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre          http://www.amsterdamned.org/~henk
P.O.Box 10096          Singel 258         Phone: +31.20.5354414
1001 EB Amsterdam      1016 AB Amsterdam  Fax: +31.20.5354445
The Netherlands        The Netherlands    Mobile: +31.6.55861746
------------------------------------------------------------------------------

# Lawyer: "Now sir, I'm sure you are an intelligent and honest man--"
# Witness: "Thank you. If I weren't under oath, I'd return the compliment."

---

From: "Saverio Niccolini" <[email-masked]>
Date: Tue, 12 Jun 2007 20:06:44 +0200

Dear Henk,

Thanks for your comments, if IPPM group wants and the CESNET folks agree we can start discussion (off-list) on a separate draft that will complement the traceroute one.

In the meantime we will finalize the draft on traceroute reviewing it under the light of the last comments received.

Cheers,
Saverio

> From: Henk Uijterwaal [mailto:[email-masked]]
> Sent: Friday, June 08, 2007 3:59 PM
> To: Saverio Niccolini
> Cc: [email-masked]
> Subject: Re: [ippm] Update proposal for draf-ietf-ippm-storetraceroutes -
> addingarbitrary data
> 
> Dear All,
>

---

From: Henk Uijterwaal <[email-masked]>
Date: Mon, 18 Jun 2007 10:46:05 +0200

All,

> Thanks for your comments, if IPPM group wants and the CESNET folks agree we
can start discussion (off-list) on a separate draft that will complement the
traceroute one.
> In the meantime we will finalize the draft on traceroute reviewing it under
the light of the last comments received.

Since there don't seem to be any other opinions, I suggest that this is what
we'll do.

Henk

---

From: Antonin Kral <[email-masked]>
Date: Mon, 18 Jun 2007 16:43:58 +0200

Hi,

> Since there don't seem to be any other opinions, I suggest that this is what

Fine, we have moved a bit since last proposal to more polished version.
Could you give me the email address of the right mailing list or set of
emails to send the proposal to move off this mailing list?

Thanks,

  Antonin

---

From: Henk Uijterwaal <[email-masked]>
Date: Mon, 18 Jun 2007 20:18:11 +0200

Hi Antonin,

> emails to send the proposal to move off this mailing list?

I think you've misunderstood me.  I have no problem with people discussing
extensions to the traceroute draft on the ippm list.  In fact, it is the
most appropriate list for this.

However, we do have the current traceroute document that was initially
proposed as a solution to an existing problem that could be published
quickly.  In practice, it has take a long time to complete, meaning that
the folks who asked for this, still don't have their standard.  If we
add another feature (however useful it is), this will only delay things
even further.  That is something I don't like.

So, my suggestion was to finish the traceroute draft as it is.  It has
already gone through last call and it is almost ready.  Once that is
published, we can start thinking about follow-up work that includes your
extensions.

Henk