Subject: [netlmm] Network-based mobility - NETLMM DT Solution Vs A solution based on MIP6

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 6 Oct 2006 20:24:04 -0700

All,
This is an effort to kick start a discussion of the merits of each
approach and reach an agreement on the deltas and the importance of the
deltas. I have purposely avoided the use of the term "PMIPv6", since
there appears to be multiple interpretations of that among different
people. The comparison here is between the proposed NETLMM DT solution
(as in draft-giaretta-netlmm-dt-protocol-02) vs a solution that would be
based on using the Mobility Header (and hence be closely aligned to
MIP6). This is not intended to get into the degree of closeness to MIP6.

What does the NETLMM DT Solution bring, by being totally different from
MIP6?
------------------------------------------------------------------------
------ 

1. The protocol can be evolved to using a reliable transport protocol
like SCTP at some point. 
2. The protocol can run over IPv4 without changes. 

While these seem like good goals, what is the practical need for the
above goals? For instance, is IPv4 signaling a necessity for a NETLMM
solution? 

What does a solution based on MIP6 bring? 
------------------------------------------
A solution that uses the Mobility Header can re-use a number of already
defined options, some of them directly and some with minor changes. The
industry is seeking a network-based local mobility solution that can
still provide a number of features that a host-based mobility solution
can provide. So, over time, we will find ourselves addressing these
requirements and re-inventing these for NETLMM. 

Mobility options that can be re-used with an MH-based protocol like
PMIPv6: 

1. MN ID Mobility Option

This option can pretty much be used with no changes. 

2. DNS-based HA lookup

While some scenarios may not need this mechanism, it may make sense in
some deployments to use DNS for this purpose, even with PMIP6. 

3. DHCP-based HA lookup 
- Home Network Identifier Option
- Home Network Information Option
- DHCP Relay Agent MIP6 Option, MIP6 HA sub-option

Same as 2. 

4. DNS Update Mobility Option

This can be used to update the DNS server with the address assigned to
the MN within the domain in which PMIP is deployed. 

5. DSMIP6 Options
- IPv4 HoA Mobility Option
- IPv4 address acknowledgement Mobility Option
- NAT Detection Mobility Option

These options can be used without changes. 

5. HA Switch message

Also useful for the same purpose as in MIP6 and can be used without
changes. 

6. Other HA reliability messages

We need to wait for this work to stabilize a bit more before we can
tell, but we must be able to leverage off a lot of this work. 

7. Multiple CoA Registration 
- BID Mobility Option

Can be used to signal the addition of a location of the MN, rather than
a replace of location. 

8. Flow bindings support
- Flow ID Option

When the edge is aware of the QoS needs of the MN (can happen via
out-of-band mechanisms), flow bindings can be conveyed to the HA using
the same mechanism as in MIP6. 

9. NEMO Support
- Prefix registration
- Prefix Assignment

The extensions defined for NEMO support can largely be re-used to
register prefixes for the end node. 

Other points: 
-------------

1. Mechanisms such as the association phase for MAG-LMA discovery
described in the NELTMM DT protocol are potentially useful in certain
deployments of a network-based mobility solution. However, this should
be feasible to do in either approach. 

Thoughts? 

Regards,
Vidya

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

---

From: Marco Liebsch <[email-masked]>
Date: Wed, 11 Oct 2006 11:35:36 +0200

Hi Vidya,

I see that a MIPv6-based solution could suit some scenarios. However,
we should also consider extensions to very basic NetLMM, in particular
to support route optimization.
MIPv6 provides complex support for end-to-end route optimization,
which might not be appropriate for a NetLMM setup in some scenarios,
where the LMA might play some role in coordinating RO. Regarding your
points 2 and 3, I don't see any reason why DNS and DHCP cannot
be used to support LMA assignment in the DT solution.

In general, I see some advantage in a transport-based protocol for
NetLMM, such as the DT protocol draft; in particular regarding
extensions for optimization to suit all deployment scenarios.

I'd like to see one solution that suits various scenarios, neither
a single solution with limited support, nor multiple solutions for
various scenarios.

marco

---

From: "Roberts Phil-APR042" <[email-masked]>
Date: Thu, 26 Oct 2006 15:27:30 -0400

Well, I would too like to stimulate some discussion, though, um, a few
weeks later, ahem.

Comments below.

> -----Original Message-----
> From: Narayanan, Vidya [mailto:[email-masked]]
> Sent: Friday, October 06, 2006 10:24 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [netlmm] Network-based mobility - NETLMM DT Solution Vs A
> solutionbased on MIP6
> 
> 
> All,
> What does a solution based on MIP6 bring?

It's important to distinguish between a couple of cases that may get
conflated, 1) reusing a home agent, and 2) reusing protocol fields.  You
are arguing here not so much for reusing a MIP6 home agent as reusing
protocol fields?  Reusing a home agent has value because there is
running code and demonstrated interoperability with other network
entities.  I'm not sure what the value of reusing protocol fields or
bits on the wire.  One could make an argument that by reusing the format
of bits on the wire, then it's easier to modify a home agent to do the
things you want done in the case you are not actually reusing the home
agent as is.  That doesn't seem to me at least do be a very strong
argument.

While I agree that some of the things below are must haves, I don't
agree that getting those things with reuse of the mobility header buys
much in standardization, implementation, or operation.  That being said
I've still commented on them.

In the response to the points below I'm assuming that the intent is to
be able to reuse the MH options for a home agent where we have an LMA in
the NETLMM design, in either the case where an HA is used with PMIP6 or
for an LMA.

> This option can pretty much be used with no changes.

Agree that you need the ability to identify mobiles apart from an IP
address.
> some deployments to use DNS for this purpose, even with PMIP6.

I don't understand what you are asserting here?

> - DHCP Relay Agent MIP6 Option, MIP6 HA sub-option

Are any of these needed in a local mobility management scenario?
Knowing the home network id or information about the home network seems
superfluous as the entities in a local mobility management scenario are
in the same network already.  And given that the mobile is unaware of
the concept of a mobility anchor it's not clear to me what defining the
ability to find one through DHCP really buys us.
> the MN within the domain in which PMIP is deployed.

Could you clarify the scenario you envision here?

> These options can be used without changes.

There might be a use for these, but I'm not sure.  It seems to me that a
dual stack scenario for a localized mobility architecture could be quite
different.  These presuppose using MIP6 for that but it might be the
case that in a different architecture the implementation of dual-stack
is simpler?
> Also useful for the same purpose as in MIP6 and can be used without

This is another case where differences in the architecture may make the
resulting support of the function simpler?  If the function is simpler
because the mobile is not involved, will you need the function in the
same way?
> Can be used to signal the addition of a location of the MN, rather
than

You'll have to help me with the use case for this.

> the same mechanism as in MIP6.

Agree that there are cases where this is needed.

> register prefixes for the end node.

Not sure I agree with this.  Certainly NETLMM has chosen to go down a
path of dealing with prefixes per mobile node but it isn't clear in my
mind yet whether the semantics of that are the same as the semantics of
NEMO.  If so, I don't disagree, I'm just not sure.

---

From: "James Kempf" <[email-masked]>
Date: Fri, 27 Oct 2006 01:12:36 -0700

Folowing up on Phil's note, we haven't heard much comment on this thread 
from proponents of a pure PMIP solution. I'd like to distinguish between 
Vidya's comments and Phil's response which, I assume, are about the 
technical desirability of using the MIP6 Mobiity Header format to implement 
the NETLMM architecture and the two PMIP drafts that will be presented in 
the MIP6 WG. I'll let Phil and Vidya and anyone else who cares to comment 
work through the technical issues on that, I'm more interested in the two 
PMIP drafts.

Perhaps one of the authors of the two PMIP drafts that are to be presented 
in the MIP6 WG meeting would care to comment why they believe that PMIP is 
technically superior to the DT NETLMM solution? Arguments about probability 
of deployment or other such are interesting, but most decisions about 
alternatives in IETF are premised intitially on technical arguments. 
References to the WG's problem statement and goals drafts 
(draft-ietf-netlmm-nohost-ps-05.txt and draft-ietf-netlmm-nohost-req-05.txt, 
now with the IESG for publication approval) pointing out the superiority of 
PMIP for satisfying the goals that the WG has agreed to are likely to be 
especially convincing. The only comment I've heard so far is that the DT 
draft introduces unnecessary new terminology.

            jak

---

From: Basavaraj Patil <[email-masked]>
Date: Fri, 27 Oct 2006 10:23:15 -0500

James,

I don't think that there is much to be gained by doing a comparison of the
NETLMM DT protocol solution vs "pure PMIP solution". This is not a question
of whether one protocol is better suited or superior in terms or performance
or simple etc. I am not commenting in any way about the use of the mobility
header to implement the NETLMM protocol here, but rather presenting another
view about NETLMM and PMIP6.
Given that the IETFs mainstream solution for IPv6 mobility is MIP6 (I hope
we are not going to get into a debate about this statement :) ), there is or
may be a desire by either SDOs or operators considering deployment of MIP6
to also have the capability to use the same infrastructure (HA and
associated AAA) for hosts that do not have MIP6 capability or for
transparently supporting mobility for IPv6 hosts (for whatever reason such
transparent mobility is needed).

So instead of a prolonged discussion about the (de)merits of NETLMM and
PMIP, we should maybe consider that the IETF standardize both and let the
industry pick and choose which protocol makes sense in a certain deployment
environment. I don't think that we can say either NETLMM or PMIP is the
perfect solution for all deployment models and hence maybe having a choice
would be a reasonable way forward.

-Raj

---

From: "Soliman, Hesham" <[email-masked]>
Date: Fri, 27 Oct 2006 09:03:46 -0700

> transparent mobility is needed).

=> I completely agree with Raj. Let's save the excitement, there isn't
going to be any significant performance differences between the the
netlmm protocol and the "hypothetical" PMIPv6 protocol. Think about it
from a simulation point of view, there is not difference. The difference
comes from the ability to reuse MIPv6 infrastructure and its extensions,
in a seamless manner. 

 > industry pick and choose which protocol makes sense in a 

=> It would be preferrable to do one protocol. But before we even decide
on this, why can't the netlmm WG (DT, chairs ...etc) explain the reasons
for not choosing PMIP and we can at least use that as a starting point
for the discussion of whether we should do 1 or 2 protocols. I find it
counter intuitive to simply ignore PMIP as a viable option. That is,
unless I missed some explanations that were already documented
somewhere.

Hesham

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 27 Oct 2006 12:25:31 -0500

Hi James,

I am not one of the authors of these drafts, but I still would like to
comment with my 2 cents. I believe that we probably need to look at the
issue at hand from a different angle or we probably need to reverse the
logic. Since MIPv6 is a protocol which is already deployed and used, I
think it would be more beneficial to all if we can identify the
technical issues that MIPv6 can not address as a Local Mobility
Management protocol via Proxy MIPv6 and then see if they can be
resolved. 

After these technical issues have been identified and a consensus been
reached that PMIPv6 is incapable of addressing them, I believe looking
for a brand new protocol will be the choice; IMHO. 

Regards,
Ahmad

> From: James Kempf [mailto:[email-masked]] 
> Sent: Friday, October 27, 2006 3:13 AM
> To: Roberts Phil-APR042; Narayanan, Vidya; [email-masked]
> Subject: Re: [netlmm] Network-based mobility - NETLMM DT 
> Solution Vs Asolutionbased on MIP6
> 
> Folowing up on Phil's note, we haven't heard much comment on 
> this thread from proponents of a pure PMIP solution. I'd like 
> to distinguish between Vidya's comments and Phil's response 
> which, I assume, are about the technical desirability of 
> using the MIP6 Mobiity Header format to implement the NETLMM 
> architecture and the two PMIP drafts that will be presented 
> in the MIP6 WG. I'll let Phil and Vidya and anyone else who 
> cares to comment work through the technical issues on that, 
> I'm more interested in the two PMIP drafts.
> 
> Perhaps one of the authors of the two PMIP drafts that are to 
> be presented in the MIP6 WG meeting would care to comment why 
> they believe that PMIP is technically superior to the DT 
> NETLMM solution? Arguments about probability of deployment or 
> other such are interesting, but most decisions about 
> now with the IESG for publication approval) pointing out the 
> superiority of PMIP for satisfying the goals that the WG has 
> agreed to are likely to be especially convincing. The only 
> comment I've heard so far is that the DT draft introduces 
> unnecessary new terminology.
> 
>             jak 
> 
>

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 27 Oct 2006 11:54:14 -0700

I fully agree with Hesham here. I think the NETLMM DT really needs to
provide an explanation of why a PMIP-like solution was not chosen as the
network-mobility protocol. The answer that "the DT deliberated it and
decided against it" is unacceptable. Clearly, the folks outside the DT
have no visibility to this. And, having talked to folks from the DT, I'm
still not clear on the reasons. 

I think this is the responsibility of the DT to prove to the rest of the
community why the solution chosen best satisfies the requirement for
network-based mobility. 

Regards,
Vidya  

> From: Soliman, Hesham 
> Sent: Friday, October 27, 2006 9:04 AM
> To: Basavaraj Patil; ext James Kempf; Phil Roberts; 
> Narayanan, Vidya; [email-masked]
> Subject: RE: [netlmm] Network-based mobility - NETLMM DT 
> Solution VsAsolutionbased on MIP6 
> 
> 
>  > I don't think that there is much to be gained by doing a  
> > comparison of the  > NETLMM DT protocol solution vs "pure 
> PMIP solution". This is  > not a question  > of whether one 
> protocol is better suited or superior in  > terms or 
> performance  > or simple etc. I am not commenting in any way 
> about the use  > of the mobility  > header to implement the 
> NETLMM protocol here, but rather  > presenting another  > 
>  > Given that the IETFs mainstream solution for IPv6 mobility 
>  > is MIP6 (I hope  > we are not going to get into a debate 
> about this statement  > :) ), there is or  > may be a desire 
> by either SDOs or operators considering  > deployment of MIP6 
>  > to also have the capability to use the same infrastructure 
> (HA and  > associated AAA) for hosts that do not have MIP6 
> capability or for  > transparently supporting mobility for 
> IPv6 hosts (for  > whatever reason such  > transparent 
> mobility is needed).
> 
> => I completely agree with Raj. Let's save the excitement, 
> there isn't going to be any significant performance 
> differences between the the netlmm protocol and the 
> "hypothetical" PMIPv6 protocol. Think about it from a 
> simulation point of view, there is not difference. The 
> difference comes from the ability to reuse MIPv6 
> infrastructure and its extensions, in a seamless manner. 
> 
>  >
>  > So instead of a prolonged discussion about the (de)merits 
> of  > NETLMM and  > PMIP, we should maybe consider that the 
> IETF standardize  > both and let the  > industry pick and 
> choose which protocol makes sense in a  > certain deployment
> 
> => It would be preferrable to do one protocol. But before we 
> even decide on this, why can't the netlmm WG (DT, chairs 
> ...etc) explain the reasons for not choosing PMIP and we can 
> at least use that as a starting point for the discussion of 
> whether we should do 1 or 2 protocols. I find it counter 
> intuitive to simply ignore PMIP as a viable option. That is, 
> unless I missed some explanations that were already 
> documented somewhere.
> 
> Hesham
>

---

From: "Roberts Phil-APR042" <[email-masked]>
Date: Fri, 27 Oct 2006 15:31:46 -0400

I think there are two separate questions.  One is "Why didn't the design
team choose PMIP6?" and the other is "Why did the design team produce
the protocol it did?"  You're not presuming that the DT should have
chosen PMIP6 are you?

> Sent: Friday, October 27, 2006 1:54 PM
> To: Soliman, Hesham; Basavaraj Patil; ext James Kempf; Roberts Phil-
> APR042; [email-masked]
> Subject: RE: [netlmm] Network-based mobility - NETLMM DT Solution
> VsAsolutionbased on MIP6
>

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 27 Oct 2006 22:50:23 +0200

Hi Vidya,

> community why the solution chosen best satisfies the requirement for

No.  You're right about looking at what best satisfies the requirements,
but not on it being up to the design team to "prove" the proposed solution
against arbitrary other solutions.  On the contrary, if any "proving" should
be done, it should be up to all people interested in the work to hold up all
the potential proposed solutions against the *requirements agreed on*; or if
needed, go back and revise the requirements, establish consensus for the
revised requirements, and then compare the solutions against those.

In the first paragrap above, you seem to be arguing as if this is a trial,
rather than engineering.

It seems to me that nobody has had complaints about the proposed solution
not fulfilling the requirements, or about the requirements being incomplete
or wrong; the discussion up to now has sounded more like "you didn't pick
my favourite solution, so I'm going to give you a hard time about it".

So if the DT 'defends' itself against one charge ("You didn't propose
PMIPv6!") the next will maybe be "You didn't propose GTP", followed by
"You didn't propose PMIPv4, which is much more proven than PMIPv6",
followed by "You didn't propose OSPF, which was used for LMM over 4
years ago, and proven to work", and so on...

And if we would accept this mode of working, any future proposal would be
open to the same kind of attack.  That wouldn't be engineering, either.

This isn't the way to argue, and it isn't a way that leads forward.

What's really relevant to the Internet Engineering Task Force is what
the requirements are, and how well the proposed solution(s) fulfil the
requirements.  That's engineering.

Can we get back to doing engineering, please?

	Henrik

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 27 Oct 2006 14:07:02 -0700

Hello Henrik,

> Can we get back to doing engineering, please?

In my 10/23/06 netlmm post, I asked:

  "So do we really need a new protocol for NETLMM, or would
  it be better to take some of the nice features from the
  DT work and fold them into a DHCP(bis) effort? (Or, can
  we just use existing DHCP mechanisms as a "good-enough"
  solution?)"

and, those were intended as engineering questions and not
bickering as to why the DT didn't pick my favorite solution.
That is why I abstained from the ballot; I am not saying no
to the DT work - only that there are engineering questions
left to discuss.

Thanks - Fred
[email-masked]

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 27 Oct 2006 14:28:05 -0700

Henrik,

IMO, Vidya's question is perfectly valid.

when a design team is formed to work on a solution
for a particular problem and if there are multiple
solutions to the problem, one of the first things
the design team is supposed to do is to evaluate if
any of the existing solutions suffices. if none of
the solutions satisfy the basic requirements, then
the design team should of course work on a new
solution from scratch.

sure, it is preferable to always do only
"engineering", but you do have to deal with the
"other" questions sometimes.

note that the design team solution is after all
*just* another solution.

Vijay

---

From: Henrik Levkowetz <[email-masked]>
Date: Fri, 27 Oct 2006 23:43:05 +0200

Hi Fred,

> bickering as to why the DT didn't pick my favorite solution.

Right.  And I didn't take your post as bickering; sorry if I came
across as generalizing to that effect.

> to the DT work - only that there are engineering questions

Perfectly acceptable, to my point of view.

Regards,

	Henrik

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 27 Oct 2006 14:55:22 -0700

To add to what Vijay has said here, it appears that the onus is being
placed on the PMIP proponents to explain why that is preferable over the
NETLMM DT solution. This is just plain wrong - it should be the other
way around, given that one PMIPv6 solution and one other MH-based
solution was already "input" to the DT. 

Vidya 

> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Friday, October 27, 2006 2:28 PM
> To: Henrik Levkowetz
> Cc: Narayanan, Vidya; [email-masked]
> when a design team is formed to work on a solution for a 
> particular problem and if there are multiple solutions to the 
> problem, one of the first things the design team is supposed 
> to do is to evaluate if any of the existing solutions 
> suffices. if none of the solutions satisfy the basic 
> requirements, then the design team should of course work on a 
> new solution from scratch.
> 
> sure, it is preferable to always do only "engineering", but 
> you do have to deal with the "other" questions sometimes.
> 
> >> provide an explanation of why a PMIP-like solution was not 
> chosen as 
> >> the network-mobility protocol. The answer that "the DT 
> deliberated it 
> >> and decided against it" is unacceptable. Clearly, the 
> folks outside 
> >> the DT have no visibility to this. And, having talked to 
> folks from 
> >> the DT, I'm still not clear on the reasons.
> >>
> >> I think this is the responsibility of the DT to prove to 
> the rest of 
> >> the community why the solution chosen best satisfies the 
> requirement 
> >> for network-based mobility.
> > 
> > No.  You're right about looking at what best satisfies the 
> > requirements, but not on it being up to the design team to 
> "prove" the 
> > proposed solution against arbitrary other solutions.  On 
> the contrary, 
> > if any "proving" should be done, it should be up to all people 
> > interested in the work to hold up all the potential 
> proposed solutions 
> > against the *requirements agreed on*; or if needed, go back 
> and revise 
> > the requirements, establish consensus for the revised 
> requirements, and then compare the solutions against those.
> > 
> > In the first paragrap above, you seem to be arguing as if this is a 
> > trial, rather than engineering.
> > 
> > It seems to me that nobody has had complaints about the proposed 
> > solution not fulfilling the requirements, or about the requirements 
> > being incomplete or wrong; the discussion up to now has 
> sounded more 
> > like "you didn't pick my favourite solution, so I'm going 
> to give you a hard time about it".
> > 
> > And if we would accept this mode of working, any future 
> proposal would 
> > be open to the same kind of attack.  That wouldn't be 
> engineering, either.
> >

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 27 Oct 2006 14:58:51 -0700

I don't think the degree of closeness to MIP6 needs to be debated at
this time. That's why I said PMIP-like in my email. 

Vidya

> From: Roberts Phil-APR042 [mailto:[email-masked]] 
> Sent: Friday, October 27, 2006 12:32 PM
> To: Narayanan, Vidya; Soliman, Hesham; Basavaraj Patil; ext 
> James Kempf; [email-masked]
> I think there are two separate questions.  One is "Why didn't 
> the design team choose PMIP6?" and the other is "Why did the 
> design team produce the protocol it did?"  You're not 
> presuming that the DT should have chosen PMIP6 are you?
> 
> 
> > > To: Basavaraj Patil; ext James Kempf; Phil Roberts; Narayanan, 
> > > Vidya; [email-masked]
> > > PMIP solution". This is  > not a question  > of whether 
> one protocol 
> > > is better suited or superior in  > terms or performance  
> > or simple 
> > > etc. I am not commenting in any way about the use  > of 
> the mobility  
> > > > header to implement the NETLMM protocol here, but rather  > 
> > > presenting another  > view about NETLMM and PMIP6.
> > >  > Given that the IETFs mainstream solution for IPv6 
> mobility  > is 
> > > MIP6 (I hope  > we are not going to get into a debate about this 
> > > statement  > :) ), there is or  > may be a desire by 
> either SDOs or 
> > > operators considering  > deployment of MIP6  > to also have the 
> > > capability to use the same infrastructure (HA and  > 
> associated AAA) 
> > > for hosts that do not have MIP6 capability or for  > 
> transparently 
> > > supporting mobility for
> mobility is 
> > > needed).
> > > => I completely agree with Raj. Let's save the excitement, there 
> > > isn't going to be any significant performance differences between 
> > > the the netlmm protocol and the "hypothetical" PMIPv6 protocol. 
> > > Think about it from a simulation point of view, there is not 
> > > difference. The difference comes from the ability to reuse MIPv6 
> > >  > So instead of a prolonged discussion about the 
> (de)merits of  > 
> > > NETLMM and  > PMIP, we should maybe consider that the IETF 
> > > standardize  > both and let the  > industry pick and choose which 
> > > protocol makes sense in a  > certain deployment
> > >
> > > => It would be preferrable to do one protocol. But before we even 
> > > decide on this, why can't the netlmm WG (DT, chairs
> > > ...etc) explain the reasons for not choosing PMIP and we can at 
> > > least use that as a starting point for the discussion of 
> whether we 
> > > should do 1 or 2 protocols. I find it counter intuitive to simply 
> > > ignore PMIP as a viable option. That is, unless I missed some 
> > > explanations that were already documented somewhere.
> > >
> > > Hesham
> > >
>

---

From: Henrik Levkowetz <[email-masked]>
Date: Sat, 28 Oct 2006 00:07:10 +0200

Hi Vijay,

> IMO, Vidya's question is perfectly valid.

Very well, we disagree on that then.

> any of the existing solutions suffices.

Two points here:  I don't necessarily agree with you
if this is your definition of a design team; there's
more to it.  But more importantly:

> if none of

Yes.  And we discussed approaches in the proposed solutions
(note, please, that there was I think 4 or 5 individual
solution drafts -- are you suggesting that we
should have discussed *only* pmip as a potential solution)?

However this isn't about that -- this is about the claim
that design team should *prove* the proposed solution
against a specific other solution -- or all other solutions.

That isn't right, and it has the potential of turning
engineering into litigation.

