Subject: Serval question! Thanks!!

From: [email-masked]
Date: Sat, 16 Apr 2005 01:36:44 +0800 (CST)

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 ??
  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 !
  
  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 .
  
  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???   
  
  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??
  
  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??
  
  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 ??
  
  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 your help!!
Roggie

---

From: Dave Katz <[email-masked]>
Date: Tue, 19 Apr 2005 12:13:46 -0700

>   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.

>   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.)

>   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.

>   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.

>   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.

>   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.

>   route had changed on another route , is it correct ??

BFD knows nothing of routes;  it only demonstrates connectivity.

>    the statement is not right because the I Hear You (H) bit is 

Thanks for pointing this out.

--Dave