Subject: [rrg] belated msg: further description of the recommendation process

From: Lixia Zhang <[email-masked]>
Date: Thu, 10 Dec 2009 21:53:54 -0800

sorry folks, day job crisis delayed this msg for a few days.

Tony and I have had some discussions on how to collect the  
recommendation document.  One comment we have heard repeated from a  
number of people is that our recommendation should document the pros  
and cons of different approaches, which can be very valuable, even  
independent from whichever specific recommendations we may end up with.

1/ To steer efforts toward that goal, we would like each proposal to  
make a concise summary, preferably no longer than ~1000 words (it may  
contain pointer to more detailed document), that describes the key  
ideas of the proposal of exactly how it addresses routing scalability  
issue, where is its cost, and where is its gain.

Given this message is getting out late, we would like to extend the  
submission time from 12/15 to 12/22, before people drift away from  
work to holidays (scream now if it does not work for some reason)

2/ with the above, we start contrast and compare proposals with each  
other.
We need to summarize the outcome of this step into a short document of  
the pros and cons for each proposal.

Tony, please help add things that I may have lost from memory

Lixia
PS; it is top on my todo list to get all the step-forward proposals on  
RRG wiki. this weekend.

---

From: Patrick Frejborg <[email-masked]>
Date: Fri, 11 Dec 2009 15:55:48 +0200

Hi Lixia,

it is going to be tight for me with the holidays around the corner
(and other projects) - it would be easier if you provide a template
with titles e.g. based upon
http://tools.ietf.org/html/draft-irtf-rrg-design-goals-01
Then we could fill explanations of how the proposal is dealing with
each issue and in the end perhaps there is some additional field where
the author can highlight some other issues that don't have an own
title.
And it would be easier for you to compare the proposals.

But this is only a suggestion, don't know how others feel about this approach.

-- patte

On Fri, Dec 11, 2009 at 7:53 AM, Lixia Zhang <[email-masked]> wrote:
> Tony and I have had some discussions on how to collect the recommendation
> document.  One comment we have heard repeated from a number of people is
> that our recommendation should document the pros and cons of different
> approaches, which can be very valuable, even independent from whichever
> specific recommendations we may end up with.
>
> 1/ To steer efforts toward that goal, we would like each proposal to make a
> concise summary, preferably no longer than ~1000 words (it may contain
> pointer to more detailed document), that describes the key ideas of the
> proposal of exactly how it addresses routing scalability issue, where is its
> cost, and where is its gain.
>
> submission time from 12/15 to 12/22, before people drift away from work to
> holidays (scream now if it does not work for some reason)
>
> 2/ with the above, we start contrast and compare proposals with each other.
> We need to summarize the outcome of this step into a short document of the
> pros and cons for each proposal.
>
> PS; it is top on my todo list to get all the step-forward proposals on RRG
> wiki. this weekend.
> _______________________________________________
> rrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/rrg
>

---

From: Michael Menth <[email-masked]>
Date: Sun, 13 Dec 2009 18:41:46 +0100

Hi Lixia,

do mapping systems also belong to the discussed proposals? I assume they 
do not although a lot of the complexity taken out of the routing is put 
into them? If I am wrong, I would like to add FIRMS to the list of 
discussed proposals:
http://www3.informatik.uni-wuerzburg.de/~menth/Publications/papers/Menth09-FIRMS.pdf 

Kind regards,

  Michael

-- 
Dr. Michael Menth, Assistant Professor
University of Wuerzburg, Institute of Computer Science
Am Hubland, D-97074 Wuerzburg, Germany, room B206
phone: (+49)-931/31-86644 (new), fax: (+49)-931/888-6632
mailto:[email-masked]
http://www3.informatik.uni-wuerzburg.de/research/ngn

---

From: Robin Whittle <[email-masked]>
Date: Mon, 14 Dec 2009 10:29:16 +1100

