IETF Logo Mail Archive

Re: [Idr] ietf-104 responding to Rüdiger's comment about bfd strict mode

"Acee Lindem (acee)" <acee@cisco.com> Thu, 28 March 2019 13:52 UTC

Return-Path: <acee@cisco.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A57112028E for <idr@ietfa.amsl.com>; Thu, 28 Mar 2019 06:52:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=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 header.b=jZT8ofTI; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=SReGLgG9
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 cV47s-SmkOC1 for <idr@ietfa.amsl.com>; Thu, 28 Mar 2019 06:52:06 -0700 (PDT)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2452512043F for <idr@ietf.org>; Thu, 28 Mar 2019 06:52:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12189; q=dns/txt; s=iport; t=1553781125; x=1554990725; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=X8wSU1N5x3TGxvkT7U2k0AQeBMhbJNBaW+SEOXusufs=; b=jZT8ofTIyS2t7asgBj1V9tuqgyQniN8Vx++D3SvHXWKyc9kSS/dU8PEa LX3NzhIoH+b3VJArU3+ZSvpEjbokWWT52nJDpXZK4aytUIfEynGaLzc/4 Rijfw5waA22egiOdgj7MQjGuZJyPsqjbrnerItFMosAWgcRfnLNOIg86V I=;
IronPort-PHdr: 9a23:Tsx+2B3sqFZh47MFsmDT+zVfbzU7u7jyIg8e44YmjLQLaKm44pD+JxGCt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8TgZdYBUERoMiMEYhQslVceOBEDTJ//xZCt8F8NHBxdo
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ADAACI0Jxc/5pdJa1kGQEBAQEBAQEBAQEBAQcBAQEBAQGBUQQBAQEBAQsBgQ4vJAUnA2h0BAsnhA6DRwOEUopYgleSRYRJgS6BJANUDQEBGAEKCYRAAheFGyI0CQ0BAQMBAQkBAwJtHAyFSgEBAQQBASEdAQEsCwEPAgEGAhEDAQIoAwICAiULFAYDCAIEAQ0FgyIBgRFMAxUBDo4ukF8CihRxgS+CeAEBBYE1AoNNGIIMAwWBLwGLMReBf4E4H4JMPoJhAQEDgXUJDQmCVDGCJop1ggeEIodKjEYJAodqi1saggOSCYJ2iDaBGIRxjTECBAIEBQIOAQEFgU04KIEucBU7KgGCQYIKgSMBCYJBhRSFP3KBKI5NAQE
X-IronPort-AV: E=Sophos;i="5.60,280,1549929600"; d="scan'208,217";a="251064226"
Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 28 Mar 2019 13:52:03 +0000
Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x2SDq3kU005338 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 28 Mar 2019 13:52:03 GMT
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 28 Mar 2019 08:52:02 -0500
Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 28 Mar 2019 08:52:02 -0500
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 28 Mar 2019 08:52:02 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=X8wSU1N5x3TGxvkT7U2k0AQeBMhbJNBaW+SEOXusufs=; b=SReGLgG91w0yVzsIAspS4ByRKWdvcLWOhq+b9DKhpZnaCIzJHT9AsB47/xLUBPe/eS8xgVdUSLFfC/31CqfYVcKk1jjShT9bbrH02SWYZTnhw8jKqSoUFKn5GOqctnEP5q17efq1H1EqzTTTLeq85R5eViOhWRj5H9NlU0SfCG0=
Received: from BN6PR1101MB2226.namprd11.prod.outlook.com (10.174.112.11) by BN6PR1101MB2258.namprd11.prod.outlook.com (10.174.117.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.17; Thu, 28 Mar 2019 13:52:01 +0000
Received: from BN6PR1101MB2226.namprd11.prod.outlook.com ([fe80::7c15:be1e:a2bd:7e28]) by BN6PR1101MB2226.namprd11.prod.outlook.com ([fe80::7c15:be1e:a2bd:7e28%5]) with mapi id 15.20.1730.019; Thu, 28 Mar 2019 13:52:01 +0000
From: "Acee Lindem (acee)" <acee@cisco.com>
To: Robert Raszuk <robert@raszuk.net>, Jeffrey Haas <jhaas@pfrc.org>
CC: "idr@ietf. org" <idr@ietf.org>
Thread-Topic: [Idr] ietf-104 responding to Rüdiger's comment about bfd strict mode
Thread-Index: AQHU5V6h8wYAQXy+UUu4cfB1ahnZGaYgzQiA
Date: Thu, 28 Mar 2019 13:52:00 +0000
Message-ID: <FBE4CC86-EE29-4E44-AC27-171D4DDD8FEC@cisco.com>
References: <20190328111833.GB24351@pfrc.org> <CAOj+MMGorV9StNVCvDyHgHHTdg+u0EQ0VDT-L6AVVUQTKGkwfQ@mail.gmail.com>
In-Reply-To: <CAOj+MMGorV9StNVCvDyHgHHTdg+u0EQ0VDT-L6AVVUQTKGkwfQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=acee@cisco.com;
x-originating-ip: [2001:420:c0c8:1002::437]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: f3d2902e-568e-4388-a3fb-08d6b3848d8f
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BN6PR1101MB2258;
x-ms-traffictypediagnostic: BN6PR1101MB2258:
x-ms-exchange-purlcount: 4
x-microsoft-antispam-prvs: <BN6PR1101MB22580C11D9EE94EDACA6422BC2590@BN6PR1101MB2258.namprd11.prod.outlook.com>
x-forefront-prvs: 0990C54589
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(346002)(376002)(366004)(136003)(39860400002)(189003)(199004)(6506007)(2616005)(68736007)(446003)(186003)(11346002)(966005)(82746002)(4326008)(46003)(53546011)(102836004)(6436002)(229853002)(14454004)(2906002)(86362001)(6246003)(99286004)(71200400001)(53936002)(71190400001)(83716004)(66574012)(476003)(76176011)(486006)(5660300002)(14444005)(256004)(81166006)(36756003)(316002)(6512007)(81156014)(54896002)(6306002)(106356001)(105586002)(110136005)(236005)(8936002)(224303003)(97736004)(6116002)(478600001)(561944003)(33656002)(606006)(9326002)(7736002)(6486002)(25786009); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR1101MB2258; H:BN6PR1101MB2226.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: WfE8SNHF8UNmfctGlS7XH7NSwfDFQsgQSmKXCowZZomcQNUMDSlW7G3aOQ8b057El++sxT138HvBXinq9I/VF3dkluWgtXQYAqE1dYAMxe5Hi0eJIHGDJtIiJVRnjS/UwaIAt9tHlBTq8reclLB7QyUV4dPMAHTgygzHm0l6tdIvZvgh9dreMy3ZoAxUDEUiLAN0Cid4U4z9gmQ36tD7sJacijQQHJ46IJ0GIHAXivBWPyMClQWbGbfJjEoMLVjvbAOSB5UOFRmOAA3oDTWJRJ2f60hAZAVORFoM9r8tJ8FG5/FZEjpDK0DmYJHMdcRlyYUOXxE7s0oGSiHGtDr/m7hcWNuUIwp4BPCgWFOIaPWth1ljpVXoewMjjVJ08UX/UcXhKMyYF+B6YhkYPv4QZ0au7pJlKREfgSSJ+SxT/lk=
Content-Type: multipart/alternative; boundary="_000_FBE4CC86EE294E44AC27171D4DDD8FECciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: f3d2902e-568e-4388-a3fb-08d6b3848d8f
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Mar 2019 13:52:00.9828 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR1101MB2258
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com
X-Outbound-Node: rcdn-core-3.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/YUmNzyq2KhFbMglyrS6StB6bsdQ>
Subject: Re: [Idr] ietf-104 responding to Rüdiger's comment about bfd strict mode
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 28 Mar 2019 13:52:09 -0000

Hi Robert,
As was discussed, manually configured BFD strict mode exist today. This is simply adding BGP signaling to these techniques.

From: Idr <idr-bounces@ietf.org> on behalf of Robert Raszuk <robert@raszuk.net>
Date: Thursday, March 28, 2019 at 8:06 AM
To: Jeff Haas <jhaas@pfrc.org>
Cc: IDR List <idr@ietf.org>
Subject: Re: [Idr] ietf-104 responding to Rüdiger's comment about bfd strict mode

Hi,

As commented on the mic for partially loosy links I would like to see hooks in BGP outside of BFD to determine if BGP session is to be established or torn down.

Specifically using existing tools like rpm or ip sla probes ...

We await your draft 😉

Thanks,
Acee

Thx
R.

On Thu, Mar 28, 2019, 12:19 Jeffrey Haas <jhaas@pfrc.org<mailto:jhaas@pfrc.org>> wrote:
In IETF 104, Rüdiger responded that he'd like to see BFD in BGP be used to
prove that a link is "stable enough" before we even announce routes.

As I mentioned at the mic, the critical issue is that we have varying
implementations of when BFD must be up in differing implementations with
regard to the BGP FSM.  E.g. Up before we start the transport session
(Connect), or Up before we transition to Established, or Up after
Established.

The proposal from Mercia and Acee effective summ to "if BFD strict
negotiated, wait for BFD to come up before transition to Established".  This
provides a common point for implementations to interoperate.  There is still
potentially issue with older implementations that relied on BFD to be Up
before BGP starts its TCP session; however upon supporting this feature we
implicitly add an option where the behavior is changed.

Back to Rüdiger's point: He has a desire that the session is stable before
we start announcing routes.  In BGP RFC parlance, we do not exchange our
routes in the Update-Send process until stability is declared.

While this is doable, how do you negotiate what level of stability is
desired?  BFD, without extensions, mostly will simply declare the session
Down when enough packets are lost.  If the link quality is very bad, this
should happen quite quickly. If the link quality is partially lossy, BFD
doesn't help.  (However, see https://tools.ietf.org/html/draft-am-bfd-performance-00)

-- Jeff

_______________________________________________
Idr mailing list
Idr@ietf.org<mailto:Idr@ietf.org>
https://www.ietf.org/mailman/listinfo/idr

v2.15.0 | Report a Bug | By Email