From rtg-bfd-bounces@ietf.org Tue Sep 18 06:41:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXaUG-0000fu-VX; Tue, 18 Sep 2007 06:39:24 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IXaUF-0000fk-Fk for rtg-bfd@ietf.org; Tue, 18 Sep 2007 06:39:23 -0400 Received: from kuber.nabble.com ([216.139.236.158]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IXaUE-0007R9-Kx for rtg-bfd@ietf.org; Tue, 18 Sep 2007 06:39:23 -0400 Received: from isper.nabble.com ([192.168.236.156]) by kuber.nabble.com with esmtp (Exim 4.63) (envelope-from ) id 1IXaUE-0002Nj-4W for rtg-bfd@ietf.org; Tue, 18 Sep 2007 03:39:22 -0700 Message-ID: <12754310.post@talk.nabble.com> Date: Tue, 18 Sep 2007 03:39:22 -0700 (PDT) From: aaron_castellino To: rtg-bfd@ietf.org MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_19559_451764.1190111962137" X-Nabble-From: nelson.aaron.xx.castellino@ericsson.com X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Subject: Some draft-ietf-bfd-base-06.txt Queries X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtg-bfd-bounces@ietf.org ------=_Part_19559_451764.1190111962137 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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. ------=_Part_19559_451764.1190111962137 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit 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: Some draft-ietf-bfd-base-06.txt Queries
Sent from the IETF - Rtg-bfd mailing list archive at Nabble.com.
------=_Part_19559_451764.1190111962137-- From rtg-bfd-bounces@ietf.org Wed Sep 19 17:33:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY79r-0004wX-U3; Wed, 19 Sep 2007 17:32:31 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IY79j-0004kH-9u for rtg-bfd@ietf.org; Wed, 19 Sep 2007 17:32:25 -0400 Received: from exprod7og52.obsmtp.com ([64.18.2.159]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IY79i-00078Q-2V for rtg-bfd@ietf.org; Wed, 19 Sep 2007 17:32:23 -0400 Received: from source ([66.129.224.36]) by exprod7ob52.obsmtp.com ([64.18.6.12]) with SMTP; Wed, 19 Sep 2007 14:32:00 PDT Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Wed, 19 Sep 2007 14:31:24 -0700 Received: from [172.16.12.13] (nimbus-sc.juniper.net [172.16.12.13]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id l8JLVNI55448; Wed, 19 Sep 2007 14:31:23 -0700 (PDT) (envelope-from dkatz@juniper.net) In-Reply-To: <12754310.post@talk.nabble.com> References: <12754310.post@talk.nabble.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: multipart/alternative; boundary=Apple-Mail-6--670598561 Message-Id: <8247D5F7-5305-4973-A3AE-B805E38F181B@juniper.net> From: Dave Katz Date: Wed, 19 Sep 2007 14:31:22 -0700 To: aaron_castellino X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 19 Sep 2007 21:31:24.0131 (UTC) FILETIME=[6DA4DB30:01C7FB04] X-Spam-Score: 1.8 (+) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Cc: rtg-bfd@ietf.org Subject: Re: Some draft-ietf-bfd-base-06.txt Queries X-BeenThere: rtg-bfd@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "RTG Area: Bidirectional Forwarding Detection DT" List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: rtg-bfd-bounces@ietf.org --Apple-Mail-6--670598561 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed 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. --Apple-Mail-6--670598561 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Kind of hard to read all mushed together. =A0I'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 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D 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. =A0There'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; =A0the 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 =3D=3D=3D= =3D 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. = =A0Demand mode is required to be implemented; =A0however, you never have = to set the D bit if you don't want to. =A0Essentially, receiving the D = bit tells you to stop sending periodic packets. =A0Essentially 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 =3D=3D=3D=3D 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. =A0The latter paragraph has lost most of its meaning (though = there is an implication that it applies to changes to bfd.DetectMult.) = =A0However, the "and" is inappropriate because there are cases where you = do want to immediately effect the timer changes but still do a poll = sequence. =A0Duly changed.


6.8.7 =3D=3D=3D=3D=3D 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.

= --Apple-Mail-6--670598561--