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

From: Eric Gray <[email-masked]>
Date: Tue, 12 Apr 2011 06:35:15 -0400

Resending this in plain text (too big)
________________________________

From: Lavanya Srivatsa [mailto:[email-masked]] 
Sent: Friday, April 08, 2011 4:39 AM
To: Weingarten, Yaacov (NSN - IL/Hod HaSharon); [email-masked]
Cc: Lavanya Srivatsa
Subject: RE: [mpls] Comments on draft-ietf-mpls-tp-linear-protection-06.txt

I am re-sending my mail since I am unable to see this in the MPLS or the MPLS-TP mailing pages!

________________________________

From: Lavanya Srivatsa 
Sent: Tuesday, April 05, 2011 3:25 PM
To: Weingarten, Yaacov (NSN - IL/Hod HaSharon); MPLS TP; [email-masked]
Cc: Lavanya Srivatsa
Subject: RE: [mpls] Comments on draft-ietf-mpls-tp-linear-protection-06.txt

Hi Yaacov,

Thanks for your prompt response. I apologize for my delayed response. 

Please see my comments inlined with [LS].

Thanks

Lavanya

________________________________

From: Weingarten, Yaacov (NSN - IL/Hod HaSharon) [mailto:[email-masked]] 
Sent: Thursday, March 17, 2011 6:44 PM
To: Lavanya Srivatsa; MPLS TP; [email-masked]
Subject: RE: [mpls] Comments on draft-ietf-mpls-tp-linear-protection-06.txt

Lavanya, hi

See my comments below

Hope this helps

BR,

yaacov

From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Lavanya Srivatsa
Sent: Thursday, March 17, 2011 11:16 AM
To: MPLS TP; [email-masked]
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.

[LS] Thanks for referring me to the comments resolution. I have looked into row#80 which talks of a different scenario but talks on the same lines as the one I have mentioned. 

When you state that R1 returns to Normal and will immediately receive the SF and go into Protecting Failure state, it depends on what you mean by "immediate" here. Unless you mean an "atomic" operation that happens either based on storing of the previous failure state or by some sort of 2-pass through the state machine (which is some form of re-assertion as I had stated), this will, for sure, cause a "traffic glitch" even though it may be momentary. Any scenario that could result in an unnecessary traffic glitch is highly undesirable and would defeat the purpose of having such a detailed protocol and state machine for protecting switching.

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.

[LS] I do not believe the suggestion to be an optimization, rather a fool-proof method that results in correct expected behaviour and does not leave it up to implementations to figure this out. If it is to be an "atomic operation" or "2-pass logic", or to pass through an "intermediate state", then this needs to be mentioned clearly. As a standard mechanism being proposed for protecting switching, I feel that it is imperative for such recommendations to be made in the draft for all such possible scenarios in order to ensure correctness and a high-level of interoperability amongst vendors implementing this solution under all situations/scenarios. It may not be too complex actually, considering the fact that Ethernet linear protection switching state machines provide solutions for such scenarios, so taking a similar strategy for MPLS should be relatively easy I guess! However, even if it is, I still think we would have to go ahead and make these recommendations in the draft for completeness and correctness.

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

[LS] If this has been a conscious decision to switch back to working for a non-revertive protection, then fine, I agree.

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

[LS] Section 4.2.4 only mentions that if there is an inconsistency between the two ends with regards to revertive/non-revertive, then the management system SHOULD be notified.

Based on your response, this is the suggestion from my side - Rephrase the 2nd sentence in Section 4.2.4 as follows - "If there is an inconsistency between the two end points, i.e. one end point is configured for revertive action and the second end point is in non-revertive mode, then this should be treated as a mis-configuration and the management system MUST be notified, and any received PSC packets with the revertive (R) field different from what is supported on the local node should be discarded."

BTW, just curious - one end being revertive and the other end being non-revertive is a scenario that can interwork in ethernet linear protection switching. Any specific reason as to why this is considered non-interworking for MPLS paths?

[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."

---

From: Eric Gray <[email-masked]>
Date: Tue, 12 Apr 2011 06:36:06 -0400

Resending in plain text (too big)
________________________________

From: Lavanya Srivatsa [mailto:[email-masked]] 
Sent: Tuesday, April 05, 2011 5:55 AM
To: Weingarten, Yaacov (NSN - IL/Hod HaSharon); MPLS TP; [email-masked]
Cc: Lavanya Srivatsa
Subject: RE: [mpls] Comments on draft-ietf-mpls-tp-linear-protection-06.txt

Hi Yaacov,

Thanks

Lavanya

Lavanya, hi

See my comments below

Hope this helps

BR,

yaacov

To the authors,

Scenario 1

[Sequence of events] 

[Result] 

[Problem] 

 

[Suggested Solution] 

Scenario 2

[Sequence of events] 

[Result] 

[Problem] 

[Suggested Solution] 

Scenario 3

[Sequence of events] 

[Result] 

[Problem] 

[Suggested Solution] 

 

- Lavanya

DETAILED SEQUENCE

Scenario 1

 

Scenario 2

Now SF clears on R1.

 

Scenario 3

Now SF clears on R1.

---

From: Lavanya Srivatsa <[email-masked]>
Date: Tue, 26 Apr 2011 19:20:33 +0530

Hello Yacoov,

With regards to your below response about FS clear, my question is - what about Manual Switch (MS) clear? Was this also a concious choice to make the operator revert to Normal from DNR state by using MS also? As per the draft, MS clear also seems to move to NR instead of DNR for non-revertive operation.
Or since MS is of lower priority, should it fall back to default DNR state only for the non-revertive operation? If so, the draft needs a correction for this.

Would appreciate your response on this.

- Lavanya

Scenario 2

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

[Suggested Solution]