Subject: Re: Architectural approaches to multi6

From: "J. Noel Chiappa" <[email-masked]>
Date: Mon, 24 Mar 2003 14:38:21 -0500

> From: RJ Atkinson <[email-masked]>

    > The only architectural approach that I've seen on this list in recent
    > months is the notion of deprecating the concept of an "address", in
    > favour of using "locator" and "identifier" for the separate purposes of
    > routing and identity. Maybe I've overlooked something ?

Ahem. Separating "location" and "identification" is an architectural
approach to dealing with the fact that the address of the entity at the
other end may change 'frequently'. It's *not* an architectural approach to
handling multi-homing in a scalable way.

The only architectural approach to scalable multi-homing that seems to have
much interest is using multiple addresses (i.e. overlapping topology naming
abstractions), and switching among them as needed.

I have in the past mentioned a number of other approaches, e.g.:

- DDC's "route stubs"
- the equivalent in MD-systems (let's call them "map stubs")
- highly dynamic abstraction boundaries with a deep hierarchy

but they all involve i) big changes to the routing architecture, and ii) for
the third, at least, frequent changes in address (in other words, you need the
I/L split there too).

Overlapping naming abstractions - which we can do with the existing routing
architecture - seems to be the only choice anyone has expressed interest in.

	Noel

---

From: "Bound, Jim" <[email-masked]>
Date: Mon, 24 Mar 2003 17:57:05 -0500

OK that is fair.
/jim

> -----Original Message-----
> From: Iljitsch van Beijnum [mailto:[email-masked]] 
> Sent: Monday, March 24, 2003 5:48 PM
> To: Bound, Jim
> Cc: RJ Atkinson; [email-masked]
> Subject: RE: Architectural approaches to multi6
> 
> 
> On Mon, 24 Mar 2003, Bound, Jim wrote:
> 
> > > 3: remove addresses from all places in the protocol stack 
> above the IP
> > >    layer. If higher layers are unaware of addresses and 
> the addresses
> > >    follow the topology, IP can route around failures by changing
> > >    addresses.
> 
> > Wearing my IP stack product developer hat.  Errrrr maybe in 
> the year 
> > 2050 if we start now.  The entire stack on end systems and routing 
> > code on embedded systems I have worked with have addresses not only 
> > embedded but permeated through all layers.  I see the 
> vision but don't 
> > have to be real here?
> 
> Yes, we have to be real at some point but not just yet. First 
> we have to determine if 3. has merit.
> 
> And I have reason to believe transition won't be as hard as 
> it may seem at first glance.
> 
> 
>

---

From: "Tony Li" <[email-masked]>
Date: Mon, 24 Mar 2003 15:57:44 -0800

Indeed.  If, in fact, we can convert upper layers to deal
with just the identifiers, we would be very close to done.  ;-)

Tony

|    -----Original Message-----
|    From: Bound, Jim [mailto:[email-masked]] 
|    Sent: Monday, March 24, 2003 2:57 PM
|    To: Iljitsch van Beijnum
|    Cc: RJ Atkinson; [email-masked]
|    Subject: RE: Architectural approaches to multi6
|    
|    
|    OK that is fair.
|    /jim
|    
|     
|    
|    
|    > -----Original Message-----
|    > From: Iljitsch van Beijnum [mailto:[email-masked]] 
|    > Sent: Monday, March 24, 2003 5:48 PM
|    > To: Bound, Jim
|    > Cc: RJ Atkinson; [email-masked]
|    > Subject: RE: Architectural approaches to multi6
|    > 
|    > 
|    > On Mon, 24 Mar 2003, Bound, Jim wrote:
|    > 
|    > > > 3: remove addresses from all places in the protocol stack 
|    > above the IP
|    > > >    layer. If higher layers are unaware of addresses and 
|    > the addresses
|    > > >    follow the topology, IP can route around failures 
|    by changing
|    > > >    addresses.
|    > 
|    > > Wearing my IP stack product developer hat.  Errrrr maybe in 
|    > the year 
|    > > 2050 if we start now.  The entire stack on end systems 
|    and routing 
|    > > code on embedded systems I have worked with have 
|    addresses not only 
|    > > embedded but permeated through all layers.  I see the 
|    > vision but don't 
|    > > have to be real here?
|    > 
|    > Yes, we have to be real at some point but not just yet. First 
|    > we have to determine if 3. has merit.
|    > 
|    > And I have reason to believe transition won't be as hard as 
|    > it may seem at first glance.
|    > 
|    > 
|    > 
|    
|