(If accepted as a principle, it also has the potential of
 scaring away any technically competent person from ever
 volunteering for a design team.  There's only so much
 grief you're willing to take, after all...)

What is important is how well the proposed solution matches
the requirements, and of course whether the requirements
reflect the needs of the concerned people.

> "other" questions sometimes.

And in this case, what exactly is it that you refer to
as "other" questions?

> note that the design team solution is after all

The design team solution has no status in the WG if the
WG doesn't choose to take it on.  And if the WG chooses
to use it as a base, nothing in it is cut in stone.

The design team solution should be considered just as good
as it has technical merits.  Not more, not less.  I'm not
asking for anything else.  What I am commenting on here,
however, is that a few people seem to be trying to get the
proposal dismissed without regards to its technical merits.

(And just to be clear, I'm not referring to all posters,
 here -- others *are* concerned about technical issues.)

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Sat, 28 Oct 2006 00:24:53 +0200

Hi Vidya,

> solution was already "input" to the DT.

Why, oh why, should it be so??

There were many solutions input to the design team.  The design team has
tried to do good work, and offered its best to the working group.  The
design team has nothing to prove or disprove.  It has simply attempted
to offer good work for consideration.

I'm trying to point out that this should really be about fulfilling the
requirements, not about 'this protocol against that'.

I count about 8 proposals for the netlmm protocol (not counting the design
team's) -- my apologies if I've missed anyone -- and the design team has
tried to take the known material into consideration.  It seems that the
logic you are proposing would ultimately lead to having a trial of all
against all...

  draft-akiyoshi-netlmm-protocol
  draft-giaretta-netlmm-protocol
  draft-gundavelli-netlmm-mip6-proxy
  draft-raman-netlmm-protocol
  draft-templin-autoconf-netlmm-dhcp
  draft-vidya-netlmm-netmob
  draft-wanghui-netlmm-protocol
  draft-wood-netlmm-emp-base
  draft-giaretta-netlmm-dt-protocol

With 9 proposals, that gives us 9*8=72 trials.  Let's go for it.

	Henrik.

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 27 Oct 2006 16:44:00 -0700

> should have discussed *only* pmip as a potential solution)?

of course not. but a question has been asked about
PMIP. I think it should be answered.

> against a specific other solution -- or all other solutions.

well the question was more like was PMIP considered
as a solution or did the design team just decide to
work on a solution from scratch.

> engineering into litigation.

I don't see this happening.

> reflect the needs of the concerned people.

sure. but it is also important to see if an existing
solution matches the requirements before starting
designing one from scratch.

> And in this case, what exactly is it that you refer to

non-engineering questions like "was this solution
considered?", "why did you guys not adopt or build
on this solution?".

>  here -- others *are* concerned about technical issues.)

I didn't want to get into this debate at all. my
preference is to standardize both. the reason I
stepped in, whatever we end up doing here, we are
going to be setting a precedent. hopefully we
don't make a mess out of it.

Vijay

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 27 Oct 2006 17:16:16 -0700

Hi Henrik,
I don't want to spend time on this kind of debate. I keep hearing that
the DT already debated the issue of basing the protocol on MIP6 and
decided against it. And those reasons are unknown to the rest of the
group at the moment. Now, there is a request for standardization of a
solution based on MIP6 by several people, citing industry direction. And
the proponents of that are being asked to prove why they prefer that
over the DT solution. That is clearly unfair - if we differ in that
view, we have to agree to disagree. I think the rest of the group
deserves to understand the reasons behind the DT choice. Going down the
number of possible combinations is not a useful exercise.  

Vidya

> From: Henrik Levkowetz [mailto:[email-masked]] 
> Sent: Friday, October 27, 2006 3:25 PM
> To: Narayanan, Vidya
> Cc: [email-masked]
> > placed on the PMIP proponents to explain why that is 
> preferable over 
> > the NETLMM DT solution. This is just plain wrong - it should be the 
> > other way around, given that one PMIPv6 solution and one other 
> > MH-based solution was already "input" to the DT.
> 
> There were many solutions input to the design team.  The 
> design team has tried to do good work, and offered its best 
> to the working group.  The design team has nothing to prove 
> or disprove.  It has simply attempted to offer good work for 
> consideration.
> 
> I'm trying to point out that this should really be about 
> fulfilling the requirements, not about 'this protocol against that'.
> 
> team's) -- my apologies if I've missed anyone -- and the 
> design team has tried to take the known material into 
> consideration.  It seems that the logic you are proposing 
> would ultimately lead to having a trial of all against all...
> 
> >> Subject: Re: [netlmm] Network-based mobility - NETLMM DT Solution 
> >> VsAsolutionbased on MIP6
> >> 
> >> Henrik,
> >> 
> particular 
> >> problem and if there are multiple solutions to the problem, one of 
> >> the first things the design team is supposed to do is to 
> evaluate if 
> >> any of the existing solutions suffices. if none of the solutions 
> >> satisfy the basic requirements, then the design team 
> should of course 
> >> work on a new solution from scratch.
> >> 
> >> sure, it is preferable to always do only "engineering", but you do 
> >> have to deal with the "other" questions sometimes.
> >>

---

From: Henrik Levkowetz <[email-masked]>
Date: Sat, 28 Oct 2006 02:16:23 +0200

Hi Vijay,

>> Hi Vijay,
...
> work on a solution from scratch.

If *this* is your concern, I believe the question has been
answered repeatedly.  A lot of work existed as input to
the design team, and the design team *didn't* decide to
ignore some of it (see a separate post listing the
proposals).  PMIP was one of those, and it wasn't ignored.
Considering all of the input materials is (in my belief)
what a design team should do.  No?

> I don't see this happening.

We're right now in a 'defend your choices' discussion, rather
than looking at fitness for the requirements.  This is
happening right now.

> designing one from scratch.

There were many proposals submitted as input; and the thoughts
going into them were taken along into the work.  There was no
'design from scratch', in that sense -- if you go through all
the proposed solutions, I believe you'll find elements from
each of them in the final design team proposal.

> considered?", "why did you guys not adopt or build

Right.  We had a number of drafts as input, and considered
them.  And this has been said repeatedly.

But it seems you're demanding that we 'defend' our design
'against' every one of the input drafts, then?  Or is it
only one of the inputs that should be considered?

> don't make a mess out of it.

Oh, we're well on our way, I think.

	Henrik

---

From: Henrik Levkowetz <[email-masked]>
Date: Sat, 28 Oct 2006 03:13:09 +0200

Hi Vidya,

on 2006-10-28 02:16 Narayanan, Vidya said the following:
> Hi Henrik,
> I don't want to spend time on this kind of debate.

Oh, I agree on that.  This kind of debate is something I really could
do without.

> I keep hearing that
> group at the moment.

The proposals are on the table.  Let go of the idea of requesting an
explanation of every little detail of the proposal.  We can't and
shouldn't do that relative to each of the drafts going into the design
team work.  Just evaluate the proposals fairly against the requirements.

> Now, there is a request for standardization of a
> solution based on MIP6 by several people, citing industry direction.

So if *some* ! industry players want the IETF to sign off on the
dotted line, nothing else matters?

> And
> over the DT solution.

This is incorrect.  Phil has posed a set of questions (which haven't
been answered) regarding requirements.  Nobody has been asked to do
what you say above; nobody has been asked to *prove* anything regarding
pmip.  There has been a request for information, in the interest of
doing good engineering.

> That is clearly unfair - if we differ in that
> deserves to understand the reasons behind the DT choice.

The DT mailing list will be made public; it should already have happened,
except I've been working too hard and simply haven't managed to get
around to it.

I'm sorry about that.

> Going down the

Oh?  So are you saying that pmip should get special consideration which
the other proposals going into the design team work should not?

If industry interest is everything, I propose we simply bring GTP to
the IETF and standardise it.  It has much much larger market share
and deployment than PMIP, and is a proven and mature LMM solution.

Enough.

	Henrik

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 27 Oct 2006 19:02:44 -0700

Snipping heavily to focus on the things I'd like to respond to - 

> > Now, there is a request for standardization of a solution based on 
> > MIP6 by several people, citing industry direction.
> 
> So if *some* ! industry players want the IETF to sign off on 
> the dotted line, nothing else matters?

Nobody is asking the IETF to sign off on anything. The industry is
leaning towards a solution that allows maximum re-use of already defined
standards. If we, at the IETF, figure out that there are serious flaws
with that thought, we need to bring those out. 

Nothing on this list has helped me figure it out yet. Supposedly, the DT
figured it out, but, like many others, I'm still waiting to be
convinced. 

Vidya

---

From: "James Kempf" <[email-masked]>
Date: Sun, 29 Oct 2006 12:28:56 -0800

I still don't have an answer to my question, and I would really, really like 
an answer. I've changed the thread title just to make the point perfectly 
clear, probably should have done that from the beginning, sorry.

