Re: [Idr] WG LC for draft-ietf-bgp-route-oscillation-stop (4/6 to 4/20)

Daniel Walton <> Thu, 16 April 2015 13:44 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D176A1B319A for <>; Thu, 16 Apr 2015 06:44:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.378
X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 4jhI4qXvaWWA for <>; Thu, 16 Apr 2015 06:44:48 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c03::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 93FB91B3199 for <>; Thu, 16 Apr 2015 06:44:48 -0700 (PDT)
Received: by iebrs15 with SMTP id rs15so51540210ieb.3 for <>; Thu, 16 Apr 2015 06:44:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=EmuQ1ELEom4GfWadeG0MCGRtN+9Hol18TNSHd5Xh6+4=; b=IXbW3qL14vU5hH5Emu67hkE47nx2tHat+znIZ6uj6ZEgex5p7tveRLSEyX1Okx3dtb RZw1QZFTSTjObMzIk2SSiTnSLp7JWn74LoAhX+vz6nGl+X0J6uSS+iDw3GNO2/TskHQx hXCXTDWvaNusDkjdBgvGPyj3fsDkQKqaIAlxI=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=EmuQ1ELEom4GfWadeG0MCGRtN+9Hol18TNSHd5Xh6+4=; b=URymMh+cU0IqNSkxorKXSLu6Bd0BxPuVUTGThsp0O4dsjW3fB8GkTY0HRG4lhWVaSu YWZFviOIchyTZ1km1K+lkDEdoF/rrKn2qcs3bBh1PEsbabUgbEzQMN3XpJuU63kAjq10 HrlHnv0kdLlgWeMb4o0l9TkTmNMqD8YC6EOQGKKwNPSEz+JitVVwlDfbIkxgmTKUCSFW 4UV6KqpHy70OKYPoIGuV1jEUOeAUP+/hnVh9/zEpy8ms0DVM1FdUwwBqnqq806HaFfxc P1TbhIkYJ6gqzQITmm7hblsEFA21E37mX29qS7vCzKby6tcRKu1jFhwcSf8i/7NA1Ers 43JQ==
X-Gm-Message-State: ALoCoQk3opY0NiKXRjwOUAEEr1pu7sHNi3DKQj2PKjrq51GT5tmYVS8Y/DUjEta+MkHvgxJJiZkp
MIME-Version: 1.0
X-Received: by with SMTP id h8mr36720321icz.25.1429191888039; Thu, 16 Apr 2015 06:44:48 -0700 (PDT)
Received: by with HTTP; Thu, 16 Apr 2015 06:44:47 -0700 (PDT)
In-Reply-To: <>
References: <002e01d070ba$275479e0$75fd6da0$> <>
Date: Thu, 16 Apr 2015 09:44:47 -0400
Message-ID: <>
From: Daniel Walton <>
To: "Dongjie (Jimmy)" <>
Content-Type: multipart/alternative; boundary=90e6ba613ba6cd7f1f0513d7aa62
Archived-At: <>
Cc: idr wg <>, "" <>, Susan Hares <>
Subject: Re: [Idr] WG LC for draft-ietf-bgp-route-oscillation-stop (4/6 to 4/20)
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 16 Apr 2015 13:44:51 -0000

> “For the sake of scalability the advertisement of multiple paths should be
> limited to those prefixes which are affected by MED-induced route
> oscillation in a network carrying a large number of alternate paths.”
> How do the RRs or confederation ASBRs identify those prefixes affected by
> MED-induced oscillation?  Is there some rules or it is operator
> configuration?

The easiest way is to monitor how often the bestpath changes for a prefix.
If the bestpath for a prefix changes at some consistent interval that is a
strong indicator of MED churn.  The details for how an implemenation would
automaticaly do this are beyond the scope of the draft.  If you want to do
it manually the easiest way is to do "show ip route | grep " 00:00" which
will show you any route that is less than a minute old.  Do that a few
times and see which prefixes keep popping up.  This of course assumes that
the box you are on displays how long the route has been in the RIB :)

As for what that churn interval typically is, it varies depending on the
network.  When we first found MED churn we often saw an interval of 60s
becuase IOS would recalculate all bestpaths as part of the BGP Scanner
process which kicked off every minute by default.  Eventually the bestpath
recalc was removed from scanner and made event-driven so then the churn
would be constant...or as fast as the MRAI timers in the network would