Subject: RE: [mobile-ip] Protocol Decision Fixed?

From: "Karim El-Malki (ERA)" <[email-masked]>
Date: Fri, 27 Apr 2001 14:26:15 +0200

Hi Phil

> > > >
> > > > > I don't agree with Karim that one LMM per cloud is all that
> > > > > will ever be
> > > > > needed simply because the cloud will be too large in some
> > > > > cases as a metro
> > > > > network (e.g. LA, Boston, London, Tokyo, Paris).
> > > >
> > > > My point was the other way round. I don't think that LMM
> > > > clouds/domains will be so small so that you continuously have
> > > > to change LMMs when you move.
> > >
> > > Well, you will be changing access routers almost every time
> > > and definitely when you cross AD boundaries right?
> >
> > Of course the MN can change ARs and can move between admin domains,
> > but I don't think there's a one-to-one mapping with the change in
> > LMM in the comment above. Maybe you want to elaborate more.
> >
> > /Karim
> >
> I guess I have elaborated in this thread already. I am 
> proposing a third (3rd)
> protocol solution where the LMM can be "hosted" in any AR and follows
> the MN around by using SeaMoby CT.  What I can't seem to get an
> answer on from Phil R. or Raj is whether a draft supporting 
> this 3rd protocol
> would be looked at as a candidate for this problem.  I want 
> to create the
> draft but I want to make sure that it will at least have a 
> chance against
> the other two proposals.

I don't think the LMM should be tied to Seamoby CT, and it doesn't
have to be in the AR (although it can be). There is a WG draft as
you know called HMIPv6. The LMM (MAP) can be located anywhere,
even at the AR. Would that not address your problem?
Applying CT would then be independent of whether it is an AR or MAP?
Any comments on the draft are welcome.

Regards
/Karim

---

From: Phil Roberts <[email-masked]>
Date: Fri, 27 Apr 2001 09:16:06 -0400

> Thanks,
> Phil

Hi,

    I posted a response to your earlier question just now.  Hope it helps.
It's not really possible to prejudge whether or not a draft would be
considered.  Like I said in the other post, in the interest of progress it's
good to avoid churn, and proposed some questions that are worth asking. 

Phil

---

From: Phil Roberts <[email-masked]>
Date: Fri, 27 Apr 2001 11:02:43 -0400

> and if consistuents believe that a simpler approach, which 
> may be radically
> different from existing proposals, would be better, and still meet the
> requirements, should we ignore them?
> 
> I think not.

I don't think so either.

> 
> To be honest, this recent requirements gathering process, 
> which consisted
> primarily of the I-D authors anyways, was sort-of a backwards 
> approach. I
> think that the WG should be open to starting the process from 
> scratch, 
> gathering the requirements and documenting them, and then allow people
> to contribute their protocol of choice.

Do you feel that the current requirements gathering is hindered by the fact
that the working group already has a document proposing a solution?  What
other requirements might we see if this weren't the case?

> 
> I think that limiting contributions to existing proposals is the wrong
> approach.
> 
> my 2 cents,

It's worth more than that I'd say.

Phil

> PatC

---

From: James Kempf <[email-masked]>
Date: Fri, 27 Apr 2001 09:04:20 -0700 (PDT)

Hi Phil,

Here's my $0.02.

>"What is different now from when we made the decision?" or
>"What do we know now that we didn't know when we made the decision?" 

1) People are paying attention. They were not when the desision was made.
The volume of traffic on this issue, even if most was generated by a few
highly interested participants, has been quite large in the last
few weeks. This is an indication that there is much interest in the
protocol, which was not the case last summer.

2) Some of the requirements that have been brought up by interested
participants are difficult or not possible to satisfy with the
working group draft. While it may be possible to modify the working
group draft to match the requirements, it seems only fair to open
up the protocol decision to other ideas that might better match
the requirements, rather than requiring a retrofit.

