Subject: Re: [Mipshop] Proposed new charter

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 19 Mar 2008 07:01:16 -0700 (PDT)

Hi Ahmad,
  Please see inline.

Regards,

Behcet

----- Original Message ----
From: Ahmad Muhanna <[email-masked]>
To: Behcet Sarikaya <[email-masked]>
Cc: Mipshop <[email-masked]>
Sent: Wednesday, March 19, 2008 8:11:13 AM
Subject: RE: [Mipshop] Proposed new charter

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!

[behcet]
Based on your argumentation, both of them qualify for informational RFCs.
However, I said "appeals" not "addresses the need of a specific SDO". My statement was based on previous statement from the chair. In fact when we submitted our draft we had yet another SDO in mind. So maybe we can say FMIP6 based approach "appeals" to more than one SDO. Bear in mind that this is pure speculation .
    
    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! 

[behcet] CT is based on what is already available in FMIP (Hi/Hack), no need to reinvent the wheel (see Rajeev's mail).  Keeping the common end informed can also be done with whatever is already available (PBU/PBack) in PMIP6 and MAG is the right place to do it.
    
    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 10:14:06 -0500

Hi Behcet, 
 
Inline.

Regards, 
Ahmad 	    

	[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!
	
	[behcet]
	Based on your argumentation, both of them qualify for
informational RFCs.
	However, I said "appeals" not "addresses the need of a specific
SDO". My statement was based on previous statement from the chair. In
fact when we submitted our draft we had yet another SDO in mind. So
maybe we can say FMIP6 based approach "appeals" to more than one SDO.
Bear in mind that this is pure speculation.

[Ahmad-start-1]
I am not sure there is a difference here between "Appeals" and
"addresses the need". But I classify this as hair splitting!

Anyhow, I believe there is a difference between the two approaches.
One approach enhances PMIPv6 registration to communicate some
information about the mobile node movement to the LMA. This approach
updates the PMIPv6 signaling and BCE processing and can be used by the
LMA for making decisions to enable smooth tunnel switching or other
decisions as needed. On the other hand, all those SDO specifics
procedures, like Context Transfer, forwarding the traffic to the MN
current location are all kept out of scope. WHY? Because they are SDOs
specific and every SDO may choose a different mechanism. 

The other approach is actually trying to standardize what I categorizes
as SDOs specific, it tries to propose a mechanism for setting up a
lateral bidirectional tunnel between ARs and try to propose a Context
Transfer mechanism. The main point here is that these mechanisms are not
specific to PMIPv6. I would like to repeat one more time, these are not
specific to PMIPv6 and consequently the proposed mechanisms can be used
if PMIPv4 is deployed, for example.

[Ahmad-end-1]	    
	
	[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! 
	
	[behcet] CT is based on what is already available in FMIP
(Hi/Hack), no need to reinvent the wheel (see Rajeev's mail).  Keeping
the common end informed can also be done with whatever is already
available (PBU/PBack) in PMIP6 and MAG is the right place to do it.

[Ahmad-start-2]
I am not sure I understand what you are trying to say here, but please
see the above comment.

[Ahmad-end-2]

---

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

Raj,

Inline.

Regards,
Ahmad

> Ahmad,
> I think this discussion is going nowhere.
> Can you please send a writeup of the problem statement to the 
> list that you believe exists?
> We can look at different solutions and how they address the problem.
> 
> At this time all you are saying is the I-D that is being 
> discussed in MIPSHOP does not solve the problem. 

[Ahmad]
May be I am missing something, Where did I say that?

> I guess it 
> would be good to understand what is the specific problem.
> 
> -Raj
> 
> 
> On 3/19/08 10:14 AM, "ext Ahmad Muhanna" <[email-masked]> wrote:
> 
> > Hi Behcet,
> >  
> > Inline.
> > 
> > Regards, 
> > Ahmad      
> > 
> > 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]
> appealing 
> > to other SDOs:) That why an informational RFC is for!
> > 
> > [behcet]
> > However, I said "appeals" not "addresses the need of a 
> specific SDO". 
> > My statement was based on previous statement from the 
> chair. In fact 
> > when we submitted our draft we had yet another SDO in mind. 
> So maybe 
> > we can say FMIP6 based approach "appeals" to more than one SDO.
> > The other approach is actually trying to standardize what I 
> > categorizes as SDOs specific, it tries to propose a mechanism for 
> > setting up a lateral bidirectional tunnel between ARs and try to 
> > propose a Context Transfer mechanism. The main point here is that 
> > these mechanisms are not specific to PMIPv6. I would like to repeat 
> > one more time, these are not specific to PMIPv6 and 
> consequently the 
> > proposed mechanisms can be used if PMIPv4 is deployed, for example.
> > 
> > [Ahmad-end-1]    
> > 
> > [Ahmad]
> 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 
> > 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!
> > 
> (Hi/Hack), 
> > no need to reinvent the wheel (see Rajeev's mail).  Keeping 
> the common 
> > end informed can also be done with whatever is already available 
> > (PBU/PBack) in PMIP6 and MAG is the right place to do it.
> > 
> > [Ahmad-start-2]