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

From: "Bound, Jim" <[email-masked]>
Date: Thu, 27 Oct 2005 08:58:18 -0400

I agree with Noel's discussion and input in this case.  One point below
I strongly agree with and will comment as I know it will come up. 

> 
>     > 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!

This is very true and also the architecture change from engineering
implementation is very significant to the entire IP stack and network
utility applications to that stack (e.g. DNS, TCPDUMP, PMTUD).  But, I
believe two important principles have been maintained with this
suggestion, and important to this discussion: keep the intelligence
required at the ends and at a minimum within the network, and maintain
the principles of end-to-end.  These tenets for mobility and
multihoming, and the need for guaranteed QoS for tomorrow.

/jim

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of 
> Noel Chiappa
> Sent: Thursday, October 27, 2005 8:24 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Architecture-discuss] Mobility and multi-homing
> 
>     > 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
> 

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

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Thu, 27 Oct 2005 08:29:23 -0700

> From: Noel Chiappa [mailto:[email-masked]] 
> Sent: Thursday, October 27, 2005 5:24 AM
> 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 
> models for how to upgrade the engines in flight.) However, 
> two problems.
> 
> 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.
> 

<snip>

> 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...
> 

I think you are mistaking the above HIP idea as an architectural
suggestion rather than as a deployment hack.  Rather, it seems to me to
support what you argued for in the above-- don't deploy a forklift
upgrade to the whole stack.

Tom

---

From: "Bound, Jim" <[email-masked]>
Date: Thu, 27 Oct 2005 19:02:13 -0400

I don't agree we need a leader group.  It should be a working group or
this list and run it similar in fashion to the way we have done IPR.
But we need rules of engagement and before all of that or this should
exists define exactly 

"what problem are we solving"?

To use a phrase from Aaron I like if all we need is a paint job then
lets not change the engine.  I personally believe some of the engine
needs enhancments.  But not where all often go for IP virtualization
(ughhh I think that is more than tunnels but no big deal for now), or
lets change what the identifier is for transport, but rather some other
thoughts:

Can guranteed QoS be achieved end-to-end and we have so many views on
this and the current work and results from Diff and Int serve are not
good enough by themselves, what is the answer? 

Conventional routing protocols do not work for ad hoc networks and do we
need another virtual layer for them in the IP reference model,
regardless if they are mobile which to me is orthogonal.

3rd world cultures will skip an entire generation of Internet technology
solutions and interoperate in a network environment of total wireless
connections with some IX pipes, and Satcom as the dominant routing core,
is the IP reference model today ok or does the engine need new parts? I
personally think the transport does with re-think beginning with SCTP
and SCP-PS.

Just thoughts not saying this should be the work, but once we identify
the problem a list will be much easier to identify and then how do we
work on such things.  Just saying well I think I have a problem so I
will go hire and build a new architecture team is not wise from an IETF
workload witin the community, architecture, and business view. And a
good ole boy self-proclaimed elitists is not the answer and the IETF
should make very sure that does not happen, it will just be rejected by
the new age Internet community, the market, and industry.  Been there
done that.

Also if this should start, out of IETF bodies will show up too like ITU
and others. The Internet is far more important to a lot of entities now,
than in 1983 or 1991, and a multi-Xillion dollar business and the IETF
has not impressed the world regarding time-to-market in several areas.
This work would be far different than delivering standards
specifications most likely, but maybe not?

/jim

> [mailto:[email-masked]] On Behalf Of Tony Li
> Sent: Thursday, October 27, 2005 2:01 PM
> To: Noel Chiappa
> Cc: [email-masked]
> > either i) to make disparate groups adhere to the concept, or ii)  
> > provide the
> > 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: "Fergie" <[email-masked]>
Date: Thu, 27 Oct 2005 23:21:57 GMT

As an observer, and an interested party, I agree with Jim on
this one -- the first order of business would be a "problem
statement".

And I also agree that working outside the auspices of the
general IAB/IESG/IETF framework would indeed be seen as somewhat
illegitimate, at least by folks who build networks, develop products,
and make architectural decisions when it comes to implementation.

