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

From: Yaacov Weingarten <[email-masked]>
Date: Thu, 10 Jan 2013 19:12:08 +0200

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, 曾峻波 <[email-masked]> 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 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>
>

-- 
Thanx and BR,
yaacov

*Still looking for new opportunity*

---

From: 曾峻波 <[email-masked]>
Date: Fri, 11 Jan 2013 10:44:00 +0800

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: [email-masked] 
> To: [email-masked] 
> CC: [email-masked]; [email-masked] 
>  
> Junbo, hi 
>  
> 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. 
>  
> -"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. 
>  
> On Thu, Jan 10, 2013 at 11:10 AM, 曾峻波  
> <[email-masked]<mailto:[email-masked]>> wrote: 
>  
>  
> the traffic so much as take the PSC state to crash.consider the  
> following 2 scenario. 
>  
>             +------+                         +------+ 
>             | LER1 |                         | LER2 | 
>             +---+--+                         +---+--+ 
> 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 | 
>                        +---+--+                         +---+--+ 
>                            +----------SF_W----------------->|always in UA:LO:R 
>                            |                                | 
>                            |                                | 
>                            |                                | 
> 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. 
>  
>  
> [email-masked]<mailto:[email-masked]> 
> Still looking for new opportunity

---

From: Yaacov Weingarten <[email-masked]>
Date: Fri, 11 Jan 2013 06:15:48 +0200

Hi,

1. I believe that this is an implementation issue, and therefore out of
scope.
2. "Contradictory" means any message that implies a different remote state.

Hope this helps

BR,
yaacov

Still looking for new opportunity
 On Jan 11, 2013 4:44 AM, "曾峻波" <[email-masked]> wrote:

> 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)
>
>
>

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Fri, 11 Jan 2013 20:40:09 +0000

I don't think there needs to be a transient state such as 'temporary normal'.  If an implementation has multiple inputs (one local, one remote) and the highest-priority input goes away, it should look at the remaining input to decide what to do before doing anything.  Transitioning into temporary normal seems like a naïve implementation.

As far as " but i think author of RFC shall make sure the standard is clear and no ambiguity", I agree.  We've gotten this question a few times on the list and I've had it a few off-list as well.  I will take steps to clarify the language in RFC6378.  Hopefully I'll have something out in time for Orlando.

eric

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of ???
> Sent: Thursday, January 10, 2013 9:44 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [mpls] in some scenario RFC6378 can not protect the traffic, so
> much as take the PSC state to crash.
> 
> 
> 
> 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)
> 
> 
> 
> > 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.
> >
> > 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.
> >
> > 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 |
> >             +---+--+                         +---+--+
> > 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 |
> >                        +---+--+                         +---+--+

---

From: "Eric Osborne (eosborne)" <[email-masked]>
Date: Tue, 15 Jan 2013 16:03:45 +0000

Inline.

> From: 曾峻波 [mailto:[email-masked]]
> Sent: Tuesday, January 15, 2013 7:48 AM
> To: Eric Osborne (eosborne); [email-masked]
> Cc: [email-masked]
> Subject: RE: [mpls] in some scenario RFC6378 can not protect the traffic, so
> hi,
> of cause,if the PSC state reevaluate all inputs when any of it has change,the PSC
> will work perfectly.but there no such discription in RFC6378.and in RFC6378
> language the NR state is not clear and ambiguity.the "TEMPORARY NORMAL
> STATE" is only a suggestion to help to make the PSC state more integrity in it's
> language. the sections of RFC6378 from 4.3.3.1 to the end dose not make the
> PSC state clear but make it confused. if RFC6378 can clarify the basic operation
> of PSC state---"the PSC state reevaluate all inputs when any of it has
> change",then absent of the sections of RFC6378 from 4.3.3.1 will ok.

As I said before, I have some text that should address this.  We recognize that the way it's currently written is confusing.  I hope to have text in time for the Orlando meeting, and will get back to this thread with a pointer to the draft.

> 
> i have a another suggestion,the LER will never send NR as a reaction to its
> peer,but always send his local highest prirority condition with the coordinateed
> PATH info to it peer.this will make the PSC state more simple.because the PSC
> state is single-phase protection,except for the PATH info,there is nothing info
> need to be coordinateed.

Other than making things 'simpler', does this actually fix any bug in PSC?

eric

