Re: [mpls-tp] [mpls] Comments on draft-ietf-mpls-tp-linear-protection-06.txt

"Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <yaacov.weingarten@nsn.com> Thu, 17 March 2011 13:12 UTC

Return-Path: <yaacov.weingarten@nsn.com>
X-Original-To: mpls-tp@core3.amsl.com
Delivered-To: mpls-tp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06D233A695E; Thu, 17 Mar 2011 06:12:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NzWD3ldQYSms; Thu, 17 Mar 2011 06:12:30 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 630083A6950; Thu, 17 Mar 2011 06:12:29 -0700 (PDT)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p2HDDp9Y009889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 17 Mar 2011 14:13:51 +0100
Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p2HDDkWg010694; Thu, 17 Mar 2011 14:13:51 +0100
Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Mar 2011 14:13:50 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CBE4A5.281092BA"
Date: Thu, 17 Mar 2011 14:13:45 +0100
Message-ID: <E4873516F3FC7547BCFE792C7D94039C0F8FA5@DEMUEXC013.nsn-intra.net>
In-Reply-To: <E13C8C03049AFA4E9CEE5A21D3E7F85D020DE13549@GUREXMB02.ASIAN.AD.ARICENT.COM>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [mpls] Comments on draft-ietf-mpls-tp-linear-protection-06.txt
Thread-Index: AcvkeK8hutvfRZeXSZymrltxfoQJoAACOzwgAAZzYNA=
References: <E13C8C03049AFA4E9CEE5A21D3E7F85D020DE13549@GUREXMB02.ASIAN.AD.ARICENT.COM>
From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <yaacov.weingarten@nsn.com>
To: ext Lavanya Srivatsa <lavanya.srivatsa@aricent.com>, MPLS TP <mpls-tp@ietf.org>, mpls@ietf.org
X-OriginalArrivalTime: 17 Mar 2011 13:13:50.0697 (UTC) FILETIME=[284B9590:01CBE4A5]
Subject: Re: [mpls-tp] [mpls] Comments on draft-ietf-mpls-tp-linear-protection-06.txt
X-BeenThere: mpls-tp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: MPLS-TP Mailing list <mpls-tp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls-tp>, <mailto:mpls-tp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls-tp>
List-Post: <mailto:mpls-tp@ietf.org>
List-Help: <mailto:mpls-tp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls-tp>, <mailto:mpls-tp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 17 Mar 2011 13:12:42 -0000

Lavanya, hi

 

See my comments below

 

Hope this helps

BR,

yaacov

 

From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of ext Lavanya Srivatsa
Sent: Thursday, March 17, 2011 11:16 AM
To: MPLS TP; mpls@ietf.org
Subject: [mpls] Comments on draft-ietf-mpls-tp-linear-protection-06.txt

 

To the authors,

 

I have a list of protection switching scenarios that do not seem to result in expected behaviour if operating as per this draft. I have proposed solutions/alternate text. I would appreciate your comments/confirmation on the same.

 

Scenario 1

Assume that there is a revertive protection switching group set up between routers R1 and R5 for working LSP1 and protection LSP2 

 

[Sequence of events] 

Both R1 and R5 in Normal state à SF on R1 à FS on R5 à FS clear on R5

[Result] 

Both R1 and R5 going to Normal state with NR(0,0)

[Problem] 

The above is an incorrect state on R1 since the local Signal Fail still exists and has not been cleared. So R1 should have moved back to the local Protecting Failure state transmitting SF(1,1) instead of going to the NR(0,0) state.

 

yw>  First off see in the comment resolution, row#80.  

To explain more fully - you just stopped your scenario one step too soon - When R1 returns to Normal state it will then immediately receive the SF indication and go into Protecting Failure.  In essence, as pointed out in the comment in row #80 of the LC comments the state machine dictates that you transition through Normal to arrive at the Protecting failure state.

This was done in order to simplify the protocol and the state machine - as you can see from the LC comments there are several other of these scenarios and if we wanted to cover every possible scenario it would greatly complicate the state machine with different levels of conditions that would need to be checked.  What you are suggesting is an optimization that you could implement, but we (after discussing this and other scenarios) opted for the simplicity of the protocol.

[Suggested Solution] 

In Section 4.3.3.3, the 2nd last bullet item under remote messages needs to be modified as - "A remote NR(0,0) message SHALL be ignored if in local Protecting administrative state.  If in remote Protecting administrative state then the LER SHALL go to Normal state and begin transmitting a NR(0,0) message OR shall go to the local Protecting Failure state if local Signal Failure is still reasserted and begin transmitting SF(1,1).

 

Scenario 2

Assume that there is a non-revertive protection switching set up between routers R1 and R5 for working LSP1 and protection LSP2.

 

[Sequence of events] 

Both R1 and R5 in Normal state à SF on R1 à SF clear on R1 à FS on R1 à FS clear on R1

[Result] 

Both R1 and R5 going to Normal state with NR(0,0)

[Problem] 

Upon clearing the Forced Switch at R1, it is expected to go local Do-Not-Revert state again and begin transmitting DNR(0,1). Upon receiving this R5 is expected to go to remote Do-Not-Revert state.

 

