Subject: [netlmm] Scope of revised charter: MN impact

From: Basavaraj Patil <[email-masked]>
Date: Tue, 17 Jun 2008 14:05:39 -0500

Hello,

The Netlmm charter (current) has expressly prohibited changes to the MN in
the context of mobility management. This limitation should be removed from
the revised charter. In order to enable inter-technology handovers or to
support mutihoming capability or other enhancements now being suggested, it
would be useful in the design process to have the ability to make
enhancements to the MN as well.

I hope the chairs will consider making the change in the revised charter.

-Raj

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

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 17 Jun 2008 13:12:54 -0700

Hello Raj,

I'm curious about this.  I thought the entire point of [netlmm] was that
some (or, quite a few) devices could not be expected to run IETF
mobility protocols (e.g., Mobile IPv6) because they could not be
modified.  If they can be modified, then the point of [netlmm] goes
way, doesn't it?  I realize this is a somewhat simplistic view of the
situation, but it would be nice to find out exactly why the devices
can't run the expected IETF protocols.  Otherwise, we might design
a solution requiring changes that, oops, still "could not" be implemented
for the wireless devices.

Regards,
Charlie P.

---

From: Basavaraj Patil <[email-masked]>
Date: Tue, 17 Jun 2008 15:25:49 -0500

Hi Charlie,

I don't believe there really is an issue as to what type of devices are
capable or not of running IETF mobility protocols. It has more to do with
whether the mobility protocols are implemented on hosts, performance (or
perceived performance :) ), overhead on air interfaces etc. These factors
and others lead to deployment choices of either host based mobility or
network based mobility.
Network based mobility does add value since it can provide mobility to
unmodified hosts (which has been the basis of the work). However what we did
realize is that in order to support multihoming, intertech HO etc. some
interaction with the MN would be useful. And that is what I am suggesting
that the charter allow. As an example, it would be useful if the MN can
indicate when it moves between MAGs that the new MAG should set the HO Flag
which will enable the LMA to assign the same address/prefix and there is no
ambiguity about whether the MN is attaching via a new interface. Such
information can also be obtained within the network itself by context
transfer or other means. However having the MN indicate it would be the most
optimal.

I don't think there really is an issue of what can and cannot be implemented
on a wireless device; At least not in the scope of the Netlmm charter.

-Raj

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 17 Jun 2008 13:44:06 -0700

Hello Basavaraj,

Of course you bring up some interesting points.  I'd like to
ask a few follow-on questions.

Basavaraj Patil wrote:
> capable or not of running IETF mobility protocols.

Well, I have to say that is pretty much at odds with various statements
I have heard about the willingness some device manufacturers in this matter.

>  It has more to do with

I'll always go with increased performance. 

> unmodified hosts (which has been the basis of the work).

This is one of the points I wanted to expand.  I think that there is too 
much distinction
drawn between network-based mobility and host-based mobility.  In fact, 
under
most scenarios the network controls the ability of the host to make the 
attachment,
and that could be considered network-based mobility.  On the other hand, 
we can
make it harder or easier for the device to choose its point of 
attachment, and if
there are nice, globally-accessible home agents available for the mobile 
node,
more choices might be made available.  PMIPv6 doesn't make the home agent
available to the mobile node, so it falls short in this regard.

>  However what we did
> interaction with the MN would be useful.

I have no doubt about that :-)

>  And that is what I am suggesting
> ambiguity about whether the MN is attaching via a new interface.

Would the MAG acknowledge?

What if the signal from the mobile node had, say, a MIPv6
Binding Update extension :-)?

Regards,
Charlie P.

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 17 Jun 2008 13:44:23 -0700 (PDT)

Hi Charlie,

The basic assumption of the NETLMM, the non-involvment of the client
in mobility signaling should always hold true. That requirement should
not be relaxed. The protocol that is on the table today is designed
with that goal. All aspects of the protocol will function with
absolutely zero changes to the host stack. This includes even the
inter-technology handoff. There is some confusion that the requirement
of virtual interface support on the host implies changes to the host
stack. That is absolutely not true, Ryuji and me will demonstrate this
soon.

Now, w.r.t to the comment from Raj that we need allow changes to host.
These changes are minor optimizations. Examples of such optimizations
include:

- The ability for the host and the access router to perform capability
   exchange
- Prefix colouring, the ability for the host to distinguish between
   a prefix that has mobility properties to a local prefix
- Some minor SEND related extensions
- Optimizations w.r.t DNA, for improving the handoff latency

None of this can be equated to a client stack requirement. These fall
in the scope of the general IPv6 host stack improvements and in the
context of NETLMM. W.G should see the host stack changes objectively
and not go with one blind rule.

Regards
Sri

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 17 Jun 2008 14:01:08 -0700

Hello Sri,

It seems to me that you have certain strong ways of
classifying which changes are legitimate, based on
whether they affect the client's "stack".  Can you be
a bit more specific about this?  How can I tell whether
something affects the "stack"?  Will all such client
signals be handled over some UDP, TCP, or SCTP
port?

Regarding:

>       .......      W.G should see the host stack changes objectively

I was going to ask how many blind rules we should have,
but then I thought maybe some people would not find it
to be very funny.  Nevertheless, I'd like to find out how
an impartial observer could distinguish between a blind
rule and charter mandate.

Regards,
Charlie P.

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 17 Jun 2008 15:27:10 -0700 (PDT)

Hi Charlie,

The broad goal is not to involve the client in mobility
management signaling. The examples cited here all confirm
to this goal. Providing certain hints, to the client
either in the form of RA's or through other mechanisms
only to improve either the clients ability to make a better
decision or for the network to understand the clients
intent, are just optimizations. This cannot be a difficult or
a controversial decision. We all can differentiate between a
an optimization vs what is a client equivalent functional
addition to the host.

> to be very funny.  Nevertheless, I'd like to find out how

:)

> rule and charter mandate.

This is clearly the job of the chairs and the AD. They will
ensure new proposals meet this criteria.

Regards
Sri

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Tue, 17 Jun 2008 18:44:40 -0400

> ensure new proposals meet this criteria.

No. This would be decided by NETLMM WG (and IETF) consensus. Not the
chairs and the AD.

Vijay

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 17 Jun 2008 15:56:07 -0700

Hello Sri,

I hope you won't mind if I explore your points a bit further.

Sri Gundavelli wrote:
> in mobility signaling should always hold true.

Is it possible to explain what is valuable about distinguishing
between mobility signaling versus other signaling?

> All aspects of the protocol will function with
> absolutely zero changes to the host stack.

That, as we will agree I am sure, has some value for
enabling host mobility for hosts that cannot adapt.

> This includes even the
> stack.

In another message, I asked how I can know if
something has changed on the host's "stack".
Does the virtual interface support run as an
application in user space?

> - The ability for the host and the access router to perform capability

Hmmm....  I guess you mean something more than would be
needed to establish a link to the access router.

>   a prefix that has mobility properties to a local prefix

Hmmm....  I guess you mean whether or not the network
enforces PMIPv6.  But, just as an example, if the mobile node
were allowed to run Mobile IPv6, this would be totally unnecessary.

Regards,
Charlie P.

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 17 Jun 2008 15:57:30 -0700 (PDT)

> No. This would be decided by NETLMM WG (and IETF) consensus. Not the

Fair enough ! At the end, every thing is a WG decision. But, there
is a general direction of the WG that confirms to the larget IETF
direction. Any case, I wont object to the comment that we all are
in power :)

Yes, the WG can decide, if a given extension is an optimization
or an introduction of software service on to the host. Sure, we dont
want another client on the host.

Sri

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 17 Jun 2008 16:34:08 -0700 (PDT)

Hi Charlie,

> between mobility signaling versus other signaling?

Sending a signaling message for creating a binding vs
sending an option in a RA message, both can be viewed
as signaling messages. But, clearly there is difference
in those two messages. This can be argued in legal terms
as both are same, but not when its seen from a technical
angle. One is for an optimization.

> enabling host mobility for hosts that cannot adapt.

The right word is Significant value :), for hosts that
cannot adopt or for operators that do not want to roll out
another software on to a client, given the variants of
operating systems and OS versions.

> application in user space?

What truely is a host stack change. I'd say modifications
to the base IPv6 specifications is an host stack change.
Extensions to 4861 messages is a host stack change. Requiring
DNAv6 is a host stack change.

Virtual interface implementation is not a host stack
change, its a simply configuration on the host. All OS's
provide semantics to create these logical interfaces,
decoupling physical interfaces.

> needed to establish a link to the access router.

The network can learn that the client is capable of doing
mobility management or the client can learn its in a managed
network and it can relax :). These extensions are not required
for the protocol operation. However I see it, it only enables
both the parties to make better choices.

> were allowed to run Mobile IPv6, this would be totally unnecessary.

If the prefix properties are notified to the client, clients that
are MIP capable (if any MIP client stacks make it to any host),
can use this effectively. But, I agree if the client is running
MIP6, in the scenario of integrated PMIP/CMIP network, it should
know, its home. The CMIP-PMIP interactions doc should take care
of this.

Regards
Sri

---

From: "Premec, Domagoj" <[email-masked]>
Date: Wed, 18 Jun 2008 11:47:49 +0200

Hi,

I share the opinion that changes to the host are necessary in some scenarios and I support removing this limitation from the revised charter.

I don't think we should make a distinction whether changes to the host impact IP stack, a user space daemon or a shell script. For example, even if the MN has support for virtual interfaces, the virtual interface used for the netlmm domain will have to be under the control of some piece of software that is not there today.

