Subject: Re: [rrg] RRG recommendation

From: [email-masked]
Date: Tue, 10 Nov 2009 04:32:08 EST

In einer eMail vom 10.11.2009 08:04:50 Westeuropäische Normalzeit schreibt  
[email-masked]:

the  presentation slides are  at:
http://www.nanog.org/meetings/nanog44/presentations/Wednesday/Zhang_Wed_N44.
pdf

Quote from these slides:
The problem: routing too flat
solution: add more hierarchies in addressing & routing
 
Yes, but do hierarchies right. There have been multiple hierarchical  
proposals which did the hierarchical aggregation in the wrong way. What it takes  
is a "sliding hierarchy" as provided by TARA so that each router is fairly 
in  the middle of the hierarchy and never at the very rim. 
Analogy: Imagine a city map for Istanbul, Turkey, with a Western part  
containing each single street and an Eastern part being a highly aggregated road 
 map for entire Asia. 
 
Or take Compact Routing studies which mentioned stretch factor 17  !!! 
Hierarchy is by no means a reason to enforce a  path which is longer  than the 
shortest one! Neither when being in the middle or at the rim  ("Istanbul").
 
How many hierarchical levels is the right number? Who says "the less the  
better" is wrong.
 
I have my doubts that the routing folks have a proper  understanding wrt 
hierarchies.
 
Heiner

---

From: Lixia Zhang <[email-masked]>
Date: Tue, 10 Nov 2009 06:44:28 -0800

On Nov 10, 2009, at 1:32 AM, [email-masked] wrote:

> In einer eMail vom 10.11.2009 08:04:50 Westeuropäische Normalzeit  
> schreibt [email-masked]:
>
>> http://www.nanog.org/meetings/nanog44/presentations/Wednesday/Zhang_Wed_N44.pdf
>>
>
> Quote from these slides:
> proposals which did the hierarchical aggregation in the wrong way.  
> What it takes is a "sliding hierarchy" as provided by TARA so that  
> each router is fairly in the middle of the hierarchy and never at  
> the very rim.
> Analogy: Imagine a city map for Istanbul, Turkey, with a Western  
> part containing each single street and an Eastern part being a  
> highly aggregated road map for entire Asia.
>
> Or take Compact Routing studies which mentioned stretch factor  
> 17 !!! Hierarchy is by no means a reason to enforce a  path which is  
> longer than the shortest one! Neither when being in the middle or at  
> the rim ("Istanbul").
>
> How many hierarchical levels is the right number? Who says "the less  
> the better" is wrong.
>
> I have my doubts that the routing folks have a proper understanding  
> wrt hierarchies.
>
> Heiner

Hi Heiner, a couple comments here.

1/ one needs to read this with the understanding of its context--the  
quote you picked reflected understanding 15 years back.
the world has changes in significant ways since then
We understand much better now too.

2/ most importantly, I was calling attention to Postel's comments on  
slides 7 & 8: these quotes were taken from the meeting minutes then:

- “Transport layer ID is not an issue that we
    need be concerned with for now. Once we
    decide what to do for IP addresses, then
    transport people can easily figure out how
    they may use the address.”

- “We must avoid circular dependencies;

- “we must define a substrate of the
    system that can operate without DNS. ...

- “we must not depend on DNS to
    bootstrap the core operation of the
    system”

Personally I believe these design guidelines still hold true today.

Lixia

---

From: Tony Li <[email-masked]>
Date: Tue, 10 Nov 2009 11:28:30 -0800

>    they may use the address.”

Well, what we already know is that we want our routing tokens to be 
changeable.  We need hierarchy in the address space to provide 
scalability.  We have seen that we need to form that hierarchy on the 
topology, otherwise we have to morph the topology to fit the hierarchy, 
and morphing the topology is expensive.  So when a host changes its 
position in the topology, the routing token needs to change.

Unfortunately, that breaks the transport connection.

We already understand enough about the routing token and the transport 
token to understand that we need to fix this overloading.

>    bootstrap the core operation of the

Relevance?  I have yet to see one proposal make this mistake.

