Re: Serval question! Thanks!!
Dave Katz <email@example.com> Tue, 19 April 2005 19:14 UTC
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 ([18.104.22.168] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DNyAa-0004lG-SO for firstname.lastname@example.org; Tue, 19 Apr 2005 15:14:03 -0400
Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [22.214.171.124]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10462 for <email@example.com>; Tue, 19 Apr 2005 15:13:58 -0400 (EDT)
Received: from colo-dns-ext2.juniper.net ([126.96.36.199]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DNyLd-0002M3-Rx for firstname.lastname@example.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 email@example.com)
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 firstname.lastname@example.org)
Mime-Version: 1.0 (Apple Message framework v622)
Content-Type: text/plain; charset="ISO-2022-JP"; format="flowed"
From: Dave Katz <email@example.com>
Date: Tue, 19 Apr 2005 12:13:46 -0700
X-Mailer: Apple Mail (2.622)
X-Spam-Score: 0.0 (/)
Subject: Re: Serval question! Thanks!!
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:firstname.lastname@example.org?subject=unsubscribe>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:email@example.com?subject=subscribe>
On Apr 15, 2005, at 10:36 AM, <firstname.lastname@example.org> 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