yw> I do not agree that the domain should transition back to DNR state once the operator did a Forced Switch he means to go back to Normal.  In a previous version of the draft we presented two possibilities of reverting to Normal from DNR state (either use an explicit Clear command or use FS) and the use of FS was chosen.  So this is the very scenario that allows the operator to revert back to Normal from DNR state.

 

[Suggested Solution] 

In Section 4.3.3.3, the 1st bullet item under local input needs to be modified as - "A local Clear SHOULD be ignored if in remote Protecting administrative state.  If in local Protecting administrative state then this input SHALL cause the LER to go into Normal state and begin transmitting a NR(0,0) message if in revertive mode or go into Do-Not-Revert state and begin transmitting DNR(0,1) if in non-revertive mode.

 

Scenario 3

Assume that there is a protection switching set up between routers R1 and R5 for working LSP1 and protection LSP2 where R1 is operating in the revertive mode and R5 is operating in the non-revertive mode.

 

yw>  There is a problem already at this point in your description - referring to section 4.2.4 of the draft - it states clearly that this misconfiguration should be reported to the management system as an error situation.

 

[Sequence of events] 

Both R1 and R5 in Normal state à SF on R1 à SF clear on R1

[Result] 

R5 moves to Wait-to-restore state and begins transmitting NR(0,1)

[Problem] 

R5 is in non-revertive mode and as such does not have a Wait-to-restore state. 

[Suggested Solution] 

In Section 4.3.3.4, the 4th bullet under remote messages needs to be modified as - "If in remote Protecting failure state, a remote Wait-to-Restore message SHALL cause the LER to go into remote Wait-to-Restore state if in revertive mode and into remote Do-Not-Revert state if in non-revertive mode and continue transmission of the current message.

 

 

I have worked out the exact sequence details of the state machine for the scenarios above, which I have listed below.

 

- Lavanya

 

 

DETAILED SEQUENCE

 

Scenario 1

Assume that there is a revertive protection switching group set up between routers R1 and R5 for working LSP1 and protection LSP2.

Intially both are in Normal state sending NR(0,0) to each other.

Now if R1 detects a Signal Failure, R1 moves to the local Protecting Failure state and sends SF(1,1) to R5.

R5, on receiving SF(1,1), now moves to the remote Protecting Failure state and will transmit NR(0,1) to R1.

R1, on receiving NR(0,1), will ignore the message.

Now issue a Forced Switch command on R5.

R5 will now move to the local Protecting Administrative state and start transmitting FS(1,1).

R1, on receiving FS(1,1), now moves to remote Protecting Adminstrative state and since it was earlier in local Protecting Failure state, it will now transmit SF(1,1) to R5.

R5, on receiving SF(1,1) from R1, will ignore the message since there is an active Local Forced Switch command.

Now issue a Clear command on R5 for clearing the Forced Switch.

R5 will now move to the Normal state since it was in local Protecting Adminstrative state and start transmitting NR(0,0).

R1, on receiving NR(0,0), will go to Normal state since it was in remote Protecting Adminstrative state and begin transmitting NR(0,0).

 

 

Scenario 2

Assume that there is a non-revertive protection switching set up between routers R1 and R5 for working LSP1 and protection LSP2.

Intially both are in Normal state sending NR(0,0) to each other.

Now if R1 detects a Signal Failure, R1 moves to the local Protecting Failure state and sends SF(1,1) to R5.

R5, on receiving SF(1,1), now moves to the remote Protecting Failure state and will transmit NR(0,1) to R1.

R1, on receiving NR(0,1), will ignore the message.

Now SF clears on R1.

R1 will go to Do-Not-Revert state and start transmitting DNR(0,1).

R5, on receving DNR(0,1) moves to the remote Do-Not-Revert state and continues transmitting current message of NR(0,1).

R1, on receiving NR(0,1), will ignore this message.

Now issue a Forced Switch command on R1.

R1 will go the local Protecting Administrative state and begins transmitting FS(1,1) to R5.

R5, on receiving FS(1,1), moves to the remote Protecting Administrative state and begins transmitting NR(0,1).

R1, on receiving NR(0,1) will ignore this message.

Now issue a Clear Forced Switch command on R1.

R1 moves to the Normal state and begins transmitting NR(0,0).

R5, on receiving NR(0,0), moves to the Normal state and begins transmitting NR(0,0).

 

 

Scenario 3

Assume that there is a protection switching set up between routers R1 and R5 for working LSP1 and protection LSP2 where R1 is operating in the revertive mode and R5 is operating in the non-revertive mode.

Intially both are in Normal state sending NR(0,0) to each other.

Now if R1 detects a Signal Failure, R1 moves to the local Protecting Failure state and sends SF(1,1) to R5.

R5, on receiving SF(1,1), now moves to the remote Protecting Failure state and will transmit NR(0,1) to R1.

R1, on receiving NR(0,1), will ignore the message.

Now SF clears on R1.

R1 will go to Wait-To-Restore state, start the WTR timer and start transmitting WTR(0,1).

R5, on receiving WTR(0,1), moves to the remote Wait-To-Restore state and continues transmission of current message NR(0,1).

 

 

________________________________

"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."