3) There is more awareness in the working group, as with the IETF
at large, in the necessity and value of doing requriements prior to selecting
a protocol. If the process is done in the other direction, there
is a tendency to "cook" the requirements to match the protocol.

>"What requirements have changed since we made the decision?" 

There were no explicitly stated, concensus-defined technical requirements when 
the decision was made. As I understand the history of the decision, it was made 
because two drafts were viewed as being easy to understand, and were combined. A 
question was put to the list about whether the draft should be made a working
group draft, and nobody responded. A third draft was viewed as
too complex because some people had questions on it. While understandability
at first presentation is important for good design, using that as the single 
requirement for a working group draft seems somewhat questionable.

There are some implicit requirements that came out of the RegV4 work
(which was also done without an explicit requirments definition phase).
Most of these seem to be showing up in the requirements that we've
been discussing on the list, but there are others that have come
out of the discussion over the last few weeks.
 
>How to proceed is based on working group consensus.
>

My suggestion is to open up the protocol selection phase, allow PhilN
to submit his draft. There are then two possibilities:

1) Have three people who have not been active participants in the requirements 
dicussion nor are they co-authors on any of the drafts nor do they have any 
vested interest in the decision sit down and match the requirements 
against the protocols. The protocol that best matches the requirements
becomes the working group draft.

2) Form a design team of draft authors, as was done for the low latency
handoff work, to combine the three drafts into one that has working
group concensus and meets the requirements.

The first procedure was successfully followed by the AAA working group,
the second, though somewhat controversial, is being pursued currently
in the MIP working group.

		jak

---

From: Pat Calhoun <[email-masked]>
Date: Thu, 26 Apr 2001 15:16:41 -0700

> I would be more than glad to participate in the editing of such draft.
> 
> Please consider me in if such request is in effect by the WG chair hats...

I am not sure whether the hats themselves have to power needed to cause
such a draft to be created, but at least the people wearing them should
consider this very seriously.

PatC

PS: Note a change in contact info.

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Sat, 28 Apr 2001 01:15:39 +0200

> protocol, which was not the case last summer.
	=> There were FOUR proposals on LMM last summer. I think 
	this constitutes interest. Perhaps you had more urgent 
	work to do back then, but that doesn't mean "people"
	were not interested. They definitely were.

> working group draft. 
	=> As a co-author of that draft and someone who worked on MIPv6
	for a couple of years I think this statement is incorrect.
	Even the requirement that we're discussing now
	(multi-level hierarchy) is already met by the current proposal
	and can be furher optimised. The point we're
	discussing is "why" ?
	I believe all the other equirements are also already
	met or can be quite easily. Perhaps you could 
	specify which ones aren't and whether you 
	have another proposal that meets those.

> While it may be possible to modify the working
	=> This is sort of the point of having a WG draft 
	isn't it ? A WG _draft_ is owned by the 
	entie WG and the entire_WG_ can propose 
	changes. Which is unfortunately not what I'm
	seeing here !
	I find it hard to believe that there is a fundamental
	design problem in the current proposal that would 
	stop it from improving. This is due to the 
	fact that the changes from MIPv6 are extremely 
	minor (1 flag).

	Hesham

---

From: "Hesham Soliman (ERA)" <[email-masked]>
Date: Sat, 28 Apr 2001 01:31:01 +0200

I din't see Karim's reply to you earlier 
	which said the same thing, so sorry for 
	repeatin what he'd already said. 

> Assumptions:
> 1).  AR changes will be frequent.  In many designs it is desirable to
>        make every BTS or AP an AR.
> 
	=> That's fine.

> 2). When you cross AD boundaries you are "probably" crossing
>       AR boundaries too.
> 
	=> Yes.

> 3).  Verticle handovers will become much more prevelant thus
>        crossing AD boundaries will be much more prevelant, eg.
>        Bluetooth to CDMA, etc.
> 
	=> No, this is a crossing between two access technologies,
	an AD may contain more than one access technology.
	There is no need to say that one access technology =
	AD. In fact one AR may have more than one access 
	technology attached to it. 

	Hesham