Subject: Re: [Architecture-discuss] Mobility and multi-homing

From: [email-masked] (Noel Chiappa)
Date: Thu, 27 Oct 2005 08:24:04 -0400 (EDT)

> From: Leslie Daigle <[email-masked]>

    > The IETF currently hosts a bunch of working groups focusing on various
    > aspects of mobility and multi homing.

>From an architectural perspective, any attempt to provide such capabilities,
when the underlying architecture isn't rich enough in
namespaces/mechanisms/etc to do so in a clean way, will result in ugly "bags
on the side" which just accelerate the death of the existing system through
feature-cancer (of which your long list of WG's, etc is a perfect example).

The alternative, a genuine architectural re-think and resulting
restructuring, is something that long and painful experience has shown is not
very palatable to the IETF community - my sense is that the costs have always
seemed too high to most. Maybe the community is more ready now to pay the
price (bearing in mind the old adage that you generally get what you pay for
- and when you pay $0 for better architecture, you don't get any better
architecture), but at this point my optimism is pretty worn out.

I don't have any good solution to this. I think in engineering terms, I think
the NSRG concept of designing a new namespace, and deploying it one
application and/or transport layer at a time, was the best one. (Efforts like
NewArch which involve "forklift" upgrades to the entire stack are interesting
- and necessary - academic exercises, but aren't practical models for how to
upgrade the engines in flight.) However, two problems.

One, I don't have a good concept of how to make it happen organizationally -
either i) to make disparate groups adhere to the concept, or ii) provide the
drive to make it happen. Two, even then you have to accept that lots of
legacy "stuff" (protocols, boxes, etc) won't be able to utilize those new
capabilities.

    > what would be the right way or right ways forward? Could we design a
    > way towards converging solutions? How do we ensure robustness of
    > solutions if we attempt to deploy multiple solutions at the same time

There is no substitute for an overall vision of where you want to wind up, in
terms of architecture. Without that, engineering efforts will head off in
disparate, unconnected, directions.

Once you have such a vision (in terms of namespaces, mechanisms, etc) then
you have a defined toolbox that all efforts use in common, which will
automatically create coherence, etc.

    > What about using HIP with routable IP addresses instead of Host
    > Identity Tags (HITs) as Upper Layer Identifiers?

Oh, yes, let's try a *different* way of fitting the proverbial 10 pounds into
the 5 pound sack. Maybe this time it will work!

I assume I need say no more about this idea, which frankly should have
instantly triggered the bogometer of anyone subscribed to an "architecture"
list...

    > Going a little bit furthermore, what are the architectural impacts of
    > doing mobility and multi-homing at the IP layer vs. other layers?

Well, that's an interesting question.

First, I'm going to back you up and recast what you said as "are
architectural features used to support mobility and multi-homing resident at
the IP layer, or other layers?" To an architect, mobility and multi-homing
are *applications* - we merely supply *tools* that other people can use to
design things that procide them.

I think it's clear that such support has to happen above the "deliver a
packet from this interface to that interface" layer. Whether one integrates
all - or part - of it with tranports, or makes some of it a separate shim
(which one might notionally think of as part of the internetwork layer,
although in reality it would be a separate sub-layer above the "deliver a
packet from this interface to that interface" stuff) is a useful question. In
a perfect world, I'd go for the shim, but in the real world, where the plane
is flying, maybe you have to bundle it with transports.

Actually, the question I wound up pondering was whether the old TCP model of
"endpoint to endpoint" was the way to go, or whether we needed some richer
model in which you were talking to a pool of servers, so that things like
load-sharing and failover popped out as well-supported by the basic transport.

Right now, with the Web, people get around this by using cookies, all those
redirector kludges, just clicking on the link again when your transaction
fails, etc.

But would it be desirable to have that capability architected in? And if so,
how to do it in a way that means that things that *don't* want that
capability don't wind up paying for it?

How you answer this has a big impact on what kinds of namespace(s) you add,
etc. E.g. is endpoint-endpoint communication still critical enough that you
need a namespace for naming endpoints? Etc, etc...

	Noel

_______________________________________________
Architecture-discuss mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/architecture-discuss

---

From: Aaron Falk <[email-masked]>
Date: Thu, 27 Oct 2005 09:56:14 -0700

--On October 27, 2005 8:24:04 AM -0400 Noel Chiappa 
<[email-masked]> wrote:
>
> Actually, the question I wound up pondering was whether the old TCP model
> of "endpoint to endpoint" was the way to go, or whether we needed some
> richer model in which you were talking to a pool of servers, so that
> things like load-sharing and failover popped out as well-supported by the
> basic transport.
>
> Right now, with the Web, people get around this by using cookies, all
> those redirector kludges, just clicking on the link again when your
> transaction fails, etc.
>
> But would it be desirable to have that capability architected in? And if
> so, how to do it in a way that means that things that *don't* want that
> How you answer this has a big impact on what kinds of namespace(s) you
> add, etc. E.g. is endpoint-endpoint communication still critical enough
> that you need a namespace for naming endpoints? Etc, etc...

Noel-

I just want to observe that you have enlarged the scope of the question 
from changing the architecture to fix something that is broken (maintaining 
transport connections when an endpoint moves from one network to another) 
to include fixing something that doesn't seem broken (maintaining transport 
connection when an endpoint moves from one host to anther within a 
network).  Does the latter seem like it needs fixing to you?  Or are you 
motivated by a desire for a cleaner architecture?  Your comment that the 
plane is flying is important and I'm loath to change engines just because 
the current one needs a paint job.

