Subject: Re: [netlmm] Scope of revised charter: MN impact

From: "Mohana Jeyatharan" <[email-masked]>
Date: Fri, 20 Jun 2008 17:41:06 +0800

Hi Gerardo,

Thanks for the reply.

Pls see reply in line. 

> -----Original Message-----
> From: Giaretta, Gerardo [mailto:[email-masked]] 
> Sent: Friday, June 20, 2008 4:59 PM
> To: Mohana Jeyatharan; Sri Gundavelli; Charles E. Perkins
> Cc: [email-masked]
> Subject: RE: [netlmm] Scope of revised charter: MN impact
> 
> Hi Mohana,
> 
> Thanks for the detailed explanation, but I am still missing something.
> 
> > -----Original Message-----
> > From: Mohana Jeyatharan [mailto:[email-masked]]
> > Sent: Thursday, June 19, 2008 5:56 PM
> > To: Giaretta, Gerardo; Sri Gundavelli; Charles E. Perkins
> > Cc: [email-masked]
> > Subject: RE: [netlmm] Scope of revised charter: MN impact
> > 
> > Hi Gerardo,
> > 
> > Some thoughts regarding your division as to whether it 
> should be PMIP
> or
> > CMIP.
> > 
> > Changing MN to be aware of PMIP and making some small MN involvement
> in
> > the air
> > interface to enable better inter access technology handovers, 
> > multihoming, route optimization and so on, does not really 
> mean we are 
> > re-inviting MIP.
> > 
> >  As to the debate into PMIP vs CMIP, this debate has been 
> done years 
> > ago, let's not restart it.  The consensus has always been CMIP and
> PMIP
> > are solving different problems, they are orthogonal and can be
> deployed
> > one besides the other (already 3GPP is doing that as you 
> have pointed 
> > out in one of your mails).  It has never been one or the other.
> Classic
> > case is HMIP and CMIP. HMIP/PMIP is mainly a local mobility 
> management 
> > mechansim. If you roam to foreign domain then it definitely 
> needs both 
> > operations (this you have highlighted in PMIP/CMIP 
> interaction draft 
> > scenario A). Unless one is talking about the 3GPP home routed case
> where
> > one see the home prefix all along(purely PMIP).
> > 
> > The current PMIP charter is that MN should not be involved 
> in mobility 
> > management signaling. For nodes that are legacy(IPv6) it works fine
> and
> > it can achieve mobility management without implementing MIP 
> stack. For 
> > nodes that have MIP then it eliminates the burden of 
> constant mobility 
> > management signaling. But, however "MN is not performing mobility 
> > management" is different from "MN is not involved in mobility
> management
> > or Mn performing some minor optimizations". As long as MN is not 
> > performing BU etc, and is not maintaining any state relevant to its 
> > mobility, it can be said as MN is not performing mobility 
> management.
> > 
> 
> But this does not make sense. If the MN includes information 
> for mobility related events (inter-tech handover, multihoming 
> after movements), it is involved in the mobility management 
> procedures. It does not make any difference if it is a AR 
> extension or a BU. So, probably you are not re-inventing MIP, 
> just adding the FA capability in MIPv6? 
> As Charlie mentioned, if the BU is sent to the AR/FA as in 
> MIPv4 than you achieve what you want :-)

[Mohana] The current charter says that MN should not be involved in
mobility management signaling.
It does not restrict the MN from participating in some support
signaling.
I am not sure why you categorize inter-tech handover optimization
signaling, or multihoming
Related signaling in PMIP to mobility management signaling. I think
mobility
Management signaling is mainly to create routing state. Please correct
me if I am wrong.
Also, having some infrequent AR interaction is very different to
updating your location
at an HA (this is mobility management signaling).

> Basically, I am still missing the problem statement. I think 
> you should come up with one clear problem statement and an 
> analysis of which requirements the current IETF protocols do 
> not solve. There was a problem statement for PMIP: mobility 
> for unmodified host. Please clarify the issues you want to 
> solve. Saying we want PMIP to better work with inter tech HO 
> with MN modifications is not a valid PS, imo.
> 

[Mohana] I am not sure why you are not satisfied with the problem
statement.
We are not changing the charter goal. Definitely there is no
modifciation to unmodified host
and MN in PMIP is not involved in mobility management signaling.
All what we are saying is that for hosts that want some better services
in PMIP
should be able to perform some signaling to the network to achieve this.
This is not
Mobility management signaling and thus I don't see why it breaks the
charter goals.

