Re: Serval question! Thanks!!

[Dave Katz <[e-mail]>]

On Apr 15, 2005, at 10:36 AM, <[e-mail]> 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