Short version:   The RRG Design Goals document cold be used as the
                 basis for a "template", but was based on very
                 little discussion and AFAIK has not achieved
                 consensus.

                 I suggest that concise summaries mention how
                 suitable the proposal is for voluntary adoption in
                 IPv4 and IPv6 - perhaps with reference to this list
                 of constraints:

              http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/

Hi Patrick,

You suggested a template for the concise summaries, which the
co-chairs requested - "preferably no longer than ~1000 words (it may
contain pointer to more detailed document)" - perhaps based on:

If we had consensus on a set of goals, I think that would be good.
However, as far as I know, we don't have consensus on this document.

Tony wrote this version on 2007-07-08 and it was announced a few days
later:

  http://psg.com/lists/rrg/2007/msg00179.html

There were only a handful of messages about the design goals before
this, and I recall not many since then.  I expected there would be
further revisions, and wrote some detailed material about improving
the Design Goals on 2009-07-14:

  http://psg.com/lists/rrg/2007/msg00199.html

but there has been no discussion of my suggestions or further
revision of the Design Goals.

rrg-design-goals-01 was finalised after less than 179 RRG messages.
There have been 5429 messages to date.  So by this measure, the
Design Goals were finalised after only 3.3% of the RRG's total
discussion.

The co-chairs have not led a discussion on the constraints due to
voluntary adoption.  Nor have they expressed their personal views on
my attempt to list the constraints.  These constraints are surely an
important basis for evaluating proposals, since no-one has suggested
we can rely on anything but voluntary adoption.

There has been some useful discussion of the constraints and a number
of people have expressed agreement with my list, both in April when I
first wrote it and in recent weeks.  No-one likes these constraints,
but I think that this support, and the lack of substantial critiques,
makes this list a worthwhile reference point when comparing proposals.

 - Robin

---

From: Tony Li <[email-masked]>
Date: Mon, 14 Dec 2009 08:20:09 -0800

> http://www3.informatik.uni-wuerzburg.de/~menth/Publications/papers/Menth09-FIRMS.pdf 

Michael,

Mapping systems are obviously a component of a solution but are not by 
themselves a solution.  To be considered seriously, they should be used 
in conjunction with some network layer solution.

Regards,
Tony

---

From: Tony Li <[email-masked]>
Date: Mon, 14 Dec 2009 08:21:34 -0800

>                  little discussion and AFAIK has not achieved

Robin,

When the discussion of the design goals slowed, we judged that to 
indicate rough consensus.

>               http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/

While you're more than welcome to do so, this is not a requirement.

Tony

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 15 Dec 2009 08:43:45 +1300

On 2009-12-15 05:20, Tony Li wrote:
> Michael Menth wrote:
>> Hi Lixia,
>>
>> do mapping systems also belong to the discussed proposals? I assume
>> they do not although a lot of the complexity taken out of the routing
>> is put into them? If I am wrong, I would like to add FIRMS to the list
>> of discussed proposals:

Hmm. Don't you think that to some extent these should be orthogonal?
A mapping mechanism needs to meet the specific requirements of a network
layer mechanism, but that doesn't require the two to be irrevocably
bound to each other.

I have a feeling that the mapping system should be very general in
nature, in case the first cut at either the locator or identifier space
proves to fall short. Also I feel it should support hierarchy, even if
we don't need a hierarchy from the start.

    Brian

---

From: Scott Brim <[email-masked]>
Date: Mon, 14 Dec 2009 14:51:34 -0500

Excerpts from Brian E Carpenter on Tue, Dec 15, 2009 08:43:45AM +1300:
> > Mapping systems are obviously a component of a solution but are
> > not by themselves a solution.  To be considered seriously, they
> > should be used in conjunction with some network layer solution.
> 
> A mapping mechanism needs to meet the specific requirements of a
> network layer mechanism, but that doesn't require the two to be
> irrevocably bound to each other.

Yes.  With a clear interface defined.

