Re: draft-bonica-tunneltrace-02

[Ping Pan <pingpan@juniper.net>]

neil.2.harrison@bt.com wrote:

> 
> -	a trail-tracing function is one diagnostic tool which is 'desirable'
> to help operations people verify routing......it is not the only 'desirable'
> diagnostic tool required.  Moreover, it is not a defect detection/handling
> tool, which is an 'essential' function IMO.  I hardly think it appropriate
> that in all the cases we want to use IP/MPLS technologies to expect the
> customer to act as the defect detection mechanism.  I see this as
> particularly ironic and inconsistent given that in the GMPLS work it is
> taken for granted that the defect detection/handling mechanisms relevant to
> the traffic/data-plane of a L1 layer network (eg SDH) must indeed be
> present....such as correct framing, BIP-X violations, trail-trace
> violations, FDI to suppress higher client layer alarms, etc. ...


Neil,

Just curious, what's wrong with using IP "tools" to detect data-plane 
LSP problems?  That's how we have been doing things in the Internet for 
years.

People may forget how "ping" and "traceroute" were used in the Internet 
years ago: they were used to solve the similar problems that we are 
facing today in (G)MPLS networks, i.e., to detect and locate trouble 
spots. In the NSFnet days, we had always used both commands (and some 
more) to detect microcode and HDLC bugs in the network....

When (G)MPLS technology becomes more mature one day, there may not be 
much need to use any tool for detecting physical layer problem. But now, 
there is urgent need to have the tools. Instead of working out 
philosophical issues, why don't we just solve the problem?

Regards,


- Ping