re: [RRG] RRG process clarification

[Xu Xiaohu <xuxh@huawei.com>]

> - the shared goal of all the proposals so far: making the routing
> system scalable by routing on topologically (read: ISP) aggregatable
> prefixes only.

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