> nature, in case the first cut at either the locator or identifier
> space proves to fall short. 

Or one could use multiple interoperating mapping systems, so that
sites could use whichever suited their needs.  (The key is
interoperating).

---

From: Michael Menth <[email-masked]>
Date: Tue, 15 Dec 2009 00:07:22 +0100

Hi Brian,

> we don't need a hierarchy from the start.
I absolutely agree. However, I see two basically different cases:
a) mapping lookup performed only by hosts
b) mapping lookup performed also by intermediate nodes
In case of a), the mapping lookup must be fast but not very fast. DNS 
would certainly do. In case of b), the mapping lookup must be very fast 
because intermediate nodes need to store/drop/relay packets without 
locators and the time span for that should be minimized. In addition, a 
relaying function is possibly of interest to avoid extensive packet 
delay and loss which is not necessary for a). Hence, designing a mapping 
system for b) is more challenging than for a).

Security and scalability are general requirements for all mapping systems.

Best wishes,

    Michael

---

From: Vince Fuller <[email-masked]>
Date: Mon, 14 Dec 2009 16:16:30 -0800

> make a concise summary, preferably no longer than ~1000 words (it
> may contain pointer to more detailed document), that describes the
> key ideas of the proposal of exactly how it addresses routing
> scalability issue, where is its cost, and where is its gain.

Lixia, Tony-

Here is the response for LISP.

	--Vince
	(on behalf of the other LISP authors: Dino, Dave, and Darrel)

		--------------------

proposal:
---------
Locator Identifier Separation Protocol (LISP)

key idea:
---------
Implements a locator-identifier separation mechanism using encapsulation
between routers at the "edge" of the Internet. Such a separation allows
topological aggregation of the routeable addresses (locators) while
providing stable and portable numbering of end systems (identifiers).

gains:
------
- topological aggregation of numbering space (RLOCs) used for routing,
  which greatly reduces both the overall size and the "churn rate" of
  the information needed to operate the Internet global routing system
- seperate numbering space (EIDs) for end-systems, effectively allowing "PI
  for all" (no renumbering cost for connectivity changes) without adding
  state to the global routing system
- improved traffic engineering capabilities that explicitly do not add
  state to the global routing system and whose deployment will allow
  active removal of more-specific state currently used
- no changes required to end systems
- no changes to Internet "core" routers
- minimal and straightforward changes to "edge" routers
- day-one advatanges for early adopters
- defined router-to-router protocol
- defined database mapping system
- defined deployment plan
- defined interoperability/interworking mechanisms
- defined scalable end-host mobility mechanisms
- prototype implementation already exists and undergoing testing
- production implementations in progress

costs:
------
- mapping system infrastructure (map servers, map resolvers, ALT routers)
  (new potential business opportunity)
- Interworking infrastructure (proxy ITRs)
  (new potential business opportunity)
- overhead for determining/maintaining locator/path liveness (common issue
  for all id/loc separation proposals)

full documentation:
-------------------
draft-ietf-lisp-05.txt (LISP base specifiction, LISP WG draft)
draft-ietf-lisp-alt-01.txt (LISP+ALT mapping database, LISP WG draft)
draft-ietf-lisp-ms-02.txt (LISP Map Server, LISP WG draft)
draft-ietf-lisp-interworking-00.txt (Interworking mechanisms, LISP WG draft)
draft-meyer-lisp-mn-00.txt (LISP Mobile Node Architecture)
draft-farinacci-lisp-lig-01.txt (LISP Internet Groper debugging tool)
draft-meyer-lisp-loc-id-implications-01.txt (locator liveness considerations)

---

From: Xu Xiaohu <[email-masked]>
Date: Tue, 15 Dec 2009 11:19:55 +0800

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Lixia
Zhang
> 发送时间: 2009年12月11日 13:54
> 收件人: [email-masked]
> 主题: [rrg] belated msg: further description of the recommendation process
> 

Hi Lixia and Tony,