domagoj

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Sri Gundavelli
> Sent: 18. lipanj 2008 01:34
> To: Charles E. Perkins
> Cc: [email-masked]
> Subject: Re: [netlmm] Scope of revised charter: MN impact
> 
> 
> Hi Charlie,
> 
> 
> Sending a signaling message for creating a binding vs sending 
> an option in a RA message, both can be viewed as signaling 
> messages. But, clearly there is difference in those two 
> messages. This can be argued in legal terms as both are same, 
> but not when its seen from a technical angle. One is for an 
> optimization.
> 
> 
> >>  All aspects of the protocol will function with  absolutely zero 
> >> changes to the host stack.
> >
> > That, as we will agree I am sure, has some value for enabling host 
> > mobility for hosts that cannot adapt.
> >
> 
> The right word is Significant value :), for hosts that cannot 
> adopt or for operators that do not want to roll out another 
> software on to a client, given the variants of operating 
> systems and OS versions.
> 
> >
> >>  This includes even the
> >>  inter-technology handoff. There is some confusion that the 
> >> requirement  of virtual interface support on the host 
> implies changes 
> >> to the host  stack.
> >
> > In another message, I asked how I can know if something has 
> changed on 
> > the host's "stack".
> > Does the virtual interface support run as an application in user 
> > space?
> >
> 
> 
> What truely is a host stack change. I'd say modifications to 
> the base IPv6 specifications is an host stack change.
> Virtual interface implementation is not a host stack change, 
> its a simply configuration on the host. All OS's provide 
> semantics to create these logical interfaces, decoupling 
> physical interfaces.
> 
> 
> >
> > Hmmm....  I guess you mean something more than would be needed to 
> > establish a link to the access router.
> >
> 
> network and it can relax :). These extensions are not 
> required for the protocol operation. However I see it, it 
> only enables both the parties to make better choices.
> 
> 
> 
> enforces PMIPv6.  
> > But, just as an example, if the mobile node were allowed to 
> run Mobile 
> > IPv6, this would be totally unnecessary.
> >
> 
> If the prefix properties are notified to the client, clients 
> that are MIP capable (if any MIP client stacks make it to any 
> host), can use this effectively. But, I agree if the client 
> is running MIP6, in the scenario of integrated PMIP/CMIP 
> network, it should know, its home. The CMIP-PMIP interactions 
> doc should take care of this.
> 
> Regards
> Sri
> 
>

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 18 Jun 2008 13:57:38 -0500

Hi Charlie,

Comments inline:

> I have heard about the willingness some device manufacturers in this matter.

BP> May be the case. But I think that there may be other underlying reasons
why a device manufacturer chooses to implement one mobility protocol or
solution over another.

> I'll always go with increased performance.

BP> Obviously... You may also consider cost/complexity factors as well in
the equation :)

> available to the mobile node, so it falls short in this regard.

BP> The network is obviously in control of hosts attaching to a network. But
I don't think that would necessarily imply that it can also control
mobility. At least I am not sure I understand your view of what you refer to
above as network-based mobility. There is sufficient distinction between
host and network based mobility even if the protocols and entities are
similar of the same. The only comment that I would state is that it is only
the host which is aware of available networks and its own capability which
can help in the choice of network attachment or mobility protocol. However
in the case where the network itself is enabling mobility, the host may
defer mobility management to the network even if it is capable of mobility
management (host based) for reasons such as network policy, preferences of
the host etc.

> Would the MAG acknowledge?

BP> Possibly. It depends.

> Binding Update extension :-)?

BP> Why? Is it needed? If the host wants to send a BU when attached to a
network which supports PMIP6 for example, it may do so by using the local
prefix instead of the HNP in the RA. The network policy may still control
the choice of mobility by the MN. But in general I think there is not a
technical issue about whether the host can send a MIP6 BU in a PMIP6 enabled
network. 

-Basavaraj

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 18 Jun 2008 14:16:01 -0500

I am not sure that there is a specific goal per se to not involve a host in
mobility management signaling. The network based mobility protocol (PMIP6)
enables mobility for hosts that may not have any mobility capability
support. In addition, there may be various reasons to optimize the mobility
related signaling over the link between the host and the access router in
certain deployments in which case an operator may prefer to manage the
host's mobility with a network based mobility approach (even if the host is
capable of mob-mgmt).
The network based mobility protocol can be optimized further to aid
deployments if there is an ability to make some changes to the host. As an
example the ability of the host to parse an RA and understand a PMIP6 prefix
vs a Local one. This is a small enhancement to the MNs IPv6 stack. But it
does enable the host to realize the access routers capability as well as in
making a choice of mobility mode.

So I believe that the Netlmm charter should change its perception of not
making any changes to the host as being sacred. Because some minimal changes
are useful to the protcols efficient operation.

-Basavaraj

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 18 Jun 2008 14:21:25 -0500

> were allowed to run Mobile IPv6, this would be totally unnecessary.

BP> It is not about whether the network enforces PMIP6. Rather it is about
whether the network supports PMIP6. A host which receives multiple prefixes
in the RA (PIOs) can parse whether the prefix is a local prefix (AR subnet)
or is a prefix from an LMA (remote subnet). This flag can aid the MN in its
ability to choose an appropriate prefix.
And if the host prefers to run Mobile IPv6, it can choose the local prefix
and use it for generating a CoA.

-Basavaraj

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 18 Jun 2008 15:41:52 -0500

Hi Raj,

Please see comments inline.

Regards,
Ahmad 

> I am not sure that there is a specific goal per se to not 
> involve a host in mobility management signaling. The network 
> based mobility protocol (PMIP6) enables mobility for hosts 
> that may not have any mobility capability support. In 
> addition, there may be various reasons to optimize the 
> mobility related signaling over the link between the host and 
> the access router in certain deployments in which case an 
> operator may prefer to manage the host's mobility with a 
> network based mobility approach (even if the host is capable 
> of mob-mgmt).
> The network based mobility protocol can be optimized further 
> to aid deployments if there is an ability to make some 
> changes to the host. As an example the ability of the host to 
> parse an RA and understand a PMIP6 prefix vs a Local one. 

[Ahmad]
I believe this is a very useful functionality. IMO, it is not more than
advertising where the HNP is anchored, or something close to this. Also,
my understanding is that legacy host should not be impacted by the
change and if does not understand the new flag, for example, it wont
impact it functionality nor its IPv6 stack. Is my understanding correct?

