Subject: Some draft-ietf-bfd-base-06.txt Queries

From: aaron_castellino <[email-masked]>
Date: Tue, 18 Sep 2007 03:39:22 -0700 (PDT)

Just some implementation queries!

4.1. Generic BFD Control Packet Format
===========================

1.   Desired Min TX Interval

      This is the minimum interval, in microseconds, that the local
      system would like to use when transmitting BFD Control packets.
      The value zero is reserved.
      
Q. Why is the value zero reserved. What happens if I get a packet with this
value as zero. Should it be discarded. if so then why is it reserved?

2.   Required Min RX Interval

      This is the minimum interval, in microseconds, between received
      BFD Control packets that this system is capable of supporting.  If
      this value is zero, the transmitting system does not want the
      remote system to send any periodic BFD Control packets.

Q. Shouldn't it be that if this this value is zero and demand mode bit is
set then the transmitting system does not want the receving system to send
packets. Along with this, if demand mode bit is not set, shouldnt the
received packet be discarded.What is the requirement of a sending system to
send a BFD control packet with this feild as zero in Async mode.

6.6
====
3. Note that if Demand mode is enabled in only one direction, continuous  
       bidirectional connectivity verification is lost (only connectivity in  
       the direction from the system in Demand mode to the other system will  
       be verified.)  Resolving the issue of one system requesting Demand  
       mode while the other requires continuous bidirectional connectivity  
       verification is outside the scope of this specification. 

Q .if a system wants to support only Asyncronous mode and will discard
demand mode packets? What happens in this situation? 
Since now each system can independently support demand mode, wouldnt it be a
problem for systems not supporting demand mode. I asume in this case the
system in this case
cannot even inform the other station that demand mode is not supported

6.8.3
====
4. If either bfd.DesiredMinTxInterval is changed or
   bfd.RequiredMinRxInterval is changed, a Poll Sequence MUST be
   initiated (see section 6.5).
   
In any case other than those explicitly called out above, timing
   parameter changes MUST be effected immediately (changing the
   transmission rate and/or the Detection Time), and a Poll Sequence
   SHOULD NOT be sent.
   
Q. Considering the above 2 statements what are the cases in which timing
parameters can be sent without poll bit set?
It seems there is no such situation except for detection time change which
does not require poll bit to be set.

6.8.7
=====          
5. A system MUST NOT periodically transmit BFD Control packets if  
       bfd.RemoteMinRxInterval is zero. 

Q. Should not this be only in demand mode? In Async mode how is this
possible?What is the purpose of this?
In Async mode if this is true, how does the state machine work, timers,
intervals etc?

Regards
/Aaron
-- 
View this message in context: http://www.nabble.com/Some-draft-ietf-bfd-base-06.txt-Queries-tf4473305.html#a12754310
Sent from the IETF - Rtg-bfd mailing list archive at Nabble.com.

---

From: Dave Katz <[email-masked]>
Date: Wed, 19 Sep 2007 14:31:22 -0700

Kind of hard to read all mushed together.  I'll try to tease it out.

On Sep 18, 2007, at 3:39 AM, aaron_castellino wrote:

> Just some implementation queries! 4.1. Generic BFD Control Packet  
> Format =========================== 1. Desired Min TX Interval This  
> is the minimum interval, in microseconds, that the local system  
> would like to use when transmitting BFD Control packets. The value  
> zero is reserved. Q. Why is the value zero reserved. What happens  
> if I get a packet with this value as zero. Should it be discarded.  
> if so then why is it reserved?

It's reserved because it isn't semantically meaningful.  There's no  
harm if you receive it as zero because the rules for determining the  
actual TX rate and detection time will end up ignoring it anyhow.

> 2. Required Min RX Interval This is the minimum interval, in  
> microseconds, between received BFD Control packets that this system  
> is capable of supporting. If this value is zero, the transmitting  
> system does not want the remote system to send any periodic BFD  
> Control packets. Q. Shouldn't it be that if this this value is zero  
> and demand mode bit is set then the transmitting system does not  
> want the receving system to send packets.

Nope;  the zero value is used in some instances in multipoint mode as  
well.

> Along with this, if demand mode bit is not set, shouldnt the  
> received packet be discarded.

No.

> What is the requirement of a sending system to send a BFD control  
> packet with this feild as zero in Async mode.

See the multipoint extensions.

> 6.6 ==== 3. Note that if Demand mode is enabled in only one  
> direction, continuous bidirectional connectivity verification is  
> lost (only connectivity in the direction from the system in Demand  
> mode to the other system will be verified.) Resolving the issue of  
> one system requesting Demand mode while the other requires  
> continuous bidirectional connectivity verification is outside the  
> scope of this specification. Q .if a system wants to support only  
> Asyncronous mode and will discard demand mode packets? What happens  
> in this situation?

It would be out of spec.  Demand mode is required to be implemented;   
however, you never have to set the D bit if you don't want to.   
Essentially, receiving the D bit tells you to stop sending periodic  
packets.  Essentially that's the only thing that is truly required  
(since if you never want to *send* the D bit, nobody can tell that  
you didn't implement the sending half.)

> Since now each system can independently support demand mode,  
> wouldnt it be a problem for systems not supporting demand mode. I  
> asume in this case the system in this case cannot even inform the  
> other station that demand mode is not supported

See above.

> 6.8.3 ==== 4. If either bfd.DesiredMinTxInterval is changed or  
> initiated (see section 6.5). In any case other than those  
> explicitly called out above, timing parameter changes MUST be  
> effected immediately (changing the transmission rate and/or the  
> Detection Time), and a Poll Sequence SHOULD NOT be sent. Q.  
> Considering the above 2 statements what are the cases in which  
> timing parameters can be sent without poll bit set? It seems there  
> is no such situation except for detection time change which does  
> not require poll bit to be set.

Good catch.  The latter paragraph has lost most of its meaning  
(though there is an implication that it applies to changes to  
bfd.DetectMult.)  However, the "and" is inappropriate because there  
are cases where you do want to immediately effect the timer changes  
but still do a poll sequence.  Duly changed.

> 6.8.7 ===== 5. A system MUST NOT periodically transmit BFD Control  
> packets if bfd.RemoteMinRxInterval is zero. Q. Should not this be  
> only in demand mode? In Async mode how is this possible?What is the  
> purpose of this? In Async mode if this is true, how does the state  
> machine work, timers, intervals etc? Regards /Aaron

Once again, see the multipoint spec.

Thanks for the close reading.

--Dave

>
> View this message in context: Some draft-ietf-bfd-base-06.txt Queries