Subject: BFD echo mode

From: "Vishwas Manral" <[email-masked]>
Date: Wed, 26 Nov 2008 09:56:56 -0800

Hi Dave/ Nitin,

I was wondering how the echo mode would actually work for BFD as the
specification does not seem to specify the same. I looked up the
archive and got the link
http://www.ietf.org/mail-archive/web/rtg-bfd/current/msg00216.html.

Seeing some vendor documentation it seems they use a seperate port for
the echo mode - as the source and the destination address. Assuming
the forwarding path just loops back the packet by swapping the source
and destination address/ port. How would an echo (request) be
distinguished from an echo reply.

Can the asusmption that the echo mode packet is a BFD packet be made
(so the BFD source / dest packet identifiers can be used)? The base
BFD spec seems to state the content of the packet need not be
specified as the packet is just looped back.

Thanks,
Vishwas

---

From: David Ward <[email-masked]>
Date: Wed, 26 Nov 2008 12:33:59 -0600

Vishwas -

On Nov 26, 2008, at 11:56 AM, Vishwas Manral wrote:

> and destination address/ port.

DW: There is no swapping of values required

> How would an echo (request) be

DW: There are no echo request/reply semantics in BFD.

> specified as the packet is just looped back.

DW: An implementation sets the src from itself and dest to itself. No  
swapping and no need to look at any contents.

-DWard

---

From: "Vishwas Manral" <[email-masked]>
Date: Wed, 26 Nov 2008 11:49:29 -0800

Hi Dave,

Thanks for the reply.  I am still a bit confused?

So I can see how we could look an IP packet in the case of Single Hop
(by having the MAC Destination Address of the peer) but having IP
address and destination the same (as of the source).

However we would not have a mechanism to loop packet in the case of
multihop (unless we are using) unless we use source hop options (thus
defining the hops).

That said as the mechanism itself is not defined, how can a peer say
it supports the Echo-mode, which is necessary for the Echo-mode to
work?

Thanks again,
Vishwas

---

From: David Ward <[email-masked]>
Date: Wed, 26 Nov 2008 14:45:05 -0600

The spec will be updated that MH echo is not recommended.

-DWard

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Thu, 27 Nov 2008 01:41:11 -0800

Hello Vishwas.

Couple of add-on comments, for single-hop.

> Seeing some vendor documentation it seems they use a seperate 
> port for the echo mode - as the source and the destination 
> address.

I hope vendors aren't using different udp dest port for echo packets.

http://tools.ietf.org/html/draft-ietf-bfd-v4v6-1hop-08 Sec4.1.

BFD Echo packets MUST be transmitted in UDP packets with destination
UDP port 3785 in an IPv4 packet.

> Can the asusmption that the echo mode packet is a BFD packet 
> be made (so the BFD source / dest packet identifiers can be 
> used)? The base BFD spec seems to state the content of the 
> packet need not be specified as the packet is just looped back.

BFD echo packets can be identified by UDP dest port 3785.
Data beyond UDP header is not specified, and that's left up to vendors.

> So I can see how we could look an IP packet in the case of 
> Single Hop (by having the MAC Destination Address of the 
> peer) but having IP address and destination the same (as of 
> the source).

I don't think there's anything that specifies that dest & src addresses
must be the same. For dest addresses tho, it maybe easier to
demultiplex if dest address is the outgoing interface.

Thanx,
Nobo

---

From: "Vishwas Manral" <[email-masked]>
Date: Thu, 27 Nov 2008 05:51:43 -0800

Hi Nobo,

> UDP port 3785 in an IPv4 packet.
Thankf for this.

> demultiplex if dest address is the outgoing interface.
That is correct. I guess you mean the destination IP address in your
message above, is that right?

Thanks,
Vishwas

---

From: "Nobo Akiya (nobo)" <[email-masked]>
Date: Thu, 27 Nov 2008 06:12:32 -0800

Hello Vishwas.

> Single Hop 
> >> (by having the MAC Destination Address of the
> >> peer) but having IP address and destination the same (as of the 
> >> source).
> >
> > I don't think there's anything that specifies that dest & src 
> > addresses must be the same. For dest addresses tho, it 
> maybe easier to 
> That is correct. I guess you mean the destination IP address 
> in your message above, is that right?

Yup, I meant destination IP address. Another reason why you should
specify the outgoing interfaces' address as the destination IP address
is that, with any other local IP address (ex: loopback), echo packet
COULD come back via different interface.

Thanx,
Nobo

---

From: David Ward <[email-masked]>
Date: Thu, 27 Nov 2008 09:45:17 -0600

Nobo -

On Nov 27, 2008, at 3:41 AM, Nobo Akiya (nobo) wrote:

> addresses

DW: there is nothing in the spec that says the addrs have to be the  
same.

-DWard

---

From: "Vishwas Manral" <[email-masked]>
Date: Sun, 30 Nov 2008 11:14:43 -0800

Hi Dave,

Agree to what you say.

I was also thinking of congestion control considerations to be put
into BFD for the Multi-hop case. The draft does not talk about it and
because BFD works on very short duration Hello's it may need to be TCP
friendly in some cases.

Do let me know what you think?

Thanks,
Vishwas

On Thu, Nov 27, 2008 at 7:45 AM, David Ward <[email-masked]> wrote:
> DW: there is nothing in the spec that says the addrs have to be the same.
>
>
> -DWard
>
>>
>> Thanx,
>> Nobo
>>
>
>

---

From: David Ward <[email-masked]>
Date: Sun, 30 Nov 2008 13:50:15 -0600

Additional congestion control isn't necessary if an implementation  
takes into consideration the adaptive timer support. This is if an  
implementer believes that BFD configuration would be set by an  
operator such that the already inconsequential amount of data being  
sent actually causes congestion. BFD should not be run over TCP due  
to overhead or UDP-lite due to lack of widespread deployment.

-DWard

---

From: "Vishwas Manral" <[email-masked]>
Date: Sun, 30 Nov 2008 12:11:19 -0800

Dave,

Sounds good. So what you are saying is that adaptive timer support
needs to be there? Is the understanding correct.

-Vishwas

On Sun, Nov 30, 2008 at 11:50 AM, David Ward <[email-masked]> wrote:
> Additional congestion control isn't necessary if an implementation takes
> into consideration the adaptive timer support. This is if an implementer
> believes that BFD configuration would be set by an operator such that the
> already inconsequential amount of data being sent actually causes
> congestion. BFD should not be run over TCP due to overhead or UDP-lite due
> to lack of widespread deployment.
>
> -DWard
>

---

From: David Ward <[email-masked]>
Date: Sun, 30 Nov 2008 23:03:30 -0600

The specification and implementation of adaptive timers was expected  
to be the congestion control mechanism.

-DWard

On Nov 30, 2008, at 2:11 PM, Vishwas Manral wrote:

>> takes