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

From: [email-masked]
Date: Thu, 23 Dec 2004 15:26:50 -0500

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-mpls-oam-requirements-05.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-mpls-oam-requirements-05.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
mpls mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mpls

---

From: [email-masked]
Date: Fri, 24 Dec 2004 09:07:49 -0000

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: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: 23 December 2004 20:27
> To: [email-masked]
> Cc: [email-masked]
> 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.
> 
http://www.ietf.org/internet-drafts/draft-ietf-mpls-oam-requirements-05.
txt