[rrg] BGP scaling limit

[Enke Chen]

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