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:[email protected]>>
* /To/: <tony.li at tony.li <mailto:[email protected]>>
* /Cc/: 'RRG' <rrg at irtf.org <mailto:[email protected]>>
* /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
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