regards,

--aaron

---

From: Tony Li <[email-masked]>
Date: Thu, 27 Oct 2005 11:01:24 -0700

> drive to make it happen.

I want to amplify this point:

For the IETF to do any kind of *effective* changes to the  
architecture, there must be architectural control at some point in  
the organization.  Prior to Kobe, it was the old boys network, as  
instantiated by the IAB.  Post Kobe, there seems to be a unfillable  
vacuum in architectural leadership.  To make significant  
architectural progress in *any* direction, we need to first resolve  
the question of who is providing this leadership and under what  
authorization.  The basic premise of the post-Kobe debacle is that  
the IAB does not have the authority to make architectural decisions  
that are at odds with popular opinion.  Until something happens to  
alter that premise, we will continue to run in circles.

Regards,
Tony

---

From: David Barak <[email-masked]>
Date: Fri, 28 Oct 2005 04:03:26 -0700 (PDT)

> the current one needs a paint job.

For some of us, the cure here would be significantly
worse than the disease.  Permitting stateful
connections to ride on top of connections which do not
require state is a beautiful thing - it's one of the
profound successes of the layered model, and
redesigning that to ensure that all endpoints are
locatable and uniquely identifiable will cause a
tremendous amount of pain to operators.  I would
venture to say that this would not make the
architecture "cleaner" in any way: witness the
kludgyness of IPv6 in its layer-munging.  

Yes, there are definite benefits to uniquely
identifying endpoints by non-transitory IDs; however,
the we lose the distinction between layer 2 and 3, and
end up with (at best) very, very ugly addressing.  At
worst, you end up losing the power of both layer 2 and
layer 3 to aggregate.

David Barak
Need Geek Rock?  Try The Franchise: 
http://www.listentothefranchise.com

__________________________________ 
Yahoo! FareChase: Search multiple travel sites in one click.
http://farechase.yahoo.com

---

From: Pekka Savola <[email-masked]>
Date: Sat, 29 Oct 2005 09:43:14 +0300 (EEST)

On Thu, 27 Oct 2005, Tony Li wrote:
> For the IETF to do any kind of *effective* changes to the architecture, there 
> must be architectural control at some point in the organization.  Prior to 
> Kobe, it was the old boys network, as instantiated by the IAB.  Post Kobe, 
> there seems to be a unfillable vacuum in architectural leadership.  To make 
> significant architectural progress in *any* direction, we need to first 
> resolve the question of who is providing this leadership and under what 
> authorization.  The basic premise of the post-Kobe debacle is that the IAB 
> does not have the authority to make architectural decisions that are at odds 
> with popular opinion.  Until something happens to alter that premise, we will 
> continue to run in circles.

Agreed.

While many participants would likely want us to move towards more 
architectural decisions, they don't want such moves to comoe at odds 
with their _own_ work.

The problem is exactly the "popular opinion"; the architectural 
control commitee would end up requiring changes that go against rough 
concensus of a WG, BOF, or even the IETF.  Some parts of the IESG have 
tried to provide guidance before, but their authority to make those 
decisions has been questioned, with ugly results.

