RE: draft-bonica-tunneltrace-02

[Shahram Davari <Shahram_Davari@pmc-sierra.com>]

Thom,

> -----Original Message-----
> From: Thomas D. Nadeau [mailto:tnadeau@cisco.com]
> Sent: Friday, March 01, 2002 11:08 AM
> To: neil.2.harrison@bt.com
> Cc: erosen@cisco.com; Shahram Davari; ccamp@ops.ietf.org
> Subject: RE: draft-bonica-tunneltrace-02 
> 
> 
> 
> >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.


I think what Neil is saying is that a path-trace is only a diagnostics
tool. It can't be used to detect path-defects in real-time. You still need
another tool to detect that the defect exists in the first place, and then
you may use path-trace to find what the problem is.

Also using a GTTP type of path-trace, you have to assume either: 1) the path is fine (has no defect) or 2) If there is any defect, it is a simple path-break defect.

Defects such as misbranching, merging, etc can't be detected, unless: 1) All nodes are GTTP upgraded and 2) There is a return path from all nodes to the GTTP host
 

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

The basic philosophy of MPLS was to decouple forwarding from routing and signaling (control-plane). The idea was that any routing and signaling protocol could be used, without the need to change the forwarding paradigm.

It is true that today we have LDP, CR-LDP, RSVP-TE, BGP, etc  as control-plane. But 
we could also have configured LSPs (without signaling), and in future people may use other
non-IP based routing/signaling protocols such as PNNI.

Therefore developing an IP-based OAM for MPLS will unnecessarily limit the routing/signaling protocols that could be used for MPLS. If it was impossible to define a non-IP based OAM, then we had no choice, but it is possible.

Yours,
-Shahram

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