Subject: [PWE3] Corner case status timeout handling in draft-ietf-pwe3-static-pw-status-00.txt

From: Luca Martini <[email-masked]>
Date: Thu, 10 Jun 2010 15:52:10 -0600

WG,

I need some suggestions and a bit of help of the following problem that
was raised in a private e-mail to me.

As defined in the document today, status for static PW is retransmitted
periodically ( let's assume we do not use the ACK bit for this discussion ).
If a PE no longer receives a status message refresh, after 3.5 the timer
expiration value specified in the last packet the status of that PE is
deemed to be 0x00000000. The problem that was raised is the fact that
that PW might be in "standby mode" with the Preferential forwarding bit
set. If we arbitrarily clear that bit, the PW can under certain
circumstances become active, and therefore cause a traffic disruption.

I can suggest a few solutions to this problem as follows:

1) specify that the timeout timer MUST be longer the the maximum time it
takes to detect that the LSP transporting the PW is down. ( my preferred
approach )

2) change the logic, so that if the status timeout timer expires, we
keep the same state, but require that every time a PW is provisioned, or
the LSP of a Pw transition from a down state to an UP state,  that a PW
status update be sent in a similar way we send the status 0x0000000 update

3) Do #2 above but only for some bits like the redundancy bits.

Thoughts ?

Thanks.
Luca

---

From: Neil McGill <[email-masked]>
Date: Thu, 10 Jun 2010 20:55:38 -0400 (GMT)

Standby is not really an error and just happens to share the error
bitmap, therefore should not really be cleared upon expiration of
an error condition.

The peer will eventually clear the standby when it transitions out
of this state anyway  - but if that all clear message is also lost...

1) but preserve the standby bit.

Thanks,

Neil.

On Thu, 10 Jun 2010, Luca Martini wrote:

> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/pwe3
>

---

From: Robert Rennison <[email-masked]>
Date: Fri, 11 Jun 2010 10:47:25 -0400

Luca,

+1 for the spirit of Neil's suggestion,  re do not infer for the status bit. Not sure if need to tie this in with rule that the  timer value is > than the LSP failure detection time.

On the rational for do not infer state change for the status bit, this seems clear :-

Making an inference about a status bit in the absence of information about that bit is only valid if the consequences of such an action are fairly benign, so we would not want to think that a given PW had become active with perhaps unintended consequences of reverting to him for example.

This thread does raise a question that I've had  when reading the draft.

In the case of the error status bits, you are  effectively saying "OK I give up I assume this PW is not in an error condition"

I am curious regarding your intent in clearing these bits, one could just as well have said I will assume that the bits are sticky. 

With the current rules 

I previously was told that say a given PW was in a  "Pseudowire not forwarding state" If I stop hearing  about him he is now in a "Pseudowire forwarding state". 
Could I not end up making an incorrect assumption to now use a given PW ?

Vs in the "status bits are sticky case" Worst case here I keep thinking there is a problem,  I am tying in the CP with the DP fate here.

One additional bit to consider is the "Request switchover to this PW" bit. This one does appear to be pretty safe to assume is 0 is we timeout.

Cheers

Rob

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Neil McGill
> Sent: Thursday, June 10, 2010 8:56 PM
> To: Luca Martini
> Cc: PWE3 WG (E-mail)
> Subject: Re: [PWE3] Corner case status timeout handling in draft-ietf-
> pwe3-static-pw-status-00.txt
> 
>

---

From: Robert Rennison <[email-masked]>
Date: Fri, 11 Jun 2010 11:45:55 -0400

Luca,

In my previous email I ask a number of questions re rationale for the current behavior vs. sticky bit approach but did not notice you had already given a specific  option (#2)
to change the  current logic and  use a sticky behavior.

This approach feels cleaner and much more fail safe plus we do not have to decide which bits are ok to clear which not, i.e. case by case exceptions to a general rule.

So, discussion for decision rationale aside, my preference is for Option 2.

Cheers

Rob

> Robert Rennison
> Sent: Friday, June 11, 2010 10:47 AM
> To: Neil McGill; Luca Martini
> Cc: PWE3 WG (E-mail)
> +1 for the spirit of Neil's suggestion,  re do not infer for the status
> bit. Not sure if need to tie this in with rule that the  timer value is
> > than the LSP failure detection time.
> 
> Making an inference about a status bit in the absence of information
> about that bit is only valid if the consequences of such an action are
> fairly benign, so we would not want to think that a given PW had become
> active with perhaps unintended consequences of reverting to him for
> example.
> 
> In the case of the error status bits, you are  effectively saying "OK I
> give up I assume this PW is not in an error condition"
> 
> I am curious regarding your intent in clearing these bits, one could
> just as well have said I will assume that the bits are sticky.
> 
> With the current rules
> 
> I previously was told that say a given PW was in a  "Pseudowire not
> forwarding state" If I stop hearing  about him he is now in a
> "Pseudowire forwarding state".
> Vs in the "status bits are sticky case" Worst case here I keep thinking
> there is a problem,  I am tying in the CP with the DP fate here.
> 
> 
> One additional bit to consider is the "Request switchover to this PW"
> bit. This one does appear to be pretty safe to assume is 0 is we
> timeout.
> 
> 
> Cheers
> 
> Rob
> 
> > > 1) specify that the timeout timer MUST be longer the the maximum
> time
> > it
> > > keep the same state, but require that every time a PW is
> provisioned,
> > or
> > > the LSP of a Pw transition from a down state to an UP state,  that
> a
> > PW

---

From: Neil McGill <[email-masked]>
Date: Fri, 11 Jun 2010 11:54:54 -0400 (GMT)

> So, discussion for decision rationale aside, my preference is for Option 2.

Thinking more on this, option 2 does seem the cleanest most
deterministic approach. So, 2 now 8).

Thanks,

Neil.

---

From: Sami Boutros <[email-masked]>
Date: Mon, 14 Jun 2010 11:29:06 -0700

>takes to detect that the LSP transporting the PW is down. ( my preferred

I agree with approach 1 too.
The local PE will no longer receives status refreshes if either the remote PE
goes down or the transport LSP goes down, in either case the local PE 
transport
LSP to the remote PE for this PW will go down, and this would forbid the
PW from coming up because of local errors.

>status update be sent in a similar way we send the status 0x0000000 update

Changing the timeout logic may break other cases, in which the status 
0x0000000
itself can't be delivered.

Thanks,

Sami