From rtg-bfd-bounces@ietf.org Wed Dec 14 05:23:15 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmTn1-0007Gr-HB; Wed, 14 Dec 2005 05:23:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmTmz-0007Gh-PK for rtg-bfd@megatron.ietf.org; Wed, 14 Dec 2005 05:23:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01044 for ; Wed, 14 Dec 2005 05:22:15 -0500 (EST) Received: from web30514.mail.mud.yahoo.com ([68.142.201.242]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EmTo9-0007sw-Rt for rtg-bfd@ietf.org; Wed, 14 Dec 2005 05:24:27 -0500 Received: (qmail 75568 invoked by uid 60001); 14 Dec 2005 10:23:02 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=NBsn/oyZP9oBy85e8vIbETq9NJREdJ504b/9jF/Dcl54MTbIhdQ6l93IRlKvO87jg2pOuv1obuKvJdkdx+32+Z0/Vhob2FBsQrZ6BbWfAI0g91P6SPtGGSdwsbbrosXfMo7+jnMUI8PWhZGn1u/06E97OBBg+h5p4MtKK3vQpiA= ; Message-ID: <20051214102302.75566.qmail@web30514.mail.mud.yahoo.com> Received: from [59.144.1.153] by web30514.mail.mud.yahoo.com via HTTP; Wed, 14 Dec 2005 02:23:02 PST Date: Wed, 14 Dec 2005 02:23:02 -0800 (PST) From: Tonuka SinhaRay To: Dave Katz In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: 8bit Cc: rtg-bfd@ietf.org Subject: Re: Regarding Min. value of Desired Min. Tx Interval and Required Min. Rx. Interval X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Sir/Madam, I am not able to find the Packet format of BFD Echo packets. Can someone please let me know about Packet Format of BFD Echo Packets? With Regards, Tonuka --- Dave Katz wrote: > > On Nov 25, 2005, at 4:41 AM, Tonuka SinhaRay wrote: > > > > > Sir/Madam, > > > > In the draft "draft-ietf-bfd-base-03.txt" Page > 26 > > and 27 , it says that bfd.DesiredMinTxInterval > must be > > initialised to a value of at least one second > > (1,000,000 microseconds). Does this mean that > > bfd.DesiredMinTxInterval should be always greater > or > > equal to 1 sec? > > No, just that the value must be at least one second > when the session > is first created. > > > > > But, in the same draft , Section 6.7.3 (paragraph > 6), > > it is specified that if bfd.SessionState is not > Up, > > the system MUST set bfd.DesiredMInTxInterval to a > > value not less than one second. > > > > Can someone please clarify what is min. value of > > Desired Min Tx Interval > > and Required Min. Rx Interval? > > There is no minimum (well, one microsecond.) MinTx > reflects the > sender's desire to transmit rapidly; MinRx reflects > the receiver's > desire to receive slowly. Thus the receiver always > places a lower > bound on the interval. > > > Is the Min. values for Desired Min. Tx Interval > and > > required Min. Rx. Interval > > different when session is Down/AdminDown/Init from > > when the session is up? > > As you quote above, MinTx must be at least one > second when the > session isn't up. > > The point of this whole exercise is to give each > system unilateral > control over the maximum transmission rate in both > directions. When > a session is first starting up, however, each system > sends slowly > because it does not know the requirements of the > other system (which > can't be guaranteed until the session is up.) For > that matter, > perhaps only one system is configured to use BFD, > and the session may > never come up, so the bandwidth consumption needs to > be limited. > > --Dave > > > > > Thank you in Advance, > > With Regards, > > Tonuka > > > > > > > > __________________________________ > > Start your day with Yahoo! - Make it your home > page! > > http://www.yahoo.com/r/hs > > > > __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From rtg-bfd-bounces@ietf.org Wed Dec 14 07:52:17 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmW7F-00047i-IW; Wed, 14 Dec 2005 07:52:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmW7D-00047b-R4 for rtg-bfd@megatron.ietf.org; Wed, 14 Dec 2005 07:52:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA19029 for ; Wed, 14 Dec 2005 07:51:15 -0500 (EST) Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmW8O-0004xE-Cn for rtg-bfd@ietf.org; Wed, 14 Dec 2005 07:53:28 -0500 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 14 Dec 2005 07:52:02 -0500 X-IronPort-AV: i="3.99,251,1131339600"; d="scan'208,217"; a="77724390:sNHT47041160" Received: from cisco.com (che-vpn-cluster-1-240.cisco.com [10.86.240.240]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id jBECpwUR003768; Wed, 14 Dec 2005 07:51:59 -0500 (EST) Message-ID: <43A0156E.6000004@cisco.com> Date: Wed, 14 Dec 2005 07:51:58 -0500 From: Reshad Rahman User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tonuka SinhaRay References: <20051214102302.75566.qmail@web30514.mail.mud.yahoo.com> Content-Type: multipart/alternative; boundary="------------000907050301040908090106" X-Spam-Score: 1.0 (+) X-Scan-Signature: a1dc446dc7ac353b90b60743d0e479e3 Cc: rtg-bfd@ietf.org, Dave Katz Subject: Re: Regarding Min. value of Desired Min. Tx Interval and Required Min. Rx. Interval X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org --------------000907050301040908090106 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit From http://www.ietf.org/internet-drafts/draft-ietf-bfd-base-04.txt: The payload of a BFD Echo packet is a local matter, since only the sending system ever processes the content. The only requirement is that sufficient information is included to demultiplex the received packet to the correct BFD session after it is looped back to the sender. The contents are otherwise outside the scope of this specification. Regards, Reshad. Tonuka SinhaRay wrote: >Sir/Madam, > >I am not able to find the Packet format of BFD Echo >packets. >Can someone please let me know about Packet Format of >BFD Echo Packets? > >With Regards, >Tonuka >--- Dave Katz wrote: > > > >>On Nov 25, 2005, at 4:41 AM, Tonuka SinhaRay wrote: >> >> >> >>> Sir/Madam, >>> >>> In the draft "draft-ietf-bfd-base-03.txt" Page >>> >>> >>26 >> >> >>>and 27 , it says that bfd.DesiredMinTxInterval >>> >>> >>must be >> >> >>>initialised to a value of at least one second >>>(1,000,000 microseconds). Does this mean that >>>bfd.DesiredMinTxInterval should be always greater >>> >>> >>or >> >> >>>equal to 1 sec? >>> >>> >>No, just that the value must be at least one second >>when the session >>is first created. >> >> >> >>>But, in the same draft , Section 6.7.3 (paragraph >>> >>> >>6), >> >> >>>it is specified that if bfd.SessionState is not >>> >>> >>Up, >> >> >>>the system MUST set bfd.DesiredMInTxInterval to a >>>value not less than one second. >>> >>>Can someone please clarify what is min. value of >>>Desired Min Tx Interval >>>and Required Min. Rx Interval? >>> >>> >>There is no minimum (well, one microsecond.) MinTx >>reflects the >>sender's desire to transmit rapidly; MinRx reflects >>the receiver's >>desire to receive slowly. Thus the receiver always >>places a lower >>bound on the interval. >> >> >> >>>Is the Min. values for Desired Min. Tx Interval >>> >>> >>and >> >> >>>required Min. Rx. Interval >>>different when session is Down/AdminDown/Init from >>>when the session is up? >>> >>> >>As you quote above, MinTx must be at least one >>second when the >>session isn't up. >> >>The point of this whole exercise is to give each >>system unilateral >>control over the maximum transmission rate in both >>directions. When >>a session is first starting up, however, each system >>sends slowly >>because it does not know the requirements of the >>other system (which >>can't be guaranteed until the session is up.) For >>that matter, >>perhaps only one system is configured to use BFD, >>and the session may >>never come up, so the bandwidth consumption needs to >>be limited. >> >>--Dave >> >> >> >>>Thank you in Advance, >>>With Regards, >>>Tonuka >>> >>> >>> >>>__________________________________ >>>Start your day with Yahoo! - Make it your home >>> >>> >>page! >> >> >>>http://www.yahoo.com/r/hs >>> >>> >>> >> >> > > >__________________________________________________ >Do You Yahoo!? >Tired of spam? Yahoo! Mail has the best spam protection around >http://mail.yahoo.com > > --------------000907050301040908090106 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit >From http://www.ietf.org/internet-drafts/draft-ietf-bfd-base-04.txt:

   The payload of a BFD Echo packet is a local matter, since only the
   sending system ever processes the content.  The only requirement is
   that sufficient information is included to demultiplex the received
   packet to the correct BFD session after it is looped back to the
   sender.  The contents are otherwise outside the scope of this
   specification.

