Subject: Re: [mpls-tp] Issues on the draft-ietf-mpls-tp-linear-protection

From: "Amir Halperin" <[email-masked]>
Date: Tue, 6 Apr 2010 14:39:47 +0300

RFC 4427 and draft-ietf-mpls-tp-linear-protection depicts manual
commands in general. I suggest that the linear protection draft will
define the protection state machine that includes manual commands as it
defined in G.8031.

Amir Halperin
mailto:[email-masked]
-----Original Message-----
From: Adrian Farrel [mailto:[email-masked]] 
Sent: Monday, March 29, 2010 10:33 AM
To: Amir Halperin; Sprecher, Nurit (NSN - IL/Hod HaSharon)
Cc: [email-masked]
Subject: Re: [mpls-tp] Issues on the
draft-ietf-mpls-tp-linear-protection

Amir,

You're right. We need to also allow manual command.

Of course, RFC 4872 is the wrong place to look for a description of such

commands since it defines RSVP-TE extensions for end-to-end recovery.

Can you check RFC 4427 (section 4.13) and draft-ietf-mpls-tp-survive-fwk
to 
make sure that they cover all of the manual commands you would hope to
see.

Thanks,
Adrian
----- Original Message ----- 
From: "Amir Halperin" <[email-masked]>
To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
Cc: <[email-masked]>
Sent: Sunday, March 28, 2010 3:14 PM
Subject: Re: [mpls-tp] Issues on the
draft-ietf-mpls-tp-linear-protection

Hi Nurit.

I think we should also consider manual commands e.g. manual-switch,
force-switch, lockout, that are defined in APS and currently not in
http://tools.ietf.org/html/rfc4872.

As far as I know, transport operators that consider MPLS-TP, expect to
receive such manual commands logic.

What do you think?

Amir Halperin
mailto:[email-masked]

________________________________

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Sprecher, Nurit (NSN - IL/Hod HaSharon)
Sent: Friday, March 26, 2010 5:34 PM
To: Ryoo, Jeong-dong; [email-masked]
Subject: Re: [mpls-tp] Issues on the
draft-ietf-mpls-tp-linear-protection

Hi Jeong-dong,

Thanks for your comments! It is much more efficient to address comments
and they are very welcome.

We will go over the comments, and see how they can be addressed. I am
sure we will come back with question, comments, etc.

I am happy to see that my observation was adopted..but please note that
in GMPLS we also have a working and proven mechanism for end-to-end and
segment protection, 1:n and mesh protection.

In principle we can use these mechanisms. What we miss in MPLS-TP is a
tool that allows the endpoints of the protection domain to coordinate
the protection state without being dependent on the presence of a
control plane.......so we basically need to define a protocol message
that can be sent inband...

We have a few options which were presented in the presentation of Yaacov
and we are very open to discuss it.

There is another question whether we want to have a single phase or two
phase protocol (which can easily be extended to support 1:n).......

Any feedback and comment will be appreciated.

Best regards,

Nurit

From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Ryoo, Jeong-dong
Sent: Friday, March 26, 2010 3:10 AM
To: [email-masked]
Subject: [mpls-tp] Issues on the draft-ietf-mpls-tp-linear-protection

Dear authors and all,

This email summarizes issues identified in
draft-ietf-mpls-tp-linear-protection-00. As I heard from other experts,
some of these issues had been raised but not been addressed yet.

1. Improper use of unavailable concept:

a. The use of the term unavailable is misleading and confusing with the
unavailability used for Performance Management in ITU-T.

b. The association to SD condition with unavailability is not correct
also considering that the SD condition is not yet defined.

c. The definition of this status is ambiguous in case of SF on the
working and SD on the protection.

2. Target to produce a protocol for protection switching coordination
that is simpler than the already existing and proven APS protocol (as
described in draft-zulr-mpls-tp-linear-protection-switching) and more
open to support future extensions (e.g., 1:n architecture) is not
achieved.

a. Comparing the fields of PSC (as proposed in
draft-ietf-mpls-tp-linear-protection-00) and APS (as described in
draft-zulr-mpls-tp-linear-protection-switching) packets to be processed
by the respective protocols (both working in 1-phase), we can compare:

- PSC [4 bytes]:

3 fields/20 bits [REQUEST / FPATH /PATH], with correlation between
REQUEST and FPATH;

4 bits, with further fields of "Ver" as version, "Type" as protection
type information;

