RE: draft-bonica-tunneltrace-02

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

> -----Original Message-----
> From: Shahram Davari [mailto:Shahram_Davari@pmc-sierra.com]
> Sent: Thursday, February 21, 2002 12:03 PM
> To: 'Ron Bonica'; ccamp@ops.ietf.org
> Subject: RE: draft-bonica-tunneltrace-02
>
>
> Hi Ron,
>
>
> > -----Original Message-----
> > From: Ron Bonica [mailto:Ronald.P.Bonica@wcom.com]
> > Sent: Thursday, February 21, 2002 11:34 AM
> > To: Shahram Davari; ccamp@ops.ietf.org
> > Subject: RE: draft-bonica-tunneltrace-02
> >
> >
> > Sharam,
> >
> > Section 7 of this document enumerates a some minimal protocol
> > requirements.
> > Specifically, it states that:
> >
> > o a traceResponse will carry information regarding a section
> > of the traced
> > path
>
> Why not information about the whole path? Is it becasue GTTP can't do it?

We have a requirement to trace through IP-in-IP tunnels. In this
environment, no single device knows the entire path. The only solution is to
ask each device, either directly or through a proxy, about the hop(s) in
which it participates.

>
> > o a traceProbe will elicit a traceResponse
>
> Why not a series of trace responses? Anything fundamentally wrong
> with it or is it becasue GTTP can't do it?

Given that we must trace through IP-in-IP tunnels, we must elicit responses
from multiple devices. So, when you ask why a single traceProbe doesn't
elicit a series of traceResponses, I assume that you are asking why a single
traceProbe doesn't elicit a series of traceResponses from a series of
devices.

Let's entertain this possiblity. How could we alert each router along the
traced path to respond to a single probe?

We could specify the IP Router Alert Option on our probe, but the presence
of that option can cause the datagram to follow a different path than it
might otherwise follow. Another possibility is to maintains some stateful,
intermediate proxy that amplifies one traceProbe into many. But why do that
when the probing application is capable of doing the same thing?

Even if you found a neat way to make multiple routers respond to a single
probe, you would still need to deal with out of sequence and missing
responses.

IMHO, a one-to-one mapping of probe to response is simplest.

>
> > o UDP will carry traceProbes and traceResponses
>
> Why not TCP or even GTTP over IP?

Does TCP add any value when a single probe elicits a single response?
Putting the protocol PDU over IP is a possibility, but protocol identifiers
are in much shorter supply than UDP port numbers.

>
> > o the protocol will be stateless
> > o each device within the trace path need not maintain an IP
> > route back to
> > the device that hosts that tracing application
>
> Why? Why return path from head of the path is not enough?
>

In its first version, a route from the head end of the traced path was
enough. I changed this in response to a comment from the WG.

> >
>
> > Although these broad brushstrokes do not specify a protocol,
> > they provide
> > direction to protocol developers.
>
> To develop GTTP!

Or any other protocol that satisfies the requirements.

>
>  We are looking for an IP
> > based protocol
> > that can probe network elements about whatever tunnels they maintain,
> > regardless of the tunnel type. We are not looking to extend
> > the capabilities
> > of any particular tunneling technology.
>
> I know. But the protocol restrictions that are mentioned must be
> justified.
>
> -Shahram
> >
> >                                       Ron
> >
> > > -----Original Message-----
> > > From: owner-ccamp@ops.ietf.org [mailto:owner-ccamp@ops.ietf.org]On
> > > Behalf Of Shahram Davari
> > > Sent: Tuesday, February 19, 2002 5:29 PM
> > > To: ccamp@ops.ietf.org
> > > Subject: RE: draft-bonica-tunneltrace-02
> > >
> > >
> > > Hi,
> > >
> > > Although this document is a generic requirement for tunnel
> > > tracing, I find many protocol specific requirements that are not
> > > actually a requirement, rather they are suggesting a
> > specific solution.
> > >
> > > For example:
> > >
> > > "The protocol elicits a series of traceResponse messages."
> > > "Each traceResponse message represents a hop that connects the
> > > head-end of the traced path to the tail-end of the traced path"
> > > "Each traceProbe message elicits exactly one traceResponse message."
> > > "UDP carries traceProbe and traceResponse messages to their
> > destinations."
> > >
> > >
> > > Thanks,
> > > -Shahram
> > >
> > >
> >