RE: draft-bonica-tunneltrace-02

["Thomas D. Nadeau" <tnadeau@cisco.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;

         Please clarify.

>-       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.

         What is a "self-contained MPLS network"? MPLS networks require IP 
networks.
When running X over MPLS why does that requirement change at all?

         --Tom




------------------------------------------------------------------------
Mathematics is the supreme nostalgia of our time.