Subject: Re: [seamoby] IETF Architecture Work (RANT)

From: James Kempf <[email-masked]>
Date: Wed, 11 Apr 2001 14:27:14 -0700 (PDT)

Hi Charlie,

Apologies for getting off on a rant here, but unfortunately
this has hit a hot button.

>I absolutely agree that architecture is needed.  I just question
>whether it belongs in a working group like [seamoby].  It would
>seem to be more appropriate at the area directorate level,
>or probably better within a group like the IAB.  I wonder if
>there should be an [iawg].  We'd need some wild-eyed masochists
>as chairs, I reckon.
>

May I quote from http://www.ietf.org/overview.html?

>The Internet Engineering Task Force (IETF) is a large open international 
>community of network designers, operators, vendors, and
>researchers concerned with the evolution of the Internet architecture and the
                                                          ^^^^^^^^^^^^
>smooth operation of the Internet. It is open to any
>interested individual. 

Notice the word "architecture" in the above? Anybody coming into
the IETF as a newbie who depended on this page to tell them what
the IETF actually does would assume that IETF was already concerned
about the Internet architecture.

In fact, whether we (the IETF) like it or not, there are other groups
outside the IETF that are taking IETF protocols and doing architecture with 
them. In many cases, this architecture will more likely than not cause
a major change in the Internet as we know it, especially if
the future looks like millions of IPv6 mobile nodes. The resulting
Internet will probably not look anything like the Internet we
know and love, because the people doing the architecture come
from a background that does not value open systems and does not
want to enable a proliferation of services. 

The IAB, IMHO, has completely and totally failed to recognize this
challenge. Working groups/BOFs have been fumbling towards a solution
(AAA WG, Middlebox BOF), but the IETF as a whole has, as yet, not recognized
the threat to the Internet architecture by the *lack* of any
serious consideration of architecture.

That said, there is a need for balance, and going in the direction
of rigid architectures ala a bell-shaped process that constrains protocol 
development is also not the right direction. And, working groups operate by 
concensus, so unless the working group members agree that architecture
is important, it won't get done.

As for seamoby, I think having some kind of architecture just so
we know what we are talking about is important. Again, the issue
is balance. I don't think the architecture has to be all-encompassing,
though having some kind of global view of how complex networking
systems work is important. 

		jak

---

From: [email-masked]
Date: Thu, 12 Apr 2001 09:21:00 +0300

Phil,

> If there was EVER a time for the IETF
> to sincerely start documentings is architecture work (which 
> it is doing a lot of these days under the covers) it is now.

I'd definately vote against this.  I think that other SDOs 
become fixed into their architectural view and stagnate.

Also, it also implies that there is a correct way to do
things.  IP technologies have been very successful because
they have focused on the interoperability of the protocols,
not on the architecture.  

The IETF does provide architecure pieces for certain
protocol sets, but anything larger, I fear would be
doomed to failure.

br,
John

---

From: Phil Roberts <[email-masked]>
Date: Thu, 12 Apr 2001 13:00:35 -0400

> Even if we don't call it architecture, what the WGs should be doing
> is improving the global Internet for mobility and not 
> reacting to other SDOs
> that show up in numbers at WG meetings and demand that the IETF
> do things for them.  I don't get why the IETF has been so responsive
> to these other SDOs.  Clearly,  this has been a huge 
> distraction for the
> MIP WG over the last few years.
>

The IETF is open to anyone who wants to participate.  Surely you're not
proposing the IETF register the affiliation of the folks showing up and
count the opinions of those who also participate in other SDOs as of less
value.  What are you proposing?

I'm not sure what you see as a distraction for the MIP WG over the last few
years.  The WG has produced a number of new proposed standard that
facilitate deployment in cdma2000 networks.  Do you view this as a bad
thing?  It seems to me they add valuable functionality around MIP that could
be used in a number of different settings.

---

From: James Kempf <[email-masked]>
Date: Thu, 12 Apr 2001 10:54:05 -0700 (PDT)

