Subject: Updated Specs

From: Dave Katz <[email-masked]>
Date: Tue, 13 Jun 2006 20:57:23 -0700

I've just sent off updated versions of all of the Two Daves' specs  
(base, 1hop, multihop, generic) to the Secretariat.  They should be  
posted shortly.

The only technical changes are fixing verbiage around asymmetric echo  
timers in the base spec (which I missed on the last version, oops)  
and documenting the officially assigned port number for multihop.

I bit the bullet and moved all of the control-protocol-specific stuff  
out of the 1hop and into the generic (which is probably misnamed, but  
we can revisit the name when it goes to RFC so as to not generate  
administrative headaches.)  A lot of text got shredded and glued back  
together, so it's worth a close read.

Since the docs are done "early" (as in more than 12 hours prior to  
the meeting cutoff) we will have time to revisit them once more prior  
to Montréal, so I would appreciate it if folks would take a close  
look at the Generic draft in particular.  If I've made any egregious  
mistakes, I can fix them prior to the meeting and then hopefully move  
to RFC on this stuff.

Thanks,

Dave'n'Dave

---

From: David Ward <[email-masked]>
Date: Wed, 14 Jun 2006 11:06:56 -0500

All -

Note that pending any edits, nits to be picked or other mods ... We will
attempt to WG LC these drafts after Montreal (there is not going to be a WG
meeting). So, please consider this your last chance to make comments as I
would like LC to to be a simple procedural wait period if at all possible.

We will need to update the MIB to match the new port numbers and any other
changes as appropriate and then I will be sending out a request for
implementation reports.

-DWard

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Wed, 14 Jun 2006 12:09:43 -0400

We do plan on making one update to the BFD/MPLS
draft by the cut-off date.

	--Tom

---

From: Dave Katz <[email-masked]>
Date: Wed, 14 Jun 2006 09:15:31 -0700

> draft by the cut-off date.

That's good, since the new drafts actually reference the -03 spec.  ;-)

--Dave

---

From: Syed Junaid Farooqi <[email-masked]>
Date: Thu, 15 Jun 2006 00:24:44 -0700

Hi,
In draft-ietf-bfd-base-05.txt

Section 6.5 Demand mode,

The mechanism used does not have to be the same in both directions, and 
is outside of

   the scope of this specification.  *One possible mechanism is the
   receipt of traffic from the remote system;* another is the use of the
   Echo function.

> Wouldnt it be better to avoid generalizing receipt of traffic as presence of connectivity, what i mean is you would have a scenario
where you have two links on a system running two BFD sessions - one on each, but the traffic forwarding is done only on one of the links
in which case the receipt of traffic wouldnt hold good unless we use the echo function (either on one or both links) or we use other
alternative means. How about reframing the sentence to "*One possible mechanism is the use of Echo function*"

~Junaid

---

From: Dave Katz <[email-masked]>
Date: Thu, 15 Jun 2006 09:08:45 -0700

On Jun 15, 2006, at 12:24 AM, Syed Junaid Farooqi wrote:

>
>> Wouldnt it be better to avoid generalizing receipt of traffic as  
>> presence of connectivity, what i mean is you would have a scenario
> where you have two links on a system running two BFD sessions - one  
> on each, but the traffic forwarding is done only on one of the links
> in which case the receipt of traffic wouldnt hold good unless we  
> use the echo function (either on one or both links) or we use other
> alternative means. How about reframing the sentence to "*One  
> possible mechanism is the use of Echo function*"

The point is that there are some situations in which the receipt of  
data traffic is a useful and low-cost way of verifying connectivity.   
The specific case in mind was a very large fan-in device, where the  
cost of running the BFD Control protocol might prove to be impractical.

The text does not purport that this is always a good idea, or always  
works, but only that it is one possible mechanism that can be used if  
appropriate.

(The subtext is that there was a draft to do something like this in a  
rather arcane way for IPsec and we were trying to avoid having  
someone invent Yet Another Hello Protocol.)

--Dave

---

From: David Ward <[email-masked]>
Date: Thu, 15 Jun 2006 11:12:58 -0500

As DK says, we cribbed the idea from existing IPsec DPD (Dead Peer
Detection).

Note that if you are in BFD demand mode, you still get bidir detection as
the other side is monitoring you and can request a poll sequence.

-DWard

---

From: Syed Junaid Farooqi <[email-masked]>
Date: Thu, 15 Jun 2006 09:55:02 -0700