BR,
Mohana
> Gerardo
> 
> > What we are saying (same as many others in the mailing 
> list), changing 
> > MN to perform some support signaling in PMIP is not exactly 
> reinviting 
> > MIP. MIP is only a mobility management protocol. There needs to be
> some
> > mechansims to solve issues when MN is operating in the PMIP mode or
> the
> > 3GPP has decided to only provide PMIp services. Ofcourse, such
> signaling
> > should not be high and it will not be high bcos, mobility managemnt 
> > injects higher signaling load into the network when 
> compared to some 
> > minor non-frequent MN support signaling.
> > 
> > If you say that to achieve better interaccess technolgy hand-off, 
> > multihoming, route optimization and so on one needs to completely
> switch
> > to MIP, then I would like to point out that (1) we may 
> loose the nice 
> > features of local mobility management as in PMIP(also HMIP) (2) you
> may
> > not be able to switch to CMIP as you please. IN TS 23.402 in section
> 4,
> > there is a static configuration of mobility management protocol that
> can
> > be used for a certain access type. In that case, if you have to use 
> > PMIP, then how is an advanced UE that wants to have 
> seamless handoff 
> > optimization, advanced multihoming ....achieve all this. 
> Definitely it 
> > needs to operate in PMIP mode and perform some mechanisms to enable 
> > this. Such mechanisms will not be like Mn perfoming mobility
> management
> > signaling(ie. Location updates).
> > 
> > This is how we feel.
> > 
> > BR,
> > Mohana
> > 
> > 
> > 
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]] On Behalf Of Giaretta, Gerardo
> > > Sent: Thursday, June 19, 2008 6:12 PM
> > > To: Sri Gundavelli; Charles E. Perkins
> > > Cc: [email-masked]
> > > Subject: Re: [netlmm] Scope of revised charter: MN impact
> > >
> > > Hi Sri, Charlie, all,
> > >
> > > As Sri correctly stated, "The basic assumption of the NETLMM, the 
> > > non-involvement of the client in mobility signaling should always 
> > > hold true."
> > >
> > > Then I am a bit confused by the classification made by Sri.
> > > As soon as we extend SEND or ND or any other MN-MAG protocol for 
> > > multihoming or inter-tech HO support with NETLMM, we are 
> making the 
> > > MN aware of the mobility and the mobility protocol. Those changes 
> > > would be introduced only because of mobility and 
> therefore must be 
> > > seen as an involvement of the client in the mobility management 
> > > signaling. I see a lot of contradictions in your 
> classification and 
> > > analysis below.
> > >
> > > I think the correct way of seeing the point is the following:
> > > IETF has defined two mobility management protocols, one involving 
> > > directly the host and requiring support from the host (MIP), and 
> > > another for hosts who do not support any mobility management 
> > > signaling (NETLMM). The question from Raj boils down to the 
> > > following: should we extend NETLMM so that the host is 
> involved in 
> > > mobility management and support mobility management signaling?
> > >
> > > If this is the case, wouldn't it mean we are re-inventing MIP? If 
> > > yes, what is wrong with the current version of MIP?
> > > Which is the problem statement to change it or the 
> requirements not 
> > > fulfilled by it?
> > >
> > > Cheers
> > > Gerardo
> > >
> > >
> > > > -----Original Message-----
> > > > From: [email-masked] 
> [mailto:[email-masked]] On
> > > Behalf
> > > > Of Sri Gundavelli
> > > > Sent: Tuesday, June 17, 2008 3:27 PM
> > > > To: Charles E. Perkins
> > > > Cc: [email-masked]
> > > > Subject: Re: [netlmm] Scope of revised charter: MN impact
> > > >
> > > > Hi Charlie,
> > > >
> > > > The broad goal is not to involve the client in mobility 
> management 
> > > > signaling. The examples cited here all confirm to this
> > > goal. Providing
> > > > certain hints, to the client either in the form of RA's 
> or through 
> > > > other mechanisms only to improve either the clients ability
> > > to make a
> > > > better decision or for the network to understand the
> > > clients intent,
> > > > are just optimizations. This cannot be a difficult or a
> > > controversial
> > > > decision. We all can differentiate between a an
> > > optimization vs what
> > > > is a client equivalent functional addition to the host.
> > > >
> > > > >
> > > > > I was going to ask how many blind rules we should have,
> > > but then I
> > > > > thought maybe some people would not find it to be very funny.
> > > > > Nevertheless, I'd like to find out how
> > > >
> > > > :)
> > > >
> > > > > an impartial observer could distinguish between a 
> blind rule and 
> > > > > charter mandate.
> > > >
> > > > This is clearly the job of the chairs and the AD. They will
> > > ensure new
> > > > proposals meet this criteria.
> > > >
> > > >
> > > > Regards
> > > > Sri
> > > >
> > > >
> > > >
> > > >
> > > > On Tue, 17 Jun 2008, Charles E. Perkins wrote:
> > > >
> > > > >
> > > > > Hello Sri,
> > > > >
> > > > > It seems to me that you have certain strong ways of 
> classifying 
> > > > > which changes are legitimate, based on whether they 
> affect the 
> > > > > client's "stack".  Can you be a bit more specific about
> > > this?  How
> > > > > can I tell whether something affects the "stack"?  
> Will all such 
> > > > > client signals be handled over some UDP, TCP, or SCTP port?
> > > > >
> > > > > Regarding:
> > > > >
> > > > >>        .......      W.G should see the host stack changes
> > > objectively
> > > > >>  and not go with one blind rule.
> > > > >
> > > > > I was going to ask how many blind rules we should have,
> > > but then I
> > > > > thought maybe some people would not find it to be very funny.
> > > > > Nevertheless, I'd like to find out how an impartial
> > > observer could
> > > > > distinguish between a blind rule and charter mandate.
> > > > >
> > > > > Regards,
> > > > > Charlie P.
> > > > >
> > > > >
> > > > >
> > > > > Sri Gundavelli wrote:
> > > > >>  Hi Charlie,
> > > > >>
> > > > >>  The basic assumption of the NETLMM, the 
> non-involvment of the
> > > client
> > > > >>  in mobility signaling should always hold true. That
> requirement
> > > should
> > > > >>  not be relaxed. The protocol that is on the table today is
> > > designed
> > > > >>  with that goal. All aspects of the protocol will 
> function with 
> > > > >> absolutely zero changes to the host stack. This includes
> > > even the
> > > > >> inter-technology handoff. There is some confusion that the
> > > requirement
> > > > >>  of virtual interface support on the host implies changes to
> the
> > > host
> > > > >>  stack. That is absolutely not true, Ryuji and me will
> > > demonstrate
> > > this
> > > > >>  soon.
> > > > >>
> > > > >>  Now, w.r.t to the comment from Raj that we need 
> allow changes
> to
> > > host.
> > > > >>  These changes are minor optimizations. Examples of such
> > > optimizations
> > > > >>  include:
> > > > >>
> > > > >>  - The ability for the host and the access router to perform
> > > capability
> > > > >>    exchange
> > > > >>  - Prefix colouring, the ability for the host to distinguish
> > > between
> > > > >>    a prefix that has mobility properties to a local prefix
> > > > >>  - Some minor SEND related extensions
> > > > >>  - Optimizations w.r.t DNA, for improving the handoff latency
> > > > >>
> > > > >>  None of this can be equated to a client stack requirement.
> These
> > > fall
> > > > >>  in the scope of the general IPv6 host stack improvements and
> in
> > > the
> > > > >>  context of NETLMM. W.G should see the host stack changes
> > > objectively
> > > > >>  and not go with one blind rule.
> > > > >>
> > > > >>  Regards
> > > > >>  Sri
> > > > >>
> > > > >
> > > > _______________________________________________
> > > > netlmm mailing list
> > > > [email-masked]
> > > > https://www.ietf.org/mailman/listinfo/netlmm
> > > _______________________________________________
> > > netlmm mailing list
> > > [email-masked]
> > > https://www.ietf.org/mailman/listinfo/netlmm
> > >
> 
_______________________________________________
netlmm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netlmm