If I might remind everyone again, please take a look at 
http://www.ietf.org/overview.html. This tells the world what IETF is
about. The very first sentence says IETF is about doing architecture.

If you don't think that should be the case, send email to Harald and
tell him to remove that.

		jak

>Date: Thu, 12 Apr 2001 13:50:45 -0400 (EDT)
>From: Jim Bound <[email-masked]>
>To: Michael Thomas <[email-masked]>
>Cc: James Kempf <[email-masked]>, [email-masked], 
[email-masked], [email-masked]
>Subject: RE: [seamoby] IETF Architecture Work (RANT)
>
>
>Mike,
>
>At a minimum we need to do good Requirements Definition and Analysis
>phase.  That has been missing in many working groups for a few years.
>That helps with sorting assumptions and guiding light out.
>
>/jim
>
>On Thu, 12 Apr 2001, Michael Thomas wrote:
>
>> James Kempf writes:
>>  > John,
>>  > 
>>  > I suggest you look at http://www.ietf.org/overview.html. This 
>>  > page is what the IETF says it does. Architecture is in the first sentence.
>>  > According to this, IETF *already* does architecture. So it is not
>>  > a matter of whether we should start doing it or not.
>>  > 
>>  > The problem is, we are doing a lousy job of it. And, as I tried
>>  > to point out in my posting several days ago, other groups are taking
>>  > IETF protocols and doing architecture with them that is directly
>>  > contrary to the Internet architecture as it currently stands.
>>  > 
>>  > So, we are by default letting other SDOs do architecture with our
>>  > protocols that will end up screwing the Internet in the end.
>> 
>>    "Death of the net, film at 11:00"
>> 
>>    Oh, I don't think that it's quite that bad.
>>    However, the thing I find somewhat disturbing
>>    is the underlying assumption that we'd get the
>>    architecture *right*. We may, but there a lot
>>    of downside if we didn't but was rubber stamped 
>>    as "The IETF Architecture."
>> 
>>    Ultimately, there's still a significant amount
>>    of room for competing architectures where the
>>    market sorts the dead ends out. If we were in
>>    monopoly situation I might feel somewhat
>>    different, but we aren't.
>> 
>>    Can I also point out that we might be using 
>>    the term architecture in different ways? I
>>    generally think of "architecture" in the
>>    analogous way as to what an architect does when
>>    she puts lines on a drawing to build a house.
>>    3GPP, Packetcable, etc, are all in the business
>>    of producing those sorts of architectures.
>>    Under that definition, the IETF has never done
>>    architectures per se. It does have a base level
>>    model, set of assumptions, and guiding
>>    principles which facilitate protocol
>>    development but this isn't really the same;
>>    it's more like a guidelines which instruct
>>    architects the do's and don't on the net. Sort
>>    of like "don't build houses with the roof on
>>    the foundation".
>> 
>> 		  Mike
>> 
>

---

From: Phil Roberts <[email-masked]>
Date: Thu, 12 Apr 2001 16:11:35 -0400

Hi Phil N.

I'm not sure I see an answer to my question.  I was trying to figure
out what we should have done to see MIP massively deployed now.

Re: your points
1. I don't see how we could have kept from supporting the (what is now
called 3gpp2) folks from doing the things they wanted to get done.  They
came, had work, contributed cycles, got working group consensus, and are
now rolling stuff out.  And I don't see why we would want not to support
them.

2. Perhaps we should take this up on the MIP list?  Now that I think about
it,
perhaps this whole thing should be on the MIP list.  (Sorry, Pat).

3. Most of the add-ons are add-ons.  One could just run vanilla mobile IP.

Phil R.

