Subject: Re: [mpls-tp] Is ring protection needed in MPLS-TP?

From: Alexander Vainshtein <[email-masked]>
Date: Tue, 2 Sep 2008 23:28:29 +0300

Rao, Italo and all,
I've added the IETF MPLS-TP list to CC.

I agree with Rao: Ethernet rings (or, to be more specific, rings comprised of IEEE 802.1 bridges) reauire a dedicated "ring protection" scheme because the "generic topology" protection mechanism employed in networks comprised of such devices  (namely, RSTP and its variations) does not meet a topology-agnostic requirement for short service downtime  (even for rings and in spite of "R" in RSTP standing for "rapid":-).

One example of such a scheme can be found in RFC 3619, and another one - in ITU-T G.8032. Since the latter is still in the pre-published state and hence cannot be retrieved from the ITU-T side without a TIES account, I could not compare these two techniques. But AFAIK both schemes follow the "learning bridge" paradigm meaning that FIB entries are learned from the traffic while traffic to unknown destinations is flooded.

MPLS (and, by implication, MPLS-TP) employ a different forwarding paradigm.

Regards,
    Sasha

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of J. Rao Cherukuri
Sent: Tuesday, September 02, 2008 7:50 PM
To: Italo Busi; Malcolm Betts; [email-masked]; Q9 ITU
Cc: Q12 ITU
Subject: RE: Is ring protection needed in MPLS-TP?

Italo,

The requirements for ring protection in Ethernet networks are different from MPLS networks.  I suggest not mixing them.  I have not heard need for MPLS rings.  Only argument is that is used in SDH networks.

Regards
Rao Cherukuri

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Italo Busi
Sent: Tuesday, September 02, 2008 11:31 AM
To: 'Malcolm Betts'; [email-masked]; 'Q9 ITU'
Cc: 'Q12 ITU'
Subject: RE: Is ring protection needed in MPLS-TP?

Malcolm,

the need to support ring protection switching in packet-based networks (Ethernet and T-MPLS in particular) was extensively discussed within Q9/15 before the work on G.8032 and G.8132 started.

As I do not think Q9/15 has changed his mind about the need to support packet ring protection switching, it could be useful to share the arguments and conclusions reached at that time.

I know some of the issues raised on this thread (e.g. physical vs logical rings) were discussed also at that time.

Italo

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Malcolm Betts
Sent: Friday, August 15, 2008 7:45 PM
To: [email-masked]; Q9 ITU
Cc: Q12 ITU
Subject: Is ring protection needed in MPLS-TP?

All, as described in the email copied below, one of the major issues of potential interest to the ITU that was raised during IETF 72 in Dublin is the need for Ring protection in MPLS-TP.  This was clearly identified as a requirement by the ITU during the initial discussions.  However, it received no support at the last IETF meeting.  I suspect that at least part of the reason for the lack of support was that those present did not understand the definition of a Ring in the context of a L2 technology.

If you still consider that ring protection is a requirement for MPLS-TP please respond to this email.  We are in particular interested in gathering input from network operators.  If the response is positive (i.e. a Ring is required) we will need a brief correspondence activity (probably driven by Q.9) to clarify the definition and requirements.

Malcolm Betts
Co chair AH T-MPLS
Phone: +1 613 763 7860 (ESN 393)
email: [email-masked]

    *   From: Loa Andersson <loa at pi.nu<mailto:[email-masked]>>
    *   To: mpls-tp at ietf.org<mailto:[email-masked]>
    *   Date: Fri, 08 Aug 2008 14:44:55 +0200
    *   Subject: [mpls-tp] the discussion on ring protection in Dublin

All,

we had a meeting in Dublin that was attended by members and of the MEAD
team and service providers.

Nurit captured note from the meeting (see below).

The possibly most important discussion in that meeting was on
MPLS ring protection. We asked the service providers whether ring protection were needed in MPLS-TP or not. Of the service providers

present at the meeting there were no one that required that
ring protection is included in MPLS-TP.

We also agreed some time for those service providers that did not
attend the meeting to voice their opinions. This mail is to invite
such opinions.

The decision whether ring protection is in or out will be taken in
early September.

