Re: [Idr] Review Request for draft BGP Overload
Robert Raszuk <robert@raszuk.net> Wed, 06 July 2016 07:34 UTC
Return-Path: <rraszuk@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 B348412D6AE for <idr@ietfa.amsl.com>; Wed, 6 Jul 2016 00:34:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.4
X-Spam-Level:
X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.198, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=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 X_YsxXcllR1Q for <idr@ietfa.amsl.com>; Wed, 6 Jul 2016 00:34:57 -0700 (PDT)
Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::229]) (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 0175A12D6A1 for <idr@ietf.org>; Wed, 6 Jul 2016 00:34:56 -0700 (PDT)
Received: by mail-lf0-x229.google.com with SMTP id f6so149074429lfg.0 for <idr@ietf.org>; Wed, 06 Jul 2016 00:34:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=aGNT42wL8LNBYDUF1abStR/WnTLa6MBlKsDAnHFGCT8=; b=RPR/P6XLP68qR39sQawm84EOcdwxtvWEc43uOPvtdAyJI//XDrBri4suE/OOGFUTEL KYLjY3nEw8IHbJpMMjYZWkZky4i2YJw2mXvUj9R+qh8llUcQxs+Dd4ogqxKfHvIZ2Hcl umNugQrtcz4osWtN0JBWlWs3XC+h0D+35VXzJkKH7dTsqbC21rRlSXLsMZSxeFF3Aij1 eeu1aTnCAIBVusT6Imq5f4LVpjDQJ7rzwitMzPga5oXlAv9ijYZ8UQg97DhzZM2s1LDH kS6mz+jqZreKpPKgr/WJiSeGCJoF1XR1NBZcIZg6VPlU1goJOLOyhpSX83fZu9oT5Yxm jOQA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=aGNT42wL8LNBYDUF1abStR/WnTLa6MBlKsDAnHFGCT8=; b=lnc7y/i6KGnVpjKR3wEACnWRvGYK3cEVqqe5wuDSFjKJAka6cjDdff9cV3GR73hBRV NY06repvp+BCvm3zmfL2Dubw7yYCfdMOTZ4L8pS0jjLGo9ktfMFgj6HC7SIyPoyYPRoD /l1XuFAgOgqGaGTtDqjMX5c0xYgovlpNPTRC2IPbdg+qvN+W+YTo+bht+4YNzHuwYFoN Bkg1dujB+Zh657qURdHaADqxdC8MEkhMKWPtfToWrZ9HC0WQ/5QLe0gtXUzB8wQ/fhPp 5kTi6x0khY4TzyDYUxzm2dfffvT0AsNtAwukzWxbbVRP5V959eWOknxASRScL0BewtmQ T+dA==
X-Gm-Message-State: ALyK8tJiIA+IWm6LVEDOD2Nwjc7zMgWoCUe1LLyl9fmtctm5/nZ8qmqjbvAsgi/t0LFFVuJKSwV1S4MhODpqcQ==
X-Received: by 10.25.18.35 with SMTP id h35mr4494316lfi.82.1467790494888; Wed, 06 Jul 2016 00:34:54 -0700 (PDT)
MIME-Version: 1.0
Sender: rraszuk@gmail.com
Received: by 10.25.21.30 with HTTP; Wed, 6 Jul 2016 00:34:54 -0700 (PDT)
In-Reply-To: <CADJmATFqusgXiMAzQrCqMczkcGkNaLiKcOMu3k7-N_pMjoOMGg@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> <CADJmATGndK0s-8Pao3cp7DfubsBFc1FG+LgMh-5NUJ32HAsvFg@mail.gmail.com> <CA+b+ER=-_omoqvM_=nqhzm_D1HB8-Wp+0ixadwaRa-7URKbHWQ@mail.gmail.com> <CADJmATFqusgXiMAzQrCqMczkcGkNaLiKcOMu3k7-N_pMjoOMGg@mail.gmail.com>
From: Robert Raszuk <robert@raszuk.net>
Date: Wed, 06 Jul 2016 09:34:54 +0200
X-Google-Sender-Auth: rKutAckwRy2Risr48d3wYqYOL7o
Message-ID: <CA+b+ERnyNk1ZSA_mu+VnRTthpCibzGGN8SCeEaSoPZq1wHNzYA@mail.gmail.com>
To: amit bhagat <scet.amit@gmail.com>
Content-Type: multipart/alternative; boundary="001a113fbed20d775e0536f29b78"
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/htjFZ6yQqu7I-H4Fv1meD-vPNE0>
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: Wed, 06 Jul 2016 07:35:00 -0000
Hi Amit, I agree that recently BGP is being stretched towards DC-fabric side to > encompass various use cases. > > However, the way I see this draft, it can be useful for both, Internet and > DC-fabrics. The main reason is to keep traffic drain procedure BGP topology > agnostic, exactly same as ISIS Overload-bit. Agree, BGP has a bigger blast > radius in Internet compared to ISIS but appropriate implementation of the > feature can provide good benefits. > I don't think this is about "blast radius". ISIS or OSPF are link state protocols and each node in the given flooding scope computes its independent SPF hence flooding such information is a necessity for consistent forwarding. Contrary to the above BGP is path/distance-vector where each BGP speaker recomputes its bRIB and re-advertises it. Therefor for the use case you have in mind all what is required is to signal in some way to a bgp peer(s) that you may not want or want again to be in forwarding for a given SAFI. You defined a new SAFI as well as new NLRI format to use for point to point signalling .. I am not convinced this is the right level of signalling choice for this purpose. How do you stop propagation of such NLRIs around ? It would be pretty harmful if one router in Clos fabric will leak it and it breaks entire fabric - wouldn't you agree ? You at very min MUST enforce the NO-EXPORT/NO-ADVERTISE semantics for such SAFI which currently your draft seems to be missing. There are couple of alternatives to accomplish the same though: - using flag in dynamic capabilities - local poisoning of next hops - use of local pref/med (same as OSPF max metric:) - use of G-shut community or simply shutting the SAFIs. When you shut SAFI in one shot all paths learned are removed and best path (or multipath) recomputed. The potential "hit" would be on re-enabling it such that you need readvertise your underlay again. It is gracefull (no packet drops) as local forwarding can continue till everyone around stops sending you packets in a given table_id (corresponding to SAFI which has been shut down). Many thx, R.
- 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