> -----Original Message-----
> From: Phil Neumiller [mailto:[email-masked]]
> Sent: Thursday, April 12, 2001 4:00 PM
> To: Phil Roberts; [email-masked]
> Subject: Re: [seamoby] IETF Architecture Work (RANT)
> 
> 
> Hi Phil R.
> 
> I will take a stab at answering.  I am officially off on a 
> rant now so *try*
> not to respond unless of course you need to defend yourself. :-)
> 
> >
> > What exactly was missed that kept it from being massively 
> deployed?  I don't
> > recall us turning down any request for work that would help 
> enable that
> > deployment, but perhaps you can point some out?
> >
> 
> 1).  As James has pointed out repeatedly, it is the IETF's 
> job to preserve,
>       cherish, and extend the architecture of the global 
> Internet.  When
>       did it become the IETF's job to work for other SDOs?  IMO, the
>       MIP WG has catered almost exclusively to cdma2000/3GPP2 and
>       UMTS/3GPP for the last 1 1/2 years or better.  I could be wrong
>       but that is my opinion.  In fact, some of the work that 
> was not expedient
>       for 3G was handed over to SeaMoby (and now the IRTF).
> 
> 2).  A real goal that SHOULD be on the MIP charter (again this is IMO)
>       is to make itself go away, i.e. MIP should be once and 
> for all absorbed
>       into the router fabric of the global Internet since the 
> work is routing work
>       and should stay routing work decoupled from other 
> issues that are related
>       to mobility.
> 
>       Distance Vector approaches like BGP4 and RIP have clearly proven
>       themselves in fixed routers and will probably make a 
> strong showing in
>       pre-commercial MANETs shortly.  What does this mean to MIP?
>       Apparently not much.  Its  quite possible that some 
> BGP-like monster
>       could really becomes the routing algorithm for all 
> devices whether fixed
>       or mobile and the utility of a home agent could be 
> nullified.  Is this a
>       concern of the MIP group?  It seems like maybe things 
> like this SHOULD
>       be on the charter to me since they are the things that 
> have to do with
>       the architecture of the global Internet itself.  
> Improvements to the global
>       Internet in its support of mobility help everybody on 
> the planet not just
>       the 3G fat cats.
> 
> 3).  I fail to see how continuing to tie security issues, QoS 
> issues, AAA
>       issues directly into the routing protocol 
> implementation of MIP help to
>       acheive the important goal of getting it universally 
> deployed in the
>       global Internet (not just a bunch of private cellular 
> networks).  (again this is IMO).
> 
> Please take all this with an industrial sized canister of 
> NaCl since it was a
> and still is a rant.
> 
> Best regards,
> 
> Phil N.
> 
>

---

From: [email-masked]
Date: Thu, 12 Apr 2001 18:11:10 -0500

>       for 3G was handed over to SeaMoby (and now the IRTF).

What specific work done in the MIP WG over the last year and a half has 
been done with 3GPP as a customer in mind? 
The MIP WG did undertake some work that was specific to PP2, but the
people who did this work in the IETF were/are people who also play in the
PP2 field. So what's wrong with that....
<RANT>
Let's not get into the philosophy of what the IETF's job is and should be
and
treat the global Internet as the holy grail
</RANT>

So adding peripheral stuff to MIP allows it to be "Maybe" used in certain
types of
networks. But that does not change the basic MIP protocol itself. 

-Basavaraj

---

From: Patrice Calhoun <[email-masked]>
Date: Fri, 13 Apr 2001 11:50:27 -0700

>is improving the global Internet for mobility and not reacting to other SDOs
>to these other SDOs.  Clearly,  this has been a huge distraction for the

Well, I suppose one could argue that the IETF is there to build protocols
that will be used in the real world. So far 3GPP2 is the one big one that 
has come up and stated that they will deploy MIP in a large scale network.

So, it sounds reasonable for the IETF to help out.

>Let's EXTEND the global Internet to support the best wireless mobility
>on the planet and let other SDOs worry about supporting their legacy
>systems.  WHY is the MIP charter so dominated with work from the
>3GXXrs I must ask?  They are not the only customer, in fact with
>the advent of "cheap" wireless, which most people are starting to see
>the advantages of  (I can only hope), cellular architectures as built today
>and the business models that support them will be deconstructed.