Summary of Routing Architecture for the Next Generation Internet (RANGI) is
as follows:

1. Key idea:
Similar to HIP [RFC4423], RANGI introduces a host identifier layer between
the network layer and the transport layer, and the transport-layer
associations (i.e., TCP connections) are no longer bound to IP addresses,
but to host identifiers. The major difference from the HIP is that the host
identifier in RANGI is a 128-bit hierarchical and cryptographic identifier
which has organizational structure. As a result, the corresponding
ID->locator mapping system for such identifiers has reasonable business
model and clear trust boundaries. In addition, RANGI uses IPv4-embeded IPv6
addresses as locators. The LD ID (i.e., the leftmost 96 bits) of this
locator is a provider-assigned /96 IPv6 prefix, while the last four octets
of this locator is a local IPv4 address (either public or private). This
special locator could be used to realize 6over4 automatic tunneling
(borrowing ideas from ISATAP [RFC5214]), which will reduce the deployment
cost of this new routing architecture. Within RANGI, the mappings from FQDN
to host identifiers are stored in the DNS system, while the mappings from
host identifiers to locators are stored in a distributed id/locator mapping
system (e.g., a hierarchical Distributed Hash Table (DHT) system, or a
reverse DNS system).

2. Gains:

RANGI achieves almost all of goals set by RRG as follows:

1) Routing Scalability: Scalability is achieved by decoupling identifiers
from locators.
2) Traffic Engineering: Hosts located in a multi-homed site can suggest the
upstream ISP for outbound and inbound traffics, while the first-hop LDBR (i.
e., site border router) has the final decision right on the upstream ISP
selection. 
3) Mobility and Multi-homing: Sessions will not be interrupted due to
locator change in cases of mobility or multi-homing.
4) Simplified Renumbering: When changing providers, the local IPv4 addresses
of the site do not need to change. Hence the internal routers within the
site don’t need renumbering.
5) Decoupling Location and Identifier: Obvious.
6) Routing Stability: Since the locators are topologically aggregatable and
the internal topology within LD will not be disclosed outside, the routing
stability could be improved greatly.
7) Routing Security: RANGI reuses the current routing system and does not
introduce any new security risk into the routing system.
8) Incremental Deployability: RANGI allows easy transition from IPv4 network
to IPv6 network. In addition, RANGI proxy allows RANGI-aware hosts to
communicate to legacy IPv4 or IPv6 hosts, and vice versa.

3. Costs:
1) Host change is required;
2) First-hop LDBR change is required to support site-controlled
traffic-engineering capability.
3) The ID->Locator mapping system is a new infrastructure to be deployed.
4) Proxy needs to be deployed for communication between RANGI-aware hosts
and legacy hosts.

4. Documents:
RANGI => http://tools.ietf.org/id/draft-xu-rangi-01.txt.
RANGI Proxy => http://tools.ietf.org/id/draft-xu-rangi-proxy-01.txt.
RANGI Presentation on IETF76 =>
http://www.ietf.org/proceedings/09nov/slides/RRG-1.ppt

---

From: Lixia Zhang <[email-masked]>
Date: Mon, 14 Dec 2009 22:28:46 -0800

> Hmm. Don't you think that to some extent these should be orthogonal?

again strictly personal opinion: I think the two can be separable  
components but one does not exist independently from the other -- in  
a  rough sense I agree with Tony that mapping alone does not make a  
solution proposal.

> network
> space

I really hesitate to say that I've been old enough (dont feel that way  
anyway:) that I have seen a number of times in the past the attempts  
for solutions that would be "very general in nature". Do not recall  
any of those succeeded particularly well...

There is some basic difference between things that are minimal in  
design (e.g. IP) vs those that are very general in nature.

Lixia

---

From: Lixia Zhang <[email-masked]>
Date: Mon, 14 Dec 2009 22:29:30 -0800

got it

---

From: Lixia Zhang <[email-masked]>
Date: Mon, 14 Dec 2009 22:21:43 -0800

