[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Which Side to Control Ingress Link Selection?
Christian Vogt wrote:
one question that I think is worth being discussed more closely on
this list: Who should have control over which ingress link packets
reach a multi-homed edge network?
(a) the recipient edge network
[snip]
BGP-based traffic engineering, as used today, supports option (a), so it
seems natural to try and support this also in future routing systems.
But if we want to support option (a) with more scalable end-to-end
techniques, such as the exchange of reachability information in LISP,
then we need to ensure that all indirection routers (AKA Six/One routers
or LISP tunnel routers) in an edge network are aware of a remote edge
network's reachability status.
[snip]
(b) Sending reachability information to all indirection routers of a
sending edge network.
[snip]
- Option (b) has the nice property that it puts the burden of "synchro-
nizing" indirection routers to the edge network that has a benefit from
it, namely, to the edge network that is selecting its ingress link.
This segues nicely into a discussion on how to scale reachability
distribution.
I touch on it a bit in draft-dickson-rrg-v6dh, section 1.1.4.2 (Edge
reachability - routing announcements).
Here's the basic problem: reachability on any indirection router, is
generally aggregated
into reachability of a PA block in BGP. This effectively hides the
specific reachability
of individual indirection router.
Directly sharing reachability information (in the positive sense, "I am
reachable") between indirection
routers, is a huge N^2 problem, where the previous-discussed long-term
estimates on N are on the order of 10^8 or more.
Consider the following (imperfect) analogy:
In the early days of AM (amplitude-modulation) wireless (radio)
transmission, the "signal" was combined with the "carrier",
and the resulting mixture was amplified and transmitted.
Most of the energy in the system went into the "carrier", resulting in
very poor performance.
When the trick of suppressing the carrier signal itself from the
combined signal, all of the energy went into the side-bands.
Suppressing one of the two side-bands, resulted in Single Side-Band, or
SSB, radio. This allowed high-power radio
to be commercially viable.
The analogy I'm getting at is this: the default reachability state is
carried by the "carrier", which is the BGP PA prefix.
If the PA block is reachable, the presumption generally is that the
indirection router is reachable.
Then, the only additional information needed, is to distribute
information on whether and when, indirection routers
are *unreachable*.
Note Well: not every more-specific edge router within a PA block will be
an indirection router. The key comparison
that needs to be done is whether the general percentage of PA
more-specifics that are indirection routers, times the
percentage of more-specific routers that are currently unavailable, is
on par with or lower than, the aggregation factor
for PA blocks generally. Note also that in some instances, there may be
some ability to aggregate unavailable more-specifics.
If the number of (aggregated) indirection routers that are unavailable,
is smaller than the number of PA blocks, or at least of
the same order of magnitude, then this approach may be worth pursuing.
The scalability of, and mechanisms for, distributing this information is
something that likely fits well into BGP.
At the edge, from the BGP speaker to indirection routers, sending state
information on reachability, might fit well into some
kind of multicast scheme. E.g. join one multicast group to receive a
full table, join another to receive updates, and once state
is synchronized via the full table, exit the full-table group. This
scales well enough, presuming the availability of multicast - something
that is pretty much a requirement for IPv6, it could be observed.
Within the BGP system, a new AFI/SAFI would likely be needed to opaquely
pass the state.
The opaqueness means it would pass through the global DFZ, without being
used by DFZ routers (e.g. in their RIBs).
And the mechanisms to trigger unreachability announcements are pretty
much orthogonal to the existence of such
annoucements.
Would be interesting to hear other folk's opinions on who should have
control over which ingress link packets reach a multi-homed edge network,
especially from folks working at providers or operators of multi-homed
edge networks.
To use an oft-quoted expression, "routing sucks". Meaning, routing
advertisements
attract traffic, and only in the presence of routes does traffic get to
its destination.
My opinion is that, notwithstanding philosophical issues, the recipient
is ultimately
in control by virtue of being able to withdraw announcements. So, from a
pragmatic
perspective, it makes most sense to view (a) as the default choice.
It also matters that, for the most part, the recipient pays for delivery
of packets.
Hot-potato routing means ISP(sender) throws the traffic to the
ISP(recipient)
as soon as possible, meaning ISP(recipient) usually bears most of the
long-haul costs.
This in turn gets passed on to the recipient, in the form of the billing
model for traffic.
Brian Dickson
--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg