Re: FW: Questions about tunneltrace

[Eric Rosen <erosen@cisco.com>]

Ron> We  are  trying  to  avoid  the trap  into  which  draft-ietf-mpls-icmp
Ron> fell. 

Political incorrectness?

Ron> The basic  problem with that  draft was that  it looked inside  an MPLS
Ron> payload,  found and  IP header,  and  assumed that  the source  address
Ron> specified by that IP header  was meaningful within the LSRs layer three
Ron> routing context.

Ron> For example, lets  say that the source address is  10.1.1.1 and the LSR
Ron> has a route to 10.1.1.1.  Is the  host to which the LSR has a route the
Ron> same one the originated the datagram?  If the LSR does not have a route
Ron> to 10.1.1.1, it sends the ICMP  message to the egress LSR.  Is the host
Ron> to which  the egress LSR  has a route  the same one the  originated the
Ron> datagram?

RFC3032 describes a pretty simple  procedure for getting the ICMP message to
the egress  of the outermost tunnel  before routing it back  to the original
source.  Chances  are rather high that  the address means the  same thing at
both ends of the outermost tunnel.

But there is an advantage of sending the response to the ingress rather than
the egress.  This has  to do with the fact that if  one of the inner tunnels
is broken, the RFC3032 procedure may  not get the response to the egress, in
which case  responses never get back  to the original source,  and the trace
doesn't tell  you anything that  you didn't already know  (i.e., something's
broken).  So having a procedure for  getting back to the tunnel ingress does
seem like a good idea.  

I  would  question  though  whether  it  is  really  necessary  to  get  the
traceresponse  back to  the OUTERMOST  tunnel ingress.   I think  that  if a
traceresponse comes from the middle of  a tunnel, it is probably good enough
to get it back to the  ingress of the immediately containing tunnel, even if
this is an interior tunnel.

True, this won't work if there is  no route between the enduser who is doing
the trace and the ingress of  the interior tunnel.  However, I think that if
there is no such route, that's  because the owner of the tunnel ingress does
not want  the enduser to  be able to  send packets to  it.  GTTP opens  up a
security hole here.  Yes, GTTP provides an authentication mechanism that can
be used to close the hole.  But  unless there is good reason to believe that
service providers will often want to  leave this hole open, we might as well
just nail  it closed; this would  result in a  significant simplification of
the protocol.

To trace a tunnel, the enduser would always have to direct the traceprobe to
the ingress of  THAT tunnel.  The traceprobe packet  which the ingress sends
through the  tunnel could itself carry  the address of the  ingress, so that
the traceresponse  could come  back.  Then  there would be  no need  for ANY
router to maintain ANY state for a traceprobe.

I would  also suggest that when a  traceresponse is generated by  a node, it
contain  ALL the  information that  the node  would have  used to  route the
arriving  probe, had  the probe's  TTL not  expired.  To  make sure  ALL the
necessary information is included,  we should probably include an identifier
for the probe's incoming  interface, as well as the full set  of MPLS and IP
headers.  Call this a "forwarding information object". 

The original traceprobe sent by an  enduser should also be able to contain a
forwarding information  object.  This would  enable you to trace,  e.g., the
path of a  packet which arrives on a particular  interface with a particular
label stack. 

Once  you've  received  a  traceresponse  from every  node  along  the  path
(excluding nodes within tunnels), you need  to send a new traceprobe to each
of those nodes.  The traceprobe sent to a particular node should contain the
forwarding information  object returned  in that node's  traceresponse.  The
semantics  would be "if  this is  the forwarding  information for  a packet,
would you put the packet in a tunnel?  if so, please initiate a trace of the
tunnel".   Since a particular  node may  be the  ingress to  multiple nested
tunnels, we  need include a tunnel depth  number, but I don't  think we need
anything as complicated as the hop object.

It's still  not clear  to me  though that this  produces something  which is
significantly  better  than  a  pseudo-trace procedure  which  examines  the
control plane exclusively.