Subject: [rrg] Inter/intra-domain routing separation

From: Toni Stoev <[email-masked]>
Date: Tue, 5 May 2009 12:35:41 +0300

Intra-domain routing can be considered as a general solution. This general solution is the provision of reachability throughout an autonomous system.
Node locators can be considered intra-domain locators. Every locator shall have default association with its containing autonomous system in order to be universally recognizable.
Utilizing these approaches inter-domain routing can be separated from intra-domain routing. Inter-domain routing shall be based on autonomous system paths and not on IP addresses and prefixes. Thus inter-domain routing tables will be substantially unloaded and more easily managed.
This will provide significant improvement to inter-domain routing scalability.

---

From: Toni Stoev <[email-masked]>
Date: Wed, 6 May 2009 02:35:52 +0300

How can locator have default association with its containing autonomous system?
Easy. Autonomous system number shall be incorporated into locator. Universally recognizable locator shall start with it.

On Tuesday 5 May 2009 12:35:41 Toni Stoev sent:
> _______________________________________________
> rrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/rrg
>

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 06 May 2009 00:57:18 -0700

Hi Toni,

Just FYI I and Enke Chen have discussed in the past an algorithmic way 
to convert 4 byte AS number into the locator. Naturally such locator 
would be an anycast and one could most likely enter given AS via any 
peering ASBR.

The scheme is very simple.

We take 4 byte AS number, assume that we will use 3 last octets while 
first octet would be all zeros and do normal byte by byte bin to dec 
conversion.

The resulting special IPv4 address would be 0.A.B.C.

For IPv6 this is even simpler :).

At that time some folks voiced their opinion that making AS part of a 
locator is a bad thing. Along the same lines they were against tunneling 
to AS/IP address. Perhaps those folks could comment now why this is a 
bad choice ?

I never understood why we can not make first baby step and introduce 
some of the hierarchy just by doing this. We pretty much already know 
today the originator AS from AS_PATH (AS SET is sporadic) as well as 
number of potentially injected new entires equal to number of ASes would 
be noise for current BGP.

Cheers,
R.

---

From: Xu Xiaohu <[email-masked]>
Date: Wed, 06 May 2009 17:22:20 +0800

> Just FYI I and Enke Chen have discussed in the past an 
> algorithmic way to convert 4 byte AS number into the locator. 
> Naturally such locator would be an anycast and one could most 
> likely enter given AS via any peering ASBR.