Any "other" customer is free to come to the IETF and state they requirements.
I can assure you that they would be heard, and cooperation is guaranteed.
However, we cannot just build something and then shove it down their throats :(

---

From: Patrice Calhoun <[email-masked]>
Date: Fri, 13 Apr 2001 12:08:26 -0700

>The original wired Internet protocols didn't have to worry about AAA or
>security or QoS to get massively deployed.

Really? RADIUS was specifically designed to allow for ISPs to provide
Internet access to users in a more scalable way.... and this is back in 1992!

>I am going to respectfully disagree Charlie.  It *COULD* have been
>already deployed massively over WPAN and WLAN technology
>had we ignored the cellular concerns of AAA and QoS and minutes
>of use carrier class requirements and gone rapidly with a data only
>model.

Phil, please help me a little. How could we ever have guessed how Mobile IP
would run over WPAN and WLAN, and could the IETF have ensured that MIP was used
over these wireless technologies?

(as an aside, alot of WLAN work has been in progress to use RADIUS/AAA to
authenticate 802.11 mobiles)

>I do agree with this, however, I also believe that the electoral system
>taught us a lesson in the last US election, that a popular vote is not
>necessarly best for the entire constituency.

No, I think it taught us that we all have different beliefs, but this is hardly
an IETF problem, is it? :)

PatC

---

From: Patrice Calhoun <[email-masked]>
Date: Fri, 13 Apr 2001 12:16:02 -0700

>> No, not SIGMOBILE, I was thinking of the Bluetooth SIG and some
>> others.  The IEEE is working on there own context transfer right now
>> in 802.11 TG 17.
>
>Hmmm, that seems like a waste of time to me, I'll admit.

First, chances are they started before we did, and second, we aren't even close
to being done yet. Are you proposing that they just sit on the sidelines
waiting? It would be nice, but perhaps not realistic.

PatC

---

From: Patrice Calhoun <[email-masked]>
Date: Fri, 13 Apr 2001 12:22:51 -0700

>perhaps this whole thing should be on the MIP list.  (Sorry, Pat).

