Subject: BFD spec updates

From: David Ward <[email-masked]>
Date: Mon, 2 Feb 2009 12:50:25 -0600

All -

Dave and Dave are presently hacking through new revs of the specs that  
covers the IESG discusses and other comments on the list over the last  
several months.

I expect new drafts in a week or so.

Thanks for your patience

Dave and Dave

---

From: Vishwas Manral <[email-masked]>
Date: Mon, 2 Feb 2009 11:11:49 -0800

Hi Dave,

Here are some things I notices when unit testing the BFD:

1. Linux does not allow the same port to be used for IPv4 and IPv6
while receiving a packet. Like other protocols RIPNG, VRRP etc can we
have a seperate set of ports for IPv6 instead of the same as IPv4. I
think its the same in other OS's like NetBSD.

2. While doing an echo, a random source address needs to be given.
Routers do not accept packets coming from others having the source
address as one of the routers IP address.

3. The Sequence number in the authentication can be made to a 64 bit
instead of 32-bit especially for meticulously keyed. Like in the
example I gave (on this list earlier) with BFD running at a fast rate
and 20 neighbors, the sequence number expires in a few days.

4. Multihop echo should be discouraged (like you mentioned in your
mail to me earlier).

5. Security implications as discussed in mails earlier.

Thanks,
Vishwas

---

From: Minto Jeyananth <[email-masked]>
Date: Mon, 2 Feb 2009 13:25:31 -0800

Vishwas,   

|
|3. The Sequence number in the authentication can be made to a 64 bit
|instead of 32-bit especially for meticulously keyed. Like in the
|example I gave (on this list earlier) with BFD running at a fast rate
|and 20 neighbors, the sequence number expires in a few days.

[minto] I'm missing something here. Sequence number is nothing do with
number of neighbors. If you run 10 millisecond transmit interval then it
will take nearly 450 days to wrap. 

-minto

---

From: Vishwas Manral <[email-masked]>
Date: Mon, 2 Feb 2009 13:48:18 -0800

Hi Minto,

> will take nearly 450 days to wrap.
I think you are right about the neighbors part. I would still want the
sequence numbers to be 64 bits even with your calculations (though the
packet could use the last 32 bits of the sequence number).

Do you know of any implementations which are currently using
authentication in BFD? We intend to do it soon, however have been
waiting for things to become clearer.

Thanks,
Vishwas

---

From: Dave Katz <[email-masked]>
Date: Mon, 2 Feb 2009 15:47:08 -0700

> think its the same in other OS's like NetBSD.

If this is the case, then Linux is deeply broken.  There are plenty of  
counterexamples;  there is not a separate V6 port for every TCP or UDP  
protocol out there.  We should not be torquing specs around broken  
operating systems.  If somebody wants BFD v6 in Linux, they can fix  
the port problem while they're there.  (Not to mention that v6 BFD is  
already deployed with the port number that was specified quite some  
time ago.)

> address as one of the routers IP address.

Many routers do many things.  We believe it is sufficient to specify  
the desired outcome, within the constraints of relevant standards,  
without getting into specifics.  This would seem to be the purview of  
a BCP.

> and 20 neighbors, the sequence number expires in a few days.

Nitin already pointed out the fact that the neighbor count does not  
apply.  But you mentioned in another message about carrying 32 bits  
out of 64;  this would accomplish exactly nothing, if I understand  
correctly.  The only function of the sequence number is to ameliorate  
replay attacks;  having 32 bits of extra sequence number hiding at  
both ends does nothing to further that goal, assuming that there was  
some way to synchronize the upper 32 bits, which there is not (the  
sequence number is not required to start from 0 or 1).