If the MIP6 WG chair and authors of the two PMIP drafts being put forth in 
the MIP6 group (specifically draft-sgundave-mipv6-proxymipv6-00 and 
draft-chowdhury-netmip6-01) think these drafts address the PS and REQ 
requirements better, from a technical standpoint, then I'd like them to 
stand up and say why they think these drafts better address those 
requirements. I know that the MIP6 WG chair and several of the authors put 
forth a negative opinion during the consenus call, and I'll charitably 
assume that they were being sincere. If their opinion was sincerely 
expressed, then I assume they put forth their opinion because they believed 
that their solutions are technically superior for satisfying the NETLMM 
requirements. So they want their solutions considered. If these folks had 
wanted both solutions to be standardized, I assume that they would have kept 
quiet during the consensus call, or they would have voiced an opinion in 
favor of the DT draft, because they felt that PMIP was an orthogonal 
solution to the solution being proposed by the DT.

And, yes, the onus is on the PMIP people. We had 13 people who voted for the 
DT draft and 6 who voted against it or abstained. By all IETF rules, that 
is, in fact, rough concensus for the DT draft. Rough consensus decisions 
don't need to be unaminous. Phil and I are being somewhat lenient here by 
trying to get some technical discussion from the PMIP people about why they 
think their solution is technically superior, because, in fact, they may be 
right, in which case the NETLMM WG really ought to adopt PMIP as its basis.

C'mon folks. Fish or cut bait. I'm starting to get the impression that the 
PMIP folks don't really have any reason why they believe their solution is 
technicallly superior when they expressed a negative opinion during the 
consensus call, and there are other reasons for proposing these drafts and 
voting against the DT draft.

            jak

---

From: <[email-masked]>
Date: Mon, 30 Oct 2006 11:29:06 -0600

>
>of course not. but a question has been asked about PMIP. I 
>think it should be answered.
>
>> However this isn't about that -- this is about the claim that design 
>> team should *prove* the proposed solution against a specific other 
>> solution -- or all other solutions.
>
>well the question was more like was PMIP considered as a 
>solution or did the design team just decide to work on a 
>solution from scratch.
>
I will try to answer this part of the question. I did raise
this question early in March (i just checked my local archives)
when i saw PMIPv4 draft announcement. I specifically asked
the DT members what it means to NETLMM when we have PMIPv4
and PMIPv6 solutions. Some felt that PMIPv4 is just documenting
the current solution and we should not be too much concerned
about it.Some felt that developing two solutions is not a good idea.
Some felt that we should take it as inputs into our design.
There were about 14 emails exchanged on this topic and i don't
see much of an agreement AFAICT. This thread died off because
we had enough topics to be discussed on our plate :-) I don't
recall any other discussion in the DT mailing list after this.
Perhaps, others may recall better.

On a related topic, the MH as a transport was not discussed
as much as SCTP vs UDP. I don't see much of an issue with
using MH instead of UDP. But i don't think this is the crux
of the issue. If i understand correctly, the issue is about
reusing the MIPv6 solution.

-mohan

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 30 Oct 2006 09:47:11 -0800

thanks a lot Mohan. nobody seemed to want to
answer that question.

> reusing the MIPv6 solution.

this does confirm what I thought, that it was
decided to design a protocol from scratch from the
beginning. infact I tend to think that this was
decided even before the WG got formed because the
initial BoF charter itself spoke about forming a
design team (which I opposed, but never got
anywhere).

anyway, I will wait for the archives to become
public before concluding anything.

Vijay

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 30 Oct 2006 19:05:35 +0100

[email-masked] wrote:
> 
>> of course not. but a question has been asked about PMIP. I think it
>> should be answered.
>> 
>>> However this isn't about that -- this is about the claim that
>>> design team should *prove* the proposed solution against a
>>> specific other solution -- or all other solutions.
>> well the question was more like was PMIP considered as a solution
>> or did the design team just decide to work on a solution from
>> scratch.
>> 
> I will try to answer this part of the question. I did raise this
> question early in March (i just checked my local archives) when i saw
> PMIPv4 draft announcement. I specifically asked the DT members what
> it means to NETLMM when we have PMIPv4 and PMIPv6 solutions. Some
> felt that PMIPv4 is just documenting the current solution and we
> should not be too much concerned about it.Some felt that developing
> two solutions is not a good idea. Some felt that we should take it as
> inputs into our design. There were about 14 emails exchanged on this
> topic and i don't see much of an agreement AFAICT. This thread died
> off because we had enough topics to be discussed on our plate :-) I
> don't recall any other discussion in the DT mailing list after this. 
> On a related topic, the MH as a transport was not discussed as much
> as SCTP vs UDP. I don't see much of an issue with using MH instead of
> UDP.

Well, UDP exists both in v4 and v6, while MH only exists in v6.

Some IPsec implementations understand MH while most understand UDP.

There's no port number for MH, so MH connections are not visible with
netstat.

> But i don't think this is the crux of the issue. If i understand
> correctly, the issue is about reusing the MIPv6 solution.

YEs, so one would quantify how hard is it to 're-use', or how much of
rfc3775 could be re-used vs re-using UDP.

Or how much of the security model of Mobile IPv6 could be re-used.

Alex

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 30 Oct 2006 10:14:29 -0800

Thanks a lot to Mohan - I am glad to finally see a DT member answering
this question after checking the DT emails. It does confirm what I
suspected as well. However, as Vijay said, I'll wait to see the archives
myself before finally concluding, since there was so much alluding to
the archives that went on in the process of discussing this issue. 

Thanks!
Vidya 

> Sent: Monday, October 30, 2006 9:47 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: [netlmm] Network-based mobility -NETLMMDT 
> thanks a lot Mohan. nobody seemed to want to answer that question.
> 
> that design 
> solution or 
> >> did the design team just decide to work on a solution from scratch.
> >>
> > PMIPv4 draft announcement. I specifically asked the DT 
> members what it 
> > means to NETLMM when we have PMIPv4 and PMIPv6 solutions. Some felt 
> > that PMIPv4 is just documenting the current solution and we 
> should not 
> > be too much concerned about it.Some felt that developing 
> two solutions 
> > is not a good idea.
> > There were about 14 emails exchanged on this topic and i don't see 
> > much of an agreement AFAICT. This thread died off because we had 
> > enough topics to be discussed on our plate :-) I don't recall any 
> > other discussion in the DT mailing list after this.
> as much as 
> > SCTP vs UDP. I don't see much of an issue with using MH instead of 
> > UDP. But i don't think this is the crux of the issue. If i 
> understand 
> this does confirm what I thought, that it was decided to 
> design a protocol from scratch from the beginning. infact I 
> tend to think that this was decided even before the WG got 
> formed because the initial BoF charter itself spoke about 
> forming a design team (which I opposed, but never got anywhere).
> 
> anyway, I will wait for the archives to become public before 
> concluding anything.
> 
> Vijay
>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Mon, 30 Oct 2006 12:25:11 -0600

Hi James,

Once again, I am not one of the authors of the drafts but I would like
to share my comments with the group. 
I agree with you, as my previous postings reflect, that the NetLMM DT
draft is a well written and thought through and I do not have any
serious technical objection. However, to be fair to the authors of the
PMIPv6 drafts, I must say that personal drafts usually are used to
introduce or bring a subject to the floor for further discussion and
probably for a DT to be formed for further study/investigation. 

I believe it is always much easier to come up with a comprehensive
**brand new** solution to any issue with a certain list of requirements
than **the real challenge** to evolve/extend/update an existing
solution/protocol to meet the same list of requirements.

Again, I do not think the issue here is how technically sound the NetLMM
DT draft solution vs. PMIPv6 drafts one. I believe the issue is if
PMIPv6 is given the same attention/chance, would it be a viable option
and meet the same list of requirements. Finally, I hope you agree that
this is very desirable for many reasons other than technical ones.

Regards,
Ahmad

