Subject: Re: [Mipshop] Proposed new charter

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 19 Mar 2008 09:03:41 -0700 (PDT)

Hi Ahmad,
  Comments inline.

Behcet

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

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]
    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]        
    
[behcet to Ahmad-1]
Well, SDO specific procedures can be adopted when the SDO adopts the protocol. I believe in both cases there will be need for adoptations, let's leave that to the specific SDO to handle.

Regarding not being applicable to PMIPv4, I don't think so because the messages are defined as IPv6 messages not IPv4. For PMIPv4, there is FMIPv4 and we probably need a different draft to deal with PMIPv4 handover.
[end] 
    [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]            
        
 [behcet to Ahmad-2]
I think the question Vijay asked was if the scope should be widened to the type of approaches you mentioned above in Ahmad-1, so I take your view that you are in support of this?

[]

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

---

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

Sorry Behcet, but this is my last email exchange on this topic.

Firstly, I can not follow you replies because of the email format you
are using which is the least to be said is confusing.

Secondly, please see inline.

Regards, 
Ahmad

________________________________

	[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]            
	        
	 [behcet to Ahmad-2]
	I think the question Vijay asked was if the scope should be
widened to the type of approaches you mentioned above in Ahmad-1, so I
take your view that you are in support of this?
	
[Ahmad-last-start]
It is very interesting!
 
Earlier you suggested for us to forget about the other solutions
proposed on netlmm wg and let us focus on the FMIPv6 for PMIPv6 handover
as the only solution for PMIPv6 handover. Later on, you admitted that
FMIPv6 solution is very speciifc in nature and supported the proposal of
widening the scope to include all other netlmm proposal to be addressed
under MIPSHOP! Now, you interpreting my views according to something
that I am not aware of.

Could you please focus on the technical discussion and let people speaks
for themselves.

Many thanks for your consideration.

Best Regards,
Ahmad	 

[Ahmad-last-end]