Subject: [RRG] yetAnotherProposal: AS-number forwarding

From: "Lars Westberg" <[email-masked]>
Date: Mon, 10 Mar 2008 07:40:11 +0100

Hi,
I haven't had time to make a draft but I think it make sense for the
discussion. However, I don't know if it already have been discussed
so....

The proposal are simple: re-use AS-numbers into the forwarding of
packets such that prefixes could be aggregated per AS. One simple
implemetation is that the packets are tunneled and that the
tunnel-address is associated to a AS-number. The AS-numbers can be
assigned to the IP-addresses by DNS or by define a small address-prefix
to AS-numbers.

Comments?

regards Lars Westberg, Ericsson Research

---

From: Xu Xiaohu <[email-masked]>
Date: Mon, 10 Mar 2008 09:46:34 +0100

Hi Lar,

You can have a look at ENCAPS or HRA
(http://www.huawei.com/file/download.do?f=3073), which are based on
AS/LD-level routing.

Best wishes,

Xiaohu XU

  _____  

发件人: [email-masked] [mailto:[email-masked]] 代表 Lars Westberg
发送时间: 2008年3月10日 7:40
收件人: [email-masked]
抄送: Lars Westberg
主题: [RRG] yetAnotherProposal: AS-number forwarding

Hi, 
I haven't had time to make a draft but I think it make sense for the
discussion. However, I don't know if it already have been discussed so....

The proposal are simple: re-use AS-numbers into the forwarding of packets
such that prefixes could be aggregated per AS. One simple implemetation is
that the packets are tunneled and that the tunnel-address is associated to a
AS-number. The AS-numbers can be assigned to the IP-addresses by DNS or by
define a small address-prefix to AS-numbers.

Comments?

---

From: "Lars Westberg" <[email-masked]>
Date: Mon, 10 Mar 2008 10:52:58 +0100

I have looked through the document but I think it is not exactly what I thought of.
 
I am just thinking of solution in which the backbone can use AS-number in the forwarding architecture. I does not mean that we need to change everything. It may be other reasons for larger changes of the routing architecture but I didn't consider it as necessary as a part of this proposal.
 
-Lasse 

________________________________

	From: Xu Xiaohu [mailto:[email-masked]] 
	Sent: den 10 mars 2008 09:47
	To: Lars Westberg; [email-masked]
	Subject: re: [RRG] yetAnotherProposal: AS-number forwarding

	Hi Lar,

	You can have a look at ENCAPS or HRA (http://www.huawei.com/file/download.do?f=3073), which are based on AS/LD-level routing.

	Best wishes,

	Xiaohu XU

________________________________

	Hi, 
	I haven't had time to make a draft but I think it make sense for the discussion. However, I don't know if it already have been discussed so....

	The proposal are simple: re-use AS-numbers into the forwarding of packets such that prefixes could be aggregated per AS. One simple implemetation is that the packets are tunneled and that the tunnel-address is associated to a AS-number. The AS-numbers can be assigned to the IP-addresses by DNS or by define a small address-prefix to AS-numbers.

	Comments?

---

From: "Juan Jose Adan" <[email-masked]>
Date: Mon, 10 Mar 2008 11:33:42 +0100

Lars

You may want to take a look on the proposal I wrote
on "Tunneled Interdomain Routing (TIDR)". In TIDR
the AS number is mapped to specific address
prefixes that are used for tunneling, and that I
called "locator prefixes". This is the URL:

 http://tools.ietf.org/html/draft-adan-idr-tidr-01<mhtml:{19C95F33-1496-4978-8A15-38798B34A6D5}mid://00000366/!x-usc:http://tools.ietf.org/html/draft-adan-idr-tidr-01>

And this URL shows a slight modification:

http://www.ietf.org/mail-archive/web/ram/current/msg01308.html<mhtml:{19C95F33-1496-4978-8A15-38798B34A6D5}mid://00000366/!x-usc:http://www.ietf.org/mail-archive/web/ram/current/msg01308.html>

Regards,
Juanjo

-----

2008/3/10, Lars Westberg <[email-masked]>:

> I am just thinking of solution in which the backbone can use AS-number in
> the forwarding architecture. I does not mean that we need to change
> everything. It may be other reasons for larger changes of the routing
> architecture but I didn't consider it as necessary as a part of this
> proposal.
>
> -Lasse
>

---

From: Lixia Zhang <[email-masked]>
Date: Mon, 10 Mar 2008 04:21:50 -0700

On Mar 9, 2008, at 11:40 PM, Lars Westberg wrote:

> implemetation is that the packets are tunneled and that the tunnel- 
> address is associated to a AS-number. The AS-numbers can be assigned  
> to the IP-addresses by DNS or by define a small address-prefix to AS- 
> numbers.
>
> Comments?
>

in an ideal world, yes having AS number as part of address used for  
routing has great benefit.  see the slide from a talk in 2006 (http://www.cs.ucla.edu/~lixia/0612Australia.pdf 
, but ignoring the title), slide 17 & 18 is about this.
If we had a chance to influence address structure, you'd want to  
include other info in addition to AS (as large ASes span large areas,  
TE would want more info to do better job).
we have another paper (http://www.cs.ucla.edu/~rveloso/papers/ 
giro.pdf) showing the benefit for including location info (which  
should be a subfield after AS number)

FYI,
Lixia

--
to unsubscribe send a message to [email-masked] 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

---

From: Geoff Huston <[email-masked]>
Date: Mon, 10 Mar 2008 22:38:12 +1100

Lixia Zhang wrote:
>> assigned to the IP-addresses by DNS or by define a small 
>> address-prefix to AS-numbers.
>>
>> Comments?
>>
> 
> routing has great benefit.  see the slide from a talk in 2006 
> (http://www.cs.ucla.edu/~lixia/0612Australia.pdf, but ignoring the 
> title), slide 17 & 18 is about this.
> If we had a chance to influence address structure, you'd want to include 
> other info in addition to AS (as large ASes span large areas, TE would 
> want more info to do better job).
> we have another paper (http://www.cs.ucla.edu/~rveloso/papers/giro.pdf) 
> showing the benefit for including location info (which should be a 
> subfield after AS number)

And while we're having one of those historical moments:
http://www.caida.org/funding/routing/atoms/proposal/index.xml

Dunno how much all this helps the world other than illustrate (a) that 
AS-based routing is probably too coarse and you may want a finer level 
of granularity in terms of division of forwarding elements and (b) all 
of this is well covered ground.

---

From: Xu Xiaohu <[email-masked]>
Date: Mon, 10 Mar 2008 13:34:48 +0100

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Lixia Zhang
> 发送时间: 2008年3月10日 12:22
> 收件人: Lars Westberg
> 抄送: [email-masked]
> 主题: Re: [RRG] yetAnotherProposal: AS-number forwarding
> 
> 
> (http://www.cs.ucla.edu/~lixia/0612Australia.pdf

With support of routing aggregation at any desired level, I can't image that
GIRO alone can do much help in routing scalability issue unless it brings in
some id/locator split idea, like GSE, SIX/ONE or HRA.

The first approach is to split the GIRO address into two parts: id and
locator. In this approach, IPv4 address part in GIRO address is used as id,
which means there is no need to change the hosts however it doesn't address
the IPv4 address depletion issue. From this perspective, it's much like eFIT
or LISP but it introduces a new locator space.

The second approach is to make hosts to negotiate the bunch of several GIRO
addresses.

The last approach is to introduce an independent host id namespace and uses
a whole GIRO address as locator.

Which one do you prefer? Or you have any other better idea?

Best wishes,
Xiaohu XU

---

From: Lixia Zhang <[email-masked]>
Date: Mon, 10 Mar 2008 06:18:07 -0700

> some id/locator split idea, like GSE, SIX/ONE or HRA.

- as you can see from the talk slides, yes the basic idea IS to
   separate edge prefixes from transit routing space

- to the specific question of whether aggregation alone
   (by AS and then location) can help much with routing scalability:
   (a) it can indeed help a lot based on the analysis using today's
       routing table content
   (b) but if we want the global routing system to scale *independently*
       from the edge user site growth, then the separation becomes
       necessary.

The reason I referred to the 2nd paper is merely to show the benefit  
of including location info in address; not sure where you got the  
implication of no-split.

Lixia

---

From: Peter Sherbin <[email-masked]>
Date: Mon, 10 Mar 2008 06:19:39 -0700 (PDT)

> Which one do you prefer? Or you have any other better idea?

ID/Loc split comes in various forms over and over again with people seem to
concentrate on a soft transition of the current system into a scalable one with a
minimal disruption. As prudent as it sounds it might not yield anticipated benefits.
More desirable approach is to abandon the current Internet entirely and build a new
one from two independent, separately managed pools of id: a locator pool and a name
pool, where names move freely around a rigid hierarchy of locators. A real time
formation of a loc+name pair provides a source/destination lasting from minutes for
mobile devices to years for a static gear.

Thank you,

Peter

> 
> 
> > -----�ʼ�ԭ��-----
> > ������: [email-masked] [mailto:[email-masked]] ����
Lixia Zhang
> > ����ʱ��: 2008��3��10�� 12:22
> > �ռ���: Lars Westberg
> > ����: [email-masked]
> > ����: Re: [RRG] yetAnotherProposal: AS-number forwarding
> > 
> > 

      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

---

From: Xu Xiaohu <[email-masked]>
Date: Mon, 10 Mar 2008 15:06:01 +0100

> -----邮件原件-----
> 发件人: Peter Sherbin [mailto:[email-masked]]
> 发送时间: 2008年3月10日 14:20
> 收件人: Xu Xiaohu; 'Lixia Zhang'; 'Lars Westberg'
> 抄送: [email-masked]
> 主题: re: [RRG] yetAnotherProposal: AS-number forwarding
> 
> pool, where names move freely around a rigid hierarchy of locators.

I basically agree with your idea of two independent, separately managed pools of id and locator namespace, but I don't like the idea of abandoning the current Internet entirely. 

The IPv4 address can still be used well as a local locator, not global locator, with an appendix of locator domain (LD) prefix/ID. For example, there are multiple LDs in the world, each LD can use independent IPv4 address space, different LD only exchange LD prefix/ID information with each other, in this way, there are at least three benefits: 1) the address depletion issue is solved; 2) the route stability is improved greatly since the route churn in one LD will not be flooded into other LDs and the LD-prefix can even be aggregated further; 3) the deployment cost is relatively low since only the LD border routers need to be upgraded and the most internal routers within LD can still be IPv4-enabled router. The LD prefix/ID is strictly hierarchical and topology-dependant, or even geographical-location related (see GIRO). This is some idea of HRA.

IMO, the strict and full hierarchy in locator namespace is not a good idea as it will limit the flexibility of address assignment and the efficiency of address utilization. 

Best wishes,
Xiaohu XU

> > > -----ï¿½Ê¼ï¿½Ô­ï¿½ï¿½-----
> > > ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½: [email-masked] [mailto:[email-masked]]
> ï¿½ï¿½ï¿½ï¿½
> Lixia Zhang
> > > ï¿½ï¿½ï¿½ï¿½Ê±ï¿½ï¿½: 2008ï¿½ï¿½3ï¿½ï¿½10ï¿½ï¿½ 12:22
> > > ï¿½Õ¼ï¿½ï¿½ï¿½: Lars Westberg
> > > ï¿½ï¿½ï¿½ï¿½: [email-masked]
> > > ï¿½ï¿½ï¿½ï¿½: Re: [RRG] yetAnotherProposal: AS-number forwarding
> > >
> > >
> know-it-all with Yahoo! Mobile.  Try it now.
> http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

---

From: Peter Sherbin <[email-masked]>
Date: Mon, 10 Mar 2008 08:51:21 -0700 (PDT)

> IMO, the strict and full hierarchy in locator namespace is not a good idea as
> it will limit the flexibility of address assignment and the efficiency of
> address utilization.

Not necessarily. One would assign flat names which are free to move anywhere.
Address rigid (geo) hierarchy would extend to Tier 1/2 ISP level with a full freedom
for addressing access points below. Thus aggregating access points becomes an ISP
task fitting into the pre-determined global hierarchy.

In this context "abandoning of the existing Internet" means in thinking about the
new architecture, with the intent is to free minds from legacy. When the new design
is done incorporating the existing Internet into it becomes a routine exercise.
Thank you for pointing that out.

Thanks,

Peter

--- Xu Xiaohu <[email-masked]> wrote:

> I basically agree with your idea of two independent, separately managed pools of
> id and locator namespace, but I don't like the idea of abandoning the current
> Internet entirely. 
> 
> The IPv4 address can still be used well as a local locator, not global locator,
> with an appendix of locator domain (LD) prefix/ID. For example, there are multiple
> LDs in the world, each LD can use independent IPv4 address space, different LD
> only exchange LD prefix/ID information with each other, in this way, there are at
> least three benefits: 1) the address depletion issue is solved; 2) the route
> stability is improved greatly since the route churn in one LD will not be flooded
> into other LDs and the LD-prefix can even be aggregated further; 3) the deployment
> cost is relatively low since only the LD border routers need to be upgraded and
> the most internal routers within LD can still be IPv4-enabled router. The LD
> prefix/ID is strictly hierarchical and topology-dependant, or even
> geographical-location related (see GIRO). This is some idea of HRA.
> 
> IMO, the strict and full hierarchy in locator namespace is not a good idea as it
> will limit the flexibility of address assignment and the efficiency of address
> utilization. 
> 
> Best wishes,
> Xiaohu XU
>

---

From: Xu Xiaohu <[email-masked]>
Date: Mon, 10 Mar 2008 17:48:17 +0100

> of including location info in address; not sure where you got the

Aha, I see the benefit of including location info in address. I'm just
interested in what's the best choice of integrating this GRIO with a kind of
id/loc split idea.

Best wishes,
Xiaohu XU

---

From: Ricardo Oliveira <[email-masked]>
Date: Mon, 10 Mar 2008 17:53:41 -0700

> interested in what's the best choice of integrating this GRIO with  
Xiaohu,

GIRO already does the separation of locator/identifier. In Fig. 3,  
which describes the address format, you can view the  "external  
component"  as the "locator", and the "internal component" is the  
"identifier". The locator is announced in BGP, while the identifier  
is used to route inside the dest network.
Cheers,

--Ricardo

---

From: "Juan Jose Adan" <[email-masked]>
Date: Tue, 11 Mar 2008 09:19:16 +0100

Hi Geoff,

>of this is well covered ground.

I think AS-based routing does not necessarily imply that
we have to use just a locator per AS, but the locators'
structure will have to be based on the AS number.

(I will use 2-byte AS numbers to better explain this).

Let's suppose we want to send traffic to a server A having
an IP address within the "identifier prefix" of a stub AS
connected to a transit provider whose ASN=1. Let's also
suppose that we use the "locator prefix" 240.0.1.0/24 to
send tunneled traffic towards AS1 (second and third bytes
are the AS number). It means that the outer IP address
would be 240.0.1.0.

For server B having an IP address in a different "identifier
prefix", AS1 could announce a second "locator prefix", for
example 240.0.1.128/25, so that traffic sent to server B
would be tunneled with the outer IP address 240.0.1.128.

And AS1 would announce these two "locator prefixes", namely
240.0.1.0/24 and 240.0.1.128/25, in different ways to the
rest of the Internet.

And this exercise can be made finer and finer so that an
"identifier prefix" could be assigned a "locator prefix"
such as 240.0.1.77/32.

Therefore AS-based routing can be used with a very fine
level of granularity I think.

Regards,
Juanjo

-----

---

From: "Lars Westberg" <[email-masked]>
Date: Tue, 11 Mar 2008 09:36:37 +0100

Good comment. 
 
In general, I don't understand the the problem definition.
If the focus, is backbone scalabillity caused by site-multihooming then
the problem space are very static. 
Therefore, an approach with predefined provider adresses space could be
pretty simple. 
One may also find a solutions that makes the mapping very simplistic
from an implementation point-of-viow.
 
-Lasse

	From: Juan Jose Adan [mailto:[email-masked]] 
	Sent: den 11 mars 2008 09:19
	To: Geoff Huston
	Cc: Lixia Zhang; Lars Westberg; [email-masked]
	Subject: Re: [RRG] yetAnotherProposal: AS-number forwarding

	Hi Geoff,

	 

	 

	 
	Regards,
	Juanjo
	 
	-----

