Subject: Re: [mpls] implementation of BFD in passive mode?

From: Greg Mirsky <[email-masked]>
Date: Thu, 15 Sep 2011 10:15:14 -0700

Dear Sasha,
I believe that changing timers through taking session into Admin Down
is compliant with RFC 5880. It is mentioned in parameter update method
in MPLS-TP CC-CV-RDI. Section 3.7.1:
   In the rare circumstance where an operator has a reason to further
   change session parameters, beyond the initial migration from default
   values; poll/final discipline can be used with the caveat that a peer
   implementation may consider a session change unacceptable and/or
   bring the BFD session down via the use of the ADMIN DOWN state.

Regards,
Greg

On Thu, Sep 15, 2011 at 12:59 AM, Alexander Vainshtein
<[email-masked]> wrote:
> Jinny,
>
> Lots of thanks for a prompt response.
>
>
>
> I am not sure that changing the parameters in AdminDown state of the session
> is compliant with 5880.
>
> Please note that the fragment I’ve quoted refers to the situation when the
> BFD session is not Up,  which clearly includes AdminDown.
>
> Note also that the session may go Down for natural reasons (if they were
> not, why should we bother to set them up anyway?), and should resume their
> original fast operation once they come up back.
>
>
>
> Last but not least, I am aware of at least two implementations that use BFD
> HW accelerators (what you call the fast path ASICs) to support intervals and
> timers in the millisecond range combined with 5880-compliant Final/Poll
> processing in SW. The protocol has been specifically designed to facilitate
> this kind of HW/SW interaction IMO.
>
>
>
> Regards,
>
>      Sasha
>
>
>
> From: binny jeshan [mailto:[email-masked]]
> Sent: Thursday, September 15, 2011 8:31 AM
> To: Alexander Vainshtein
> Cc: [email-masked]; Robert Rennison
>
> Subject: Re: implementation of BFD in passive mode?
>
>
>
> Hi Sasha,
>
>
>
> Your points are correct. In the same section, i find the below aspects also.
>
>
>
> <quote>
>
>
>
> The time values used to determine BFD packet transmission intervals
>
>    and the session Detection Time may be modified at any time without
>
>    affecting the state of the session.  When the timer parameters are
>
>    changed for any reason, the requirements of this section apply.
>
> <end>
>
>
>
> <quote>
>
> If bfd.DesiredMinTxInterval is increased and bfd.SessionState is Up,
>
>    the actual transmission interval used MUST NOT change until the Poll
>
>    Sequence described above has terminated.  This is to ensure that the
>
>    remote system updates its Detection Time before the transmission
>
>    interval increases.
>
> <end>
>
> Changing timers can be done in two ways as per my understanding.
>
>
>
> 1. Router A operator can initiate the timing change through poll request and
> at the end of the poll sequence the new timer values are applied.
> 2. Route A and B can bring the session Admin Down, Change its timers and
> start-off again..
>
>
>
> Slow interval can be used in below cases as per my understanding.
>
> 1. When session starts up in Down state
>
> 2. When session goes down due to any defects
>
>
>
> When you start a session, you need not do a polling, since the timer
> negotiation section 6.8.2, will be used, and not the polling.
>
> Polling will be used only when timer is 'modified'.
>
>
>
> Why some routers may not implement Polling?
>
> One reason could be that in cases if BFD is accelerated in a Fast Path ASIC
> (for sub-second interval configurations), it becomes hard to change
> parameters in run-time using polling without affecting the running session.
> This is due to implementation limitations at hardware level. In such case,
> these routers allow polling for sessions running at software.
>
>
>
> Thanks for the question..
>
>
>
> Regards,
>
> Binny Jeshan
>
>
>
>
>
> On 15 September 2011 10:10, Alexander Vainshtein
> <[email-masked]> wrote:
>
> Binny,
>
> You say that some routers may not implement the poll-final sequence for BFD
> and require bringing down their BFD sessions in order to change the session
> parameters.
>
>
>
> I wonder how this is supposed to be compatible with the following in RFC
> 5880:
>
>
>
> From Section 6.2 "BFD State Machine":
>
> <quote>
>
>                              +--+
>
>                              |  | UP, ADMIN DOWN, TIMER
>
>                              |  V
>
>                      DOWN  +------+  INIT
>
>               +------------|      |------------+
>
>               |            | DOWN |            |
>
>               |  +-------->|      |<--------+  |
>
>               |  |         +------+         |  |
>
>               |  |                          |  |
>
>               |  |               ADMIN DOWN,|  |
>
>               |  |ADMIN DOWN,          DOWN,|  |
>
>               |  |TIMER                TIMER|  |
>
>               V  |                          |  V
>
>             +------+                      +------+
>
>        +----|      |                      |      |----+
>
>    DOWN|    | INIT |--------------------->|  UP  |    |INIT, UP
>
>        +--->|      | INIT, UP             |      |<---+
>
>             +------+                      +------+
>
> <end quote>
>
>
>
> From Section 6.8.3 "Timer Manipulation":
>
> <quote>
>
>    When bfd.SessionState is not Up, the system MUST set
>
>    bfd.DesiredMinTxInterval to a value of not less than one second
>
>    (1,000,000 microseconds).  This is intended to ensure that the
>
>    bandwidth consumed by BFD sessions that are not Up is negligible,
>
>    particularly in the case where a neighbor may not be running BFD.
>
> <end quote>
>
>
>
> To me these two fragments mean that BFD sessions are always started as
> "slow" (i.e., not faster than 1 packet/second), revert to "slow" every time
> they go down, and can only progress to the desired rate via the Final/Poll
> negotiation.
>
>
>
> Did I miss something substantial?
>
>
>
> Regards,
>
>      Sasha
>
> ________________________________
>
> From: [email-masked] [[email-masked]] On Behalf Of binny
> jeshan [[email-masked]]
> Sent: Thursday, September 15, 2011 5:25 AM
> To: Das, Bevan N (Bevan)
> Cc: [email-masked]
> Subject: Re: implementation of BFD in passive mode?
>
> Hi Bevan,
>
>
>
> As per my understanding about BFD in passive mode, its should be implemented
> in all routes supporting 5880, except when explicitly passive mode is said
> to be not supported. I believe the Spirent Test Center BFD base package has
> already implemented this and you can test your SUT using it. You can test
> the negative scenario passive-passive too.
>
>
>
> The same applies for Poll-final sequence also. Some routers may implement
> this, whereas some may not. They require to bring down the session and edit
> the BFD session parameters.
>
>
>
> Hope this helps you.
>
>
>
> Thanks,
>
> Binny Jeshan.
>
> On 15 September 2011 01:52, Das, Bevan N (Bevan)
> <[email-masked]> wrote:
>
> Hi,
>
> I am a software tester in Alcatel-Lucent, and part of my current work is
> verifying BFD interoperability of one of our products with routers.
>
> In reading through RFC 5880 and in searching through web guides for BFD, I
> have seen two modes possible for BFD:  "active" and "passive".  However, all
> the routers that I have worked with up until now only implement "active"
> mode.  Are there any implementations of BFD that actually use "passive"
> mode?  In other words, am I safe in just verifying interoperability with
> routers in "active" mode?
>
> Thank you for your time,
>
> Bevan Das
> [email-masked]
>
>
>
> 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.
>
>
>
> 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.