> Sent: Sunday, October 29, 2006 2:29 PM
> To: Roberts Phil-APR042; Narayanan, Vidya; Soliman, Hesham; 
> Basavaraj Patil; [email-masked]
> Subject: Why is PMIP a superior solution for NETLMM 
> requireiments? (was: Re: [netlmm] Network-based mobility - 
> NETLMM DT Solution VsAsolutionbased on MIP6)
> 
> I still don't have an answer to my question, and I would 
> really, really like an answer. I've changed the thread title 
> just to make the point perfectly clear, probably should have 
> done that from the beginning, sorry.
> 
> If the MIP6 WG chair and authors of the two PMIP drafts being 
> put forth in the MIP6 group (specifically 
> draft-sgundave-mipv6-proxymipv6-00 and
> draft-chowdhury-netmip6-01) think these drafts address the PS 
> and REQ requirements better, from a technical standpoint, 
> then I'd like them to stand up and say why they think these 
> drafts better address those requirements. I know that the 
> MIP6 WG chair and several of the authors put forth a negative 
> opinion during the consenus call, and I'll charitably assume 
> that they were being sincere. If their opinion was sincerely 
> expressed, then I assume they put forth their opinion because 
> they believed that their solutions are technically superior 
> for satisfying the NETLMM requirements. So they want their 
> solutions considered. If these folks had wanted both 
> solutions to be standardized, I assume that they would have 
> kept quiet during the consensus call, or they would have 
> voiced an opinion in favor of the DT draft, because they felt 
> that PMIP was an orthogonal solution to the solution being 
> proposed by the DT.
> 
> And, yes, the onus is on the PMIP people. We had 13 people 
> who voted for the DT draft and 6 who voted against it or 
> abstained. By all IETF rules, that is, in fact, rough 
> concensus for the DT draft. Rough consensus decisions don't 
> need to be unaminous. Phil and I are being somewhat lenient 
> here by trying to get some technical discussion from the PMIP 
> people about why they think their solution is technically 
> superior, because, in fact, they may be right, in which case 
> the NETLMM WG really ought to adopt PMIP as its basis.
> 
> C'mon folks. Fish or cut bait. I'm starting to get the 
> impression that the PMIP folks don't really have any reason 
> why they believe their solution is technicallly superior when 
> they expressed a negative opinion during the consensus call, 
> and there are other reasons for proposing these drafts and

---

From: Basavaraj Patil <[email-masked]>
Date: Mon, 30 Oct 2006 15:20:45 -0600

Jim,

>clear, probably should have done that from the beginning, sorry.

Let me say first of all that I am not in any way claiming superiority
of one solution over another. I really have not done an analysis or a
simulation to determine that PMIP is a technically better solution (to
use the terms in the subject). I for one (speaking as an individual
without any WG chair hats on) am satisfied if the Netlmm WG and the DT
has concluded that given the requirements and problem statement, the
DT solution in the I-D draft-giaretta-netlmm-dt-protocol-02 is the
appropriate one. 

>requirements. 

I am not an author on either one of the above I-Ds. So I will not
comment on specifically how these solutions stack up to the
requirements of the netlmm WG.

> I know that the MIP6 WG chair and several of the authors put
>assume that they were being sincere.

