[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