-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
I started off a thread I can't keep up with. :-) I'm going to try and summarize a bunch of things here, in one email. >> Clark: "There are clearly two classes of network entities, subscribers >> and providers; there may be a gray area but that is not important." > > I think this is a slight misstatement. There _are_ clearly two classes > of ASes: transit and leaf. It's easy to tell which are which, and the > vast majority of growth is in the latter. This is precisely what I question. I've provided some examples below, so as not to make the main text here too long, but, IMHO, the main area of growth in the 'net today is in AS' which have the characteristics of both a transit and a leaf. >> If they do, then with what granularity do they care? Traditionally, >> traffic engineering is done to the granularity of the reachable >> destination. > > Nit: it's traditionally done to the granularity that one can get peers > to accept prefixes for groups of destinations. Right--the smallest block of reachable destinations, today, is the longest prefix your peer will accept. > The EID-to-RLOC mapping can be far more granular since it doesn't impact > routing tables; you can give individual EIDs different mappings if > desired. This is far superior for destination-based TE than what we have > today, where you have to apply BGP-based TE to an entire /24 or even /20. Doesn't this increase the size of the Locator table, over time, to be precisely the size of the EID table? There appear to be several drivers in place to push more discrete routing into the fore--again, see below the sig for instances. The net result is granularity ends up at the host level, or perhaps below, at the flow level. I'm not certain mapping helps this--because mapping assumes that once you hit the leaf/transit divide, the granularity levels automatically decrease. I'm concerned this no longer true--the 80/20 rule is in it's last gasps, I think, and we have to figure out how to work in a world with 20/80, maybe, or 100/100, in some sense. It's easy to say: "We'll map at the edge, and then aggregate the space we're mapping in to." Then along comes a situation where we need more granular traffic engineering than the mapping we're using, so we break the mapping space up into smaller chunks, and give each piece a more granular piece. This is of little cost to the provider who does it--it only increases the mapping table size by one--and gives them much more control over traffic flow to destinations for which traffic transits their network. There must be exceptions, and exceptions turn out to be the rule. Anyone see any similarity to the way the IPv4 address space is handled today? Everyone still gains by pushing more granular information into the table, at little cost to themselves. We could say: "Ah, but we'll just limit the length to something quite a bit longer than what is allowed today!" Given the drivers for more granularity, what you most likely end up with here is either: 1. People need the service, so they will find a way. If IP won't do it, then IP==POTS. Let's retire now, and be done with it. 2. An exponentially growing table of short prefixes, facilitated by the huge IPv6 address space (as Tony has pointed out, routing /32's in IPv6 is the same thing as routing hosts in IPv4, so you've gained nothing in table size if you go in that direction). :-) Russ - -- [EMAIL PROTECTED] CCIE <>< Grace Alone == 1. The Transit/Content Provider I, like most folks on this list, get my 'net access through a cable provider. They pick up the traffic from the edge of my network (I have four routers in my house, all live, none just for lab or test--and I assume, at some point, that every house is going to have an entire network of devices, not a single device), transport it through their network, and send it to their upstream. They do the same for entire business networks, with their "business class" services. Hence, they should be treated as a transit AS. OTOH, they provide services, such as pay for play, where they provide the content locally, and allow their subscribers to use those services. Those services consist of information carried across a transit network, the 'net, from some content creator to their network. They have "terminal" servers in place to handle receiving and processing this content. They also create content locally, and sell it to other content providers throughout the world. Hence, they should be treated as a leaf AS. 2. The Content/Transit Provider Suppose you have some entertainment company that creates a lot of content. They have a lot of servers, and sell content to a lot of different providers, and direct to consumers, as their primary forms of business. Since they terminate a lot of traffic, they should be treated as a leaf AS. They also have a lot of subcontractors working for them, and have, in fact, contracted out an entire facility (outsourced) from some other creative house. These people must not only have access to the entertainment company's network, they must also have access to their "home" network, for tools, material, and management. The entertainment company simply creates a path for them to reach their home company through their 'net connection (it's cheaper to converge the traffic rather than paying for separate access), and transit it. They should then be treated like a transit AS. In fact, this situation plays out in more ways.... A large theme park operator also provides content locally, and then transits traffic for contractors who run entire venues, such as stores and eateries, within the confines of the theme park, for instance. They are also both a transit AS and a leaf node AS. 3. The Government/Transit Provider Any given US state government offers a number of, well, "services" to the people who live there. For instance, the ability to pay their taxes online comes to mind (I'm hesitant to use the word "service" and "pay taxes" in the same sentence. :-) ). They also might provide information about state colleges, tourist information, and others. Hence, they should be treated as a leaf AS. At the same time, every US state government also has a lot of departments that want access to the 'net, and also to have transport between the various offices of that department. Think your local DMV. Okay, sorry for injecting such a horrible thing into your head. It's like the tune that you can't stop playing in your head over and over once you year it, isn't is? :-) The state gov't provides all of these various departments transport and access to the 'net across their network. Hence, they are a transit AS. I'm certain there are a thousand more "grey area" networks--in fact, I'm certain "grey area" networks are growing in percentages, and "pure" networks are going away. Every coffee house is a "grey area" network, although they handle it today by having two separate networks, or using some other form of semi-physical separation. Every hotel is in the same position. At some point, people are going to tire of using two connections to do this stuff--we're telling them to converge, and they want to. :-) == Drivers for more granularity For instance: 1. Traffic engineering is quickly becoming a service by service affair, rather than a network affair, particularly on the server side of things. How many folks eat an entire subnet (/24) today, for a single service, so they can engineer traffic to that service specifically? 2. Quality of service threatens to add more granularity--you can no longer treat a host as a single traffic endpoint, from the network's point of view. Instead, a single host actually needs multiple virtual (or logical, if you will) connections, each with different characteristics. You can provide those connections through different queuing mechanisms in the network, or through layer 3 virtualization, or through some other means, but you still have to deal with multiple distinct streams with the same source/destination pair in some way--which means it becomes harder and harder, over time, to treat a subnet as a single "unit," I think. 3. Mobility adds more granularity, as well. While mobility on a per host basis isn't a "killer app," it's quickly becoming something that's just expected. People see they have partial mobility with their cell phones, and they want more (or rather content providers want them to have more). If IP doesn't step up the plate on this, then IP == POTS, and we can all just retire into our easy chairs, and talk about the "good old days," IMHO. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHUWCAER27sUhU9OQRApUnAJ9/PoqZxqLF77/dQBivn7oZW+0IxQCfUJsA asLIptTxJXGG1exuOayMJWY= =7QNg -----END PGP SIGNATURE----- -- to unsubscribe send a message to [EMAIL PROTECTED] 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