> BR.
> zengjunbo(bobo)
> 
> ----------------------------------------
> > From: [email-masked]
> > To: [email-masked]; [email-masked]
> > CC: [email-masked]
> > Subject: RE: [mpls] in some scenario RFC6378 can not protect the traffic, so
> > Date: Fri, 11 Jan 2013 20:40:09 +0000
> >
> > I don't think there needs to be a transient state such as 'temporary normal'. If
> an implementation has multiple inputs (one local, one remote) and the highest-
> priority input goes away, it should look at the remaining input to decide what to
> do before doing anything. Transitioning into temporary normal seems like a
> naïve implementation.
> >
> > As far as " but i think author of RFC shall make sure the standard is clear and
> no ambiguity", I agree. We've gotten this question a few times on the list and
> I've had it a few off-list as well. I will take steps to clarify the language in
> RFC6378. Hopefully I'll have something out in time for Orlando.
> >
> >
> >
> > eric
> >
> >>(if figure3 is not display normally,please see attach file,thanks.)
> >>
> >>hi,
> >>
> >>1. yes,i agree with you that the TEMPORARY NORMAL STATE is an
> implementation issue,but i think author of RFC shall make sure the standard is
> clear and no ambiguity.usually,a network is composed of different equipment
> come from different compay,LER1 and LER2 will interwork with each other
> according RFC6378. if there is absence of TEMPORARY NORMAL STATE
> defination,mybe LER1 in TEMPORARY NORMAL STATE send NR to its peer and
> LER2 don't send NR to its peer,this will make the PSC state chaos.
> >>
> >>
> >>
> >>                          +------+                         +------+
> >>                          | LER1 |                         | LER2 |
> >>                          +---+--+                         +---+--+
> >>      unidirection SF_W raise |                                |
> >>                              |                                |
> >>                              +-----------SF_W---------------->|
> >>                              |                                |
> >>                              |                                |
> >>      local FS command input  |                                |
> >>                              |                                |
> >>                     PA:F:L   +-----------FS------------------>|
> >>                              |                                |PA:F:R
> >>                              |                                |
> >>       TEMPORARY NORMAL STATE +-------NR---------------------->| N
> >>                     |        |                                |if this NR reach,LER2 will
> >>                     |        |                                |switch traffic to work path,
> >>                     |        |                                |this will broken the traffic.
> >>                     V        |                                |
> >>       final state  PF:W:L    +----------SF_W----------------->|PF:W_R
> >>                              |                                |LER2 will switch traffic to
> >>                              |                                |protection path,traffic is
> >>                              |                                |restored.
> >>            figure 3:lack of TEMPORARY NORMAL STATE,traffic will be broken
> accidentally.
> >>
> >>when the flow arrived ad the TEMPORARY NORMAL STATE,if LER1 send NR
> to its peer,then the traffic is broken for a while accidentally,and restore when
> the SF_W reach LER2.so, i think the TEMPORARY NORMAL STATE shall be add
> to the PSC state to make the state machine clear and no ambiguity.
> >>
> >>
> >>2.if the "Contradictory" means any message that implies a different
> >>remote state,this is agree with my suggestion 2:LER always accept the input
> from his peer by PSC PDU.and according the defination of "Contradictory",there
> are some description in RFC6378 should be correct,for example a.in 4.3.3.2 --"A
> remote Forced Switch message SHALL be ignored by the PSC Control logic when
> in Unavailable state as a result of a (local or remote) Lockout of protection."  if
> the FS message is diferrent from previous PSC msg,it should be accepted.
> >>b.in the Appendix A. PSC State Machine Tables,Part 2: Remote messages
> state machine -- "
> >>               | LO    | SF-P | FS   | SF-W | MS   | WTR  | DNR  | NR
> >>       --------+-------+------+------+------+------+------+------+------
> >>       N       |UA:LO:R|UA:P:R|PA:F:R|PF:W:R|PA:M:R| i    | i    | i
> >>       UA:LO:L | i     | i    | i    | i    | i    | i    | i    | i
> >>       UA:P:L  | [10]  | i    | [19] | i    | i    | i    | i    | i
> >>       UA:LO:R | i     | i    | i    | i    | i    | i    | i    | [16]
> >>       UA:P:R  |UA:LO:R| i    |PA:F:R| i    | i    | i    | i    | [16]
> >>       PF:W:L  | [11]  | [12] |PA:F:R| i    | i    | i    | i    | i
> >>       PF:W:R  |UA:LO:R|UA:P:R|PA:F:R| i    | i    | [14] | [15] | N
> >>       PA:F:L  |UA:LO:R| i    | i    | i    | i    | i    | i    | i
> >>       PA:M:L  |UA:LO:R|UA:P:R|PA:F:R| [13] | i    | i    | i    | i
> >>       PA:F:R  |UA:LO:R| i    | i    | i    | i    | i    | DNR  | [17]
> >>       PA:M:R  |UA:LO:R|UA:P:R|PA:F:R| [13] | i    | i    | DNR  | N
> >>       WTR     |UA:LO:R|UA:P:R|PA:F:R|PF:W:R|PA:M:R| i    | i    | [18]
> >>       DNR     |UA:LO:R|UA:P:R|PA:F:R|PF:W:R|PA:M:R| i    | i    | i
> >>"most of the Ignore shall be change.
> >>c.some other similar description shall be correct.
> >>
> >>
> >>Best Regards!
> >>Junbo Zeng(BoBo)
> >>
> >>
> >>> Date: Fri, 11 Jan 2013 06:15:48 +0200
> >>> Subject: RE: [mpls] in some scenario RFC6378 can not protect the
> >>> From: wyaacov at gmail.com
> >>> To: zjbdamo at hotmail.com
> >>> CC: mpls at ietf.org
> >>>
> >>>
> >>> Hi,
> >>>
> of
> >>> 4.no<http://4.no <http://4.no/> > NR reach LER2, if the error is
> bidirectional,LER2