IETF Logo Mail Archive

Re: BFD WG adoption for draft-haas-bfd-large-packets

"Reshad Rahman (rrahman)" <rrahman@cisco.com> Fri, 26 October 2018 18:24 UTC

Return-Path: <rrahman@cisco.com>
X-Original-To: rtg-bfd@ietfa.amsl.com
Delivered-To: rtg-bfd@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A549130DDA for <rtg-bfd@ietfa.amsl.com>; Fri, 26 Oct 2018 11:24:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.502
X-Spam-Level:
X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YjOFFpLLBMtV for <rtg-bfd@ietfa.amsl.com>; Fri, 26 Oct 2018 11:24:58 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6A80126CB6 for <rtg-bfd@ietf.org>; Fri, 26 Oct 2018 11:24:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2722; q=dns/txt; s=iport; t=1540578297; x=1541787897; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=7MHX/1U1mFJl4EZpMhA+hZg7vG2BSBtmy/P2A7QnN2U=; b=HRMLeQdnu0g9wm6YcRAY+s0c8r1MiJqCR2OG6HolRnaQuLK+FD0/FS5y 1C+6st2FFvODCofwf5fZ8lAPTLmBrqTl4AnVzG0sm+5B/oTnCtjnQhlA4 F4OTbamHZ/LtNFi3d/aGeTtL54emJcGif6T9o0dSuTiyp5k6k45aNjq9u I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AFAAApW9Nb/4ENJK1jGQEBAQEBAQEBAQEBAQcBAQEBAQGBUgMBAQEBAQsBgVoqZn8oCoNrlDCCDZcdgXoLAQEjCYRAAheDASE1DA0BAwEBAgEBAm0cDIU6AQEBAwEjEUUQAgEIDgoCAiYCAgIwFRACBAENBYMhAYF5CA+mS4EuhDAChWcFgQuKXBeBQT+BOB+CTIMbAQEDgV4Xgm0xgiYCiQWVegkChmeKFhiBUogShmGMbYl+AhEUgSYfAjSBVXAVZQGCQYM6AQGHXYU+b4EoincBgR4BAQ
X-IronPort-AV: E=Sophos;i="5.54,428,1534809600"; d="scan'208";a="472040266"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Oct 2018 18:24:56 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id w9QIOuA8008990 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 26 Oct 2018 18:24:56 GMT
Received: from xch-rcd-005.cisco.com (173.37.102.15) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 26 Oct 2018 13:24:56 -0500
Received: from xch-rcd-005.cisco.com ([173.37.102.15]) by XCH-RCD-005.cisco.com ([173.37.102.15]) with mapi id 15.00.1395.000; Fri, 26 Oct 2018 13:24:56 -0500
From: "Reshad Rahman (rrahman)" <rrahman@cisco.com>
To: Jeffrey Haas <jhaas@pfrc.org>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
CC: "Naiming Shen (naiming)" <naiming@cisco.com>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>
Subject: Re: BFD WG adoption for draft-haas-bfd-large-packets
Thread-Topic: BFD WG adoption for draft-haas-bfd-large-packets
Thread-Index: AQHUZn7F2obCS5tWFUCJRL2ls+mZdKUo1C+ggAHIywD//67wkIAAV7mA///Hi8CABg0XgIAAHPRwgAB/doCAAOF5gA==
Date: Fri, 26 Oct 2018 18:24:56 +0000
Message-ID: <77F8D72A-9E3E-41FF-A61D-E8545CB98581@cisco.com>
References: <E052CA19-228D-4271-BF9E-7499255E7C53@cisco.com> <7332e35048d34d44a65ea70df409699c@XCH-ALN-001.cisco.com> <90B9205E-CBD8-4779-96D1-2D15BD1F7E24@cisco.com> <e08744fc4b264fd1bf9844dd0f29557e@XCH-ALN-001.cisco.com> <59DD4DA1-6C83-4D3D-92E7-B4271EB259E8@cisco.com> <2dc00a0d58db41958ad61d73d08ead17@XCH-ALN-001.cisco.com> <20181025153804.GD12336@pfrc.org> <a367a9ceec9e4f96ac41223a4fde494f@XCH-ALN-001.cisco.com> <20181026005755.GF12336@pfrc.org>
In-Reply-To: <20181026005755.GF12336@pfrc.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.b.0.180311
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [161.44.212.40]
Content-Type: text/plain; charset="utf-8"
Content-ID: <4B873E7B590E6B4885F06C48737B93D0@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com
X-Outbound-Node: alln-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/RKWUi-KSghiccRCXwiTwpuEkZWc>
X-BeenThere: rtg-bfd@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTG Area: Bidirectional Forwarding Detection DT" <rtg-bfd.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-bfd>, <mailto:rtg-bfd-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/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>
X-List-Received-Date: Fri, 26 Oct 2018 18:25:00 -0000

    An interesting question for the large-packets draft is whether we want to
    support a periodic probing mode, perhaps leveraging the stability draft's
    ideas.  Or, should it instead only be consistent?

I can see how using BFD to detect an MTU failure and doing the reroute can make sense, it's forwarding fault detection after all. But IMO probing MTU should not be done by BFD, unless we're considering rechartering/BFDv2.

Regards,
Reshad (hat on). 

On 2018-10-25, 8:58 PM, "Jeffrey Haas" <jhaas@pfrc.org> wrote:

    On Thu, Oct 25, 2018 at 10:28:52PM +0000, Les Ginsberg (ginsberg) wrote:
    > > https://tools.ietf.org/html/draft-ietf-bfd-stability-02
    > 
    > [Les:] I have read this draft - not sure how relevant it is.
    
    Mostly, the idea being that it's possible to do probing in BFD without
    necessarily having to commit your entire detection resources to it.
    
    > Naiming had suggested that MTU sized packets need not be sent all the time but only occasionally - 
    > and that a failure might not be used to take the BFD session down - 
    > rather it would be seen as a "soft-failure" and reported separately from the BFD session state.
    > My response was in that context - which it seems was also in your mind in your BFD Echo proposal.
    > 
    > This, however, seems not to be what Albert has in mind - as he has since commented that he really wants to have sub-second detection of MTU issues and 
    > he wants traffic rerouted "immediately".
    
    Right.  This is part of the point I'd made earlier in the thread.  Some
    consumers need immediate failover and consistent MTU probe while others
    might be satisfied with periodic probing.  
    
    An interesting question for the large-packets draft is whether we want to
    support a periodic probing mode, perhaps leveraging the stability draft's
    ideas.  Or, should it instead only be consistent?
    
    -- Jeff

v2.30.2 | Report a Bug | By Email | System Status