Thanks,

> This is a small enhancement to the MNs IPv6 stack. But it 
> does enable the host to realize the access routers capability 
> as well as in making a choice of mobility mode.
> 
> So I believe that the Netlmm charter should change its 
> perception of not making any changes to the host as being 
> sacred. Because some minimal changes are useful to the 
> protcols efficient operation.
> 
> -Basavaraj
> 
> 
> > The broad goal is not to involve the client in mobility management 
> > signaling. The examples cited here all confirm to this 
> goal. Providing 
> > certain hints, to the client either in the form of RA's or through 
> > other mechanisms only to improve either the clients ability 
> to make a 
> > better decision or for the network to understand the 
> clients intent, 
> > are just optimizations. This cannot be a difficult or a 
> controversial 
> > decision. We all can differentiate between a an 
> optimization vs what 
> > is a client equivalent functional addition to the host.
> > 
> >> 
> >> I was going to ask how many blind rules we should have, but then I 
> >> thought maybe some people would not find it to be very funny.  
> >> Nevertheless, I'd like to find out how
> > 
> > :)
> > 
> >> an impartial observer could distinguish between a blind rule and 
> >> charter mandate.
> > 
> classifying which 
> >> changes are legitimate, based on whether they affect the client's 
> >> "stack".  Can you be a bit more specific about this?  How 
> can I tell 
> >> whether something affects the "stack"?  Will all such 
> client signals 
> >> be handled over some UDP, TCP, or SCTP port?
> >> 
> >> Regarding:
> >> 
> >> I was going to ask how many blind rules we should have, but then I 
> >> thought maybe some people would not find it to be very funny.  
> >> Nevertheless, I'd like to find out how an impartial observer could 
> >> distinguish between a blind rule and charter mandate.
> >> 
> >> Regards,
> >> Charlie P.
> >> 
> >> 
> >> 
> >> Sri Gundavelli wrote:
> >>>  Hi Charlie,
> >>> 
> >>>  The basic assumption of the NETLMM, the non-involvment of the 
> >>> client  in mobility signaling should always hold true. That 
> >>> requirement should  not be relaxed. The protocol that is on the 
> >>> table today is designed  with that goal. All aspects of 
> the protocol 
> >>> will function with  absolutely zero changes to the host 
> stack. This 
> >>> includes even the  inter-technology handoff. There is 
> some confusion 
> >>> that the requirement  of virtual interface support on the host 
> >>> implies changes to the host  stack. That is absolutely not true, 
> >>> Ryuji and me will demonstrate this  soon.
> >>> 
> >>>  None of this can be equated to a client stack requirement. These 
> >>> fall  in the scope of the general IPv6 host stack 
> improvements and 
> >>> in the  context of NETLMM. W.G should see the host stack changes 
> >>> objectively  and not go with one blind rule.
> >>> 
> >>>  Regards
> >>>  Sri
> >>> 
> >>

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 18 Jun 2008 15:46:57 -0500

Hi Ahmad,

Inline:

---snip---
> impact it functionality nor its IPv6 stack. Is my understanding correct?

Yes. There is no impact to a legacy host which does not understand the
flags.

-Raj

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Thu, 19 Jun 2008 03:12:10 -0700

Hi Sri, Charlie, all,

As Sri correctly stated, "The basic assumption of the NETLMM, the
non-involvement of the client in mobility signaling should always hold
true."

Then I am a bit confused by the classification made by Sri. As soon as
we extend SEND or ND or any other MN-MAG protocol for multihoming or
inter-tech HO support with NETLMM, we are making the MN aware of the
mobility and the mobility protocol. Those changes would be introduced
only because of mobility and therefore must be seen as an involvement of
the client in the mobility management signaling. I see a lot of
contradictions in your classification and analysis below. 

I think the correct way of seeing the point is the following: IETF has
defined two mobility management protocols, one involving directly the
host and requiring support from the host (MIP), and another for hosts
who do not support any mobility management signaling (NETLMM). The
question from Raj boils down to the following: should we extend NETLMM
so that the host is involved in mobility management and support mobility
management signaling?

If this is the case, wouldn't it mean we are re-inventing MIP? If yes,
what is wrong with the current version of MIP? Which is the problem
statement to change it or the requirements not fulfilled by it?

Cheers
Gerardo

> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Sri Gundavelli
> Sent: Tuesday, June 17, 2008 3:27 PM
> To: Charles E. Perkins
> Cc: [email-masked]
client
> >>  inter-technology handoff. There is some confusion that the
requirement
> >>  None of this can be equated to a client stack requirement. These
fall

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Thu, 19 Jun 2008 03:16:13 -0700

Hi Sri,

client
> angle. One is for an optimization.

This is valid in general. But if you send the option in the RA for
mobility purposes, as it would be the case in NETLMM "optimizations",
then I don't see the difference. The difference would just be formal and
not semantic: you would just include an option in a ND message instead
of using a MH message. 

Gerardo

requirement

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Thu, 19 Jun 2008 03:24:18 -0700

Hi Raj and Charlie,