> 4. Multihop echo should be discouraged (like you mentioned in your

This has been added.

> 5. Security implications as discussed in mails earlier.

Verbiage has been added that deprecates MD5, and any further work  
(HMAC etc.) should be done via additional WG work.  Is there something  
else needed?

--Dave

---

From: Nitin Bahadur <[email-masked]>
Date: Mon, 2 Feb 2009 14:51:06 -0800

> think its the same in other OS's like NetBSD.

This is an OS issue. Multiple vendors support BFD IPv4 & IPv6 with just 1
port.

Thanks
Nitin

---

From: Vishwas Manral <[email-masked]>
Date: Mon, 2 Feb 2009 15:45:33 -0800

Hi Dave,

Like I had clearly mentioned in a mail, these are issues I found
during implementation/ testing. This may/ may not be incorporated in
the RFC.

> Nitin already pointed out the fact that the neighbor count does not apply.
>  But you mentioned in another message about carrying 32 bits out of 64;
>  this would accomplish exactly nothing, if I understand correctly.  The only
> function of the sequence number is to ameliorate replay attacks;  having 32
> bits of extra sequence number hiding at both ends does nothing to further
> that goal, assuming that there was some way to synchronize the upper 32
> bits, which there is not (the sequence number is not required to start from
> 0 or 1).
Minto, pointed out that the number of neighbors don't matter. That
said you got it right sequence number is used to amiliorate the replay
attacks. As the sequence number wraps around fast, the replay attacks
of packets become easier.

If we started with a 64 bit sequence number with only the last 32 bit
randomized in the first packet (the higher order 32 bits being 0), the
packets cannot be replayed at all, even if we use a 32 bit sequence
number.

> protocol out there.
I agree not all protocols have different UDP ports for IPv4 and IPv6.
However I am telling you of a practical issue with implementations
which have rightly been taken care of in a lot of protocols, which can
easily be accomadated in BFD too. Like I said it may be more than a
Linux only issue (other OS's too).

> Many routers do many things.  We believe it is sufficient to specify the
> desired outcome, within the constraints of relevant standards, without
> getting into specifics.  This would seem to be the purview of a BCP.
I agree. however the drafts do talk about application specific
information, like ICMP redirects etc need to be turned off. I was
giving more information based on the coding and testing I have done.

> Verbiage has been added that deprecates MD5, and any further work (HMAC
> etc.) should be done via additional WG work.  Is there something else
> needed?
Actually there are issues with SHA-1 too. That is the reason we have
been propagating HMAC-SHA-1 at the least. Maybe once the updated
document is there we can comment on it.

If you look at some of the archived mails (there has hardly been any
discussion) you will find the other issues/ concerns that have been
raised along the way.

Thanks,
Vishwas

On Mon, Feb 2, 2009 at 2:47 PM, Dave Katz <[email-masked]> wrote:
> protocol out there.  We should not be torquing specs around broken operating
> systems.  If somebody wants BFD v6 in Linux, they can fix the port problem
> while they're there.  (Not to mention that v6 BFD is already deployed with
> the port number that was specified quite some time ago.)
>
>>
>>
> Many routers do many things.  We believe it is sufficient to specify the
> desired outcome, within the constraints of relevant standards, without
> getting into specifics.  This would seem to be the purview of a BCP.
>
>>
>>
> Nitin already pointed out the fact that the neighbor count does not apply.
>  But you mentioned in another message about carrying 32 bits out of 64;
>  this would accomplish exactly nothing, if I understand correctly.  The only
> function of the sequence number is to ameliorate replay attacks;  having 32
> bits of extra sequence number hiding at both ends does nothing to further
> that goal, assuming that there was some way to synchronize the upper 32
> bits, which there is not (the sequence number is not required to start from
> 0 or 1).
>
>>
>>
> Verbiage has been added that deprecates MD5, and any further work (HMAC
> etc.) should be done via additional WG work.  Is there something else
> needed?
>
> --Dave
>
>>
>>
>> Thanks,
>> Vishwas
>>

---

From: Vishwas Manral <[email-masked]>
Date: Mon, 2 Feb 2009 15:49:07 -0800

Hi Nitin,

> This is an OS issue. Multiple vendors support BFD IPv4 & IPv6 with just 1
I agree. However as we move forward BFD is being extended to multiple
environments and there may be a lot more implementations of BFD.

I myself am trying to work on BFD for OAM purposes for Multiaccess
links and OAM in conjunction with CFM.

Thanks,
Vishwas

---

From: Dave Katz <[email-masked]>
Date: Mon, 2 Feb 2009 19:00:32 -0700

On Feb 2, 2009, at 4:45 PM, Vishwas Manral wrote:

>> apply.

Woops, sorry Minto.

> packets cannot be replayed at all, even if we use a 32 bit sequence

This doesn't make sense to me.  The packet carries 32 bits only.  If  
the 32 bits are incrementing, the evildoer can inject a packet with  
the right 32 bit value into the stream at the right instant after 20  
days or whatever the interval is, and he can inject the *same* packet  
every 20 days and it will still be accepted.  Anything not carried in  
the packet simply doesn't matter, as the bad guy doesn't need to know  
the other 32 bits.  Or am I still missing something?

> Linux only issue (other OS's too).

Not so easily, as the existing port numbers have already been  
deployed.  It will be easier (and proper) to fix Linux, since it is  
obviously broken.

> giving more information based on the coding and testing I have done.

The redirect issue is standards-based.  We're not going to be able to  
describe every implementation issue.  I've added some general text  
about APIs and such;  once the new drafts are out we can revisit this  
if necessary.

>> (HMAC

I've been digging through all the email, but other than the general  
comments on the weakness of MD5 and some strengthening of the verbiage  
about using cryptographic authentication, I haven't been able to find  
anything that applies to the drafts in question.  Incompatible changes  
or new authentication types belong in other documents at this point.   
Please point me at specifics if I've missed anything obvious.

Thanks,

--Dave

---

From: Vishwas Manral <[email-masked]>
Date: Mon, 2 Feb 2009 18:42:17 -0800

Hi Dave,

> This doesn't make sense to me.  The packet carries 32 bits only.  If the 32
> bits are incrementing, the evildoer can inject a packet with the right 32
> bit value into the stream at the right instant after 20 days or whatever the
> interval is, and he can inject the *same* packet every 20 days and it will
> still be accepted.  Anything not carried in the packet simply doesn't
> matter, as the bad guy doesn't need to know the other 32 bits.  Or am I
> still missing something?
Ok it is like this. When you calculate the hash you actually use 64
bits, but the higher order 32 bits are assumed to be known. So we
start with 0 and as the lower order sequence wraps around, both ends
increment the higher order bits. So the number is implicitly known to
the two ends but never sent across. So we can only be exchanging 32
bit numbers but using 64 bit numbers for hash calculations.

An older packet replayed will not work if the higher order bits do not
match as the sequence numbers will not match.

> Not so easily, as the existing port numbers have already been deployed.  It
> will be easier (and proper) to fix Linux, since it is obviously broken.
Ok.

> describe every implementation issue.  I've added some general text about
> APIs and such;  once the new drafts are out we can revisit this if
> necessary.
Ok.

> I've been digging through all the email, but other than the general comments
> on the weakness of MD5 and some strengthening of the verbiage about using
> cryptographic authentication, I haven't been able to find anything that
> applies to the drafts in question.  Incompatible changes or new
> authentication types belong in other documents at this point.  Please point
> me at specifics if I've missed anything obvious.
Let me dig deeper and see if I find something. Also let me see if I
remember some other issues I have had with the implementation.

One interesting one was if the slow timer value configured is actually
faster than the tx/ rx interval used and we change the inactivity
interval (detect interval - but you could call it an off scenario).

Thanks,
Vishwas

---

From: Dave Katz <[email-masked]>
Date: Mon, 2 Feb 2009 19:54:58 -0700

> match as the sequence numbers will not match.

Ah, got it.  This would be an incompatible change to the protocol,  
though it is effectively the same as changing the shared key.  An  
implementation is free to add one to the shared key every time the  
sequence number rolls over and do so without changing the spec.

> interval (detect interval - but you could call it an off scenario).

I'm not sure I follow.  Do you mean if you're using 1 second intervals  
during session bringup but then use 10 second intervals when the  
session is established?  Seems like the poll sequence thing should  
take care of it.  (Note that if you want 10 second intervals when the  
session is up, you're free to negotiate 10 second intervals while down  
as well;  the spec just says "at least [one second]" and either end  
can unilaterally push back on the interval.

--Dave

---

From: Vishwas Manral <[email-masked]>
Date: Mon, 2 Feb 2009 19:01:49 -0800

Hi Dave,

> Ah, got it.  This would be an incompatible change to the protocol, though it
> is effectively the same as changing the shared key.  An implementation is
> free to add one to the shared key every time the sequence number rolls over
> and do so without changing the spec.
No, but the hash we currently use only uses a 32-bit sequence number
so it will not work. If we want the mechanism we need to specify where
we need to keep the higher order bits when calculating the hash.

> during session bringup but then use 10 second intervals when the session is
> established?  Seems like the poll sequence thing should take care of it.
>  (Note that if you want 10 second intervals when the session is up, you're
> free to negotiate 10 second intervals while down as well;  the spec just
> says "at least [one second]" and either end can unilaterally push back on
> the interval.
>
Thats exactly how it should be done. In the sense we do not use the
new interval till we have completed the poll sequence. I found all
these issues while testing that is why informing you in case if it is
of help

Content-Class: urn:content-classes:message
Subject: Re: draft-palanivelan-bfd-v2-gr-01
Date: Tue, 3 Feb 2009 16:49:12 -0800
From: Nitin Bahadur <[email-masked]>
To: <[email-masked]>, <[email-masked]>

Hi,

  You really do not need GR extensions to BFD to help with
planned restart. There is enough text in draft-ietf-bfd-generic=20
(Section 4.3.2.2) to help you accomplish what you want.

 At the top of my head, I can think of 2 ways:

1) Restarting router brings down BFD session with diag code of
   ADMIN_DOWN. ADMIN_DOWN should not bring down the adjacency
   on the peer. So the peer BFD session will go down but ISIS/OSPF
   will not treat it as an adjacency down event.

2) Restarting router increases the BFD session timer to XXX=20
   seconds (XXX > restart time). It can save some state locally
   to note this. After restart, the restarting router reads the local
   state and continues the BFD session from the UP state.
  =20
Thanks
Nitin

Date: Tue, 3 Feb 2009 17:02:28 -0800
Subject: Re: draft-palanivelan-bfd-v2-gr-01
From: Vishwas Manral <[email-masked]>
To: Nitin Bahadur <[email-masked]>
Cc: [email-masked], [email-masked]

Hi Nitin,

I agree with you. This is something like how we have done it too.

One small part is weeding out any sessions that were not updated in
the restart time.

Thanks,
Vishwas

On Tue, Feb 3, 2009 at 4:49 PM, Nitin Bahadur <[email-masked]> wrote:
> Hi,
>
>  You really do not need GR extensions to BFD to help with
> planned restart. There is enough text in draft-ietf-bfd-generic
> (Section 4.3.2.2) to help you accomplish what you want.
>
>  At the top of my head, I can think of 2 ways:
>
> 1) Restarting router brings down BFD session with diag code of
>   ADMIN_DOWN. ADMIN_DOWN should not bring down the adjacency
>   on the peer. So the peer BFD session will go down but ISIS/OSPF
>   will not treat it as an adjacency down event.
>
> 2) Restarting router increases the BFD session timer to XXX
>   seconds (XXX > restart time). It can save some state locally
>   to note this. After restart, the restarting router reads the local
>   state and continues the BFD session from the UP state.
>
> Thanks
> Nitin
>

Date: Tue, 3 Feb 2009 17:06:31 -0800
Subject: Re: draft-palanivelan-bfd-v2-gr-01
From: Vishwas Manral <[email-masked]>
To: Nitin Bahadur <[email-masked]>
Cc: [email-masked], [email-masked]

Hi Nitin,

Also note the first case may not work when BFD is sharing fate with
the control plane and we have an unplanned restart.

Thanks,
Vishwas

On Tue, Feb 3, 2009 at 5:02 PM, Vishwas Manral <[email-masked]> wrote:
> Hi Nitin,
>
> I agree with you. This is something like how we have done it too.
>
> One small part is weeding out any sessions that were not updated in
> the restart time.
>
> Thanks,
> Vishwas
>
> On Tue, Feb 3, 2009 at 4:49 PM, Nitin Bahadur <[email-masked]> wrote:
>> Hi,
>>
>>  You really do not need GR extensions to BFD to help with
>> planned restart. There is enough text in draft-ietf-bfd-generic
>> (Section 4.3.2.2) to help you accomplish what you want.
>>
>>  At the top of my head, I can think of 2 ways:
>>
>> 1) Restarting router brings down BFD session with diag code of
>>   ADMIN_DOWN. ADMIN_DOWN should not bring down the adjacency
>>   on the peer. So the peer BFD session will go down but ISIS/OSPF
>>   will not treat it as an adjacency down event.
>>
>> 2) Restarting router increases the BFD session timer to XXX
>>   seconds (XXX > restart time). It can save some state locally
>>   to note this. After restart, the restarting router reads the local
>>   state and continues the BFD session from the UP state.
>>
>> Thanks
>> Nitin
>>
>

Date: Wed, 4 Feb 2009 11:23:18 -0800
Subject: Re: More BFD base issues
From: Vishwas Manral <[email-masked]>
To: [email-masked]

> Hi Dave,
>
> I think the detectection time interval is not correct at all. Let me
> quote a few parts of the text:
>
>   In Asynchronous mode, the Detection Time calculated in the local
>   system is equal to the value of Detect Mult received from the remote
>   system, multiplied by the agreed transmit interval of the remote
>   system (the greater of bfd.RequiredMinRxInterval and the last
>   received Desired Min TX Interval.)
>
> Also note that
>
>   With the exceptions listed in the remainder of this
>   section, a system MUST NOT transmit BFD Control packets at an
>   interval less than the larger of bfd.DesiredMinTxInterval and
> bfd.RemoteMinRxInterval.
>
> And note that we need to do a jitter of 0 to 25 % in the timer values.
> This means that the actual transmit interval has to be may be atleast
> 0 to 25% more than the larger of the Tx and RecvRx interval (let us
> call it actual receive interval ActTx).
>
> So if we have a detect Multiplier of 2, we will receive only 1 packet
> in the detect within the interval.
>
> So let us take a time line:
>
> At t1 a BFD packet is sent. The remote system receives the packet at
> t1 time (assuming 0 transit and processing time). The detection timer
> will be fired at t1 + (2 * ActTx time).
>
> The next packet will be sent at t1 + (actTx + random1) time. Assume
> this packet is lost.
>
> The next packet will be sent at t1 + (actTx + random1) + (actTx +
> random2). Only one packet will ever be ever received in the detect
> interval. So even if the detect multiplier is 2 a loss of 1 packet
> will cause the session down.
>
> I think to solve this issue as well as the specific case of detect
> mult 1. To calculate the detect interval we should use (recvd detect
> mult + 1) * ActTx and not recvd detect mult * ActTx.
>
> Here are some more comments below.
>
> 1. Shouldn't we on getting a packet with state UP, go to Init state.
>
>   "Init state means that the remote system is communicating, and the
>   local system desires to bring the session up, but the remote system
>   does not yet realize it."
>
> 2. Do we need to put some information about congestion control
> especially in the Multihop case.
>
> 3.  The draft states
>
>   One possible approach is to build an implementation such that
>   authentication is configured, but not considered "in use" until the
>   first packet containing a matching authentication section is received
>   (providing the necessary synchronization.)
>
> I do not know what it means by a matching authentication section. If
> it means enabling authentication once a packet with the A bit is set
> is got, then I think this is an easy way of DoS attacks. Send a packet
> with the A bit and the neighbors will not be able to communicate after
> that.
>
> 4. I do not see the way mentioned below as the right solution:
>
>   With the exceptions listed in the remainder of this
>   section, a system MUST NOT transmit BFD Control packets at an
>   interval less than the larger of bfd.DesiredMinTxInterval and
> bfd.RemoteMinRxInterval.
>
>   The periodic transmission of BFD Control packets SHOULD be jittered
>   by up to 25%, that is, the interval SHOULD be reduced by a random
>   value of 0 to 25%, in order to avoid self-synchronization.  Thus, the
>   average interval between packets may be up to 12.5% less than that
>   negotiated.
>
>   If bfd.DetectMult is equal to 1, the interval between transmitted BFD
>   Control packets MUST be no more than 90% of the negotiated
>   transmission interval, and MUST be no less than 75% of the negotiated
>   transmission interval.
>
> So if we have a DetectMult of 1. We have the bfd.RemoteMinRxInterval <
> bfd.DesiredMinTxInterval. The Remote system has no control of how fast
> the packets are sent. In my view in this case we should have the
> Remote system calculate the detection interval to be 25 % more than
> the actual detection interval however the Hellos are always sent at
> the right rate - never less than the minimum of the 2 intervals.
>
> 5. What is to be done to packets for which the Tx or Rx Interval is
> changed but the poll sequence is not initiated?
>
>   If bfd.RequiredMinRxInterval is reduced and bfd.SessionState is Up,
>   the previous value of bfd.RequiredMinRxInterval MUST be used when
>   calculating the Detection Time for the remote system until the Poll
>   Sequence described above has terminated.
>
> Thanks,
> Vishwas
>

