Subject: RE: draft-nadeau-pwe3-oam-msg-map-04.txt

From: "Thomas D. Nadeau" <[email-masked]>
Date: Thu, 25 Mar 2004 13:16:22 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Thursday, March 25, 2004 12:54 PM
To: [email-masked]; [email-masked]
Subject: RE: [PWE3] draft-nadeau-pwe3-oam-msg-map-04.txt

Tom...
> > 
> > If you read the draft, you will see that at no point it is 
> > suggested that ATM or SONET alarms should be mapped to PW 
> > alarms.
> NH=> I am being pedantic here, but one does not map 'alarms' between
> layer networks under any situations....even those where the func arch
> requirements of layer networks involved are not violated.  
> The only OAM
> semantic that should be passed between layer networks is the FDI (the
> purpose being to *suppress alarms*)....and then only in an arch valid
> client/server case, this should not passed *between* layer 
> networks when
> operating in a peer-partition sense.  And to be clear why, I have
> attempted an expanation below:
> 
> 	Why should one "not map 'alarms' between layer networks"? It 
> seems to me that this is done in a variety of contexts today. Can 
> you justify why this is not a good idea. 
> 
NH=> I will assume we are discussing the client/server case.  The part
of the mail that was snipped explained why defect mapping indications in
the peer-partition case was not generally a good idea.

An alarm should be strive to be singular in nature.  It should be raised
by the 1st equipment downstream of the defect that is able to detect it.
This gives a localised indication of the where the problem is.  All
client layers (see note) should be informed of the lower layer defect by
sending them a FDI (and this ought to be done in the
data-plane....depends on how well-specified the client layer is
however).  The defect detected in the server layer, at its trail
termination point, is the also the point associated with the alarm.
Above the server layer trail termination point there is a server->client
adaptation function.....this is where the FDI (in terms of the client
layer FDI syntax) is injected.

If you don't do something like this there could be a huge number of
uncorrelated alarms raised at the trail termination points of the
affected clients.  These may be in other operators networks, and maybe
in other countries.

Note - This is only strictly true for the co-cs and co-ps
clients....though some folks who working on ethernet (cl-ps)
fault-management may disagree with this, as they are considering
introducing a 'fixed' topology overlay of OAM insertion/extraction
points. In a sense these can be considered to be a co-ps overlay.

Hope that helps explain what I meant by not 'mapping alarms'.

	Then I don't see why you think that what Peter was describing
is not what you describe above.  The msg mapping draft does describe
how to a) "gives a localised indication of the where the problem 
is.", and b) "Above the server layer trail termination point there 
is a server->client adaptation function.....this is where the FDI 
(in terms of the client layer FDI syntax) is injected." 

	--Tom