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

From: "BOCCI Matthew" <[email-masked]>
Date: Tue, 3 Mar 2009 15:41:27 +0100

Thanks all

The specific requirements are much clearer now.

Matthew
Matthew

----- Original Message -----
From: [email-masked] <[email-masked]>
To: [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>; [email-masked] <[email-masked]>
Cc: [email-masked] <[email-masked]>
Sent: Tue Mar 03 15:20:24 2009
Subject: Re: [mpls-tp] MPLS-TP Framework - control plane control of OAM

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

Malcolm Betts wrote 03 March 2009 14:15
> 
> 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
> 
> 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
> 
> 
> 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
> >
> > 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.
> 
> 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).
> 
> > 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.
> 
> 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.*
> 
> > 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.
> 
> 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
> 
> >
> > 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
> >
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of Adrian Farrel
> > > Sent: Tuesday, March 03, 2009 2:40 AM
> > > To: BOCCI Matthew
> > > Cc: [email-masked]
> > > Subject: Re: [mpls-tp] MPLS-TP Framework - control plane 
> control of
> > > OAM
> > >
> > > 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,
> > >
> > > 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
> > > >
> > > >
> > >
> > > _______________________________________________
> > > 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
> >
> > _______________________________________________
> > 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
> 
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

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

Thanks Matthew......but can I check a key related point here with you
please as one of the editors of draft-ietf-mpls-tp-gach-gal-02?
 
You will have noted from several of my posts that I am not happy with
the DP OAM residing under the GAL (in draft-ietf-mpls-tp-gach-gal-02)
for 2 reasons:
-    we should have a very clear seperation of CP/MP and DP
protocols.....and defect detecting/handling OAM is for sure part of the
DP, so it should not appear under the GAL as that should only be used by
the CP/MP protocols
-    the DP OAM and DP traffic need to have identical headers....this is
currently not the case as the DP OAM resides under the GAL and thus has
a different header structure to normal DP traffic.
 
I am aware that Stewart has issued draft-bryant-pwe3-packet-pw-00.txt
(although its not clear to me if this has been discussed in the MPLS-TP
team yet or not).  Now whilst I do not consider this a good solution for
the DP traffic encapsulation (for a few reasons) this is where the 'OAM
indicate' flag needs to reside, and not under the GAL.  So this issue
needs fixing in the MPLS-TP design team. 
 
Can you assure me this will happen?
 
regards, Neil
 
________________________________