If you want examples, look no farther than:
http://www.watersprings.org/pub/id/draft-ietf-grow-rift-01.txt

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: David Meyer <[email-masked]>
Date: Sat, 29 Oct 2005 09:26:24 -0700

On Sat, Oct 29, 2005 at 09:43:14AM +0300, Pekka Savola wrote:
> >For the IETF to do any kind of *effective* changes to the architecture, 
> >there must be architectural control at some point in the organization.  
> >Prior to Kobe, it was the old boys network, as instantiated by the IAB.  
> >Post Kobe, there seems to be a unfillable vacuum in architectural 
> >leadership.  To make significant architectural progress in *any* 
> >direction, we need to first resolve the question of who is providing this 
> >leadership and under what authorization.  The basic premise of the 
> >post-Kobe debacle is that the IAB does not have the authority to make 
> >architectural decisions that are at odds with popular opinion.  Until 
> >something happens to alter that premise, we will continue to run in 
> >circles.
> 
> Agreed.
> 

	To be honest, I didn't see much in the way of IESG
	"guidance" associated with the rift work, unless of
	course you mean the "guidance" to attempt to document the
	issues.

	Dave

---

From: Pekka Savola <[email-masked]>
Date: Sat, 29 Oct 2005 20:32:40 +0300 (EEST)

> 	course you mean the "guidance" to attempt to document the

I wasn't very closely in the loop, but the following was my 
perception:

My recollection is that an IESG member first started being vocal on 
the RIFT issues.  This resulted in extended discussion and a RIFT 
document.  Later, it also resulted in creation of a WG (without having 
to go through a BOF), the most important task of which seemed to be be 
documenting the issue.

---

From: David Meyer <[email-masked]>
Date: Sat, 29 Oct 2005 10:36:51 -0700

> to go through a BOF), the most important task of which seemed to be be 

	I don't remember a WG being created, motivated by the
	rift document, with or without a BOF. Which WG are you
	referring to?

	Dave

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Sat, 29 Oct 2005 19:48:07 +0200

Since this thread has grown far away from the subject line, I'm changing 
it....

It's been clear to me for years that fundamental architectural *change* can 
only come about in the same way that the Internet itself did:

Some people get together and work out what to aim for, and DO IT; then, 
having proved that it can work, they turn around and push it out into an 
uncaring and hostile world.

What the IETF with its consensus principle can do is to *protect* an 
architecture - against both those who would change it in "bad" ways and 
against those who would apply "minor" changes without thinking about its 
result - this leads to the IETF, at its best, being an effective body for 
enacting minor changes and extensions to an architecture with reasonable 
thought about the consequences.

The corridors of the IETF are filled with people who are *able* to think of 
new architectures, and sometimes even *willing* to do so - at its best, the 
IETF can form an environment in which they can meet.
If we're really lucky, the IETF will be able to give prospective new 
architectures some room and time to grow and socialize.... like MPLS, HIP, 
BGP, LDAP, SNMP, RSVP and many others have tried to do - with opinions 
sharply differing over the beauty of the result, of course.

But those who expect *fundamental* change to be *started* within *any* 
established organization understand neither organizations nor human nature.

My $0.02 of pessimism.

                      Harald

--On lørdag, oktober 29, 2005 09:43:14 +0300 Pekka Savola 
<[email-masked]> wrote:

> architectural decisions, they don't want such moves to comoe at odds with
> their _own_ work.
>
> The problem is exactly the "popular opinion"; the architectural control
> commitee would end up requiring changes that go against rough concensus
> of a WG, BOF, or even the IETF.  Some parts of the IESG have tried to
> provide guidance before, but their authority to make those decisions has
> been questioned, with ugly results.

---

From: Tony Li <[email-masked]>
Date: Sat, 29 Oct 2005 13:41:19 -0700

Harald,

> It's been clear to me for years that fundamental architectural  
> *change* can only come about in the same way that the Internet  
> itself did:
>
> Some people get together and work out what to aim for, and DO IT;  
> then, having proved that it can work, they turn around and push it  
> out into an uncaring and hostile world.

Thank you for the inspirational approach, but hey, we've been there,  
done that, and got the egg on our faces to show for it.  Remember GSE?

