Subject: Re: [mpls-tp] OAM ambiguity in IDdraft-vigoureux-mpls-tp-oam-requirements-00

From: Maarten Vissers <[email-masked]>
Date: Mon, 08 Sep 2008 10:06:48 +0200

Adrian,

I have structured the OAM mechanisms into Classes, Types and Functions.
I have identified four classes: multi-ownership, pro-active, on-demand and
communication channel.
Each class has multiple types and each type has one or more functions as
presented in the table hereafter.

CLASS				TYPE			FUNCTION
============================================================================
===================
Multi-ownership		Levels		Network, Tandem (carrier, prot.sw.)
and Link Connections
				Security		OAM level filtering
----------------------------------------------------------------------------
-------------------
Pro-active			Status		Continuity Check &
Connectivity Check
				Performance		Interruption
							Frame Loss
				Maintenance		Alarm Suppression
							Locked Indication
							Remote Defect
Indication
							Client Signal Fail
----------------------------------------------------------------------------
-------------------
On-demand			Status		Connectivity Check
				Performance		Frame Loss
							Frame Delay
							Frame Delay
Variation
							Throughput
				Fault location	Channel connectivity
							Flow connectivity
				Discovery		Flow connectivity
----------------------------------------------------------------------------
-------------------
Communication channel	Protection		Head-/tail-end
synchronisation
				Synchronization	Distribute timing quality
				General Purpose	MCN ECC
							SCN ECC
----------------------------------------------------------------------------
-------------------
 
The 'communication channel' class has three types. The MCC and SCC OAM are
'General Purpose' communication channel types supporting the MCN ECC and SCN
ECC functions.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Adrian Farrel
Sent: 18 August 2008 10:49
To: [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] OAM ambiguity in
IDdraft-vigoureux-mpls-tp-oam-requirements-00

Nurit,

It is right to bring out the difference between data plane and management
plane, and that should surely be part of the framework.

But I think (again) we are in danger of developing solution-oriented
requirements, instead of pure requirements.

It is hugely likely that the pure requirements will lead us to develop data
plane based OAM, but the requirements must be expressed in terms of
functionality, not in terms of solutions.

Further, if we concentrate on the requirements, we do not have to worry what
OAM, OA&M or any other acronym stands for. We can have requirements, and we
can look at how to meet them.

>I think OAM (in the transport layer) stands for Operation, 
>Administration and Maintenance, and the scope of OAM is this document.
>
>I do not understand why we should refer to the management plane or to 
>the "Vertical OAM" or OAM&P in this document and personally I would 
>prefer to see another terminology referring to the vertical one in 
>order to avoid confusion.

Cheers,
Adrian
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp