Re: [mpls] BFD Packet Flow

Greg Mirsky <gregimirsky@gmail.com> Sat, 21 August 2010 18:05 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: mpls@core3.amsl.com
Delivered-To: mpls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B74683A67F9; Sat, 21 Aug 2010 11:05:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.702
X-Spam-Level:
X-Spam-Status: No, score=-1.702 tagged_above=-999 required=5 tests=[AWL=-0.304, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, J_CHICKENPOX_54=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3aXO3wLW3JED; Sat, 21 Aug 2010 11:05:00 -0700 (PDT)
Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id A07CE3A693E; Sat, 21 Aug 2010 11:04:59 -0700 (PDT)
Received: by vws10 with SMTP id 10so4430417vws.31 for <multiple recipients>; Sat, 21 Aug 2010 11:05:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=dk2QbQjjkE4d6gdTjFUvHogSmS0Defkl2+OHVE79KPk=; b=nUOPLOsxdGwaKaxZMV7LgnJGVgZ/WJPnqi+71WVQ4Xr/b7B7Kd6FYWlRnwTo0/hEuR Ch2fH+rmUI3aYkgqKvynMSM8yfkwcMlVRjwrOcl+cX2uChH+Fjp/G1FyA58yGXiRetdc UZRkyH5jsOnVmeM0IJyylS4uuYHBjMcxY+1bs=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=wGTHEJ53/dYt+8HuddQJgsaRm7F/1uHWGIA76HGwz6Z4oG5uXFP6wEYxYROXEeWu7b bBCbboGLyiPTzwJYuI6VF6bfdatkRhKO/c/0EdrCOfGcD4ZFOEp41/RwQJUUKHIV6gry UhCoPfyIG5LxXPM61sRUIk7k1Q8+Gl1/ottVA=
MIME-Version: 1.0
Received: by 10.220.93.17 with SMTP id t17mr1822081vcm.126.1282413933630; Sat, 21 Aug 2010 11:05:33 -0700 (PDT)
Received: by 10.220.105.69 with HTTP; Sat, 21 Aug 2010 11:05:33 -0700 (PDT)
In-Reply-To: <E13C8C03049AFA4E9CEE5A21D3E7F85D146398@GUREXMB02.ASIAN.AD.ARICENT.COM>
References: <E13C8C03049AFA4E9CEE5A21D3E7F85D146398@GUREXMB02.ASIAN.AD.ARICENT.COM>
Date: Sat, 21 Aug 2010 11:05:33 -0700
Message-ID: <AANLkTimF2QhCGj-NF3eMfLgcBGOM4v7g2GjK_AOrfckb@mail.gmail.com>
From: Greg Mirsky <gregimirsky@gmail.com>
To: Lavanya Srivatsa <lavanya.srivatsa@aricent.com>
Content-Type: multipart/alternative; boundary="001636284f88f8152f048e5942aa"
Cc: "mpls@ietf.org" <mpls@ietf.org>, rtg-bfd <rtg-bfd@ietf.org>, "gupta_rakesh62@yahoo.co.in" <gupta_rakesh62@yahoo.co.in>
Subject: Re: [mpls] BFD Packet Flow
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mpls>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 21 Aug 2010 18:05:02 -0000

Dear Lavanya,
I wouldn't consider LSP Ping based bootstrap of BFD session as extra
handshake. It is not required and exchange of Discriminator can be done with
help of NMS.

Regards,
Greg

On Sat, Aug 21, 2010 at 3:48 AM, Lavanya Srivatsa <
lavanya.srivatsa@aricent.com> wrote:

> Hi Yaacov, Greg and others,
>
> Does not the below sequence cause BFD to become a "4-way handshake" as
> opposed to a "3-way handshake" as it is intended to be?
>
> Should not the LSP Ping request packet be considered in lieu of the first
> BFD control packet that would have been sent in the case of "single-hop"
> neighbour monitoring BFD scenarios (as defined by the base BFD draft)?
> Is not the LSP Ping request packet bootstrapping the BFD discriminator
> being sent solely for the express purpose of "initiating" a BFD session
> establishment?
>
> If so, should not the receipt of an LSP Ping echo request packet carrying a
> BFD discriminator, cause the BFD state machine to move to INIT state (from
> DOWN)? Agreed, the LSP ping packet is _not_ a BFD packet and under any other
> circumstances, is not expected to affect/influence the BFD state machine,
> but for reasons mentioned above, would this not be a correct behaviour?
>
> If so, step 3 below, would become -
> 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=Init to LSR-A, whose
> session still in Down State.
>
> This would cause the remaining steps to collapse to:
> 4. LSR-A receives the BFD Control and switches to Up state (as per
> RFC5880 receving an Init state when in Down state), and sends a BFD
> Control Packet with State=Up to LSR-Z
>
> 5. LSR-Z receives the BFD Control and switches to UP state
>
> The above would ensure that the BFD handshake is still "3-way: -
> 1. Ping from LSR-A to LSR-Z
> 2. BFD-Init from LSR-Z to LSR-A
> 3. BFD-Up from LSR-A to LSR-Z
>
> Please let me know if I am missing something here.
>
> - Lavanya
>
>
>
> Date: Thu, 19 Aug 2010 11:08:30 +0200
> From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)"
>        <yaacov.weingarten@nsn.com>
> Subject: RE: [mpls] BFD Packet Flow
> To: "ext Dave Katz" <dkatz@juniper.net>,        "RAKESH GUPTA"
>         <gupta_rakesh62@yahoo.co.in>
> Cc: mpls@ietf.org, rtg-bfd@ietf.org
>
> 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
>
> [LS] Does this not make the entire BFD session establishment as a 4-way
> handshake rather than a 3-way handshake?
>
> 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?
>
>
>
> Thanx and BR,
>
> Yaacov Weingarten
>
> Nokia Siemens Networks
>
>
>
> ________________________________
>
> From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On
> Behalf Of ext Dave Katz
> Sent: Saturday, August 14, 2010 00:39
> To: RAKESH GUPTA
> Cc: mpls@ietf.org; rtg-bfd@ietf.org WG
> Subject: Re: [mpls] BFD Packet Flow
>
>
>
> I suppose the source of confusion might be RFC 5884's choice of
> verbiage:
>
>
>
>   On receipt of the LSP Ping Echo request message, the egress LSR MUST
>   send a BFD Control packet to the ingress LSR...
>
> This might give the impression that LSP Ping is just transmitting BFD
> control packets willy-nilly without any BFD context.  But it also says:
>
>  A BFD session is bootstrapped using LSP Ping.
>
> and
>
>   A BFD session may be established for a FEC associated with an MPLS
> LSP.
>
> This seems unambiguous that a BFD session is being established, and the
> procedure for doing so is spelled out clearly in RFC 5880.  I believe
> the following to be unambiguous:
>
>   State (Sta)
>      Set to the value indicated by bfd.SessionState.
>
> and
>
>   bfd.SessionState
>      ...This variable MUST be initialized to Down.
>
> One might be tempted to start in Init state in order to save one packet
> during session establishment, but in doing so one would be breaking the
> semantics of the protocol, in particular the three-way handshake through
> session failure.
>
> --Dave
>
>
> On Aug 12, 2010, at 4:20 AM, RAKESH GUPTA wrote:
> hi,
>
> I have query regarding BFD packet flow when LSP Ping is used for
> bootstrapping.
>
> As per my understanding from the RFC 5880 and RFC 5884 when LSP Ping is
> used for bootstrapping the remote end MUST reply with BFD control in
> response to the LSPPing.
>
> The specification does not clearly specify about the Stat parameter
> value that should be returned in the response of LSPPing. Should it have
> the value Init or Down? Or it might be possible to return no stat
> information.
>
> Can someone please share the exact packet flow that happens during BFD
> session set up with LSPPing in Bootstrap till the session comes into UP
> state?
>
> thanks a lot in advance for ur help,
> rakesh
>
> "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."
>