Subject: Re: [rrg] Next topic: properties of identifiers

From: [email-masked]
Date: Tue, 14 Jul 2009 16:25:01 EDT

In einer eMail vom 14.07.2009 19:47:16 Westeuropäische Normalzeit schreibt  
[email-masked]:

On Jul  12, 2009, [email-masked] wrote:

> Let's put it differently:  Incremental deployability requires still BGP
> to overcome the main  function of BGP which is the non-scalable way to
> disseminate all these  hundred thousands of prefixes. The methods are  
> not
> new:  Remember  BGP-based dissemination of MPLS-VPN sites (just lacking
>  the goal to build ONE SINGLE "internet-VPN") : here the information   
> are
> labels, i.e. not IP addresses. Also remember LISP's  default mapper.
> Issueing a prefix of length 0 might attract traffic  destined for a  
> node
> which doesn't propagate its  traditional reachability prefixes anymore
> but just new routing info  for a new architecture, analogously to the
>  MPLS-labels.

Heiner -

I agree with the argument that IP  addresses could theoretically be
replaced in their role of locators.   Although I would add that the
feasibility of this heavily depends on the  deployment model:
Absolutely. The model must a) work, b) be incrementally deployable and c)  
solve all the problems that are due to the state-of-art though bad 
architecture:  abolish the scalability problem (even if the internet were a millions 
times  bigger),overcome the IPv4 address depletion issue, cater for 
multihoming,  make Moore's law  become applicable and finally  enable much better TE 
 by also providing the view to the rear ( who else would use THIS router 
for  transit to get to some destination down in the forward direction.)
I wouldn't emphasize all these  objectives if my model didn't  enable them 
:-)

LISP proxies are not a good example because they require IP  addresses
as locators to route packets towards a proxy.  On the other  hand, APT's
deployment model -- which calls for initial local deployment  and
subsequent expansion -- could facilitate the introduction of  new
locators.  Of course, those new locators would have to be suitable  for
use across administratively discontinuous providers, like IP  addresses.
 
LISP is an attempt to rescue the existing model and the existing  
paradigms.(called jack-up model)
While most people praise the existing paradigms and e.g. think that  
caching is a nice enhancement thereof  I rather believe that caching is a  
built-in repair system of an old/bad architecture from the start.
 
Heiner

- Christian

---

From: [email-masked]
Date: Sat, 18 Jul 2009 16:31:44 EDT

In einer eMail vom 18.07.2009 17:10:05 Westeuropäische Normalzeit schreibt  
[email-masked]:

>  Lixia Zhang wrote:
> ...
>> But I would like to step up a level  and repeat what I said earlier:
>> 1/ I do not think it is in our  charter to define how many  
>> identifiers we ought to have, or  what they ought to be.
>> 2/ Our job is to figureout scalable routing  architecture.
>> 3/ We need to have a good understanding about the  interplay between  
>> addresses and identifiers, no less and  also no more.

IMHO, at first it takes a clear idea about an architecture, i.e. about  
network components and how they interrelate. These network components need  to 
be identified, of course. However I don't think that it is helpful to  
define identifiers in the first place and then look for an architecture which  
complies with these identifiers.
 
With MAC + IPv4 address we have 10 octets. Are they used best ? Why is  
there no co-working with IEEE such that the best exploitation can be  made from 
having 10 octets altogether ? 
LISP needs an aditional header. I can anticipate that on day soon  a second 
LISP-header is prepended to the LISP-header.
My experience: if there is no discipline and no strive for optimal  
utilization, but egoistic behavior instead, then
even more available octets won't help (like MAC+IPv6 =22 octets).
 
Some email mentioned that the architecture should not just solve one  
particular problem (scalability) but should enable more flexible and better  
routing. Is everyone happy with the existing Multicast solutions ???
Is everyone satisfied by having no rear mirrow for recognizing all those  
routers which would use the current one for transit? Is everyone convinced 
that  the orthogonality of intra and inter-domain routing is the best ever 
after  ?
 
Heiner

---

From: [email-masked]
Date: Sun, 19 Jul 2009 06:49:56 EDT

Resent for dispatching a spelling mistake primarily :-)
In einer eMail vom 18.07.2009 23:33:32 Westeuropäische Normalzeit schreibt  
[email-masked]:

IMHO, at first it takes a clear idea about an architecture, i.e. about  
network components and how they should interrelate. These network  components 
need  to be identified, of course. However I don't think that it  is helpful 
to define identifiers in the first place and then look for an  architecture 
which complies with these identifiers.

routing: 
 
- Is everyone happy with the existing Multicast solutions ???
 
- Is everyone satisfied by having no rear mirror for recognizing all those  
routers which would use the current one for transit? And by never being 
able to  add one (e.g. for the sake of TE traffic balancing etc.)
 
- Is everyone convinced that the orthogonality of intra and  inter-domain 
routing is the best ever after ?
 
Heiner

---

From: [email-masked]
Date: Sun, 26 Jul 2009 04:22:11 EDT

In einer eMail vom 25.07.2009 20:24:19 Westeuropäische Normalzeit schreibt  
[email-masked]:

Well, to  me, central to the notion of the Internet architecture and more  
specifically to a routing architecture is the notion of topology.  It  
would seem somewhat challenging to be able to describe topology without  
being able to describe a graph.  And if we want to be able to  describe a 
graph, we need to be able to articulate the nodes and edges in  that 
graph.  I don't see how to do this with just service  identifiers.

Regards,
Tony

Right.For the same reason I don't understand either to have a service  
identifier discussion here.
Routing is about recognizing and utilizing topology.By knowing the topology 
 you can see all paths in forward direction wrt a given destination as well 
as  which network part would use you for transit (the rear mirror).
You have much less by assembling hundred thousands of routes instead.
 
Heiner

---

From: [email-masked] (Noel Chiappa)
Date: Sun, 26 Jul 2009 09:33:16 -0400 (EDT)

> From: Tony Li <[email-masked]>

    > Well, to me, central to the notion of the Internet architecture and
    > qmore specifically to a routing architecture is the notion of topology.
    > It would seem somewhat challenging to be able to describe topology
    > without being able to describe a graph.

I agree pretty much 100% with all you've said, but one minor caveat (and the
credit for this observation goes to someone else, but I can't remember who,
or what mailing list - sorry): using a graph as a model of the network
connectivity (probably a more accurate term than 'topology', but I think
we're stuck with the latter now) usually works very well, but... it is not
necessarily the be-all and end-all. For some networks (e.g. wireless) it may
not work so well. Graphs do have issues in other cases too, e.g. this one:

  http://mercury.lcs.mit.edu/~jnc/tech/abstraction_flame.html

Having said that, I don't have what I consider a superior alternative, for
the mathematical model of network connectivity, here in my hip-pocket, ready
to offer. Like a like of things in routing, there are trade-offs: accuracy
versus amount of information needed to describe a particular connectivity
pattern is one, and for _most_ networks, using a graph to model the
connectivity does really, really well on this.

I don't know how difficult it would be to come up with a routing architecture
that could support multiple models simultaneously (e.g. a graph for most of
the network, but other stuff for local regions, e.g. perhaps something
geographic for a wirless network, etc, etc). My intuition says it would
probably be hard (impossible) to design an architecture where one could
incrementally deploy new models in an interoperable way.

But all that is pretty advanced - we're still a long way from an architecture
which would allow even simpler stuff, like multiple path-selection algorithms
with incremental deployment of new ones, local control of abstraction, etc. (I
mean a long way in deployment terms - a vaguely plausible design was done a
long time ago.)

	Noel

---

From: [email-masked] (Noel Chiappa)
Date: Sun, 26 Jul 2009 10:08:07 -0400 (EDT)

> From: [email-masked]

    > By knowing the topology you can see all paths in forward direction wrt
    > a given destination as well as which network part would use you for
    > transit (the rear mirror). You have much less by assembling hundred
    > thousands of routes instead.

True - but can we expect routers to have a _complete_ map of the network, or
not? Even leaving aside technical issues such as the amount of information,
some sites may wish to 'hide' information about the internals of their
network.

So then you have to work out how to make the routing work when entities do
not have complete maps...

	Noel

---

From: [email-masked]
Date: Sun, 26 Jul 2009 13:22:16 EDT

> thousands of routes instead.

True - but  can we expect routers to have a _complete_ map of the network, 
or
not?  
Of course not (this is not even required in a multi-area ospf  
network).Instead Hierarchy is the clue for coping with scalability. But  there have been 
many many (failing) attempts so far : Nimrod,  PNNI,  ISLAY, Brian's, 
Rangi, CLNP, HAIR, LISP (2-staged), and now  (N)-DIF. Also E.164.Non of these 
caters for a "sliding" hierarchy such that  every node is (well, almost) in the 
middle of its nearest surrounding topology  at lowest level, followed by 
more and more sparsed topologies at higher levels,  the more they are remote. 
Instead they all are static, loaded with political  and/or ISP-sensitive 
dependencies.

Even  leaving aside technical issues such as the amount of information,
some  sites may wish to 'hide' information about the internals of  their
network.

Sure, and also while some other internals might be solicited to the  
outside. But these are well-known challenges. There are more in addition: How to  
enable such a sliding hierarchy. How to implement a hierarchy where strict 
links  do not only show up inside the immediate neighborhood but 
interconnect,  eventually, routers which are 20 000 km away from each other.

>not have complete maps...
 
... yes, and where there are also entities around which aren't aware of  
such a new technology at all.

Noel

Heiner