In the draft of  "Simple Tunnel Endpoint Signalling in BGP"[
http://tools.ietf.org/id/draft-xu-tunnel-00.txt ] ,  an IP address specific
extended community is used for carring
the tunnel endpoint (RLOC), which is associated with the NLRI (EID prefix).
In fact, as long as the tunnel endpoint address  is an anycast address
within the originator AS , it is just AS-based inter-domain routing.

Xiaohu

> We take 4 byte AS number, assume that we will use 3 last 
> octets while first octet would be all zeros and do normal 
> byte by byte bin to dec conversion.
> 
> At that time some folks voiced their opinion that making AS 
> part of a locator is a bad thing. Along the same lines they 
> were against tunneling to AS/IP address. Perhaps those folks 
> could comment now why this is a bad choice ?
> 
> I never understood why we can not make first baby step and 
> introduce some of the hierarchy just by doing this. We pretty 
> much already know today the originator AS from AS_PATH (AS 
> SET is sporadic) as well as number of potentially injected 
> new entires equal to number of ASes would be noise for current BGP.
> 
> Cheers,
> R.
> 
> > Easy. Autonomous system number shall be incorporated into 
> locator. Universally recognizable locator shall start with it.
> > 
> >> Intra-domain routing can be considered as a general 
> solution. This general solution is the provision of 
> reachability throughout an autonomous system.
> >> Node locators can be considered intra-domain locators. 
> Every locator shall have default association with its 
> containing autonomous system in order to be universally recognizable.
> >> Utilizing these approaches inter-domain routing can be 
> separated from intra-domain routing. Inter-domain routing 
> shall be based on autonomous system paths and not on IP 
> addresses and prefixes. Thus inter-domain routing tables will 
> be substantially unloaded and more easily managed.

---

From: Toni Stoev <[email-masked]>
Date: Thu, 7 May 2009 05:40:05 +0300

Robert, Xiaohu, thanks for commenting.

To be clear, I use the term "autonomous system" in the sense of "routing domain", considering both interchangeable.

---

From: Scott Brim <[email-masked]>
Date: Thu, 07 May 2009 07:43:18 -0400

Toni Stoev allegedly wrote on 05 05 2009 5:35 AM:
> Intra-domain routing can be considered as a general solution. This
> general solution is the provision of reachability throughout an
> autonomous system. Node locators can be considered intra-domain
> locators. Every locator shall have default association with its

First, see http://tools.ietf.org/html/rfc1955

Second, IMHO AS#s are the wrong granularity.

  - a prefix can be reachable via more than one AS

  - there can be more than one prefix within an AS

  - it should be possible to route different prefixes, and subprefixes,
    via different paths for traffic engineering purposes.

Scott

---

From: <[email-masked]>
Date: Thu, 7 May 2009 16:24:31 +0100

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Scott Brim
> Sent: 07 May 2009 12:43
> To: Toni Stoev
> Cc: IRTF RRG
> Subject: Re: [rrg] Inter/intra-domain routing separation
> 

Why should we do that at the level of prefix - would it not be nicer to
route different traffic via different paths to load balance based on
load - who really wants to prefix balance. 

Also, a computer can be reached by more than one prefix as well as more
than one AS

If we assume we have an end point identifier then would AS be the wrong
level of granularity for the top level of a routing heirarchy?  Seems to
me that the prefix level is too detailed for us to handle well so we
need to make the top level less fine grained? 

Louise

---

From: Xu Xiaohu <[email-masked]>
Date: Fri, 08 May 2009 11:23:23 +0800

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Scott Brim
> 发送时间: 2009年5月7日 19:43
> 收件人: Toni Stoev
> 抄送: IRTF RRG
> 主题: Re: [rrg] Inter/intra-domain routing separation
> 

How about providing enough flexibility so that both AS granularity and
prefix granularity are available? For example,  those tunnel endpoint
routers (ETR) within the same AS could either use unique unicast addresses
per router or an anycast address as their tunnel endpoint addresses (RLOC).

Xiaohu

---

From: "Fleischman, Eric" <[email-masked]>
Date: Tue, 12 May 2009 08:48:58 -0700

It is my personal opinion that most of these definitions are already
well established in Internet parlance and therefore re-definitions are
not warranted (or needed).

It is also my personal opinion that some of the recent postings could
have been resolved by reference to well-established traditional
architectural principals such as the IP Topology Hierarchy, which
defines topology layers such as "autonomous systems" as well as routing
concepts such as intra-domain and inter-domain.

Coworkers who think as I do in terms of historic Internet constructs
such as those articulated by Catenet, the ROAD Group, or NIMROD will
probably think in terms of recursion and the possibility of creating
complex structures within IP Topology Hierarchy layers. The power and
beauty of this historic model when applied to the IP Topology Hierarchy
framework is amazingly impressive. But that is the topic for another
posting... The goal of this posting is solely to express my personal
opinion that historic Internet concepts and traditional Internet
terminology retain great value, power, and usefulness and should not
easily be overlooked (or modified).

---

From: Toni Stoev <[email-masked]>
Date: Fri, 22 May 2009 05:55:35 +0300

> First, see http://tools.ietf.org/html/rfc1955

Scott,

I saw that proposal.
I have read other network architecture materials too.
In my proposals I may be using ideas from other people or I may be thinking up ideas that others have thought up priorly. Either way I'm thinking with my head.
What I see so far is that there are many good ideas thought up already. Almost all that we currently need.
But what we lack in solutions is idealism. That is, the good ideas to be stretched to their full scale. And solutions to be comprised all of good ideas.
Because of the lack of idealism we have global systems pliant to crises.
Well, if ideas are too many at once, there won't be any idealistic solution realized. But we need a start.
So let us claim idealism.

Toni