> indicate rough consensus.

(no hat) consensus should be explicitly solicited, rather than  
implicitly assumed.

BTW folks I'm having problems access the RRG WIKI page (when I tried  
to login, got database error), will try again later to get the current  
proposal candidates added there.

Lixia

---

From: Tony Li <[email-masked]>
Date: Tue, 15 Dec 2009 01:46:54 -0800

> (no hat) consensus should be explicitly solicited, rather than 

Fair.  In any case, we intentionally left the document open as it was 
subject to further revisions.

Further, it's not clear that the status of the document is really 
relevant to the discussion at hand.  Folks are welcome to use it if they 
want.

Tony

---

From: Tony Li <[email-masked]>
Date: Tue, 15 Dec 2009 01:49:46 -0800

Received.

T

---

From: Tony Li <[email-masked]>
Date: Tue, 15 Dec 2009 01:52:19 -0800

> we don't need a hierarchy from the start.

Brian,

Our recommendation is focused on providing an alternative routing 
architecture.  A mapping system is a fine component, but would not seem 
to provide a credible architecture by itself.

Tony

---

From: $witch <[email-masked]>
Date: Tue, 15 Dec 2009 12:30:05 +0100

>>  On Dec 14, 2009, at 8:21 AM, Tony Li wrote:
........
> relevant to the discussion at hand.  Folks are welcome to use it if they  

Hi, Tony, Lixia and all

consensus implies knowledge, that in turn require effort, time and so on

am used to read papers posted on list, tryng to reduce the knowledge-gap  
in "quiet-mode".

but if there is need of people saying "yes" or "no" : here i am

about http://www.firstpr.com.au/ip/ivip/RRG-2009/constraints/

like to express two notices :

a) IPv4 by itself is the greatest engine that move people and companies to  
IPv6; just an example between many, many others.
one IPv4 "public" address can cost upto 2 euro/month (at least in  
berlusconi-land) while an IPv6 /48 network is (now) for free.

b) people that had not a first-hand experience of the kind of matters you  
are managing, is hardly consensus-able; but many of them will adopt new  
solutions for a wide typology of reasons and, at least, for curiosity.

so, in short and for what i understood : ok, the document is good, i agree.

wish you all RRGs a great week.

Alessandro

---

In protocol design, perfection has been reached not when there is nothing  
left to add, but when there is nothing left to take away. RFC 1925

---

From: "Flinck, Hannu (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 17 Dec 2009 11:02:03 +0200

Most of the scalability discussions we have had are dealing exactly with
the mapping system, not how to tunnel or rewrite the addresses. The
mapping system is the architecture that uses the tunnels or address
manipulation based on some address structure.  A tunneling
scheme/address rewrite together with an address structure is not
sufficient for scalabilty. 

- Hannu

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On 
>Behalf Of ext Tony Li
>Sent: Tuesday, December 15, 2009 11:52
>To: Brian E Carpenter
>Cc: [email-masked]; Lixia Zhang
>Subject: Re: [rrg] belated msg: further description of the 
>recommendation process
>
>Brian E Carpenter wrote:
>
>>> Mapping systems are obviously a component of a solution but are not 
>>> by themselves a solution.  To be considered seriously, they 
>should be 
>>> used in conjunction with some network layer solution.
>> 
>> space proves to fall short. Also I feel it should support hierarchy, 
>> even if we don't need a hierarchy from the start.
>
>
>
>Brian,
>
>Our recommendation is focused on providing an alternative 
>routing architecture.  A mapping system is a fine component, 
>but would not seem to provide a credible architecture by itself.
>
>Tony
>

---

From: Patrick Frejborg <[email-masked]>
Date: Thu, 17 Dec 2009 11:57:25 +0200

Hi Lixia and Tony,

a summary of the hIPv4 framework follows