Oh, you can take this thread to your list. No objections on my side. I 
always dislike bashing other protocols on this list, but we seem to
entertain plenty such threads :(

PatC

---

From: Kulwinder Atwal <[email-masked]>
Date: Fri, 13 Apr 2001 14:32:35 -0400

> Sent: Friday, April 13, 2001 7:27 AM
> To: Kulwinder Atwal; [email-masked]

> > But, it is impossible to predict the optimal frequency that 
> route updates
> > should occur.  A user, or vehicle may remain stationary for 
> hours at a time
> > then move at a high rate.  Should the router update occur 
> once per 30
> > seconds, per hour, or per millisecond?  What about Context Transfer?
> 
> Yes we have your point, event driven systems are better in many ways,
> but I think they are only reliable if redundancy is added and 
> many times
> timers are adding that redundancy (in the time domain) when the event
> triggers fail (in the frequency domain).

Timers are an L2 issue.  They are necessary, but at the L2 level.
A Timer is a physical embodiment.  It belongs at L2.  Link reliability
(redundancy) is an L2 issue.

Logical Trigger: Route Lost
Physical Event: Timer times out, or other side terminates link.

> 
> >
> > Is the endpoint record a fridge, ID Badge, stereo, person, 
> car, ship or
> > plane?
> >
> > This is why context transfer and route updates need to 
> occur based on
> > Physical Events propagated up the stack as Logical 
> Triggers.  NOT TIMERS.
> > Becuase it is impossible to predict the Usage Model.
> 
> If you study MANET algorithms Kulwinder you will see that 
> this is  exactly
> how they work (at least in the routing sense).

I attended the MANET WG meeting.  All of the proposals had timers.
I discussed this with the Co-Chair, Joe Macker.  It appears as if most of
the work seems to be taylored to 802.11.  

Since 802.11 is primarily a PHY, with no link reliability mechanisms (no
MAC), the solutions presented introduced timers to compensate for a full
MAC.

> 
> >
> > The mapping of Physical Events to Logical Triggers may 
> change depending on
> > the technology, application, external event, or user preference.
> >
> > We need enable all current and future Usage Models.
> 
> A bit altruistic, but I'll try to help, I like generalized solutions!

Not as altruistic as you think.  This is primarily an IETF-centric view.
The SIG has many Usage Models currently and in development.  Since the SIG
encourages future profiles to be IP based, future Usage Models will be IP
based as well.

- Kulwinder.

---

From: Kulwinder Atwal <[email-masked]>
Date: Fri, 13 Apr 2001 14:38:21 -0400

> From: Patrice Calhoun [mailto:[email-masked]]
> Sent: Friday, April 13, 2001 2:50 PM
> To: Phil Neumiller; [email-masked]; James Kempf
> Cc: [email-masked]

The SIG did come and state its requirements to the IESG.  You were invited.
You missed that meeting, becuase you thought we were meeting in the bar
downstairs.  The SIG is composed of 2481 companies is that big enough for
you?  

- Kulwinder.

---

From: Patrice Calhoun <[email-masked]>
Date: Fri, 13 Apr 2001 14:59:33 -0700

>downstairs.  The SIG is composed of 2481 companies is that big enough for

(assuming that you are criticizing my note)

Yes, and I am sorry that I was not able to find you guys. I realize that this
was a first attempt, and I applaud the effort. Of course, in the future, it
would be nice for bluetooth to take their requirements and make them known
in the individual WGs where the work occurs, since that's the way the IETF
works. I am quite certain this is the intended direction, so no response is
necessary (unless I am wrong).

btw, I was not in any way shape or form, stating that bluetooth, or any other
SDO doesn't want to collaborate. This is a response to why MIP has been
listening to 3GPP2. Bluetooth, up to now, has never been putting requirments
in the Mobile IP WG. However, look at the following for a great example of how
some external SDOs can get their requirements heard in the IETF (note that the
document is not "authored" by an SDO, but by IETF folks that have an interest
in the particular SDO.

ftp://ftp.isi.edu/internet-drafts/draft-hiller-cdma2000-aaa-02.txt

Oh and for what it's worth, AAA was not custom designed for 3GPP2. However, 
their requirements were fulfilled in the protocol design phase.

Hope this helps,

PatC

---

From: Kulwinder Atwal <[email-masked]>
Date: Fri, 13 Apr 2001 15:27:19 -0400

> As far as the database portion goes, I would like you take a look at
> some work going on in Randy Katz's group at Berkley.  They have
> something called OceanStore that is incredibly cool.  In this model
> your secure data follows you around as you are mobile and sloshes
> around in something analogous to a service provider SANs (storage
> area network).  You only need your privacy key and a secure pipe
> to carry your entire digital library around wherever you go.  Here is
> the URL http://oceanstore.cs.berkeley.edu/ .
> 

This is closer to what I was thinking.  Although, maybe not the entire
digital library, just the part that is most used.

-Kulwinder.

---

From: Kulwinder Atwal <[email-masked]>
Date: Fri, 13 Apr 2001 17:13:04 -0400

> From: Michael Thomas [mailto:[email-masked]]
> Sent: Friday, April 13, 2001 5:02 PM
> To: Kulwinder Atwal
> Cc: 'Michael Thomas'; [email-masked]'; James Kempf;
> [email-masked]; Phil Neumiller; [email-masked]
>  > This is a very Internet centric view.  
> 
>    What can I say? I'm a nethead.
> 
>  > It may be hard to imagine, but Bluetooth really does have 
> more applications
>  > than a wireless LAN card, or the Internet.
> 
>    What is the point of not running it over IP?
>    Note that IP is not necessarily synonymous with
>    the Internet.

You need to think of this in phases.  

Phase 1: First Bluetooth must provide an easy way for vertical market stacks
to migrate to Bluetooth:  Move Legacy stacks to Bluetooth.

Phase 2: The IETF needs to provide the functionality of those stacks in IP
based protocols:  Write new protocols.

Phase 3: Then those vertical markets can then migrate to IP.

Currently the IETF protocols do not support the needs of every Usage Model
(vertical market stack).

First you build it.  Then they will come.

> 
>  > The SIG does spec new radios, conduct tests for 
> interoperability, and vendor
>  > qualification.
> 
>    Fine, those are great things for the SIG (and
>    IEEE) to do. A fixed set of tasks and then
>    shut down when they're done. 

There will always be new radios, and new companies wanting their products
certified.

- Kulwinder.

---

From: "Fleming, Kris D" <[email-masked]>
Date: Fri, 13 Apr 2001 16:11:26 -0700

> in the Mobile IP WG

3GPP2 has additional requirements to support voice calls.  These same
requirement and changes to MIP to support voice calls can also be used
for Bluetooth to support voice of IP based calls.  Bluetooth usage model
are often base on best effort service.  There should be no addition 
requirement for Bluetooth.   Bluetooth should be view as another media
which supports IP similar to 802.11.  802.11 did not have any addition
requirements, why should Bluetooth?

> The SIG members that I have talked to feel that MIP is a cellular protocol
> for 3GPP2.  And as such, feel that MANET is probably the best place for a
> Mobile Router protocol.

I don't know who in the SIG that you have talked to but the Bluetooth SIG
has always wanted to support MIP.   If you are connected to a Bluetooth 
PAN Access point then you can use MIP, the same why that you use MIP over
802.11.   It in not only a cellular protocol for 3GPP2!  

What is useful is to send up indications to the MIP layer when you are about

to move from one Bluetooth Access point to another.  This could trigger a
MIP 
to register with a new FA.  This is just one example, there are many other 
SEAMOBY related issues that should be done, and discussed on this list.  

The goal of the Bluetooth SIG PAN WG is to allow any IP base protocol to 
run over Bluetooth.  This allows Bluetooth become another PHY media, which
supports IP and other networking protocols.  In addition, we are 
encouraging IP base applications and new usage model that people can 
dream up using IP.

Also Kulwinder often make statements about the Bluetooth SIG and 
it's direction.  The problem is with that is that he isn't a member of the 
Bluetooth PAN WG, nor is he a member of any other SIG WG, and makes 
incorrect and misleading statements like the original statement.

---

From: Kulwinder Atwal <[email-masked]>
Date: Sat, 14 Apr 2001 14:00:17 -0400

> From: Fleming, Kris D [mailto:[email-masked]]
> Sent: Friday, April 13, 2001 7:11 PM
> To: 'Kulwinder Atwal'; [email-masked]'; James Kempf;
> [email-masked]; Phil Neumiller
> I don't know who in the SIG that you have talked to 

I have talked to at least half a dozen PAN members, and some SIG members
more senior than yourself in the last month.  I have received unsolicited
emails from three PAN members within the last week on various PAN issues.  I
think the time to continue this discussion is next month after the release
of the PAN docs to the public.

Thanks,
Kulwinder.

---

From: [email-masked]
Date: Tue, 17 Apr 2001 08:59:59 +0300

Hi Phil,

> of use carrier class requirements and gone rapidly with a data only

I'm probably out of the loop, but what technologies supporting
WPANs are widely available?  Also, WLAN devices are becoming
more popular, but I don't think that they are still being mass
produced (however, I will say that a local service provider
is rolling out HIPPERLAN service in my neighborhood - though
the hardware & cost is still too high, IMO).

best regards,
John

---

From: [email-masked]
Date: Tue, 17 Apr 2001 09:06:59 +0300

Hi Michael,

>    of like "don't build houses with the roof on

I agree completely.  This is what I meant in my original
mail.

cheers,
John