From rtg-bfd-bounces@ietf.org Fri Apr 15 13:44:04 2005 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25818; Fri, 15 Apr 2005 13:44:04 -0400 (EDT) Received: from megatron.ietf.org ([132.151.6.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMV1b-0002k5-PJ; Fri, 15 Apr 2005 13:54:40 -0400 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMUkf-0005GF-88; Fri, 15 Apr 2005 13:37:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DMUke-0005Fc-57 for rtg-bfd@megatron.ietf.org; Fri, 15 Apr 2005 13:37:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25006 for ; Fri, 15 Apr 2005 13:37:00 -0400 (EDT) From: roggie-bfd@sohu.com Received: from [61.135.145.13] (helo=websmtp2.mail.sohu.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DMUuf-0002H6-0C for rtg-bfd@ietf.org; Fri, 15 Apr 2005 13:47:36 -0400 Received: from mx66.mail.sohu.com (unknown [192.168.95.81]) by websmtp2.mail.sohu.com (Postfix) with ESMTP id 8C9C20411A37; Sat, 16 Apr 2005 01:36:40 +0800 (CST) Message-ID: <26294606.1113586604737.JavaMail.postfix@mx66.mail.sohu.com> Date: Sat, 16 Apr 2005 01:36:44 +0800 (CST) To: Mime-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_560_6239160.1113586604732" X-Mailer: Sohu Web Mail 2.0.13 X-SHIP: 219.239.105.83 X-Priority: 3 X-SHMOBILE: 0 X-Sohu-Antivirus: 0 X-Spam-Score: 2.4 (++) X-Scan-Signature: cd3fc8e909678b38737fc606dec187f0 Cc: rtg-bfd@ietf.org Subject: Serval question! Thanks!! 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 X-Spam-Score: 2.4 (++) X-Scan-Signature: 311e798ce51dbeacf5cdfcc8e9fda21b ------=_Part_560_6239160.1113586604732 Content-Type: multipart/alternative; boundary="----=_Part_559_11721563.1113586604732" ------=_Part_559_11721563.1113586604732 Content-Type: text/plain; charset="GB2312" X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id NAA25006 Content-Transfer-Encoding: quoted-printable Dave, 1=A1=A2The transmmit interval is at least 1s before the session is UP ,= i am not sure does the vlaue set to the BFD control packet! if does and at what time = does the BFD control set the actual value to the BFD control packet , if not how= to decided=20 the INIT timeout time ? Before the session is UP if received a P bit se= t control packet , it will send back a F bit set control packet , but the vlaue o= f MTI and MRI in the control packet is setted to 1s or the actual value ?? 2=A1=A2In Section 4.1 it said "Poll (P) If set, the transmitting system is requesting verification of connectivity, or of a parameter change. If clear, the transmitting system is not requesting verification." In Section 6.7.3 it said "If Demand mode is active, and either bfd.DesiredMinTxInterval is changed or bfd.RequiredMinRxInterval is changed, a Poll Sequence MUST be initiated (see section 6.7.8). If Demand mode is not active, bfd.SessionState is Up, and either bfd.DesiredMinTxInterval is changed or bfd.RequiredMinRxInterval is changed, all subsequent transmitted Control packets MUST be sent with the Poll (P) bit set until a packet is received with the Final (F) bit set (except for those packets sent in response to received Polls.)" In Section 6.7.13 it said "When it is desired to change the detect multiplier, the value of bfd.DetectMult can be changed to any nonzero value. The new value will be transmitted with the next BFD Control packet. See section 6.7.8 for additional requirements." I am not sure whether the "parameter change" said in Section 4.1 includ= e=20 the Detect Multiplier Change that said in Section 6.7.13 , or ONLY incl= ude=20 the timer parameters that said in Section 6.7.3. =20 pls list the "parameter change" case that said in Section 4.1 ! =20 3=A1=A2In Section 6.7.3 , it only said that when MTI increased or MRI r= educed the actual transmission interval or detection time MUST not change unti= l=20 a Control packet is received with the Final (F) bit set . if MTI reduce= d it will change the transmission interval immediately , but i think it w= ill have problem until received a control packet from remote system if the=20 changed MTI vlaue is very low but the remote MRI is very large . =20 4=A1=A2a question for example : A ------ B MTI=3D100ms MTI=3D10ms MRI=3D20ms MRI=3D30ms MERI=3D20ms if A want to send echo packet , the actual echo transmission interval=20 will be the largest value of A's MTI and A's MRI and B's MTI and B's MR= I=20 and B's MERI , is it right??? =20 =20 5=A1=A2if echo function is active , i am not sure whether the echo pack= et is sent periodly in Demand mode mode and Asynchronous mode , or ONLY sent=20 periodly in Asynchronous mode and when needed in Demand mode?? =20 6=A1=A2if echo function is active , the control packet is sent at least= 1s=20 and the control packet will take the 1s value in it , is it correct?? =20 7=A1=A2if BFD run on the multi-hop route , it will only detect whether = the=20 route can reached the destination or not , it can not detect whether th= e route had changed on another route , is it correct ?? =20 8=A1=A2BTW , in Section 6.7.8 it said "Note that if the I Hear You (H) bit is changing to zero, the session is going down and Demand mode will no longer be active." the statement is not right because the I Hear You (H) bit is removed. =20 Thanks for your help!! Roggie =20 ------=_Part_559_11721563.1113586604732 Content-Type: text/html X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id NAA25006 Content-Transfer-Encoding: quoted-printable 
Dave,
  1=A1=A2The transmmit interval is at least 1s before the session is UP ,=
 i am not sure
  does the vlaue set to the BFD control packet! if does and at what time =
does the
  BFD control set the actual value to the BFD control packet , if not how=
 to decided=20
  the INIT timeout time ? Before the session is UP if received a P bit se=
t control
  packet , it will send back a F bit set control packet , but the vlaue o=
f MTI and MRI
  in the control packet is setted to 1s or the actual value ??
  2=A1=A2In Section 4.1 it said
   "Poll (P)

      If set, the transmitting system is requesting verification of
      connectivity, or of a parameter change.  If clear, the
      transmitting system is not requesting verification."
  In Section 6.7.3 it said
   "If Demand mode is active, and either bfd.DesiredMinTxInterval is
   changed or bfd.RequiredMinRxInterval is changed, a Poll Sequence MUST
   be initiated (see section 6.7.8).

   If Demand mode is not active, bfd.SessionState is Up, and either
   bfd.DesiredMinTxInterval is changed or bfd.RequiredMinRxInterval is
   changed, all subsequent transmitted Control packets MUST be sent with
   the Poll (P) bit set until a packet is received with the Final (F)
   bit set (except for those packets sent in response to received
   Polls.)"
  In Section 6.7.13 it said
   "When it is desired to change the detect multiplier, the value of
   bfd.DetectMult can be changed to any nonzero value.  The new value
   will be transmitted with the next BFD Control packet.  See section
   6.7.8 for additional requirements."
  I am not sure whether the "parameter change" said in Section 4.1 includ=
e=20
  the Detect Multiplier Change that said in Section 6.7.13 , or ONLY incl=
ude=20
  the timer parameters that said in Section 6.7.3.
 =20
  pls list the "parameter change" case that said in Section 4.1 !
 =20
  3=A1=A2In Section 6.7.3 , it only said that when MTI increased or MRI r=
educed
  the actual transmission interval or detection time MUST not change unti=
l=20
  a Control packet is received with the Final (F) bit set . if MTI reduce=
d
  it will change the transmission interval immediately , but i think it w=
ill
  have problem until received a control packet from remote system if the=20
  changed MTI vlaue is very low but the remote MRI is very large .
 =20
  4=A1=A2a question for example :
     A    ------     B
  MTI=3D100ms     MTI=3D10ms
  MRI=3D20ms      MRI=3D30ms
                MERI=3D20ms
  if A want to send echo packet , the actual echo transmission interval=20
  will be the largest value of A's MTI and A's MRI and B's MTI and B's MR=
I=20
  and B's MERI , is it right???  =20
 =20
  5=A1=A2if echo function is active , i am not sure whether the echo pack=
et is
  sent periodly in Demand mode mode and Asynchronous mode , or ONLY sent=20
  periodly in Asynchronous mode and when needed in Demand mode??
 =20
  6=A1=A2if echo function is active , the control packet is sent at least=
 1s=20
  and the control packet will take the 1s value in it , is it correct??
 =20
  7=A1=A2if BFD run on the multi-hop route , it will only detect whether =
the=20
  route can reached the destination or not , it can not detect whether th=
e
  route had changed on another route , is it correct ??
 =20
  8=A1=A2BTW , in Section 6.7.8 it said
  "Note that if
   the I Hear You (H) bit is changing to zero, the session is going down
   and Demand mode will no longer be active."
   the statement is not right because the I Hear You (H) bit is removed.
 =20
Thanks for your help!!
Roggie
------=_Part_559_11721563.1113586604732-- ------=_Part_560_6239160.1113586604732-- From rtg-bfd-bounces@ietf.org Tue Apr 19 15:14:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNyAe-0004mu-8c; Tue, 19 Apr 2005 15:14:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNyAa-0004lG-SO for rtg-bfd@megatron.ietf.org; Tue, 19 Apr 2005 15:14:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10462 for ; Tue, 19 Apr 2005 15:13:58 -0400 (EDT) Received: from colo-dns-ext2.juniper.net ([207.17.137.64]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNyLd-0002M3-Rx for rtg-bfd@ietf.org; Tue, 19 Apr 2005 15:25:27 -0400 Received: from merlot.juniper.net (merlot.juniper.net [172.17.27.10]) by colo-dns-ext2.juniper.net (8.12.3/8.12.3) with ESMTP id j3JJDnBm071517; Tue, 19 Apr 2005 12:13:49 -0700 (PDT) (envelope-from dkatz@juniper.net) Received: from [172.16.12.13] (nimbus-sc.juniper.net [172.16.12.13]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id j3JJDme86270; Tue, 19 Apr 2005 12:13:48 -0700 (PDT) (envelope-from dkatz@juniper.net) In-Reply-To: <26294606.1113586604737.JavaMail.postfix@mx66.mail.sohu.com> References: <26294606.1113586604737.JavaMail.postfix@mx66.mail.sohu.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=ISO-2022-JP; format=flowed Message-Id: <2811b5aeac3ad73af62196da67eb3336@juniper.net> Content-Transfer-Encoding: 7bit From: Dave Katz Date: Tue, 19 Apr 2005 12:13:46 -0700 To: X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Content-Transfer-Encoding: 7bit Cc: rtg-bfd@ietf.org Subject: Re: Serval question! Thanks!! 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 Apr 15, 2005, at 10:36 AM, wrote: > Dave, > 1、The transmmit interval is at least 1s before the session is UP , i > am not sure > does the vlaue set to the BFD control packet! if does and at what > time does the > BFD control set the actual value to the BFD control packet , if not > how to decided > the INIT timeout time ? Before the session is UP if received a P bit > set control > packet , it will send back a F bit set control packet , but the > vlaue of MTI and MRI > in the control packet is setted to 1s or the actual value ?? The values in the packet fields are always valid; the timing requirements when not in Up state mandate that the 1 second (or greater) values are advertised in the packets. This should be clear in the spec, which says that bfd.DesiredMinTxInterval has to be set to at least 1 second; the rules for building packets say that you put bfd.DesiredMinTxInterval into the field in the packet. > 2、In Section 4.1 it said > "Poll (P) > > If set, the transmitting system is requesting verification of > connectivity, or of a parameter change. If clear, the > transmitting system is not requesting verification." > In Section 6.7.3 it said > "If Demand mode is active, and either bfd.DesiredMinTxInterval is > changed or bfd.RequiredMinRxInterval is changed, a Poll Sequence > MUST > be initiated (see section 6.7.8). > > If Demand mode is not active, bfd.SessionState is Up, and either > bfd.DesiredMinTxInterval is changed or bfd.RequiredMinRxInterval is > changed, all subsequent transmitted Control packets MUST be sent > with > the Poll (P) bit set until a packet is received with the Final (F) > bit set (except for those packets sent in response to received > Polls.)" > In Section 6.7.13 it said > "When it is desired to change the detect multiplier, the value of > bfd.DetectMult can be changed to any nonzero value. The new value > will be transmitted with the next BFD Control packet. See section > 6.7.8 for additional requirements." > I am not sure whether the "parameter change" said in Section 4.1 > include > the Detect Multiplier Change that said in Section 6.7.13 , or ONLY > include > the timer parameters that said in Section 6.7.3. > > pls list the "parameter change" case that said in Section 4.1 ! Section 4.1 is describing the general purpose of the field, and does not describe normative behavior. The parameter changes alluded to there are the ones explicitly called out in 6.7.3 (the timing parameters.) Detect Mult can change at any time when demand mode isn't running; however, 6.7.8 requires that all content changes in demand mode trigger a poll sequence (since otherwise the far end will never hear about them.) > > 3、In Section 6.7.3 , it only said that when MTI increased or MRI > reduced > the actual transmission interval or detection time MUST not change > until > a Control packet is received with the Final (F) bit set . if MTI > reduced > it will change the transmission interval immediately , but i think > it will > have problem until received a control packet from remote system if > the > changed MTI vlaue is very low but the remote MRI is very large . If the remote RX Interval is larger than the local TX Interval, then the local transmission rate will not change regardless of the value of the local TX interval (the remote system has negotiated a higher rate) so it doesn't matter what happens. > > 4、a question for example : > A ------ B > MTI=100ms MTI=10ms > MRI=20ms MRI=30ms > MERI=20ms > if A want to send echo packet , the actual echo transmission interval > will be the largest value of A's MTI and A's MRI and B's MTI and B's > MRI > and B's MERI , is it right??? The echo rate is controlled only by the remote's advertised minimum echo RX interval. The MTI/MRI fields only affect the transmission rate of control packets. This allows echo and control packets to run at different rates, which is one of the reasons for having echo mode. > > 5、if echo function is active , i am not sure whether the echo packet > is > sent periodly in Demand mode mode and Asynchronous mode , or ONLY > sent > periodly in Asynchronous mode and when needed in Demand mode?? Echo packets are always sent periodically when the echo function is active; it is independent of demand mode. One useful way of applying demand mode is in conjunction with both sides running the echo function; since the echo function is supplying detection, the control protocol can go to sleep. > > 6、if echo function is active , the control packet is sent at least 1s > and the control packet will take the 1s value in it , is it correct?? Control packets can be sent at any rate determined by the participants, independent of the echo function. It is noted that, since the echo function provides liveness detection, the control packets may be sent slowly (1 sec or greater) or not at all (demand mode) but this is up to the implementations. As always, the RX and TX intervals control the transmission rate, so if an implementation wants to slow down control packets, it must do so by manipulating the timing parameters. > > 7、if BFD run on the multi-hop route , it will only detect whether the > route can reached the destination or not , it can not detect whether > the > route had changed on another route , is it correct ?? BFD knows nothing of routes; it only demonstrates connectivity. > > 8、BTW , in Section 6.7.8 it said > "Note that if > the I Hear You (H) bit is changing to zero, the session is going > down > and Demand mode will no longer be active." > the statement is not right because the I Hear You (H) bit is > removed. Thanks for pointing this out. --Dave From rtg-bfd-bounces@ietf.org Thu Apr 21 09:36:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DObqy-00037D-7T; Thu, 21 Apr 2005 09:36:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DObqw-00036V-Hx for rtg-bfd@megatron.ietf.org; Thu, 21 Apr 2005 09:36:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA29576 for ; Thu, 21 Apr 2005 09:36:21 -0400 (EDT) Received: from rproxy.gmail.com ([64.233.170.199]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DOc2M-0007eT-Lu for rtg-bfd@ietf.org; Thu, 21 Apr 2005 09:48:11 -0400 Received: by rproxy.gmail.com with SMTP id z35so427632rne for ; Thu, 21 Apr 2005 06:36:11 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=OL1tbDCNgn9wHr3OytSK6nys5AIeS4Xsu2ygl/N7QhrIIPCKRtySF7YX6h1flujG1v4h50Zk3iY6KilN+oRyk3z8BXbIoLGxIDRpmagKgpw7XU4zf0stQwwLcl2wMgj+D56k2YHHG/kP9RDJNgXmVOwDn4ablVrWI1Y0kqDwHnI= Received: by 10.38.78.59 with SMTP id a59mr2212957rnb; Thu, 21 Apr 2005 06:36:11 -0700 (PDT) Received: by 10.38.75.43 with HTTP; Thu, 21 Apr 2005 06:36:11 -0700 (PDT) Message-ID: <9e31186f050421063668a536eb@mail.gmail.com> Date: Thu, 21 Apr 2005 15:36:11 +0200 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: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable Subject: Pending issues? X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Carlos Garcia Braschi 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, After a little action after the IETF meeting, traffic about new questions regarding the protocol has been dwindling. There seems to be no pending issues with the current drafts, and little wording to be added to the drafts (Admin Down issue, AFAIK). Is there something keeping the drafts from moving forward? (apart from the workload on the authors, of course :-). On the other hand, I still do not have a clear understanding on how the issue of application to static routes, BGP (and I would like also to add RIP) could be progressed. Last time we wrote about a separate draft, would it be done in this WG? Or should it go to the home WG of the routing protocols? (actually it seems only BGP has a WG now...). For RIP and static routes there does not seem to me to be a need for changes to be made to the protocols on the wire. I do not know for BGP (haven't been able to find the details of the proposal), but does not seem to be needed, either, so this WG could be the place... Regards, Carlos. From rtg-bfd-bounces@ietf.org Thu Apr 28 10:05:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DR9de-0003M1-Qg; Thu, 28 Apr 2005 10:05:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DR9dd-0003Lw-1i for rtg-bfd@megatron.ietf.org; Thu, 28 Apr 2005 10:05:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17391 for ; Thu, 28 Apr 2005 10:05:05 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.205]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DR9qS-0003lb-Rk for rtg-bfd@ietf.org; Thu, 28 Apr 2005 10:18:26 -0400 Received: by wproxy.gmail.com with SMTP id 71so608215wri for ; Thu, 28 Apr 2005 07:04:57 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=s3zzK+FUY239kGs9Kd0N+ObPw303KjaRX3TaXw4Zby5sP0LOBsuj+SOqAK9L51CXeZqwVCYsw+c/hbvLXkqfWBtYIiIsx7pDv1AyEGzu9dVFbE664GNNOy4O+YmfR8P1UKJzFgUXE3MtShsB3FC45HIXm23bpX7j+qQm6tE2CqY= Received: by 10.54.121.18 with SMTP id t18mr256685wrc; Thu, 28 Apr 2005 07:04:57 -0700 (PDT) Received: by 10.54.70.2 with HTTP; Thu, 28 Apr 2005 07:04:57 -0700 (PDT) Message-ID: Date: Thu, 28 Apr 2005 10:04:57 -0400 From: Rurick Kellermann 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: bb8eae9af85e4fcfe76f325e38493bf4 Content-Transfer-Encoding: quoted-printable Subject: test message X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Rurick Kellermann 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