Subject: RE: Clarification on today discussions

From: [email-masked]
Date: Wed, 20 Mar 2002 01:59:08 -0000

Thanks Shahram....one specific observation in line.  However, I strongly
agree with your general thrust below, that it is simply not good enough to
wait until things fall over before reacting....there are some excellent
networking principles that have been developed over many years and IMO it is
bordering on professional negligence to disregard these as of no import.
Wrt to defect detection/handling, Y.1710 is a good treatise on the general
requirements/principles problem space, and I would be amazed if most major
operators did not agree with these.....OK its targeted at MPLS, but the wise
reader can see that the principles are general in application and are
already specified/used for SDH/Sonet, PDH, ATM and OTN (G.709).

regards, Neil

Shahram Davari wrote 19 March 2002 20:57
> 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. 
NH=>Well, that means one has to question the viability of what is happening
in PWE3 and whether anyone is intending to carry ATM, or anything else like
Sonet (since exactly the same principles apply here), over MPLS....or more
accurately any PSN.  It can't be argued both ways, which seems the current
case. So what's the answer from the ADs on this?
> 
> 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: George Swallow <[email-masked]>
Date: Wed, 20 Mar 2002 18:07:23 -0500

Neil -

> case. So what's the answer from the ADs on this?

I quite agree that an operator who uses MPLS to extend and or replace
an ATM or FR service may well desire a level of OAM in the MPLS
protion that matches what exists (or is expected) elsewhere.  But
following the end-to-end argument, this should be built into PWE3
solutions.  The vast majority of MPLS which is not offering such
services should not be "strongly recommended" to adopt such methods.

...George

==================================================================
George Swallow       Cisco Systems                  (978) 497-8143
                     250 Apollo Drive
                     Chelmsford, Ma 01824

---

From: Yakov Rekhter <[email-masked]>
Date: Thu, 21 Mar 2002 07:19:41 -0800

George,

> solutions.  

And therefore, this should be a fine work item for the pwe3 working group.
So, I would suggest that Neil should bring this up on the pwe3 mailing
list.

Yakov.