/Loa

-------------------  notes from the meeting  -------------------------
Hi,

My quick take off from the meeting:

1.    There is a requirement for bi-directional LSPs.

a.    It is required that they are co-routed (for simple operation).

b.    We should not preclude non co-routed LSPs (as unidirectional fault
in 1+1 unidirectional protection switching (in case of bi-directional
LSPs) will result in non co-routed LSPs.

2.    uni-directional LSPs should not be precluded (although it was
stated that in many cases bi-directional LSP is set even for real
uni-directional traffic).

3.    50ms is requested basically for the migration from legacy/SDH
networks. This is the value customers are used to and will request for
(pre-condition to move from SDH to packet based networks).

4.    It was indicated that in physical rings it is required to apply
linear protection.

a.    Still we need to re-visit it as I am unsure that we can provide
protection for P2MP LSPs in physical ring topologies using linear
protection.

b.    It was decided to send a 'head up' to the list that since there
was no requirement for a dedicated mechanism for ring protection we
consider to drop the requirement. Italo asked to wait with the decision
until September and it was agreed to wait.

5.    It was indicated that revertive is required and that it serves
better than re-optimization.

I would like to thank the SPs for participating in the meeting.

It is extremely important to have a close dialogue. We need to
understand better the requirements in order to provide the best
solution.

Best regards,

Nurit

--
Loa Andersson

Principal Networking Architect
Acreo AB                           phone:  +46 8 632 77 14
Isafjordsgatan 22                  mobile: +46 739 81 21 64
Kista, Sweden                      email:  loa.andersson at acreo.se
                                           loa at pi.nu

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

---

From: Huub van Helvoort <[email-masked]>
Date: Wed, 03 Sep 2008 00:33:42 +0200

Hi Sasha,

You wrote:

> I agree with Rao: Ethernet rings (or, to be more specific, rings 
> comprised of IEEE 802.1 bridges) reauire a dedicated "ring protection" 
> scheme because the "generic topology" protection mechanism employed 
> in networks comprised of such devices  (namely, RSTP and its variations) 
> does not meet a topology-agnostic requirement for short service downtime 
>  (even for rings and in spite of "R" in RSTP standing for "rapid":-).

That is why we *never* mentioned ethernet ring protection before.
Rao was the first to introduce this topic, and I think it is out
of scope of the MPLS-TP protection discussion.
Even comparing it with ethernet is wrong because Ethernet is CL-PS
and MPLS-TP is CO-PS.

> One example of such a scheme can be found in RFC 3619, and another one - 
> in ITU-T G.8032. Since the latter is still in the pre-published state 
> and hence cannot be retrieved from the ITU-T side without a TIES 
> account, I could not compare these two techniques.

There is no need to retrieve it because it is out of scope.

> But AFAIK both 
> schemes follow the "learning bridge" paradigm meaning that FIB entries 
> are learned from the traffic while traffic to unknown destinations is 
> flooded.
>  

Right, so let us stick to that and avoid confusion.

Regards, Huub.

> Regards,
>     Sasha
>  
>     ------------------------------------------------------------------------
>     *From:* [email-masked] [mailto:[email-masked]] *On
>     Behalf Of *J. Rao Cherukuri
>     *Sent:* Tuesday, September 02, 2008 7:50 PM
>     *To:* Italo Busi; Malcolm Betts; [email-masked]; Q9 ITU
>     *Cc:* Q12 ITU
>     *Subject:* RE: Is ring protection needed in MPLS-TP?
> 
>     Italo,
> 
>      
> 
>     The requirements for ring protection in Ethernet networks are
>     different from MPLS networks.  I suggest not mixing them.  I have
>     not heard need for MPLS rings.  Only argument is that is used in SDH
>     networks.
> 
>      
> 
>     Regards
> 
>     Rao Cherukuri
> 
>      
> 
>     ------------------------------------------------------------------------
> 
>     *From:* [email-masked] [mailto:[email-masked]] *On
>     Behalf Of *Italo Busi
>     *Sent:* Tuesday, September 02, 2008 11:31 AM
>     *To:* 'Malcolm Betts'; [email-masked]; 'Q9 ITU'
>     *Cc:* 'Q12 ITU'
>     *Subject:* RE: Is ring protection needed in MPLS-TP?
> 
>      
> 
>     Malcolm,
> 
>      
> 
>     the need to support ring protection switching in packet-based
>     networks (Ethernet and T-MPLS in particular) was extensively
>     discussed within Q9/15 before the work on G.8032 and G.8132 started.
> 
>      
> 
>     As I do not think Q9/15 has changed his mind about the need to
>     support packet ring protection switching, it could be useful to
>     share the arguments and conclusions reached at that time.
> 
>      
> 
>     I know some of the issues raised on this thread (e.g. physical vs
>     logical rings) were discussed also at that time.
> 
>      
> 
>     Italo
> 
>          
> 
>         ------------------------------------------------------------------------
> 
>         *From:* [email-masked] [mailto:[email-masked]] *On
>         Behalf Of *Malcolm Betts
>         *Sent:* Friday, August 15, 2008 7:45 PM
>         *To:* [email-masked]; Q9 ITU
>         *Cc:* Q12 ITU
>         *Subject:* Is ring protection needed in MPLS-TP?
> 
>         All, as described in the email copied below, one of the major
>         issues of potential interest to the ITU that was raised during
>         IETF 72 in Dublin is the need for Ring protection in MPLS-TP. 
>         This was clearly identified as a requirement by the ITU during
>         the initial discussions.  However, it received no support at the
>         last IETF meeting.  I suspect that at least part of the reason
>         for the lack of support was that those present did not
>         understand the definition of a Ring in the context of a L2
>         technology.
> 
>         If you still consider that ring protection is a requirement for
>         MPLS-TP please respond to this email.  We are in particular
>         interested in gathering input from network operators.  If the
>         response is positive (i.e. a Ring is required) we will need a
>         brief correspondence activity (probably driven by Q.9) to
>         clarify the definition and requirements.
> 
>         Malcolm Betts
>         Co chair AH T-MPLS
>         Picture (Metafile)
>                   o /From/: Loa Andersson <loa at pi.nu
>                     <mailto:[email-masked]>>
>                   o /To/: mpls-tp at ietf.org
>                     <mailto:[email-masked]>
>                   o /Date/: Fri, 08 Aug 2008 14:44:55 +0200
>                   o /Subject/: [mpls-tp] the discussion on ring
>                     protection in Dublin 
> 
>         Picture (Metafile)
>         All,
> 
>         MPLS ring protection. We asked the service providers whether
>         ring protection were needed in MPLS-TP or not. Of the service
>         providers
> 

-- 
================================================================
                   http://www.van-helvoort.eu/
================================================================
Always remember that you are unique...just like everyone else...
_______________________________________________
mpls-tp mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: Stewart Bryant <[email-masked]>
Date: Wed, 03 Sep 2008 10:03:27 +0100

Huub
> Even comparing it with ethernet is wrong because Ethernet is CL-PS

Is this true even when  Ethernet is configured for transport applications?

Stewart

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 3 Sep 2008 11:12:38 +0200

G.8032 on Ethernet Ring Protection works for CL-PS and provides the 50ms
protection switching. 
For the C0-PS (802.1Qay) there is currently no dedicated mechanism for
ring environment. 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Stewart Bryant
Sent: Wednesday, September 03, 2008 12:03
To: Huub van Helvoort
Cc: [email-masked]; Q9 ITU; Q12 ITU; [email-masked]
Subject: Re: [mpls-tp] Is ring protection needed in MPLS-TP?

Huub
> Even comparing it with ethernet is wrong because Ethernet is CL-PS

Is this true even when  Ethernet is configured for transport
applications?

Stewart

---

From: Maarten Vissers <[email-masked]>
Date: Mon, 08 Sep 2008 13:49:42 +0200

Stewart,

Ethernet in transport networks is CO-PS. Each VLAN is to be set up as a
n-port 'connection' (n>=2).
Within such n-port VLAN, forwarding of frames may be performed in either
CL-PS mode (n>2), or in CO-PS mode (n=2). CO-PS based forwarding is
unconditional forwarding of a frame/packet to all output ports of the n-port
connection; i.e. braodcasting/flooding. CL-PS based forwarding is
conditional forwarding of a frame/packet to a subset of the output ports of
the n-port connection.

In theory it is possible to extend MPLS(-TP) with a CL-PS forwarding mode.
As an example you can set up a p2mp MPLS Tunnel LSP and upgrade the switch
fabrics in the P nodes to forward a tunnel LSP packet to only one or more of
the tunnel output ports. Simply read the PW label inside each tunnel LSP
packet at the ingress port and forward each tunnel LSP packet to the tunnel
output port or ports that has/have the PW label value registered.

You could deploy such extended MPLS forwarding capability in TV distribution
applications. Each TV channel is mapped into a PW. All PWs are muxed into a
p2mp tunnel. The p2mp tunnel has its input port at a service edge node and
its output ports on DSLAMs. If the tunnel carries 300 TV channels and each
DSLAM only want to receive a subset of those TV channels, then you can
filter on the basis of PW label value, much like you can filter on MAC
multicast destination address in the case of a p2mp VLAN carrying these 300
TV channels.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Stewart Bryant
Sent: 03 September 2008 11:03
To: Huub van Helvoort
Cc: [email-masked]; Q9 ITU; Q12 ITU; [email-masked]
Subject: Re: [mpls-tp] Is ring protection needed in MPLS-TP?

Huub
>
> Even comparing it with ethernet is wrong because Ethernet is CL-PS and 
> MPLS-TP is CO-PS.

Stewart

---

From: Lucy Yong <[email-masked]>
Date: Mon, 08 Sep 2008 15:52:51 -0500

Maarten,

See below.

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Maarten Vissers
> Sent: Monday, September 08, 2008 6:50 AM
> To: [email-masked]; 'Huub van Helvoort'
> Cc: [email-masked]; 'Q9 ITU'; 'Q12 ITU'; [email-masked]
> Subject: RE: [mpls-tp] Is ring protection needed in MPLS-TP?
> 
> Stewart,
> 
[Lucy:]  This is an enhanced "connection", i.e. different from a
conventional connection definition.
> conditional forwarding of a frame/packet to a subset of the output ports
of
[Lucy:] When n>2, it also needs broadcast/flooding forwarding. So both CL-PS
and CO-PS can apply to N>2. 
> output port or ports that has/have the PW label value registered.
[Lucy:] In this case, a mode indication is needed on each packet, so
forwarding process will check outer label for the packets with unconditional
forwarding mode and will use both outer and inner label for the packets with
conditional forwarding mode. If the connection only has 2 ports,
unconditional forwarding mode is assumed.
Blocking can apply to conditional forwarding mode.
Should we add such connection into MPLS-TP requirement?

---

From: "Diego Caviglia" <[email-masked]>
Date: Tue, 9 Sep 2008 08:37:52 +0200

Lucy, Maarten,
              Apart the discussion about ring protection, that as I said in several e-mails could be left a part for a while, I think that p2mp video distribution could be one of the most interesting application for mpls-tp.

The Alessandro's requirements on which also Julien agreed (please correct me if I'm wrong here) are:

[CUT]
1. MPLS-TP resilience mechanisms for point to multipoint traffic (e.g. video distribution) must be specified 2. MPLS-TP resilience mechanisms for point to multipoint traffic must recover as quick as possible (next step will be to set how fast) [CUT]

FWIW I agree that is a requirement.

BR

Diego

> Of Lucy Yong
> Sent: lunedì 8 settembre 2008 22.53
> To: 'Maarten Vissers'; [email-masked]; 'Huub van Helvoort'
> Cc: [email-masked]; 'Q9 ITU'; 'Q12 ITU'; [email-masked]
> > fabrics in the P nodes to forward a tunnel LSP packet to only one or
> more
> of
> > applications. Each TV channel is mapped into a PW. All PWs are muxed
> into
> a
> Behalf

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 09 Sep 2008 09:43:45 +0200

Diego,

An MPLS-TP network will include a VPLS-TP (i.e. Ethernet VLAN) layer
network. The complete layer stack for MPLS-TP/VPLS-TP is:

      customer/client
-----------------------------  -
|    ETH      | MPLS-TP PW  |  ^
-----------------------------  |
|      MPLS-TP Tunnel       |  |
-----------------------------  |MPLS-TP/VPLS-TP
|      MPLS-TP Section      |  |layer stack
-----------------------------  |
|      Physical Media       |  v
-----------------------------  -

