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

From: "John.zhao" <[email-masked]>
Date: Fri, 27 Apr 2007 15:17:09 +0800

Hi, vidya

         How do you think about the scenarioB in this draft?

     The transparent is what we want to do. But complexity scenario make it
not be done easily. So just as that draft has mentioned in the second
paragraph in page13 as the following:

                   "Based on the considerations in this section, there is
therefore a clear need to define some mechanisms in order to manage the
co-existence of nodes that use Mobile IPv6 and nodes that rely on Proxy
Mobile IPv6."

         Right? If you think it right, then I think we have get a agreement
that need a mechanism.

         In another side, some SDO utilize the PMIP protocol, why we need
them to develop many difference method to do the general progress?

         If you ask for the reality applicable scenario, then wimax, wlan,
3gpp2 will all become the candidate. We didn't resolve this problem. Push it
to them. That is ok. That means we want to utilize the link-layer method to
do so, right? Otherwise, why we didn't handle it in layer-3 that is the
scope of IETF. If thus, maybe a new egg-chichen problem occurred.

         My two cents.

         Best Rgds,

Thanks,

John.zhao

<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

> -----Original Message-----

> From: Hesham Soliman [ <mailto:[email-masked]>
mailto:[email-masked]] 

> Sent: Thursday, April 26, 2007 8:37 PM

> To: [email-masked]

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

> Sorry, forgot to cc the list 

> -----Original Message-----

> From: Hesham Soliman [ <mailto:[email-masked]>
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>
https://www1.ietf.org/mailman/listinfo/netlmm

 

------------------------------

_______________________________________________

netlmm mailing list

[email-masked]

 <https://www1.ietf.org/mailman/listinfo/netlmm>
https://www1.ietf.org/mailman/listinfo/netlmm

End of netlmm Digest, Vol 13, Issue 57

**************************************

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