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

From: 류정동 <[email-masked]>
Date: Sat, 27 Mar 2010 03:25:08 +0900

Isn't it the GMPLS Notify message for the PSC PDU format?
Please, let me know the place where GMPLS does linear "protection" switching, not a framework but actual mechanism.

Thanks,

Jeong-dong

-----원본 메시지-----
From: "John E Drake" <[email-masked]>
From Date: 2010-03-27 오전 2:41:13
To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>, "Ryoo, Jeong-dong" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc:
Subject: RE: [mpls-tp] Issues on the draft-ietf-mpls-tp-linear-protection

Nurit,

Snipped...

>
> 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.
[JD]

That's correct, although for some reason some people don't seem to understand this.

>
> 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...
[JD]

That's correct, and as you mentioned in the meeting, one option is to simply to place the existing GMPLS control plane tool, the Notify message, within the OAM channel.

---

From: John E Drake <[email-masked]>
Date: Fri, 26 Mar 2010 12:41:01 -0700

RFC 4872/4873, I think.  If not, just check the CCAMP RFC list.

Sent from my iPhone

On Mar 26, 2010, at 11:25 AM, "류정동" <[email-masked]<mailto:[email-masked]>> wrote:

Thanks,

Jeong-dong

-----원본 메시지-----
From: "John E Drake" <[email-masked]<mailto:[email-masked]>>
From Date: 2010-03-27 오전 2:41:13
To: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]<mailto:[email-masked]>>, "Ryoo, Jeong-dong" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc:
Subject: RE: [mpls-tp] Issues on the draft-ietf-mpls-tp-linear-protection

Nurit,

Snipped...

[JD]

[JD]

---

From: "Ryoo, Jeong-dong" <[email-masked]>
Date: Mon, 29 Mar 2010 10:50:39 +0900

Nurit,

I just returned after a long flight over pacific ocean.

We definetly need the least number of phases for faster protection switching.

By adding another phase, it introduces another round of delay in protection switching time.

1:n needs at least two phases by following the operation principle of APS.
If PCS comes up with one phase even for 1:n, it will be a big improvement in the area of protection switching technology.
However, 1:n in packet transport network doesn't make much sense.
(1:1)^n would be better for protecting n working paths with 1 protection path.
1:n just adds more complexity without providing a significant benefit over (1:1)^n.

For 1:1/1+1, APS does the switching in one phase,
I would like to expect PSC can also do it without adding more phases, but in a simple and efficient way.

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]
==============================================

-----Original Message-----
From: "Sprecher, Nurit (NSN - IL/Hod HaSharon)" <[email-masked]>
From Date: 2010-03-26 PM 11:33:44
To: "Ryoo, Jeong-dong" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc:
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]
==============================================