There are now three alternatives to support p2mp traffic for e.g. TV
distribution:
1) Ethernet rooted-multipoint VLAN (VPLS) with each TV channel identified by
a multicast destination address
2) MPLS-TP point-to-multipoint PW (one TV channel per PW)
3) MPLS-TP point-to-multipoint Tunnel with each TV channel identified by a
PW label.

Alterantives 1 and 3 require a single p2mp connection (VLAN/VPLS, tunnel) to
be set up that carries all TV channels. Alternative 2 requires many p2mp
connections (PW) to be set up, each PW carrying one TV channel.

Alternatives 1 and 2 can branch out at S-PE and T-PE nodes located at the
edges of Metro domains. Alternative 3 can branch out at P nodes located
inside the Metro domains, which is an advantage compared to alternatives
1/2.

An other item to be considered in this p2mp TV distribution application is
the question of signle or multi-technology packet transport netowrks. I.e.
will MPLS-TP/VPLS-TP be the signle technology in a carrier network or should
we expect that part of the netowrk is Ethernet based. In the latter case the
p2mp TV channel distribution architecture should be designed with this dual
technology in mind.

Regards,
Maarten

-----Original Message-----
From: Diego Caviglia [mailto:[email-masked]] 
Sent: 09 September 2008 08:38
To: Lucy Yong; Maarten Vissers; [email-masked]; Huub van Helvoort
Cc: [email-masked]; Q9 ITU; Q12 ITU; [email-masked]
Subject: RE: [mpls-tp] Is ring protection needed in MPLS-TP?