I would very much like to clarify that my response to the consensus
call (in my email
http://www1.ietf.org/mail-archive/web/netlmm/current/msg00825.html)
was not in my role as a MIP6 WG chair. I should have probably stated
this in my email and avoided the confusion. Apologies for that. But
let me say that my opinion w.r.t the consensus call was as an
individual WG member (without any chair hat whatsoever) and has no
greater relevance than anyone elses opinion in the WG.
As a WG chair for MIP6 I do not for an instant want to opine (unless
specifically asked to comment) the choices and decisions that Netlmm
makes in my WG chair role. So please do not mix up my MIP6 chair role
in my response to the consensus call.

> If their opinion was sincerely
>requirements. 

>So they want their solutions considered. If these folks had
>wanted both solutions to be standardized, I assume that they would
>have kept quiet during the consensus call,

I think the underlying belief here is that if PMIP were to be
considered the netlmm DT solution would be redundant. I have no such
expectation. And my response to the consensus call stated that the WG
should consider all solutions and as the WG is aware, there are
several solutions (draft-templin-autoconf-netlmm-dhcp-04.txt, 2 PMIP6
I-Ds that you mentioned above and, the DT draft). You asked for an
opinion and I gave one acting as an individual.

Regarding whether I think both solutions need to be stanardized, I
have stated that given the deployment models and wide-area mobility
choices that an operator makes, the choice of what kind of network
based mobility solution is chosen is upto the operator. So standardize
both and let the operators choose. Maybe at some point in time, there
will be enough data to help the operators make a better choice (at
least I do not have such data at the present time). My opinion about
standardizing both was based on ensuring that the work on specifying
any network based solution is done in the IETF and is not undertaken
by every network architecture development entity (i.e 3GPP, 3GPP2,
WMF, etc.) which would make matters even worse.

> or they would have voiced an opinion in

I dont know if PMIP is orthogonal to the DT draft. Dont you think that
the requirements can be addressed by either of these? But as I have
said before if the DT and WG is clear about the solution based on the
requirements and have assessed alternatives, I have no problem with
that decision. 

>right, in which case the NETLMM WG really ought to adopt PMIP as its

So, now if you look at the goals/requirements that netlmm has set out
in draft-ietf-netlmm-nohost-req-05.txt:

1. Handover Performance Improvement (Goal #1)

First of all, I think that handovers with latency < 70 ms is something
that can only be accomplished if you have lower layer
support. Secondly, I would also say that you can do this even without
relying on network based mobility (i.e host based solutions can
accomplish this just as well). Thirdly, I am wondering if the latency of <
70ms is implictly assuming some specific air interfaces?
But I think this requirement can be met (challenging no doubt because
of the stringent time constraints) by any of the solutions.

2. Reduction in Handover-related Signaling Volume (Goal #2)

My interpretation of this requirement is that it is driven by a need
to not have the host and hence the air interface used for HO
signaling. With any network based mobility solution wherein you are
moving the tunnels associated with a host to a different BS/access
point, this issue is taken care of.
So the question is does PMIP or Netlmm offer a more optimized
signaling to do this tunnel management. Several possible answers. You
can consider MIP6 with HMIP type of model in which case the signaling
is optimized. So I dont think there is a clear (IMHO) advantage or
disadvantage of choosing either solution.

3. Location Privacy (Goal #3)

AFAICT this issue is addressed equally well by the use of an HMIP6
type of deployment which can cover a significantly large geographical
space (depends on network deployment and planning of course). So this
requirement does not have any specific bearing on the solution itself.

4. Limit Overhead in the Network (Goal #4)

Optimize the number of bits on the wire in the access network to
manage the tunnel. Is this right? If so, I dont see one solution being
technically superior (or vastly superior at least) over another.

5. Simplify Mobile Node Mobility Management Security by Deriving from
   IP Network Access and/or IP Movement Detection Security (Goal #5)

Again, is'nt there a solution already for HMIP6 security? So if you
were to consider PMIP with an HMIP type of deployment or extension, I
think the security concerns would be addressed. My point is that this
requirement is also something that does not make the choice of
netlmm-dt-solution automatic.

6. Link Technology Agnostic (Goal #6)

This requirement is pretty straight forward and I dont think either of
the solutions are dependent on the access/link-layer
specifics. However to achieve that <70ms HO, I wonder if it can be
really access agnostic.

7. Support for Unmodified Mobile Nodes (Goal #7)

The whole point of network based mobility support is to support
mobility for hosts without making enhancements to it. So I guess this
requirement can be met by any network based mobility solution.

Having said that, I still think that the requirement itself is a bit
strange because there is no reason to have such a requirement. If you
need to support a feature, some degree of change is to be
expected. But anyway, this issue has been discussed in the past. I
just had to say this one more time :)

8. Support for IPv4 and IPv6 (Goal #8)

I do agree that PMIP6 is only intended as a mobility solution for IPv6
hosts and relies on MIP6 as the global mobility protocol. Support for
IPv4 at least as far as I know is not addressed.
So maybe this is a requirement that PMIP6 cannot meet.

9. Re-use of Existing Protocols Where Sensible (Goal #9)

Reuse... I guess this could also be implied as considering reusing a
protocol like MIP6 for tunnel management.

10. Localized Mobility Management Independent of Global Mobility
    Management (Goal #10)

The point of PMIP is to basically reuse the same protocol for network
based mobility. The reasons for these have been mentioned in the
emails from Stefano et al.

11. Configurable Data Plane Forwarding between Local Mobility Anchor
    and Mobile Access Gateway (Goal #11)

Use of IP-in-IP or other tunnelling solutions is a choice. I dont
think this will affect the choice of the netlmm protocol solution
significantly. 

>voting against the DT draft.

So at least from my prspective, the requirements can be addressed one
way or another. I cant say without real-data (simulations) if one is
technically superior over another. But if someone has this kind of
data and would be willing to share it, I would be more than glad to
review it and be convinced about the protocol choice.

Lastly, I would like to say that I am not asking Netlmm change their
opinions or views about what protocol makes sense for them to
standardize. Obviously the folks in the DT and the active WG members
are in a better position to make such a decision.

Now with my MIP6 chair hat on:
The MIP6 WG was asked to consider PMIP. And a discussion of this work
is scheduled for the WG meeting in San Diego. Personally I do not view
this work as being in conflict with the Netlmm scope and DT
solution. So I would hope that people do not view this work being
proposed in MIP6 as an alternative to netlmm work. There is a lot of
tension and emails with strong language being exchanged on this
topic. I hope people would just take a rational view of the
engineering issues and solutions and refrain from accusations one way
or another. 

Cheers,
-Raj

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 30 Oct 2006 15:06:35 -0800

Having glanced through 'draft-sgundave-mip6-proxymip6',
I'll ask the obvious question: isn't it true that the PMIP
proposals (or, at least the sgundave proposal) are about
maintaining a stable *home* address while the NETLMM/DT and
NETLMM/DHCP proposals are about maintaing stable *regional*
addresses? If so, then is it possible that the two solutions
are complementary rather than one vs. the other?

For my application, the stable regional address is probably
going to best satisfy the majority expected use cases since
traffic won't have to flow through a (possibly) distant home
agent. But it seems like other applications could benefit
from a stable home address since it would give the MN
something stable to put into the global DNS whereas a stable
regional address alone might not. So from that standpoint,
I guess the question is whether the MN should participate
in the global mobility signaling or whether it is OK for a
proxy in the network to do that?

Thanks - Fred

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 30 Oct 2006 19:46:01 -0800 (PST)

> are complementary rather than one vs. the other?

It is true, our proposal is about maintaining a stable home
address/prefix. This may complement the DT work, as you say.
The core idea is to leverage the MIPv6 signalling, infrastructure
and offer a network based mobility solution. I will not dare to
enter the NETLMM vs PMIP discussion. In my mind, not speaking
on behalf of the other authors, I'd say, its a useless
discussion comparing this draft with the NETLMM DT draft. The
objectives and the scope may be different. I just say, for
certain operating environments, a solution based on proxy MIPv6
is required and this is a step towards that. This proposal may
or may not be as grand as the DT draft. Based on certain market
data, we see a need for this solution and we want to standardise
this. The scope and the interest of this work is just limited by
that goal.

Regards
Sri

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 30 Oct 2006 21:04:17 -0800

Hi Fred,

Templin, Fred L wrote:
> regional address alone might not. 

this makes sense when you do use a global mobility
management protocol *and* a local mobility
management protocol at the same time. the equivalent
when you use host-based mobility management protocols
is running MIPv6 and HMIPv6 at the same time.

but there are many deployments where there are no
two levels of IP mobility. there are also deployments
where there are two levels of IP mobility, but the
local mobility management protocol is at L2.

when you consider a particular domain which is running
just *one* network mobility management protocol, there
is no difference between running PMIPv6 or NETLMM. MAG
is equivalent to the PMA, LMA is equivalent to the HA
and the regional IP address/prefix is the same as the
home address/home prefix.

as far as I am concerned, we are not labeling PMIPv6
as a network-based global mobility management
protocol. it can be used a network-based local mobility
management protocol. in fact I think its a bad idea to
use anything other than a host-based mobility management
protocol when the mobility signaling is happening over
the Internet.

Vijay

---

From: Jean-Mickael Guerin <[email-masked]>
Date: Tue, 31 Oct 2006 09:07:35 +0100

Hi,
> protocol when the mobility signaling is happening over
If someone knows: where PMIPv4 is deployed, end users take really
benefit of a global mobility service or actually end users is only
roaming inside a domain ?

Jean-Mickael

---

From: "James Kempf" <[email-masked]>
Date: Tue, 31 Oct 2006 00:13:13 -0800

Raj,

Thanx for clarifying.

            jak

----- Original Message ----- 
From: "Basavaraj Patil" <[email-masked]>
To: "ext James Kempf" <[email-masked]>; "Phil Roberts" 
<[email-masked]>; "Narayanan, Vidya" <[email-masked]>; 
"Soliman, Hesham" <[email-masked]>; <[email-masked]>
Sent: Monday, October 30, 2006 1:20 PM
Subject: Re: Why is PMIP a superior solution for NETLMM requireiments? (was: 
Re: [netlmm] Network-based mobility - NETLMM DT Solution VsAsolutionbased on 
MIP6)

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 31 Oct 2006 00:36:33 -0800

At the last couple of IETFs, we have discussed this quite a bit, but the
topic seems to be coming up again. In my view, the use of network-based
mobility for anything other than local mobility is bad. Global mobility
management is meant to deal with mobility across heterogeneous
interfaces and mobility across administrative domains. Network-based
mobility solutions have inherent problems with such scenarios. Just
because PMIPv6 is based on MIP6 does not mean that it automatically has
the same scope as MIP6. IMHO, NETLMM and PMIP6 are solving the same
problem and suffer from exactly the same limitations in terms of
applicability. 

As many would recall, we had a discussion in Dallas on network-based
global mobility and talked about why it is a bad idea. As far as I know,
nothing has happened to change that view. 

Regards,
Vidya

> Sent: Monday, October 30, 2006 9:04 PM
> To: Templin, Fred L
> Cc: [email-masked]
> Subject: Re: Why is PMIP a superior solution for NETLMM 
> requireiments?(was:Re: [netlmm] Network-based mobility - 
> NETLMMDT SolutionVsAsolutionbased on MIP6)
> 
> Hi Fred,
> 
> Templin, Fred L wrote:
> I'll ask the 
> > obvious question: isn't it true that the PMIP proposals 
> (or, at least 
> > the sgundave proposal) are about maintaining a stable 
> *home* address 
> > while the NETLMM/DT and NETLMM/DHCP proposals are about maintaing 
> > stable *regional* addresses? If so, then is it possible 
> that the two 
> > solutions are complementary rather than one vs. the other?
> > 
> going to 
> > best satisfy the majority expected use cases since traffic 
> won't have 
> > to flow through a (possibly) distant home agent. But it seems like 
> > other applications could benefit from a stable home address 
> since it 
> > would give the MN something stable to put into the global 
> DNS whereas 
> > a stable regional address alone might not.
> 
> this makes sense when you do use a global mobility management 
> protocol *and* a local mobility management protocol at the 
> same time. the equivalent when you use host-based mobility 
> management protocols is running MIPv6 and HMIPv6 at the same time.
> 
> but there are many deployments where there are no two levels 
> of IP mobility. there are also deployments where there are 
> two levels of IP mobility, but the local mobility management 
> protocol is at L2.
> 
> when you consider a particular domain which is running just 
> *one* network mobility management protocol, there is no 
> difference between running PMIPv6 or NETLMM. MAG is 
> equivalent to the PMA, LMA is equivalent to the HA and the 
> regional IP address/prefix is the same as the home 
> address/home prefix.
> 
> as far as I am concerned, we are not labeling PMIPv6 as a 
> network-based global mobility management protocol. it can be 
> used a network-based local mobility management protocol. in 
> fact I think its a bad idea to use anything other than a 
> host-based mobility management protocol when the mobility 
> signaling is happening over the Internet.
> 
> Vijay
>

---

From: "Junghoon Jee" <[email-masked]>
Date: Tue, 31 Oct 2006 17:47:37 +0900

Vidya,

> As many would recall, we had a discussion in Dallas on 
> network-based global mobility and talked about why it is a 
> bad idea. 

I was also at that BoF. However, I suppose my memory is so bad...  :-)
Can you help me to refresh my memory?

-Junghoon

> As far as I know, nothing has happened to change that view. 
> 
> Regards,
> Vidya
> 
> > requireiments?(was:Re: [netlmm] Network-based mobility - NETLMMDT 
> > SolutionVsAsolutionbased on MIP6)
> > 
> > Hi Fred,
> > 
> > Templin, Fred L wrote:
> management protocol 
> > *and* a local mobility management protocol at the same time. the 
> > equivalent when you use host-based mobility management protocols
is 
> > running MIPv6 and HMIPv6 at the same time.
> > 
> > but there are many deployments where there are no two levels of IP

> > mobility. there are also deployments where there are two 
> levels of IP 
> > mobility, but the local mobility management protocol is at L2.
> > 
> > *one* network mobility management protocol, there is no difference

> > between running PMIPv6 or NETLMM. MAG is equivalent to the 
> PMA, LMA is 
> > equivalent to the HA and the regional IP address/prefix is 
> the same as 
> > the home address/home prefix.
> > 
> > network-based global mobility management protocol. it can be used
a 
> > network-based local mobility management protocol. in fact I 
> think its 
> > a bad idea to use anything other than a host-based mobility 
> management 
> > protocol when the mobility signaling is happening over the
Internet.

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 31 Oct 2006 01:19:29 -0800

An attempt at addressing a few more points below: 

<snip>
 
> It's important to distinguish between a couple of cases that 
> may get conflated, 1) reusing a home agent, and 2) reusing 
> protocol fields.  You are arguing here not so much for 
> reusing a MIP6 home agent as reusing protocol fields?  
> Reusing a home agent has value because there is running code 
> and demonstrated interoperability with other network 
> entities.  I'm not sure what the value of reusing protocol 
> fields or bits on the wire.  One could make an argument that 
> by reusing the format of bits on the wire, then it's easier 
> to modify a home agent to do the things you want done in the 
> case you are not actually reusing the home agent as is.  That 
> doesn't seem to me at least do be a very strong argument.
> 
> While I agree that some of the things below are must haves, I 
> don't agree that getting those things with reuse of the 
> mobility header buys much in standardization, implementation, 
> or operation.  

I think the re-use buys a lot in terms of both standardization and
implementation. Any of the functionality that would be needed for
network-based mobility needs to be re-done here. Plus, when an entity
already understands these options, there is an implementation re-use
that is also valuable. 

> That being said I've still commented on them.
> 
> In the response to the points below I'm assuming that the 
> intent is to be able to reuse the MH options for a home agent 
> where we have an LMA in the NETLMM design, in either the case 
> where an HA is used with PMIP6 or for an LMA.
> 

Yes. 

> Agree that you need the ability to identify mobiles apart 
> from an IP address.
> > 
> > 2. DNS-based HA lookup
> > 

The DT draft has gone down a different path for LMA selection - that is
certainly practical for many NETLMM deployments. But, in certain
scenarios, I can see the use of DNS or DHCP for the same. 

> Knowing the home network id or information about the home 
> network seems superfluous as the entities in a local mobility 
> management scenario are in the same network already.  And 
> given that the mobile is unaware of the concept of a mobility 
> anchor it's not clear to me what defining the ability to find 
> one through DHCP really buys us.

Same as the comment above. In fact, some systems today, use stateless
DHCP to get configuration information to the mobile. The relay agent
(the MAG, in a NETLMM scenario) would then be able to obtain the LMA/HA
corresponding to the MN using DHCP. And, since the LMA and MAG belong to
the same domain, the integrated scenario (for which the DHCP options are
primarily written) is all the more applicable. 

> Could you clarify the scenario you envision here?

The IP address of the MN within the NETLMM/PMIP domain can be made
available for DNS queries. The LMA/HA will update the DNS server of the
MN ID (FQDN) to IP address mapping. 

> There might be a use for these, but I'm not sure.  It seems 
> to me that a dual stack scenario for a localized mobility 
> architecture could be quite different.  These presuppose 
> using MIP6 for that but it might be the case that in a 
> different architecture the implementation of dual-stack is simpler?
> > 

I'm not sure how the dual-stack scenario is any simpler. In fact, the
dual-stack scenario is best supported by host-based mobility, since both
IPv4 and IPv6 CoAs can be tied to one HoA. However, I'd envision that
these options can pretty much be reused for independent network-based
mobility of both IP addresses tied to a given interface of an MN within
the NETLMM/PMIP domain. 

> This is another case where differences in the architecture 
> may make the resulting support of the function simpler?  If 
> the function is simpler because the mobile is not involved, 
> will you need the function in the same way?
> > 

I don't see how it is simpler. At the infrastructure end, the LMA is
still maintaining all the state needed for mobility management. 

> You'll have to help me with the use case for this.

With IPv6, a node can have multiple IP addresses on a certain interface.
Multiple IP addresses corresponding to a given MN can be registered
using this work that is currently underway in Monami6. 

> Not sure I agree with this.  Certainly NETLMM has chosen to 
> go down a path of dealing with prefixes per mobile node but 
> it isn't clear in my mind yet whether the semantics of that 
> are the same as the semantics of NEMO.  If so, I don't 
> disagree, I'm just not sure.

The prefixes assigned to an MN in NETLMM are different from those that
an MN may be serving in the capacity of an MR. Essentially, the NETLMM
prefix is a prefix assigned to the egress interface of an MN, while the
NEMO prefix is the one an MR is serving on its ingress interface. When a
NETLMM/PMIP MN is also acting as an MN, serving a prefix on its ingress
interface, I think the NEMO extensions apply as such. 

So, we can go down the existing list of extensions and discuss in detail
about each one. But, I don't think that is the most useful thing to do.
The bottomline is that there are many extensions that can be reused,
even if not all can be reused. And, we'll continue to define more in the
future as need arises - there is no reason to do those in two places.
And, there will probably be some extensions that only apply to one or
the other. But, the reuse of those feasible, given that the set is quite
large, still seems very valuable to me in terms of both standardization
and implementation. 

Thanks,
Vidya

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 31 Oct 2006 11:00:14 +0100

Junghoon Jee wrote:
>> network-based global mobility and talked about why it is a bad 
>> idea.
> 

Dallas minutes Mobility Architectures for the Internet:
http://www.archivesat.com/post714833.htm

Montreal minutes Global IP Mobility Management:
http://www1.ietf.org/mail-archive/web/mipshop/current/msg02784.html

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 31 Oct 2006 18:00:58 +0100

Narayanan, Vidya wrote:
> At the last couple of IETFs, we have discussed this quite a bit, but 
> the topic seems to be coming up again. In my view, the use of 
> network-based mobility for anything other than local mobility is bad.
>  Global mobility management is meant to deal with mobility across 
> heterogeneous interfaces and mobility across administrative domains. 
> Network-based mobility solutions have inherent problems with such 
> scenarios. Just because PMIPv6 is based on MIP6 does not mean that it
>  automatically has the same scope as MIP6. IMHO, NETLMM and PMIP6 are
>  solving the same problem and suffer from exactly the same
> limitations in terms of applicability.
> 
>  global mobility and talked about why it is a bad idea. As far as I 
> know, nothing has happened to change that view.

Prior to Dallas, we have also seen host _and_ router mobility prototyped
and tested with BGP, no host involvement, over large areas, through
public Internet core routers.

I wouldn't be that quick to discard global network-based mobility.  I
would debate the meaning of 'global' though.

Alex

---

From: Jari Arkko <[email-masked]>
Date: Tue, 31 Oct 2006 23:52:18 +0200

Basavaraj,

Thanks for your analysis of the requirements. We
need to focus and talk about the requirements
fullfillment, scenarios that are being addressed,
technical, concrete things. So your analysis is
a good part of that. Some further work is still
needed, however. For instance, over the last
months we've had a lot of discussions about the
nature of the interface NETLMM provides for
the hosts, and what the subnet model needs
to be. I think we are finally starting to understand
how it can be made to work. Is the situation the
same in the PMIP solution, or different?
> engineering issues and solutions and refrain from accusations one way
Let me just state first that I am concerned about the
high tension here. Everyone, please keep in mind the
basic IETF discussion groundrules and focus on the
technical content, not the intentions or qualities of
the persons involved.

In any case, there are a number of factors
at a high level that we need to consider.
The problem we are trying to solve, and
its detailed requirements is an obvious
topic.

Another issue is that we are in the IETF to
make standards. The option of publishing
all proposals makes sometimes sense, but
not always. The point of the standards is
that we have a common way to do something.
Sometimes achieving that common way
means having to pay a price in terms of
not getting all the functions that someone
wanted, not getting the exact solution
some group wanted, etc. Deciding the
compromise may thus be painful for the
participants. But there should be effort
in trying to get there before we give up
and create multiple solutions. I don't think
we've spent enough effort on this issue
yet to make that call.

The third issue is timing. As most of us
are probably aware, if we do not make
a decision in a timely manner others
will in practice make the decision for us.
As a result, I do not think we can wait
infinitely long. I have suggested to both
the NETLMM and MIP6 chairs that we
should continue the discussion on list
before the meeting, talk about this in
the meetings but that a week or two after
the meeting we need to know what to
do.

Finally, the primary way that new work
gets done in the IETF is the BOF and
rechartering processes. We need to
respect the results of those processes,
even if we as individuals may not always
agree with them. If we want add more
chartered standards work in this space,
it needs to happen through the same
process.

--Jari