Re: [Idr] Review Request for draft BGP Overload

amit bhagat <scet.amit@gmail.com> Tue, 05 July 2016 22:12 UTC

Return-Path: <scet.amit@gmail.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 B2D3212D0FC for <idr@ietfa.amsl.com>; Tue, 5 Jul 2016 15:12:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 YMzqj1JctlnB for <idr@ietfa.amsl.com>; Tue, 5 Jul 2016 15:12:50 -0700 (PDT)
Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (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 2905D12B05B for <idr@ietf.org>; Tue, 5 Jul 2016 15:12:50 -0700 (PDT)
Received: by mail-qt0-x236.google.com with SMTP id w59so108386329qtd.3 for <idr@ietf.org>; Tue, 05 Jul 2016 15:12:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=N+RRo9COZe1xK5SDynWyJPu3iU63gWSJb2AgjNa5YFU=; b=IpReQ+aReWn0tRAYXk1vlphS6bt5pObCfm9YDw4IQ1lUzCtbHF7i884ijLcn9ysOyV SAGBLlmRfmuvXxYvIZDK9ioOXa0vAYk0BrDycM/5RYz5LvSLouIuf3fxQ/b/uK3S2BTd 8+2Zv0tnREkhUzzpPjWzo/lMIeUYGAXnmBve6SqSnZ2/CoJ7ctQsXDnBwOQunkE68f2A uMMm4+aEjd/hlPE5yGMk9Hf6F+mMpoEgflCmYDtjMl4p9fWW7r65mjieNWb+CI1ZdfcX I7tYJJ3z0PmGsSE0vlEJMRMN3b/jTtWK2W2ylQ4bX2GcPfrT8MSZ/BUZgD9+g/BY8huX cLhA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=N+RRo9COZe1xK5SDynWyJPu3iU63gWSJb2AgjNa5YFU=; b=l2RMc1CpKIxWDCKS1joUEF0GPCXXvAGJvXkz+rqu81QXQQxGSpsm9DIObgjOpBUWYh 2FQAJ/snw29LOFLyEraReLwJT8sm0I07ntMMora3hvPyzgeNzKjsMYHYmiUhDNxOA0Qx ViQ0CBoM5raAhb3AowzGYKRh298G39uDI5xVJECjoPM3ZRNQDSDTGJAMHBoN9x3eVCNy Gukv24jJyTfzCkMGVLRCEenWnc1ip04Dnlt/cL4zROewjP6i/Cb0CyLvQWdR6fhZ3Lbn +iK/X9mhXncsGW3Z3iSyA2BIZ96WTQk28s2EOXzgQdINTpreGakFpTRyeP3b4K1qDWLg g2Xw==
X-Gm-Message-State: ALyK8tI3clP29H7RRbQcIzXhkLjSAE/Gx6mfAC4CYRlvMem3BbQVP8hGAj3EUbfZrj1U+Qg8N2bu0JcB81szgg==
X-Received: by 10.200.49.165 with SMTP id h34mr31129188qte.43.1467756769325; Tue, 05 Jul 2016 15:12:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.43.232 with HTTP; Tue, 5 Jul 2016 15:12:48 -0700 (PDT)
In-Reply-To: <CA+b+ERnOgiq3g+oCp-3vx1Ncq8QSrf-32Go_RWDeO+P7VHUNRA@mail.gmail.com>
References: <CADJmATHTYEW3_S+8=wLmjYL35oPF24J+Tu9O+m7w_7uLUMghjQ@mail.gmail.com> <CA+b+ERnOgiq3g+oCp-3vx1Ncq8QSrf-32Go_RWDeO+P7VHUNRA@mail.gmail.com>
From: amit bhagat <scet.amit@gmail.com>
Date: Tue, 05 Jul 2016 15:12:48 -0700
Message-ID: <CADJmATGndK0s-8Pao3cp7DfubsBFc1FG+LgMh-5NUJ32HAsvFg@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
Content-Type: multipart/alternative; boundary="001a11c10850da391e0536eac0c7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/9JUn8Gg2rdEjtk3eqpOMZ0zT2-s>
Cc: idr wg <idr@ietf.org>
Subject: Re: [Idr] Review Request for draft BGP Overload
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
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: Tue, 05 Jul 2016 22:12:53 -0000

Hi Robert,

Many thanks for your comments.

Initially, I thought about using a community but that would mean putting
all NLRIs in the Update message. This could also mean a different Update
per-neighbor/per-peergroup.

re: G-shut community - Reading through G-shut draft, it seems to be
targeting a single use case - maintenance. Additionally, it requires manual
configuration of route-policies. The way I envision this is a simple Update
that is applicable to all peers; no need to worry about manipulating any
BGP attributes.

re: new SAFI - The reason for requesting a new SAFI is so that a new NLRI
encoding can be defined to keep it simple. The existing SAFI would require
adding NLRIs to the Update message.

re: BGP session distinction - Is there a need to identify IBGP or EBGP
session? Perhaps I am missing something.

re: Global mode - the use case would be if a BGP speaker has multiple links
to different peers and running different AFI/SAFI pairs per links, it might
be just easy to drain a particular type of traffic rather than ALL traffic.

Additionally, one of the other use cases I am thinking of is when a BGP
speaker drops its Established neighbor-count below a threshold, it can
advertise itself as "Overloaded". This can help avoid congestion. Agreed,
this can also be the cause of network outage, but within a CLOS fabric, it
should not be a problem due to multiple paths.

Again, thanks for reviewing.

Amit.

On Tue, Jul 5, 2016 at 12:39 PM, Robert Raszuk <robert@raszuk.net> wrote:

> Hi Amit,
>
> In an essence it seems that your proposal is just a subset of "Graceful
> BGP session shutdown"
> https://tools.ietf.org/html/draft-ietf-grow-bgp-gshut-06.
>
> Can you clarify how your encoding is any better then proposed by Pierre's,
> et al. G-Shut community?
>
> Why do you need a new SAFI for it ? Would it be easier to use community or
> attribute and send it over existing SAFIs ?
>
> How in your encoding one can distinguish IBGP sessions from EBGP sessions
> (case of core or edge line card replacement) ?
>
> What is the use case to not use "global" mode .. ie. when do you envision
> need to signal overload for only subset of AFI/SAFIs carried by given BGP
> speaker ?
>
> Many Thx,
> Robert.
>
>
> On Tue, Jul 5, 2016 at 9:25 PM, amit bhagat <scet.amit@gmail.com> wrote:
>
>> Hey All,
>>
>> We are looking for your comments on the new draft
>> https://datatracker.ietf.org/doc/draft-bhagat-bgp-overload/
>>
>> We would really appreciate any comments and questions about the document.
>>
>> Best Regards,
>>
>> Amit Bhagat
>>
>>
>>
>> _______________________________________________
>> Idr mailing list
>> Idr@ietf.org
>> https://www.ietf.org/mailman/listinfo/idr
>>
>>
>