From: Dave Katz <[email-masked]>
To: Vishwas Manral <[email-masked]>
Subject: Re: More BFD base issues
Date: Wed, 4 Feb 2009 12:44:03 -0700
Cc: [email-masked]

On Feb 4, 2009, at 12:23 PM, Vishwas Manral wrote:

>> Hi Dave,
>>
>> I think the detectection time interval is not correct at all. Let me
>> quote a few parts of the text:
>>
>>  In Asynchronous mode, the Detection Time calculated in the local
>>  system is equal to the value of Detect Mult received from the remote
>>  system, multiplied by the agreed transmit interval of the remote
>>  system (the greater of bfd.RequiredMinRxInterval and the last
>>  received Desired Min TX Interval.)
>>
>> Also note that
>>
>>  With the exceptions listed in the remainder of this
>>  section, a system MUST NOT transmit BFD Control packets at an
>>  interval less than the larger of bfd.DesiredMinTxInterval and
>> bfd.RemoteMinRxInterval.
>>
>> And note that we need to do a jitter of 0 to 25 % in the timer  
>> values.
>> This means that the actual transmit interval has to be may be atleast
>> 0 to 25% more than the larger of the Tx and RecvRx interval (let us
>> call it actual receive interval ActTx).

No; jitter is always *subtracted*.

    The periodic transmission of BFD Control packets SHOULD be jittered
    by up to 25%, that is, the interval SHOULD be reduced by a random
    value of 0 to 25%, in order to avoid self-synchronization.  Thus,  
the
    average interval between packets may be up to 12.5% less than that
    negotiated.

>>
>> 1. Shouldn't we on getting a packet with state UP, go to Init state.
>>
>>  "Init state means that the remote system is communicating, and the
>>  local system desires to bring the session up, but the remote system
>>  does not yet realize it."

No, we need a three-way handshake that ensures that both sides see the  
path fail:

    Once a session has been declared down, it cannot come back up until
    the remote end first signals that it is down (by leaving the Up
    state), thus implementing a three-way handshake.

>>
>>
>> 2. Do we need to put some information about congestion control
>> especially in the Multihop case.

The new draft (in internal review, to be popping out forthwith) has  
suitably vague language to the effect that the transmit interval  
manipulation is the necessary hook, and that particular algorithms do  
not impact interoperability and are therefore outside the scope of the  
spec.  Somebody can write a BCP if they like, but there's an  
opportunity for product differentiation here.

>>
>>
>> 3.  The draft states
>>
>>  One possible approach is to build an implementation such that
>>  authentication is configured, but not considered "in use" until the
>>  first packet containing a matching authentication section is  
>> received
>>  (providing the necessary synchronization.)
>>
>> I do not know what it means by a matching authentication section. If
>> it means enabling authentication once a packet with the A bit is set
>> is got, then I think this is an easy way of DoS attacks. Send a  
>> packet
>> with the A bit and the neighbors will not be able to communicate  
>> after
>> that.

The new draft has a bit more explicative language;  the idea of this  
whole thing was to provide a way for a network to transition to using  
authentication without tearing down sessions.  One would expect that  
someone would configure "I would like to do authentication when you're  
ready" at one end and then configure "I want to do configuration  
*now*" at the other end, and then authentication would be up and stay  
up.  This sensitivity to receiving an authenticated packet and turning  
it on is not meant to be the long-term state of the device, but a  
transition mechanism.  Also note that the DoS attack scenario is no  
worse than having no authentication at all.

>>
>>
>> 4. I do not see the way mentioned below as the right solution:
>>
>>  With the exceptions listed in the remainder of this
>>  section, a system MUST NOT transmit BFD Control packets at an
>>  interval less than the larger of bfd.DesiredMinTxInterval and
>> bfd.RemoteMinRxInterval.
>>
>>  The periodic transmission of BFD Control packets SHOULD be jittered
>>  by up to 25%, that is, the interval SHOULD be reduced by a random
>>  value of 0 to 25%, in order to avoid self-synchronization.  Thus,  
>> the
>>  average interval between packets may be up to 12.5% less than that
>>  negotiated.
>>
>>  If bfd.DetectMult is equal to 1, the interval between transmitted  
>> BFD
>>  Control packets MUST be no more than 90% of the negotiated
>>  transmission interval, and MUST be no less than 75% of the  
>> negotiated
>>  transmission interval.
>>
>> So if we have a DetectMult of 1. We have the  
>> bfd.RemoteMinRxInterval <
>> bfd.DesiredMinTxInterval. The Remote system has no control of how  
>> fast
>> the packets are sent.

Sure it does;  that's what bfd.RemoteMinRXInterval is for.  I don't  
see what you're saying here.

>> In my view in this case we should have the
>> Remote system calculate the detection interval to be 25 % more than
>> the actual detection interval however the Hellos are always sent at
>> the right rate - never less than the minimum of the 2 intervals.

I see no difference between this and the text as written, except that  
the packet transmission and detection are happening a little more  
slowly.  Raising the value of DesiredMinTxInterval by 25% or whatever  
would have the same effect.

>>
>>
>> 5. What is to be done to packets for which the Tx or Rx Interval is
>> changed but the poll sequence is not initiated?
>>
>>  If bfd.RequiredMinRxInterval is reduced and bfd.SessionState is Up,
>>  the previous value of bfd.RequiredMinRxInterval MUST be used when
>>  calculating the Detection Time for the remote system until the Poll
>>  Sequence described above has terminated.

It's broken, and the transmission rate will not change, and the vendor  
will be humiliated in public for having an implementation that is  
seriously out of spec.

--Dave

>> Vishwas

Date: Wed, 4 Feb 2009 12:07:19 -0800
Subject: Re: More BFD base issues
From: Vishwas Manral <[email-masked]>
To: Dave Katz <[email-masked]>
Cc: [email-masked]

Hi Dave,

Thanks for the very quick reply.

>>> I think the detectection time interval is not correct at all. Let me
>>> quote a few parts of the text:
>>>
>>>  In Asynchronous mode, the Detection Time calculated in the local
>>>  system is equal to the value of Detect Mult received from the remote
>>>  system, multiplied by the agreed transmit interval of the remote
>>>  system (the greater of bfd.RequiredMinRxInterval and the last
>>>  received Desired Min TX Interval.)
>>>
>>> Also note that
>>>
>>>  With the exceptions listed in the remainder of this
>>>  section, a system MUST NOT transmit BFD Control packets at an
>>>  interval less than the larger of bfd.DesiredMinTxInterval and
>>> bfd.RemoteMinRxInterval.
>>>
>>> And note that we need to do a jitter of 0 to 25 % in the timer values.
>>> This means that the actual transmit interval has to be may be atleast
>>> 0 to 25% more than the larger of the Tx and RecvRx interval (let us
>>> call it actual receive interval ActTx).
>
> No; jitter is always *subtracted*.

That is correct but we cannot have the Tx Interval lesser than ActTx
ever right?

The way I was seeing it was that except for the Detect Multiplier 1
case, we will never have a transmit interval less that ActTx. To not
get the synchronization we will use a jitter. Otherwise if you never
use the value of Tx and RecvRx as is the values do not hold
significance. Otherwise we should change the definitions like
(asuuming probability for randomness the definition is wrong 100% of
the time):

    bfd.RequiredMinRxInterval

         The minimum interval, in microseconds, between received BFD
         Control packets that this system requires.

The definition should be changed to if say we want 25% jitter we would state:

         133.33% of the minimum interval, in microseconds, between received BFD
         Control packets that this system requires.

Similarly if we want 20% it should be 125%. The point is if a user
configures value X for the minimum interval required they never get it
- so this should be clearly mentioned.

>   The periodic transmission of BFD Control packets SHOULD be jittered
>   by up to 25%, that is, the interval SHOULD be reduced by a random
>   value of 0 to 25%, in order to avoid self-synchronization.  Thus, the
>   average interval between packets may be up to 12.5% less than that
>   negotiated.
>
>>>
>>> 1. Shouldn't we on getting a packet with state UP, go to Init state.
>>>
>>>  "Init state means that the remote system is communicating, and the
>>>  local system desires to bring the session up, but the remote system
>>>  does not yet realize it."
>
> No, we need a three-way handshake that ensures that both sides see the path
> fail:
Yes, I agree, but if I see a packet from the neighbor why should I not
go in Init state. Please see the definition of Init state I have
attached above, otehrwise we should trigger this packet as a error
packet in the flow.

>   Once a session has been declared down, it cannot come back up until
>   the remote end first signals that it is down (by leaving the Up
>   state), thus implementing a three-way handshake.
>
>>>
>>>
>>> 2. Do we need to put some information about congestion control
>>> especially in the Multihop case.
>
> The new draft (in internal review, to be popping out forthwith) has suitably
> vague language to the effect that the transmit interval manipulation is the
> necessary hook, and that particular algorithms do not impact
> interoperability and are therefore outside the scope of the spec.  Somebody
> can write a BCP if they like, but there's an opportunity for product
> differentiation here.
Great thanks.

