Subject: Clarification on today discussions

From: Shahram Davari <[email-masked]>
Date: Tue, 19 Mar 2002 12:56:53 -0800

Hi All,

During today's MPLS meeting, Ping Pan raised the question that the application should
derive the solution, and that he is not aware of any application needs that can't be
met by LSP-ping and GTTP. 

My answer was:

ATM/FR over MPLS application requires that upon any failure detection in the 
MPLS network, AIS should be sent from the egress LSR on the ATM/FR connections
in order to suppress the downstream alarms at the terminating point of those 
connections. This can't be done with ICMP/LSP-ping or GTTP, because in these solutions
the egress is not the node that detects the failure. While in Y.1711 it is the egress
LSR that detects the failure and can correctly inject AIS in to the ATM/FR connections.

Talking to Ping Pan after the meeting, I realized where his comments are coming from.
His argument is that since he doesn't know of any deployed ATM/FR over MPLS network, he thinks
there is no problem to be solved. 

In other words he thinks we should not try to fix a problem which has not occurred
in the real world yet. Although this might be an acceptable approach to some folks/companies,
this is not simply true for many others. In my opinion anticipation of the problems and 
providing solutions upfront is a sound engineering practice and leads to easier adaptation
of the technology in shortest amount of time without frustrations.

This approach reminds me of the first time (a year ago) that I presented the need for a connectivity checking
tool for LSPs, on the basis that the forwarding table could be corrupted in the forwarding hardware
or it may not match the forwarding table that exists in the software. Many people objected that this
is insane and that we should not fix a vendors buggy implementation with more software. But we 
all saw that Ping Pan came with his LSP-ping draft and in the introduction section of his draft
mentioned that this has been seen in real networks and a quick fix is needed.

I would like to bring your attention to the fact that such a problem can also happen in the
L1/L2 over MPLS networks as well as static configured LSPs and CR-LDP based LSPs, which can't 
use LSP-ping to solve. This is simply an engineering observation and not a fortune telling.

So you are free to sit and wait until a problem is reported from the field, or you could take 
action now and try to find a solution to a problem that sound engineering mind could anticipate
to occur. 

The decision is upon you.

Yours,
Shahram Davari
Senior Product Research Engineer
R&D Research Ottawa
PMC-Sierra, Inc. 
Phone: (613) 271-4018
Fax:   (613) 271-6468

---

From: Ping Pan <[email-masked]>
Date: Wed, 20 Mar 2002 04:32:06 -0800

> there is no problem to be solved. 

I am not interested in working a "Long Term Solution for Generations to 
Come". That's just my personal opinion.

> use LSP-ping to solve. This is simply an engineering observation and not a fortune telling.

Base on the requirements and suggestions from other providers and 
vendors, Kireeti has re-written the draft to support the applications 
above. Please read -03 draft.

Thank you!

- Ping