Subject: [Mpls-interop] FRR in MPLS-TP

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Wed, 22 Oct 2008 23:22:43 +0200

Hi,

Coming to an old issue that I presented but not sure if it was concluded
:-)

We have requirement in MPLS-TP for bi-directional protection switching. 

While I can see a potential solution for 1:1 FRR (as we protect each LSP
independently), it looks to me harder to have a solution for 1:N FRR in
the general case where the bypass tunnel bypasses more than the next
link. 

Any view of whether FRR can be implemented for bi-directional protection
switching?

Can we provide a solution for the specific case where the bypass tunnel
bypasses the next link (like in the case of a ring where we can monitor
the spans/section layer? In such a case we could have a bypass tunnel to
protect against a link failure but a fundamental requirement is that we
can support bi-directional protection switching)

Best regards,

Nurit

----------------------------------------- 
Best regards, 

Nurit Sprecher

Nokia Siemens Networks GmbH & Co. KG 
Industry Environment

Senior Specialist, Carrier Ethernet Transport

3 Hanagar St. Neve Ne'eman B

45241 Hod Hasharon, Israel

Tel. +972 9 7751229

Mobile +972 54 2200954 
Email: [email-masked] <BLOCKED::mailto:[email-masked]> 

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

---

From: "Adrian Farrel" <[email-masked]>
Date: Fri, 24 Oct 2008 21:18:40 +0100

Hi Nurit,

The good news is that it "just works" although no-one will have built it 
yet.

> We have requirement in MPLS-TP for bi-directional protection switching.

And I think you mean something more than "rotecting bidireciotnal LSP" :-)

> the general case where the bypass tunnel bypasses more than the next

I believe 1:N will work just fine as well.

It may turn out to be hard to configure and operate, but that is *laways* 
the case for 1:N protection in any protection scheme.

> Any view of whether FRR can be implemented for bi-directional
> protection switching?

Sure, why not? If the bypass tunnel is bidirectional, the only issue is the 
coordination of the failover.

> Can we provide a solution for the specific case where the
> bypass tunnel bypasses the next link (like in the case of a
> ring where we can monitor the spans/section layer? In
> such a case we could have a bypass tunnel to protect
> against a link failure but a fundamental requirement is that
> we can support bi-directional protection switching)

I don't see any issues.

Also I don't see that rings are in any way special. We would expect to be 
able to monitor spans/sections in any network topology. Similarly to protect 
one or more hops with the bypass tunnel.

The only issue reamins the coordination of the switchover for bidirecitonal 
switching. In an abstract sense, this is clearly articulated in the RFC 
4426/7/8 series.

Bye,
Adrian

---

From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Date: Sun, 26 Oct 2008 01:18:44 +0200

Hi Adrian,
Thanks for your response. 
Well, indeed I referred for the coordination issue of the switchover for
bidirecitonal switching (see previous e-mails of mine on this topic). 
Assuming that we have a protocol like APS, which can signal a
uni-directional fault to the remote side, still the PLR needs to
identify which of the LSPs are affected from this failure, or for which
LSPs protection switching has been performed at the remote peer, etc.
For the general case, it means that we need APS channel per bypass
tunnel and we need to know which LSPs are protected by the bypass tunnel
from which  we get the APS message......
Best regards,
Nurit

-----Original Message-----
From: ext Adrian Farrel [mailto:[email-masked]] 
Sent: Friday, October 24, 2008 22:19
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); MEAD team
Cc: Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Subject: Re: [Mpls-interop] FRR in MPLS-TP

Hi Nurit,

yet.

> We have requirement in MPLS-TP for bi-directional protection
switching.

And I think you mean something more than "rotecting bidireciotnal LSP"
:-)

It may turn out to be hard to configure and operate, but that is
*laways* 
the case for 1:N protection in any protection scheme.

> Any view of whether FRR can be implemented for bi-directional

Sure, why not? If the bypass tunnel is bidirectional, the only issue is
the 
coordination of the failover.

I don't see any issues.

Also I don't see that rings are in any way special. We would expect to
be 
able to monitor spans/sections in any network topology. Similarly to
protect 
one or more hops with the bypass tunnel.

The only issue reamins the coordination of the switchover for
bidirecitonal 
switching. In an abstract sense, this is clearly articulated in the RFC 
4426/7/8 series.

Bye,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 26 Oct 2008 00:58:22 +0100

Hi,

Sorry, I thought you were referring to lack of MIB support.

The way this works in GMPLS is that the point of fault detection (if it is 
not the PLR) sends a message to the PLR to tell it to switch over (noting 
that in the bidirectional case the MP is the PLR for the reverse direction 
and will also need to be told). Please note that if you are running OAM, the 
point of fault detection might not be local to the fault, and there is 
nothing to assume that the OAM message that detects the fault is the same or 
different from the switchover message.

Various optimizations are possible to prevent sending a single message for 
each LSP that must switchover. But it will need to always be possible to 
send such a message for a single LSP. This is handled in GMPLS by allowing 
one switchover message to list multiple LSPs.