>>>
>>> 3.  The draft states
>>>
>>>  One possible approach is to build an implementation such that
>>>  authentication is configured, but not considered "in use" until the
>>>  first packet containing a matching authentication section is received
>>>  (providing the necessary synchronization.)
>>>
>>> I do not know what it means by a matching authentication section. If
>>> it means enabling authentication once a packet with the A bit is set
>>> is got, then I think this is an easy way of DoS attacks. Send a packet
>>> with the A bit and the neighbors will not be able to communicate after
>>> that.
>
> The new draft has a bit more explicative language;  the idea of this whole
> thing was to provide a way for a network to transition to using
> authentication without tearing down sessions.  One would expect that someone
> would configure "I would like to do authentication when you're ready" at one
> end and then configure "I want to do configuration *now*" at the other end,
> and then authentication would be up and stay up.  This sensitivity to
> receiving an authenticated packet and turning it on is not meant to be the
> long-term state of the device, but a transition mechanism.  Also note that
> the DoS attack scenario is no worse than having no authentication at all.
Thanks,

>>>
>>>
>>> 4. I do not see the way mentioned below as the right solution:
>>>
>>>  With the exceptions listed in the remainder of this
>>>  section, a system MUST NOT transmit BFD Control packets at an
>>>  interval less than the larger of bfd.DesiredMinTxInterval and
>>> bfd.RemoteMinRxInterval.
>>>
>>>  The periodic transmission of BFD Control packets SHOULD be jittered
>>>  by up to 25%, that is, the interval SHOULD be reduced by a random
>>>  value of 0 to 25%, in order to avoid self-synchronization.  Thus, the
>>>  average interval between packets may be up to 12.5% less than that
>>>  negotiated.
>>>
>>>  If bfd.DetectMult is equal to 1, the interval between transmitted BFD
>>>  Control packets MUST be no more than 90% of the negotiated
>>>  transmission interval, and MUST be no less than 75% of the negotiated
>>>  transmission interval.
>>>
>>> So if we have a DetectMult of 1. We have the bfd.RemoteMinRxInterval <
>>> bfd.DesiredMinTxInterval. The Remote system has no control of how fast
>>> the packets are sent.
>
> Sure it does;  that's what bfd.RemoteMinRXInterval is for.  I don't see what
> you're saying here.
It is related to the first point I am raising.

>>> In my view in this case we should have the
>>> Remote system calculate the detection interval to be 25 % more than
>>> the actual detection interval however the Hellos are always sent at
>>> the right rate - never less than the minimum of the 2 intervals.
>
> I see no difference between this and the text as written, except that the
> packet transmission and detection are happening a little more slowly.
>  Raising the value of DesiredMinTxInterval by 25% or whatever would have the
> same effect.
>
>>>
>>>
>>> 5. What is to be done to packets for which the Tx or Rx Interval is
>>> changed but the poll sequence is not initiated?
>>>
>>>  If bfd.RequiredMinRxInterval is reduced and bfd.SessionState is Up,
>>>  the previous value of bfd.RequiredMinRxInterval MUST be used when
>>>  calculating the Detection Time for the remote system until the Poll
>>>  Sequence described above has terminated.
>
> It's broken, and the transmission rate will not change, and the vendor will
> be humiliated in public for having an implementation that is seriously out
> of spec.
Humiliation is another thing!!!

What I am eager to know is should I just see the poll bit to realize
something may have changed in the Tx and ReqRx or not. I think we need
to make this more explicit. The spec needs to be clear about such
things.

In my view the poll/ final bit are used to see if the neighbor has got
a particular message I sent across. There could be cases where I do
not care f the neighbor knows immediately (I do not need to verify a
handshake).

Like I said the spec should be explicit and not assume things. I would
also want the explicit note of when the Final bit is unset too. I
think for a good spec it is better to clearly specify than to assume
the other person understands what we are thinking.

Thanks,
Vishwas

Date: Wed, 4 Feb 2009 12:35:57 -0800
Subject: Re: More BFD base issues
From: Vishwas Manral <[email-masked]>
To: Dave Katz <[email-masked]>
Cc: [email-masked]

Hi Dave,

>From the Section on timer negotiation. If you note that if I make my
timer 133.3% of the ActTx interval and then use a 25% less jitter (so
ActTx to 1.33 ActTx), I get the exact behavior as below and do not
violate the below or any definition in Section 6.2.

However you will note with the scheme you state we violate the statement

   With the exceptions listed in the remainder of this
   section, a system MUST NOT transmit BFD Control packets at an
   interval less than the larger of bfd.DesiredMinTxInterval and
   bfd.RemoteMinRxInterval.

It is never transmitted as above (without exception). It becomes a
MUST instead of a MUST NOT.

>>> 3.  The draft states
>>>
>>>  One possible approach is to build an implementation such that
>>>  authentication is configured, but not considered "in use" until the
>>>  first packet containing a matching authentication section is received
>>>  (providing the necessary synchronization.)
>>>
>>> I do not know what it means by a matching authentication section. If
>>> it means enabling authentication once a packet with the A bit is set
>>> is got, then I think this is an easy way of DoS attacks. Send a packet
>>> with the A bit and the neighbors will not be able to communicate after
>>> that.
>
> The new draft has a bit more explicative language;  the idea of this whole
> thing was to provide a way for a network to transition to using
> authentication without tearing down sessions.  One would expect that someone
> would configure "I would like to do authentication when you're ready" at one
> end and then configure "I want to do configuration *now*" at the other end,
> and then authentication would be up and stay up.  This sensitivity to
> receiving an authenticated packet and turning it on is not meant to be the
> long-term state of the device, but a transition mechanism.  Also note that
> the DoS attack scenario is no worse than having no authentication at all.
A better way would be, I am ok with authenticating packets and
non-auth packets, but will send out non-auth packets. When I configure
the same on all the neighbors, I then go and configure send and
receive and the authentication is enabled. I think Cisco uses the same
mechanism to change from one Key to another in other protocols.

Thanks,
Vishwas

Date: Wed, 4 Feb 2009 12:45:38 -0800
Subject: Re: More BFD base issues
From: Vishwas Manral <[email-masked]>
To: Dave Katz <[email-masked]>
Cc: [email-masked]

Hi Dave,

The packet reception algorithm does not seem to be consistent with the
Poll thing we noted earlier.

Also note:

      If the Required Min Echo RX Interval field is zero, the
      transmission of Echo packets, if any, MUST cease.

we have missed the case of in the Interval goes from zero to non-zero,
though we have mentioned the behavior of non-zero to zero.

Thanks,
Vishwas

On Wed, Feb 4, 2009 at 12:35 PM, Vishwas Manral <[email-masked]> wrote:
> Hi Dave,
>
> From the Section on timer negotiation. If you note that if I make my
> timer 133.3% of the ActTx interval and then use a 25% less jitter (so
> ActTx to 1.33 ActTx), I get the exact behavior as below and do not
> violate the below or any definition in Section 6.2.
>
> However you will note with the scheme you state we violate the statement
>
>   With the exceptions listed in the remainder of this
>   section, a system MUST NOT transmit BFD Control packets at an
>   interval less than the larger of bfd.DesiredMinTxInterval and
>   bfd.RemoteMinRxInterval.
>
> It is never transmitted as above (without exception). It becomes a
> MUST instead of a MUST NOT.
>
>>>> 3.  The draft states
>>>>
>>>>  One possible approach is to build an implementation such that
>>>>  authentication is configured, but not considered "in use" until the
>>>>  first packet containing a matching authentication section is received
>>>>  (providing the necessary synchronization.)
>>>>
>>>> I do not know what it means by a matching authentication section. If
>>>> it means enabling authentication once a packet with the A bit is set
>>>> is got, then I think this is an easy way of DoS attacks. Send a packet
>>>> with the A bit and the neighbors will not be able to communicate after
>>>> that.
>>
>> The new draft has a bit more explicative language;  the idea of this whole
>> thing was to provide a way for a network to transition to using
>> authentication without tearing down sessions.  One would expect that someone
>> would configure "I would like to do authentication when you're ready" at one
>> end and then configure "I want to do configuration *now*" at the other end,
>> and then authentication would be up and stay up.  This sensitivity to
>> receiving an authenticated packet and turning it on is not meant to be the
>> long-term state of the device, but a transition mechanism.  Also note that
>> the DoS attack scenario is no worse than having no authentication at all.
> A better way would be, I am ok with authenticating packets and
> non-auth packets, but will send out non-auth packets. When I configure
> the same on all the neighbors, I then go and configure send and
> receive and the authentication is enabled. I think Cisco uses the same
> mechanism to change from one Key to another in other protocols.
>
> Thanks,
> Vishwas
>

From: Dave Katz <[email-masked]>
To: Vishwas Manral <[email-masked]>
Subject: Re: More BFD base issues
Date: Wed, 4 Feb 2009 14:03:39 -0700
Cc: [email-masked]

On Feb 4, 2009, at 1:07 PM, Vishwas Manral wrote:

>> The definition should be changed to if say we want 25% jitter we  
>> would state:
>
>         133.33% of the minimum interval, in microseconds, between  
> received BFD
>         Control packets that this system requires.
>
> Similarly if we want 20% it should be 125%. The point is if a user
> configures value X for the minimum interval required they never get it
> - so this should be clearly mentioned.

Well, it is explicitly mentioned when talking about jitter, as I  
quoted before:

>
>
>>  The periodic transmission of BFD Control packets SHOULD be jittered
>>  by up to 25%, that is, the interval SHOULD be reduced by a random
>>  value of 0 to 25%, in order to avoid self-synchronization.  Thus,  
>> the
>>  average interval between packets may be up to 12.5% less than that
>>  negotiated.

I can add a brief note to the definition if that would make it clearer.

>>
>>
>>>>
>>>> 1. Shouldn't we on getting a packet with state UP, go to Init  
>>>> state.
>>>>
>>>> "Init state means that the remote system is communicating, and the
>>>> local system desires to bring the session up, but the remote system
>>>> does not yet realize it."
>>
>> No, we need a three-way handshake that ensures that both sides see  
>> the path
>> fail:
> Yes, I agree, but if I see a packet from the neighbor why should I not
> go in Init state. Please see the definition of Init state I have
> attached above, otehrwise we should trigger this packet as a error
> packet in the flow.