---

From: Xu Xiaohu <[email-masked]>
Date: Tue, 11 Mar 2008 12:07:05 +0100

> is used to route inside the dest network.

Ricardo,

What you said is just the first approach I mentioned in the previous mail as
follows:
The first approach is to split the GIRO address into two parts: id and
locator. In this approach, IPv4 address part in GIRO address is used as id,
which means there is no need to change the hosts however it doesn't address
the IPv4 address depletion issue and it introduces a new locator space
compared to LISP/eFIT.

What's the benefit of introducing a new locator namespace compared with
LISP/eFIT which reuses IP address as locator?  Once the id/loc split idea is
introduced, the locator can be allocated in a hierarchical way even though
we still use IPv4/v6 as locator. 

Best wishes,
Xiaohu XU

---

From: Scott Brim <[email-masked]>
Date: Mon, 10 Mar 2008 10:25:07 -0400

On 3/10/08 7:38 AM, Geoff Huston allegedly wrote:
> of granularity in terms of division of forwarding elements ...

... which as far as I remember is the primary reason we've reluctantly 
dismissed the idea of AS-based routing several times over the years.

---

From: Ricardo Oliveira <[email-masked]>
Date: Tue, 11 Mar 2008 16:10:50 -0700

> we still use IPv4/v6 as locator.
Xiaohu:
The main advantage of using the ASN+location+SID namespace is to  
enable both topological and geographical aggregation, and help in   
reducing route geographical stretch.
Note that GIRO is *not* a loc/id separation solution, but just a  
different way of organizing the bits in the address and announcing in  
BGP only the relevant bits for inter-domain routing. The 2nd half of  
GIRO address is also a locator to route pkts inside the dest ASN.  
This means that all mapping can be easily done trough DNS by querying  
the  dest host name to get the full GIRO address, in the same way  
hosts are looked up in current Internet.

