[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [RRG] RRG process clarification



Just to clarify: in GIRO there's no map'nencap or header manipulation (GSE), and therefore GIRO is different from the proposals bellow. GIRO addresses are structured in two parts, internal and external. The external part is the one announced in BGP, whereas the internal part is used for routing inside the destination net; but all pkts carry always the same address. More details at http://www.cs.ucla.edu/ ~rveloso/papers/giro.pdf

Thanks,

--Ricardo

On May 5, 2008, at 12:49 AM, Ricardo Oliveira wrote:

Xiaohu and all,

Routing purely by geographical location is not viable since routing is done per policy and traffic exchange agreements between ISPs and not by location. Said that, and as mentioned in this list before, GIRO is a solution that takes advantage of geographical info in the address, while keeping policy routing between ISPs. The closest solution to GIRO pointed bellow is GSE, with the difference that in GIRO the local address is not rewritten at border routers, but rather appended to the prefix advertised in BGP.

--Ricardo

Hi Lixia,

Should the geographically aggregatable address be out of the consideration?
For example, the site networks will use geographically aggregatable
addresses which are independent of the ISPs. However, these addresses can be aggregated in the ISP network even though the transit networks within some
region are required to be connected directly or indirectly.

Best wishes,
Xiaohu XU

- alternative ways to get there (branches)
#1 Using only aggregatable addresses throughout in the Internet
The essence of this approach is that a multihomed site will have
multiple address prefixes.
Example approaches under this category:
- SHIM6, with a shim layer between IP and transport to hide the multiple
   IP addresses from transport
- A proposal by Mark Handley, which pushes all multiple IP addresses
   all the way up to transport layer to handle
(NOTE: I mention these examples for the sake of illustrating what this branch means; by no means we should get into specific proposal debate
here)

#2 Routing on aggregatable addresses only inside the global transit
core (the place that faces scalability challenges today), but do not
push these provider-based addresses into user sites.
The essence of this approach is that a mapping layer must exist at the
interface between user sites and the transit core.
(the word "layer" is meant an insulation boundary between parts of the
net; please do not confuse it with "protocol layer". I simply could
not find another word at the moment)
Example approaches under this category:
- map-n-encap, which uses IP-in-IP tunneling at the boundary
- GSE, which uses IP address rewrite at the boundary

Some people prefer to separate out IP-address-rewrite to a 3rd
category, and I would be happy to go that way as well.

Does the above miss any other branches at the top level design tree?

Lixia
PS: I do owe Robin a reply with regard to what are the steps towards
the decision (i.e. whether RRG needs a depth-first search to reach a
decision), but I want to make clear that the above question is
orthogonal to that debate.



--
to unsubscribe send a message to rrg-request@psg.com 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



--
to unsubscribe send a message to rrg-request@psg.com 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


--
to unsubscribe send a message to rrg-request@psg.com 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


--
to unsubscribe send a message to rrg-request@psg.com 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