Note that using the DNS and creating a circular dependency are two 
different things.  We're already at the point where DNS is a fundamental 
requirement for Internet operations.  If you cannot resolve 
www.google.com, www.yahoo.com and www.cnn.com, then for all practical 
purposes, the net is down.

Tony

---

From: Scott Brim <[email-masked]>
Date: Thu, 12 Nov 2009 05:08:53 +0900

> token to understand that we need to fix this overloading.

But it's not routing's problem that transport misuses location-dependent
information.  Lixia's quote is quite true.

---

From: Tony Li <[email-masked]>
Date: Wed, 11 Nov 2009 17:06:06 -0800

Scott,

> information.  Lixia's quote is quite true.

The fact that transport is overloaded on top of routing makes it 
routing's responsibility to get out from underneath.  Transport is fat 
dumb and happy where it is.  If routing does not force the change, then 
we have the (unacceptable) status quo.

Regards,
Tony

---

From: Lixia Zhang <[email-masked]>
Date: Mon, 16 Nov 2009 23:29:09 -0800

On Nov 10, 2009, at 11:28 AM, Tony Li wrote:

> Lixia Zhang wrote:
>
>> 2/ most importantly, I was calling attention to Postel's comments  
>> on slides 7 & 8: these quotes were taken from the meeting minutes  
>> then:
> topology,

the above seems a general statement that everyone would agree.
the real question is: are we talking about a single address hierarchy  
that everyone's routing table would conform to, or somewhat different  
hierarchies as viewed from different ASes...

> otherwise we have to morph the topology to fit the hierarchy, and  
> morphing the topology is expensive.  So when a host changes its  

I could not decipher the last sentence: when a host changes its  
attachment point, its IP address changes -- do you mean routing token  
= IP address?
> Unfortunately, that breaks the transport connection.

depends.
there exist multiple implementations today that do not break transport  
connections when host change IP addresses.

> We already understand enough about the routing token and the  
> transport token to understand that we need to fix this overloading.
>
>

Do not depend on DNS to get packet delivered.

> different things.  We're already at the point where DNS is a  
> fundamental requirement for Internet operations.

for Internet applications.

>  If you cannot resolve www.google.com, www.yahoo.com and  
> www.cnn.com, then for all practical purposes, the net is down.

yes, from end users view point.
But we still want to be able to send IP packets even when DNS is done.

Lixia

---

From: Lixia Zhang <[email-masked]>
Date: Mon, 16 Nov 2009 23:48:04 -0800

On Nov 11, 2009, at 5:06 PM, Tony Li wrote:

> routing's responsibility to get out from underneath.  Transport is  
> fat dumb and happy where it is.  If routing does not force the  
> change, then we have the (unacceptable) status quo.
>
> Regards,
> Tony

the fact that TCP uses IP address for its own connection identifier  
makes it broke when the incoming interface address changes (either  
host moved, or packets just coming from a different interface)

So all we need to do to fix this specific problem is to find TCP a  
topologically independent identifier to use (e.g. HIP as one example,  
though I do not mean to endorse HIP here, just as an example)

Lixia

---

From: Patrick Frejborg <[email-masked]>
Date: Tue, 17 Nov 2009 11:00:45 +0200

Hi Lixia,

A comment inline

On Tue, Nov 17, 2009 at 9:29 AM, Lixia Zhang <[email-masked]> wrote:
>> changeable.  We need hierarchy in the address space to provide scalability.
>> We have seen that we need to form that hierarchy on the topology,
>
> the real question is: are we talking about a single address hierarchy that
> everyone's routing table would conform to, or somewhat different hierarchies
> as viewed from different ASes...
>
>> otherwise we have to morph the topology to fit the hierarchy, and morphing
>> the topology is expensive.  So when a host changes its position in the
>> topology, the routing token needs to change.
>
> I could not decipher the last sentence: when a host changes its attachment
> point, its IP address changes -- do you mean routing token = IP address?
>>
If you have hierarchy in the address space you will have two types of
locators (IP addresses), one locator that is describing how your
endpoint is connected to the local network (ELOC) and the second
locator describing how your local network is attached to the Internet
(ALOC). If the endpoint changes inside the local network (endpoint
mobility) then the connection gets disconnected, you would need Mobile
IP or HIP in order to survive. But if your attachment locator  (ALOC)
changes in a multi-homing solution the ELOC will not change, not for
the local endpoint nor for the remote endpoint - it is only the remote
or local ALOC value that changes when network failure occurs. And
today the applications do not see any ALOC values at the API, only
ELOC values, i.e. local and remote IP addresses. So when the border
routers detect a network failure, the border router could replace the
ALOC value with the backup path's ALOC value, route the packets via
the backup path using policy based routing and the endpoints can
continue without knowing that a redundant path has been taken. Or the
border router could send an ICMP message to the endpoints so that they
are aware that ALOC values changes and the endpoints changes the ALOC
values themselves - but the application is not aware of the change
since the ELOC values remains intact.

But then we have the security issues - it would be a nice tool for the
dark side to hijack connections by sending out ICMP messages form the
Internet, wouldn't it?
So something needs to be added somewhere, IMO the transport layer
should carry session identifier so that the endpoints are aware of the
change in the path, or the endpoints negotiate the change. And even
better if the transport layer is multi-path capable, load balancing is
achieved and also a much faster network convergence for the
application can be provided. And endpoint mobility inside the local
network can also be supported.

I'm working on to add an appendix in my draft for the scenario above,
adding a more detailed description than above. It seems that it is
possible to migrate from a multi-homing solution towards a
multi-pathing solution if there is a little bit more intelligence in
the endpoints - outcome is that the workload of the network gets
decreased - a better balance between the endpoints and network is
achieved.
It will though take some time before it is ready (time constraints) -
I also need to add a section regarding NAT, thanks to Fred Templin's
presentation I found a use case for NAT.

-- patte

>> requirement for Internet operations.
>
>>  If you cannot resolve www.google.com, www.yahoo.com and www.cnn.com, then
>> for all practical purposes, the net is down.
>
> _______________________________________________
> rrg mailing list
> [email-masked]
> http://www.irtf.org/mailman/listinfo/rrg
>

---

From: Tony Li <[email-masked]>
Date: Tue, 17 Nov 2009 07:46:13 -0800

> hierarchies as viewed from different ASes...

First, 'address' is a horribly overloaded term that we should simply 
excise from our discussions.  We cannot have a semantically useful 
conversation if we cannot have common, precise terminology.

I'm going to interpret your 'address' in the above to be purely a 
routing token (a.k.a., a locator).  Yes, I think we agree that we need 
multiple namespaces, with at least one locator and one identifier namespace.

You _could_ have more, but it would seem to fly in the face of Occam's 
razor.  That said, it's not an unthinkable architecture.

>> So when a host changes its 
> attachment point, its IP address changes -- do you mean routing token = 
> IP address?

Again, you're falling trap to the vague meaning of 'address'.  Yes, when 
a host changes its point of attachment, its locator needs to change.

> connections when host change IP addresses.

Do tell.  Normal TCP will not do this.

> Do not depend on DNS to get packet delivered.

Sorry, we already broke that.  When DNS is down, the net is down.  ;-)

> But we still want to be able to send IP packets even when DNS is done.

Well, assuming that the end user already has the necessary bits, I have 
yet to see any proposal that will not deliver the packets, even if DNS 
is down.  Did I miss something?  With ILNP, it will revert to legacy 
IPv6 semantics, which seems perfectly acceptable.

Note that all proposals are going to have issues when their mapping 
system is down.  Again, the real point of the original point is to avoid 
  the circular dependency, where you can't ever get the system up. 
Again, I haven't seen anyone fall into that trap.  And it applies to the 
mapping system, not just DNS.

Tony

---

From: Dae Young KIM <[email-masked]>
Date: Wed, 18 Nov 2009 05:58:40 +0900

Hi,

I'm joining the school of ID/Locator separation, and would like to propose
the following architecture:

A. Fundamentals:
    o Skeletons:
         o ID is global, Locator is local(private) to AS.
         o Keep use of DNS, with some extension.
         o TCP works on ID, IP on Loctor, Gateways(BGP) on AS #.
         o Gateways advertises only AS #s, not network prefixes.
    o Corollaries:
         o Number space of AS is limited to 2^^16(64K) in one tier.
         o AS tier recurs hierarchically, downward and upwards(or inwards
and outwards). In each tier, the maximum number of ASs is limited to 2^^16.
         o AS(cloud) can float within and across tiers. AS(ISP) can change
is neighbor relation anytime in the course of its existence within and
across the tier architecture.
    o Implementation choices:
         o Take IPv6 and IPv6 addresses as IDs. That is, IP addresses in the
current Internet infrastructure is to be used as IDs, not anymore as
locators.
         o DNS is extended to serve not only name-to-address(ID) mapping but
also ID-to-AS mapping.

B. Scenario of outgoing communication example:
    1. DNS returns the remote (glabal) ID as well as the AS number it
belongs to.
    2. TCP establishes connections by use of ID.
    3. TCP requests, to IP, transmission of segments with the AS number, as
a parameter, of the domain where the destination peer belongs.
   4a. If the target AS is local domain, IP uses a local locator to deliver
the packet.
   4b. If the target AS is foreign, IP uses a local locator to deliver the
packet to the egress gateway(BGP) router.
   5. Local gateway relays the packet to one of the next hop gateways that
advertised the target AS #.

C. Scenario of incoming communication example:
    (Your homework.)

D. Consequences.

    o Gateway routing table doesn't explode, never exceeds 64K(2^^16).
    o AS tier can recurs, theoretically, indefinitely. The whole Internet
can scale to infinity.
    o NAT is a norm, not an evil.
    o The current IP address management infrastructure won't be abandoned.
They operate exactly the same way as it does. Only that the number is now
used as IDs, not for locators.
    o The current DNS infrastructure is maintained, only with a bit of
extension. It now has to keep database of (domain name, ID, AS number)
tuples.
    o Minimal disturbance to the current Internet infrastructure, with a
path out for sustainable scalability.

I'm also attaching the text. The idea has yet to be elaborated more and be
documented in far more detail in a proper form.

Your comments are solicited.

On Wed, Nov 18, 2009 at 12:46 AM, Tony Li <[email-masked]> wrote:

> First, 'address' is a horribly overloaded term that we should simply excise
> from our discussions.  We cannot have a semantically useful conversation if
> we cannot have common, precise terminology.
>
> I'm going to interpret your 'address' in the above to be purely a routing
> token (a.k.a., a locator).  Yes, I think we agree that we need multiple
> namespaces, with at least one locator and one identifier namespace.
>
>  So when a host changes its position in the topology, the routing token
>>> needs to change.
>>>
>>
> Again, you're falling trap to the vague meaning of 'address'.  Yes, when a
> host changes its point of attachment, its locator needs to change.
>
>
>
> Well, assuming that the end user already has the necessary bits, I have yet
> to see any proposal that will not deliver the packets, even if DNS is down.
>  Did I miss something?  With ILNP, it will revert to legacy IPv6 semantics,
> which seems perfectly acceptable.
>
> Note that all proposals are going to have issues when their mapping system
> is down.  Again, the real point of the original point is to avoid  the
> circular dependency, where you can't ever get the system up. Again, I
> haven't seen anyone fall into that trap.  And it applies to the mapping
> system, not just DNS.
>
> Tony
>
>

-- 
Regards,

DY
http://cnu.kr/~dykim <http://cnu.kr/%7Edykim>

---

From: Danny McPherson <[email-masked]>
Date: Tue, 17 Nov 2009 21:46:40 -0700

> Sorry, we already broke that.  When DNS is down, the net is down.  ;-)

Com'n Tony, that's a little disingenuous (unless you 
were strictly kidding and not just smirking there :-)

The point is that circular dependencies are bad, and a routing 
and forwarding substrate function that relies on DNS reachability 
isn't particularly desirable.

-danny

---

From: Shane Amante <[email-masked]>
Date: Tue, 17 Nov 2009 21:57:14 -0700

Danny,

> were strictly kidding and not just smirking there :-)

I don't think he was, particularly in light of the vast majority of end-users perception that regardless of whether DNS fails or IP connectivity to a Web site fails the "Internet is down".

> isn't particularly desirable.

One way to avoid this is to number the DNS and/or mapping system components [exclusively] inside Locator space, thus there's no circular dependence on getting _to_ a "mapping resolver".  Thus, the routing system containing the set of LOC's does not have a circular dependency ...

-shane

---

From: Danny McPherson <[email-masked]>
Date: Tue, 17 Nov 2009 22:07:23 -0700

> I don't think he was, particularly in light of the vast majority of end-users perception that regardless of whether DNS fails or IP connectivity to a Web site fails the "Internet is down".

Yeah, I got that far :-)

> One way to avoid this is to number the DNS and/or mapping system components [exclusively] inside Locator space, thus there's no circular dependence on getting _to_ a "mapping resolver".  Thus, the…

I understood the distinction..  Perhaps not referring to it as "the DNS" 
would alleviate a great deal of confusion - and might even focus folks on 
more optimal mapping resolution mechanisms in the future (i.e., the current 
DNS is at least as broken as the routing system, methinks :-)

-danny

---

From: Shane Amante <[email-masked]>
Date: Tue, 17 Nov 2009 23:00:09 -0700

Danny,

On Nov 17, 2009, at 22:07 MST, Danny McPherson wrote:
> would alleviate a great deal of confusion

Apologies for the confusion; however, in the past on the list, some people have pointed out that there is a difference between "the DNS", the protocol, and (separately) DNS as currently deployed for hostname to IP address resolution.  I would agree that sub-optimal /implementations/ of the DNS have lead to poor experiences and/or operational practices.  OTOH, it's impossible to deny the existence proof that many multi-billion dollar organizations (e.g.: content providers of news, information, music, movies, etc.) depend on the successful functioning of the current DNS -- even with its flaws, (lack of DNSSEC probably being the most notable example).  Said differently, the organizations that understand the critical role that DNS plays in their day-to-day business *do* figure out the best practices to engineer and operate it, (or, even, outsource it to companies that *can*).  Those that don't, well I guess you know the answer there.  :-)

Ultimately, the point I would make (not necessarily to you, but others on the list) is that DNS as currently deployed gets a bad rap (perhaps, unjustifiably so); however, a lot of thought, engineering, etc. has gone into (and, is continuing to go into) "the DNS".  Thus, IMHO, it would be a mistake to dismiss "the DNS" as a potential ID-to-LOC mapping system out-of-hand, given the experience we as a community have with it and the dependence we already have on it.  Certainly there are things that can be done to improve "the DNS", but those are likely very well understood at this point vs. imagining and engineering a whole new mapping resolution system.

> - and might even focus folks on 

See above.  :-)

-shane

---

From: Yakov Rekhter <[email-masked]>
Date: Wed, 18 Nov 2009 04:59:46 -0800

Tony,

[clipped...]

> mapping system, not just DNS.

Another point to consider is to minimize the total number of
mapping systems in the whole system. Or to put it differently,
try to maximize re-use of the mapping systems. Use of dynamic
DNS updates with ILNP is an example of this.

Yakov.

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 18 Nov 2009 22:39:36 +0900

Yakov,

Can you clarify which out of current proposals being discussed in RRG WG 
uses more then one mapping system within it's own entire system ?

Contrary to that claim there are number of proposals which use no new 
mapping plane at all so I am not clear which proposal(s) currently under 
consideration your message may be intended to refer to.

Thx,
R.

---

From: Christian Vogt <[email-masked]>
Date: Mon, 30 Nov 2009 00:45:53 -0500

On Nov 11, 2009, Scott Brim wrote:

> information.  [...]

Of course it is, because it encourages operators to use provider-
independent address space:  It requires provider-independent addresses
for multi-homing and traffic engineering.  And it makes renumbering
harder due to the use of referrals with topology semantics, unless you
use provider-independent addresses.

- Christian