---

From: "Charles E. Perkins" <[email-masked]>
Date: Fri, 20 Jun 2008 09:54:19 -0700

Hello Mohana,

I have questions about your answers to Gerardo...

Mohana Jeyatharan wrote:

> [Mohana] The current charter says that MN should not be involved
> in mobility management signaling.  It does not restrict the MN
> from participating in some support signaling.

Do you mean that it is O.K. for a MN to support mobility
management, but that it is not O.K. for a MN to be involved
with mobility management?

I think such a distinction would be almost impossible
to apply or evaluate in practice.

>   I am not sure why
> you categorize inter-tech handover optimization signaling, or
> multihoming Related signaling in PMIP to mobility management
> signaling.

I would certainly characterize handover signaling as related
to mobility management.  It's almost a tautology!!

> I think mobility Management signaling is mainly to
> create routing state.

As opposed to... what?  Forwarding state?  Bridging
state?  Location state?  or... ??

> Also, having some infrequent AR interaction is very different
> to updating your location at an HA (this is mobility management
> signaling).

How infrequent?  Does the relatively long MIPv6 maximum
binding lifetime (3 days, I think) lead to overly frequent signaling?
Compared to, say, what?

> modifciation to unmodified host

This, I can go along with :-)

> should be able to perform some signaling to the network to achieve this.

I can also go along with this :-)

> Mobility management signaling and thus I don't see why it breaks the

This is the part that has me stumped.

Regards,
Charlie P.