Re: I-D ACTION:draft-ietf-ccamp-tracereq-00.txt

[David Meyer <dmm@sprint.net>]

Ron beat me to it. Thanks Ron.

Dave

On Wed, Sep 04, 2002 at 02:20:08PM -0400, Ron Bonica wrote:
>> Tom,
>> 
>> Measurement of one way delay and jitter are beyond the scope of this
>> document. Although one-way delay and jitter are very interesting metrics,
>> obtaining them is a non-trivial matter.
>> 
>> /speaking as individual contributor/
>> 
>>                                         Ron
>> 
>> 
>> > -----Original Message-----
>> > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On
>> > Behalf Of Tom Scott
>> > Sent: Wednesday, September 04, 2002 9:38 AM
>> > To: ccamp@ops.ietf.org
>> > Subject: Re: I-D ACTION:draft-ietf-ccamp-tracereq-00.txt
>> >
>> >
>> > [ post by non-subscriber.  with the massive amount of spam, it is easy to
>> >   miss and therefore delete mis-posts.  so fix subscription addresses! ]
>> >
>> > The draft addresses spatial tracing.
>> >
>> > Is there also interest in time? The only reference to temporal
>> > tracing is in
>> > section 6 item 5: "include tunnel components and round trip delay
>> > across each
>> > component". In this draft or possibly another it might be
>> > valuable to extend the
>> > granularity of the discussion to:
>> >
>> > * time: delay and jitter from one node to another.
>> >
>> > * space: what are the nodes? Reference to GMPLS in the draft indicate
>> >    that L1/L2 transport nodes are of interest.
>> >
>> > * space and time: within nodes, such as routers, would you extend the
>> >    spatial and temporal tracing to interfaces? to other logical /
>> > functional
>> >    components such as the "datapath elements" referenced in RFC 3290/89?
>> >    Timing in transport equipment at the sub-IP area and in
>> > datapath components
>> >    of those nodes?
>> >
>> > It's valuable to know not only where traffic goes but also the
>> > time it takes to
>> > get there, on all layers of the path, in equipment on each of
>> > those layers, and
>> > in functional components within those nodes. But these issues
>> > don't have to be
>> > covered in this draft. They might be addressed elsewhere by
>> > individuals whose
>> > daily work depends on multivendor multiprovider QoS tracing.
>> >
>> > -- TT
>> >
>> >
>> >
>> >
>>