FW: Questions about tunneltrace

[Ron Bonica <rbonica@mci.net>]

Eric,

Thanks for your comments. See reply below....


> -----Original Message-----
> From: owner-tun-trace@ops.ietf.org
> [mailto:owner-tun-trace@ops.ietf.org]On Behalf Of Eric Rosen
> Sent: Tuesday, February 27, 2001 12:16 PM
> To: tun-trace@ops.ietf.org
> Subject: Questions about tunneltrace
>
>
> From draft-bonica-tunneltrace-01:
>
>       9) When the tunneling technology isolates the user-plane from the
>       control-plane, do not rely upon the control plane to discover the
>       path.
>
> From draft-bonica-tunproto-00:
>
>    D2 receives the TraceProbe, exercises access control, and determines
>    that it is the hop's head end device. D2 consults its FIB and
>    determines that an IP-in-IP tunnel supports H1.
>
> I think this is saying that  D2 must consult its control
> structures in order
> to determine whether the "hop" H1  is a tunnel or not.  Doesn't
> this violate
> the requirement above?  In the  event of failures, D2's
> "determination" that
> data packets are supposed to be traveling through a tunnel
> doesn't necessar-
> ily mean that data packets would actually travel through that tunnel.

You have a point! Strictly speaking, I am not tracing through the
user-plane, but bouncing back and forth between the user-plane and the
control-plane. I have no choice but to do so.

In order to remain in the user-plane, I would have to send a series of
datagrams from the head-end of the top-level tunnel to the tail-end of the
top level tunnel, causing the each datagram to self destruct at a different
point along the path. Upon destruction, each datagram would elicit some
feedback that would a) include tunnel details and b) be sent all the way
back to the head-end of the top-level path.

Isn't that the kind of layer violation that we are trying to avoid?

Even if this is an acceptable layer violation, don't I still need to do such
things when tracing through tunnels that don't support TTL decrement?

>
> I am also  puzzled more generally about the phrase "D2  consults
> its FIB and
> determines  that a  ...  tunnel  supports H1."   I don't
> understand  how in
> general  D2  can  make  this  determination from  the
> information  that  is
> available in  the traceprobe packet.  If  we're trying to  trace
> nested MPLS
> tunnels, then it would  seem that we at least need to  know the
> label that a
> data packet would have  when it enters D2, but I don't  see any
> place to put
> that.
> More generally,  there doesn't seem to be  any provision
> for handling
> the case  in which  the routing  of a packet  is not  based
> entirely  on the
> packet's destination address.
>
> Similarly, I don't see  how a hop can be identified by  a
> object" which
> has only the IP addresses of the  hop endpoints.  There can be
> any number of
> tunnels between the same  two endpoints, each with different
> characteristics
> and  even with  different routes.   The  only data  you seem  to
> provide  of
> choosing one of these tunnels over the others is the destination
> IP address,
> and this isn't necessarily sufficient.


Again, you have a point!

When we analyse H1, the following information is available:

	-> top-level information (D1's loopback, D4's loopback, TOS)
	-> H1 information (a head-end address on D2, and a tail-end address on D3)

Now, assume that there are two tunnels between D2 and D3. One supports all
UDP traffic, while the other supports all TCP traffic. As currently
specified, GTTP could not distinguish between them. I need another field in
the traceProbe that contains the begining of the packet that I would trace,
including transport layer headers.

>
> On a  more trivial  matter, the  protocol draft will  need to
> say something
> about timing out remembered traceprobes,  in case the trace
> response doesn't
> come back.

Agreed. I will catch this on the next revision.

>
>
>