Dave Katz penned, On 6/15/2006 9:08 AM:
>> in which case the receipt of traffic wouldnt hold good unless we use 
>> the echo function (either on one or both links) or we use other
True, I had the idea of Multiple BGP peers on a box and registering the 
BGP sessions with BFD for fast detection e.g. I have close to 200 BGP 
peers on a box
all the BGP sessions registered with BFD, in this particular case, I can 
run demand mode as i do not want the extra overhead, however, I can have 
demand mode + echo mode and still get fast detection. In this case, i 
would have a problem if i implemented demand mode + traffic receipt as 
traffic is being received from only a few of the peers.
My concern here is that the draft should not be misunderstood as 
promoting traffic receipt as one of the preferred means of checking 
connectivity  ( I am not against using receipt of traffic as a means of 
checking connectivity per se, in fact on low speed links i would rather 
use this method).
> rather arcane way for IPsec and we were trying to avoid having someone 
> invent Yet Another Hello Protocol.)
> --Dave
>
>
>

---

From: Dave Katz <[email-masked]>
Date: Fri, 16 Jun 2006 10:30:32 -0700

On Jun 15, 2006, at 9:55 AM, Syed Junaid Farooqi wrote:

>> The point is that there are some situations in which the receipt  
>> of data traffic is a useful and low-cost way of verifying  
>> connectivity.  The specific case in mind was a very large fan-in  
>> device, where the cost of running the BFD Control protocol might  
>> prove to be impractical.
> True, I had the idea of Multiple BGP peers on a box and registering  
> the BGP sessions with BFD for fast detection e.g. I have close to  
> 200 BGP peers on a box
> all the BGP sessions registered with BFD, in this particular case,  
> I can run demand mode as i do not want the extra overhead, however,  
> I can have demand mode + echo mode and still get fast detection. In  
> this case, i would have a problem if i implemented demand mode +  
> traffic receipt as traffic is being received from only a few of the  
> peers.

This is of course an option (and called out as such.)  The assumption  
is that the vendors are smart enough to decide what mechanism to use  
based on their own needs and environments;  Darwin will clean up  
after those who are not.

> connectivity  ( I am not against using receipt of traffic as a  
> means of checking connectivity per se, in fact on low speed links i  
> would rather use this method).

There is no "preferred" method;  essentially none of this is subject  
to standardization, there are few if any real interoperability  
issues, and implementors are free to be imaginative (all of this was  
an explicit goal of BFD, at least from the authors' point of view.)

In this particular case, traffic receipt and the echo function were  
given equal billing (and certainly the existence of the whole echo  
protocol and the hooks for it in the control protocol give it a bit  
more weight than a half sentence mentioning traffic receipt.)  Both  
are listed as "possible" mechanisms;  if this is "promotion" it's  
pretty weak.  A small troll sitting under each end of the link  
deciding when to do a poll sequence is also a possible mechanism.  ;-)

--Dave

---

From: Syed Junaid Farooqi <[email-masked]>
Date: Fri, 16 Jun 2006 11:00:20 -0700

Dave Katz penned, On 6/16/2006 10:30 AM:
>>> data traffic is a useful and low-cost way of verifying 
>> the BGP sessions with BFD for fast detection e.g. I have close to 200 
>> BGP peers on a box
>> all the BGP sessions registered with BFD, in this particular case, I 
>> can run demand mode as i do not want the extra overhead, however, I 
>> can have demand mode + echo mode and still get fast detection. In 
> based on their own needs and environments;  Darwin will clean up after 
> those who are not.
>
>> connectivity  ( I am not against using receipt of traffic as a means 
>> of checking connectivity per se, in fact on low speed links i would 
>> rather use this method).
>
> to standardization, there are few if any real interoperability issues, 
> and implementors are free to be imaginative (all of this was an 
> explicit goal of BFD, at least from the authors' point of view.)
Agreed !
> pretty weak.  *A small troll sitting under each end of the link 
> deciding when to do a poll sequence is also a possible mechanism.  ;-) *
This is priceless, for everything else - mastercard :)

-- 
Syed Junaid Farooqi	
Redback Networks

---

From: "Geoffrey Huang" <[email-masked]>
Date: Mon, 19 Jun 2006 16:17:21 -0700

> -----Original Message-----
> From: David Ward [mailto:[email-masked]]
> Sent: Thursday, June 15, 2006 9:13 AM
> To: Dave Katz; Syed Junaid Farooqi; David Ward
> Cc: bfd
> Subject: Re: Updated Specs
> 

I'm honored (I think).  In all seriousness, my opinion is that the DPD
scheme of "let the interested party decide" has worked out well.  This
is especially true when contrasted with previous, less scalable methods
for liveliness detection in IKE.

As your BFD draft points out (and as you have pointed out elsewhere in
this thread), the behavior is optional.

-g