Behalf
> Of Basavaraj Patil
> Sent: Wednesday, June 18, 2008 11:58 AM
> To: Charles Perkins
> Cc: [email-masked]
> >> whether the mobility protocols are implemented on hosts,
performance
> (or
> BP> The network is obviously in control of hosts attaching to a
network.
> But
> mobility. At least I am not sure I understand your view of what you
refer
> to

I think I agree with Charlie here. If we consider how a MIP handoff flow
takes place in a managed operator's network (where PMIP is considered as
an option), I think the following are the high level stapes:

1. MN discovers a new AP/AR
2. MN performs authentication and the network authenticates/authorizes
the MN to access the network
3. MN gets an IP address from the network
4. MN sends a BU
5. HA accepts (authenticates and authorizes) the BU and if everything is
fine, it sends a successful BA

The network is fully in control of step 2 and 5. Depending on the
deployment, it can be in control also of step 3. There is no way for the
MN to perform any handoff if the network does not authorize it or
control it. 

The following steps are for a PMIP flow:
 
1. MN discovers a new AP/AR
2. MN performs authentication and the network authenticates/authorizes
the MN to access the network
3. MN asks for an IP address from the network and the PBU/PBA takes
place.
4. LMA accepts (authenticates and authorizes) the PBU and if everything
is fine, it sends a successful PBA
5. The MN gets the IP address

What is different in terms of control of the network? That the BU is
sent by the network as a PBU? That does not increase at all the control
of the network on the mobility of the host, as the first step is the
only that really triggers the whole mobility event and it is always
performed based on radio conditions; that is the real mobility which is
either host-controlled or network-controlled. But this has nothing to do
with IETF

Gerardo

> >> indicate when it moves between MAGs that the new MAG should set the
HO
> Flag
> >> which will enable the LMA to assign the same address/prefix and
there
> is no

---

From: Julien Laganier <[email-masked]>
Date: Thu, 19 Jun 2008 12:57:04 +0200

Hello Gerardo,

Some thoughts from my side below:

On Thursday 19 June 2008, Giaretta, Gerardo wrote:
> non-involvement of the client in mobility signaling should always
> hold true."
>
> Then I am a bit confused by the classification made by Sri. As soon
> as we extend SEND or ND or any other MN-MAG protocol for multihoming
> or inter-tech HO support with NETLMM, we are making the MN aware of
> the mobility and the mobility protocol. Those changes would be
> introduced only because of mobility and therefore must be seen as an
> involvement of the client in the mobility management signaling. I see
> a lot of contradictions in your classification and analysis below.

Our current charter makes that distinction: "While some mobile node 
involvement is necessary and expected for generic mobility functions
such as movement detection and to inform the access router about 
mobile node movement, no specific mobile node to network protocol will 
be required for localized mobility management itself."

I do see a difference between "generic mobility functions" on one hand, 
and "mobility management signaling" on the other side.

I think we should take "mobility management signaling" as the ability to 
inject routing entries in the routing fabric as a reaction to movements 
of a mobile node. Then "generic mobility functions" would be everything 
else related to mobility that does not involve modifying routing state 
in the routing fabric, e.g., finding out I changed link / access router 
(what the DNA protocol is supposed to do), finding out my interface is 
down because I left coverage area of the wireless access point (L2 link 
down notifications send to IP layer, DNA WG did something too in that 
space), and I'm sure we can find more...

> I think the correct way of seeing the point is the following: IETF
> has defined two mobility management protocols, one involving directly
> the host and requiring support from the host (MIP), and another for
> hosts who do not support any mobility management signaling (NETLMM).
> The question from Raj boils down to the following: should we extend
> NETLMM so that the host is involved in mobility management and
> support mobility management signaling?

I tend to agree Raj's question boil down to that question. But I 
actually disagree with Raj's characterization:

   The Netlmm charter (current) has expressly prohibited changes to the
   MN in the context of mobility management. This limitation should be
   removed from the revised charter. In order to enable inter-technology
   handovers or to support mutihoming capability or other enhancements
   now being suggested, it would be useful in the design process to have
   the ability to make enhancements to the MN as well.

To me our current charter allows us to make enhancements to the MN as 
long as those enhancements are not mobility management signalling. Thus 
it seems to me that we can, as per our current charter, add support for 
inter-tech hanodvers or multihoming as long as we do not require the MN 
to inject routing entries in the NETLMM fabric.

Cheers,

--julien

> > :
> > >>        .......      W.G should see the host stack changes
>
> objectively
>
> > >>  in mobility signaling should always hold true. That requirement
>
> should
>
> > >>  not be relaxed. The protocol that is on the table today is
>
> designed
>
> > >>  absolutely zero changes to the host stack. This includes even
> > >> the inter-technology handoff. There is some confusion that the
>
> requirement
>
> > >>  of virtual interface support on the host implies changes to the
>
> host
>
> > >>  stack. That is absolutely not true, Ryuji and me will
> > >> demonstrate
>
> this
>
> > >>  soon.
> > >>
> > >>  Now, w.r.t to the comment from Raj that we need allow changes
> > >> to
>
> host.
>
> > >>  These changes are minor optimizations. Examples of such
>
> optimizations
>
> > >>  include:
> > >>
> > >>  - The ability for the host and the access router to perform
>
> capability
>
> > >>    exchange
> > >>  - Prefix colouring, the ability for the host to distinguish
>
> between
>
> > >>  in the scope of the general IPv6 host stack improvements and in
>
> the
>
> > >>  context of NETLMM. W.G should see the host stack changes
>
> objectively
>

