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 >> >> >
- Re: [Idr] Review Request for draft BGP Overload amit bhagat
- Re: [Idr] Review Request for draft BGP Overload Robert Raszuk
- Re: [Idr] Review Request for draft BGP Overload amit bhagat
- Re: [Idr] Review Request for draft BGP Overload Robert Raszuk
- Re: [Idr] Review Request for draft BGP Overload amit bhagat
- Re: [Idr] Review Request for draft BGP Overload Robert Raszuk
- Re: [Idr] Review Request for draft BGP Overload amit bhagat
- Re: [Idr] Review Request for draft BGP Overload Robert Raszuk
- [Idr] Review Request for draft BGP Overload amit bhagat