The "definition" you quote is an attempt to describe, in a somewhat  
accessible way, the semantic meaning of the state.  The full state  
machine is very clearly documented, both with a diagram and with  
normative prose.

The receipt of Up while in Down state is not an error, it just means  
that the other end hasn't seen your end go down, or that packet got  
lost on the way.  If that packet saying you were Down was lost in  
transit, transitioning to Init state would mean that the other end  
would never signal a session failure.  And before you mention that it  
could key on your sending Init in your packet, *that* packet could be  
lost as well in which case the far end would have no idea that you  
were ever down, and the three-way handshake would fail.

Designing state machines like this is a subtle art (as evidenced by  
the fact that my first try at the state machine was broken, which is  
why we had to bump the version number awhile back.)  This one is  
tested and solid and widely implemented.  Let's move on.

>>>>
>>>> So if we have a DetectMult of 1. We have the  
>>>> bfd.RemoteMinRxInterval <
>>>> bfd.DesiredMinTxInterval. The Remote system has no control of how  
>>>> fast
>>>> the packets are sent.
>>
>> Sure it does;  that's what bfd.RemoteMinRXInterval is for.  I don't  
>> see what
>> you're saying here.
> It is related to the first point I am raising.

I'll add "except for jitter" to the places that talk about the minimum  
time values, and hopefully that will settle all this.

>
> What I am eager to know is should I just see the poll bit to realize
> something may have changed in the Tx and ReqRx or not. I think we need
> to make this more explicit. The spec needs to be clear about such
> things.

The spec is abundantly clear about what to do when you receive  
packets, regardless of whether Poll is set or not.  You update the  
timers--it's normative and explicitly spelled out.  Poll is not a  
mechanism to signal the receiver that it should further examine the  
packet (nor do I know of any text that implies this.)  Rather, Poll is  
a mechanism to ensure that the far end has heard your recent packet  
(acknowledged by setting Final.)

>
> In my view the poll/ final bit are used to see if the neighbor has got
> a particular message I sent across. There could be cases where I do
> not care f the neighbor knows immediately (I do not need to verify a
> handshake).
>
> Like I said the spec should be explicit and not assume things. I would
> also want the explicit note of when the Final bit is unset too. I
> think for a good spec it is better to clearly specify than to assume
> the other person understands what we are thinking.

I thought the spec was clear, but I can add "the Final bit MUST be  
clear otherwise" at the end of the text in section 6.8.7 if that will  
make it clearer.  I'm not sure what other assumptions you are  
referring to.

--Dave

From: Dave Katz <[email-masked]>
To: Vishwas Manral <[email-masked]>
Subject: Re: More BFD base issues
Date: Wed, 4 Feb 2009 14:11:22 -0700
Cc: [email-masked]

On Feb 4, 2009, at 1:35 PM, Vishwas Manral wrote:

> Hi Dave,
>
>> From the Section on timer negotiation. If you note that if I make my
> timer 133.3% of the ActTx interval and then use a 25% less jitter (so
> ActTx to 1.33 ActTx), I get the exact behavior as below and do not
> violate the below or any definition in Section 6.2.
>
> However you will note with the scheme you state we violate the  
> statement
>
>   With the exceptions listed in the remainder of this
>   section, a system MUST NOT transmit BFD Control packets at an
>   interval less than the larger of bfd.DesiredMinTxInterval and
>   bfd.RemoteMinRxInterval.
>
> It is never transmitted as above (without exception). It becomes a
> MUST instead of a MUST NOT.

This will be settled with the jitter text I mentioned in the last  
message.

>
>
>>>> 3.  The draft states
>>>>
>>>> One possible approach is to build an implementation such that
>>>> authentication is configured, but not considered "in use" until the
>>>> first packet containing a matching authentication section is  
>>>> received
>>>> (providing the necessary synchronization.)
>>>>
>>>> I do not know what it means by a matching authentication section.  
>>>> If
>>>> it means enabling authentication once a packet with the A bit is  
>>>> set
>>>> is got, then I think this is an easy way of DoS attacks. Send a  
>>>> packet
>>>> with the A bit and the neighbors will not be able to communicate  
>>>> after
>>>> that.
>>
>> The new draft has a bit more explicative language;  the idea of  
>> this whole
>> thing was to provide a way for a network to transition to using
>> authentication without tearing down sessions.  One would expect  
>> that someone
>> would configure "I would like to do authentication when you're  
>> ready" at one
>> end and then configure "I want to do configuration *now*" at the  
>> other end,
>> and then authentication would be up and stay up.  This sensitivity to
>> receiving an authenticated packet and turning it on is not meant to  
>> be the
>> long-term state of the device, but a transition mechanism.  Also  
>> note that
>> the DoS attack scenario is no worse than having no authentication  
>> at all.
> A better way would be, I am ok with authenticating packets and
> non-auth packets, but will send out non-auth packets. When I configure
> the same on all the neighbors, I then go and configure send and
> receive and the authentication is enabled. I think Cisco uses the same
> mechanism to change from one Key to another in other protocols.

That is also a workable mechanism, though it has the downside that you  
have to configure one machine twice.  But in any case, the existing  
text says "One possible approach" and does not preclude others.   
Implementors are free to do what they want.

In defining BFD we went out of our way to be careful about what to  
make normative and what to leave up to implementors.  We explicitly  
did *not* want to write an implementation guide (e.g. OSPF), both  
because it confuses normative requirements with particular  
implementation choices, and because we wanted to leave enough wiggle  
room to allow product differentiation for everyone insofar as it does  
not affect interoperability (we are trying to make a living here,  
after all.)

Anyone is free to publish BCPs or Informational drafts to share  
implementation ideas, but the authors of the spec have chosen not to.

--Dave

From: Dave Katz <[email-masked]>
To: Vishwas Manral <[email-masked]>
Subject: Re: More BFD base issues
Date: Wed, 4 Feb 2009 14:20:47 -0700
Cc: [email-masked]

On Feb 4, 2009, at 1:45 PM, Vishwas Manral wrote:

> Hi Dave,
>
> The packet reception algorithm does not seem to be consistent with the
> Poll thing we noted earlier.
>
> Also note:
>
>      If the Required Min Echo RX Interval field is zero, the
>      transmission of Echo packets, if any, MUST cease.
>
> we have missed the case of in the Interval goes from zero to non-zero,
> though we have mentioned the behavior of non-zero to zero.

This is because the ceasing of Echo transmission is normative, but  
starting transmission is non-normative.  The bit you quote here is  
normative and procedural, and is saying what must be done upon receipt  
of a zero.  Nothing in particular must be done when receiving nonzero.

There is also the following bit of text:

6.8.9. Transmission of BFD Echo Packets

    BFD Echo packets MUST NOT be transmitted when bfd.SessionState is  
not
    Up.  BFD Echo packets MUST NOT be transmitted unless the last BFD
    Control packet received from the remote system contains a nonzero
    value in Required Min Echo RX Interval.

    BFD Echo packets MAY be transmitted when bfd.SessionState is Up.   
The
    interval between transmitted BFD Echo packets MUST NOT be less than
    the value advertised by the remote system in Required Min Echo RX
    Interval, except as follows:

       A 25% jitter MAY be applied to the rate of transmission, such  
that
       the actual interval MAY be between 75% and 100% of the advertised
       value.  A single BFD Echo packet MAY be transmitted between
       normally scheduled Echo transmission intervals.

    The transmission of BFD Echo packets is otherwise outside the scope
    of this specification.

See previous discussion about keeping normative text tight.  There is  
a general problem of trying to list all of the things that MAY be done  
at any particular time, which is essentially infinite.  Trying to be  
more explicit in cases like this will bloat the spec even further than  
it already is (for a protocol that purports to be "simple" the spec is  
getting pretty beefy.)  The authors feel that the existing text is  
sufficient for implementors versed in the art to build correct and  
interoperable implementations.

--Dave

From: Dave Katz <[email-masked]>
To: Vishwas Manral <[email-masked]>
Subject: Re: More BFD base issues
Date: Wed, 4 Feb 2009 14:30:29 -0700
Cc: [email-masked]

On Feb 4, 2009, at 1:35 PM, Vishwas Manral wrote:

> Hi Dave,
>
>> From the Section on timer negotiation. If you note that if I make my
> timer 133.3% of the ActTx interval and then use a 25% less jitter (so
> ActTx to 1.33 ActTx), I get the exact behavior as below and do not
> violate the below or any definition in Section 6.2.
>
> However you will note with the scheme you state we violate the  
> statement
>
>   With the exceptions listed in the remainder of this
>   section, a system MUST NOT transmit BFD Control packets at an
>   interval less than the larger of bfd.DesiredMinTxInterval and
>   bfd.RemoteMinRxInterval.
>
> It is never transmitted as above (without exception). It becomes a
> MUST instead of a MUST NOT.

Actually, this one is already fine in the spec.  The paragraph  
immediately following the one you quote contains one of the  
exceptions, which is the application of jitter.

--Dave

Date: Wed, 4 Feb 2009 13:58:44 -0800
Subject: Re: More BFD base issues
From: Vishwas Manral <[email-masked]>
To: Dave Katz <[email-masked]>
Cc: [email-masked]

Hi Dave,

Thanks for your replies. I am good with most of the agreements.

>>  With the exceptions listed in the remainder of this
>>  section, a system MUST NOT transmit BFD Control packets at an
>>  interval less than the larger of bfd.DesiredMinTxInterval and
>>  bfd.RemoteMinRxInterval.
>>
>> It is never transmitted as above (without exception). It becomes a
>> MUST instead of a MUST NOT.
>
> Actually, this one is already fine in the spec.  The paragraph immediately
> following the one you quote contains one of the exceptions, which is the
> application of jitter.
But jitter is not the exception it is the rule for every packet (its
like saying do x for every packet except for all packets). I think it
is confusing to say it mildly.

> we have missed the case of in the Interval goes from zero to non-zero,
> though we have mentioned the behavior of non-zero to zero.