---

From: "Christian Huitema" <[email-masked]>
Date: Tue, 25 Mar 2003 12:01:14 -0800

The way I see it, applications are evolving to use IP addresses more,
not less. There are many reasons, such as the flakiness of the DNS
resolution process, but there are also many applications (or transports)
that actually want to reason over IP addresses in an attempt to control
or organize network usage. In a multi-homing scenario, applications are
likely to treat the address on the GPRS interface different from the
Wifi or the Ethernet interface; they also will want to know whether they
need to open the firewall to reach a specific address, etc. 

> From: Bound, Jim [mailto:[email-masked]]
> Sent: Tuesday, March 25, 2003 11:32 AM
> To: Iljitsch van Beijnum; Brian E Carpenter
> Cc: [email-masked]
> 
> No one uses FQDN's above IP till one gets to the Application layer.
Why
> do you say this?
> 
> Also we need a solution that does not assume this at all.  Doing this
> would at best be nice to have long term.
> 
> THere is also no way to enforce it.
> 
> /jim
> 
> 
> 
> 
> > Sent: Tuesday, March 25, 2003 1:25 PM
> > To: Brian E Carpenter
> > Cc: [email-masked]
> > Subject: Re: Architectural approaches to multi6
> >
> >
> > On dinsdag, maa 25, 2003, at 17:14 Europe/Amsterdam, Brian E
> > Carpenter
> > wrote:
> >
> > >>>> 3: remove addresses from all places in the protocol
> > stack above the
> > >>>> IP
> > >>>>    layer. If higher layers are unaware of addresses and the
> > >>>> addresses
> > > We've been preaching against exposing addresses above the
transport
> > > layer since RFC 1900 (dated 1996) at least. Little has
> > changed in the
> > > real world.
> >
> > As far as I can tell, most people/applications use names rather than
> > addresses most of the time. The trouble is that protocols such as
TCP
> > use the addresses in the IP header in their processing. If we make
> > these protocols look at something else (the FQDN, an address
> > that's not
> > in the IP header, ...) we are free to change addresses at any time
> > without breaking sessions.
> >
> > >> And I have reason to believe transition won't be as hard as it
may
> > >> seem
> > >> at first glance.
> >
> > > Not sure I understand that statement.
> >
> > Changing all references to addresses everywhere except in the
> > IP layer
> > is a huge undertaking. However, I think multihoming benefits can be
> > achieved before this process has been completed.
> >
> >
> >
>

---

From: "Tony Li" <[email-masked]>
Date: Thu, 27 Mar 2003 21:07:25 -0800

I would NOT agree that there are no solutions in routing.
That said, I think that a solution MUST involve having
the transport NOT use the locator as a portion of the
pseudo-header.  So at the very least, there must be host
changes.

I believe that we must solve the failure of non-last-mile
links, including ISP links or even site-internal links.
We cannot do this through signaling our routing and
be scalable, so there must be some way for the 
correspondent host to try multiple locators and figure
out which locators currently work. 

Tony

|    -----Original Message-----
|    From: Dmitri Krioukov [mailto:[email-masked]] 
|    Sent: Thursday, March 27, 2003 2:16 PM
|    To: [email-masked]
|    Subject: RE: Architectural approaches to multi6
|    
|    
|    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: "Bound, Jim" <[email-masked]>
Date: Fri, 28 Mar 2003 11:13:35 -0500

> pseudo-header.  So at the very least, there must be host changes.

With MHAP this would not be needed as the PI would enter the Host Node
with the identifier in the header and could be used for the checksum, in
that architecture view.  

The use of the HOA with a MIPv6 architecture would also avoid this
problem.

Looking at GFN and HIP currently.

> links, including ISP links or even site-internal links. We 
> cannot do this through signaling our routing and be scalable, 
> so there must be some way for the 

This is more complex.

/jim