Re: BFD echo mode

David Ward <dward@cisco.com> Mon, 01 December 2008 05:04 UTC

Return-Path: <rtg-bfd-bounces@ietf.org>
X-Original-To: rtg-bfd-archive@megatron.ietf.org
Delivered-To: ietfarch-rtg-bfd-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB1603A67EE; Sun, 30 Nov 2008 21:04:14 -0800 (PST)
X-Original-To: rtg-bfd@core3.amsl.com
Delivered-To: rtg-bfd@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0464B3A67EE for <rtg-bfd@core3.amsl.com>; Sun, 30 Nov 2008 21:04:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VsfvCUG3XteQ for <rtg-bfd@core3.amsl.com>; Sun, 30 Nov 2008 21:04:13 -0800 (PST)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id B465D3A67B6 for <rtg-bfd@ietf.org>; Sun, 30 Nov 2008 21:04:12 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.33,693,1220227200"; d="scan'208";a="29482135"
Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 01 Dec 2008 05:04:06 +0000
Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id mB1546KH007358; Mon, 1 Dec 2008 00:04:06 -0500
Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id mB1546DL001186; Mon, 1 Dec 2008 05:04:06 GMT
Received: from xmb-rtp-202.amer.cisco.com ([64.102.31.52]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Dec 2008 00:04:06 -0500
Received: from [127.0.0.1] ([171.68.225.134]) by xmb-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 1 Dec 2008 00:03:33 -0500
In-Reply-To: <77ead0ec0811301211i967f3cao810de37ba54315e@mail.gmail.com>
References: <77ead0ec0811260956u62e0e27aj66fbdba29453c5ad@mail.gmail.com> <F3F69139C275F848A1DB1518DC2C216806859108@xmb-sjc-22c.amer.cisco.com> <100B46D2-FC38-4E33-879A-61F0217CC83D@cisco.com> <77ead0ec0811301114p7dbe9cc9kbc0ff482ccdb66d@mail.gmail.com> <ACA91E09-E039-48A3-80FB-4D280E3CDC4B@cisco.com> <77ead0ec0811301211i967f3cao810de37ba54315e@mail.gmail.com>
Mime-Version: 1.0 (Apple Message framework v753.1)
Content-Type: text/plain; charset="US-ASCII"; delsp="yes"; format="flowed"
Message-Id: <D71A6E2B-7B9F-4AE6-8D2D-23B46F6BE219@cisco.com>
Content-Transfer-Encoding: 7bit
From: David Ward <dward@cisco.com>
Subject: Re: BFD echo mode
Date: Sun, 30 Nov 2008 23:03:30 -0600
To: Vishwas Manral <vishwas.ietf@gmail.com>
X-Mailer: Apple Mail (2.753.1)
X-OriginalArrivalTime: 01 Dec 2008 05:03:33.0956 (UTC) FILETIME=[29362040:01C95372]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3121; t=1228107846; x=1228971846; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dward@cisco.com; z=From:=20David=20Ward=20<dward@cisco.com> |Subject:=20Re=3A=20BFD=20echo=20mode |Sender:=20 |To:=20=22Vishwas=20Manral=22=20<vishwas.ietf@gmail.com>; bh=IIYcARt1+bJQOEjoAxGUDiyv4nBPP5bse/80GOP/E/4=; b=lJZvyiJ5L0uSism9uUmaykvoOHEia230FNk+M8e/fPKqgJp5SbLnvfdIeB lNB/BJcy3CK/2JRkri3TG2w9hXkNaX2N7rT/zrMfDsnKVJbyUSv8Hi8AAVf/ i1Vje+7Wwb;
Authentication-Results: rtp-dkim-1; header.From=dward@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; );
Cc: rtg-bfd@ietf.org, David Ward <dward@cisco.com>, Dave Katz <dkatz@juniper.net>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/rtg-bfd>
List-Post: <mailto:rtg-bfd@ietf.org>
List-Help: <mailto:rtg-bfd-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=subscribe>
Sender: rtg-bfd-bounces@ietf.org
Errors-To: rtg-bfd-bounces@ietf.org

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:

> 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 <dward@cisco.com> 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
>>
>> On Nov 30, 2008, at 1:14 PM, Vishwas Manral wrote:
>>
>>> 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 <dward@cisco.com> wrote:
>>>>
>>>> Nobo -
>>>>
>>>> On Nov 27, 2008, at 3:41 AM, Nobo Akiya (nobo) wrote:
>>>>
>>>>>
>>>>> 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.
>>>>
>>>>
>>>> DW: there is nothing in the spec that says the addrs have to be  
>>>> the same.
>>>>
>>>>
>>>> -DWard
>>>>
>>>>>
>>>>> Thanx,
>>>>> Nobo
>>>>>
>>>>
>>>>
>>
>>