>  This is because the ceasing of Echo transmission is normative, but
> starting transmission is non-normative.  The bit you quote here is
> normative and procedural, and is saying what must be done upon
> receipt of a zero.  Nothing in particular must be done when receiving
> nonzero.

May be for the non-zero case we should mention that based on
conditions in section 6.8.9 the echo function may be started. From the
code perspective that is exactly what would be done.

The next 2 lines state the below and I think we can be consistent.

      Update the transmit interval as described in section 6.8.2.

      Update the Detection Time as described in section 6.8.4.

> Anyone is free to publish BCPs or Informational drafts to share
> implementation ideas, but the authors of the spec have chosen not to
I would be ok with the specification if it did not introduce new holes
into the specification. Particular implementations can be changed.

> The spec is abundantly clear about what to do when you receive packets,
> regardless of whether Poll is set or not.  You update the timers--it's normative
> and explicitly spelled out.  Poll is not a mechanism to signal the receiver that
> it should further examine the packet (nor do I know of any text that implies
> this.)  Rather, Poll is a mechanism to ensure that the far end has heard your
> recent packet (acknowledged by setting Final.)
That is exactly what I said too. So when we state

   If either bfd.DesiredMinTxInterval is changed or
   bfd.RequiredMinRxInterval is changed, a Poll Sequence MUST be
   initiated (see section 6.5).

My question was do we need to verify the same at the receiving end or
not? If not it would be good to state it.

Thanks,
Vishwas

From: Dave Katz <[email-masked]>
To: Vishwas Manral <[email-masked]>
Subject: Re: More BFD base issues
Date: Wed, 4 Feb 2009 15:19:57 -0700
Cc: [email-masked]

On Feb 4, 2009, at 2:58 PM, Vishwas Manral wrote:

> Hi Dave,
>
> Thanks for your replies. I am good with most of the agreements.
>
>>> With the exceptions listed in the remainder of this
>>> section, a system MUST NOT transmit BFD Control packets at an
>>> interval less than the larger of bfd.DesiredMinTxInterval and
>>> bfd.RemoteMinRxInterval.
>>>
>>> It is never transmitted as above (without exception). It becomes a
>>> MUST instead of a MUST NOT.
>>
>> Actually, this one is already fine in the spec.  The paragraph  
>> immediately
>> following the one you quote contains one of the exceptions, which  
>> is the
>> application of jitter.
> But jitter is not the exception it is the rule for every packet (its
> like saying do x for every packet except for all packets). I think it
> is confusing to say it mildly.

It is a SHOULD, so it is indeed an exception.

>
>
>> we have missed the case of in the Interval goes from zero to non- 
>> zero,
>> though we have mentioned the behavior of non-zero to zero.
>
>> This is because the ceasing of Echo transmission is normative, but
>> starting transmission is non-normative.  The bit you quote here is
>> normative and procedural, and is saying what must be done upon
>> receipt of a zero.  Nothing in particular must be done when receiving
>> nonzero.
>
> May be for the non-zero case we should mention that based on
> conditions in section 6.8.9 the echo function may be started. From the
> code perspective that is exactly what would be done.
>
> The next 2 lines state the below and I think we can be consistent.
>
>      Update the transmit interval as described in section 6.8.2.
>
>      Update the Detection Time as described in section 6.8.4.
>
>> Anyone is free to publish BCPs or Informational drafts to share
>> implementation ideas, but the authors of the spec have chosen not to
> I would be ok with the specification if it did not introduce new holes
> into the specification. Particular implementations can be changed.

The authors feel that this is not a "hole" and in fact this text has  
existed for a number of years now without any complaint or apparent  
difficulty in interpretation.

>
>
>   If either bfd.DesiredMinTxInterval is changed or
>   bfd.RequiredMinRxInterval is changed, a Poll Sequence MUST be
>   initiated (see section 6.5).
>
> My question was do we need to verify the same at the receiving end or
> not? If not it would be good to state it.

As the spec notes,

    This section discusses the normative requirements of the protocol in
    order to achieve interoperability.  It is important for implementors
    to enforce only the requirements specified in this section, as
    misguided pedantry has been proven by experience to adversely affect
    interoperability.

In other words, don't make checks that the spec doesn't say to make.   
I think that is sufficient.

The receiving system is not a conformance tester.

--Dave

Date: Wed, 4 Feb 2009 14:51:40 -0800
Subject: Re: More BFD base issues
From: Vishwas Manral <[email-masked]>
To: Dave Katz <[email-masked]>
Cc: [email-masked]

Hi Dave,

Please do whatever you feel, however in my view the first case is a
gaping hole. Just to clarify it is equivalent to saying "MUST do X for
all packets, and SHOULD NOT do X for all packets". You seem to state
SHOULD is an "exception" so the statement is correct.

One more case, I come across is what if the Poll is inititiated by the
two ends symultaneously. I know you can all these exceptional
conditions, but we finally had to write similar stuff in BGP when
parallel connections are initiated symultaneously. The Poll isnt
cleared till the final bit is got. So do we set the Poll and the Final
bit togather (which is not allowed by the spec). Please clarify?

>> But jitter is not the exception it is the rule for every packet (its
>> like saying do x for every packet except for all packets). I think it
>> is confusing to say it mildly.
>
> It is a SHOULD, so it is indeed an exception.
You seem to be stating that for an implementation doing a SHOULD is an
exception (is there an IETF document which has chnaged the definition
of should to the way you mention). Is that how we intended it to be?
It does not match the language in the IETF. If that is true I guess we
have no point of contention (though it does amuse me).

> The authors feel that this is not a "hole" and in fact this text has existed
> for a number of years now without any complaint or apparent difficulty in
> interpretation.
I agree it may not qualify as a gaping hole necessarily. It helps to
however fill in all not so big holes if they can be improved by adding
a few lines in the text (and anyway adds no ned functionality as it is
'obvious').

>>  If either bfd.DesiredMinTxInterval is changed or
>>  bfd.RequiredMinRxInterval is changed, a Poll Sequence MUST be
>>  initiated (see section 6.5).
>>
>> My question was do we need to verify the same at the receiving end or
>> not? If not it would be good to state it.
>
> As the spec notes,
>
>   This section discusses the normative requirements of the protocol in
>   order to achieve interoperability.  It is important for implementors
>   to enforce only the requirements specified in this section, as
>   misguided pedantry has been proven by experience to adversely affect
>   interoperability.
>
> In other words, don't make checks that the spec doesn't say to make.  I
> think that is sufficient.
>
> The receiving system is not a conformance tester.
Ok. In my view if we specify the behavior in unknown cases we may
avoid unnecessary issues. You seem to state let us leave it for the
intelligent implementor. I however feel we have to understand that not
everyone has the same intelligence as the senior architects in
Juniper.

Thanks,
Vishwas

Date: Thu, 5 Feb 2009 10:13:13 -0800
Subject: Re: More BFD base issues
From: Vishwas Manral <[email-masked]>
To: Dave Katz <[email-masked]>
Cc: [email-masked]

Hi Dave,

I thought over this issue.

> One more case, I come across is what if the Poll is inititiated by the
> two ends symultaneously. I know you can all these exceptional
> conditions, but we finally had to write similar stuff in BGP when
> parallel connections are initiated symultaneously. The Poll isnt
> cleared till the final bit is got. So do we set the Poll and the Final
> bit togather (which is not allowed by the spec). Please clarify?
I think the best way would be to allow FINAL and POLL bit in the same
packet. Is there a reason to explicitly disallow it?

Thanks,
Vishwas

From: Dave Katz <[email-masked]>
To: Vishwas Manral <[email-masked]>
Subject: Re: More BFD base issues
Date: Thu, 5 Feb 2009 11:35:43 -0700
Cc: [email-masked]

On Feb 5, 2009, at 11:13 AM, Vishwas Manral wrote:

> Hi Dave,
>
> I thought over this issue.
>
>> One more case, I come across is what if the Poll is inititiated by  
>> the
>> two ends symultaneously. I know you can all these exceptional
>> conditions, but we finally had to write similar stuff in BGP when
>> parallel connections are initiated symultaneously. The Poll isnt
>> cleared till the final bit is got. So do we set the Poll and the  
>> Final
>> bit togather (which is not allowed by the spec). Please clarify?
> I think the best way would be to allow FINAL and POLL bit in the same
> packet. Is there a reason to explicitly disallow it?

Yes, it's to avoid the possibility of packet floods.  Since packets  
with Final can be sent without regard to rate control, it would open  
up a possibility of wire-rate packets being exchanged in both  
directions if packets with Poll could be sent the same way.  It would  
require a broken implementation for it to happen, but one of the  
overriding design criteria in BFD was to avoid catastrophic meltdown  
due to excessive packet transmission.  It was felt that this  
requirement would provide some protection at little or no cost on the  
wire (potentially one extra packet if both sides feel the need to poll  
simultaneously) and a negligible increase in implementation complexity.

The authors have watched networks melt into silicon sludge too many  
times over the years because of runaway control traffic (AOL down for  
19 hours;  ATT SS7 down for hours;  MCI frame relay down for 10 days  
along with the Chicago Board of Trade) and we wanted to make double- 
sure that we weren't creating yet another way of taking down the  
infrastructure.  There is ample empirical data showing that most  
control protocol implementations do not behave well when they get  
overloaded.

In any case, the scenario you describe is trivially dealt with if you  
consider packets with Final to be "extra" (not subject to scheduling)  
since they are supposed to be sent "as soon as practicable", and by  
definition any packet with Poll is done on a regular periodic basis.   
Slightly different code paths for the two cases and you're done.

--Dave

> Vishwas

Date: Thu, 5 Feb 2009 11:26:02 -0800
Subject: Re: More BFD base issues
From: Vishwas Manral <[email-masked]>
To: Dave Katz <[email-masked]>
Cc: [email-masked]

Hi Dave,

You miss the basic point of networking!!! Two machines operate
independently and that is the reason they can both initiate poll at
the same time. There is no broken implementation required for this.
Try put a time buffer in you receive queue (this is to like simulating
overload - not a change of behavior) and change the parameters in both
the ends of the session. Your implementation will show you the same
behavior.