Another way to cut this is to send a message that reports the failed 
resource. In this case, the PLR must scan all of the LSPs it knows about to 
see which use the failed resource. Easy if the resource is local, much 
harder if the resource is downstream, and this is why in GMPLS we chose to 
report the list of LSPs to the PLR from the node that detected the fault.

Note that the GMPLS function requires that the PLR is known for each LSP, 
and this is included in the signaling.

Oh, and also note that GMPLS signaling for switchover is directed and does 
not assume that the control plane is out-of-band. Specifically, the GMPLS 
message could be sent in band. (No doubt it is still possible to have an 
argument based upon GMPLS being a control plane protocol and MPLS-TP being 
able to operate in the absence of a control plane. *If* anyone cares to 
bring this up again I will continue to assert that any OAM protocol, and 
specifically any APS protocol, is a control protocol.)

Cheers,
Adrian

----- Original Message ----- 
From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
To: "Adrian Farrel" <[email-masked]>; "MEAD team" 
<[email-masked]>
Cc: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <[email-masked]>
Sent: Sunday, October 26, 2008 12:18 AM
Subject: RE: [Mpls-interop] FRR in MPLS-TP

Hi Adrian,

-----Original Message-----
From: ext Adrian Farrel [mailto:[email-masked]]
Sent: Friday, October 24, 2008 22:19
To: Sprecher, Nurit (NSN - IL/Hod HaSharon); MEAD team
Cc: Weingarten, Yaacov (NSN - IL/Hod HaSharon)
Subject: Re: [Mpls-interop] FRR in MPLS-TP

Hi Nurit,

yet.

I don't see any issues.

Bye,
Adrian

---

From: <[email-masked]>
Date: Tue, 28 Oct 2008 15:43:05 +0100

Hi.

Adrian, allow me to bring it up again: "any OAM protocol, and
specifically any APS protocol, is a control protocol"

I completely agree on that. APS is the typical example I use to teach
transmission people they've been using a control plane for a long time,
just without naming it this way...

Unfortunately, I fear that ITU-T and marketing might use the phrase
"control plane" differently. [By the way, this O in ASON means
"Optical": not so sure that G.8080 applies to packet technologies.] It
may read crazy, but I believe that one of the MPLS-TP document
(Huub/Adrian's lexicography?) should recall what IETF mean by "control
plane": I would say something like "messages exchanged by nodes to be
able to convey traffic", but in fact it appears that, even among us, we
often use the term to refer to control minus OAM (it's shorter than
"topolology distribution and LSP signaling" actually targeted by
original intentions in requirements)...

Regards,

Julien

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Adrian Farrel

Hi,

The way this works in GMPLS is that the point of fault detection (if it
is 
not the PLR) sends a message to the PLR to tell it to switch over
(noting 
that in the bidirectional case the MP is the PLR for the reverse
direction 
and will also need to be told). Please note that if you are running OAM,
the 
point of fault detection might not be local to the fault, and there is 
nothing to assume that the OAM message that detects the fault is the
same or 
different from the switchover message.

Various optimizations are possible to prevent sending a single message
for 
each LSP that must switchover. But it will need to always be possible to

send such a message for a single LSP. This is handled in GMPLS by
allowing 
one switchover message to list multiple LSPs.

Another way to cut this is to send a message that reports the failed 
resource. In this case, the PLR must scan all of the LSPs it knows about
to 
see which use the failed resource. Easy if the resource is local, much 
harder if the resource is downstream, and this is why in GMPLS we chose
to 
report the list of LSPs to the PLR from the node that detected the
fault.

Note that the GMPLS function requires that the PLR is known for each
LSP, 
and this is included in the signaling.

Oh, and also note that GMPLS signaling for switchover is directed and
does 
not assume that the control plane is out-of-band. Specifically, the
GMPLS 
message could be sent in band. (No doubt it is still possible to have an

argument based upon GMPLS being a control plane protocol and MPLS-TP
being 
able to operate in the absence of a control plane. *If* anyone cares to 
bring this up again I will continue to assert that any OAM protocol, and

Cheers,
Adrian

----- Original Message ----- 

Hi Adrian,

-----Original Message-----

Hi Nurit,

yet.

I don't see any issues.

Bye,
Adrian

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 28 Oct 2008 14:58:41 -0000

Hi Julien,

I'm in complete agreement with you agreeing with me :-)

ASON is being re-cast as ASTN (T is for transport). G.8080 will apply 
equally to all transport networks.

IMHO, the problem comes from implementation where (for obvious reasons) OAM 
has been handled in hardware not in software. For many people, hardware = 
data plane. Don't know where that leaves us when we implement the control 
plane on a network processor, or when we do some part of the control plane 
function (like protocol keepalive processing) in hardware.

Maybe all a bit academic.

However, in selecting an OAM solution for MPLS-TP we should not rule out one 
message exchange or another simply because of the protocol family it 
historically comes from.

A
----- Original Message ----- 
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Tuesday, October 28, 2008 2:43 PM
Subject: RE: [Mpls-interop] FRR in MPLS-TP

Hi.

Regards,

Julien

-----Original Message-----

Hi,

Cheers,
Adrian

----- Original Message ----- 

Hi Adrian,

-----Original Message-----

Hi Nurit,

yet.

I don't see any issues.

Bye,
Adrian