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 >>>>> >>>> >>>> >> >>
- BFD echo mode Vishwas Manral
- Re: BFD echo mode David Ward
- Re: BFD echo mode Vishwas Manral
- Re: BFD echo mode David Ward
- RE: BFD echo mode Nobo Akiya (nobo)
- Re: BFD echo mode Vishwas Manral
- RE: BFD echo mode Nobo Akiya (nobo)
- Re: BFD echo mode David Ward
- Re: BFD echo mode Vishwas Manral
- Re: BFD echo mode David Ward
- Re: BFD echo mode Vishwas Manral
- Re: BFD echo mode David Ward