> Yes, it's to avoid the possibility of packet floods.  Since packets with
> Final can be sent without regard to rate control, it would open up a
> possibility of wire-rate packets being exchanged in both directions if
> packets with Poll could be sent the same way.  It would require a broken
> implementation for it to happen, but one of the overriding design criteria
> in BFD was to avoid catastrophic meltdown due to excessive packet
> transmission.
We have two different machines. They can initiate the poll at the same
time. There is no broken implementation at all. Poll can be initiated
at both ends symultaneously. Please explain what you mean by a broken
implementation? I have given you basic examples of how the same
problem has manifested in BGP.

You seem to be adding a lot of complexity into the spec for protecting
a case of some timer value which can change (which will rearly
happen). You are now stating that Poll bit is not sticky for certain
packets.

The problem is you are not seeing the difference between where the
spec needs to specify things and where the spec can let the
implementor do things themselves.

Thanks,
Vishwas

On Thu, Feb 5, 2009 at 10:35 AM, Dave Katz <[email-masked]> wrote:
>
> On Feb 5, 2009, at 11:13 AM, Vishwas Manral wrote:
>
>> Hi Dave,
>>
>> I thought over this issue.
>>
>>> One more case, I come across is what if the Poll is inititiated by the
>>> two ends symultaneously. I know you can all these exceptional
>>> conditions, but we finally had to write similar stuff in BGP when
>>> parallel connections are initiated symultaneously. The Poll isnt
>>> cleared till the final bit is got. So do we set the Poll and the Final
>>> bit togather (which is not allowed by the spec). Please clarify?
>>
>> I think the best way would be to allow FINAL and POLL bit in the same
>> packet. Is there a reason to explicitly disallow it?
>
> Yes, it's to avoid the possibility of packet floods.  Since packets with
> Final can be sent without regard to rate control, it would open up a
> possibility of wire-rate packets being exchanged in both directions if
> packets with Poll could be sent the same way.  It would require a broken
> implementation for it to happen, but one of the overriding design criteria
> in BFD was to avoid catastrophic meltdown due to excessive packet
> transmission.  It was felt that this requirement would provide some
> protection at little or no cost on the wire (potentially one extra packet if
> both sides feel the need to poll simultaneously) and a negligible increase
> in implementation complexity.
>
> The authors have watched networks melt into silicon sludge too many times
> over the years because of runaway control traffic (AOL down for 19 hours;
>  ATT SS7 down for hours;  MCI frame relay down for 10 days along with the
> Chicago Board of Trade) and we wanted to make double-sure that we weren't
> creating yet another way of taking down the infrastructure.  There is ample
> empirical data showing that most control protocol implementations do not
> behave well when they get overloaded.
>
> In any case, the scenario you describe is trivially dealt with if you
> consider packets with Final to be "extra" (not subject to scheduling) since
> they are supposed to be sent "as soon as practicable", and by definition any
> packet with Poll is done on a regular periodic basis.  Slightly different
> code paths for the two cases and you're done.
>
> --Dave
>
>>
>>
>> Thanks,
>> Vishwas
>>
>
>

From: Dave Katz <[email-masked]>
To: Vishwas Manral <[email-masked]>
Subject: Re: More BFD base issues
Date: Thu, 5 Feb 2009 13:55:16 -0700
Cc: [email-masked]

On Feb 5, 2009, at 12:26 PM, Vishwas Manral wrote:

> Hi Dave,
>
> You miss the basic point of networking!!! Two machines operate
> independently and that is the reason they can both initiate poll at
> the same time. There is no broken implementation required for this.
> Try put a time buffer in you receive queue (this is to like simulating
> overload - not a change of behavior) and change the parameters in both
> the ends of the session. Your implementation will show you the same
> behavior.

And you're missing the point of what I'm saying.  There is nothing  
broken in having both sides wanting to Poll at the same time (and it  
in fact is quite likely to happen when a session first comes up, as  
both sides will likely be negotiating new transmit times.)  This works  
just fine with the spec as defined.

>
>
>> Yes, it's to avoid the possibility of packet floods.  Since packets  
>> with
>> Final can be sent without regard to rate control, it would open up a
>> possibility of wire-rate packets being exchanged in both directions  
>> if
>> packets with Poll could be sent the same way.  It would require a  
>> broken
>> implementation for it to happen, but one of the overriding design  
>> criteria
>> in BFD was to avoid catastrophic meltdown due to excessive packet
>> transmission.
> We have two different machines. They can initiate the poll at the same
> time. There is no broken implementation at all. Poll can be initiated
> at both ends symultaneously. Please explain what you mean by a broken
> implementation? I have given you basic examples of how the same
> problem has manifested in BGP.

The scenario we're trying to avoid is one in which two machines  
rapidly exchange packets with both P and F set.  The receipt of P  
requires an immediate response with F, but if P happens to be set in  
that rapid response, the first machine will rapidly respond with F.   
The brokenness would happen if one machine kept sending P with its F;   
in that case the packets would ricochet forever at wire speed.

The simple expedient of not allowing P and F together provides some  
leverage against this brokenness, at a cost of an extra packet.  Yes,  
we can't avoid all broken software (since by definition it could  
ignore this rule as well), but the rule provides some cheap insurance  
at very low cost.

>
>
> You seem to be adding a lot of complexity into the spec for protecting
> a case of some timer value which can change (which will rearly
> happen). You are now stating that Poll bit is not sticky for certain
> packets.

As we have discussed before, packet contents are *not* state  
variables.  This is clearly defined in the spec.  There is no such  
thing as a "sticky" value in a packet--packets are ephemeral.  How  
this is handled in an implementation is not the concern of the spec.

Further, this is not "a lot" of complexity.  I explained how one could  
code it in one sentence.  In our implementation it requires a handful  
of lines of code to pull off.

>
>
> The problem is you are not seeing the difference between where the
> spec needs to specify things and where the spec can let the
> implementor do things themselves.

Well, as the first implementor of BFD (and an active developer in our  
products) I do have a solid footing on what's spec and what's  
implementation.  I explained at length why the spec reads the way it  
does.  I see no use in belaboring this point.

--Dave

Date: Thu, 5 Feb 2009 13:45:36 -0800
Subject: Re: More BFD base issues
From: Vishwas Manral <[email-masked]>
To: Dave Katz <[email-masked]>
Cc: [email-masked]

Hi Dave,

Atleast we now agree its not a broken implementation when the two ends
send the Poll symultaneously.

I have sent a simple suggestion to you in private a while back - will
wait for your reply. Another solution to prevent one extra packet
would be to just restart the Hello timer (which I think sound a lot
more simpler).

> The scenario we're trying to avoid is one in which two machines rapidly
> exchange packets with both P and F set.
The idea you said was to help avoid one packet send. I have told you
exactly how you can avoid the one extra packet send case.

It seems you want to go to great lengths to prevent one packet send.
My view is such things have generally been un-optimal and result in
more issues than fixes.

> Well, as the first implementor of BFD (and an active developer in our
> products) I do have a solid footing on what's spec and what's implementation.
>I explained at length why the spec reads the way it does.  I see no
> use in belaboring this point.
I do not deny the fact. You said that it was a broken implementation
if it happens (which we now agree was not the case). You also said
that it prevents a packet send, I have mentioned other ways to do the
same.

You could restart your packet send in case you send a Final bit and it
gets you the same behavior. Please explain how a simple and obvious
solution is not better than the solution you propose.

I also wanted to know if you felt your implementation is currently
handling this case correctly?

Thanks,
Vishwas

On Thu, Feb 5, 2009 at 12:55 PM, Dave Katz <[email-masked]> wrote:
>
> On Feb 5, 2009, at 12:26 PM, Vishwas Manral wrote:
>
>> Hi Dave,
>>
>> You miss the basic point of networking!!! Two machines operate
>> independently and that is the reason they can both initiate poll at
>> the same time. There is no broken implementation required for this.
>> Try put a time buffer in you receive queue (this is to like simulating
>> overload - not a change of behavior) and change the parameters in both
>> the ends of the session. Your implementation will show you the same
>> behavior.
>
> And you're missing the point of what I'm saying.  There is nothing broken in
> having both sides wanting to Poll at the same time (and it in fact is quite
> likely to happen when a session first comes up, as both sides will likely be
> negotiating new transmit times.)  This works just fine with the spec as
> defined.
>
>>
>>
>>> Yes, it's to avoid the possibility of packet floods.  Since packets with
>>> Final can be sent without regard to rate control, it would open up a
>>> possibility of wire-rate packets being exchanged in both directions if
>>> packets with Poll could be sent the same way.  It would require a broken
>>> implementation for it to happen, but one of the overriding design
>>> criteria
>>> in BFD was to avoid catastrophic meltdown due to excessive packet
>>> transmission.
>>
>> We have two different machines. They can initiate the poll at the same
>> time. There is no broken implementation at all. Poll can be initiated
>> at both ends symultaneously. Please explain what you mean by a broken
>> implementation? I have given you basic examples of how the same
>> problem has manifested in BGP.
>
> The scenario we're trying to avoid is one in which two machines rapidly
> exchange packets with both P and F set.  The receipt of P requires an
> immediate response with F, but if P happens to be set in that rapid
> response, the first machine will rapidly respond with F.  The brokenness
> would happen if one machine kept sending P with its F;  in that case the
> packets would ricochet forever at wire speed.
>
> The simple expedient of not allowing P and F together provides some leverage
> against this brokenness, at a cost of an extra packet.  Yes, we can't avoid
> all broken software (since by definition it could ignore this rule as well),
> but the rule provides some cheap insurance at very low cost.
>
>>
>>
>> You seem to be adding a lot of complexity into the spec for protecting
>> a case of some timer value which can change (which will rearly
>> happen). You are now stating that Poll bit is not sticky for certain
>> packets.
>
> As we have discussed before, packet contents are *not* state variables.
>  This is clearly defined in the spec.  There is no such thing as a "sticky"
> value in a packet--packets are ephemeral.  How this is handled in an
> implementation is not the concern of the spec.
>
> Further, this is not "a lot" of complexity.  I explained how one could code
> it in one sentence.  In our implementation it requires a handful of lines of
> code to pull off.
>
>>
>>
>> The problem is you are not seeing the difference between where the
>> spec needs to specify things and where the spec can let the
>> implementor do things themselves.
>
> Well, as the first implementor of BFD (and an active developer in our
> products) I do have a solid footing on what's spec and what's
> implementation.  I explained at length why the spec reads the way it does.
>  I see no use in belaboring this point.
>
> --Dave
>
>