---

From: "Premec, Domagoj" <[email-masked]>
Date: Thu, 19 Jun 2008 13:04:12 +0200

Gerardo,

The proposed changes are backwards compatible with legacy hosts, so they would be "using" PMIP6 just as described by the PMIP6 draft. The primary intention of the hints in the RA is to let the MIP enabled host be aware of the PMIP service so it is able to make a conscious decision to use either the PMIP service or to perform its own mobility management. If the host doesn't implement those optional enhancements, then the default behaviour is as described in the PMIP6 draft. I don't think that giving the host an option to become aware of the network capabilities in terms of netlmm service is the same as re-inventing MIP.

domagoj

> [mailto:[email-masked]] On Behalf Of Giaretta, Gerardo
> Sent: 19. lipanj 2008 12:12
> To: Sri Gundavelli; Charles E. Perkins
> Cc: [email-masked]
> As Sri correctly stated, "The basic assumption of the NETLMM, 
> the non-involvement of the client in mobility signaling 
> should always hold true."
> 
> Then I am a bit confused by the classification made by Sri. 
> As soon as we extend SEND or ND or any other MN-MAG protocol 
> for multihoming or inter-tech HO support with NETLMM, we are 
> making the MN aware of the mobility and the mobility 
> protocol. Those changes would be introduced only because of 
> mobility and therefore must be seen as an involvement of the 
> client in the mobility management signaling. I see a lot of 
> I think the correct way of seeing the point is the following: 
> IETF has defined two mobility management protocols, one 
> involving directly the host and requiring support from the 
> host (MIP), and another for hosts who do not support any 
> mobility management signaling (NETLMM). The question from Raj 
> boils down to the following: should we extend NETLMM so that 
> the host is involved in mobility management and support 
> mobility management signaling?
> 
> If this is the case, wouldn't it mean we are re-inventing 
> MIP? If yes, what is wrong with the current version of MIP? 
> Which is the problem statement to change it or the 
> requirements not fulfilled by it?
> 
> Cheers
> Gerardo
> 
> 
> but then I 
> > > It seems to me that you have certain strong ways of classifying 
> > > which changes are legitimate, based on whether they affect the 
> > > client's "stack".  Can you be a bit more specific about 
> this?  How 
> > > can I tell whether something affects the "stack"?  Will all such 
> > > client signals be handled over some UDP, TCP, or SCTP port?
> > >
> > > Regarding:
> > >
> but then I

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Thu, 19 Jun 2008 05:33:19 -0700

Hi Domagoj,

I am missing a basic point in your problem statement here. The MN does
not need to be aware via RA or other explicit means if PMIPv6 is used.
The reason is that the MN will implicitly know that by the fact that the
HNP will be advertised in a given link. If the HNP is advertised, there
is no need for nay mobility action from the MN. This is how PMIPv6 works
and should work in the future in my view

Gerardo

> From: Premec, Domagoj [mailto:[email-masked]]
> Sent: Thursday, June 19, 2008 4:04 AM
> To: Giaretta, Gerardo; Sri Gundavelli; Charles E. Perkins
> Cc: [email-masked]
> Subject: RE: [netlmm] Scope of revised charter: MN impact
> 
> Gerardo,
> 
> The proposed changes are backwards compatible with legacy hosts, so
they
> would be "using" PMIP6 just as described by the PMIP6 draft. The
primary
> intention of the hints in the RA is to let the MIP enabled host be
aware
> of the PMIP service so it is able to make a conscious decision to use
> either the PMIP service or to perform its own mobility management. If
the
> host doesn't implement those optional enhancements, then the default
> behaviour is as described in the PMIP6 draft. I don't think that
giving
> the host an option to become aware of the network capabilities in
terms of
> netlmm service is the same as re-inventing MIP.
> 
> domagoj
> 
> 
to

---

From: "Premec, Domagoj" <[email-masked]>
Date: Thu, 19 Jun 2008 15:15:12 +0200

Hi Gerardo,

The MN can not tell if PMIP is used simply by looking at the assigned prefix. In one case the network can run the PMIP service for a prefix, in another case the MN could be attached to its real home link and there would be no PMIP service behind the home prefix. The MN can not differentiate between those two cases. The LMA and MAG may be far away from each other and so the MAG-LMA tunnel overhead in terms of delay may be significant. In this case the MIP enabled MN may prefer to do its own MIP managemet and make use of the route optimization or use CoA for short lived sessions.  (on a sidenote, MAG and LMA can be in different administrative domains and the word "localized" in the netlmm name is misleading as it does not reflect any more the intended usage of the protocol)

Another point why the MN needs to be aware that it is in a netlmm domain is inter-access handover. I believe that inter-access handover needs assistance from the MN, and the MN can provide such assistance only if it is aware that it is in a netlmm domain.

domagoj

