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

From: "Susan Hares" <[email-masked]>
Date: Mon, 6 Apr 2015 18:36:41 -0400

This begins a 2 week WG LC for draft-ietf-bgp-route-oscillation. In your
comments about the readiness of the draft please include "support" or "no
support", and comment about the value of the draft. 

You can see the draft at: 

http://datatracker.ietf.org/doc/draft-ietf-idr-route-oscillation-stop/

Sue Hares and John Scudder

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Tue, 7 Apr 2015 04:16:55 +0000

support

From: Susan Hares
Date: Tuesday 7 April 2015 00:36
To: idr wg
Cc: "[email-masked]<mailto:[email-masked]>"
Subject: [Idr] WG LC for draft-ietf-bgp-route-oscillation-stop (4/6 to 4/20)

This begins a 2 week WG LC for draft-ietf-bgp-route-oscillation. In your comments about the readiness of the draft please include “support” or “no support”, and comment about the value of the draft.

---

From: "Russ White" <[email-masked]>
Date: Wed, 15 Apr 2015 16:24:11 -0400

> support", and comment about the value of the draft.

Support -- this draft is a valuable addition to the WG documents.

Russ

---

From: "Yi Yang (yiya)" <[email-masked]>
Date: Thu, 16 Apr 2015 04:17:38 +0000

+1.

Yi

On 4/15/15, 4:24 PM, "Russ White" <[email-masked]> wrote:

>_______________________________________________
>Idr mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/idr

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 16 Apr 2015 06:30:40 +0000

Yes/support

Cheers,
Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 16 Apr 2015 08:35:31 +0200

Support

Best,
r.

On Tue, Apr 7, 2015 at 12:36 AM, Susan Hares <[email-masked]> wrote:

> comments about the readiness of the draft please include “support” or “no
> support”, and comment about the value of the draft.
>
>
>

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Thu, 16 Apr 2015 08:45:10 +0000

Support.

And one minor comment:

In section 3 and section 6 it says:

"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?

Best regards,
Jie

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Tuesday, April 07, 2015 6:37 AM
To: idr wg
Cc: [email-masked]
Subject: [Idr] WG LC for draft-ietf-bgp-route-oscillation-stop (4/6 to 4/20)

This begins a 2 week WG LC for draft-ietf-bgp-route-oscillation. In your comments about the readiness of the draft please include "support" or "no support", and comment about the value of the draft.

---

From: Daniel Walton <[email-masked]>
Date: Thu, 16 Apr 2015 09:44:47 -0400

>
> “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
allow.

Daniel

---

From: "Susan Hares" <[email-masked]>
Date: Mon, 20 Apr 2015 00:59:16 -0400

Daniel: 

Do you see any current changes in the churn level?  Have you examined the churn inside of a datacenter?

Sue 

From: Daniel Walton [mailto:[email-masked]] 
Sent: Thursday, April 16, 2015 9:45 AM
To: Dongjie (Jimmy)
Cc: Susan Hares; idr wg; [email-masked]
Subject: Re: [Idr] WG LC for draft-ietf-bgp-route-oscillation-stop (4/6 to 4/20)

“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.”

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 allow.

Daniel

---

From: Daniel Walton <[email-masked]>
Date: Tue, 21 Apr 2015 10:42:21 -0400

> churn inside of a datacenter?

Most customers I worked with that hit MED churn were hitting the Type I
variety (details in rfc3345) and solved it by increasing the IGP metrics
between their clusters or confed sub-ASes.  UUNET was the big exception,
they used confederations and were hitting Type II churn but it wasn't
painful enough for them to make changes to stop it as the changes needed
were fairly dramatic. UUNET's churn was one of the big drivers for doing
add-path.

I haven't run into MED churn in the data center yet.  Many of our data
center customers use BGP without an IGP which eliminates one of the
variables needed to cause the churn.

Daniel