1. Key idea
The hierarchical IPv4 framework is adding scalability in the routing
architecture by introducing hierarchy in the IPv4 address space. The
hIPv4 addressing scheme is divided in two parts, the Area Locator
(ALOC) address space which is globally unique and the Endpoint Locator
(ELOC) address space which is only regionally unique. The ALOC and
ELOC prefixes are added as an IP option to the IPv4 header as
described in RFC 1385. Instead of creating a tunneling (i.e. overlay)
solution a new routing element is needed in every ALOC realm, a
Locator Swap Router - the current IPv4 forwarding plane remains
intact, also no new routing protocols or mapping systems are required.
The control plane of the ALOC realm routers needs some modification in
order for ICMP to be compatible with the hIPv4 framework. When an area
(one or several AS) of an ISP has become an ALOC realm only ALOC
prefixes are exchanged with other ALOC realms. Directly attached ELOC
prefixes are only inserted to the RIB of the local ALOC realm, ELOC
prefixes are not distributed in the DFZ. Multi-homing can be achieved
in two ways, either the enterprise request an ALOC prefix from the RIR
(this is not recommended) or the enterprise receive the ALOC prefixes
from their upstream ISPs - ELOC prefixes are PI addresses and remains
intact when a upstream ISP is changed, only the ALOC prefixes is
replaced. When the RIB of DFZ is compressed no longer an ingress
router knows if the destination prefix is available or not, only
attachment points (ALOC prefixes) of the destination prefix are
advertised in the DFZ. Thus the endpoints must take more
responsibility for their sessions. This can be achieved by using
multipath enabled transport protocols, such as SCTP and MPTCP, at the
endpoints. The multipath transport protocols also provides a session
identifier, i.e. verification tag/token, thus the location and
identifier split is carried out - site mobility, endpoint mobility and
mobile site mobility is achieved. DNS needs to be upgraded, to resolve
the location of an endpoint it must have one ELOC value (current
A-record) and at least one ALOC value (in multi-homing solutions there
will be several ALOC values for an endpoint). The hIPv4 framework can
also be integrated to a map-and-encapsulate solution; the ITR/ETR
needs to incorporate the hIPv4 stack and might use a multipath enabled
transport protocol to serve the hIPv4/multipath transport protocol
enabled endpoints.

2. Gains:
1) Improved routing scalability: Adding hierarchy in the address space
enables a hierarchy in the routing architecture. Early adapters of an
ALOC realm will no longer carry the RIB of the DFZ – only ELOC
prefixes of directly attached networks and ALOC prefixes from other
service provider that have migrated.
2) Scalable support for traffic engineering: Multipath enabled
transport protocols are recommended to achieve dynamic load-balancing
of a session. Support for Valiant Load-balancing schemes has been
added to the framework; more research work is required around VLB
switching.
3) Scalable support for multi-homing: Only attachment points of a
multi-homed site are advertised in the DFZ, DNS will inform the
requester how many attachment points the destination endpoint has. It
is the initiating endpoints choice/responsibility which attachment
point is used; endpoints using multipath enabled transport protocols
can make use of several attachment points for a session.
4) Simplified Renumbering: When changing provider, the local ELOC
prefixes remains intact, only the ALOC prefix is changed on the
endpoints.
5) Decoupling Location and Identifier: The verification tag (SCTP) and
token (MPTCP) can be considered to have the characteristics of a
session identifier and thus a session layer is created between the
transport and application layer in the TCP/IP model
6) Routing quality: The hIPv4 framework introduce no tunneling
mechanisms, only a swap of the IPv4 header and locator header at the
destination ALOC realm is required, thus current routing algorithms
are preserved as such. Valiant Load-balancing might be used as a new
forwarding mechanism.
7) Routing Security: Similar as with today’s DFZ, except that ELOC
prefixes can not be high-jacked (by injecting a longest match prefix)
outside an ALOC realm (improved security)
8) Deployability: The hIPv4 framework is an evolution of the current
IPv4 framework and is backwards compatible with the current IPv4
framework. Sessions in a local network and inside an ALOC realm might
in the future still use the current IPv4 framework.

