[GROW] Handling of LAGs in Mitigating Negative Impact of Maintenance through BGP Session Culling

Thomas King <thomas.king@de-cix.net> Tue, 09 January 2018 11:30 UTC

Return-Path: <thomas.king@de-cix.net>
X-Original-To: grow@ietfa.amsl.com
Delivered-To: grow@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 936271272E1; Tue, 9 Jan 2018 03:30:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.611
X-Spam-Level:
X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
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 r_BC1Mb-bl1I; Tue, 9 Jan 2018 03:30:42 -0800 (PST)
Received: from de-cix.net (relay4.de-cix.net [46.31.123.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F061F1200FC; Tue, 9 Jan 2018 03:30:38 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.46,335,1511823600"; d="scan'208";a="1264703"
Received: from smtp.de-cix.net ([192.168.65.10]) by mailgw014.de-cix.net with ESMTP; 09 Jan 2018 12:30:36 +0100
Received: from MS-EXCHANGE.for-the-inter.net (MS-EXCHANGE.for-the-inter.net [192.168.49.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by smtp.de-cix.net (Postfix) with ESMTPS id 4B701B00B8; Tue, 9 Jan 2018 12:30:36 +0100 (CET)
Received: from MS-EXCHANGE.for-the-inter.net (192.168.49.2) by MS-EXCHANGE.for-the-inter.net (192.168.49.2) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Tue, 9 Jan 2018 12:30:36 +0100
Received: from MS-EXCHANGE.for-the-inter.net ([fe80::9449:4d85:69bf:3d4c]) by MS-EXCHANGE.for-the-inter.net ([fe80::9449:4d85:69bf:3d4c%12]) with mapi id 15.00.1347.000; Tue, 9 Jan 2018 12:30:36 +0100
From: Thomas King <thomas.king@de-cix.net>
To: "grow@ietf.org" <grow@ietf.org>
CC: "draft-ietf-grow-bgp-session-culling@ietf.org" <draft-ietf-grow-bgp-session-culling@ietf.org>
Thread-Topic: Handling of LAGs in Mitigating Negative Impact of Maintenance through BGP Session Culling
Thread-Index: AQHTiT1EVmpr6uxEKUG4l9q8mMNj9A==
Date: Tue, 09 Jan 2018 11:30:35 +0000
Message-ID: <8BB20DB3-61E9-4CAC-B33B-B18CA12C2591@de-cix.net>
Accept-Language: en-US, de-DE
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.168.141.67]
Content-Type: text/plain; charset="utf-8"
Content-ID: <5DCC3109BAFC06409FE22EDC4A9D95EF@for-the-inter.net>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/grow/J31rm1eJ2qRweiIOD11LqRRuKPA>
Subject: [GROW] Handling of LAGs in Mitigating Negative Impact of Maintenance through BGP Session Culling
X-BeenThere: grow@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Grow Working Group Mailing List <grow.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/grow>, <mailto:grow-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/grow/>
List-Post: <mailto:grow@ietf.org>
List-Help: <mailto:grow-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/grow>, <mailto:grow-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 09 Jan 2018 11:30:44 -0000

Hi all,

we at DE-CIX are currently implementing BGP Session Culling and we hit the question how to handle LAGs (e.g. LACP, Static configured). The Internet Draft is not covering this question yet, however, from our point of view it is worth discussing it.

Our suggestion for handling LAGs looks like this:
Typically, a minimum number of port members can be defined for a LAG being up. The LAG is not touched by BGP Session Culling during a maintenance unless this number is undercut. If the number if undercut the LAG is handled by BGP Session Culling as defined in the Internet Draft.

If no value for the minimum number of active port members is defined for a LAG, the value 1 should be used as this is the behaviour of LAGs today already.

Best regards,
Thomas