From: Dave Katz <[email-masked]>
To: Vishwas Manral <[email-masked]>
Subject: Re: More BFD base issues
Date: Thu, 5 Feb 2009 15:04:24 -0700
Cc: [email-masked]

On Feb 5, 2009, at 2:45 PM, Vishwas Manral wrote:

>>
> The idea you said was to help avoid one packet send. I have told you
> exactly how you can avoid the one extra packet send case.

No, you have it backwards.  The point is to avoid a meltdown, at the  
cost of one *extra* packet, which is essentially zero cost.

>
>
> It seems you want to go to great lengths to prevent one packet send.
> My view is such things have generally been un-optimal and result in
> more issues than fixes.

No, we go to small lengths to try not to destroy networks.

>
>
>> Well, as the first implementor of BFD (and an active developer in our
>> products) I do have a solid footing on what's spec and what's  
>> implementation.
>> I explained at length why the spec reads the way it does.  I see no
>> use in belaboring this point.
> I do not deny the fact. You said that it was a broken implementation
> if it happens (which we now agree was not the case). You also said
> that it prevents a packet send, I have mentioned other ways to do the
> same.
>
> You could restart your packet send in case you send a Final bit and it
> gets you the same behavior. Please explain how a simple and obvious
> solution is not better than the solution you propose.

You are free to implement it any way you want.  You just have to meet  
the transmission rate constraints and can't set P and F in the same  
packet.

>
>
> I also wanted to know if you felt your implementation is currently
> handling this case correctly?

Yes, and it is widely deployed, as are others'.

But the fact of the matter is that the spec has read this way for  
several years, it is technically sound, it has been reviewed by  
experts, there are multiple interoperable implementations out there,  
and the spec is in last call.  You are free to go to the WG and  
introduce a document to change the spec as you see fit.  But frankly  
this discussion is a waste of everyone's bandwidth.

--Dave

Date: Thu, 5 Feb 2009 14:25:58 -0800
Subject: Re: More BFD base issues
From: Vishwas Manral <[email-masked]>
To: Dave Katz <[email-masked]>
Cc: [email-masked]

Hi Dave,

You are unwilling to compare alternate similar/ simpler solutions.

I think we can leave the dicussion like you suggested.

Thanks,
Vishwas

On Thu, Feb 5, 2009 at 2:04 PM, Dave Katz <[email-masked]> wrote:
>
> On Feb 5, 2009, at 2:45 PM, Vishwas Manral wrote:
>
>>>
>> The idea you said was to help avoid one packet send. I have told you
>> exactly how you can avoid the one extra packet send case.
>
> No, you have it backwards.  The point is to avoid a meltdown, at the cost of
> one *extra* packet, which is essentially zero cost.
>
>>
>>
>> It seems you want to go to great lengths to prevent one packet send.
>> My view is such things have generally been un-optimal and result in
>> more issues than fixes.
>
> No, we go to small lengths to try not to destroy networks.
>
>>
>>
>>> Well, as the first implementor of BFD (and an active developer in our
>>> products) I do have a solid footing on what's spec and what's
>>> implementation.
>>> I explained at length why the spec reads the way it does.  I see no
>>> use in belaboring this point.
>>
>> I do not deny the fact. You said that it was a broken implementation
>> if it happens (which we now agree was not the case). You also said
>> that it prevents a packet send, I have mentioned other ways to do the
>> same.
>>
>> You could restart your packet send in case you send a Final bit and it
>> gets you the same behavior. Please explain how a simple and obvious
>> solution is not better than the solution you propose.
>
> You are free to implement it any way you want.  You just have to meet the
> transmission rate constraints and can't set P and F in the same packet.
>
>>
>>
>> I also wanted to know if you felt your implementation is currently
>> handling this case correctly?
>
> Yes, and it is widely deployed, as are others'.
>
> But the fact of the matter is that the spec has read this way for several
> years, it is technically sound, it has been reviewed by experts, there are
> multiple interoperable implementations out there, and the spec is in last
> call.  You are free to go to the WG and introduce a document to change the
> spec as you see fit.  But frankly this discussion is a waste of everyone's
> bandwidth.
>
> --Dave
>

Date: Thu, 5 Feb 2009 14:31:01 -0800
Subject: Re: More BFD base issues
From: Nitin Bahadur <[email-masked]>
To: Dave Katz <[email-masked]>, Vishwas Manral <[email-masked]>
Cc: [email-masked]

Folks,

  The BFD base spec is in IESG processing and close to being approved as an
RFC. Please do not make further protocol behavior changes to the spec unless
it's a big necessity and something is badly broken.

  That said, if there are optimizations that can be performed, then a new
draft can be written towards that effect.

  The discussion of allowing P & F bits simultaneously is moot at this point
IMO...since the spec has been stable for a while and any changes in that
regard would not only break existing implementations (if version number is
not bumped) but also more importantly push the spec another 6-9 months from
becoming an RFC.

> But the fact of the matter is that the spec has read this way for
> several years, it is technically sound, it has been reviewed by
> experts, there are multiple interoperable implementations out there,
> and the spec is in last call.  You are free to go to the WG and
> introduce a document to change the spec as you see fit.  But frankly
> this discussion is a waste of everyone's bandwidth.
> 
> --Dave

Thanks
Nitin

From: David Ward <[email-masked]>
To: [email-masked]
Subject: BFD specs moving forward
Date: Thu, 5 Feb 2009 16:53:29 -0600
Cc: David Ward <[email-masked]>, Dave Katz <[email-masked]>

We'll be publishing the specs w/ changes to address the IESG DISCUSS  
points and nits picked shortly. I know that everyone has wanted BFD to  
be an RFC long before now and originally we promised to have the  
fastest specification to RFC in the history of the IETF but, we've all  
learned a lot from wide implementation and deployment experience. As  
one should expect, it produced a much more sound protocol.

Not trying to be premature and irrational exuberance but, next on the  
plate will be a resubmission of the D&D p2mp draft. many other  
technologies are dependent on the point to multipoint solution.

Thanks

Dave and Dave

From: [email-masked]
To: [email-masked]
Subject: I-D Action:draft-ietf-bfd-base-09.txt 
Date: Thu,  5 Feb 2009 18:15:02 -0800 (PST)
Cc: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF.

	Title           : Bidirectional Forwarding Detection
	Author(s)       : D. Katz, D. Ward
	Filename        : draft-ietf-bfd-base-09.txt
	Pages           : 49
	Date            : 2009-02-05

This document describes a protocol intended to detect faults in the
bidirectional path between two forwarding engines, including
interfaces, data link(s), and to the extent possible the forwarding
engines themselves, with potentially very low latency.  It operates
independently of media, data protocols, and routing protocols.

Conventions used in this document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [KEYWORDS].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-bfd-base-09.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-bfd-base-09.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--NextPart--

From: [email-masked]
To: [email-masked]
Subject: I-D Action:draft-ietf-bfd-v4v6-1hop-09.txt 
Date: Thu,  5 Feb 2009 18:15:02 -0800 (PST)
Cc: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF.

	Title           : BFD for IPv4 and IPv6 (Single Hop)
	Author(s)       : D. Katz, D. Ward
	Filename        : draft-ietf-bfd-v4v6-1hop-09.txt
	Pages           : 8
	Date            : 2009-02-05

This document describes the use of the Bidirectional Forwarding
Detection protocol over IPv4 and IPv6 for single IP hops.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-bfd-v4v6-1hop-09.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-bfd-v4v6-1hop-09.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--NextPart--

From: [email-masked]
To: [email-masked]
Subject: I-D Action:draft-ietf-bfd-generic-05.txt 
Date: Thu,  5 Feb 2009 18:15:02 -0800 (PST)
Cc: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF.

	Title           : Generic Application of BFD
	Author(s)       : D. Katz, D. Ward
	Filename        : draft-ietf-bfd-generic-05.txt
	Pages           : 18
	Date            : 2009-02-05

This document describes the generic application of the Bidirectional
Forwarding Detection (BFD) protocol.

Conventions used in this document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [KEYWORDS].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-bfd-generic-05.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-bfd-generic-05.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--NextPart--

From: [email-masked]
To: [email-masked]
Subject: I-D Action:draft-ietf-bfd-multihop-07.txt 
Date: Thu,  5 Feb 2009 18:15:02 -0800 (PST)
Cc: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF.

	Title           : BFD for Multihop Paths
	Author(s)       : D. Katz, D. Ward
	Filename        : draft-ietf-bfd-multihop-07.txt
	Pages           : 7
	Date            : 2009-02-05

This document describes the use of the Bidirectional Forwarding
Detection protocol (BFD) over multihop paths, including
unidirectional links.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-bfd-multihop-07.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-bfd-multihop-07.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--NextPart--

From: [email-masked]
To: [email-masked]
Subject: I-D Action:draft-katz-ward-bfd-multipoint-02.txt 
Date: Thu,  5 Feb 2009 18:15:02 -0800 (PST)
Cc: [email-masked]

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Bidirectional Forwarding Detection Working Group of the IETF.

	Title           : BFD for Multipoint Networks
	Author(s)       : D. Katz, D. Ward
	Filename        : draft-katz-ward-bfd-multipoint-02.txt
	Pages           : 29
	Date            : 2009-02-05

This document describes extensions to the Bidirectional Forwarding
Detection (BFD) protocol for its use in multipoint and multicast
networks.  Comments on this draft should be directed to rtg-
[email-masked].

Conventions used in this document

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [KEYWORDS].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-katz-ward-bfd-multipoint-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Message/External-body;
	name="draft-katz-ward-bfd-multipoint-02.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--NextPart--