The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2001-Dec> msg00192



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

MPLSOAM BOF meeting draft minutes

  • From: "David Allan" <dallan@nortelnetworks.com>
  • Date: Mon, 17 Dec 2001 10:45:32 -0500
  • Cc: Ben Mack-Crane <Ben.Mack-Crane@tellabs.com>, neil.2.harrison@bt.com, mpls@UU.NET

Title: RE: MPLSOAM BOF meeting draft minutes
Hi Dave:
 
I understand your points.....
 
When it comes to fault management (which this discussion seems to be focused upon), my expectation is that I'm doing this for multiple reasons, first is knowing I have a problem, the second is the possiblity of the network taking some automated corrective action, protection switching, local repair, re-route etc. So I have a reasonable expectation that the layer/level doing fault management also has the ability to take some corrective action.
 
If I'm doing fault management at the pseudo-wire layer, I have trouble imagining it's utility. It will either depend on the lower layer to take some corrective action (wait some arbitrary amount of time before declaring the service dead) or it will have to implement some nodal behavior to direct the lower layer to take some corrective action. This could get messy.
 
If the fault actually occurs in the PW end points, then if the transported service has it's own OAM (e.g. ATM, SONET or FR), then I am assuming that the interworking function (IWF) would permit the fault to be sectionalized as either the PW or the ingress/egress links. Its only if the PW interworking function is transparent to the higher layer OAM that you lose this capability, the PW and the ingress/egress appear as a single link.
 
Similarly if either end of the PW goes down or degrades, the service is effectively toast unless the PW client layer has some degree of agility and can detect the fault and take corrective action.
 
So IMHO fault management is required in layers that can proactively respond to faults. I understand that there can be a rationale for a pseudo-wire having some OAM functions, but this does not eliminate the need for OAM in the PW transport, in this case MPLS.
 
rgds
Dave
-----Original Message-----
From: Dave McDysan [mailto:dave.mcdysan@wcom.com]
Sent: Friday, December 14, 2001 11:53 AM
To: Allan, David [CAR:NS00:EXCH]; Shahram Davari; Punj, Arun; 'Giles Heron'; Fedyk, Don [BL60:1A00:EXCH]
Cc: Ben Mack-Crane; neil.2.harrison@bt.com; mpls@UU.NET
Subject: RE: MPLSOAM BOF meeting draft minutes

See my earlier response to Sharam to see if my pont is clearer. Please explain "PW/IWF is completely transparent"
 
Dave
-----Original Message-----
From: owner-mpls@UU.NET [mailto:owner-mpls@UU.NET]On Behalf Of David Allan
Sent: Thursday, December 13, 2001 7:13 PM
To: Shahram Davari; 'Dave McDysan'; Punj, Arun; 'Giles Heron'; Don Fedyk
Cc: Ben Mack-Crane; neil.2.harrison@bt.com; mpls@UU.NET
Subject: RE: MPLSOAM BOF meeting draft minutes

Dave:

Isn't a failure at the ends of the pseudo wire effectively a failure in the client layer. The failed node has visiblity in the client layer. 

All ingress and egress points are single points of failure. Its only if the PW IWF function is completely transparent (e.g. Virtual leased line) that you potentially have a problem. And that is more poor design.

cheers
Dave

> >
> > Since pseudo-wire is a layered service, MPLS OAM alone will
> > not solve this
> > problem. There are also defects that can occur in the
> > functions at the ends
> > of the pseudo-wire.
> >
> > Dave
> >
>
>