[rrg] BGP scaling limit

[Enke Chen]

BTW, the MED setting could also be based on the normalized metric.  For 
example:

           IGP metric                     MED
          --------------------------------
             0-20                               10
            21-40                              20
            41-100                            30
            ...

-- Enke

Enke Chen wrote:
> Hi, Danny:
>
> Just saw this email as I am not on the IRTF mailing list:
>
> Excerpt from the email:
>
> ------------------------------------------------------------------------------ 
>
>
> I don't agree with this.  Offer me an alternative for 10 or
> more interconnections between the largest networks today?
> Offer me an alternative for how those paths and the current
> inter-domain routing protocol amplify (not minimize) the number
> of paths.
> -----------------------------------------------------------
>
> Here is what I (Enke) am thinking:
>
> I do agree that the current operational model of doing shortest-exit
> (and thus resulting in path multiplications) has scalability concerns,
> especially with the increase in the number of peering locations between
> providers.
>
> 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.
>
> Any comments?
>
> -- Enke
>      
>    * /From/: Danny McPherson <danny at arbor.net
>      <mailto:danny at DOMAIN.HIDDEN>>
>    * /To/: <tony.li at tony.li <mailto:tony.li at DOMAIN.HIDDEN>>
>    * /Cc/: 'RRG' <rrg at irtf.org <mailto:rrg at DOMAIN.HIDDEN>>
>    * /Date/: Mon, 12 Jan 2009 14:01:24 -0700
>
> ------------------------------------------------------------------------
>
> On Jan 12, 2009, at 10:34 AM, Tony Li wrote:
>
>     
>    As you point out, this is more to do with the specific protocol than
>    it is to do with the overall routing architecture. As such, this is
>    why it's
>
>    really much more of the domain of IDR than RRG.
>     
> Well, so long as the folks designing the next generation
> understand the problem and mitigate the constraints.  I'm
> not totally sure the former is the case, which has effects
> on the latter.
>
>
>    BTW, AFAIK, route reflection _reduces_ the number of paths as
>    compared to
>
>    full-mesh IBGP.  Am I missing something?
>     
> Depends on the number of RRs, where the best path
> is, network architecture, etc..  The growth curves
> I've seen (wFrom rrg-bounces at irtf.org  Mon Jan 12 13:01:51 2009
>
>
>
> On Jan 12, 2009, at 10:34 AM, Tony Li wrote:
>
>     
>    As you point out, this is more to do with the specific protocol than
>    it is to do with the overall routing architecture. As such, this is
>    why it's
>
>    really much more of the domain of IDR than RRG.
>     
> Well, so long as the folks designing the next generation
> understand the problem and mitigate the constraints.  I'm
> not totally sure the former is the case, which has effects
> on the latter.
>
>
>    BTW, AFAIK, route reflection _reduces_ the number of paths as
>    compared to
>
>    full-mesh IBGP.  Am I missing something?
>     
> Depends on the number of RRs, where the best path
> is, network architecture, etc..  The growth curves
> I've seen (which I hhich I hope to be able to share soon)
> illustrate that the number of iBGP paths is growing
> at anywhere from 6-14x the rate of the DFZ, and
> the reason is because of external factors, protocol
> design issues, and implementations.
>
>
>    Paths that are introduced for the sake of traffic engineering are a
>    well
>
>    understood and self-inflicted problem.
>     
> Really?  So a multi-homed AS is TE?  So networks that interconnect
> in 10 places result in 10 paths for each prefix and that's self-
> inflicted?  What's the alternative to avoiding this self-inflicted
> pain?
>
>
>     If those folks that introduced the
>    extra paths took equivalent interest in limiting their dispersion and
>     
>    cooperated in filtering unnecessary long prefixes, this could
>    readily be
>
>    addressed.
>     
> No, I'm not talking about just extraneous or covered prefixes,
> that's only a tiny part of the problem I'm referring to.
> Denseness of external interconnection, unique attributes,
> BGP as defined today AND TE have effects on these, I'd say the
> latter the least.
>
>
>     In short, this is not an issue with the fundamental
>     
>    architecture, it's about how the architecture is being used. Thus,
>    this is
>
>    largely an operational issue.
>     
> I don't agree with this.  Offer me an alternative for 10 or
> more interconnections between the largest networks today?
> Offer me an alternative for how those paths and the current
> inter-domain routing protocol amplify (not minimize) the number
> of paths.
>
>
>    Further, if we did something to fundamentally remove the capability to
>     
>    traffic engineer in the future, I strongly suspect that that would
>    be an
>
>    architectural issue, most likely fatal.
>     
> Again, TE is only a tiny part of the problem I'm referring
> to here - fully dependent on ones definition of TE, of course.
>
> -danny
>
> _______________________________________________
> rrg mailing list
> rrg at irtf.org
> http://www.irtf.org/mailman/listinfo/rrg
>
>
> ope to be able to share soon)
> illustrate that the number of iBGP paths is growing
> at anywhere from 6-14x the rate of the DFZ, and
> the reason is because of external factors, protocol
> design issues, and implementations.
>
>
>    Paths that are introduced for the sake of traffic engineering are a
>    well
>
>    understood and self-inflicted problem.
>     
> Really?  So a multi-homed AS is TE?  So networks that interconnect
> in 10 places result in 10 paths for each prefix and that's self-
> inflicted?  What's the alternative to avoiding this self-inflicted
> pain?
>
>
>     If those folks that introduced the
>    extra paths took equivalent interest in limiting their dispersion and
>     
>    cooperated in filtering unnecessary long prefixes, this could
>    readily be
>
>    addressed.
>     
> No, I'm not talking about just extraneous or covered prefixes,
> that's only a tiny part of the problem I'm referring to.
> Denseness of external interconnection, unique attributes,
> BGP as defined today AND TE have effects on these, I'd say the
> latter the least.
>
>
>     In short, this is not an issue with the fundamental
>     
>    architecture, it's about how the architecture is being used. Thus,
>    this is
>
>    largely an operational issue.
>     
> I don't agree with this.  Offer me an alternative for 10 or
> more interconnections between the largest networks today?
> Offer me an alternative for how those paths and the current
> inter-domain routing protocol amplify (not minimize) the number
> of paths.
>
>
>    Further, if we did something to fundamentally remove the capability to
>     
>    traffic engineer in the future, I strongly suspect that that would
>    be an
>
>    architectural issue, most likely fatal.
>     
> Again, TE is only a tiny part of the problem I'm referring
> to here - fully dependent on ones definition of TE, of course.
>
> -danny
>
> _______________________________________________
> rrg mailing list
> rrg at irtf.org
> http://www.irtf.org/mailman/listinfo/rrg
>
>