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

Job Snijders <job@instituut.net> Tue, 09 January 2018 15:50 UTC

Return-Path: <job@instituut.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 DF860126D0C for <grow@ietfa.amsl.com>; Tue, 9 Jan 2018 07:50:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=instituut-net.20150623.gappssmtp.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 LJnTQddYzUzv for <grow@ietfa.amsl.com>; Tue, 9 Jan 2018 07:50:43 -0800 (PST)
Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1341D129516 for <grow@ietf.org>; Tue, 9 Jan 2018 07:50:42 -0800 (PST)
Received: by mail-wm0-x22f.google.com with SMTP id i11so21483172wmf.4 for <grow@ietf.org>; Tue, 09 Jan 2018 07:50:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=instituut-net.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=I55ZrYvkjBAmGanBmxIUnvFfkqNHpDVk7VbXyRwzJyg=; b=PSZ3yE9KullrsT9ERvhlEncPKx1RURgVCLBVHSJ/wLl21zllQOH9yJYNr7JySbGV7x iwVfHALvL8z3m+lwZtQcSxVaL29PbLQ77+9Toe727jwbjK+b85AfQ9cpmflCJ2QVE/ON yGvOPYVQJqf+zJboO4FLbRqwI/nJutqCwrvSzvvymbdrWHrDXirSBihlFi47nnT8/7ot y1KLPVbD2tdO2G4SGmdKB3oBrwAubvp6XBcuIXJ4a7HWm6QCzhWLTYEs6+8Ing1frEaO G65yruBriIAaM2CBjZ7l8QjUAjO5wqMmZXwXtk5ardMSF7eu2IlyAccxa/FmQZ7p4Xj6 Roqg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=I55ZrYvkjBAmGanBmxIUnvFfkqNHpDVk7VbXyRwzJyg=; b=DUGqPDSN1Ip2kN3DrkUR37CzTBYK13A72dMl6ofTKN8EmFKVENthCOpy+SJ5u7NiGC 5WbxJ3iwjeUKPJtO7q6KjJXJe7tIww+zGhwmm4xk6ifzcgWuB+V2Zuzrsry84vg+KLzk 1MJMUJhqzNIxVq64o7GVP/iUJqoppYGjSZ6yTYcnVt4aUwFgxcAQljgYILnbCuhffZ4e Krc0gH9mNbsgY9ZLptuWVSbCZnWKkl6WwzTCbNbdpT4i9oig7ligedcy+xj08cqDYEL3 ZlAUojzV+sJ1GQhKdLp9HIGc4wt6FvkhSxkor3tq/FWZukszA32uRa7ynXkzLNioE3rl pg1Q==
X-Gm-Message-State: AKwxyteLd5rc7YJ3uJdzCANXJCK6iCFFm6x/hxTBJg7WxjDUIPzTUBKq 22b2dKSVwcBxHIUvEWsHbJwfww==
X-Google-Smtp-Source: ACJfBot2k/3zGRspNIhsZPOgsPeHXgUpg/xkwa1rMq7GKasNvr5+7sr1zzBuW6jEnxU6pW63/XgA/A==
X-Received: by 10.80.246.21 with SMTP id c21mr3566116edn.271.1515513041257; Tue, 09 Jan 2018 07:50:41 -0800 (PST)
Received: from vurt.meerval.net (vurt.meerval.net. [192.147.168.22]) by smtp.gmail.com with ESMTPSA id z102sm8178511ede.29.2018.01.09.07.50.39 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 09 Jan 2018 07:50:40 -0800 (PST)
Received: from localhost (vurt.meerval.net [local]) by vurt.meerval.net (OpenSMTPD) with ESMTPA id 2f2e6d6d; Tue, 9 Jan 2018 15:50:39 +0000 (UTC)
Date: Tue, 09 Jan 2018 15:50:39 +0000
From: Job Snijders <job@instituut.net>
To: Will Hargrave <will@harg.net>
Cc: Thomas King <thomas.king@de-cix.net>, grow@ietf.org, draft-ietf-grow-bgp-session-culling@ietf.org
Message-ID: <20180109155039.GD59807@vurt.meerval.net>
References: <8BB20DB3-61E9-4CAC-B33B-B18CA12C2591@de-cix.net> <20180109113506.GA99435@vurt.meerval.net> <53E19D26-D4C0-4722-8CFE-FDC5BF5C3FBC@harg.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <53E19D26-D4C0-4722-8CFE-FDC5BF5C3FBC@harg.net>
X-Clacks-Overhead: GNU Terry Pratchett
User-Agent: Mutt/1.9.2 (2017-12-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/grow/1H30kxE7e1QN_5bRi3EfOoX9d-U>
Subject: Re: [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 15:50:45 -0000

On Tue, Jan 09, 2018 at 03:34:46PM +0000, Will Hargrave wrote:
> On 9 Jan 2018, at 11:35, Job Snijders wrote:
> > > 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.
> >
> > Is this in context of multi-chassis LAG?
> 
> I think if we include anything about LAGs we should make it very clear
> that you must apply the culling ACL to *either* all ports of a LAG
> *or* none.  Applying it to half of an MCLAG could be disastrous.

Will, my reading of Thomas' message is slightly different, I don't think
he is proposing to apply culling ACLs on half the ports of a LAG, he
proposes that culling ACLs are only applied (to all ports) when more
than X members of a LAG will be impacted by the maintenance (where X is
an ixp-participant configurable number).

> I didn’t realise there were IXPs using MC-LAG. Discovering this maybe
> surprise some members.

Thomas, in terms of IETF logistics, the RFC-To-Be draft-ietf-grow-bgp-session-culling
document has already been submitted to the RFC Editor and is in the
queue, information on LAGs cannot be added at this point to the
publication.

However, since this is a BCP, the next iteration could include
additional information as our understanding of the culling practise
improves, and the BCP number wouldn't change of course.

>From what I read in your message your organisation is still in the early
phases of applying the 'culling' mechanism. I recommend you to (over
time) carefully take notes of the interaction between LAG and culling,
and whatever arises as the best current practise is documented in the
next revision of the BCP.

Kind regards,

Job