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

"Nagendra Kumar Nainar (naikumar)" <naikumar@cisco.com> Tue, 23 October 2018 17:29 UTC

Return-Path: <naikumar@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 E757A1274D0 for <rtg-bfd@ietfa.amsl.com>; Tue, 23 Oct 2018 10:29:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 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, 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
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 bG3oD4GufOJ1 for <rtg-bfd@ietfa.amsl.com>; Tue, 23 Oct 2018 10:29:44 -0700 (PDT)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98903124C04 for <rtg-bfd@ietf.org>; Tue, 23 Oct 2018 10:29:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=37766; q=dns/txt; s=iport; t=1540315784; x=1541525384; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=xXhCVQHs6fU3yEzsY1X6lbiwCz6P2+kLZCcm76cVV5s=; b=ZacncxVMWj34dULFqCWMpqtecAiIJDfkH1hIBwdxE1+V1/xx+FYj81mg m8VTcbnl/AQ8I7vy6gdNbyMroSNGDbpQ5eLY/avj6sln95J8FhPYhamGg chbIqm7ltpcewDpzLvA1lHrsXsJYYNTUEYdhCbgdsZbkH08pDN44SITI9 Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AFAADVWc9b/5ldJa1jGQEBAQEBAQEBAQEBAQcBAQEBAQGBUgMBAQEBAQsBgQ1NKmZ/KAqDa5Q1gg2XFYF6CwEBhGwCF4UTITUMDQEDAQECAQECbSiFOgEBAQQjClwCAQYCEQMBAiEBBgMCAgIwFAkIAgQBEhuCO0sBgR1kjAebTYEuiiGLYheCAIERJx+CTIUVCRaCTTGCJgKJZoRRj0VUCQKJQ4cvF5AwlkQCERSBJh4BNieBLnAVZQGCQQmCGhp9AQIHjRNvimIrgQGBHwEB
X-IronPort-AV: E=Sophos;i="5.54,417,1534809600"; d="scan'208,217";a="189853713"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Oct 2018 17:29:43 +0000
Received: from XCH-ALN-012.cisco.com (xch-aln-012.cisco.com [173.36.7.22]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id w9NHThuX010545 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 23 Oct 2018 17:29:43 GMT
Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-ALN-012.cisco.com (173.36.7.22) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Tue, 23 Oct 2018 12:29:42 -0500
Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1395.000; Tue, 23 Oct 2018 12:29:42 -0500
From: "Nagendra Kumar Nainar (naikumar)" <naikumar@cisco.com>
To: "Acee Lindem (acee)" <acee@cisco.com>, Albert Fu <afu14@bloomberg.net>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
Subject: Re: BFD WG adoption for draft-haas-bfd-large-packets
Thread-Topic: BFD WG adoption for draft-haas-bfd-large-packets
Thread-Index: AQHUavKD2obCS5tWFUCJRL2ls+mZdKUtJtSA
Date: Tue, 23 Oct 2018 17:29:42 +0000
Message-ID: <59BFB826-8BCB-4C27-A0FB-52E65752C576@cisco.com>
References: <59FA61C0-3B50-49C7-82B2-BCF69E1A4C55@cisco.com>
In-Reply-To: <59FA61C0-3B50-49C7-82B2-BCF69E1A4C55@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.a.0.180210
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.82.233.148]
Content-Type: multipart/alternative; boundary="_000_59BFB8268BCB4C27A0FB52E65752C576ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 173.36.7.22, xch-aln-012.cisco.com
X-Outbound-Node: rcdn-core-2.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-bfd/vUcQFPLQm95WeG0OdBn6JhVz0bo>
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: Tue, 23 Oct 2018 17:29:48 -0000

Hi,

So youā€™re saying there is a problem where the data plane interfaces do not support the configured MTU due to a SW bug? I hope these are not our routers šŸ˜‰

In scenarios involving L2 provider in between, I remember seeing such issues where the provider may silently drop frames of certain size that is less than MTU defined on the interfaces. If control plane like OSPF is stable, there is no way to detect using control plane.

Thanks,
Nagendra

From: Rtg-bfd <rtg-bfd-bounces@ietf.org> on behalf of "Acee Lindem (acee)" <acee@cisco.com>
Date: Tuesday, October 23, 2018 at 1:05 PM
To: Albert Fu <afu14@bloomberg.net>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
Subject: Re: BFD WG adoption for draft-haas-bfd-large-packets