Lucy, Maarten,
              Apart the discussion about ring protection, that as I said in
several e-mails could be left a part for a while, I think that p2mp video
distribution could be one of the most interesting application for mpls-tp.

The Alessandro's requirements on which also Julien agreed (please correct me
if I'm wrong here) are:

[CUT]
1. MPLS-TP resilience mechanisms for point to multipoint traffic (e.g. video
distribution) must be specified 2. MPLS-TP resilience mechanisms for point
to multipoint traffic must recover as quick as possible (next step will be
to set how fast) [CUT]

BR

Diego

> Behalf Of Lucy Yong
> > From: [email-masked] [mailto:[email-masked]] On Behalf 
> > Of Maarten Vissers
> > Ethernet in transport networks is CO-PS. Each VLAN is to be set up 
> > as a n-port 'connection' (n>=2).
> > Within such n-port VLAN, forwarding of frames may be performed in 
> > either CL-PS mode (n>2), or in CO-PS mode (n=2). CO-PS based 
> > forwarding is unconditional forwarding of a frame/packet to all 
> > output ports of the
> n-port
> > conditional forwarding of a frame/packet to a subset of the output 
> > ports
> of
> > the n-port connection.
> [Lucy:] When n>2, it also needs broadcast/flooding forwarding. So both 
> CL- PS and CO-PS can apply to N>2.
> >
> > the tunnel output ports. Simply read the PW label inside each tunnel 
> > LSP packet at the ingress port and forward each tunnel LSP packet to 
> > the
> tunnel
> forwarding process will check outer label for the packets with 
> unconditional forwarding mode and will use both outer and inner label 
> for the packets with conditional forwarding mode. If the connection 
> only has 2 ports, unconditional forwarding mode is assumed.
> > p2mp tunnel. The p2mp tunnel has its input port at a service edge 
> > node
> and
> > its output ports on DSLAMs. If the tunnel carries 300 TV channels 
> > and
> each
> > DSLAM only want to receive a subset of those TV channels, then you 
> > can filter on the basis of PW label value, much like you can filter 
> > on MAC multicast destination address in the case of a p2mp VLAN 
> > carrying these
> 300
> > TV channels.
> >
> > Regards,
> > Maarten
> >

---

