Subject: [mpls] A question regarding RFC 6428

From: Alexander Vainshtein <[email-masked]>
Date: Thu, 23 Aug 2012 13:45:57 +0000

Dave/George/John,

I have serious doubts regarding one of the modifications to the BFD FSM that has been introduced in RFC 6428<http://datatracker.ietf.org/doc/rfc6428/?include_text=1>.
The BFD FSM diagram (Figure 7) for coordinated BFD operation in Section 3.7.5 "State Machines" indicates that the BFD session transits from UP to DOWN upon receiving an LDI (and, optionally, LKR) message.

Could you please explain the rationale for such a change in the BFD state machine vs. what has been as described in RFC 5880<http://datatracker.ietf.org/doc/rfc5880/?include_text=1>?
(The text in 6428 explains that the state machine is modified in order to support mis-connectivity defect, but I do not see how this is related to LDI).

This change is introduced in addition to a requirement from Section 3.7.2 that receiving Link Down Indication (be it a local link failure or an MPLS-TP LDI message) results in entering a (presumably, Loss of Continuity) MEP defect state. Further, section 3.7.2 states that "receiving nothing" (i.e., expiration of the BFD session timer) has higher priority that reception of LDI. My reading of these results in the following:

1.       If LDI is received after the session timer expiration it is ignored

2.       If LDI is received before the session timer expiration, the session first goes down and sends back RDI with the Path Down diagnostic code. It is not clear whether the BFD session timer expiration results in changing the diagnostic code to "Control Detection Timer Expired" or not

3.       In the situation when BFD session timer does not expire while LDI state remains active (e.g., because the LSP uses FRR or segment protection to bypass the failed link), the session would cycle thru DOWN->INIT-->UP--> DOWN - session flapping/churn.

4.       It is not clear what is supposed to happen if the BFD session went DOWN because an LDI message has been received and then LDI state has been cleared (e.g., using the fast clearance mechanism defined in Section 5.2 of RFC 6427<http://datatracker.ietf.org/doc/rfc6427/?include_text=1>) before the session timer has expired.

To make my position clear, I do not see any issues with adding LDI as a trigger for sending the MEP to its DOWN state. I simply do not understand why this requires modification of the BFD State machine. At best this would speed up generation of RDI towards the remote MEP, but the price does not seem to justify the effort.  Note that RDI is not used as a trigger for protection actions; if bidirectional LSP protection is required, this is achieved via the PSC - e.g., as defined in RFC 6378<http://datatracker.ietf.org/doc/rfc6428/?include_text=1>.

Your feedback  would be highly appreciated.

Regards,
     Sasha

This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.

---

From: David Allan I <[email-masked]>
Date: Thu, 23 Aug 2012 17:52:12 -0400

HI Sasha:

We simply have two more protocol inputs into the state machine as MPLS-TP introduced the ability for intermediate nodes to introduce transactions of OAM significance into an LSP.

Hmm I read it exactly backwards, the introductury texts to section 3.7.5 should have mentioned mis-connectivity as well as LDI/LDR instead of just LKR.

1.       If LDI is received after the session timer expiration it is ignored.

Correct, that could happen if the CC rate was such that losing 3 occurred faster than the local criteria for issuing LDI. However that was not the use case LDI was invented for.

2.       If LDI is received before the session timer expiration, the session first goes down and sends back RDI with the Path Down diagnostic code. It is not clear whether the BFD session timer expiration results in changing the diagnostic code to "Control Detection Timer Expired" or not .

What diagnostic code to use for an LDI could be clarified.

Agreed, once you have multiple mechanisms involved, they do have the possibility of disagreeing. But you would not want to use FRR and LDI together. Of course, that does not mean that someone won't do it.

If you get an LDI you would transition to DOWN, you would then have to go through INIT etc. so I'm not sure there is an issue here. It came first, so I think the timers are rendered irrelevant by the session re-starting.

To make my position clear, I do not see any issues with adding LDI as a trigger for sending the MEP to its DOWN state. I simply do not understand why this requires modification of the BFD State machine.

How does the MEP get to a down state using LDI as a trigger without LDI as an input to the state machine?... this kinda sounds like the "via several miracles" picture ;-) It is simply a remote version of a local LOF/LOL indication.

 At best this would speed up generation of RDI towards the remote MEP, but the price does not seem to justify the effort.  Note that RDI is not used as a trigger for protection actions; if bidirectional LSP protection is required, this is achieved via the PSC - e.g., as defined in RFC 6378<http://datatracker.ietf.org/doc/rfc6428/?include_text=1>.