From: BOCCI Matthew [mailto:[email-masked]] 
Sent: 03 March 2009 14:41
To: Harrison,N,Neil,CXM R; [email-masked]; [email-masked];
[email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [mpls-tp] MPLS-TP Framework - control plane control of OAM

	Thanks all

	Matthew
	Matthew
	
	----- Original Message -----
	From: [email-masked] <[email-masked]>
	To: [email-masked] <[email-masked]>; [email-masked]
<[email-masked]>; [email-masked]
<[email-masked]>; [email-masked]
<[email-masked]>
	Cc: [email-masked] <[email-masked]>
	Sent: Tue Mar 03 15:20:24 2009
	Subject: Re: [mpls-tp] MPLS-TP Framework - control plane control
of OAM

	> From: [email-masked]
[mailto:[email-masked]] On

---

From: Loa Andersson <[email-masked]>
Date: Tue, 03 Mar 2009 16:53:42 +0100

Neil,

concerning drafts that has been discussed in the MEAD team (I guess
that is what you mean by MPLS-TP team, all other discussion are fully
public).

There are a number of draft that we decided that we wanted to include
in the MEAD team coordination (mostly to have a good document flow, and
the right things decided first).

The tentative list of these documents are found at:

http://www.tla-group.com/~loa/editor-doc-list.pdf

We have not published first versions of all these drafts yet, we
are actually reluctant that all of them are needed. The rules for
these documents is that the MEAD team will discuss them once they
are published.

Other documents, like the draft-bryant-pwe3-packet-pw-00.txt are
individual drafts and could be published as and when the authors
decide to publish.

Now for a specific draft two different things could generally happen:

- the MEAD team thinks it is a MPLS-TP draft and want to include
   it in what the MEAD team coordinates
- the MEAD team might say that this is not a MPLS-TP draft and that
   any working group might progress it as it see fit

I've no indication that the authors or any members of the MEAD team
thinks that draft-bryant-pwe3-packet-pw-00.txt should be coordinated
by the MEAD. And consequently we have not discussed the document.
If or when I see such a request I will poll the MEAD to see what is
the consensus of the MEAD team.

There are no requirements, as long as the appointed editors for the
documents in the list above agree to publish, to discuss with the
MEAD before publishing.

All other documents, when first published, are solely the responsibility
of the authors (IETF speak: individual drafts).

If you want an overview of the documents that is currently under
MEAD team coordination, please have a look at:

http://wiki.tools.ietf.org/misc/mpls-tp/

/Loa

[email-masked] wrote:
> ------------------------------------------------------------------------
> *From:* BOCCI Matthew [mailto:[email-masked]]
> *Sent:* 03 March 2009 14:41
> *To:* Harrison,N,Neil,CXM R; [email-masked]; [email-masked]; 
> *Cc:* [email-masked]
> *Subject:* Re: [mpls-tp] MPLS-TP Framework - control plane control of OAM
> 
>     Thanks all
> 
> ------------------------------------------------------------------------
> 

-- 

Loa Andersson

Sr Strategy and Standards Manager
Ericsson ///                          phone:  +46 8 632 77 14

                                       email:  [email-masked]
                                               [email-masked]
                                               [email-masked]

---

From: Loa Andersson <[email-masked]>
Date: Tue, 03 Mar 2009 16:59:32 +0100

All,

I should live according to rules I try to force others to live
by; this is the same mail as earlier, but with a new subject line.

/Loa

Loa Andersson wrote:
>> protocols.....and defect detecting/handling OAM is for sure part of 
>> the DP, so it should not appear under the GAL as that should only be 
>> used by the CP/MP protocols
>> -    the DP OAM and DP traffic need to have identical headers....this 
>> is currently not the case as the DP OAM resides under the GAL and thus 
>> has a different header structure to normal DP traffic.
>>  
>> (although its not clear to me if this has been discussed in the 
>> MPLS-TP team yet or not).  Now whilst I do not consider this a good 
>> solution for the DP traffic encapsulation (for a few reasons) this is 
>> where the 'OAM indicate' flag needs to reside, and not under the GAL.  
>> So this issue needs fixing in the MPLS-TP design team.  

-- 

Loa Andersson

---

From: <[email-masked]>
Date: Tue, 3 Mar 2009 19:34:07 -0000

Many thanks Loa for the process clarifications and document information.
But I need a little further help here:

> > by the MEAD. And consequently we have not discussed the document.

However, its says in the introduction of
draft-bryant-pwe3-packet-pw-00.txt:

"The server MPLS network may be a "classic" MPLS network or an MPLS-TP
network [RFC5317].  The client may also be either a "classic" MPLS
network of an MPLS-TP network.  Considerations as to whether an MPLS
"classic" network can act as a server for an MPLS-TP network are outside
the scope of this document."

And it then goes on to propose what the DP traffic encapsulations should
look like.....which essentially has the generic 4-byte CW followed by a
2-byte PPP-based PID.  Now AFAIK this is something new which has
primarily been motivated by MPLS-TP....as indeed the extract taken from
the introduction given above would seem to indicate.  IMO I further
assume this is the proposed DP encapsulation for all MPLS-TP clients.
But maybe the authors can clarify that please.

If my assumption is correct then it would seem important for the MEAD
team to consider this document....which brings me to my second point:

2	Unless we know what *both* the proposed (i) CP/MP protocol
encapsulation and (ii) DP encapsulation is for MPLS-TP we are working in
the dark.  However, irrespective of this I am making two quite clear
recommendations to the MEAD team here:
-	that the packets carrying CP/MP protocols are very clearly
differentiated from the packets carrying DP traffic and DP OAM 
-	that the header of the DP OAM is identical to the traffic units
of the DP it monitoring....which means:
	* the DP OAM must not appear under the GAL...as this has a
different header structure to MPLS-TP DP traffic (assuming this is what
is in draft-bryant-pwe3-packet-pw-00.txt)
	* that the 'OAM indicate' flag must be in the normal DP
encapsulation (assuming this is what is in
draft-bryant-pwe3-packet-pw-00.txt)

I believe these are sensible (even obvious IMO) technical
recommendations that no one could dispute, so I want to be sure the MEAD
team will address them.

Wrt to any further comments to draft-bryant-pwe3-packet-pw-00.txt these
can be taken later.  But I would like clear clarification on the above
points for now.

regards, Neil

> From: Loa Andersson [mailto:[email-masked]] 
> Sent: 03 March 2009 16:00
> To: Harrison,N,Neil,CXM R
> Cc: [email-masked]; [email-masked]
> Subject: when the MEAD team discusses new documents (Was: Re: 
> [mpls-tp] MPLS-TP Framework - control plane control of OAM)
> 
> All,
> 
> >>      > must be supported by signalling. An operator may 
> choose not use 
> >> this
> >>      > Where there is activity needed at only one place in 
> the network 
> >> and
> >>      > a. a direct request from the management plane b. an 
> indirect 
> >> request
> >>      > created/configured (because they are indeed a 
> construct in a 
> >> network)
> >>      > CV flows not activated immediately on LSP set-up) 
> or we will 
> >> generate
> >>      > monitoring since OAM has to be as simple and sparse 
> as possible 
> >> with
> >>      > minimum configuration....because it must be super 
> reliable.  It
> >>     is one
> >>      > > > 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
> >>      > > > >    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