Re: [mpls] in some scenario RFC6378 can not protect the traffic, so much as take the PSC state to crash.

[曾峻波 <[e-mail]>]

yaacov,thanks for your patient explain.

1. Regarding Scenario #1:according the Section 4.3.3.1,i think the there need a new state ---TEMPORARY NORMAL STATE,just as its name implies,this state is a temporary state,and in this state LER shall never send NR PDU to its peer and will check its local persistent state to deside the final state and inform its peer by PSC PDU according this final state.

2.Regarding Scenario #2:I wonder how to define "contradictory". any change of the PSC PDU or the Path is not same with previous PSC PDU or any other? 



Best Regards! 
Junbo Zeng(BoBo) 



________________________________
> Date: Thu, 10 Jan 2013 19:12:08 +0200 
> Subject: Re: [mpls] in some scenario RFC6378 can not protect the  
> traffic, so much as take the PSC state to crash. 
> From: [e-mail] 
> To: [e-mail] 
> CC: [e-mail]; [e-mail] 
>  
> Junbo, hi 
>  
> Thank you for your scenarios.  However, both of these scenarios are  
> addressed by the text of RFC6378. 
>  
> 1. Regarding Scenario #1: The second paragraph of Section 4.3.3.1  
> states - "When the LER transitions into the Normal state, the PSC  
> Control Process SHALL check the persistent state of the local triggers  
> to decide if it should further transition into a new state...." Meaning  
> that in your scenario, after receiving the Clear, before transitioning  
> into Normal State, LER-1 should have checked the status of the other  
> triggers and decided, based upon the still active SF-W to transition  
> into Protecting Failure state, transmitting a SF(1,1) message. As to  
> the reaction of LER-2, see below. 
>  
> 2. Regarding Scenario #2: The second paragraph of Section 4.3.3 states  
> -"When a LER is in a remote state, i.e. state transition in reaction  
> to a PSC message recieved from the far-end LER, and receives a new  
> PSC message from the far-end LER that indicates a contradictory  
> state, e.g. in remote Unavailable state receiving a remote FS(1,1)  
> message, then the PSC Control Logic SHALL reevaluate all inputs (both  
> the local input and the remote message) as if the LER is in the  
> Normal state."  Meaning that in both the continuation of the previous  
> scenario as well as in your scenario, LER-2 should react to the remote  
> SF message as if in Normal and transition into Remote Protecting  
> Failure State. 
>  
> Therefore, I contend that neither scenario will cause PSC to crash. 
>  
>  
>  
> On Thu, Jan 10, 2013 at 11:10 AM, 曾峻波  
> <[e-mail]<mailto:[e-mail]>> wrote: 
>  
>  
> (if the figure can not display normally,please see the attach file.thanks.) 
>  
>  
> When in multi fault/priority condition scenario,RFC6378 can not protect  
> the traffic so much as take the PSC state to crash.consider the  
> following 2 scenario. 
>  
>             +------+                         +------+ 
>             | LER1 |                         | LER2 | 
>             +---+--+                         +---+--+ 
>                 +----------NR------------------->| 
>                 |                                | 
>                 |                                | 
>                 |<---------NR--------------------+ 
>   local lockout |                                | 
>    input        |                                | 
>                 +-----------LOCK---------------->| 
>                 |                                | 
>                 |                                | 
>                 |<---------NR--------------------+ 
>                 |                                | 
>   unidirection  |                                | 
>   SF_W raise    |                                | 
>                 +-------------LOCK-------------->| 
>                 |                                | 
>                 |                                | 
>                 |<---------NR--------------------+ 
>                 |                                | 
>   local clear   |                                | 
>    input        |                                | 
>                 +------------NR----------------->| 
>                 |                                | 
>                 |                                | 
>                 |<-----------NR------------------+ 
>                 |                                | 
>  
>  
>              figure 1: unidirection SF_W raise after local lockout input 
>  
> in figure 1,consider the following procedure 
> 1.LER1 and LER2 are both in NORMAL state and exchange NR PDU. 
> 2.the lockout command input into LER1,then LER1 send LOCK to LER2,LER2  
> send NR to LER1. 
> 3.a unidirection SF_W is raised in LER1,according RFC6378, LER1 still  
> send LOCK to LER2,LER2 send NR to LER1. 
> 4.the clear command input into LER1,according RFC6378,LER1 will send NR  
> to LER2,LER2 still send NR to LER1. so traffic is broken. 
>  
>  
>  
>  
>                        +------+                         +------+ 
>                        | LER1 |                         | LER2 | 
>                        +---+--+                         +---+--+ 
>                       N    +----------NR------------------->|       N 
>                            |                                | 
>                            |                                | 
>                            |<---------NR--------------------+ 
>       local lockout input  |                                | 
>                            |                                | 
>                    UA:LO:L +-----------LOCK---------------->| 
>                            |                                |UA:LO:R 
>                            |                                | 
>                            |<---------NR--------------------+ 
>         local clear input  |                                | 
>                            |                                | 
>                            |                                | 
>                         N  +-------NR--------------.........| 
>                            |                                | 
>                SF_W raise  | this nr is lost for smth.      | 
>                            | and SF_W is raised.            | 
>                            |                                | 
>                            +----------SF_W----------------->|always in UA:LO:R 
>                            |                                | 
>                            |                                | 
>                            |                                | 
>                            |<-----------SF_W----------------+ 
>                            |                                | 
>                            |                                | 
>  
>        figure 2: after clear a local LOCKOUT command,SF_W is raise  
> immediately,and the NR send to LER2 is lost for something. 
>  
> in figure 2,consider the following procedure. 
> 1.LER1 and LER2 are both in NORMAL state and exchange NR PDU. 
> 2.the lockout command input into LER1,then LER1 send LOCK to LER2 and  
> transfer to UA:LO:L,LER2 send NR to LER1 and transfer to UA:LO:R. 
> 3.the clear command input into LER1,LER1 transfer to NR and send NR to  
> LER2,but this NR is lost for some unknown reason, and SF_W is raised  
> immediately in LER1,so that the NR that send by LER1 to LER2 is  
> replaced by SF_W. 
> 4.no<http://4.no> NR reach LER2, if the error is bidirectional,LER2  
> will send SF_W to LER1,or NR to LER2 if unidirectional.but in any  
> condition,LER2 will still in UA:LO:R state.the PSC is crashed. 
>  
>  
> so i have 2 pieces of suggestion 
> 1.LER always send his local highest priority to it's peer. 
> 2.LER always accept the input from his peer by PSC PDU. 
>  
>  
>  
>  
>  
>  
> Best Regards! 
>  
>  
>  
> Junbo Zeng(BoBo) 
>  
>  
>  
>  
>  
>  
> _______________________________________________ 
> mpls mailing list 
> [e-mail]<mailto:[e-mail]> 
> https://www.ietf.org/mailman/listinfo/mpls 
>  
>  
>  
>  
> --  
> Thanx and BR, 
> yaacov 
>  
> Still looking for new opportunity