[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Questions about tunneltrace
- To: tun-trace@ops.ietf.org
- Subject: Questions about tunneltrace
- From: Eric Rosen <erosen@cisco.com>
- Date: Tue, 27 Feb 2001 12:16:11 -0500
- Delivery-date: Tue, 27 Feb 2001 09:17:09 -0800
- Envelope-to: tun-trace-data@psg.com
- Reply-to: erosen@cisco.com
- User-Agent: EMH/1.10.0 WEMI/1.13.2 (Mochimune) FLIM/1.12.1(Nishinokyō) Emacs/20.6 (sparc-sun-solaris2.5.1)MULE/4.0 (HANANOEN)
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.
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 "hop 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.
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.