Re: [mpls] BFD Packet Flow

xiao.min2@zte.com.cn Mon, 23 August 2010 03:08 UTC

Return-Path: <xiao.min2@zte.com.cn>
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 E70073A679F; Sun, 22 Aug 2010 20:08:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -98.286
X-Spam-Level:
X-Spam-Status: No, score=-98.286 tagged_above=-999 required=5 tests=[AWL=-1.851, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, J_CHICKENPOX_54=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, USER_IN_WHITELIST=-100]
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 xmwTWbikHdQq; Sun, 22 Aug 2010 20:08:35 -0700 (PDT)
Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 4BB3D3A680A; Sun, 22 Aug 2010 20:08:32 -0700 (PDT)
Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 205951791264950; Mon, 23 Aug 2010 11:07:33 +0800 (CST)
Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 79154.6119633634; Mon, 23 Aug 2010 10:59:29 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o7N38jdp022819; Mon, 23 Aug 2010 11:08:45 +0800 (CST) (envelope-from xiao.min2@zte.com.cn)
In-Reply-To: <AANLkTin6sP5AUL6ahTa1m=Bbx1mGjPT37Yk3C7BaTj0S@mail.gmail.com>
To: Greg Mirsky <gregimirsky@gmail.com>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005
Message-ID: <OFDFE55158.5979EF5E-ON48257788.000F6B3E-48257788.00112FCB@zte.com.cn>
From: xiao.min2@zte.com.cn
Date: Mon, 23 Aug 2010 11:08:31 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-08-23 11:08:41, Serialize complete at 2010-08-23 11:08:41
Content-Type: multipart/alternative; boundary="=_alternative 00112FCA48257788_="
X-MAIL: mse2.zte.com.cn o7N38jdp022819
Cc: mpls@ietf.org, rtg-bfd@ietf.org, RAKESH GUPTA <gupta_rakesh62@yahoo.co.in>, mpls-bounces@ietf.org
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: Mon, 23 Aug 2010 03:08:38 -0000

Hi Greg,

Acc to section 6 (the second paragraph) of RFC 5884:
 "The egress LSR MAY respond with an LSP Ping Echo
reply message that carries the local discriminator assigned by it for
the BFD session."
So it should be said like that in step 3, there MAY be another action for 
the LSR-Z to respond with an LSP Ping Echo reply, but it's not must.

And I have a small comment on step 2, "both sessions still in Down state" 
may be inaccurate and "both session ends still in Down state" is better.

Best Regards,
Xiao Min




Greg Mirsky <gregimirsky@gmail.com> 
·¢¼þÈË:  mpls-bounces@ietf.org
2010/08/20 00:21

ÊÕ¼þÈË
"Weingarten, Yaacov (NSN - IL/Hod HaSharon)" <yaacov.weingarten@nsn.com>
³­ËÍ
mpls@ietf.org, rtg-bfd@ietf.org, RAKESH GUPTA <gupta_rakesh62@yahoo.co.in>
Ö÷Ìâ
Re: [mpls] BFD Packet Flow






Dear Yaacov,
it is my understanding, that after receiving LSP Ping Request (step 3) 
LSR-Z must send LSP Ping Reply with My Discriminator. Then, even if LSR-Z 
is in Passive mode, LSR-A will receive LSR-Z's discriminator and can 
advance to Init state.

Regards,
Greg

On Thu, Aug 19, 2010 at 2:08 AM, Weingarten, Yaacov (NSN - IL/Hod 
HaSharon) <yaacov.weingarten@nsn.com> wrote:
Hi, 
 
Just to verify that I understand the flow of messages and the state of the 
BFD Session ¨C is the following flow correct ¨C
 
Assume a LSP between LSR-A and LSR-Z ¨C
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 ¨C 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 ¨C regarding step 3 above ¨C 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

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls
 

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls

_______________________________________________
mpls mailing list
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls