From jhaas@slice.pfrc.org Fri Aug 6 08:25:45 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 02B903A6A53 for ; Fri, 6 Aug 2010 08:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.462 X-Spam-Level: X-Spam-Status: No, score=-100.462 tagged_above=-999 required=5 tests=[AWL=-0.797, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334, 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 Yw9Ij9nWMwz4 for ; Fri, 6 Aug 2010 08:25:44 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by core3.amsl.com (Postfix) with ESMTP id 30AE33A6A97 for ; Fri, 6 Aug 2010 08:25:44 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id A677A22438B; Fri, 6 Aug 2010 15:26:15 +0000 (UTC) Date: Fri, 6 Aug 2010 15:26:15 +0000 From: Jeffrey Haas To: rtg-bfd@ietf.org Subject: Re: Draft Minutes from IETF 78, Maastricht Message-ID: <20100806152615.GA9741@slice> References: <5E893DB832F57341992548CDBB33316398450B3F0F@EMBX01-HQ.jnpr.net> <20100728092646.GA9998@slice> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20100728092646.GA9998@slice> User-Agent: Mutt/1.5.18 (2008-05-17) X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Aug 2010 15:25:45 -0000 There were no additions or corrections to the minutes and they have been posted on the website in spite of me writing the wrong month. :-) On Wed, Jul 28, 2010 at 09:26:46AM +0000, Jeffrey Haas wrote: > Thanks to Dave Ward for capturing minutes. Please submit additions or > corrections before Wednesday, September 1. -- Jeff From dkatz@juniper.net Fri Aug 13 14:47:21 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@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) Subject: Re: [mpls] BFD Packet Flow 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" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" 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-- From ibty.jamal@gmail.com Wed Aug 18 11:52:14 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 606FF3A6A04 for ; Wed, 18 Aug 2010 11:52:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_44=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 TSVMaM648z5e for ; Wed, 18 Aug 2010 11:52:13 -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 747B63A686B for ; Wed, 18 Aug 2010 11:52:13 -0700 (PDT) Received: by vws10 with SMTP id 10so934870vws.31 for ; Wed, 18 Aug 2010 11:52:48 -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=QbF+cJNdtBNeyRNaRtjZDtbzQVfAYqn2YxUVbh1AlFY=; b=QThf22A3G8lWOIFAW9ojZRvkbPEUjl6i4knJ5pZMZyLzi8NQlEo3ZVgE38SCu+yP0g QzmtvDZZ8I+3HdBsPE61JrGFwN4HlT1Ct9Ly8ZLrUjWKJ/1SjXsVA4v3YYKRfL78RQQj mXooyNyyYrnGjUfBbvCtRb0UMnzi+4RZ6RL34= 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=ThUIGDq+ponF06iUxnNg6LOvC/p/a28stF6KziqCFlWJO5oO55NA4SSda4rbXA29rV L7HkLjgbCO2NpWuu7EciuIbe8dKF1opdmvKUJ5SfNRecybVDRYCsdUtGweTDB4fWx980 bc8lBQMok/Zmf1Q/9ncN2UdyIvkmVk1pv3e6o= MIME-Version: 1.0 Received: by 10.220.121.134 with SMTP id h6mr4793834vcr.111.1282157568121; Wed, 18 Aug 2010 11:52:48 -0700 (PDT) Received: by 10.220.98.195 with HTTP; Wed, 18 Aug 2010 11:52:48 -0700 (PDT) In-Reply-To: References: Date: Wed, 18 Aug 2010 21:52:48 +0300 Message-ID: Subject: Re: BFD alternate path? From: ibtisam jamal To: Vishwas Manral Content-Type: text/plain; charset=ISO-8859-1 Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Aug 2010 18:52:14 -0000 Hi, I have a ring topology that uses bfd on interfaces to detect link failure. When bfd detects that a link is down .What happens to the already packaged packets on mpls level are they droped or rerouted to the next available path. logicaly speaking i think the packets already labeled will be dropped. on the other hand a few miliseconds later the link is reestablished and down again.What happens to these packets are they queued while mpls is recalculating the path or are they discarded. Another situation is when the link is up but has errors does bfd have anyway to detect this.when i monitor the interface i see that there is a mismatch in the IN packets and OUT packets but bfd is still up. What does bfd do when it detects these errors ? thanks , Ibtisam From dkatz@juniper.net Thu Aug 19 00:17:01 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9F6EE3A6896 for ; Thu, 19 Aug 2010 00:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_44=0.6, 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 wrkWdLeQZJsq for ; Thu, 19 Aug 2010 00:17:00 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id 6BDC53A6809 for ; Thu, 19 Aug 2010 00:17:00 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTGzajX+y7xOVFuKPuo5U6f/CidJsAAV+@postini.com; Thu, 19 Aug 2010 00:17:35 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; Thu, 19 Aug 2010 00:14:36 -0700 Received: from [172.16.12.57] ([172.16.12.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id o7J7EZb05810; Thu, 19 Aug 2010 00:14:35 -0700 (PDT) (envelope-from dkatz@juniper.net) Subject: Re: BFD alternate path? MIME-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset="us-ascii" From: Dave Katz In-Reply-To: Date: Thu, 19 Aug 2010 00:14:35 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: <81633AAC-9776-4D29-92FF-B65321476D2B@juniper.net> References: To: ibtisam jamal X-Mailer: Apple Mail (2.1081) Cc: rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 07:17:01 -0000 Much of this are implementation details that are not subject to = standardization; the answer would depend on a particular vendor's = implementation (and this list is not an appropriate place to discuss = vendor details). BFD does not detect errors, nor does it detect lost packets (nor can = it). Sessions generally fail due to session timeout, which typically = requires N lost packets in a row, where N is the multiplier value called = out in the spec. --Dave On Aug 18, 2010, at 11:52 AM, ibtisam jamal wrote: > Hi, >=20 > I have a ring topology that uses bfd on interfaces to detect link = failure. > When bfd detects that a link is down .What happens to the already > packaged packets on mpls level are they droped or rerouted to the next > available path. >=20 > logicaly speaking i think the packets already labeled will be dropped. >=20 > on the other hand a few miliseconds later the link is reestablished > and down again.What happens to these packets are they queued while > mpls is recalculating the path or are they discarded. >=20 > Another situation is when the link is up but has errors does bfd have > anyway to detect this.when i monitor the interface i see that there > is a mismatch in the IN packets and OUT packets but bfd is still up. >=20 > What does bfd do when it detects these errors ? >=20 > thanks , >=20 > Ibtisam >=20 From yaacov.weingarten@nsn.com Thu Aug 19 02:08:08 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68E823A6909; Thu, 19 Aug 2010 02:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.712 X-Spam-Level: X-Spam-Status: No, score=-1.712 tagged_above=-999 required=5 tests=[AWL=-0.314, 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 xftSHwZJK8HB; Thu, 19 Aug 2010 02:08:01 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 049C83A6908; Thu, 19 Aug 2010 02:08:00 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o7J98XFf013503 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 Aug 2010 11:08:33 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o7J98T1k021780; Thu, 19 Aug 2010 11:08:33 +0200 Received: from DEMUEXC030.nsn-intra.net ([10.150.128.57]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 19 Aug 2010 11:08:31 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB3F7E.1853262D" Subject: RE: [mpls] BFD Packet Flow Date: Thu, 19 Aug 2010 11:08:30 +0200 Message-ID: <62D9AC1F11702146A0387CBFF3A8CD3D0288E545@DEMUEXC030.nsn-intra.net> In-Reply-To: <8F235FED-E707-48FE-9713-4AEB4746241C@juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [mpls] BFD Packet Flow Thread-Index: Acs7MTYtpNk5kbyhSnCEDodsS3FdbQES1Zwg References: <538950.60100.qm@web94001.mail.in2.yahoo.com> <8F235FED-E707-48FE-9713-4AEB4746241C@juniper.net> From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" To: "ext Dave Katz" , "RAKESH GUPTA" X-OriginalArrivalTime: 19 Aug 2010 09:08:31.0812 (UTC) FILETIME=[18687840:01CB3F7E] Cc: mpls@ietf.org, rtg-bfd@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 09:08:08 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB3F7E.1853262D Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi,=20 =20 Just to verify that I understand the flow of messages and the state of the BFD Session - is the following flow correct - =20 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=3DDown 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=3DInit to LSR-Z 5. LSR-Z receives the BFD Control and switches to Up state, and sends a BFD Control Packet with State=3DUp to LSR-A 6. LSR-A receives the BFD Control and switches to UP state =20 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? =20 Thanx and BR, Yaacov Weingarten Nokia Siemens Networks =20 ________________________________ 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 =20 I suppose the source of confusion might be RFC 5884's choice of verbiage: =20 On receipt of the LSP Ping Echo request message, the egress LSR MUST send a BFD Control packet to the ingress LSR... =20 This might give the impression that LSP Ping is just transmitting BFD control packets willy-nilly without any BFD context. But it also says: =20 A BFD session is bootstrapped using LSP Ping. and =20 A BFD session may be established for a FEC associated with an MPLS LSP. =20 =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: =20 State (Sta) =20 Set to the value indicated by bfd.SessionState. =20 and =20 bfd.SessionState =20 ...This variable MUST be initialized to Down. =20 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. =20 --Dave =20 =20 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.=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. 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 =20 ------_=_NextPart_001_01CB3F7E.1853262D Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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=3DDown 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=3DInit to = LSR-Z

5. = LSR-Z receives the BFD Control and switches to Up state, and sends a BFD = Control Packet with State=3DUp 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?

 

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

 

------_=_NextPart_001_01CB3F7E.1853262D-- From gregimirsky@gmail.com Thu Aug 19 09:21:04 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A3C73A6966; Thu, 19 Aug 2010 09:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.717 X-Spam-Level: X-Spam-Status: No, score=-1.717 tagged_above=-999 required=5 tests=[AWL=-0.319, 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 EppGLuRRXgu4; Thu, 19 Aug 2010 09:21:02 -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 6EC423A6A2B; Thu, 19 Aug 2010 09:21:02 -0700 (PDT) Received: by vws10 with SMTP id 10so2084704vws.31 for ; Thu, 19 Aug 2010 09:21:37 -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=ahUSWczq+iUb9V/3Uhd2tAElKMlPbZxlmk3dPAQroiU=; b=FpuNlbKRVmt2NGTcE3Q6zADGJyJ73Kp12o7C4jBC1O35IQmrMlA3YG2CyxyF6i/Fg9 qMMalNCLTAehTpAdVvFWwM+YQo5EuiWNSi4itVFqr716Q47u+Hqmwpm004LB1q3vLybg dgFpcqUx7MG7hIAGeARgx+8aDBT5B341pBs7o= 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=kbuDCwvuPsg8fBw93qhjuaZuv6DaASZ+ZOFtAxuWrScf1q3RtoRnxNlQopB4491uX0 3f2q/afAi0bBrQAXGSqcsVRYRoyQ1vpjls2Ks3ZWRu0fD4HXQ9F3ajNU3APWxqRGwW8N kijWfnPkBQ8pX2Gm8SQjQCWCjq2YYqj9PjeDk= MIME-Version: 1.0 Received: by 10.220.99.21 with SMTP id s21mr38070vcn.82.1282234897020; Thu, 19 Aug 2010 09:21:37 -0700 (PDT) Received: by 10.220.105.69 with HTTP; Thu, 19 Aug 2010 09:21:36 -0700 (PDT) In-Reply-To: <62D9AC1F11702146A0387CBFF3A8CD3D0288E545@DEMUEXC030.nsn-intra.net> References: <538950.60100.qm@web94001.mail.in2.yahoo.com> <8F235FED-E707-48FE-9713-4AEB4746241C@juniper.net> <62D9AC1F11702146A0387CBFF3A8CD3D0288E545@DEMUEXC030.nsn-intra.net> Date: Thu, 19 Aug 2010 09:21:36 -0700 Message-ID: Subject: Re: [mpls] BFD Packet Flow From: Greg Mirsky To: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" Content-Type: multipart/alternative; boundary=0016e64e9d208e3831048e2f9348 Cc: mpls@ietf.org, rtg-bfd@ietf.org, RAKESH GUPTA , ext Dave Katz X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Aug 2010 16:21:04 -0000 --0016e64e9d208e3831048e2f9348 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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) wrote: > Hi, > > > > Just to verify that I understand the flow of messages and the state of th= e > BFD Session =96 is the following flow correct =96 > > > > Assume a LSP between LSR-A and LSR-Z =96 > > 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 =96 both sessions still in Down state. > > 3. LSR-Z receives the LSP-Ping, and (assuming that LSR-Z is in Active mod= e) > sends a BFD Control Packet with its own Discriminator, the Discriminator > received from the LSP-Ping, and State=3DDown 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=3DInit to LSR-Z > > 5. LSR-Z receives the BFD Control and switches to Up state, and sends a B= FD > Control Packet with State=3DUp to LSR-A > > 6. LSR-A receives the BFD Control and switches to UP state > > > > Additional question =96 regarding step 3 above =96 must LSR-Z be in Activ= e > mode? What happens if LSR-Z is in Passive mode and LSR-A is in Active mod= e? > > > > 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 va= lue > 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 > > --0016e64e9d208e3831048e2f9348 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Dear Yaacov,
it is my understanding, that after receiving LSP Ping Reque= st (step 3) LSR-Z must send LSP Ping Reply with My Discriminator. Then, eve= n 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) &= lt;yaacov.weingarten@nsn.com> wrote:

Hi,

=A0

Just to verify that I understand the flow of messages and the state of the BFD Session =96 is the following flow correct =96

=A0

Assume a LSP between LSR-A and LSR-Z =96

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 =96 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=3DDown 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 s= ends a BFD Control Packet with State=3DInit to LSR-Z

5. LSR-Z receives the BFD Control and switches to Up state, and sends a BFD Control Packet with State=3DUp to LSR-A

6. LSR-A receives the BFD Control and switches to UP state

=A0

Additional question =96 regarding step 3 above =96 must LSR-Z be in Active mode? What happens if LSR-Z is in Passive mode and LSR-A is in Active mode?

=A0

Thanx and BR,

Yaacov Weingarten

Nokia Siemens Networks

=A0

From:<= /span> rtg-bfd-bounc= es@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

=A0

I suppose the source of confusion might = be RFC 5884's choice of verbiage:

=A0

=A0=A0 On receipt of the LSP Ping Echo request me=
ssage, the egress LSR MUST
=
=A0=A0 send a BFD Control packet to the ingress LSR...=

=A0

This might give the impression that LSP = Ping is just transmitting BFD control packets willy-nilly without any BFD context. =A0Bu= t it also says:

=A0

=A0=A0 A BFD session is bootstrapped u=
sing LSP Ping.
<= span style=3D"font-size: 10.5pt; font-family: Monaco;">

and

=A0

=A0=A0 A BFD session may be established for a FEC=
 associated with an MPLS LSP.=A0

=A0

This seems unambiguous that a BFD sessio= n is being established, and the procedure for doing so is spelled out clearly in RFC 5= 880. =A0I believe the following to be unambiguous:

=A0

=A0=A0 State (Sta)
=A0 
=A0=A0=A0=A0=A0 Set to the value indicated by bfd.Sess=
ionState.
=A0
and
=A0
=A0=A0 bfd.SessionState
=A0 
=A0=A0=A0=A0=A0 ...This variable MUST be initialized t=
o Down.

=A0

One might be tempted to start in Init st= ate 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 handsha= ke through session failure.

=A0

--Dave

=A0

=A0

On Aug 12, 2010, at 4:20 AM, RAKESH GUPT= A 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 u= sed 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 va= lue 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
ht= tps://www.ietf.org/mailman/listinfo/mpls

=A0


_______________________________________________
mpls mailing list
mpls@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/mpls


--0016e64e9d208e3831048e2f9348-- From lavanya.srivatsa@aricent.com Sat Aug 21 03:47:46 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D11613A6872 for ; Sat, 21 Aug 2010 03:47:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.07 X-Spam-Level: X-Spam-Status: No, score=-1.07 tagged_above=-999 required=5 tests=[AWL=-1.530, BAYES_20=-0.74, 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 MDHgTfr6GH8x for ; Sat, 21 Aug 2010 03:47:45 -0700 (PDT) Received: from jaguar.aricent.com (jaguar.aricent.com [121.241.96.11]) by core3.amsl.com (Postfix) with ESMTP id 4DB193A6863 for ; Sat, 21 Aug 2010 03:47:45 -0700 (PDT) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id 5EAC636B38 for ; Sat, 21 Aug 2010 16:17:22 +0530 (IST) Received: from GUREXHT01.ASIAN.AD.ARICENT.COM (gurexht01.asian.ad.aricent.com [10.203.171.136]) by jaguar.aricent.com (Postfix) with ESMTP id 4934E36B34 for ; Sat, 21 Aug 2010 16:17:22 +0530 (IST) Received: from GUREXMB02.ASIAN.AD.ARICENT.COM ([10.203.171.134]) by GUREXHT01.ASIAN.AD.ARICENT.COM ([10.203.171.137]) with mapi; Sat, 21 Aug 2010 16:18:16 +0530 From: Lavanya Srivatsa To: rtg-bfd , "gregimirsky@gmail.com" , "yaacov.weingarten@nsn.com" Date: Sat, 21 Aug 2010 16:18:15 +0530 Subject: RE: [mpls] BFD Packet Flow Thread-Topic: [mpls] BFD Packet Flow Thread-Index: AQHLQR5cJtHYB/DNZUWc5isipg2+Lg== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "gupta_rakesh62@yahoo.co.in" , "dkatz@juniper.net" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2010 10:47:47 -0000 Hi Yaacov, Greg and others, Does not the below sequence cause BFD to become a "4-way handshake" as oppo= sed 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 B= FD control packet that would have been sent in the case of "single-hop" nei= ghbour monitoring BFD scenarios (as defined by the base BFD draft)? Is not the LSP Ping request packet bootstrapping the BFD discriminator bein= g sent solely for the express purpose of "initiating" a BFD session establi= shment? 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 oth= er 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=3DInit 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=20 Control Packet with State=3DUp 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)" Subject: RE: [mpls] BFD Packet Flow To: "ext Dave Katz" , "RAKESH GUPTA" 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=3DDown 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=3DInit to LSR-Z 5. LSR-Z receives the BFD Control and switches to Up state, and sends a BFD Control Packet with State=3DUp 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 han= dshake 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: =20 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= From gregimirsky@gmail.com Sat Aug 21 11:05:01 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@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 ; 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: References: Date: Sat, 21 Aug 2010 11:05:33 -0700 Message-ID: Subject: Re: [mpls] BFD Packet Flow From: Greg Mirsky To: Lavanya Srivatsa Content-Type: multipart/alternative; boundary=001636284f88f8152f048e5942aa Cc: "mpls@ietf.org" , rtg-bfd , "gupta_rakesh62@yahoo.co.in" , "dkatz@juniper.net" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2010 18:05:02 -0000 --001636284f88f8152f048e5942aa Content-Type: text/plain; charset=ISO-8859-1 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)" > > Subject: RE: [mpls] BFD Packet Flow > To: "ext Dave Katz" , "RAKESH GUPTA" > > 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." > --001636284f88f8152f048e5942aa Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear Lavanya,
I wouldn't consider LSP Ping based bootstrap of BFD se= ssion 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&quo= t; 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 B= FD 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 bein= g sent solely for the express purpose of "initiating" a BFD sessi= on 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 oth= er 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=3DInit 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=3DUp 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)"
=A0 =A0 =A0 =A0<yaacov.wei= ngarten@nsn.com>
Subject: RE: [mpls] BFD Packet Flow
To: "ext Dave Katz" <dkat= z@juniper.net>, =A0 =A0 =A0 =A0"RAKESH GUPTA"
=A0 =A0 =A0 =A0<gupta_rakesh62@yahoo.co.in>
Cc: mpls@ietf.org<= /a>, 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=3DDown 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=3DInit to LSR-Z

5. LSR-Z receives the BFD Control and switches to Up state, and sends a
BFD Control Packet with State=3DUp 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-w= ay 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<= /a> [mailto:rtg-bfd-bounces@iet= f.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:



=A0 On receipt of the LSP Ping Echo request message, the egress LSR MUST =A0 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. =A0But it also says:
=A0A BFD session is bootstrapped using LSP Ping.

and

=A0 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. =A0I believe
the following to be unambiguous:

=A0 State (Sta)
=A0 =A0 =A0Set to the value indicated by bfd.SessionState.

and

=A0 bfd.SessionState
=A0 =A0 =A0...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 circul= ated or used for any purpose other than for what it is intended. If you hav= e received this message in error, please notify the originator immediately.= If you are not the intended recipient, you are notified that you are stric= tly 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."

--001636284f88f8152f048e5942aa-- From dkatz@juniper.net Sat Aug 21 12:56:37 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 111B03A686D; Sat, 21 Aug 2010 12:56:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.848 X-Spam-Level: X-Spam-Status: No, score=-5.848 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, J_CHICKENPOX_54=0.6, 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 tpw2FqVRBleb; Sat, 21 Aug 2010 12:56:36 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with ESMTP id D4BBF3A67FE; Sat, 21 Aug 2010 12:56:35 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKTHAvke4HdaSgF5vlfJrdlLgi5s9rIgJL@postini.com; Sat, 21 Aug 2010 12:57:10 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; Sat, 21 Aug 2010 12:45:10 -0700 Received: from [172.16.12.57] ([172.16.12.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id o7LJjAb80454; Sat, 21 Aug 2010 12:45:10 -0700 (PDT) (envelope-from dkatz@juniper.net) Subject: Re: [mpls] BFD Packet Flow MIME-Version: 1.0 (Apple Message framework v1081) Content-Type: multipart/alternative; boundary="Apple-Mail-23--829968089" From: Dave Katz In-Reply-To: <62D9AC1F11702146A0387CBFF3A8CD3D0288E545@DEMUEXC030.nsn-intra.net> Date: Sat, 21 Aug 2010 12:45:09 -0700 Message-ID: <6F1E904F-CF1B-49B2-B8B7-088EA91CC661@juniper.net> References: <538950.60100.qm@web94001.mail.in2.yahoo.com> <8F235FED-E707-48FE-9713-4AEB4746241C@juniper.net> <62D9AC1F11702146A0387CBFF3A8CD3D0288E545@DEMUEXC030.nsn-intra.net> To: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" X-Mailer: Apple Mail (2.1081) Cc: mpls@ietf.org, rtg-bfd@ietf.org, RAKESH GUPTA X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2010 19:56:37 -0000 --Apple-Mail-23--829968089 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="windows-1252" On Aug 19, 2010, at 2:08 AM, Weingarten, Yaacov (NSN - IL/Hod HaSharon) = wrote: > Hi, > =20 > Just to verify that I understand the flow of messages and the state of = the BFD Session =96 is the following flow correct =96 > =20 > Assume a LSP between LSR-A and LSR-Z =96 > 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 =96 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=3DDown 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=3DInit to LSR-Z > 5. LSR-Z receives the BFD Control and switches to Up state, and sends = a BFD Control Packet with State=3DUp to LSR-A > 6. LSR-A receives the BFD Control and switches to UP state > =20 > Additional question =96 regarding step 3 above =96 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 --Apple-Mail-23--829968089 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset="windows-1252"
=

Hi,

 

Just to verify that I understand the flow of messages and the state of the BFD Session = =96 is the following flow correct =96

 

Assume a LSP between LSR-A and LSR-Z =96

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 =96 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=3DDown 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=3DInit to = LSR-Z

5. LSR-Z receives the BFD Control and switches to Up state, and sends a BFD = Control Packet with State=3DUp to LSR-A

6. LSR-A receives the BFD Control and switches to UP = state

 

Additional question =96 regarding step 3 above =96 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

= --Apple-Mail-23--829968089-- From dkatz@juniper.net Sat Aug 21 13:05:38 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F4393A67FE; Sat, 21 Aug 2010 13:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.699 X-Spam-Level: X-Spam-Status: No, score=-5.699 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, J_CHICKENPOX_54=0.6, 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 fFKYIoOa8LN1; Sat, 21 Aug 2010 13:05:36 -0700 (PDT) Received: from exprod7og109.obsmtp.com (exprod7og109.obsmtp.com [64.18.2.171]) by core3.amsl.com (Postfix) with ESMTP id 6CF803A67B2; Sat, 21 Aug 2010 13:05:08 -0700 (PDT) Received: from source ([66.129.224.36]) (using TLSv1) by exprod7ob109.postini.com ([64.18.6.12]) with SMTP ID DSNKTHAxlUOUu7uxgqgKqiwU36zRYyn/60a1@postini.com; Sat, 21 Aug 2010 13:06:10 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; Sat, 21 Aug 2010 12:54:01 -0700 Received: from [172.16.12.57] ([172.16.12.57]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id o7LJs0b80820; Sat, 21 Aug 2010 12:54:00 -0700 (PDT) (envelope-from dkatz@juniper.net) Subject: Re: [mpls] BFD Packet Flow MIME-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset="us-ascii" From: Dave Katz In-Reply-To: Date: Sat, 21 Aug 2010 12:53:59 -0700 Content-Transfer-Encoding: quoted-printable Message-ID: References: To: Lavanya Srivatsa X-Mailer: Apple Mail (2.1081) Cc: rtg-bfd , "gupta_rakesh62@yahoo.co.in" , "mpls@ietf.org" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Aug 2010 20:05:38 -0000 This is really about trying to optimize an exchange that most likely = isn't worth optimizing (and could potentially lead to protocol failure = in some implementation circumstances.) The reason that BFD requires an exchange of BFD packets before leaving = Down state is to absolutely ensure, from the vantage point of the = protocol, that both sides agree that the session is down. Clearly if a = BFD session is being created for the first time, both ends understand = that the session is down and thus there can be no ambiguity. However, one could posit a situation where MPLS has hiccuped somehow and = wants to restart the process and the same discriminator is delivered. = If it started in Init state, the other end could potentially be in Up = state and so the fact that one end cycled the session would be lost. One could claim that This Can't Happen for various reasons, or that it = Doesn't Matter for various other reasons, but the protocol must be = self-protecting in general and not make assumptions about what might not = matter or what the external conditions are. The protocol is written the = way it is to *guarantee* that both sides understand that a session was = down. To respond directly, yes, there is a fourth packet flying here, but it's = not a BFD packet. Think of it as the BFD configuration being = provisioned instead--does a configuration action in other circumstances = qualify as a "fourth way"? --Dave On Aug 21, 2010, at 3:48 AM, Lavanya Srivatsa wrote: > Hi Yaacov, Greg and others, >=20 > 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? >=20 > 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? >=20 > 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? >=20 > 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=3DInit to LSR-A, = whose > session still in Down State. >=20 > 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=20 > Control Packet with State=3DUp to LSR-Z >=20 > 5. LSR-Z receives the BFD Control and switches to UP state >=20 > 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 >=20 > Please let me know if I am missing something here. >=20 > - Lavanya >=20 >=20 >=20 > Date: Thu, 19 Aug 2010 11:08:30 +0200 > From: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" > > Subject: RE: [mpls] BFD Packet Flow > To: "ext Dave Katz" , "RAKESH GUPTA" > > Cc: mpls@ietf.org, rtg-bfd@ietf.org >=20 > Hi, >=20 >=20 >=20 > Just to verify that I understand the flow of messages and the state of > the BFD Session - is the following flow correct - >=20 >=20 >=20 > Assume a LSP between LSR-A and LSR-Z - >=20 > 1. Both LSRs initialize the BFD Session and set the state to Down >=20 > 2. LSR-A (the ingress LSR) sends a LSP-Ping (with the Discriminator = TLV) > to LSR-Z - both sessions still in Down state. >=20 > 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=3DDown to LSR-A, = both > session still in Down State. >=20 > 4. LSR-A receives the BFD Control and switches to Init state (as per > RFC5880), and sends a BFD Control Packet with State=3DInit to LSR-Z >=20 > 5. LSR-Z receives the BFD Control and switches to Up state, and sends = a > BFD Control Packet with State=3DUp to LSR-A >=20 > 6. LSR-A receives the BFD Control and switches to UP state >=20 > [LS] Does this not make the entire BFD session establishment as a = 4-way handshake rather than a 3-way handshake? >=20 > 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? >=20 >=20 >=20 > Thanx and BR, >=20 > Yaacov Weingarten >=20 > Nokia Siemens Networks >=20 >=20 >=20 > ________________________________ >=20 > 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 >=20 >=20 >=20 > I suppose the source of confusion might be RFC 5884's choice of > verbiage: >=20 >=20 >=20 > On receipt of the LSP Ping Echo request message, the egress LSR MUST > send a BFD Control packet to the ingress LSR... >=20 > This might give the impression that LSP Ping is just transmitting BFD > control packets willy-nilly without any BFD context. But it also = says: >=20 > A BFD session is bootstrapped using LSP Ping. >=20 > and >=20 > 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: >=20 > State (Sta) > Set to the value indicated by bfd.SessionState. >=20 > and >=20 > bfd.SessionState > ...This variable MUST be initialized to Down. >=20 > 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. >=20 > --Dave >=20 >=20 > 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 > 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 From xiao.min2@zte.com.cn Sun Aug 22 20:08:38 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@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: To: Greg Mirsky Subject: Re: Re: [mpls] BFD Packet Flow MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: 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 , mpls-bounces@ietf.org X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 03:08:38 -0000 This is a multipart message in MIME format. --=_alternative 00112FCA48257788_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgR3JlZywNCg0KQWNjIHRvIHNlY3Rpb24gNiAodGhlIHNlY29uZCBwYXJhZ3JhcGgpIG9mIFJG QyA1ODg0Og0KICJUaGUgZWdyZXNzIExTUiBNQVkgcmVzcG9uZCB3aXRoIGFuIExTUCBQaW5nIEVj aG8NCnJlcGx5IG1lc3NhZ2UgdGhhdCBjYXJyaWVzIHRoZSBsb2NhbCBkaXNjcmltaW5hdG9yIGFz c2lnbmVkIGJ5IGl0IGZvcg0KdGhlIEJGRCBzZXNzaW9uLiINClNvIGl0IHNob3VsZCBiZSBzYWlk IGxpa2UgdGhhdCBpbiBzdGVwIDMsIHRoZXJlIE1BWSBiZSBhbm90aGVyIGFjdGlvbiBmb3IgDQp0 aGUgTFNSLVogdG8gcmVzcG9uZCB3aXRoIGFuIExTUCBQaW5nIEVjaG8gcmVwbHksIGJ1dCBpdCdz IG5vdCBtdXN0Lg0KDQpBbmQgSSBoYXZlIGEgc21hbGwgY29tbWVudCBvbiBzdGVwIDIsICJib3Ro IHNlc3Npb25zIHN0aWxsIGluIERvd24gc3RhdGUiIA0KbWF5IGJlIGluYWNjdXJhdGUgYW5kICJi b3RoIHNlc3Npb24gZW5kcyBzdGlsbCBpbiBEb3duIHN0YXRlIiBpcyBiZXR0ZXIuDQoNCkJlc3Qg UmVnYXJkcywNClhpYW8gTWluDQoNCg0KDQoNCkdyZWcgTWlyc2t5IDxncmVnaW1pcnNreUBnbWFp bC5jb20+IA0Kt6K8/sjLOiAgbXBscy1ib3VuY2VzQGlldGYub3JnDQoyMDEwLzA4LzIwIDAwOjIx DQoNCsrVvP7Iyw0KIldlaW5nYXJ0ZW4sIFlhYWNvdiAoTlNOIC0gSUwvSG9kIEhhU2hhcm9uKSIg PHlhYWNvdi53ZWluZ2FydGVuQG5zbi5jb20+DQqzrcvNDQptcGxzQGlldGYub3JnLCBydGctYmZk QGlldGYub3JnLCBSQUtFU0ggR1VQVEEgPGd1cHRhX3Jha2VzaDYyQHlhaG9vLmNvLmluPg0K1vfM 4g0KUmU6IFttcGxzXSBCRkQgUGFja2V0IEZsb3cNCg0KDQoNCg0KDQoNCkRlYXIgWWFhY292LA0K aXQgaXMgbXkgdW5kZXJzdGFuZGluZywgdGhhdCBhZnRlciByZWNlaXZpbmcgTFNQIFBpbmcgUmVx dWVzdCAoc3RlcCAzKSANCkxTUi1aIG11c3Qgc2VuZCBMU1AgUGluZyBSZXBseSB3aXRoIE15IERp c2NyaW1pbmF0b3IuIFRoZW4sIGV2ZW4gaWYgTFNSLVogDQppcyBpbiBQYXNzaXZlIG1vZGUsIExT Ui1BIHdpbGwgcmVjZWl2ZSBMU1ItWidzIGRpc2NyaW1pbmF0b3IgYW5kIGNhbiANCmFkdmFuY2Ug dG8gSW5pdCBzdGF0ZS4NCg0KUmVnYXJkcywNCkdyZWcNCg0KT24gVGh1LCBBdWcgMTksIDIwMTAg YXQgMjowOCBBTSwgV2VpbmdhcnRlbiwgWWFhY292IChOU04gLSBJTC9Ib2QgDQpIYVNoYXJvbikg PHlhYWNvdi53ZWluZ2FydGVuQG5zbi5jb20+IHdyb3RlOg0KSGksIA0KIA0KSnVzdCB0byB2ZXJp ZnkgdGhhdCBJIHVuZGVyc3RhbmQgdGhlIGZsb3cgb2YgbWVzc2FnZXMgYW5kIHRoZSBzdGF0ZSBv ZiB0aGUgDQpCRkQgU2Vzc2lvbiCoQyBpcyB0aGUgZm9sbG93aW5nIGZsb3cgY29ycmVjdCCoQw0K IA0KQXNzdW1lIGEgTFNQIGJldHdlZW4gTFNSLUEgYW5kIExTUi1aIKhDDQoxLiBCb3RoIExTUnMg aW5pdGlhbGl6ZSB0aGUgQkZEIFNlc3Npb24gYW5kIHNldCB0aGUgc3RhdGUgdG8gRG93bg0KMi4g TFNSLUEgKHRoZSBpbmdyZXNzIExTUikgc2VuZHMgYSBMU1AtUGluZyAod2l0aCB0aGUgRGlzY3Jp bWluYXRvciBUTFYpIA0KdG8gTFNSLVogqEMgYm90aCBzZXNzaW9ucyBzdGlsbCBpbiBEb3duIHN0 YXRlLg0KMy4gTFNSLVogcmVjZWl2ZXMgdGhlIExTUC1QaW5nLCBhbmQgKGFzc3VtaW5nIHRoYXQg TFNSLVogaXMgaW4gQWN0aXZlIA0KbW9kZSkgc2VuZHMgYSBCRkQgQ29udHJvbCBQYWNrZXQgd2l0 aCBpdHMgb3duIERpc2NyaW1pbmF0b3IsIHRoZSANCkRpc2NyaW1pbmF0b3IgcmVjZWl2ZWQgZnJv bSB0aGUgTFNQLVBpbmcsIGFuZCBTdGF0ZT1Eb3duIHRvIExTUi1BLCBib3RoIA0Kc2Vzc2lvbiBz dGlsbCBpbiBEb3duIFN0YXRlLg0KNC4gTFNSLUEgcmVjZWl2ZXMgdGhlIEJGRCBDb250cm9sIGFu ZCBzd2l0Y2hlcyB0byBJbml0IHN0YXRlIChhcyBwZXIgDQpSRkM1ODgwKSwgYW5kIHNlbmRzIGEg QkZEIENvbnRyb2wgUGFja2V0IHdpdGggU3RhdGU9SW5pdCB0byBMU1ItWg0KNS4gTFNSLVogcmVj ZWl2ZXMgdGhlIEJGRCBDb250cm9sIGFuZCBzd2l0Y2hlcyB0byBVcCBzdGF0ZSwgYW5kIHNlbmRz IGEgDQpCRkQgQ29udHJvbCBQYWNrZXQgd2l0aCBTdGF0ZT1VcCB0byBMU1ItQQ0KNi4gTFNSLUEg cmVjZWl2ZXMgdGhlIEJGRCBDb250cm9sIGFuZCBzd2l0Y2hlcyB0byBVUCBzdGF0ZQ0KIA0KQWRk aXRpb25hbCBxdWVzdGlvbiCoQyByZWdhcmRpbmcgc3RlcCAzIGFib3ZlIKhDIG11c3QgTFNSLVog YmUgaW4gQWN0aXZlIA0KbW9kZT8gV2hhdCBoYXBwZW5zIGlmIExTUi1aIGlzIGluIFBhc3NpdmUg bW9kZSBhbmQgTFNSLUEgaXMgaW4gQWN0aXZlIA0KbW9kZT8NCiANClRoYW54IGFuZCBCUiwNCllh YWNvdiBXZWluZ2FydGVuDQpOb2tpYSBTaWVtZW5zIE5ldHdvcmtzDQogDQoNCkZyb206IHJ0Zy1i ZmQtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnJ0Zy1iZmQtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIA0KT2YgZXh0IERhdmUgS2F0eg0KU2VudDogU2F0dXJkYXksIEF1Z3VzdCAxNCwgMjAx MCAwMDozOQ0KVG86IFJBS0VTSCBHVVBUQQ0KDQpDYzogbXBsc0BpZXRmLm9yZzsgcnRnLWJmZEBp ZXRmLm9yZyBXRw0KU3ViamVjdDogUmU6IFttcGxzXSBCRkQgUGFja2V0IEZsb3cNCiANCkkgc3Vw cG9zZSB0aGUgc291cmNlIG9mIGNvbmZ1c2lvbiBtaWdodCBiZSBSRkMgNTg4NCdzIGNob2ljZSBv ZiB2ZXJiaWFnZToNCiANCiAgIE9uIHJlY2VpcHQgb2YgdGhlIExTUCBQaW5nIEVjaG8gcmVxdWVz dCBtZXNzYWdlLCB0aGUgZWdyZXNzIExTUiBNVVNUDQogICBzZW5kIGEgQkZEIENvbnRyb2wgcGFj a2V0IHRvIHRoZSBpbmdyZXNzIExTUi4uLg0KIA0KVGhpcyBtaWdodCBnaXZlIHRoZSBpbXByZXNz aW9uIHRoYXQgTFNQIFBpbmcgaXMganVzdCB0cmFuc21pdHRpbmcgQkZEIA0KY29udHJvbCBwYWNr ZXRzIHdpbGx5LW5pbGx5IHdpdGhvdXQgYW55IEJGRCBjb250ZXh0LiAgQnV0IGl0IGFsc28gc2F5 czoNCiANCiAgIEEgQkZEIHNlc3Npb24gaXMgYm9vdHN0cmFwcGVkIHVzaW5nIExTUCBQaW5nLg0K DQphbmQNCiANCiAgIEEgQkZEIHNlc3Npb24gbWF5IGJlIGVzdGFibGlzaGVkIGZvciBhIEZFQyBh c3NvY2lhdGVkIHdpdGggYW4gTVBMUyANCkxTUC4gIA0KIA0KVGhpcyBzZWVtcyB1bmFtYmlndW91 cyB0aGF0IGEgQkZEIHNlc3Npb24gaXMgYmVpbmcgZXN0YWJsaXNoZWQsIGFuZCB0aGUgDQpwcm9j ZWR1cmUgZm9yIGRvaW5nIHNvIGlzIHNwZWxsZWQgb3V0IGNsZWFybHkgaW4gUkZDIDU4ODAuICBJ IGJlbGlldmUgdGhlIA0KZm9sbG93aW5nIHRvIGJlIHVuYW1iaWd1b3VzOg0KIA0KICAgU3RhdGUg KFN0YSkNCiANCiAgICAgIFNldCB0byB0aGUgdmFsdWUgaW5kaWNhdGVkIGJ5IGJmZC5TZXNzaW9u U3RhdGUuDQogDQphbmQNCiANCiAgIGJmZC5TZXNzaW9uU3RhdGUNCiANCiAgICAgIC4uLlRoaXMg dmFyaWFibGUgTVVTVCBiZSBpbml0aWFsaXplZCB0byBEb3duLg0KIA0KT25lIG1pZ2h0IGJlIHRl bXB0ZWQgdG8gc3RhcnQgaW4gSW5pdCBzdGF0ZSBpbiBvcmRlciB0byBzYXZlIG9uZSBwYWNrZXQg DQpkdXJpbmcgc2Vzc2lvbiBlc3RhYmxpc2htZW50LCBidXQgaW4gZG9pbmcgc28gb25lIHdvdWxk IGJlIGJyZWFraW5nIHRoZSANCnNlbWFudGljcyBvZiB0aGUgcHJvdG9jb2wsIGluIHBhcnRpY3Vs YXIgdGhlIHRocmVlLXdheSBoYW5kc2hha2UgdGhyb3VnaCANCnNlc3Npb24gZmFpbHVyZS4NCiAN Ci0tRGF2ZQ0KIA0KIA0KT24gQXVnIDEyLCAyMDEwLCBhdCA0OjIwIEFNLCBSQUtFU0ggR1VQVEEg d3JvdGU6DQoNCg0KDQpoaSwNCg0KSSBoYXZlIHF1ZXJ5IHJlZ2FyZGluZyBCRkQgcGFja2V0IGZs b3cgd2hlbiBMU1AgUGluZyBpcyB1c2VkIGZvciANCmJvb3RzdHJhcHBpbmcuIA0KDQpBcyBwZXIg bXkgdW5kZXJzdGFuZGluZyBmcm9tIHRoZSBSRkMgNTg4MCBhbmQgUkZDIDU4ODQgd2hlbiBMU1Ag UGluZyBpcyANCnVzZWQgZm9yIGJvb3RzdHJhcHBpbmcgdGhlIHJlbW90ZSBlbmQgTVVTVCByZXBs eSB3aXRoIEJGRCBjb250cm9sIGluIA0KcmVzcG9uc2UgdG8gdGhlIExTUFBpbmcuDQoNClRoZSBz cGVjaWZpY2F0aW9uIGRvZXMgbm90IGNsZWFybHkgc3BlY2lmeSBhYm91dCB0aGUgU3RhdCBwYXJh bWV0ZXIgdmFsdWUgDQp0aGF0IHNob3VsZCBiZSByZXR1cm5lZCBpbiB0aGUgcmVzcG9uc2Ugb2Yg TFNQUGluZy4gU2hvdWxkIGl0IGhhdmUgdGhlIA0KdmFsdWUgSW5pdCBvciBEb3duPyBPciBpdCBt aWdodCBiZSBwb3NzaWJsZSB0byByZXR1cm4gbm8gc3RhdCBpbmZvcm1hdGlvbi4NCg0KQ2FuIHNv bWVvbmUgcGxlYXNlIHNoYXJlIHRoZSBleGFjdCBwYWNrZXQgZmxvdyB0aGF0IGhhcHBlbnMgZHVy aW5nIEJGRCANCnNlc3Npb24gc2V0IHVwIHdpdGggTFNQUGluZyBpbiBCb290c3RyYXAgdGlsbCB0 aGUgc2Vzc2lvbiBjb21lcyBpbnRvIFVQIA0Kc3RhdGU/DQoNCnRoYW5rcyBhIGxvdCBpbiBhZHZh bmNlIGZvciB1ciBoZWxwLA0KcmFrZXNoDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQptcGxzIG1haWxpbmcgbGlzdA0KbXBsc0BpZXRmLm9yZw0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxzDQogDQoNCl9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptcGxzIG1haWxpbmcgbGlzdA0K bXBsc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9tcGxz DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQptcGxz IG1haWxpbmcgbGlzdA0KbXBsc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9tcGxzDQoNCg0K --=_alternative 00112FCA48257788_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0zIGZhY2U9InNhbnMtc2VyaWYiPkhpIEdyZWcsPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5BY2MgdG8gc2VjdGlvbiA2ICh0 aGUgc2Vjb25kIHBhcmFncmFwaCkNCm9mIFJGQyA1ODg0OjwvZm9udD4NCjxicj48Zm9udCBzaXpl PTMgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7JnF1b3Q7PC9mb250Pjxmb250IHNpemU9Mz48dHQ+ VGhlDQplZ3Jlc3MgTFNSIE1BWSByZXNwb25kIHdpdGggYW4gTFNQIFBpbmcgRWNobzxicj4NCnJl cGx5IG1lc3NhZ2UgdGhhdCBjYXJyaWVzIHRoZSBsb2NhbCBkaXNjcmltaW5hdG9yIGFzc2lnbmVk IGJ5IGl0IGZvcjxicj4NCnRoZSBCRkQgc2Vzc2lvbi4mcXVvdDs8L3R0PjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTM+PHR0PlNvIGl0IHNob3VsZCBiZSBzYWlkIGxpa2UgdGhhdCBpbiBzdGVwIDMs IHRoZXJlIE1BWQ0KYmUgYW5vdGhlciBhY3Rpb24gZm9yIDwvdHQ+PC9mb250Pg0KPGJyPjxmb250 IHNpemU9Mz48dHQ+dGhlIExTUi1aIHRvIHJlc3BvbmQgd2l0aCBhbiBMU1AgUGluZyBFY2hvIHJl cGx5LA0KYnV0IGl0J3Mgbm90IG11c3QuPC90dD48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6 ZT0zPjx0dD5BbmQgSSBoYXZlIGEgc21hbGwgY29tbWVudCBvbiBzdGVwIDIsICZxdW90O2JvdGgg c2Vzc2lvbnMNCnN0aWxsIGluIERvd24gc3RhdGUmcXVvdDsgPC90dD48L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0zPjx0dD5tYXkgYmUgaW5hY2N1cmF0ZSBhbmQgJnF1b3Q7Ym90aCBzZXNzaW9uIGVu ZHMgc3RpbGwNCmluIERvd24gc3RhdGUmcXVvdDsgaXMgYmV0dGVyLjwvdHQ+PC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5CZXN0IFJlZ2FyZHMsPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MyBmYWNlPSJzYW5zLXNlcmlmIj5YaWFvIE1pbjwvZm9udD4NCjxi cj4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+ DQo8dGQgd2lkdGg9MzUlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5HcmVnIE1p cnNreSAmbHQ7Z3JlZ2ltaXJza3lAZ21haWwuY29tJmd0OzwvYj4NCjwvZm9udD4NCjxicj48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJzcDttcGxzLWJvdW5jZXNAaWV0 Zi5vcmc8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAxMC8wOC8y MCAwMDoyMTwvZm9udD4NCjx0ZCB3aWR0aD02NCU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2 YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj4mcXVvdDtXZWluZ2FydGVuLCBZYWFjb3YgKE5TTiAtIElML0hvZA0KSGFTaGFyb24p JnF1b3Q7ICZsdDt5YWFjb3Yud2VpbmdhcnRlbkBuc24uY29tJmd0OzwvZm9udD4NCjx0ciB2YWxp Z249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+bXBsc0BpZXRmLm9yZywgcnRnLWJmZEBpZXRmLm9yZywgUkFLRVNIDQpHVVBUQSAmbHQ7Z3Vw dGFfcmFrZXNoNjJAeWFob28uY28uaW4mZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+ DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9m b250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SZTogW21wbHNd IEJGRCBQYWNrZXQgRmxvdzwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGln bj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJy Pjxmb250IHNpemU9Mz5EZWFyIFlhYWNvdiw8YnI+DQppdCBpcyBteSB1bmRlcnN0YW5kaW5nLCB0 aGF0IGFmdGVyIHJlY2VpdmluZyBMU1AgUGluZyBSZXF1ZXN0IChzdGVwIDMpDQpMU1ItWiBtdXN0 IHNlbmQgTFNQIFBpbmcgUmVwbHkgd2l0aCBNeSBEaXNjcmltaW5hdG9yLiBUaGVuLCBldmVuIGlm IExTUi1aDQppcyBpbiBQYXNzaXZlIG1vZGUsIExTUi1BIHdpbGwgcmVjZWl2ZSBMU1ItWidzIGRp c2NyaW1pbmF0b3IgYW5kIGNhbiBhZHZhbmNlDQp0byBJbml0IHN0YXRlLjxicj4NCjxicj4NClJl Z2FyZHMsPGJyPg0KR3JlZzxicj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTM+T24gVGh1LCBB dWcgMTksIDIwMTAgYXQgMjowOCBBTSwgV2VpbmdhcnRlbiwgWWFhY292IChOU04NCi0gSUwvSG9k IEhhU2hhcm9uKSAmbHQ7PC9mb250PjxhIGhyZWY9bWFpbHRvOnlhYWNvdi53ZWluZ2FydGVuQG5z bi5jb20+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWU+PHU+eWFhY292LndlaW5nYXJ0ZW5AbnNuLmNv bTwvdT48L2ZvbnQ+PC9hPjxmb250IHNpemU9Mz4mZ3Q7DQp3cm90ZTo8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGNvbG9yPSMwMDAwODAgZmFjZT0iQ29taWMgU2FucyBNUyI+SGksIDwvZm9udD4N CjxwPjxmb250IHNpemU9MiBjb2xvcj0jMDAwMDgwIGZhY2U9IkNvbWljIFNhbnMgTVMiPiZuYnNw OzwvZm9udD4NCjxwPjxmb250IHNpemU9MiBjb2xvcj0jMDAwMDgwIGZhY2U9IkNvbWljIFNhbnMg TVMiPkp1c3QgdG8gdmVyaWZ5IHRoYXQNCkkgdW5kZXJzdGFuZCB0aGUgZmxvdyBvZiBtZXNzYWdl cyBhbmQgdGhlIHN0YXRlIG9mIHRoZSBCRkQgU2Vzc2lvbiCoQw0KaXMgdGhlIGZvbGxvd2luZyBm bG93IGNvcnJlY3QgqEM8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTIgY29sb3I9IzAwMDA4MCBmYWNl PSJDb21pYyBTYW5zIE1TIj4mbmJzcDs8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTIgY29sb3I9IzAw MDA4MCBmYWNlPSJDb21pYyBTYW5zIE1TIj5Bc3N1bWUgYSBMU1AgYmV0d2Vlbg0KTFNSLUEgYW5k IExTUi1aIKhDPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDAwODAgZmFjZT0iQ29t aWMgU2FucyBNUyI+MS4gQm90aCBMU1JzIGluaXRpYWxpemUNCnRoZSBCRkQgU2Vzc2lvbiBhbmQg c2V0IHRoZSBzdGF0ZSB0byBEb3duPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDAw ODAgZmFjZT0iQ29taWMgU2FucyBNUyI+Mi4gTFNSLUEgKHRoZSBpbmdyZXNzDQpMU1IpIHNlbmRz IGEgTFNQLVBpbmcgKHdpdGggdGhlIERpc2NyaW1pbmF0b3IgVExWKSB0byBMU1ItWiCoQyBib3Ro IHNlc3Npb25zDQpzdGlsbCBpbiBEb3duIHN0YXRlLjwvZm9udD4NCjxwPjxmb250IHNpemU9MiBj b2xvcj0jMDAwMDgwIGZhY2U9IkNvbWljIFNhbnMgTVMiPjMuIExTUi1aIHJlY2VpdmVzIHRoZQ0K TFNQLVBpbmcsIGFuZCAoYXNzdW1pbmcgdGhhdCBMU1ItWiBpcyBpbiBBY3RpdmUgbW9kZSkgc2Vu ZHMgYSBCRkQgQ29udHJvbA0KUGFja2V0IHdpdGggaXRzIG93biBEaXNjcmltaW5hdG9yLCB0aGUg RGlzY3JpbWluYXRvciByZWNlaXZlZCBmcm9tIHRoZQ0KTFNQLVBpbmcsIGFuZCBTdGF0ZT1Eb3du IHRvIExTUi1BLCBib3RoIHNlc3Npb24gc3RpbGwgaW4gRG93biBTdGF0ZS48L2ZvbnQ+DQo8cD48 Zm9udCBzaXplPTIgY29sb3I9IzAwMDA4MCBmYWNlPSJDb21pYyBTYW5zIE1TIj40LiBMU1ItQSBy ZWNlaXZlcyB0aGUNCkJGRCBDb250cm9sIGFuZCBzd2l0Y2hlcyB0byBJbml0IHN0YXRlIChhcyBw ZXIgUkZDNTg4MCksIGFuZCBzZW5kcyBhIEJGRA0KQ29udHJvbCBQYWNrZXQgd2l0aCBTdGF0ZT1J bml0IHRvIExTUi1aPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDAwODAgZmFjZT0i Q29taWMgU2FucyBNUyI+NS4gTFNSLVogcmVjZWl2ZXMgdGhlDQpCRkQgQ29udHJvbCBhbmQgc3dp dGNoZXMgdG8gVXAgc3RhdGUsIGFuZCBzZW5kcyBhIEJGRCBDb250cm9sIFBhY2tldCB3aXRoDQpT dGF0ZT1VcCB0byBMU1ItQTwvZm9udD4NCjxwPjxmb250IHNpemU9MiBjb2xvcj0jMDAwMDgwIGZh Y2U9IkNvbWljIFNhbnMgTVMiPjYuIExTUi1BIHJlY2VpdmVzIHRoZQ0KQkZEIENvbnRyb2wgYW5k IHN3aXRjaGVzIHRvIFVQIHN0YXRlPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDAw ODAgZmFjZT0iQ29taWMgU2FucyBNUyI+Jm5ic3A7PC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0yIGNv bG9yPSMwMDAwODAgZmFjZT0iQ29taWMgU2FucyBNUyI+QWRkaXRpb25hbCBxdWVzdGlvbg0KqEMg cmVnYXJkaW5nIHN0ZXAgMyBhYm92ZSCoQyBtdXN0IExTUi1aIGJlIGluIEFjdGl2ZSBtb2RlPyBX aGF0IGhhcHBlbnMNCmlmIExTUi1aIGlzIGluIFBhc3NpdmUgbW9kZSBhbmQgTFNSLUEgaXMgaW4g QWN0aXZlIG1vZGU/PC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDAwODAgZmFjZT0i Q29taWMgU2FucyBNUyI+Jm5ic3A7PC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDAw ODAgZmFjZT0iQ29taWMgU2FucyBNUyI+VGhhbnggYW5kIEJSLDwvZm9udD4NCjxwPjxmb250IHNp emU9MiBjb2xvcj0jMDAwMDgwIGZhY2U9IkNvbWljIFNhbnMgTVMiPllhYWNvdiBXZWluZ2FydGVu PC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0yIGNvbG9yPSMwMDAwODAgZmFjZT0iQ29taWMgU2FucyBN UyI+Tm9raWEgU2llbWVucyBOZXR3b3JrczwvZm9udD4NCjxwPjxmb250IHNpemU9MiBjb2xvcj0j MDAwMDgwIGZhY2U9IkNvbWljIFNhbnMgTVMiPiZuYnNwOzwvZm9udD4NCjxkaXYgYWxpZ249Y2Vu dGVyPg0KPHA+DQo8aHI+PC9kaXY+DQo8cD48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj48Yj5G cm9tOjwvYj4gPC9mb250PjxhIGhyZWY9Im1haWx0bzpydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmci IHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iVGFob21hIj48dT5y dGctYmZkLWJvdW5jZXNAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0i VGFob21hIj4NClttYWlsdG86PC9mb250PjxhIGhyZWY9Im1haWx0bzpydGctYmZkLWJvdW5jZXNA aWV0Zi5vcmciIHRhcmdldD1fYmxhbms+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iVGFo b21hIj48dT5ydGctYmZkLWJvdW5jZXNAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXpl PTIgZmFjZT0iVGFob21hIj5dDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPmV4dCBEYXZlIEthdHo8Yj48 YnI+DQpTZW50OjwvYj4gU2F0dXJkYXksIEF1Z3VzdCAxNCwgMjAxMCAwMDozOTxiPjxicj4NClRv OjwvYj4gUkFLRVNIIEdVUFRBPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEi PjxiPjxicj4NCkNjOjwvYj4gPC9mb250PjxhIGhyZWY9bWFpbHRvOm1wbHNAaWV0Zi5vcmcgdGFy Z2V0PV9ibGFuaz48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZSBmYWNlPSJUYWhvbWEiPjx1Pm1wbHNA aWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTIgZmFjZT0iVGFob21hIj47DQo8L2Zv bnQ+PGEgaHJlZj0ibWFpbHRvOnJ0Zy1iZmRAaWV0Zi5vcmciIHRhcmdldD1fYmxhbms+PGZvbnQg c2l6ZT0yIGNvbG9yPWJsdWUgZmFjZT0iVGFob21hIj48dT5ydGctYmZkQGlldGYub3JnPC91Pjwv Zm9udD48L2E+PGZvbnQgc2l6ZT0yIGZhY2U9IlRhaG9tYSI+DQpXRzwvZm9udD4NCjxkaXYgYWxp Z249cmlnaHQgZGlyPXJ0bD4NCjxwPjxmb250IHNpemU9MiBmYWNlPSJUYWhvbWEiPjxiPlN1Ympl Y3Q6PC9iPiBSZTogW21wbHNdIEJGRCBQYWNrZXQgRmxvdzwvZm9udD48L2Rpdj4NCjxwPjxmb250 IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD4NCjxwPjxmb250IHNp emU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPkkgc3VwcG9zZSB0aGUgc291cmNlIG9mIGNvbmZ1 c2lvbg0KbWlnaHQgYmUgUkZDIDU4ODQncyBjaG9pY2Ugb2YgdmVyYmlhZ2U6PC9mb250Pg0KPHA+ PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pg0KPHA+PGZv bnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDsmbmJzcDsgT24gcmVjZWlwdCBvZiB0 aGUgTFNQIFBpbmcNCkVjaG8gcmVxdWVzdCBtZXNzYWdlLCB0aGUgZWdyZXNzIExTUiBNVVNUPC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7Jm5ic3A7IHNl bmQgYSBCRkQgQ29udHJvbCBwYWNrZXQNCnRvIHRoZSBpbmdyZXNzIExTUi4uLjwvZm9udD4NCjxw Pjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD4NCjxwPjxm b250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPlRoaXMgbWlnaHQgZ2l2ZSB0aGUgaW1w cmVzc2lvbiB0aGF0DQpMU1AgUGluZyBpcyBqdXN0IHRyYW5zbWl0dGluZyBCRkQgY29udHJvbCBw YWNrZXRzIHdpbGx5LW5pbGx5IHdpdGhvdXQgYW55DQpCRkQgY29udGV4dC4gJm5ic3A7QnV0IGl0 IGFsc28gc2F5czo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFu Ij4mbmJzcDs8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTI+PHR0PiZuYnNwOyZuYnNwOyBBIEJGRCBz ZXNzaW9uIGlzIGJvb3RzdHJhcHBlZCB1c2luZyBMU1ANClBpbmcuPC90dD48L2ZvbnQ+DQo8ZGl2 IGFsaWduPXJpZ2h0IGRpcj1ydGw+DQo8YnI+PC9kaXY+DQo8cD48Zm9udCBzaXplPTMgZmFjZT0i VGltZXMgTmV3IFJvbWFuIj5hbmQ8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMg TmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBO ZXciPiZuYnNwOyZuYnNwOyBBIEJGRCBzZXNzaW9uIG1heSBiZSBlc3RhYmxpc2hlZA0KZm9yIGEg RkVDIGFzc29jaWF0ZWQgd2l0aCBhbiBNUExTIExTUC4mbmJzcDsgPC9mb250Pg0KPHA+PGZvbnQg c2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pg0KPHA+PGZvbnQgc2l6 ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+VGhpcyBzZWVtcyB1bmFtYmlndW91cyB0aGF0IGEg QkZEDQpzZXNzaW9uIGlzIGJlaW5nIGVzdGFibGlzaGVkLCBhbmQgdGhlIHByb2NlZHVyZSBmb3Ig ZG9pbmcgc28gaXMgc3BlbGxlZA0Kb3V0IGNsZWFybHkgaW4gUkZDIDU4ODAuICZuYnNwO0kgYmVs aWV2ZSB0aGUgZm9sbG93aW5nIHRvIGJlIHVuYW1iaWd1b3VzOjwvZm9udD4NCjxwPjxmb250IHNp emU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPiZuYnNwOzwvZm9udD4NCjxwPjxmb250IHNpemU9 MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7Jm5ic3A7IFN0YXRlIChTdGEpPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IFNldA0KdG8gdGhlIHZhbHVlIGluZGljYXRlZCBieSBiZmQuU2Vzc2lvblN0YXRlLjwvZm9udD4N Cjxicj48Zm9udCBzaXplPTM+PHR0PiZuYnNwOzwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9 Mz48dHQ+YW5kPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0zPjx0dD4mbmJzcDs8L3R0Pjwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOyZuYnNwOyBi ZmQuU2Vzc2lvblN0YXRlPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5l dyI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IC4uLlRoaXMNCnZhcmlhYmxlIE1VU1QgYmUgaW5p dGlhbGl6ZWQgdG8gRG93bi48L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTM+Jm5ic3A7PC9mb250Pg0K PHA+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+T25lIG1pZ2h0IGJlIHRlbXB0 ZWQgdG8gc3RhcnQgaW4NCkluaXQgc3RhdGUgaW4gb3JkZXIgdG8gc2F2ZSBvbmUgcGFja2V0IGR1 cmluZyBzZXNzaW9uIGVzdGFibGlzaG1lbnQsIGJ1dA0KaW4gZG9pbmcgc28gb25lIHdvdWxkIGJl IGJyZWFraW5nIHRoZSBzZW1hbnRpY3Mgb2YgdGhlIHByb3RvY29sLCBpbiBwYXJ0aWN1bGFyDQp0 aGUgdGhyZWUtd2F5IGhhbmRzaGFrZSB0aHJvdWdoIHNlc3Npb24gZmFpbHVyZS48L2ZvbnQ+DQo8 cD48Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+DQo8cD48 Zm9udCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4tLURhdmU8L2ZvbnQ+DQo8cD48Zm9u dCBzaXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+DQo8cD48Zm9udCBz aXplPTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj4mbmJzcDs8L2ZvbnQ+DQo8cD48Zm9udCBzaXpl PTMgZmFjZT0iVGltZXMgTmV3IFJvbWFuIj5PbiBBdWcgMTIsIDIwMTAsIGF0IDQ6MjAgQU0sIFJB S0VTSA0KR1VQVEEgd3JvdGU6PC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5l dyBSb21hbiI+PGJyPg0KPC9mb250Pg0KPHA+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxp Z249dG9wPg0KPHRkIHdpZHRoPTEwMCU+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+aGksPGJyPg0KPGJyPg0KSSBoYXZlIHF1ZXJ5IHJlZ2FyZGluZyBCRkQgcGFja2V0IGZsb3cg d2hlbiBMU1AgUGluZyBpcyB1c2VkIGZvciBib290c3RyYXBwaW5nLg0KPGJyPg0KPGJyPg0KQXMg cGVyIG15IHVuZGVyc3RhbmRpbmcgZnJvbSB0aGUgUkZDIDU4ODAgYW5kIFJGQyA1ODg0IHdoZW4g TFNQIFBpbmcgaXMNCnVzZWQgZm9yIGJvb3RzdHJhcHBpbmcgdGhlIHJlbW90ZSBlbmQgTVVTVCBy ZXBseSB3aXRoIEJGRCBjb250cm9sIGluIHJlc3BvbnNlDQp0byB0aGUgTFNQUGluZy48YnI+DQo8 YnI+DQpUaGUgc3BlY2lmaWNhdGlvbiBkb2VzIG5vdCBjbGVhcmx5IHNwZWNpZnkgYWJvdXQgdGhl IFN0YXQgcGFyYW1ldGVyIHZhbHVlDQp0aGF0IHNob3VsZCBiZSByZXR1cm5lZCBpbiB0aGUgcmVz cG9uc2Ugb2YgTFNQUGluZy4gU2hvdWxkIGl0IGhhdmUgdGhlDQp2YWx1ZSBJbml0IG9yIERvd24/ IE9yIGl0IG1pZ2h0IGJlIHBvc3NpYmxlIHRvIHJldHVybiBubyBzdGF0IGluZm9ybWF0aW9uLjxi cj4NCjxicj4NCkNhbiBzb21lb25lIHBsZWFzZSBzaGFyZSB0aGUgZXhhY3QgcGFja2V0IGZsb3cg dGhhdCBoYXBwZW5zIGR1cmluZyBCRkQNCnNlc3Npb24gc2V0IHVwIHdpdGggTFNQUGluZyBpbiBC b290c3RyYXAgdGlsbCB0aGUgc2Vzc2lvbiBjb21lcyBpbnRvIFVQDQpzdGF0ZT88YnI+DQo8YnI+ DQp0aGFua3MgYSBsb3QgaW4gYWR2YW5jZSBmb3IgdXIgaGVscCw8YnI+DQpyYWtlc2g8L2ZvbnQ+ PC90YWJsZT4NCjxwPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxicj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KbXBscyBt YWlsaW5nIGxpc3Q8L2ZvbnQ+PGZvbnQgc2l6ZT0zIGNvbG9yPWJsdWUgZmFjZT0iVGltZXMgTmV3 IFJvbWFuIj48dT48YnI+DQo8L3U+PC9mb250PjxhIGhyZWY9bWFpbHRvOm1wbHNAaWV0Zi5vcmcg dGFyZ2V0PV9ibGFuaz48Zm9udCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJUaW1lcyBOZXcgUm9t YW4iPjx1Pm1wbHNAaWV0Zi5vcmc8L3U+PC9mb250PjwvYT48Zm9udCBzaXplPTMgY29sb3I9Ymx1 ZSBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjx1Pjxicj4NCjwvdT48L2ZvbnQ+PGEgaHJlZj1odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL21wbHMgdGFyZ2V0PV9ibGFuaz48Zm9u dCBzaXplPTMgY29sb3I9Ymx1ZSBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjx1Pmh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBsczwvdT48L2ZvbnQ+PC9hPg0KPHA+PGZvbnQg c2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+Jm5ic3A7PC9mb250Pg0KPGJyPjxmb250IHNp emU9Mz48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCm1wbHMgbWFpbGluZyBsaXN0PC9mb250Pjxmb250IHNpemU9MyBjb2xvcj1ibHVlPjx1 Pjxicj4NCjwvdT48L2ZvbnQ+PGEgaHJlZj1tYWlsdG86bXBsc0BpZXRmLm9yZz48Zm9udCBzaXpl PTMgY29sb3I9Ymx1ZT48dT5tcGxzQGlldGYub3JnPC91PjwvZm9udD48L2E+PGZvbnQgc2l6ZT0z IGNvbG9yPWJsdWU+PHU+PGJyPg0KPC91PjwvZm9udD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbXBscyB0YXJnZXQ9X2JsYW5rPjxmb250IHNpemU9MyBjb2xv cj1ibHVlPjx1Pmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbXBsczwvdT48 L2ZvbnQ+PC9hPjxmb250IHNpemU9Mz48YnI+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0 dD5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm1w bHMgbWFpbGluZyBsaXN0PGJyPg0KbXBsc0BpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbXBsczxicj4NCjwvdHQ+PC9mb250Pg0KPGJyPg0K --=_alternative 00112FCA48257788_=-- From lavanya.srivatsa@aricent.com Thu Aug 26 04:08:44 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7441A3A6A6D for ; Thu, 26 Aug 2010 04:08:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.304 X-Spam-Level: X-Spam-Status: No, score=-1.304 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, 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 quIma-o7Vz1C for ; Thu, 26 Aug 2010 04:08:43 -0700 (PDT) Received: from jaguar.aricent.com (jaguar.aricent.com [121.241.96.11]) by core3.amsl.com (Postfix) with ESMTP id EDA653A6990 for ; Thu, 26 Aug 2010 04:08:42 -0700 (PDT) Received: from jaguar.aricent.com (localhost [127.0.0.1]) by postfix.imss71 (Postfix) with ESMTP id C422B36B96 for ; Thu, 26 Aug 2010 16:38:10 +0530 (IST) Received: from GUREXHT01.ASIAN.AD.ARICENT.COM (gurexht01.asian.ad.aricent.com [10.203.171.136]) by jaguar.aricent.com (Postfix) with ESMTP id AE29336B89 for ; Thu, 26 Aug 2010 16:38:10 +0530 (IST) Received: from GUREXMB02.ASIAN.AD.ARICENT.COM ([10.203.171.134]) by GUREXHT01.ASIAN.AD.ARICENT.COM ([10.203.171.137]) with mapi; Thu, 26 Aug 2010 16:39:07 +0530 From: Lavanya Srivatsa To: rtg-bfd , "dkatz@juniper.net" Date: Thu, 26 Aug 2010 16:39:06 +0530 Subject: RE: [mpls] BFD Packet Flow Thread-Topic: [mpls] BFD Packet Flow Thread-Index: AQHLRQ8ZnBNBzNxqt0GWbAIBApyFDQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "mpls@ietf.org" , "gupta_rakesh62@yahoo.co.in" X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 11:08:44 -0000 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 co= ntext. In the >> LSP context, LSR-Z is by definition in the active role be= cause 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 monit= ored 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 woul= d 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 req= uest 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 Act= ive 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* s= end a BFD control packet but will respond with an LSP Ping response (carryi= ng LSR-Z's discriminator) instead. Is my understanding correct? If so, the text in the RFC seems to slightly m= islead with the "MAY" clause for the LSP Ping response. - Lavanya Date: Sat, 21 Aug 2010 12:45:09 -0700 From: Dave Katz Subject: Re: [mpls] BFD Packet Flow To: "Weingarten, Yaacov (NSN - IL/Hod HaSharon)" Cc: mpls@ietf.org, rtg-bfd@ietf.org, RAKESH GUPTA Message-ID: <6F1E904F-CF1B-49B2-B8B7-088EA91CC661@juniper.net> Content-Type: text/plain; charset=3D"windows-1252" On Aug 19, 2010, at 2:08 AM, Weingarten, Yaacov (NSN - IL/Hod HaSharon) wro= te: > Hi, > > Just to verify that I understand the flow of messages and the state of th= e 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 mod= e) sends a BFD Control Packet with its own Discriminator, the Discriminator= received from the LSP-Ping, and State=3DDown to LSR-A, both session still = in Down State. > 4. LSR-A receives the BFD Control and switches to Init state (as per RFC5= 880), and sends a BFD Control Packet with State=3DInit to LSR-Z > 5. LSR-Z receives the BFD Control and switches to Up state, and sends a B= FD Control Packet with State=3DUp 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 mo= de? 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 ar= e really a way of describing the way the protocol behaves in a larger conte= xt. In the LSP context, LSR-Z is by definition in the active role because = it must send the first BFD packet. --Dave= From venkatflex@gmail.com Thu Aug 26 12:06:20 2010 Return-Path: X-Original-To: rtg-bfd@core3.amsl.com Delivered-To: rtg-bfd@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 003333A6971 for ; Thu, 26 Aug 2010 12:06:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.44 X-Spam-Level: X-Spam-Status: No, score=-2.44 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 V8BxiRoNO0eZ for ; Thu, 26 Aug 2010 12:06:17 -0700 (PDT) Received: from mail-pz0-f44.google.com (mail-pz0-f44.google.com [209.85.210.44]) by core3.amsl.com (Postfix) with ESMTP id D7E393A689E for ; Thu, 26 Aug 2010 12:06:17 -0700 (PDT) Received: by pzk6 with SMTP id 6so906514pzk.31 for ; Thu, 26 Aug 2010 12:06:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:content-type; bh=5ZnfJ+gnmo+jAy5UqUPrnpGAyT2qU6sEyZ6RXPTdVPw=; b=DiTv5mNekmVPeuUpjaW9jkPsQIlJCaLMtF4obwmBeY1OQw+L1CVY3G+I/mSM8tdFHK BZl1bkVB8PpdeOk1yBFpIwylSzOcdl71KXNszpLbh19GRDcijWLFODaULTP4P8GrznkT aO0E91Uu4RwzPQliDF7QzX38Jor42NQA9eYZ8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=ZHOxxbZllKbjpoY2cFl5KcuaoLiCAO1rJ2iiAjDdXkeiV8+DGhLIK6tbXa+yVu3HlI SjhvTMnF3zs1d+hkE5f5O/+hWeqS9HSqxlsxjg2pN4PFU3ZQFMeD0n8wNoS6vvKRi3ol KsSzroeHwtJOSCFNTDG5e5fNTiubgidI6PdAY= MIME-Version: 1.0 Received: by 10.142.148.2 with SMTP id v2mr336842wfd.114.1282849609057; Thu, 26 Aug 2010 12:06:49 -0700 (PDT) Received: by 10.142.163.6 with HTTP; Thu, 26 Aug 2010 12:06:48 -0700 (PDT) Date: Fri, 27 Aug 2010 00:36:48 +0530 Message-ID: Subject: Re: BFD MIB From: venkatesan mahalingam To: rtg-bfd@ietf.org, jhaas@pfrc.org, vishwas.ietf@gmail.com Content-Type: multipart/alternative; boundary=000e0cd3289c3f869b048ebeb3e2 X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Aug 2010 19:06:20 -0000 --000e0cd3289c3f869b048ebeb3e2 Content-Type: text/plain; charset=ISO-8859-1 Hi, Can you please update the latest information on this mail thread? IMO, instead of duplicating the BFD session specific informations (Tx, Rx intervals, BFD mode, Authentication types, session role, etc.,) at the client application (MPLS, RSVP) level, like bfdSessIpMapTable (IP map table for session), we can have tables for LSP map table, PW map table, MPLS-TP MEG/MEP map tables at the BFD mib itself. Any thoughts? This will reduce the burden for client applications and no need to inherit the client application specific default BFD config. parameters while the client application triggers the BFD session. If we follow this, we may have to see the BFD session running for neighbor, LSP, PW, MEG/MEP at the BFD level, not at the client application level. I think, this should be OK. Having the BFD session triggering from the BFD table and the client application level triggering will certainly introduce the burden on the users of the application. We may have limited configuration options at the application level, this may force the user to modify the client triggered BFD session at the BFD level for additional configurations OR user may directly configure the BFD mibs with all the configuration options at the BFD level for applications, we may need to indicate the BFD session index to the application. Which mode (BFD mib triggered/Client application triggered/both) is recommended for LSP/PW/MEG level proactive monitoring? Thanks, Venkat. To: Vishwas Manral Subject: Re: BFD MIB From: Jeffrey Haas Date: Sun, 21 Mar 2010 12:49:08 +0000 Cc: rtg-bfd at ietf.org Delivered-to: rtg-bfd at core3.amsl.com In-reply-to: <77ead0ec1003201631k1e4f9b0al74299e2fdd1efa1d at mail.gmail.com> List-archive: List-help: > List-id: "RTG Area: Bidirectional Forwarding Detection DT" List-post: > List-subscribe: , < mailto:rtg-bfd-request@ietf.org?subject=subscribe> List-unsubscribe: , < mailto:rtg-bfd-request@ietf.org?subject=unsubscribe> References: <77ead0ec0911101119l60233263ye1d9af1ee1d5287a at mail.gmail.com> <20100320165553.GC31380 at slice> <77ead0ec1003201631k1e4f9b0al74299e2fdd1efa1d at mail.gmail.com> User-agent: Mutt/1.5.18 (2008-05-17) -------------------------------------------------------------------------------- Vishwas, Unfortunately, I'm not at the current IETF session. I will admit to some biases against SNMP configuration of protocols based on my experiences with trying to find use cases for configuring BGP via a MIB. However, I'm also aware of operators who *do* want things like OSPF configurable via MIB. Regardless of our own particular SNMP SET based prejudices, we must answer two questions: 1. Given the protocol cases where BFD may be fully configured, does the MIB support this? 2. Given the protocol cases where BFD may have been configured outside of the SNMP system, does the MIB safely support configuration or manipulation of those sessions? Speaking as co-chair of the group for a moment to the BFD MIB authors: Do you have specific use cases for SNMP configuration in mind in the BFD MIB? If not, should we consider moving the bulk of the MIB to read-only? (This question also goes out to members of the WG that may require MIB configuration support.) On Sat, Mar 20, 2010 at 04:31:51PM -0700, Vishwas Manral wrote: > you are right. the point i have raised is sessiontable should be read > only in bfd. i do not know what it would mean to have a session row > without a protocol waiting for the session notification. this is one > of the basic flaws in the mib. sessions are learned dynamically and we > cannot configure a row for every possible session. I agree that we cannot do this for every possible session. Protocols requiring bootstrap of discriminator values MUST come from the outside of MIB configuration. Given this, what should the current sessiontable show? One option that is reasonable within the context of SNMP would be to have the logical row's StorageType be readOnly for rows created by sessions requiring bootstrap. Alternatively, permanent, would permit manipulation of row variables but with potentially serious impacts upon the protocol. As for "a protocol waiting for the session notification", it would be reasonable for a protocol-specific MIB to have their session/neighbor/etc. table AUGMENTed with a BFD peering table. Such a table would likely have an "enable BFD" object, and at least one more object which referred to the bfdSessIndex of the associated BFD session. Whether the configuration for the BFD session was part of the augmentation table or in the base BFD MIB is an implementation detail; I can see configuration scenarios both ways. The challenge for the MIB authors is to write text for the BFD MIB supporting each use case. By way of supporting the reverse mapping, the BFD MIB could also have a RowPointer into the appropriate BFD protocol-specific portion of its MIB. > the second part is that we should allow objects to be configured on a > global or an interface basis so when a session is configured from a > protcol the default value of parameters is automatically inherited. on > seeing the cli from the vendor i mentioned its also done the way i > have mentioned. While I agree that such mechanisms are operationally useful, they are also vendor-specific forms of convenience. At a SNMP table level, it is indistinguishable to have interface-specific configuration templates and to have the user enter each of the same values from the template into the appropriate portion of the protocol MIB. Putting such templates into the base protocol MIB constrains the implementation to have a specific form that may be inappropriate to a given vendor. In my opinion, that is out of scope for the BFD MIB but certainly within scope of vendor support in an enterprise MIB. -- Jeff -- Best Regards, Venkatesan Mahalingam. --000e0cd3289c3f869b048ebeb3e2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
Can you please update the latest information on this mail thread?
=A0
IMO, instead of duplicating the BFD session specific informations (Tx,= Rx=A0intervals, BFD mode, Authentication types, session role, etc.,)=A0at = the client application (MPLS,=A0RSVP)=A0level, like bfdSessIpMapTable (IP m= ap table for session), we can have tables for LSP map table, PW map table, = MPLS-TP MEG/MEP map tables at the BFD mib itself.
=A0
Any thoughts?
=A0
This will reduce the burden for client applications and no need to inh= erit the client application specific=A0default BFD config. parameters while= the client application triggers the=A0BFD session.
=A0
If we follow this, we may have to see the BFD session running for neig= hbor, LSP, PW, MEG/MEP at the BFD level, not at the client application leve= l.
I think, this should be OK.
=A0
Having the BFD session triggering from the BFD table and the client ap= plication level triggering will certainly introduce the burden on the users= of the application.
=A0
We may have limited configuration options at the application level, th= is may force the user to modify=A0the client triggered BFD session=A0at the= BFD level for additional configurations OR user may directly configure the= BFD mibs with all the=A0configuration options=A0at the BFD level for appli= cations, we may need to indicate the BFD session index to the application.<= /div>
=A0
Which mode (BFD=A0mib triggered/Client application triggered/both)=A0i= s recommended for LSP/PW/MEG level proactive monitoring?
=A0
Thanks,
Venkat.
To: Vishwas Manral <vishwas.ietf at gm= ail.com>
Subject: Re: BFD MIB
From: Jeffrey Haas <jhaas a= t pfrc.org>
Date: Sun, 21 Mar 2010 1= 2:49:08 +0000
Cc: rtg-bfd at ietf.org
Delivered-to: r= tg-bfd at core3.amsl.com
In-reply= -to: <77ead0ec1003201631k1e4f9b0al74299e2fdd1efa1d at mail.gmail.com>
List-archive: <= http://www.ietf.org/mail-archive/web/rtg-bfd>
List-help: <mailto:rtg-bfd-requ= est@ietf.org?subject=3Dhelp>
List-id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-post: &= lt;mailto:rtg-bfd@ietf.org>
List-subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@i= etf.org?subject=3Dsubscribe>
List-unsubscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-reque= st@ietf.org?subject=3Dunsubscribe>
References: <77ead0ec0911101119l60233263ye1d9af1ee1d5287a at mail.gmail.com> <20100320165553.GC31380 at= slice> <77ead0ec1003201631k1e4f9b0al74299e2fdd1efa1d at mail.gmail.com>
User-agent: Mutt/1.5.18 (2008-05-17)

------------------------------------------------------------------------= --------

Vishwas,

Unfortunately, I'm not at the current IETF session.

I will admit to some biases against SNMP configuration of protocols base= d on
my experiences with trying to find use cases for configuring BGP vi= a a MIB.
However, I'm also aware of operators who *do* want things l= ike OSPF
configurable via MIB.=A0 Regardless of our own particular SNMP SET basedprejudices, we must answer two questions:

1. Given the protocol cases where BFD may be fully configured, does the = MIB
=A0=A0 support this?
2. Given the protocol cases where BFD may ha= ve been configured outside of
=A0=A0 the SNMP system, does the MIB safel= y support configuration or manipulation
=A0=A0 of those sessions?

Speaking as co-chair of the group for a moment to the BFD MIB authors:= =A0 Do
you have specific use cases for SNMP configuration in mind in the= BFD MIB?
If not, should we consider moving the bulk of the MIB to read-= only?
(This question also goes out to members of the WG that may require MIB
c= onfiguration support.)

On Sat, Mar 20, 2010 at 04:31:51PM -0700, Vishwas Manral wrote:
> = you are right. the point i have raised is sessiontable should be read
&g= t; only in bfd. i do not know what it would mean to have a session row
> without a protocol waiting for the session notification. this is one> of the basic flaws in the mib. sessions are learned dynamically and = we
> cannot configure a row for every possible session.

I agree that we cannot do this for every possible session.=A0 Protocols<= br>requiring bootstrap of discriminator values MUST come from the outside o= f
MIB configuration.=A0 Given this, what should the current sessiontable= show?
One option that is reasonable within the context of SNMP would be to havethe logical row's StorageType be readOnly for rows created by session= s
requiring bootstrap.=A0 Alternatively, permanent, would permit manipul= ation of
row variables but with potentially serious impacts upon the protocol.

As for "a protocol waiting for the session notification", it w= ould be
reasonable for a protocol-specific MIB to have their session/nei= ghbor/etc.
table AUGMENTed with a BFD peering table.=A0 Such a table wou= ld likely have
an "enable BFD" object, and at least one more object which referr= ed to the
bfdSessIndex of the associated BFD session.=A0 Whether the con= figuration for
the BFD session was part of the augmentation table or in = the base BFD MIB is
an implementation detail; I can see configuration scenarios both ways.=A0 T= he
challenge for the MIB authors is to write text for the BFD MIB suppor= ting
each use case.

By way of supporting the reverse mapping, the BFD MIB could also have a<= br>RowPointer into the appropriate BFD protocol-specific portion of its MIB= .

> the second part is that we should allow objects to be configured on= a
> global or an interface basis so when a session is configured fro= m a
> protcol the default value of parameters is automatically inheri= ted. on
> seeing the cli from the vendor i mentioned its also done the way i
= > have mentioned.

While I agree that such mechanisms are operationally useful, they are al= so
vendor-specific forms of convenience.=A0 At a SNMP table level, it is=
indistinguishable to have interface-specific configuration templates an= d to
have the user enter each of the same values from the template into the
a= ppropriate portion of the protocol MIB.=A0

Putting such templates into the base protocol MIB constrains the
impl= ementation to have a specific form that may be inappropriate to a given
= vendor.=A0 In my opinion, that is out of scope for the BFD MIB but certainl= y
within scope of vendor support in an enterprise MIB.

-- Jeff



--
Best Regards,
Venkatesan Mahalingam.
=

--000e0cd3289c3f869b048ebeb3e2--