Hi DY,
Just for the record Enke Chen and myself have came up with this idea as
well about ... 4 years ago :)
There are number of written documents we have on this. You can easily
google for it to see where is has been proposed before (even in this WG):
http://www.ietf.org/mail-archive/web/idr/current/msg03174.html
The main part of our proposal was that all transit ASes do not need to
be upgraded as IP header would contain plane old IPv4 address
constructed from AS number. Also all destination ASBRs would
automatically recognize this address and decapsulate.
But our primary focus was not too address "melting Internet" ... our
focus was to provide a means and ability to provide fast connectivity
restoration aka PIC but in the inter-as scope (so far it works well
intra-as).
The mapping plane for it comes for free ... each BGP update carries the
origin AS today .. now we can even RPKI validate it - to eliminate
manual mistakes. Soon we will also extend current origin validation to
make it even more secure.
Clearly the deployment price to pay would be to carry AS host routes oh
well ... perhaps additional 30K routes more in the Internet if everyone
suddenly would participate.
But where and what is the benefit ...... The benefit would be only
feasible if for a given network all of it's customers and transits start
sending AS IP address encapsulated packets. Otherwise you still need to
keep all addresses in control plane as well as put all addresses in the
FIB.
But now that we have ILNP on the table I am just thinking loud here ...
if DNS record could return us not the locator or set of locators, but
EID's numerical representation of an AS number hosts which support it
could easily encap it this way while in the inner header still contain
today's IP address of the given server.
So here is more of the question to ILNP authors if they have considered
such option ....
Many thx,
R.
Like...
o Packets would be appended by an AS number of the destination at
exiting its own AS.
o DFZ routers sees only AS numbers in determining the next hop router.
o The destination IP address would be examined only after the packet
has entered the destination AS.
Regards,
DY
On Sat, May 8, 2010 at 9:26 AM, Dae Young KIM<[email protected]> wrote:
This sounds similar to an idea I raised some months ago; inter-domain
routing based on AS numbers.
Some people were criticizing that AS's are not of equal scales (from a
tiny one to a global scale) and that it is not a useful/practical
granularity.
Studying the IRON, the enterprise also can be as small as SOHO and as
big as the entire global Internet. Not much different.
Then why not try an inter-domain routing (solely) based on AS numbers?
Nonsense?
Regards,
DY
On Sat, May 8, 2010 at 6:13 AM, Toni Stoev<[email protected]> wrote:
На Friday 07 May 2010 22:40:28 [email protected] написа:
Toni,
I am sorry, but I don't understand what you mean.
Heiner,
Currently inter-domain routing is based on IP address prefixes, which are
intra-domain context, and on AS number paths.
The simple and scalable model is the inter-domain routes to be only AS paths.
Toni
Heiner
-----Ursprüngliche Mitteilung-----
Von: Toni Stoev<[email protected]>
An: IRTF
RRG<[email protected]>http://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing
Verschickt: Fr., 7. Mai. 2010, 0:41
Thema: Re: [rrg] RG futures
On Thursday 06 May 2010 12:02:39 [email protected] sent:
How about an honest discussion that deals with the real causes of the
scalability problem!
The scalability (size) issue only unveils how miserably bad the (most
important) IETF routing paradigms are. Particularly:
...
Heiner
Intra-domain routing is as simple as node location naming follows topology.
Inter-domain routing has issues with intra-domain context – route identification
prefixes based on intra-domain identity/location naming, so called addresses.
Inter-domain routing has issues with route destination/endpoint ambiguity – what
an inter-domain route leads to, node(s) or autonomous system?
Regards to all.
_______________________________________________
_______________________________________________
rrg mailing list
[email protected]
http://www.irtf.org/mailman/listinfo/rrg