> From: Giaretta, Gerardo [mailto:[email-masked]] 
> Sent: 19. lipanj 2008 14:33
> To: Premec, Domagoj; Sri Gundavelli; Charles E. Perkins
> Cc: [email-masked]
> I am missing a basic point in your problem statement here. 
> The MN does not need to be aware via RA or other explicit 
> means if PMIPv6 is used.
> The reason is that the MN will implicitly know that by the 
> fact that the HNP will be advertised in a given link. If the 
> HNP is advertised, there is no need for nay mobility action 
> from the MN. This is how PMIPv6 works and should work in the 
> future in my view
> 
> Gerardo
> 
> > > As soon as we extend SEND or ND or any other MN-MAG protocol for 
> > > multihoming or inter-tech HO support with NETLMM, we are 
> making the 
> > > MN aware of the mobility and the mobility protocol. Those changes 
> > > would be introduced only because of mobility and 
> therefore must be 
> > > seen as an involvement of the client in the mobility management 
> > > signaling. I see a lot of contradictions in your 
> classification and 
> > > analysis below.
> > >
> > > IETF has defined two mobility management protocols, one involving 
> > > directly the host and requiring support from the host (MIP), and 
> > > another for hosts who do not support any mobility management 
> > > signaling (NETLMM). The question from Raj boils down to the 
> > > following: should we extend NETLMM so that the host is 
> involved in 
> > > mobility management and support mobility management signaling?
> > >
> > > If this is the case, wouldn't it mean we are re-inventing MIP? If 
> > > yes, what is wrong with the current version of MIP?
> [mailto:[email-masked]] On
> > > Behalf
> > > > Of Sri Gundavelli
> management 
> classifying

---

From: Julien Laganier <[email-masked]>
Date: Thu, 19 Jun 2008 15:19:56 +0200

On Thursday 19 June 2008, Giaretta, Gerardo wrote:
> Hi Domagoj,
>
> I am missing a basic point in your problem statement here. The MN
> does not need to be aware via RA or other explicit means if PMIPv6 is
> used. The reason is that the MN will implicitly know that by the fact
> that the HNP will be advertised in a given link. If the HNP is
> advertised, there is no need for nay mobility action from the MN.
> This is how PMIPv6 works and should work in the future in my view

FWIW - I agree with Gerardo here.

--julien

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Thu, 19 Jun 2008 06:24:35 -0700

Hi Domagoj,

> Sent: Thursday, June 19, 2008 6:15 AM
> The MN can not tell if PMIP is used simply by looking at the assigned
> prefix. In one case the network can run the PMIP service for a prefix,
in
> another case the MN could be attached to its real home link and there
> would be no PMIP service behind the home prefix. The MN can not
> differentiate between those two cases. 

Correct, but why the MN should be aware of the difference? The MN is
just interested in having a valid IP address for sending and receiving
packets. That's all the MN needs to know and this can be done looking at
the prefixes. I think PMIPv6 was defined exactly to make the MN unaware
of the actual MN movement. This is explicitly mentioned in the charter
and in  

> The LMA and MAG may be far away
> from each other and so the MAG-LMA tunnel overhead in terms of delay
may
> be significant. In this case the MIP enabled MN may prefer to do its
own
> MIP managemet and make use of the route optimization or use CoA for
short
> lived sessions. 

If PMIPv6 is used the MN will not have any change to have a CoA
assigned. 

I think what you are referring to is the capability for the UE to select
between PMIPv6 and DSMIPv6. Isn't that?  

> (on a sidenote, MAG and LMA can be in different
> administrative domains and the word "localized" in the netlmm name is
> misleading as it does not reflect any more the intended usage of the
> protocol)
> 

The word is correct, it is the applicability of PMIPv6 to that scenario
which is misleading :-)

(wait wait guys...I'm kidding here, don't want to re-open that
discussion!)

Gerardo

> Another point why the MN needs to be aware that it is in a netlmm
domain
> is inter-access handover. I believe that inter-access handover needs
> assistance from the MN, and the MN can provide such assistance only if
it
> is aware that it is in a netlmm domain.
> 
> 
> domagoj
> 
> 
> 
the
> > > > IETF has defined two mobility management protocols, one
involving
> > > > > >>  of virtual interface support on the host implies changes
to
> > > > > >>  in the scope of the general IPv6 host stack improvements
and
> > in

---

From: "Premec, Domagoj" <[email-masked]>
Date: Thu, 19 Jun 2008 15:46:52 +0200

Gerardo,

> Correct, but why the MN should be aware of the difference? 

well.. as I said, I  believe it is needed for inter-access handover. It also makes sense if the MN is MIP enabled and if the network is offering both regular IP service (local prefix) and the PMIP service. In this case the MN may prefer the regular IP service and do route optimization on top of it which should give it better perfomance in terms of packet delay.

> I think what you are referring to is the capability for the 
> UE to select between PMIPv6 and DSMIPv6. Isn't that?  

Yes, that's correct (assuming MN is authorized for both services). In addition, a hint about the netlmm service availability is necessary for inter-access handover even in the case of non-MIP enabled MN.

domagoj

> Sent: 19. lipanj 2008 15:25
> Correct, but why the MN should be aware of the difference? 
> The MN is just interested in having a valid IP address for 
> sending and receiving packets. That's all the MN needs to 
> know and this can be done looking at the prefixes. I think 
> PMIPv6 was defined exactly to make the MN unaware of the 
> actual MN movement. This is explicitly mentioned in the 
> charter and in  
> 
> If PMIPv6 is used the MN will not have any change to have a 
> CoA assigned. 
> 
> I think what you are referring to is the capability for the 
> UE to select between PMIPv6 and DSMIPv6. Isn't that?  
> 
> administrative domains 
> > and the word "localized" in the netlmm name is misleading 
> as it does 
> > not reflect any more the intended usage of the
> > protocol)
> > 
> 
> The word is correct, it is the applicability of PMIPv6 to 
> that scenario which is misleading :-)
> 
> means if 
> > > PMIPv6 is used.
> > > The reason is that the MN will implicitly know that by 
> the fact that 
> > > the HNP will be advertised in a given link. If the HNP is 
> > > > > > >>  None of this can be equated to a client stack 
> requirement.
> > > These
> > > > > fall

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Thu, 19 Jun 2008 06:53:38 -0700

