Return-Path: 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 6FEB13A6852; Fri, 13 Aug 2010 14:47:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 QOmCu364rMmH; Fri, 13 Aug 2010 14:47:08 -0700 (PDT) Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by core3.amsl.com (Postfix) with ESMTP id 9A2AA3A67F0; Fri, 13 Aug 2010 14:47:04 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKTGW9ezuL5LC7xqrOeNCAw6B0nDEWBOGe@postini.com; Fri, 13 Aug 2010 14:47:41 PDT Received: from merlot.juniper.net (172.17.27.10) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 13 Aug 2010 14:39:21 -0700 Received: from nimbus-sf.juniper.net (nimbus-sf.juniper.net [172.16.12.139]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id o7DLdKb52461; Fri, 13 Aug 2010 14:39:20 -0700 (PDT) (envelope-from dkatz@juniper.net) MIME-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary="Apple-Mail-158-633166095" From: Dave Katz In-Reply-To: <538950.60100.qm@web94001.mail.in2.yahoo.com> Date: Fri, 13 Aug 2010 15:39:20 -0600 Message-ID: <8F235FED-E707-48FE-9713-4AEB4746241C@juniper.net> References: <538950.60100.qm@web94001.mail.in2.yahoo.com> To: RAKESH GUPTA X-Mailer: Apple Mail (2.1081) Cc: mpls@ietf.org, "rtg-bfd@ietf.org WG" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Aug 2010 21:47:21 -0000 --Apple-Mail-158-633166095 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" 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. =20 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, >=20 > I have query regarding BFD packet flow when LSP Ping is used for = bootstrapping.=20 >=20 > 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. >=20 > 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. >=20 > 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? >=20 > thanks a lot in advance for ur help, > rakesh >=20 >=20 > _______________________________________________ > mpls mailing list > mpls@ietf.org > https://www.ietf.org/mailman/listinfo/mpls --Apple-Mail-158-633166095 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="us-ascii" = 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/ma= ilman/listinfo/mpls

= --Apple-Mail-158-633166095--