Subject: Re: [mpls-tp] MPLS-TP Framework - control plane control of OAM

From: "BOCCI Matthew" <[email-masked]>
Date: Mon, 2 Mar 2009 19:45:34 +0100

Adrian,

Thanks for addressing this one.

We had originally interpreted the text to mean triggering an OAM flow. I
agree that the control plane can be used for negotiating the OAM
protocol to use on an LSP, and configuring the appropriate objects as
required, but does it also include turning on and off the OAM flow once
all this is configured?

Matthew  

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]] 
> Sent: 28 February 2009 18:19
> To: BOCCI Matthew
> Cc: [email-masked]
> Subject: MPLS-TP Framework - control plane control of OAM
> 
> Hi Matthew,
> 
> In section 3.5 you have...
> 
>    Editor's note: Isn't the following a management plane operation.  I
>    can't think of a routing protocol triggering an OAM message.  Or do
>    we mean that the control plane is capable of reacting to 
> OAM events?
>    Control plane and OAM are independent.
> 
>    The MPLS-TP control plane is capable of activating MPLS-TP OAM
>    functions as described in the OAM section of this document
>    Section 3.4 e.g. for fault detection and localization in 
> the event of
>    a failure in order to efficiently restore failed transport paths.
> 
> I'm not sure I understand your note!
> The control plane contains more than routing protocols. For 
> example, signaling protocols.
> I don't think the paragraph says "triggering an OAM message." 
> It says "activating OAM."
> There is precedent in GMPLS for signaling enabling and 
> disabling OAM on an LSP.
> See draft-ietf-ccamp-oam-configuration-fwk-00.txt
> 
> Cheers,
> Adrian 
> 
>

---

From: <[email-masked]>
Date: Mon, 2 Mar 2009 18:56:05 -0000

Matthew.

The DP defect detection/handling OAM is completely independent of the CP
or MP method of setting up the LSP.  However, it is essetntial that the
activation/deactivation of an OAM (ie CV) flow must be synchronised to
the LSP set-up/tear-down process...irrespective of whether that is under
CP or MP actions.

Note also that this defect detection/handling OAM is *part of the DP and
must look like normal traffic*.  It should not therefore sit under the
GAL as this is primarily there for providing a logically OOB (wrt DP)
channel for CP/MP protocols and has a header structure that is not the
same as normal DP traffic.  The OAM indicate flag must therefore be part
of the normal traffic DP encasulation header.  This needs attention wrt
to the MPLS-TP drafts, ie draft-ietf-mpls-tp-gach-gal and
draft-bryant-pwe3-packet-pw-00.txt.

regards, Neil

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of BOCCI Matthew
> Sent: 02 March 2009 18:46
> To: Adrian Farrel
> Cc: [email-masked]
> Subject: Re: [mpls-tp] MPLS-TP Framework - control plane 
> control of OAM
> 
> Adrian,
> 
> _______________________________________________
> mpls-tp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls-tp
>

---

From: <[email-masked]>
Date: Mon, 2 Mar 2009 19:10:48 -0000

PS Matthew.....I should also have added that it makes sense for the
defect detection/handling OAM on *all* LSPs to be the same.  This is
obvious since one cannot predict a priori what sort of misconnectivity
defects will occur and where they will occur, and each LSP trail
termination point must be able to understand the OAM it sees incoming.
So if one allowed lots of different defect/detection OAM to be
configured then each trail termination would have to be able to work
with all such configurations.  This will also impact the alignment of
defect entry/exit state criteria and consequent actions.

My advice....keep the MPLS-TP defect detection/handling OAM very simple,
sparse and as uniform as possible.

regards, Neil