3. Costs and issues:
1) Upgrade of the stack at an endpoint or the endpoint should make use
of an ITR/XTR
2) In a multi-homing solution the border routers should be able to
apply policy based routing upon the ALOC value in the locator header
3) New policies must be set by the RIRs
4) Short timeframe before the expected depletion of the IPv4 address
space occurs
5) Will enterprises give up their global allocation of the current
IPv4 address block they have gained?
6) Co-ordination with MPTCP is highly desirable

http://tools.ietf.org/html/draft-frejborg-hipv4-04
(a description of how map-and-encapsulate can be integrated to the
hIPv4 framework is missing, it is on the to-do list and a presentation
has been sent to the rrg-list)

-- patte

---

From: "Yangyang Wang" <[email-masked]>
Date: Fri, 18 Dec 2009 00:35:09 +0800

Hi Lixia, Tony, and all,

    The following is a summary of our proposal  "name overlay (NOL) 
service for scalable Internet routing". It is at preliminary stage for comments
and hope that it can give some contribution to scaling issue.

1. key idea:
----------------
The basic idea is to add a name overlay (NOL) on the existing TCP/IP stack.

Its functions include: 

1) host names configuration, registration and authentication; 

2) Initiate and manage transport connection channels (i.e., TCP/IP connections) by name; 

3) keep application data transport continuity for mobility. 

    At the edge network, we introduce a new type of gateway NTR (Name Transfer 

Relay), which block the PI addresses of edge networks into upstream transit networks. 

NTRs performs address and/or port translation between blocked PI addresses and 

globally routable addresses, which seem like today’s widely used NAT/NAPT devices. 

Both legacy and NOL applications behind a NTR can access the outside as usual. To 

access the hosts behind a NTR from outside, we need to use NOL traverse the NTR 

by name and initiate connections to the hosts behind it. 

    Different from proposed host-based ID/Locator split solutions, such as HIP, Shim6, 

and name-oriented stack, NOL doesn’t need to change the existing TCP/IP stack, 

sockets and their packet formats. NOL can co-exist with the legacy infrastructure, 

the core-edges separation solutions (e.g., APT, LISP, Six/one, Ivip, etc.)

2. gains:

-------

1) Reduce routing table size: Prevent edge network PI address into transit netwok by 

    deploying gateway NTR

2) Traffic Engineering: For legacy and NOL application initiating session, the incoming 

    traffic can be directed to a specific NTR by DNS answer for names. In addition, for 

    NOL application, its initial session can be redirected from one NTR to other appropriate 

    NTRs. These mechanisms provide some support for traffic engineering.

3) Multi-homing: When a PI address network connects to Internet by multi-homing with 

    several providers, it can deploy NTRs to block the PI addresses into provide networks. 

    And the NTRs can be allocated PA addresses from the upstream providers and store 

    them in NTRs’ address pool. By DNS query or NOL session, any session that want to 

    access the hosts behind the NTR can be delegated to a specific PA address in the NTR 

    address pool.

4) Mobility: NOL layer manage the traditional TCP/IP transport connections, and keeps 

    application data transport continue by setting breakpoints and sequence numbers in data 

    stream.

5) No need to change TCP/IP stack, sockets and DNS system. 

6) No need for extra mapping system.

7) NTR can be deployed unilaterally, just like NATs

8) NOL applications can communicate with legacy applications.

9) NOL can be compatible with existing solutions, such as APT, LISP, Ivip, etc.

10) End user controlled multi-path indirect routing based on distributed NTRs. 

      This will give benefits to the performance-aware applications, such as, MSN, Video 

       streaming, etc. 

3. costs

------

1) Legacy applications have trouble with initiating access to the servers behind NTR. 

    Such trouble can be resolved by deploying NOL proxy for legacy hosts, or delegating 

    globally routable PA addresses in NTR address pool for these servers, or deploying 

    server proxy outside NTR.

2) It may increase the number of entries of DNS, but not drastic, because it only 

    increases DNS entries in domains granularity not hosts. The name used in NOL, 

    for example, just like email address [email-masked]. The needed DNS entries and 

    query is just for "domain.net", and The NTR knows "hostnames". The DNS entries will not 

    only be increased, but its dynamic might be agitated as well. However the scalability and 

    performance of DNS is guaranteed by name hierarchy and cache mechanism.

3) Address translating/rewriting costs on NTRs.

4. documents

--------------

Current documents are in the attachment of this email, including a slide and a summary.

---

From: Michael Menth <[email-masked]>
Date: Tue, 22 Dec 2009 16:40:43 +0100

Hi all,

here is the summary of GLI-Split.

Merry Christmas and a happy new year!

    Michael

Proposal: Global Locator, Local Locator, and Identifier Split (GLI-Split)

Key Idea:

GLI-Split implements a separation between global routing (in the
global Internet outside edge networks) and local routing (inside
edge networks) and  using global and local locators (GLs, LLs). In
addition, a separate static identifier (ID) is used to identify
communication endpoints (e.g. nodes or services) independently of
any routing information. Locators and IDs are encoded in IPv6
addresses to enable backwards-compatibility with the IPv6
Internet. The higher order bits store either a GL or a LL while
the lower order bits contain the ID. A local mapping system maps
IDs to LLs and a global mapping system maps IDs to GLs. The full
GLI-mode requires nodes with upgraded networking stacks and
special GLI-gateways. The GLI-gateways perform stateless locator
rewriting in IPv6 addresses with the help of the local and global
mapping system. Non-upgraded IPv6 nodes can also be accommodated
in GLI-domains since an enhanced DHCP service and GLI-gateways
compensate their missing GLI-functionality. This is an important
feature for incremental deployability.

Gains:

The benefits of GLI-Split are
 * Hierarchical aggregation of routing information in the global
   Internet through separation of edge and core routing
 * Provider changes not visible to nodes inside GLI-domains
   (renumbering not needed)
 * Rearrangement of subnetworks within edge networks not visible
   to the outside world (better support of large edge networks)
 * Transport connections survive both types of changes
 * Multihoming
 * Improved traffic engineering for incoming and outgoing traffic
 * Multipath routing and load balancing for hosts
 * Improved resilience
 * Improved mobility support without home agents and triangle routing
 * Interworking with the classic Internet
   - without triangle routing over proxy routers
   - without stateful NAT

These benefits are available for upgraded GLI-nodes, but
non-upgraded nodes in GLI-domains partially benefit from these
advanced features, too. This offers multiple incentives for early
adopters and they have the option to migrate their nodes gradually
from non-GLI stacks to GLI-stacks.

Costs:

 * Local and global mapping system
 * Modified DHCP or similar mechanism
 * GLI-gateways with stateless locator rewriting in IPv6 addresses
 * Upgraded stacks (only for full GLI-mode)

Documentation:

GLI is only a theoretical proposal. A protocol simulation has been
shown at EuroView 2009. We believe that GLI-Split offers many
features and methods that may be reused in a future Internet
routing architecture. The full description is available at
http://www3.informatik.uni-wuerzburg.de/~menth/Publications/papers/Menth-GLI-Split.pdf

---

From: Lixia Zhang <[email-masked]>
Date: Wed, 23 Dec 2009 23:37:44 -0800

> sufficient for scalabilty.

Hi Hannu,

I agree that the mapping itself is a critical part of the  
architecture. However I believe a mapping proposal needs to go  
together with an overall architecture, because one needs to know where  
mapping happens, mapping what to what.
Take a simple example: ILNP has kind of mapping (implemented in DNS)  
and LISP has another kind of mapping, 2 different proposals have  
rather different mappings.

Lixia