Regards,
Reshad.

Tonuka SinhaRay wrote:
Sir/Madam,

I am not able to find the Packet format of BFD Echo
packets.
Can someone please let me know about Packet Format of
BFD Echo Packets?

With Regards,
Tonuka
--- Dave Katz <dkatz@juniper.net> wrote:

  
On Nov 25, 2005, at 4:41 AM, Tonuka SinhaRay wrote:

    
 Sir/Madam,

  In the draft "draft-ietf-bfd-base-03.txt" Page
      
26
    
and 27 , it says that bfd.DesiredMinTxInterval
      
must be
    
initialised to a value of at least one second
(1,000,000 microseconds). Does this mean that
bfd.DesiredMinTxInterval should be always greater
      
or
    
equal to 1 sec?
      
No, just that the value must be at least one second
when the session  
is first created.

    
But, in the same draft , Section 6.7.3 (paragraph
      
6),
    
it is specified that if bfd.SessionState is not
      
Up,
    
the system MUST set bfd.DesiredMInTxInterval to a
value not less than one second.

Can someone please clarify  what is min. value of
Desired Min Tx Interval
and Required Min. Rx Interval?
      
There is no minimum (well, one microsecond.)  MinTx
reflects the  
sender's desire to transmit rapidly;  MinRx reflects
the receiver's  
desire to receive slowly.  Thus the receiver always
places a lower  
bound on the interval.

    
Is the Min. values for Desired Min. Tx Interval
      
