RE: draft-bonica-tunneltrace-02

[neil.2.harrison@bt.com]

Eric/Shahram,  see addtional remarks below.  regards Neil

> Shahram> 1) If a router  is not GTTP upgraded, it will  drop 
> the TTL expired
> Shahram>    GTTP messages.  Consequently the host will not 
> receive any reply
> Shahram>    from that router,  which translates to a break  
> in the tunnel at
> Shahram>    that point.
> 
> For GTTP to be useful at all, the tunnel head ends must support it. 
> 
> If a particular  node within a tunnel does not support  GTTP, 
> but some nodes
> beyond  it do,  we won't  get complete  trace info,  but 
> should  be  able to
> continue tracing beyond the non-supporting node.
> 
> But the  basic point is valid,  that in order  to use GTTP to 
>  trace through
> your network,  your routers must  support it.  I  guess I 
> don't see  this as
> much of a problem.  I  wouldn't call it an interoperability 
> problem, because
> no existing mechanisms are broken by the use of GTTP. 
NH=> If you noted in some of my earlier mails I was very careful to refer to
'simple breaks' when using trail-trace type of mechanisms for defect
diagnosis.  If you ever get a misbranching/mismerging defect then:
-	you need to know it exists in the 1st place (not obvious how this
can be done....with CV it's trivial, as you see the source ID of any
offending LSP at the sink of the offended LSP, so you both detect/diagnose
immediately)....I'll ignore the fact that a whole raft of consequent actions
are also missing;
-	since the location of such defects cannot be known a priori, then if
you want the 'misbranched' GTTP messages to elicit a response then the
arbitrary nodes where they end up must be able to respond......and in
general this means the whole network/nodes need to be 'GTTP aware' and they
need a return channel to the source.
IMO any trail-trace functions are best used under the assumption that the
network is actually defect-free.....we need other tools to detect/handle the
defects (for the many reasons I tried to point out in earlier mails).
> 
> Shahram> 2) TTL expired user packets will now be forwarded to 
> UDP module
> Shahram>    instead of being dropped. Which could overload 
> the UDP module in
> Shahram>    certain situations.  
> 
> TTL-expired user packets are not simply dropped today; they 
> are forwarded to
> the ICMP module  to cause the generation of an  ICMP message. 
>  Usually there
> is some sort of limit placed on the number of packets that 
> can be queued for
> ICMP processing, or the  number of such packets that can be  
> seen in a given
> amount of  time, etc.  The  marginal overhead to  see whether 
> a  packet that
> makes it through to ICMP processing  is a GTTP packet doesn't 
> seem like that
> big a deal.
NH=> Asking ICMP to proxy for missing defect handling in MPLS is a
possibility....and as Geroge hints in an earlier mail is actually an example
of a layer violation, but so be it.  However, this should not be used in
XoverMPLS....you need a solution here that is self-contained within the MPLS
network.