Subject: Re: [mpls] BFD Packet Flow

From: Lavanya Srivatsa <[email-masked]>
Date: Thu, 26 Aug 2010 16:39:06 +0530

Dave,

Thanks for the earlier response about the so-called 4-way handshake. I got what you are trying to say...

I had a question on the below though:
>> In some sense the question is meaningless;  the active and passive roles are really a way of describing the way the protocol behaves in a larger context.  In the >> LSP context, LSR-Z is by definition in the active role because it must send the first BFD packet.

If so, does this mean that BFD-MPLS is applicable only in the Active-Active scenario i.e. both LSR-A and LSR-Z in Active roles? The reason I am saying this is one would expect LSR-A to be playing the Active role because LSR-A is the **head-end of the forward unidirectional path** that is being monitored in case of an unidirectional MPLS path. Now if LSR-Z is also required to be in Active state because it sends the first BFD packet, then this would imply that only Active-Active scenario is applicable for BFD-MPLS, right?

The BFD-MPLS RFC also goes on to say that the node receiving a LSP Ping request MUST send a BFD control packet and MAY send an LSP Ping response.
Does this imply the Active-Passive scenario for BFD-MPLS (i.e. LSR-A in Active role and LSR-Z in Passive role)?

In the sense, if LSR-Z is Active, upon receiving an LSP Ping request, LSR-Z will respond with a BFD control packet.
If LSR-Z is Passive, upon receiving an LSP Ping request, LSR-Z will *not* send a BFD control packet but will respond with an LSP Ping response (carrying LSR-Z's discriminator) instead.

Is my understanding correct? If so, the text in the RFC seems to slightly mislead with the "MAY" clause for the LSP Ping response.

- Lavanya

Date: Sat, 21 Aug 2010 12:45:09 -0700
From: Dave Katz <[email-masked]>
Subject: Re: [mpls] BFD Packet Flow
To: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)"
        <[email-masked]>
Cc: [email-masked], [email-masked], RAKESH GUPTA
        <[email-masked]>
Message-ID: <[email-masked]>
Content-Type: text/plain; charset="windows-1252"

On Aug 19, 2010, at 2:08 AM, Weingarten, Yaacov (NSN - IL/Hod HaSharon) wrote:

> Hi,
>
> Just to verify that I understand the flow of messages and the state of the BFD Session ? is the following flow correct ?
>
> Assume a LSP between LSR-A and LSR-Z ?
> 1. Both LSRs initialize the BFD Session and set the state to Down
> 2. LSR-A (the ingress LSR) sends a LSP-Ping (with the Discriminator TLV) to LSR-Z ? both sessions still in Down state.
> 3. LSR-Z receives the LSP-Ping, and (assuming that LSR-Z is in Active mode) sends a BFD Control Packet with its own Discriminator, the Discriminator received from the LSP-Ping, and State=Down to LSR-A, both session still in Down State.
> 4. LSR-A receives the BFD Control and switches to Init state (as per RFC5880), and sends a BFD Control Packet with State=Init to LSR-Z
> 5. LSR-Z receives the BFD Control and switches to Up state, and sends a BFD Control Packet with State=Up to LSR-A
> 6. LSR-A receives the BFD Control and switches to UP state
>
> Additional question ? regarding step 3 above ? must LSR-Z be in Active mode? What happens if LSR-Z is in Passive mode and LSR-A is in Active mode?

In some sense the question is meaningless;  the active and passive roles are really a way of describing the way the protocol behaves in a larger context.  In the LSP context, LSR-Z is by definition in the active role because it must send the first BFD packet.

--Dave

"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."