From: "Di Giglio Andrea" <[email-masked]>
Date: Tue, 9 Sep 2008 09:54:00 +0200

Sorry,
Perhaps, I did not understand.
In Option 3 each TV channel is carried by a single PW or a unique LSP (of course in a PW)?

Regards
Andrea

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Maarten Vissers
Inviato: martedì 9 settembre 2008 9.44
A: 'Diego Caviglia'
Cc: [email-masked]; 'Q9 ITU'; 'Q12 ITU'; [email-masked]
Oggetto: [mpls-tp] p2mp (e.g. video distribution) in MPLS-TP

Diego,

      customer/client

Regards,
Maarten

-----Original Message-----
From: Diego Caviglia [mailto:[email-masked]]
Sent: 09 September 2008 08:38
To: Lucy Yong; Maarten Vissers; [email-masked]; Huub van Helvoort
Cc: [email-masked]; Q9 ITU; Q12 ITU; [email-masked]
Subject: RE: [mpls-tp] Is ring protection needed in MPLS-TP?

Lucy, Maarten,

[CUT]

BR

Diego

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

CONFIDENTIALITY NOTICE

This message and its attachments are addressed solely to the persons above and may contain confidential information. If you have received the message in error, be informed that any use of the content hereof is prohibited. Please return it immediately to the sender and delete the message. Should you have any questions, please contact us by replying to [email-masked].

        Thank you

                                        www.telecomitalia.it

--------------------------------------------------------------------

---

From: Maarten Vissers <[email-masked]>
Date: Tue, 09 Sep 2008 10:08:34 +0200

Andrea,

In option 3 the set of TV channel is carried in one p2mp LSP, and each TV
channel is identified by a unique PW label (e.g. TV channel 1: PW label 101,
TV channel 2: PW label 102, etc.)

Regards,
Maarten

-----Original Message-----
From: Di Giglio Andrea [mailto:[email-masked]] 
Sent: 09 September 2008 09:54
To: 'Maarten Vissers'; 'Diego Caviglia'
Cc: [email-masked]; 'Q9 ITU'; 'Q12 ITU'; [email-masked]
Subject: R: [mpls-tp] p2mp (e.g. video distribution) in MPLS-TP

Sorry,
Perhaps, I did not understand.
In Option 3 each TV channel is carried by a single PW or a unique LSP (of
course in a PW)?

Regards
Andrea

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di
Maarten Vissers
Inviato: martedì 9 settembre 2008 9.44
A: 'Diego Caviglia'
Cc: [email-masked]; 'Q9 ITU'; 'Q12 ITU'; [email-masked]
Oggetto: [mpls-tp] p2mp (e.g. video distribution) in MPLS-TP

Diego,

      customer/client

Regards,
Maarten

-----Original Message-----
From: Diego Caviglia [mailto:[email-masked]]
Sent: 09 September 2008 08:38
To: Lucy Yong; Maarten Vissers; [email-masked]; Huub van Helvoort
Cc: [email-masked]; Q9 ITU; Q12 ITU; [email-masked]
Subject: RE: [mpls-tp] Is ring protection needed in MPLS-TP?

Lucy, Maarten,

[CUT]

BR

Diego

CONFIDENTIALITY NOTICE

This message and its attachments are addressed solely to the persons above
and may contain confidential information. If you have received the message
in error, be informed that any use of the content hereof is prohibited.
Please return it immediately to the sender and delete the message. Should
you have any questions, please contact us by replying to
[email-masked].

        Thank you

                                        www.telecomitalia.it

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 10 Sep 2008 17:26:29 +0100

On 09/09/2008 07:37, "Diego Caviglia" <[email-masked]> wrote:
> distribution) must be specified 2. MPLS-TP resilience mechanisms for point to
> multipoint traffic must recover as quick as possible (next step will be to set
> how fast) [CUT]
> 

In draft-jenkins-mpls-mpls-tp-requirements we currently have

MPLS-TP protection mechanisms MUST be applicable to point-to-point and
SHOULD be applicable to point-to-multipoint transport paths.

And 

MPLS-TP MUST support mechanisms that rapidly detect, locate, notify and
remedy network faults.

Do they already cover the above?

Ben