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.