and
    
required Min. Rx. Interval
different when session is Down/AdminDown/Init from
when the session is up?
      
As you quote above, MinTx must be at least one
second when the  
session isn't up.

The point of this whole exercise is to give each
system unilateral  
control over the maximum transmission rate in both
directions.  When  
a session is first starting up, however, each system
sends slowly  
because it does not know the requirements of the
other system (which  
can't be guaranteed until the session is up.)  For
that matter,  
perhaps only one system is configured to use BFD,
and the session may  
never come up, so the bandwidth consumption needs to
be limited.

--Dave

    
Thank you in Advance,
With Regards,
Tonuka


		
__________________________________
Start your day with Yahoo! - Make it your home
      
page!
    
http://www.yahoo.com/r/hs

      
    


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com

--------------000907050301040908090106-- From rtg-bfd-bounces@ietf.org Wed Dec 14 08:23:06 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmWb4-0004Gv-IT; Wed, 14 Dec 2005 08:23:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmWb2-0004GY-SH for rtg-bfd@megatron.ietf.org; Wed, 14 Dec 2005 08:23:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23237 for ; Wed, 14 Dec 2005 08:21:57 -0500 (EST) Received: from szxga03-in.huawei.com ([61.144.161.55] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmWc7-0006LF-CC for rtg-bfd@ietf.org; Wed, 14 Dec 2005 08:24:11 -0500 Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IRH003ZEP31XO@szxga03-in.huawei.com> for rtg-bfd@ietf.org; Wed, 14 Dec 2005 21:21:01 +0800 (CST) Received: from szxml02-in ([172.24.1.6]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0IRH00BYCP31ZY@szxga03-in.huawei.com> for rtg-bfd@ietf.org; Wed, 14 Dec 2005 21:21:01 +0800 (CST) Received: from z11024 ([10.110.100.87]) by szxml02-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0IRH0073WPAS4F@szxml02-in.huawei.com>; Wed, 14 Dec 2005 21:25:41 +0800 (CST) Date: Wed, 14 Dec 2005 21:15:16 +0800 From: Suping Zhai To: Tonuka SinhaRay , bfd Message-id: <0IRH0073XPAS4F@szxml02-in.huawei.com> Organization: huawei MIME-version: 1.0 X-Mailer: Foxmail 4.2 [cn] Content-type: text/plain; charset=GB2312 Content-transfer-encoding: 7BIT X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: 7BIT Cc: Subject: Re: Re: Regarding Min. value of Desired Min. Tx Interval and Required Min.Rx. Interval X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: zhaisuping@huawei.com List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Hi Tonuka, >From my understanding, BFD echo packets frame format is the same as the request packet frame format except that in some scenario the "P" and "F" bit value is different. Best Regards, Suping >Sir/Madam, > >I am not able to find the Packet format of BFD Echo >packets. >Can someone please let me know about Packet Format of >BFD Echo Packets? > >With Regards, >Tonuka >--- Dave Katz wrote: > >> >> On Nov 25, 2005, at 4:41 AM, Tonuka SinhaRay wrote: >> >> > >> > Sir/Madam, >> > >> > In the draft "draft-ietf-bfd-base-03.txt" Page >> 26 >> > and 27 , it says that bfd.DesiredMinTxInterval >> must be >> > initialised to a value of at least one second >> > (1,000,000 microseconds). Does this mean that >> > bfd.DesiredMinTxInterval should be always greater >> or >> > equal to 1 sec? >> >> No, just that the value must be at least one second >> when the session >> is first created. >> >> > >> > But, in the same draft , Section 6.7.3 (paragraph >> 6), >> > it is specified that if bfd.SessionState is not >> Up, >> > the system MUST set bfd.DesiredMInTxInterval to a >> > value not less than one second. >> > >> > Can someone please clarify what is min. value of >> > Desired Min Tx Interval >> > and Required Min. Rx Interval? >> >> There is no minimum (well, one microsecond.) MinTx >> reflects the >> sender's desire to transmit rapidly; MinRx reflects >> the receiver's >> desire to receive slowly. Thus the receiver always >> places a lower >> bound on the interval. >> >> > Is the Min. values for Desired Min. Tx Interval >> and >> > required Min. Rx. Interval >> > different when session is Down/AdminDown/Init from >> > when the session is up? >> >> As you quote above, MinTx must be at least one >> second when the >> session isn't up. >> >> The point of this whole exercise is to give each >> system unilateral >> control over the maximum transmission rate in both >> directions. When >> a session is first starting up, however, each system >> sends slowly >> because it does not know the requirements of the >> other system (which >> can't be guaranteed until the session is up.) For >> that matter, >> perhaps only one system is configured to use BFD, >> and the session may >> never come up, so the bandwidth consumption needs to >> be limited. >> >> --Dave >> >> > >> > Thank you in Advance, >> > With Regards, >> > Tonuka >> > >> > >> > >> > __________________________________ >> > Start your day with Yahoo! - Make it your home >> page! >> > http://www.yahoo.com/r/hs >> > >> >> > > >__________________________________________________ >Do You Yahoo!? >Tired of spam? Yahoo! Mail has the best spam protection around >http://mail.yahoo.com From rtg-bfd-bounces@ietf.org Wed Dec 14 12:42:52 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmaeS-0000sx-Rj; Wed, 14 Dec 2005 12:42:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmaeQ-0000qa-LX for rtg-bfd@megatron.ietf.org; Wed, 14 Dec 2005 12:42:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00286 for ; Wed, 14 Dec 2005 12:41:44 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmafX-000128-JA for rtg-bfd@ietf.org; Wed, 14 Dec 2005 12:44:00 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 14 Dec 2005 09:42:21 -0800 X-IronPort-AV: i="3.99,252,1131350400"; d="scan'208"; a="240947875:sNHT1084709450" Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id jBEHg8Mm016584; Wed, 14 Dec 2005 09:42:19 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Dec 2005 09:42:18 -0800 Received: from [171.71.139.226] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 14 Dec 2005 09:42:17 -0800 User-Agent: Microsoft-Entourage/10.1.6.040913.0 Date: Wed, 14 Dec 2005 11:42:47 -0600 From: David Ward To: , Tonuka SinhaRay , bfd , David Ward , Dave Katz Message-ID: In-Reply-To: <0IRH0073XPAS4F@szxml02-in.huawei.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 14 Dec 2005 17:42:17.0727 (UTC) FILETIME=[BA1F10F0:01C600D5] X-Spam-Score: 1.1 (+) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Content-Transfer-Encoding: 7bit Cc: Subject: Re: Regarding Min. value of Desired Min. Tx Interval and Required Min.Rx. Interval X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org The P and F bit have no bearing in the Echo packet contents (you are sending packets to yourself from yourself). Remember there is a control and data stream for Echo and P and F would only be used in the control stream. You can fill Echo packets w/ whatever you like ... 0s, 1s, Shakespeare, etc :-) -DWard On 12/14/05 7:15 AM, "Suping Zhai" wrote: > Hi Tonuka, >> From my understanding, BFD echo packets frame format is the same as the >> request packet frame format except that in some scenario the "P" and "F" bit >> value is different. > > Best Regards, > Suping >> Sir/Madam, >> >> I am not able to find the Packet format of BFD Echo >> packets. >> Can someone please let me know about Packet Format of >> BFD Echo Packets? >> >> With Regards, >> Tonuka >> --- Dave Katz wrote: >> >>> >>> On Nov 25, 2005, at 4:41 AM, Tonuka SinhaRay wrote: >>> >>>> >>>> Sir/Madam, >>>> >>>> In the draft "draft-ietf-bfd-base-03.txt" Page >>> 26 >>>> and 27 , it says that bfd.DesiredMinTxInterval >>> must be >>>> initialised to a value of at least one second >>>> (1,000,000 microseconds). Does this mean that >>>> bfd.DesiredMinTxInterval should be always greater >>> or >>>> equal to 1 sec? >>> >>> No, just that the value must be at least one second >>> when the session >>> is first created. >>> >>>> >>>> But, in the same draft , Section 6.7.3 (paragraph >>> 6), >>>> it is specified that if bfd.SessionState is not >>> Up, >>>> the system MUST set bfd.DesiredMInTxInterval to a >>>> value not less than one second. >>>> >>>> Can someone please clarify what is min. value of >>>> Desired Min Tx Interval >>>> and Required Min. Rx Interval? >>> >>> There is no minimum (well, one microsecond.) MinTx >>> reflects the >>> sender's desire to transmit rapidly; MinRx reflects >>> the receiver's >>> desire to receive slowly. Thus the receiver always >>> places a lower >>> bound on the interval. >>> >>>> Is the Min. values for Desired Min. Tx Interval >>> and >>>> required Min. Rx. Interval >>>> different when session is Down/AdminDown/Init from >>>> when the session is up? >>> >>> As you quote above, MinTx must be at least one >>> second when the >>> session isn't up. >>> >>> The point of this whole exercise is to give each >>> system unilateral >>> control over the maximum transmission rate in both >>> directions. When >>> a session is first starting up, however, each system >>> sends slowly >>> because it does not know the requirements of the >>> other system (which >>> can't be guaranteed until the session is up.) For >>> that matter, >>> perhaps only one system is configured to use BFD, >>> and the session may >>> never come up, so the bandwidth consumption needs to >>> be limited. >>> >>> --Dave >>> >>>> >>>> Thank you in Advance, >>>> With Regards, >>>> Tonuka >>>> >>>> >>>> >>>> __________________________________ >>>> Start your day with Yahoo! - Make it your home >>> page! >>>> http://www.yahoo.com/r/hs >>>> >>> >>> >> >> >> __________________________________________________ >> Do You Yahoo!? >> Tired of spam? Yahoo! Mail has the best spam protection around >> http://mail.yahoo.com > > From rtg-bfd-bounces@ietf.org Fri Dec 16 03:31:41 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnB09-0005yX-Sa; Fri, 16 Dec 2005 03:31:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnB07-0005yN-M0 for rtg-bfd@megatron.ietf.org; Fri, 16 Dec 2005 03:31:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17614 for ; Fri, 16 Dec 2005 03:30:39 -0500 (EST) Received: from zproxy.gmail.com ([64.233.162.194]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EnB1e-0004Qh-Fb for rtg-bfd@ietf.org; Fri, 16 Dec 2005 03:33:17 -0500 Received: by zproxy.gmail.com with SMTP id z6so620215nzd for ; Fri, 16 Dec 2005 00:31:35 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=pksF8RPSOZf2WWla81SQKk3YYE914f27dfAMADv2XZsUCfpI+0/0wR3vzN8mTO+MaKlkrOxaVwji8DATSgFTaxAP5xZ5+7otb5NEZfGjSZB/UooMivTU0J0gU9h3aSFGVrqCKbszvZ6dC5OauhY9mq/mknESQhO0VN93dcyic1A= Received: by 10.36.91.14 with SMTP id o14mr2814954nzb; Fri, 16 Dec 2005 00:31:35 -0800 (PST) Received: by 10.36.118.3 with HTTP; Fri, 16 Dec 2005 00:31:35 -0800 (PST) Message-ID: <92c950310512160031t4d8fea47i5ee3777003f88065@mail.gmail.com> Date: Fri, 16 Dec 2005 14:01:35 +0530 From: Glen Kent To: rtg-bfd@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: quoted-printable Subject: Why BFD for IPv4 and IPv6? X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Hi, BFD (draft-ietf-bfd-base-04.txt) runs over L2 between two directly connected nodes and provides liveliness detection mechanism b/w them. If this is so, then why do we need a separate BFD protocol for Ipv4 and IPv6. Detecting forwarding plane liveliness over L2 IMO is a superset of that doing it over IPv4/6? One scenario that i can think of when you would require a separate BFD for v4/v6 is when you have 2 directly connected links and we change the IPv4/6 address on one side. This will not be detected by the base BFD and the link is still alive. Is it for this that we have the other BFD draft (draft-ietf-bfd-v4v6-1hop-04.txt)? Also, if somebody runs BFD for v4/v6, then is he/she required to run the base BFD also? Thanks, Glen From rtg-bfd-bounces@ietf.org Tue Dec 20 13:48:47 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EomXX-0003CH-1N; Tue, 20 Dec 2005 13:48:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EomXW-0003BH-2N for rtg-bfd@megatron.ietf.org; Tue, 20 Dec 2005 13:48:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17997 for ; Tue, 20 Dec 2005 13:47:42 -0500 (EST) Received: from zproxy.gmail.com ([64.233.162.204]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EomZw-0000xK-Fp for rtg-bfd@ietf.org; Tue, 20 Dec 2005 13:51:19 -0500 Received: by zproxy.gmail.com with SMTP id 8so1592148nzo for ; Tue, 20 Dec 2005 10:48:42 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=HKGUERt5Gbwu+s45dfvbhPccMbLKpr4X/fYH8NPS/lEKw8Fst87KtDJxB56HHftdPM8nFcAR0R9+XhBeHjUhsf65syvGssqMloOLEu+j+6SnnNge76+mFEDJT1kBRoKUywYQymGAaOkmCRYKZAmcdNzRxMB44oMfytRmq62gdDw= Received: by 10.37.2.15 with SMTP id e15mr7107205nzi; Tue, 20 Dec 2005 10:48:41 -0800 (PST) Received: by 10.36.127.3 with HTTP; Tue, 20 Dec 2005 10:48:41 -0800 (PST) Message-ID: <9e31186f0512201048k50754fb0r@mail.gmail.com> Date: Tue, 20 Dec 2005 19:48:41 +0100 From: Carlos Garcia Braschi To: rtg-bfd@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable Subject: BFD for different BGP next hops X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Hi, Let's say there is an implementation of BFD used to test reachability of routes announced through a BGP routing session. Let's say that the BGP session announces several routes with different next hop addresses, but all of them are inside the same subnet (so that they could use bfd-v4v6-1hop). This could be the case, for example, in a peering point. I have a doubt: would a router implementing this establish a BFD session with each next hop received or just with the BGP peer? Although from the point of view of BFD interoperability this is of no concern, from the point of view of using BFD in the practical sense, it is quite important, as I would expect a BFD session with each next hop, but probably others would like to check just the BGP peer and think about this case an exception rather than the norm. And the behaviours would be quite different... Is this just an implementation option/issue that router manufacturers may or may not offer? Should it have a name and/or more formal description? Something similar may happen with RIP but I think no one uses the option so it's not an issue... Regards, Carlos. -- Telef=F3nica Empresas. From rtg-bfd-bounces@ietf.org Tue Dec 20 14:26:16 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eon7o-0005b8-4C; Tue, 20 Dec 2005 14:26:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eon7m-0005ax-HT for rtg-bfd@megatron.ietf.org; Tue, 20 Dec 2005 14:26:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22325 for ; Tue, 20 Dec 2005 14:25:08 -0500 (EST) Received: from pmesmtp03.mci.com ([199.249.20.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EonA7-0002EJ-5x for rtg-bfd@ietf.org; Tue, 20 Dec 2005 14:28:46 -0500 Received: from pmismtp04.wcomnet.com ([166.38.62.39]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0IRT0055Z9YVGJ@firewall.mci.com> for rtg-bfd@ietf.org; Tue, 20 Dec 2005 19:25:43 +0000 (GMT) Received: from pmismtp04.wcomnet.com by pmismtp04.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with SMTP id <0IRT004019VGNG@pmismtp04.mcilink.com>; Tue, 20 Dec 2005 19:25:43 +0000 (GMT) Received: from XS344V8068056 ([153.39.147.245]) by pmismtp04.mcilink.com (iPlanet Messaging Server 5.2 HotFix 1.14 (built Mar 18 2003)) with ESMTP id <0IRT0048Z9XGHG@pmismtp04.mcilink.com>; Tue, 20 Dec 2005 19:24:52 +0000 (GMT) Date: Tue, 20 Dec 2005 14:24:52 -0500 From: Bill Barns In-reply-to: <9e31186f0512201048k50754fb0r@mail.gmail.com> To: "'Carlos Garcia Braschi'" , rtg-bfd@ietf.org Message-id: <0IRT004909XGHG@pmismtp04.mcilink.com> Organization: MCI MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 X-Mailer: Microsoft Office Outlook, Build 11.0.6353 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-index: AcYFliuEufFVUQryQ+yC8ZEpijVK6QAAPVkw X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: quoted-printable Cc: Subject: RE: BFD for different BGP next hops X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: william.barns@mci.com List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org A situation that interests me is health monitoring of labeled paths = coming from BGP using RFC 3107 when route reflector servers are the means of distributing those paths/LSPs. BFD to the BGP peer isn't helpful to = that goal. And that seemed to give me an excuse to inquire whether BFD to = the next hops is a good idea for this purpose or if I should be looking elsewhere. For better or worse, there sure are a lot of features and flavors of OAM = / link monitoring / connectivity verification / failure detection from = various points of view that could arguably be part of the picture. Overall I = find that more disorienting than helpful, though. /Bill -----Original Message----- From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On = Behalf Of Carlos Garcia Braschi Sent: Tuesday, December 20, 2005 1:49 PM To: rtg-bfd@ietf.org Subject: BFD for different BGP next hops Hi, Let's say there is an implementation of BFD used to test reachability of routes announced through a BGP routing session. Let's say that the BGP session announces several routes with different next hop addresses, but all of them are inside the same subnet (so that they could use bfd-v4v6-1hop). This could be the case, for example, in a peering point. I have a doubt: would a router implementing this establish a BFD session with each next hop received or just with the BGP peer? Although from the point of view of BFD interoperability this is of no concern, from the point of view of using BFD in the practical sense, it is quite important, as I would expect a BFD session with each next hop, but probably others would like to check just the BGP peer and think about this case an exception rather than the norm. And the behaviours would be quite different... Is this just an implementation option/issue that router manufacturers may or may not offer? Should it have a name and/or more formal description? Something similar may happen with RIP but I think no one uses the option so it's not an issue... Regards, Carlos. -- Telef=F3nica Empresas. From rtg-bfd-bounces@ietf.org Tue Dec 20 16:53:57 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EopQi-0000w1-On; Tue, 20 Dec 2005 16:53:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EopQg-0000tL-VB for rtg-bfd@megatron.ietf.org; Tue, 20 Dec 2005 16:53:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03416 for ; Tue, 20 Dec 2005 16:52:50 -0500 (EST) Received: from netcore.fi ([193.94.160.1]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EopT9-0007LP-NY for rtg-bfd@ietf.org; Tue, 20 Dec 2005 16:56:30 -0500 Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id jBKLrch02497; Tue, 20 Dec 2005 23:53:38 +0200 Date: Tue, 20 Dec 2005 23:53:38 +0200 (EET) From: Pekka Savola To: Carlos Garcia Braschi In-Reply-To: <9e31186f0512201048k50754fb0r@mail.gmail.com> Message-ID: References: <9e31186f0512201048k50754fb0r@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 2.4 (++) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: rtg-bfd@ietf.org Subject: Re: BFD for different BGP next hops X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org On Tue, 20 Dec 2005, Carlos Garcia Braschi wrote: > I have a doubt: would a router implementing this establish a BFD > session with each next hop received or just with the BGP peer? ... This issue has been discussed a couple of times on the list, without a clear conclusion; some folks think that BFD should only be used to the BGP session end-point (which gives roughtly the same amount of liveness testing as today), Jeff Haas has thought it would be useful to test the liveness to the 3rd party next-hops as well as that's one potential failure mode. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From rtg-bfd-bounces@ietf.org Tue Dec 20 19:04:51 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EorTP-0004OX-LV; Tue, 20 Dec 2005 19:04:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EorTN-0004Ni-GE for rtg-bfd@megatron.ietf.org; Tue, 20 Dec 2005 19:04:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA21414 for ; Tue, 20 Dec 2005 19:03:46 -0500 (EST) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EorVt-0004Ud-Hx for rtg-bfd@ietf.org; Tue, 20 Dec 2005 19:07:25 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 20 Dec 2005 16:04:40 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id jBL04SQS014927; Tue, 20 Dec 2005 16:04:38 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Dec 2005 16:04:32 -0800 Received: from [171.71.139.226] ([171.68.225.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 20 Dec 2005 16:04:31 -0800 User-Agent: Microsoft-Entourage/10.1.6.040913.0 Date: Tue, 20 Dec 2005 18:04:36 -0600 From: David Ward To: , "'Carlos Garcia Braschi'" , , David Ward , Dave Katz , Jeffrey Haas Message-ID: In-Reply-To: <0IRT004909XGHG@pmismtp04.mcilink.com> Mime-version: 1.0 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable X-OriginalArrivalTime: 21 Dec 2005 00:04:31.0992 (UTC) FILETIME=[1E7CAF80:01C605C2] X-Spam-Score: 3.4 (+++) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: quoted-printable Cc: Subject: Re: BFD for different BGP next hops X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org Bill - In this case you would: 0) Form a BFD session to the RR via BGP bootstrapping 1) Form BFD sessions to the nexthops via IGP bootstrapping throughout the topology. Thus, if the RR was using nexthopself you would be covered and also for all interior nexthops. For EBGP nexthops, one should form BFD sessions via EBGP bootstrapping. Fo= r third party nexthops, you will need to cause bootstrapping to occur via other means (e.g. via CLI/NMS). Since it is rare/not-wise/violating reasonable security measures to blindly accept all third party nexthops, th= e authors believe it is also not wise to for BFD sessions via "triggered" third party nexthops and recommend a configured session to be enabled if desired. Hope it helps. -DWard On 12/20/05 1:24 PM, "Bill Barns" wrote: > A situation that interests me is health monitoring of labeled paths comin= g > from BGP using RFC 3107 when route reflector servers are the means of > distributing those paths/LSPs. BFD to the BGP peer isn't helpful to that > goal. And that seemed to give me an excuse to inquire whether BFD to the > next hops is a good idea for this purpose or if I should be looking > elsewhere. >=20 > For better or worse, there sure are a lot of features and flavors of OAM = / > link monitoring / connectivity verification / failure detection from vari= ous > points of view that could arguably be part of the picture. Overall I fin= d > that more disorienting than helpful, though. >=20 > /Bill >=20 > -----Original Message----- > From: rtg-bfd-bounces@ietf.org [mailto:rtg-bfd-bounces@ietf.org] On Behal= f > Of Carlos Garcia Braschi > Sent: Tuesday, December 20, 2005 1:49 PM > To: rtg-bfd@ietf.org > Subject: BFD for different BGP next hops >=20 > Hi, >=20 > Let's say there is an implementation of BFD used to test reachability > of routes announced through a BGP routing session. Let's say that the > BGP session announces several routes with different next hop > addresses, but all of them are inside the same subnet (so that they > could use bfd-v4v6-1hop). This could be the case, for example, in a > peering point. >=20 > I have a doubt: would a router implementing this establish a BFD > session with each next hop received or just with the BGP peer? >=20 > Although from the point of view of BFD interoperability this is of no > concern, from the point of view of using BFD in the practical sense, > it is quite important, as I would expect a BFD session with each next > hop, but probably others would like to check just the BGP peer and > think about this case an exception rather than the norm. > And the behaviours would be quite different... >=20 > Is this just an implementation option/issue that router manufacturers > may or may not offer? Should it have a name and/or more formal > description? >=20 > Something similar may happen with RIP but I think no one uses the > option so it's not an issue... >=20 > Regards, > Carlos. > -- > Telef=F3nica Empresas. >=20 From rtg-bfd-bounces@ietf.org Thu Dec 22 12:23:29 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpUA5-0001P2-NS; Thu, 22 Dec 2005 12:23:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpUA1-0001OL-Mk for rtg-bfd@megatron.ietf.org; Thu, 22 Dec 2005 12:23:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08432 for ; Thu, 22 Dec 2005 12:22:19 -0500 (EST) Received: from gateout02.mbox.net ([165.212.64.22]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpUCs-000203-0b for rtg-bfd@ietf.org; Thu, 22 Dec 2005 12:26:23 -0500 Received: from gateout02.mbox.net (gateout02.mbox.net [165.212.64.22]) by gateout02.mbox.net (Postfix) with ESMTP id C512C17A4; Thu, 22 Dec 2005 17:22:57 +0000 (GMT) Received: from gateout02.mbox.net [127.0.0.1] by gateout02.mbox.net via mtad (C8.MAIN.3.27E) with ESMTP id 432JLVRw40121Mo2; Thu, 22 Dec 2005 17:22:56 GMT Received: from gateout02.mbox.net [127.0.0.1] by gateout02.mbox.net via mtad (C8.MAIN.3.27E) with ESMTP id 431JLVRw20015Mo2; Thu, 22 Dec 2005 17:22:53 GMT X-USANET-Routed: 2 gwsout-vs R:localhost:1825 Received: from gw3.EXCHPROD.USA.NET [165.212.116.254] by gateout02.mbox.net via smtad (C8.MAIN.3.27I); Thu, 22 Dec 2005 17:22:53 GMT X-USANET-Source: 165.212.116.254 IN jhaas@nexthop.com gw3.EXCHPROD.USA.NET X-USANET-MsgId: XID633JLVRw24903Xo2 Received: from localhost ([65.247.36.31]) by gw3.EXCHPROD.USA.NET over TLS secured channel with Microsoft SMTPSVC(6.0.3790.211); Thu, 22 Dec 2005 10:22:52 -0700 Date: Thu, 22 Dec 2005 12:22:51 -0500 From: Jeffrey Haas To: David Ward Message-ID: <20051222172251.GD23148@nexthop.com> References: <0IRT004909XGHG@pmismtp04.mcilink.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-OriginalArrivalTime: 22 Dec 2005 17:22:52.0819 (UTC) FILETIME=[57163630:01C6071C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: 'Carlos Garcia Braschi' , rtg-bfd@ietf.org, Dave Katz Subject: Re: BFD for different BGP next hops X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: rtg-bfd-bounces@ietf.org Errors-To: rtg-bfd-bounces@ietf.org On Tue, Dec 20, 2005 at 06:04:36PM -0600, David Ward wrote: > 1) Form BFD sessions to the nexthops via IGP bootstrapping throughout the > topology. > > Thus, if the RR was using nexthopself you would be covered and also for all > interior nexthops. As a further (probably unneeded) clarification, for iBGP you probably wouldn't want to form BFD sessions for the nexthops in the non-directly connected case. In the event of an event in your internal network that affected forwarding, BFD between the various routers will cause the necessary IGP event to happen that will cause BGP to do the Right Thing. However, if the Right Thing isn't timely enough (time to flood and reconverge the IGP at a given BGP speaker, maybe in the several second range), a BFD session to a given iBGP nexthop *might* provide faster convergence. Personally, I think it'll just result in your thrashing your BGP every time you have lossy forwarding at any internal link. :-) The directly connected iBGP case resembles the eBGP case, so I'll comment on that below. > For EBGP nexthops, one should form BFD sessions via EBGP bootstrapping. For > third party nexthops, you will need to cause bootstrapping to occur via > other means (e.g. via CLI/NMS). Since it is rare/not-wise/violating > reasonable security measures to blindly accept all third party nexthops, the > authors believe it is also not wise to for BFD sessions via "triggered" > third party nexthops and recommend a configured session to be enabled if > desired. This is clearly a "rope" situation - give the customer what they want and they're likely to hang themselves. This wont stop someone from getting such rope installed. :-) BFD sessions to directly connected nexthops, triggered or not, can be helpful in situations where forwarding connectivity may not be properly reflected in the routing. ATM and frame relay networks, as examples, are vulnerable to blackholes resulting from imperfect meshing or failures in a given virtual circuit. Code wise, it might be appropriate to treat a nexthop with which you've enabled BFD to have the same effect as an unreachable IGP nexthop when you have a BFD session failure. > -DWard -- Jeff Haas NextHop Technologies