On Wed, Sep 8, 2010 at 1:37 AM, Fred Baker <f...@cisco.com> wrote: > > On Sep 8, 2010, at 1:02 PM, Christopher Morrow wrote: > >> this all gets 'crazy', I suppose if we wanted to route on flow-label >> not destination-ip-address this might happen, but ... that seems >> 'crazy' as I said before :) since not everyone would be using the >> flow-label (maybe) and inconsistent routing would suddenly make the >> internet look a lot like a PSTN network (to me). > > well, we could talk about MPLS... that has always seemed to me a might > PSTN-ish.
yea... sad, eh? (but handy at times, sadly) > > My presumption here is that flow label routing would be within a single > administration or a set of consenting administrations, and as such would not > be affected by whether neighboring administrations chose to use it r chose > how to use it. > ah! I missed the 'single admin domain' part in the original message. Inside a single admin-domain sure, this looks like mpls without the mpls-label, maybe that's an advantage, maybe not. > One example of a use case for it is in the IAB-TE.pdf deck (google that, it's > under iab.org somewhere) that Jason Schiller used in the IAB Routing Workshop > a few years back. One of the questions was how to simplify this case: We have > N+1 ISPs, one that is in a bad way and N others trying to get data to it. > They are interconnected by some number of undersea cables (and therefore > lambdas), which are in turn operated by multiple administrations. > yup, the latam example. > ,-------. ,-------. > ,-' `-. ,-' `-. > / ISP #1 \ / ISP #2 \ > ( ) ( ) > \ / \ / > `-. ,-' `-. ,-' > `-------' || || `-------' > || || > Undersea|| ||Undersea > Cable|| ||Cable > Network|| ||Network > || || > ,-------. > ,-' `-. > / \ > ( ISP #3 ) > \ / > `-. ,-' > `-------' (nice art!) > ISP #3 has a problem; due to the issues of laying undersea cable, "just add > bandwidth" is a lot more easily said than done. The total amount of traffic > destined to it approximates the capacity of the cables/lambdas in use, but of > course varies in composition over time. As a result, ISP #3 is forever > gerrymandering /24s to bias traffic towards one link or another. ISPs #1 and > #2 go slightly mad with route flaps as a result. > > What I am about to describe doesn't solve load spreading across ISPs #1 and > #2. But, for the traffic that arrives at let's say ISP #1, if its ingress > nodes were each given permission to route traffic for ISP #3 to one of the > relevant cables/lambdas up to some rate, and then to a second cable/lambda up > to some rate, and so on. The sum of the rates granted to the ingress points > is less than or equal to the rate of the cable/lambda in question. What this > means is that ISP #1 is in control of its own routing without being > micromanaged by the ISP downstream, and can sell a service to ISP #3 of > delivering the indicated data in a manner that is reasonably load balanced > across the cables/lambdas connecting them. > seems crazy still (still managing state somewhere), but I grant the example works out in principle. As you say below, today this is done with mpls or other encap technologies (or could be), using something NOT encap'd sounds like a win. > One could just as easily imagine doing that with MPLS; the point is to have > an appropriate set of tags. I just happen to not be fond of circuit or > virtual circuit networks, and I think this doesn't require the explicit N^2 > problem implied by a mesh of LSPs. thanks! (that clarifies it for me, and I hope gets us out of a rathole) -Chris -------------------------------------------------------------------- IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