--Ricardo

---

From: Xu Xiaohu <[email-masked]>
Date: Wed, 12 Mar 2008 09:33:45 +0100

Ricardo,

Thanks a lot for your clarification.:)

Best wishes,
Xiaohu XU

---

From: [email-masked]
Date: Sat, 15 Mar 2008 11:29:22 EDT

The GERO address scheme perfectly contains the geolocation information  which 
I requested as well, but was rejected by argumenting with "is  not 
incrementally deployable" and "requires host changes".
 
I can only confirm and even extend the list of positive results:
The routing table entries  will become very short  (maybe 600 but certainly 
not more than 2-3 K ), the update churn will  disappear completely, the such 
small routing table could be enlarged just for  the sake of faster forwarding:  
just one next hop table lookup,  offset by the respective geopatch number 
(note, that there are 360 x 180  =64800 geopatches which is less than 
256x256=65536)   in case the  destination belongs to a different patch i.e. which is 
confined by  different longitudes and latitudes), and certainly likewise while 
using another  table for the next hop determination if the destination belongs to 
the same  geopatch like the current router. In preparation, experimental RF
C1712 has been  published a long time ago, but never used and never properly 
read, not even by  the RFC-editor: there, where the encoding is standardized, 
longitutes and  latitudes are terribly mixed up :-(
Note also that the one single  table lookup may cover both inter- and  
intra-domain hops, will say that one lookup will do no matter how many OSPF-  nodes 
may be the potential destination node.
 
Note that the "<=" -compare operator is much more powerful than the "="  
operator, and also note that  geopatches are the only entities which are  best 
suited for aggregation: much better than unicast addresses  for sure  (while AS 
numbers and Multicast addresses aren't at all !!!)
 
Heiner
 
In einer eMail vom 10.03.2008 12:23:17 Westeuropäische Normalzeit schreibt  
[email-masked]:

FYI,
Lixia