> [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: 02 March 2009 18:56
> To: [email-masked]; [email-masked]
> Cc: [email-masked]

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 3 Mar 2009 01:39:34 -0000

I believe that turning on and off an OAM (monitoring) flow is a part of the 
configuration.

A
----- Original Message ----- 
From: "BOCCI Matthew" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, March 02, 2009 6:45 PM
Subject: RE: MPLS-TP Framework - control plane control of OAM

Adrian,

Matthew

---

From: "Attila Takacs" <[email-masked]>
Date: Tue, 3 Mar 2009 07:59:24 +0100

Hi Matthew and Adrian,

I think we should differentiate between on-demand and proactive OAM
monitoring flows. 
The CP should support turning on/off proactive monitoring, but the
handling of on-demand flows should be left to the respective OAM
mechanisms.

Best regards,
Attila

> [mailto:[email-masked]] On Behalf Of Adrian Farrel
> Sent: Tuesday, March 03, 2009 2:40 AM
> To: BOCCI Matthew
> Cc: [email-masked]
> I believe that turning on and off an OAM (monitoring) flow is 
> a part of the configuration.
> 
> A

---

From: Thomas Nadeau <[email-masked]>
Date: Tue, 3 Mar 2009 08:02:34 +0000

I think we need to be specific about this.  There is work within  
CCAMP for example, that explicitly triggers the OAM to start/stop so I  
want to make sure we aren't being confused by doing an operation like  
that here. In this case I agree with our esteemed colleague from Wales  
on this; its part of the configuration.

	--Tom

On Mar 3, 2009:1:39 AM, at 1:39 AM, Adrian Farrel wrote:

> I believe that turning on and off an OAM (monitoring) flow is a part  
> of the configuration.
>
> A
> ----- Original Message ----- From: "BOCCI Matthew" <[email-masked] 
> >

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 03 Mar 2009 09:03:48 +0100

Attila,

On-demand OAM needs to be started/stopped and this is normally initiated via
network management. The NM system send via the management communication
network (MCN) the necessary commands to the MEP function that has to perform
the on-demand test.

When setting up a connection under control of a control plane, then the
control plane has to configure the MEP and MIP functions in the connection.
After that initial set up of connection and its MEP and MIP functions
control over those MEP functions is handed over to the network management
system. If an operator wants to start or stop pro-active OAM, then he/she
will control this via his/her NM system, which passes this information to
the MEP functions via the MCN.

There is as such no need for the control plane (and its signalling
communication network (SCN)) to be involved. But it is technically possible
to have the NM system use the SCN instead of the MCN to send the commands to
the MEP functions.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Attila Takacs
Sent: dinsdag 3 maart 2009 7:59
To: Adrian Farrel; BOCCI Matthew
Cc: [email-masked]
Subject: Re: [mpls-tp] MPLS-TP Framework - control plane control of OAM

Hi Matthew and Adrian,

I think we should differentiate between on-demand and proactive OAM
monitoring flows. 
The CP should support turning on/off proactive monitoring, but the handling
of on-demand flows should be left to the respective OAM mechanisms.

Best regards,
Attila

> Subject: Re: [mpls-tp] MPLS-TP Framework - control plane control of 
> OAM
> 
> We had originally interpreted the text to mean triggering an OAM flow. 
> I agree that the control plane can be used for negotiating the OAM 
> required, but does it also include turning on and off the OAM flow 
> once all this is configured?
> 
> Matthew
> 
> 
> 
> >    we mean that the control plane is capable of reacting to OAM 
> > events?
> >    Section 3.4 e.g. for fault detection and localization in the 
> > event of
> > The control plane contains more than routing protocols. For example, 
> > signaling protocols.
> > There is precedent in GMPLS for signaling enabling and disabling OAM 
> > on an LSP.

---

From: <[email-masked]>
Date: Tue, 3 Mar 2009 08:46:30 -0000

Largely agree with Maarten here....but I have a couple of further points
on this in-line: 

Maarten Vissers wrote 03 March 2009 08:04
> network (MCN) the necessary commands to the MEP function that 

NH=> The key point for operations folks is that when LSPs are
created/configured (because they are indeed a construct in a network)
the ability to detect defects and take consequent actions (including
raising alarms) has to be synchronised to whatever process (be it MP or
CP) is used.  If not true then we will either not detect defects (ie if
CV flows not activated immediately on LSP set-up) or we will generate
false alarms (ie CV flows not deactivated immediately on LSP tear-down).

> the MEP functions via the MCN.

NH=> I am not a fan of having lots of nested MEP/MIP TCM sublayer
monitoring since OAM has to be as simple and sparse as possible with
minimum configuration....because it must be super reliable.  It is one
thing configuring and activating/deactivating OAM at the *end-points* of
a LSP but it is quite a different thing IMO to add nested OAM
configuration of partial span sublayers.  The obvious point here is that
the end-points of a LSP are invariant across failures and
protection/restoration actions whereas embedded partial OAM sublayer
spans are not.  I also think the situation is different with protection
switching (where the working and protection paths can be
known/configured in advance) and restoration (where the protection path
may not be known, and so cannot be configured, in advance).

*If there is to any TCM with MPLS-TP then this needs to be taken account
of in draft-abfb-mpls-tp-control-plane-framework-00.txt and
draft-sprecher-mpls-tp-survive-fwk-01.txt, ie how are you going to do it
such that configuration and activation/deactivation is synchronised to
LSP set-up/tear-down.  Note that if PM flows are also active then there
needs to be consideration of how the PM counters (of loss say) are
co-ordinated across failures/recovery.  So Attila and Adrian you should
please consider this for your drafts.*  
 
> to have the NM system use the SCN instead of the MCN to send 

NH=> For co-ps networks that use label-swapping (as does MPLS-TP) and
use the CP to set-up/tear-down LSPs, the signalling needs to be able to
configure the trail termination of the sink with the expected SA of the
LSP source...so that when the DP CV flows starts it will know what SA to
expect in the CV OAM packets.

regards, Neil 

> [mailto:[email-masked]] On Behalf
> Of Attila Takacs
> disabling OAM

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 3 Mar 2009 09:27:45 -0000

I don't think we need to get too excited.

Where there is activity needed at only one place in the network and 
instigated from the management plane it can be controlled by:
a. a direct request from the management plane
b. an indirect request from the management plane forwarded
   through the control plane

There is no particular benefit to using the control plane unless the point 
where the activity is needed is to be selected dynamically.

Where there is activity needed at more than one place in the network and 
coordination is desired, it can be controlled by:
c. multiple management plane requests sent all of the necessary
  points in the network
d. a single management plane request distributed through the
  control plane
e. a single management plane request distributed through OAM

AFAIK no-one is trying to rule any of these out. This thread started, I 
think, trying to address point d.

Note, however, that the signaling plane is most appropriate when all the 
points for coordination lie on the same LSP.

Adrian

----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, March 03, 2009 8:46 AM
Subject: RE: [mpls-tp] MPLS-TP Framework - control plane control of OAM

regards, Neil

---

From: "Malcolm Betts" <[email-masked]>
Date: Tue, 3 Mar 2009 09:15:22 -0500

I think the key point is that for pro active OAM it must be possible to
synchronize the activation/deactivation with the configuration/tear down
of a path.  Therefore the MEP configuration and activation/deactivation
must be supported by signalling. An operator may choose not use this
mechanism.  It should be possible to also enable/disable/suspend pro
active OAM via the management plane.

On demand OAM should always be activated/deactivated via the management
plane. 

Malcolm Betts
Nortel Networks
Phone: +1 613 763 7860 (ESN 393)
email: [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Adrian Farrel
Sent: Tuesday, March 03, 2009 4:28 AM
To: [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] MPLS-TP Framework - control plane control of OAM

Where there is activity needed at only one place in the network and
instigated from the management plane it can be controlled by:
a. a direct request from the management plane b. an indirect request
from the management plane forwarded
   through the control plane

There is no particular benefit to using the control plane unless the
point where the activity is needed is to be selected dynamically.

Adrian

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Tuesday, March 03, 2009 8:46 AM
Subject: RE: [mpls-tp] MPLS-TP Framework - control plane control of OAM

regards, Neil

---

From: <[email-masked]>
Date: Tue, 3 Mar 2009 14:20:24 -0000

Thanks Malcolm, that sure makes sense to me.  regards, Neil

Malcolm Betts wrote 03 March 2009 14:15
> control of