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

[Dave Katz <[e-mail]>]

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

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
> Sent from the IETF - Rtg-bfd mailing list archive at Nabble.com.