I would claim that if a MN supports MIP, a local IP address should
always be assigned. I think the point is if we will be chartered to
discuss a deployment where both PMIP and MIP are possible in a network
architecture. 3GPP has already solved this issue in EPS/SAE, so there is
not any dependency from 3GPP on this.

Both items you have listed (and I have some slightly different opinions
but let's not go there for now) are not in list of the items already
agreed for the new charter. So I think we should not discuss in general
if the MN can signal or not as such; we should pick the last charter
item and if that requires any MN signaling, then we will discuss it

Gerardo 

> Sent: Thursday, June 19, 2008 6:47 AM
> well.. as I said, I  believe it is needed for inter-access handover.
It
> also makes sense if the MN is MIP enabled and if the network is
offering
> both regular IP service (local prefix) and the PMIP service. In this
case
> the MN may prefer the regular IP service and do route optimization on
top
> of it which should give it better perfomance in terms of packet delay.
> 
> Yes, that's correct (assuming MN is authorized for both services). In
> addition, a hint about the netlmm service availability is necessary
for
> inter-access handover even in the case of non-MIP enabled MN.
> 
> domagoj
> 
> 
> 
> > > > > The proposed changes are backwards compatible with legacy
hosts,
> > so
MIP?
> > If
> > > > > > > >> absolutely zero changes to the host stack. This
includes
> > > > > > even the

---

From: "Premec, Domagoj" <[email-masked]>
Date: Thu, 19 Jun 2008 16:03:48 +0200

Gerardo,

> I think the point is if we will be 
> chartered to discuss a deployment where both PMIP and MIP are 
> possible in a network architecture.

the latest PMIP draft already allows for such a mixed mode deployment in section 6.14.

domagoj

> Sent: 19. lipanj 2008 15:54
> I would claim that if a MN supports MIP, a local IP address 
> should always be assigned. I think the point is if we will be 
> chartered to discuss a deployment where both PMIP and MIP are 
> possible in a network architecture. 3GPP has already solved 
> this issue in EPS/SAE, so there is not any dependency from 
> 3GPP on this.
> 
> Both items you have listed (and I have some slightly 
> different opinions but let's not go there for now) are not in 
> list of the items already agreed for the new charter. So I 
> think we should not discuss in general if the MN can signal 
> or not as such; we should pick the last charter item and if 
> that requires any MN signaling, then we will discuss it
> 
> Gerardo 
> 
> > > I think what you are referring to is the capability for the UE to 
> > > select between PMIPv6 and DSMIPv6. Isn't that?
> > 
> > > The MN is just interested in having a valid IP address 
> for sending 
> > > and receiving packets. That's all the MN needs to know 
> and this can 
> > > be done looking at the prefixes. I think
> actual MN 
> > > movement. This is explicitly mentioned in the charter and in
> > >
> > > I think what you are referring to is the capability for the UE to 
> > > select between PMIPv6 and DSMIPv6. Isn't that?
> > >
> > > The word is correct, it is the applicability of PMIPv6 to that 
> > > scenario which is misleading :-)
> > >

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 20 Jun 2008 00:06:30 +1000

> FWIW - I agree with Gerardo here.

=> +1

Hesham

---

From: Hesham Soliman <[email-masked]>
Date: Fri, 20 Jun 2008 00:17:24 +1000

Hi Charlie, Sri,

> rule and charter mandate.

=> That's probably one of the most useful comments so far. There is a lot of
blindness in the definitions of "network control"...etc but I hope it's not
too late to collectively understand these concepts. We had one blind rule
before to not "involve the mobile node". Now it seems some want to change
that rule due to the predictable/predicted problems with multihoming. An
outside objective observer would find this U-turn a bit strange IMHO.

>> in mobility signaling should always hold true.

=> Actually, the basic assumption was no signalling from the mobile at all.

Hesham

---

From: Julien Laganier <[email-masked]>
Date: Thu, 19 Jun 2008 16:43:33 +0200

Hi Hesham,

On Thursday 19 June 2008, Hesham Soliman wrote:
> >> client in mobility signaling should always hold true.
>

I disagree with this statement. Our charter says "While some mobile node 

--julien

---

From: Basavaraj Patil <[email-masked]>
Date: Thu, 19 Jun 2008 11:13:59 -0500

Hi Gerardo,

On 6/19/08 8:24 AM, "Giaretta Gerardo" <[email-masked]> wrote:

---snip---

> between PMIPv6 and DSMIPv6. Isn't that?

The point being made is that when the MN receives an RA with multiple PIOs,
it would be useful to know if a prefix is anchored locally (AR) or elsewhere
(LMA). I agree that from the perspective of the MNs operation and ability to
obtain a prefix/address it does not matter. But it does help an MN in
choosing a prefix based on its own capability and preference as an example.

-Raj