Hi Albert,

Resending due to a related problem ā€“ message was too big for IETF filter and I pruned part of the thread at the end.

From: "Albert Fu (BLOOMBERG/ 120 PARK)" <afu14@bloomberg.net>
Reply-To: Albert Fu <afu14@bloomberg.net>
Date: Tuesday, October 23, 2018 at 12:45 PM
To: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>, Acee Lindem <acee@cisco.com>
Subject: Re: BFD WG adoption for draft-haas-bfd-large-packets

Hi Acee,

You are right in that this issue does not happen frequently, but when it does, it is time consuming to troubleshoot and causes unnecessary network downtime to some applications (e.g. between two end hosts, some applications worked fine, but others would intermittently fail when they tried to send large size packets over the failing ECMP path).

So youā€™re saying there is a problem where the data plane interfaces do not support the configured MTU due to a SW bug? I hope these are not our routers šŸ˜‰

I believe the OSPF MTU detection is a control plane mechanism to check config, and may not necessary detect a data plane MTU issue (since OSPF does not support padding). Also, most of our issues occurred after routing adjacency had been established, and without any network alarms.

Right. However, if the interface is flapped when the MTU changes, OSPF would detect dynamic MTU changes (e.g., configuration), that the control plane is aware of.

Thanks,
Acee

Thanks
Albert

From: acee@cisco.com At: 10/23/18 12:30:55
To: Albert Fu (BLOOMBERG/ 120 PARK ) <mailto:afu14@bloomberg.net> , rtg-bfd@ietf.org<mailto:rtg-bfd@ietf.org>, ginsberg@cisco.com<mailto:ginsberg@cisco.com>
Subject: Re: BFD WG adoption for draft-haas-bfd-large-packets
Hi Albert, Les,

I tend to agree with Les that BFD doesnā€™t seem like the right protocol for this. Note that if you use OSPF as your IGP and flap the interface when the MTU changes, youā€™ll detect MTU mismatches immediately due to OSPFā€™s DB exchange MTU negotiation. Granted, control plane detection wonā€™t detect data plane bugs resulting in MTU fluctuations but I donā€™t see this as a frequent event.

Thanks,
Acee


From: Rtg-bfd <rtg-bfd-bounces@ietf.org> on behalf of "Albert Fu (BLOOMBERG/ 120 PARK)" <afu14@bloomberg.net>
Reply-To: Albert Fu <afu14@bloomberg.net>
Date: Tuesday, October 23, 2018 at 11:44 AM
To: "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
Subject: RE: BFD WG adoption for draft-haas-bfd-large-packets

Hi Les,

Given that it takes relative lengthy time to troubleshoot the MTU issue, and the associated impact on customer traffic, it is important to have a reliable and fast mechanism to detect the issue.

I believe BFD, especially for single hop control-plane independent situation (btw, this covers majority of our BFD use case), is indeed an ideal and reliable solution for this purpose. It is also closely tied with the routing protocols, and enable traffic to be diverted very quickly.

The choice of BFD timer is also one of the design tradeoffs - low BFD detection timer will cause more network churns. We do not need extremely aggressive BFD timer to achieve fast convergence. For example, with protection, we can achieve end to end sub-second convergence by using relatively high BFD interval of 150ms.

In the case where the path will be used for a variety of encapsulations (e.g. Pure IP and L3VPN traffic), we would set the BFD padding to cater for the largest possible payload. So, in our case, our link needs to carry a mix of pure IP (1500 max payload) and MPLS traffic (1500 + 3 headers), we would set the padding so that the total padded BFD packet size is 1512 bytes.

As you rightly pointed out, ISIS routing protocol does support hello padding, but since this is a control plane process, we can not use aggressive timer. The lowest hello interval the can be configured is 1s, so with default multiplier of 3, the best we can achieve is 3s detection time.

What we would like is a simple mechanism to validate that a link can indeed carry the expected max payload size before we put it into production. If an issue occurs where this is no longer the case (e.g. due to outages or re-routing within the Telco circuit), we would like a reliable mechanism to detect this, and also divert traffic around the link quickly. I feel BFD is a good method for this purpose.

Thanks
Albert