For those that don't, it was an architectural change that would have  
made major semantic changes to v6.  It was dismissed, in the view of  
some, unjustly.

> If we're really lucky, the IETF will be able to give prospective  
> new architectures some room and time to grow and socialize.... like  
> MPLS, HIP, BGP, LDAP, SNMP, RSVP and many others have tried to do -  
> with opinions sharply differing over the beauty of the result, of  
> course.

I agree, but we have clear evidence to the contrary: architectural  
change will be shut down in the name of politics.  Until that room to  
grow is in evidence, the only precedent that we have is that  
innovation will be stifled by the high priests of v6.

> But those who expect *fundamental* change to be *started* within  
> *any* established organization understand neither organizations nor  
> human nature.

You can call me naive all day long, but let's be accurate here: my  
hope is that the organization will change itself so that it can  
foster new thinking.  I don't expect or even want the organization  
itself to provide the innovation.  Architecture by committee?  Been  
there, seen that movie too.  Ugly.

How the IETF opens itself to change is an open question and there are  
many different possible paths.  Whether we declare victory and say  
that IPv6 is done or declare disaster and start over makes no  
difference to me.  Either way, we need to move on, and the IAB is in  
the best position to lead the community to accept this.

The creation of this mailing list is certainly one possible step.  It  
can be viewed as being open to actually discussing change.   
Alternately, it can be viewed as simply a rat hole to absorb  
dissent.  It's not clear which it is, and only the actions of the IAB  
over time will tell.

We all have one common and overriding goal: the continued and ongoing  
growth of the Internet.  Growth requires change and, as you note,  
organizations tend to resist change.  Thus, if the IETF is not  
careful, it is well positioned to inhibit the growth of the Internet  
and thus become self-defeating.  As stewards of the IETF, we must  
continue be watchful of this trap and encourage innovation, even when  
it opposes the status quo and political forces within the  
organization.  That is our responsibility to one another and to each  
and every Internet user, past, present and future.

Respectfully yours,
Tony

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Sat, 29 Oct 2005 20:52:04 +0200

At 19:48 29/10/2005, Harald Tveit Alvestrand wrote:
>*change* can only come about in the same way that the Internet itself did:
>

Harald,
Allways agreed with you here. This is why I push out my globalisation 
approach aside of yours, into an uncaring IETF and a favorable world.

>architecture - against both those who would change it in "bad" ways 
>and against those who would apply "minor" changes without thinking 
>about its result - this leads to the IETF, at its best, being an 
>effective body for enacting minor changes and extensions to an 
>architecture with reasonable thought about the consequences.

This list is IAB's. If the result is the same it will demonstrate the 
split between, at leat some, users and the IETF is too deep for a 
patch. This would acknowledge a balkanisation divide in the 
architecture itself. Don't kill my last hopes.

>*any* established organization understand neither organizations nor 

The fundamental changes I look for are simplification in the low 
layers for a more solid trunc, and architectural development in user 
layers for new branches. This will result in fundamental changes in 
the way to use the networks, not in their current architecture. 
Question: is this for IAB/IETF? Reponses will be on this list and at PESCI.

My 2 euro cent of hope.
jfc

---

From: Melinda Shore <[email-masked]>
Date: Sun, 30 Oct 2005 18:19:34 -0500

On 10/29/05 12:48 PM, "Harald Tveit Alvestrand" <[email-masked]>
wrote:
> result 

Unfortunately I don't think that's true, regardless of the decision-
making mechanism.  An awful lot of the things that are being done that
I think are causing problems are being driven by concerns that aren't
strictly technical - revenue models, cost of ownership issues,
deployment management (it's a heck of a lot easier to drop a new box
into the network than it is to either change something that's already
there or get rid of something that's already there), and so on.
The NAT traversal stuff would probably make a good case study of how
things can go wrong.  The IAB's UNSAF document should have been taken
a lot more seriously than it was but now, to the extent that it's
being thought about at all, it's being thought about as just a hoop
to jump through to get some documents published.  The industry just
got out in front, jumped on some technology we all knew was flawed, and
the stuff got published.

My .signature elsewhere says "software longa, hardware brevis," and I
hope that one thing that we can agree to in the future is that no
badly flawed short-term technologies are going to squeak through under
the assumption that something more correct is going to be published
later and will supercede it, 'cause that probably isn't going to happen.

Melinda