I've seen banter about inconsistencies in IP-in-IP tunnels (among
other things), but this is no different that shortcomings brought
up in the associated IETF WG meetings when these protocols were
initially developed...

- ferg

-- "Bound, Jim" <[email-masked]> wrote:

/jim

---

From: "Bound, Jim" <[email-masked]>
Date: Fri, 28 Oct 2005 11:31:23 -0400

Jari,

This is all current working group work???  Or I am working on this now
for nothing :--) (this is in jest).  All need to take Noel's mail very
seriously on lets not add yet more confusion by adding parts and I too
agree I could just sit back and watch other forces fix architecture
issues. I do still have faith in committees that have good leaders that
believe leadership is an action not discussion, pontification, and more
meetings :--).  What problem needs to be solved again?  I also agree if
there is a problem, the IETF only has X time to solve it or someone else
will solve it out of here.  But, I still don't have firm grasp on the
architecture problem other than end-to-end is total mess today which has
caused other bad things IMO.

/jim 

> [mailto:[email-masked]] On Behalf Of Jari Arkko
> Sent: Friday, October 28, 2005 11:23 AM
> To: Leslie Daigle; Pekka Nikander (JO/LMF); [email-masked]
> Leslie Daigle wrote:
> > [Tap tap tap -- "is this thing on?" ;-)  I'm forwarding Pekka
> > Nikander's suggested topic-starters, one at a time, to see if
> > we can get some "discuss" going, about "architecture".  -- LLD]
> 
> First, I'd like to thank you Leslia and Pekka for setting this
> list and discussion up.  I believe this can be very useful.
> We do talk too little of the architecture in the IETF.
> 
> And Pekka wrote:
> 
> > 1. Mobility and multi-homing
> 
> Actually, I have a bit different view into this than seems
> to be the focus of the discussion so far. What I view as
> architecture isn't necessarily agreement on a single
> solution, nor is it the simplicity of solutions. What seems
> more important is that we have broken down the problem
> into separable pieces. Solutions for individual pieces
> can then proceed in their own pace and style. It seems
> evident to me that we have a case of "market will decide"
> here for some components, and I think its fine - but don't
> take this as opinion that markets work in all cases. Also,
> "we have options and we will let the market choose" shouldn't
> be the same as "we aren't doing anything to guide the
> solutions".
> 
> Some examples of the separable pieces include
> 
> - Network attachment functions that satisfy
>   needs of mobile hosts. There's a lot of ongoing
>   work in this space relating to either functional
>   or performance improvements, e.g., DNA, optimized
>   v6 setups (optimistic DAD), access security for
>   roaming (EAP), and so on.
> 
> - The actual multiaddressing function, e.g., Mobile
>   IPv6 + extensions, HIP + extensions, SHIM+SEND+
>   friends, application layer.
> 
> - Triggering mechanisms that assist getting
>   information about conditions, better attachment
>   points, etc.
> 
> - Interfaces to transport layer to inform them
>   about switching to a new path and/or getting
>   information from them about current reachability.
> 
> - Local "services", such as ability to offer forwarding
>   agents via DHCP, maybe ability to pull old packets
>   from previous router, etc.
> 
> Re: deploy multiple solutions at  the same time. Here
> I think we have a case for some more short term work.
> We are starting to have so many extensions to the
> "waist" of IP that I'm not fully convinced anyone knows
> which order all those processing steps should be taken.
> 
> Re: what would be the right way or right ways forward?
> Looking at this field, I think we've learned a few lessons
> over the years. One of the issues that we need to pay
> more attention to include deployment (e.g. ability to
> do something without having to (a) set up servers in
> the network and (b) set up subscriptions of users for
> those servers). Another issue is different environments.
> Mechanisms that are more likely to be deployed are
> likely to work despite IP versions, NATs, etc.
> 
> Re: functions beyond multiaddress suggested by Noel.
> I don't think we should work on server pooling; this
> seems to work well now. But another issue that may
> deserve more attention is denial-of-service protection.
> 
> --Jari
> 
>