Subject: FW: [netlmm] draft-giaretta-netlmm-mip-interactions

From: "Hesham Soliman" <[email-masked]>
Date: Fri, 27 Apr 2007 13:37:18 +1000

Sorry, forgot to cc the list 

-----Original Message-----
From: Hesham Soliman [mailto:[email-masked]] 
Sent: Friday, April 27, 2007 1:19 PM
To: [email-masked]'
Subject: RE: [netlmm] draft-giaretta-netlmm-mip-interactions

Hi John,  

	         Basically, we can assume that the MN is a easy terminal and
we put all of the logic need to   		do for PMIP in network side.
But there is some disadvantages and problems existed in this
situation.

	1)       If a network provide the PMIPv6 support and MIPv6 support
simultaneously , and the MN also 	provide both of them, then which one
will be choice to support? This is belong to the interaction 	scope, so if
we didn't discuss it in this draft, then where is more perfect? At lease it
is not a 	solution issue. If it depend a solution to resolve, then how
can guarantee the compatible  between 	difference vendors based on the same
PMIP protocol?

=> The premise of your statement is what I want to avoid. In the scenario I
had in mind there is no such thing as "MN supports PMIP". PMIP would be a
transparent technology. If a MN appears in a network that supports PMIP then
it gets a CoA,if it supports MIPv6 it updates the HA with the CoA and that's
the end. If the MN doesn't support MIPv6 then it gets an address and it
doesn't need to know anything else. 
The idea of informing the MN is only an issue when you want to choose
whether MIPv6 or PMIP should be supported on a per-MN basis. I'm saying we
should avoid this scenario altogether and assume that PMIP is the default
when it's present. I can't believe I'm saying that :) 
But this is the easiest way to go. I'm not a fan of PMIP or NETLMM as
everyone knows, but if it has to be there, then the hierarchical model (in
the draft) is the only one that makes sense to me and it doesn't cause
interoperability issues.  

	2)       If maybe we didn't need to inform the MN that PMIP is used
in the network, but the network 	need to confirm which kind of mobile
management is the choose of MN. Only based on profile , that is 	not
enough. Because, we can't imagine that a MN change its profile everytime
when it roam to a new 	network with a difference mobile management . 

=> Correct. The profile part is a recipe for unpredictable behaviour because
a profile depends on the device and the SW capabilities of that device are
not a good way for an AR/AAA server to track what mobility management should
be done. 

Hesham

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

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 26 Apr 2007 21:25:03 -0700

<WG chair hat off>

I agree with Hesham here.  Supporting PMIP selectively is added
complexity for networks and as Hesham points out, it doesn't really mean
anything to say a host supports "PMIP"; the point of PMIP is to be
transparent to the host.  Of course, even beyond this, an operator may
choose to have such selective behavior if they want to indicate host
capabilities to the network elements, but, it is not clear that
operators want such complexity.  I further agree that tracking such host
capabilities are not desirable in reality.  

Vidya

> Sent: Thursday, April 26, 2007 8:37 PM
> To: [email-masked]
> Subject: FW: [netlmm] draft-giaretta-netlmm-mip-interactions
> 
> => The premise of your statement is what I want to avoid. In 
> the scenario I had in mind there is no such thing as "MN 
> supports PMIP". PMIP would be a transparent technology. If a 
> MN appears in a network that supports PMIP then it gets a 
> CoA,if it supports MIPv6 it updates the HA with the CoA and 
> that's the end. If the MN doesn't support MIPv6 then it gets 
> an address and it doesn't need to know anything else. 
> The idea of informing the MN is only an issue when you want 
> to choose whether MIPv6 or PMIP should be supported on a 
> per-MN basis. I'm saying we should avoid this scenario 
> altogether and assume that PMIP is the default when it's 
> present. I can't believe I'm saying that :) But this is the 
> easiest way to go. I'm not a fan of PMIP or NETLMM as 
> everyone knows, but if it has to be there, then the 
> hierarchical model (in the draft) is the only one that makes 
> sense to me and it doesn't cause interoperability issues.  
> 
>

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 26 Apr 2007 21:53:50 -0700

-----Original Message-----
From: Narayanan, Vidya [mailto:[email-masked]] 
Sent: Thursday, April 26, 2007 9:25 PM
To: Hesham Soliman; [email-masked]
Subject: RE: [netlmm] draft-giaretta-netlmm-mip-interactions

<WG chair hat off>

:) Another way to put it, instead of saying PMIP capable,
host-based mobility capable or incapable. Off course the
host will always support PMIP, because it does not have
to do anything.
   
If the network can learn the terminal's capabilities, there
is better control on the services it can offer. I do see
Vijay's and your comment, that it can be solved for specific
architectures. But, the generic capability exchange, the
MAG notifying the terminal that its offering PMIP service
and the terminal notifying the network that it has MIP stack,
might be useful. Where and when to solve, I've no strong 
opinion ...may be its specific to deployed architectures ...

Sri