It would also enhance the accuracy of PM associated with availability as even with a slow CC rate, the LSP would enter the unavailable state faster. But more fundamentally, my take of figure 1 in 6378 is that CC/RDI are OAM indications as inputs into PSC, else why are we bothering. CC/RDI is a trigger for protection actions.

I hope this helps
Dave

---

From: Alexander Vainshtein <[email-masked]>
Date: Fri, 24 Aug 2012 05:02:50 +0000

Dave,

Lots of thanks for a prompt and informative response. A couple of comments if you do not mind.

Your response is (consistent with  RFC 6428) essentially says that the BFD session state machine is  the MEP state machine. This is implied by your statement "How does the MEP get to a down state using LDI as a trigger without LDI as an input to the state machine?... this kinda sounds like the "via several miracles" picture ;-) It is simply a remote version of a local LOF/LOL indication". Of course (and I've tried to explain that) LDI is an input to the MEP state machine. But it does not have to be an input to the BFD state machine IMO - unless you want to merge them into a single complicated one. One implication of this approach is that you cannot implement an MPLS-TP MEP without implementing BFD. This is not exactly what RFC 6427 says.

Regarding the need for fast RDI:

  1.  To the best of my understanding RDI is not defined as a trigger for protection - at least not in RFC 6378. (For the reference, Line RDI is not defined as a trigger for APS in GR-253, so this is not something that traditional transport networks do.)
  2.  I agree that fast RDI would, in theory, improve the count of "remote unavailable seconds" in some scenarios if these are counted. However I do not see any IETF documents that define how these are counted, nor am I sure that these are defined in any relevant ITU-T documents with specific reference to the BFD diagnostic codes - because with BFD used for RDI the state of the BFD session receiving RDI would be DOWN just as in the case of the session timer going down; the only difference is the diagnostic code. (Taking into account that ITU-T goes full speed towards an alternative CC/CV/RDI mechanism for LSPs, I doubt this is going to happen, but this is just a not very educated guess:-).

I would also like to bring to your attention the following statement from Section 6.8.16 "Administrative Control" of RFC 5880"

<quote>

   If signaling is received from outside BFD that the underlying path
   has failed, an implementation MAY administratively disable the
   session with the diagnostic Path Down.

   Other scenarios MAY use the diagnostic Administratively Down.

   BFD Control packets SHOULD be transmitted for at least a Detection
   Time after transitioning to AdminDown state in order to ensure that
   the remote system is aware of the state change.  BFD Control packets
   MAY be transmitted indefinitely after transitioning to AdminDown
   state in order to maintain session state in each system

<end quote>

My reading of this fragment is that 5880 takes a different approach to treating "external" signals - and IMO LDI is exactly that.

Last but not least, RFC 6428 is not marked as updating RFC 5880 (I've checked both the IETF data tracker and the RFC Editor site).

Regards,

     Sasha

________________________________
From: David Allan I [[email-masked]]
Sent: Thursday, August 23, 2012 11:52 PM
To: Alexander Vainshtein; [email-masked]; John E Drake ([email-masked])
Cc: Rotem Cohen; Mishael Wexler; Andrew Sergeev; Yechiel Rosengarten; Jagrati Shringi; [email-masked]; [email-masked]
Subject: RE: A question regarding RFC 6428

HI Sasha:
I have serious doubts regarding one of the modifications to the BFD FSM that has been introduced in RFC 6428<http://datatracker.ietf.org/doc/rfc6428/?include_text=1>.
The BFD FSM diagram (Figure 7) for coordinated BFD operation in Section 3.7.5 “State Machines” indicates that the BFD session transits from UP to DOWN upon receiving an LDI (and, optionally, LKR) message.

This change is introduced in addition to a requirement from Section 3.7.2 that receiving Link Down Indication (be it a local link failure or an MPLS-TP LDI message) results in entering a (presumably, Loss of Continuity) MEP defect state. Further, section 3.7.2 states that “receiving nothing” (i.e., expiration of the BFD session timer) has higher priority that reception of LDI. My reading of these results in the following:

2.       If LDI is received before the session timer expiration, the session first goes down and sends back RDI with the Path Down diagnostic code. It is not clear whether the BFD session timer expiration results in changing the diagnostic code to “Control Detection Timer Expired” or not .

3.       In the situation when BFD session timer does not expire while LDI state remains active (e.g., because the LSP uses FRR or segment protection to bypass the failed link), the session would cycle thru DOWN->INIT-->UP--> DOWN – session flapping/churn.

 At best this would speed up generation of RDI towards the remote MEP, but the price does not seem to justify the effort.  Note that RDI is not used as a trigger for protection actions; if bidirectional LSP protection is required, this is achieved via the PSC – e.g., as defined in RFC 6378<http://datatracker.ietf.org/doc/rfc6428/?include_text=1>.

I hope this helps
Dave