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

[Ron Bonica <Ronald.P.Bonica@wcom.com>]

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
>
>
>
>