RE: [mpls] I-D ACTION:draft-ietf-mpls-oam-requirements-05.txt

I recently posted (21 December 2004 14:12) a mail against the thread
"RE: [mpls] draft-ietf-mpls-p2mp-sig-requirement-00.txt" to this list
which said the following:

==start=>
I agree with you on the assumption that the requirements are indeed
correct.
{NH editing note=> So this is referring to the *requirements* draft
which is the subject of this thread.}

When we are dealing with either of the co modes there is a particularly
important requirement on the base defect detection/handling OAM (this is
quite different to any ad hoc OAM for diagnostics or Network Performance
measurements say)....that is the OAM MUST:
-	reside in the data-plane of the traffic it is
protecting/monitoring
-	be unidirectional.

The latter requirement is rather important for these reasons:

1	the consequent actions (such as traffic suppression, raising
local alarms, sending FDI to suppress higher layer network alarms, etc)
MUST be done at the trail sink.
2	allows both p2p and p2mp cases to be handled scalably in a
similar manner.

For p2p cases there is a further requirement:

3	Virtually all applications using p2p trails have a
bi-directional availability requirement, ie if either direction fails
then it is usual for the application to fail.  This means unavailability
needs to be considered as an OR function of each direction.  The
implication of this is that any Network Performance measurements that
are in force for SLA purposes MUST be suspended in both directions when
the unavailable state is entered (in EITHER direction).  However, in the
available state Network Performance is a unidirectional measurement.
Note also here:
-	that Net Perf measurements must also be coupled to the trail
sink and are clearly unidirectional themselves
-	that there is a required 'ordering' of processes, viz:
	* mode defines relevant defects and required OAM (they are
different in in each network mode);
	* defects must be defined in terms of entry/exit criteria and
consequent actions;
	* if we want to keep things simple (and I recommend we do),
entry/exit of the unavailable state should be based only on defect
persistency, ie don't include network performance metrics in this if
possible;
	* once we have clearly defined available and unavailable 'time'
we have a correct basis for the measurement of network performance
SLAs....noting that both (un)availability and network performance SLAs
are important, but unless the above ordering is taken into account the
process of network performance measurements can be made either very
complex or meaningless.
<==end=

Monique kindly responded thanking me for the clarifications.  I have
heard no comment saying the above is not correct (indeed, I would be
surprised if there was given it is largely just a statement of fact).
Given this, I must assume the requirements draft will be updated to
capture these important points.  I would be happy to propose some text
if this helps.

regards, Neil

> -----Original Message-----
> From: mpls-bounces@lists.ietf.org 
> [mailto:mpls-bounces@lists.ietf.org] On Behalf Of 
> Internet-Drafts@ietf.org
> Sent: 23 December 2004 20:27
> To: i-d-announce@ietf.org
> Cc: mpls@ietf.org
> Subject: [mpls] I-D ACTION:draft-ietf-mpls-oam-requirements-05.txt
> 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories. This draft is a work item of the 
> Multiprotocol Label Switching Working Group of the IETF.
> 
> 	Title		: OAM Requirements for MPLS Networks
> 	Author(s)	: T. Nadeau, et al.
> 	Filename	: draft-ietf-mpls-oam-requirements-05.txt
> 	Pages		: 14
> 	Date		: 2004-12-23
> 	
> As transport of diverse traffic types such as voice, frame
>    relay, and ATM over MPLS become more common, the ability 
> to detect, 
>    handle and diagnose control and data plane defects becomes 
>    critical. 
> 
>    Detection and specification of how to handle those defects is not 
>    only important because such defects may not only affect the 
>    fundamental operation of an Multi-Protocol Label Switching 
> network, 
>    but also because they MAY impact service level specification    
>    commitments for customers of that network.
> 
> A URL for this Internet-Draft is: 
>
http://www.ietf.org/internet-drafts/draft-ietf-mpls-oam-requirements-05.
txt

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls