Subject: RE: Architectural approaches to multi6

From: "Bound, Jim" <[email-masked]>
Date: Tue, 25 Mar 2003 15:33:40 -0500

> > No one uses FQDN's above IP till one gets to the Application layer.
> > Why
> > do you say this?
> 
> I don't think I was saying that people are doing this today.

Hmmm thought you did.  I misunderstood then.  My apologies then.

> 
> > Also we need a solution that does not assume this at all.
> 
> Why not?

WHen I say assume let me clarify.  By "assume" I mean, solution we end
up with won't work if all *sockaddr_DL references to Network Byte Order
addresses MUST become references to *char_foo_identifier strings.  I
will assume you know the ramfications to the stack above IP "virtual"
layer in the IP stack and then to what we often call "user" space where
the applications reside.  That is a non-starter.

> 
> > Doing this would at best be nice to have long term. THere is also no
> > way to enforce it.
> 
> So there we have our long term goal. If we can get there by using 16 
> byte values that look enough like IPv6 addresses to fool existing 
> implementations for a while but label them "identifier - not 
> to be used 
> in routing" I don't have a problem with that.

Yep that is what I was thinking architecturally.  But have not gone down
the affect to code yet.

That being said I believe Christian's point was quite valid.

Regards,
/jim

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 26 Mar 2003 01:30:10 +0100

> the applications reside.  That is a non-starter.

Yes, we need both a very long transition period during which certain 
parts can handle the new paradigm while others can't and first rate 
backward compatibility.

>> to be used in routing" I don't have a problem with that.

> Yep that is what I was thinking architecturally.  But have not gone 

There are lots of issues to consider before that.

> That being said I believe Christian's point was quite valid.

I'm not convinced by his example. Yes, applications will want to know 
something about the connectivity properties in order to adapt their 
behavior. But I don't see how access to the IP addresses is going to do 
that. An application can't tell if 3ffe:2500:310:1:203:93ff:fec5:2d28 
is an address used on a low-bandwidth, high-delay GPRS link or a 
high-bandwidth, low-delay fast ethernet link. The application needs to 
know which interface is going to be used, the address is immaterial. If 
the IP layer can move a session from one interface to another some 
additional glue is needed to provide this information on an ongoing 
basis.

However, there is another reason why people work around the DNS that I 
think may be a bigger problem: while the domain name system isn't open 
to trivial fakery like some other protocols (SMTP...) its security 
isn't stellar either.

The trouble with hardcoding addresses in configuration files is that 
invariably the addresses change and invariably it is next to impossible 
to find all the places they're stored beforehand. What we need here is 
something that isn't as fixed as a configuration file, but also isn't 
as ephemeral as information learned from the DNS.

---

From: "Dmitri Krioukov" <[email-masked]>
Date: Thu, 27 Mar 2003 17:15:48 -0500

After browsing through this thread I'd like
to ask the following question: how many people
on this list would agree that a scalable
*engineering* solution to the multihoming
problem can be based neither on routing as we
know it today nor on any future improved and
superior routing architecture (if such an
architecture is based on the graph-theoretical
network representation)? (I assume that any
address binding mechanisms (similar to DNS)
are not considered as a part of routing.)

Also, a somewhat related question: is handling
failures beyond the links between the multihomer
and its transit provider (such as failures of links
between providers and the rest of the world) a
requirement? That it is not is an implicit assumption
of my first question. If it is (like it seemingly
follows from the requirement ID but not from Christian's
experiment), then a solution can only be routing-based,
and, hence (how many would agree?), it cannot be
scalable.

thanks,
--
dima.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Fri, 28 Mar 2003 00:03:28 +0100

On donderdag, maa 27, 2003, at 23:15 Europe/Amsterdam, Dmitri Krioukov  
wrote:

> superior routing architecture

I wouldn't:  
http://www.ietf.org/internet-drafts/draft-van-beijnum-multi6-isp-int- 
aggr-00.txt

There's also the current practice of announcing a more specific out of  
A's aggregate to B. Even if the more specific is filered so traffic  
ends up with A, if A and B peer it can still reach the destination over  
B.

> requirement?

For some users: yes.

> That it is not is an implicit assumption

I don't see how your conclusion follows from your premise. Adding a  
level of indirection (such as the identifier/locator separation) would  
handle this nicely.

---

From: Peter Tattam <[email-masked]>
Date: Fri, 28 Mar 2003 11:59:09 +1100 (EST)

> are not considered as a part of routing.)

I do, based on the premise that multihoming information to end points cannot be
transmitted via a broadcast or via a routing protocol without the transmission
being unscalable.  The goal of transmitting the information conflicts with the
goal of maintaining stability of the core.  We see the results of this in BGP
by the instability caused by route flapping and other similar events.

In my opinion, BGP represents an unstable feedback loop or system. 

Mathematically, I believe it can probably be modelled by differential equations
which ultimately have perioidic functions as solutions.  I am not even sure
that BGP can cope fully with unstable links between nodes even in a fully
aggregated network.  However an aggregated network eliminates two areas of
instability. 

The first is that in an unaggregated BGP network, when a link becomes degraded
the traffic being redirected via another path is likely to add components to
the differential equation that result in positive feedback loops. 

The second is that in an unaggregated BGP network, minor changes to the
topology need to be propagated (i.e. broadcast) to the entire network.  Aside
from the problem of all nodes requiring enough resources to process the
quantity of information, it is this widespread broadcasting which further adds
to excessive data passing from node to node and adding further complications to
the differential equation representing the whole network. 

That's my opinion.  The analysis may be flawed, so feel free to criticize.

--
Peter R. Tattam                            [email-masked]
Managing Director,    Trumpet Software International Pty Ltd
Hobart, Australia,  Ph. +61-3-6245-0220,  Fax +61-3-62450210