1 byte with "Reserved" field.

- APS [4 bytes] "tentatively":

3 fields/20 bits [REQUEST / REQUESTED SIGNAL / BRIDGED SIGNAL], with no
correlation;

4 bits, with further fields of "Protection Type";

1 byte "Version" & "Reserved" fields.

It is not clear if there is any actual advantage of PSC comparing to the
APS.

b. With 1:1 and (1:1)^n, the protocol can work in one phase, so defining
an explicit code for the SF-P in Request field (and not using the FPATH)
is enough for handling the switching conditions.

c. With 1:n, the protocol must work in two phases in order to handle the
protection switching and avoid misconnections in case when a pre-emption
of currently operated switch occurs due to an higher priority trigger on
a different working channel. Thus, the need for a Requested signal field
and a Bridged signal field, carrying respectively the Channel ID for
which the connection to the protection resource is requested, and the
Channel ID actually connected to the protection resource. This
information exchange is required regardless of the type of protection
switching triggers (fault, state or user commands).

FPATH field is currently thought to indicate just a fault condition on
the addressed channel, which is not enough.

Therefore using the REQUEST and REQUESTED SIGNAL fields as in draft-zulr
is more efficient and extensible to future functions like (1:1)^n and
1:n.

3. SF condition on recovery path is detected after a correlation between
the values in the Request and FPath fields in the received PSC message.
This correlation is a complication comparing to explicitly associated
Bridge Request code (as in draft-zulr).

SF on the protection path should be included in the Request code. SF on
the protection path should have higher priority than the Forced switch
and lower than the Lockout of protection.

4. One principle of the operation in
draft-ietf-mpls-tp-linear-protection-00 that can be observed is that two
ends send the same type of PSC packet even if their local
requests/states are different. This could result in deadlock situation

a) In case of unidirectional switching triggers, the reply message sent
by the far end should be different from the protection switching code
send by the source. This is required to allow a reliable revert switch
(in case of failure/degrade) and a reliable clearing of commands (in
case of operator commands) without causing the deadlock condition.

Example:

- A unidirectional failure detected and finally recovered at node A.

- Node A starts the WTR timer and sends the WTR message.

- Upon receiving the WTR message, node Z also sends WTR message.

- The WTR timer expires. Node A sends NR message.

- If a WTR message was generated from node Z before node Z processes the
NR message, node A goes into WTR state and generates WTR message.

- Now two nodes are in WTR state forever...

Or even in the first WTR message generation, if an SF message arrives
from far end, which does not have a local SF, WTR will be cancelled and
SF message will be generated. Then, two ends will be in SF forever.

b) Similar to the above issue, in case of a bidirectional failure, if
the WTR timers of two ends expire at different times, the same deadlock
could occur.

c) When two WTR timers expire at the same time but there is outdated WTR
message due to the very short period of time between WTR message
generation and WTR timer expiration.

The aforementioned deadlock can also occur in clearing operator's
commands.

Without changing the principles of the operations, it will most likely
end up with a new complicated protocol. Like more phases would be
needed, a mechanism to ignore an outdated message would be needed, and
some exceptional handlings should be added and so on.

As Nurit stated in her previous email on ring protection, we need good
justifications to define a new mechanism/technology.

Why do we need to develop a new technology while there is the technology
that is proven by deployment for more than the last ten years in
transport networks? And I don't think "Not Invented Here" approach is so
desirable.

Best regards,

Jeong-dong

==============================================
Jeong-dong Ryoo, Ph.D.
Principal Member of Research Staff
Network Research Department
Electronics and Telecommunications Research Institute (ETRI)
Phone: +82-42-860-5384, Fax: +82-42-860-6342
Email: [email-masked] <mailto:[email-masked]>
==============================================

<http://umail.etri.re.kr/External_ReadCheck.aspx?email=[email-masked]&
name=mpls-tp%40ietf.org&fromemail=[email-masked]&messageid=%3Cc570bc1b-
[email-masked]%3E>

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

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

---

From: Huub van Helvoort <[email-masked]>
Date: Tue, 06 Apr 2010 14:06:54 +0200

Hello Amir,

> define the protection state machine that includes manual commands as it

This is also proposed in
http://www.ietf.org/id/draft-zulr-mpls-tp-linear-protection-switching-00.txt

Regards, Huub.

-- 
================================================================
Always remember that you are unique...just like everyone else...