Subject: Re: [Mipshop] Proposed new charter

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 19 Mar 2008 05:48:31 -0700 (PDT)

Hi Ahmad,
  Comments inline.

Regards,

Behcet
----- Original Message ----
From: Ahmad Muhanna <[email-masked]>
To: Vijay Devarapalli <[email-masked]>
Cc: Mipshop <[email-masked]>
Sent: Wednesday, March 19, 2008 6:08:15 AM
Subject: Re: [Mipshop] Proposed new charter

Hi Vijay,

I am not against addressing PMIPv6 handover optimization per say in
MIPSHOP, however, I do not like the proposed solution using FMIPv6. IMO,
that is too restrictive, limited to a very specific deployment, and
couples CT with Handover optimization solution which IMO, not a good
idea. Again, I believe that handover optimization SHOULD be independent
of CT mechanism.

[behcet]
I don't understand this and qualify it rhetorical. If you need to transfer context which is only needed for handover, should we do it separately?
Why is it too restrictive? There are certain SDO implications and one method appeals to one SDO and the next to the other SDO.

Having said this, I believe that, although the other proposals,
transient registration, etc.  are categorized under handover
optimization but they still considered as an enhancement to PMIPv6
registration, introduces new options, and update the PMIPv6 BCE. I
strongly believe that a mechanism like transient registration belongs to
Netlmm wg. Additionally, this work item needs to be considered as part
of the current Netlmm priorities. 

[behcet]
This will amount to developing multiple solutions for HO optimizations. Is this what we want? PMIP6 HO for SDO X in WG X
PMIP6 HO for SDO Y in WG Y
or whatever?

snipped the rest.

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

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Wed, 19 Mar 2008 08:11:13 -0500

Hi Behcet,
Please see comments inline.

Regards, 
Ahmad
________________________________
	Subject: Re: [Mipshop] Proposed new charter

	Hi Ahmad,
	  Comments inline.
	
	Regards,
	
	Behcet
	
	----- Original Message ----
	From: Ahmad Muhanna <[email-masked]>
	To: Vijay Devarapalli <[email-masked]>
	Cc: Mipshop <[email-masked]>
	Sent: Wednesday, March 19, 2008 6:08:15 AM
	Subject: Re: [Mipshop] Proposed new charter
	
	Hi Vijay,
	
	I am not against addressing PMIPv6 handover optimization per say
in
	MIPSHOP, however, I do not like the proposed solution using
FMIPv6. IMO,
	that is too restrictive, limited to a very specific deployment,
and
	couples CT with Handover optimization solution which IMO, not a
good
	idea. Again, I believe that handover optimization SHOULD be
independent
	of CT mechanism.
	
	[behcet]
	I don't understand this and qualify it rhetorical. If you need
to transfer context which is only needed for handover, should we do it
separately?

[Ahmad]
I would suggest that we stay away from passing judgments on each others
technical opinions. That is not good for a healthy technical discussion
and a very slippery slope:)

	Why is it too restrictive? There are certain SDO implications
and one method appeals to one SDO and the next to the other SDO.

[Ahmad]
If the proposed solution is addressing the need of a specific SDO, let
us call it as such. As you just said, it is not necessarily appealing to
other SDOs:) That why an informational RFC is for!

	Having said this, I believe that, although the other proposals,
	transient registration, etc.  are categorized under handover
	optimization but they still considered as an enhancement to
PMIPv6
	registration, introduces new options, and update the PMIPv6 BCE.
I
	strongly believe that a mechanism like transient registration
belongs to
	Netlmm wg. Additionally, this work item needs to be considered
as part
	of the current Netlmm priorities. 
	
	[behcet]
	This will amount to developing multiple solutions for HO
optimizations. Is this what we want? PMIP6 HO for SDO X in WG X
	PMIP6 HO for SDO Y in WG Y
	or whatever?

[Ahmad]
I look at differently. On one hand, some people are trying to address
handover optimization at the access side while keeping the common end of
both tunnels (LMA) blind of what is going on. Another mechanism uses a
more logical and reasonable solution by addressing the handover
mechanism at the common end which is responsible for switching the
tunnels. Not only that but it also keeps the common end informed of what
is going on with the MN movements which could be used in making some
intelligent decisions! 

	snipped the rest.