Gentlemen,
This discussion is strictly out of scope for RRG. This is about BGP internals, not about routing and addressing architectures. Please take it to IDR, where it would be most appropriate. Regards, Tony |-----Original Message----- |From: Enke Chen [mailto:[email protected]] |Sent: Thursday, February 05, 2009 8:39 PM |To: Danny McPherson |Cc: [email protected]; [email protected]; Enke Chen |Subject: Re: [rrg] BGP scaling limit | |Danny McPherson wrote: |> |> On Jan 31, 2009, at 10:17 PM, Enke Chen wrote: |>> |>> So here is an alternative (operationally): |>> |>> accept MEDs from each other and perform longest-exit. |>> |>> The MEDs could be set by the sender based on the location |(community) |>> so that at most 2 or 3 peering locations would advertise the same |>> MED. |>> |>> For example, for a particular prefix originated from New York: |>> |>> Peering Location MED |>> ----------------------------- |>> New York / DC 10 |>> |>> Chicago/ Denver 20 |>> SFO / LA 30 |>> ..... |>> |>> The location/community based route-map should be uniform (i.e., |>> identical) at the peering |>> locations. |>> |>> This approach should reduce the number paths significantly, and yet |>> maintain redundancy |>> and convergence properties in a network. |> |> The increasing number of interconnections will still be |> necessary, and the number of internally amplified routes |> will grow accordingly. With each BGP speaker or Route |> Reflector set/cluster MEDs would possibly decrease the |> number of routes contained in the core (as every router |> wouldn't default to advertising the local paths as best) |> but it only marginally improves the problem, which is still |> highly topologically dependent and constrained by the |> current BGP internal scaling model. | |Marginally??? The approach reduces the number of paths to be |a constant |(chosen by a provider) from being proportional to the number of peering |locations. | |> |> Furthermore, MEDs trigger lots of other badness (e.g., |> oscillation), require inter-provider coordination and |> normalization (e.g., with different IGPs and metric space, |> internal metric allocation models and multipliers vary |> considerably, etc..), can make peer gaming much simpler, |> and are usually broken when considering routes originated |> in multiple locations from an adjacent peer AS. | |The actual metrics/MED do not require coordination between providers. |What is needed is for the providers to accept the metric/MED from |each other. | |MED induced oscillation is a concern, but it is rare. | |> |> I.e., MEDs should turn closest-exit (hot potato) routing |> into best-exit routing (cold potato/?), but in my experience |> most often result in mashed potato routing (e.g., S 7.1.1 |> of RFC 4277). | |It is all about tradeoffs. As you might remember, InternetMCI used to |accept MEDs from other providers and it worked just fine | |-- Enke |. | | _______________________________________________ rrg mailing list [email protected] http://www.irtf.org/mailman/listinfo/rrg
