Subject: [netlmm] Fwd: I-D Action:draft-tsirtsis-logically-separate-lmaha-00.txt

From: "George Tsirtsis" <[email-masked]>
Date: Tue, 25 Mar 2008 10:49:22 +0000

Hi all,

Krishnan and I put together a draft describing what the expected
behavior of a combined LMA/HA implementation should be. This should
help the discussions around the so called scenario C of the PMIP-MIPv6
interactions draft (draft-giaretta-netlmm-mip-interactions).

I hope you find the discussion in this draft useful.
Please let us know if you have any comments/questions.

Regards
George

---------- Forwarded message ----------
From:  <[email-masked]>
Date: 2008/3/25
Subject: I-D Action:draft-tsirtsis-logically-separate-lmaha-00.txt
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : Behavior of Collocated HA/LMA
        Author(s)       : G. Tsirtsis, S. Krishnan
        Filename        : draft-tsirtsis-logically-separate-lmaha-00.txt
        Pages           : 9
        Date            : 2008-03-25

 In discussions about PMIPv6-MIPv6 interactions in NETLMM WG, scenario
 C describes the case of collocation of LMA and HA function.  In this
 case a PMIP network emulates the "home link" for MNs using MIPv6.
 This document argues that even when LMA and HA functions are
 Collocated they MUST be treated as logically separate entities.  In
 particular this draft argues that PMIP BCEs MUST NOT overwrite MIPv6
 BCEs and vice versa.

 A URL for this Internet-Draft is:
 http://www.ietf.org/internet-drafts/draft-tsirtsis-logically-separate-lmaha-00.txt

 Internet-Drafts are also available by anonymous FTP at:
 ftp://ftp.ietf.org/internet-drafts/

 Below is the data which will enable a MIME compliant mail reader
 implementation to automatically retrieve the ASCII version of the
 Internet-Draft.

_______________________________________________
 I-D-Announce mailing list
 [email-masked]
 https://www.ietf.org/mailman/listinfo/i-d-announce
 Internet-Draft directories: http://www.ietf.org/shadow.html
 or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
_______________________________________________
netlmm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netlmm

---

From: "Kilian Weniger" <[email-masked]>
Date: Tue, 25 Mar 2008 17:05:01 +0100

Hi all,

there has been little progress on the topic of interworking between MIPv6 and PMIPv6 recently. One reason is that the authors of draft-giaretta-netlmm-mip-interactions so far couldn't agree on the general approach to solve the interworking scenario, where the HA and LMA are co-located and the MN's mobility management scheme changes between PMIPv6 and MIPv6 during a session (i.e., MIPv6 HoA == PMIPv6 HoA). This scenario is called "scenario C" and is described in detail in draft-giaretta-netlmm-mip-interactions-02.

There are currently two approaches on the table to solve scenario C:

  1) One BCE per MN for PMIPv6-MIPv6 handovers (see draft-giaretta-netlmm-mip-interactions-02)

       BCE is equally shared by PMIPv6 and MIPv6, i.e., 
       MN and MAG change the same BCE. Neither of the
       mobility schemes is prioritized over the other.

  2) Two BCEs per MN for PMIPv6-MIPv6 handovers (see draft-tsirtsis-logically-separate-lmaha-00.txt)

       One BCE for PMIPv6 and one BCE for MIPv6. 
       The HA/LMA always prefers the MIPv6 BCE over the 
       PMIPv6 BCE for forwarding data packets, i.e., 
       PMIPv6 BCE is only used if the MIPv6 BCE is emtpy.

The current interactions draft draft-giaretta-netlmm-mip-interactions-02 assumes approach 1), whereas draft-tsirtsis-logically-separate-lmaha-00.txt proposes approach 2).

We would like to hear the WG's comments and opinions about both approaches. 

Thanks,

Kilian

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of George Tsirtsis
> Sent: Dienstag, 25. März 2008 11:49
> To: Netlmm
> Cc: [email-masked]
> Subject: [MEXT] Fwd: 
> I-DAction:draft-tsirtsis-logically-separate-lmaha-00.txt
> 
> Hi all,
> 
>         Filename        : 
> draft-tsirtsis-logically-separate-lmaha-00.txt
>         Pages           : 9
>         Date            : 2008-03-25
> 
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext
> 
> 

Panasonic R&D Center Germany GmbH
63225 Langen, Hessen, Germany
Reg: AG Offenbach (Hessen) HRB 33974
Managing Director: Thomas Micke

---

From: "Kilian Weniger" <[email-masked]>
Date: Tue, 25 Mar 2008 17:04:58 +0100

Hi George,

I have some clarifying questions regarding section 4.1.1 of your draft, which argues why sharing a single BCE between MIPv6 and PMIPv6 is supposed to be wrong in draft-giaretta-netlmm-mip-interactions-02. All three arguments mentioned in the draft are about scenarios where the MN has multiple active network interfaces (with or without MIPv6 multihoming). However, I don't really understand the logic of these arguments and why they apply, maybe you can elaborate. 

  1) "Directing traffic between foreign links: If an MN can maintain two
      links at the same time, it can direct traffic to one or the other
      link by simply sending a BU to its HA, registering the CoA
      corresponding to one or the other link."

Why is this scenario related to PMIPv6-MIPv6 interactions? This is a pure MIPv6 scenario not related to the discussion of shared vs. separate BCEs for PMIPv6 and MIPv6, right?

  2) "Directing traffic between home and foreign link: If one of the
      links maintained is the home link, the MN can direct traffic to it
      by sending a deregistration MIPv6 BU to the HA over the home link,
      while it can also direct traffic to the foreign link by sending a
      MIPv6 BU to the HA directing traffic to the CoA of the foreign
      link."

If I understand the scenario correctly, the MN has one active interface connected to the home link and another active interface connected to a foreign link and wants to switch dynamically between both without moving. Since we are not talking about HAs extended by MIPv6 multihoming/monami6 extensions here, is this special scenario even supported by RFC3775? I think it is not, since both the MN and the HA would defend the HA on the home link.

  3) "Directing traffic between Multiple links: MEXT WG is also working
      on [I-D.ietf-monami6-multiplecoa] and
      [I-D.soliman-monami6-flow-binding] specifications allowing an MN
      to register multiple links (multiple CoAs and the home link) to
      its HA at the same time and even direct different flows to
      different links."

      It should be clear that none of this can be possible if every time
      the MN connects to its home link, the corresponding PMIPv6 BCE
      overwrites the HA BCEs for the same mobile or every time the MN sends
      a BU to its HA over a foreign link, the MIPv6 BCE overwrites the LMA
      BCE entry for the same MN."

This argument only applies to monami6 HAs. However, monami6 is out of the agreed scope of the MIPv6-PMIPv6 interactions draft. draft-giaretta-netlmm-mip-interactions-02 says 

  "Note that the issues are described based on current
   specification and does not assume any optimized solution for any
   scenario.  The specifications considered as a baseline for the
   analysis are the following: [RFC3775], [RFC4877] and [pmipv6-draft]."

Thanks,

Kilian

---

From: "George Tsirtsis" <[email-masked]>
Date: Tue, 25 Mar 2008 16:37:56 +0000

Hi Kilian,

I appreciate you reading the draft so quickly, see below some comments.

>  Why is this scenario related to PMIPv6-MIPv6 interactions? This is a pure MIPv6 scenario not related to the discussion of shared vs. separate BCEs for PMIPv6 and MIPv6, right?

GT> This scenario does not present a problem for PMIP-MIP
interactions. It is presented in the draft since for some people
thinking about alternating between CoAs of two foreign links while
both of the foreign links are up sounds natural. In the draft I am
simply arguing that the same should be possible between a home and a
foreign link.

>  If I understand the scenario correctly, the MN has one active interface connected to the home link and another active interface connected to a foreign link and wants to switch dynamically between…

GT> Kilian, please reconsider your thinking on this. RFC3775 fully
supports this scenario. There is a parallel thread in MEXT where this
is being discussed. RFC3775 does not say anything about how many IP
interfaces the MN has. The only think RFC3775 says is that only one
CoA is registered at any one time. An MN can obviously have two (or
more) IP links e.g., one over 3G and another over WLAN. These IP
interfaces have their own addresses, which are potential care-of
address in MIPv6. RFC3775 defines that only one of them can be
registered at any one time. MCoA extensions allow more than one to be
registered at the same time.

GT> The above should be blindingly obvious to anyone who has ever
implemented Mobile IP for inter-technology handoffs. People who doubt
this, should check any one the many Mobile IP based WLAN to 3G handoff
implementations. Most companies in the wireless space have tried this
at least internally over the last several years. I know for a fact
that the implementation I was involved with did exactly that and I bet
most others do the same. This is obvious since different airlink
technologies tend to overlap in coverage causing the MN to be
connecting to both of them at the same time. at least for a time (...a
long time of the MN stays in the overlap zone). By registering either
one CoA or the other the MN switches between the two available links
based on SNR ot policy parameters..

>  This argument only applies to monami6 HAs. However, monami6 is out of the agreed scope of the MIPv6-PMIPv6 interactions draft. draft-giaretta-netlmm-mip-interactions-02 says

GT> The MCoA considerations in this draft are there to remind people
what else is possible given features we are developing in MEXT and the
fact that implementing BCEs in the wrong day today, may affect
features tomorrow. It would be rather shortsighted to ignore what we
know is coming. In any case, as you see above the issue exists even
without considering MCoA.

---

From: "George Tsirtsis" <[email-masked]>
Date: Tue, 25 Mar 2008 16:42:55 +0000

Killian, let's stop cross posting to MEXT and continue this discussion
in NETLMM list ONLY!
This should be the last e-mail to MEXT on this topic.

Thanks for your help
George

---

From: Hesham Soliman <[email-masked]>
Date: Wed, 26 Mar 2008 19:37:45 +1100

Please take mext out of this thread. This is a NETLMM draft.

On 26/03/2008, at 3:05 AM, Kilian Weniger wrote:
> Hi all,
>
> there has been little progress on the topic of interworking between  
> MIPv6 and PMIPv6 recently. One reason is that the authors of draft- 
> giaretta-netlmm-mip-interactions so far couldn't agree on the  
> general approach to solve the interworking scenario, where the HA  
> and LMA are co-located and the MN's mobility management scheme  
> changes between PMIPv6 and MIPv6 during a session (i.e., MIPv6 HoA  
> == PMIPv6 HoA). This scenario is called "scenario C" and is  
> described in detail in draft-giaretta-netlmm-mip-interactions-02.
>
> The current interactions draft draft-giaretta-netlmm-mip- 
> interactions-02 assumes approach 1), whereas draft-tsirtsis- 
> logically-separate-lmaha-00.txt proposes approach 2).
>

---

From: "Kilian Weniger" <[email-masked]>
Date: Wed, 26 Mar 2008 15:23:02 +0100

Hi George, 

thanks for the clarifications. Please see comments inline.

> >  If I understand the scenario correctly, the MN has one 
> active interface connected to the home link and another 
> active interface connected to a foreign link and wants to 
> switch dynamically between both without moving. Since we are 
> not talking about HAs extended by MIPv6 multihoming/monami6 
> extensions here, is this special scenario even supported by 
> RFC3775? I think it is not, since both the MN and the HA 
> would defend the HA on the home link.
> >
> 

Maybe we have different specific scenarios in mind. I agree of course
that generally an inter-technology handoff can be supported by RFC3775,
but an inter-technology handoff can also be supported by
draft-giaretta-netlmm-mip-interactions-02.txt when the BCE is
overwritten after the handover. Can you elaborate what exactly is the
problem when the BCE is overwritten in an inter-technology PMIPv6-MIPv6
handoff scenario? Let's discuss this using specific example scenarios.

The example scenario I had in mind from your description is as follows:
1. The MN is connected to the foreign link via interface 1 and the CoA
is registered at the HA
2. The MN switches on interface 2, which attaches to the home link.
Hence, interface 2 configures the MN's HoA.
3. Usually, the MN would now send a BU de-registration to update the HA
with the new location. As I understood your scenario, the MN now does
*not* send a BU de-registration, because it still wants to receive the
traffic via interface 1 for some reason. 

My comment was that this may be a problem, since both MN and HA would
defend the same HoA on the home link. AFAIK, RFC3775 doesn't specify the
case that the MN is attached to the home link and has the HoA
configured, but does not defend its HoA on the link (BTW, IMHO we should
discuss what the text in the RFC3775 specification supports, not what
some MIPv6 implementations support.)

> >  This argument only applies to monami6 HAs. However, 
> monami6 is out of the agreed scope of the MIPv6-PMIPv6 
> interactions draft. draft-giaretta-netlmm-mip-interactions-02 says
> >
> 

The point is that MCoA extensions are out of scope of the current
PMIPv6-MIPv6 interactions draft. It really doesn't make sense to discuss
out of scope topics IMHO. It is already difficult enough to have
progress with the in-scope topics. Mixing the discussion with potential
future extensions doesn't help progress at all IMHO.

Furthermore, you need to do a fair comparison. If you consider MIPv6
MCoA HA for the MIPv6-PMIPv6 handoffs, you also need to consider LMAs
with future PMIP MCoA + flow filtering extensions (which may involve the
MN). With such extensions in place, it will probably be possible to
support your scenario even when the single-CoA PMIPv6-MIPv6 handoff
scenario (which is the one that is actually for discussion now) is
solved by overwriting the BCE. A PMIP MCoA extension would extend the
single BCE in the LMA to multiple BCEs, because how can you ever support
multiple CoAs with a single BCE (Monami6 also specifies multiple BCEs)?
But again, such discussion is mood, since we don't know yet how a future
PMIP MCoA extension looks like. Let's focus on the scenarios that are in
scope of the PMIPv6-MIPv6 interactions draft now and that is the single
CoA handoff scenario.

Kilian

---

From: "George Tsirtsis" <[email-masked]>
Date: Thu, 27 Mar 2008 11:14:22 +0000

Killian, sorry for the delay in responding...things are a bit crazy
here. See comments inline.

>  traffic via interface 1 for some reason.

GT2> Yes, this is a valid example illustrating what I have been talking about.

>  some MIPv6 implementations support.)

GT2> There is nothing in RFC3775 preventing this. In fact, RFC 3775
(section 11.5.4) is very explicit about the fact that the MN MUST NOT
defend its HoA on the home link until AFTER it sends a BU to the HA,
so that you do not have two nodes on the same link defending the same
address. The RFC is also very specific about how the MN should
construct an NS message if one must be sent prior to the deregBU,
exactly for the same reason.

>  future extensions doesn't help progress at all IMHO.

GT2> I disagree. Making MCoA out of scope is arbitrary and wrong.
Documenting a PMIPv6 implementation that is clearly incompatible with
an already fully specified MIPv6 extension (in WG LC level) is wrong
and against NETLMM charter which requires PMIPv6 and MIPv6
compatibility. I repeat, however, that what you have been proposing is
even incompatible with RFC3775.

GT2> Kllian think about this carefully. PMIP MUST NOT be visible to
mobiles. A PMIP domain emulates a link and as far as the MN is
concerned, a link is a link, whether the link is using Ethernet, GTP,
PMIP or whatever. As you may know PMIP and GTP are now used almost
interchangeably in 3GPP Rel8 specifications. In this system the
following configurations are defined.
       (1)  the 3GPP Gateway implements a PMIP LMA and a MIPv6 HA, and
       (2) the 3GPP Gateway implements a GTP termination and a MIPv6 HA.
In both cases the GTP and PMIP domains emulate a home link for MIPv6
i.e., scenario C as we discuss here.

GT2> Could you imagine us having the same discussion we are having now
about PMIP-MIP interactions, about GTP-MIP interactions? Would you
find acceptable that a GTP registration overwrites a MIPv6 BCE?. It
would be unthinkable and anyone who proposed such a notion would be
laughed at. Why is it then so appealing to do this obviously wrong
thing when instead of GTP based link-emulation, we have PMIP based
link-emulation?

George

---

From: "George Tsirtsis" <[email-masked]>
Date: Thu, 27 Mar 2008 12:16:24 +0000

I broke my own rule and CCed MEXT by accident.
Kilian et.al., if you have further comments please respond to this
e-mail which does not copy mext list.

Thanks
George

---

From: "Genadi Velev" <[email-masked]>
Date: Fri, 28 Mar 2008 17:10:41 +0100

Hi George,

I appreciate your effort in capturing the problem of HA-LMA collocated
implementation. You indeed observe an aspect of the MIPv6-PMIPv6
interactions problem that was not considered at the time when the
MIP-PMIP interactions I-D was written.  You say in your document:

  "This logic [GV: PMIPv6 PBUs to overwrite state created by PMIPv6 BUs
   and vice versa] breaks down if one considers MNs that are capable of
   maintaining more than one link at the same time.  Such capability is
   common and can be utilised in many different way, while specifically
   MIPv6 allows for the following behavior:"

It is obvious that a collocated HA/LMA must have multiple simultaneously
active BCEs (MIPv6 and/or PMIPv6) whenever the MN maintains multiple IP
links. However, I don't see why generally "BCE Overwriting is Wrong".
There are at least 2 cases coming to my mind in which overwriting is OK:
case 1) if the MN has a single interface and moves from non-PMIPv6
domain to PMIPv6 domain and case 2) if the MN performs a hard-handover
(vertical handover) between interfaces. For example, PMIPv6
specification describes that the Handoff Indicator (HI) field in the PBU
can explicitly tell the HA/LMA that interface handover is performed (HI
value of 2). In that case the PMIPv6 PBUs can overwrite the MIPv6 BCE. 

Therefore, IMHO we shall differentiate between cases where overwriting
the MIPv6 BCE by PMIPv6 PBU is technically desired and another cases
(simultaneous multiple IP links are up) where maintenance of separate
PMIPv6/MIPv6 BCEs is desired. 

Genadi

> Sent: Tuesday, March 25, 2008 11:49 AM
> To: Netlmm
> Cc: [email-masked]
> Subject: [MEXT] Fwd:

---

From: "George Tsirtsis" <[email-masked]>
Date: Fri, 28 Mar 2008 21:47:50 +0000

Hi Genadi,

I am glad you now understand the issue with the multiple links.
What you suggest, however, is entirely unrealistic.

Below you say:
">  Therefore, IMHO we shall differentiate between cases where overwriting
>  PMIPv6/MIPv6 BCEs is desired."

Could you please explain how would the HA/LMA know whether a given MN
can maintain multiple links in parallel or not? And before we start
talking about AAA servers, god-boxes, capabilities negotiation,
telepathy, and other, at best non-universal and at worst non-existent,
system level bells and whistles, please remember that here we are in
the IETF talking about PMIP-MIP interactions.

Let me also repeat my earlier comment about how unthinkable what you
suggest would seem to a casual observer if we were talking about
GTP-MIP interactions. I repeat, would you find acceptable that a GTP
registration overwrites a MIP BCE? under any circumstances?

Finally, I am really perplexed about this. What is so "hot" about
overwriting BCEs? Why so much insistence in the face of overwhelming
evidence that it is a bad idea and when there is a perfectly valid,
bug-free alternative?

Regards and have a nice weekend
George

---

From: "Genadi Velev" <[email-masked]>
Date: Mon, 31 Mar 2008 14:03:24 +0200

Hi George,

> What you suggest, however, is entirely unrealistic.

I think your estimation of my suggestion is a bit dramatic. Please find
my answers below. 

> the IETF talking about PMIP-MIP interactions.

Since you don't want to hear about nice AAA protocols, I'm going to give
you a concrete example based on information exchange during attach
procedure in 3GPP ;-)  Would you claim that information exchange on L2
(or technology/link specific exchange) that is used for IP configuration
is non-universal and non-existent case (especially in point-to-point
links)?  Here is the example: during the attach procedure to the 3GPP
LTE access, the MN can set a "Handover" indicator. This would mean that
the MN wants to perform a handover from any non-3GPP access to LTE
access. Then the LMA can learn via the PBU from the MAG (e.g. HI field
set to 2) that the MN performs a handover between interfaces, hence, the
MIP BCE can be overwritten. OTOH, if the "Handover" indicator during LTE
attach is not set, the PBU from the MAG would contain HI value 4 and the
LMA would create a PMIP BCE without overwriting the MIP BCE (this is the
case from your scenario). The MIP BCE would be deleted after MN sends
deregistration BU to the HA. 

> registration overwrites a MIP BCE? under any circumstances?

I thought we were talking about MIP-PMIP interactions and not about
MIP-GTP interactions.  HA and GTP tunnel endpoint collocation is neither
in the scope of the current email thread nor in the NETLMM scope.  

> evidence that it is a bad idea and when there is a perfectly valid,

George, there is nothing "hot" about overwriting BCEs. In some cases the
MIP->PMIP handover procedure would be faster, if the PBU can overwrite
the MIP BCE, because the PBU arrives earlier at the HA/LMA than the
deregistration BU from the MN. That's all. I'm advocating to have more
freedom in the implementation of collocated HA/LMA.

Regards,
Genadi

---

From: Hesham Soliman <[email-masked]>
Date: Mon, 31 Mar 2008 23:17:45 +1100

> deregistration BU to the HA.

=> That's all well and good until some radical user decides to connect  
a 3G modem to his/her laptop and *also* move between 3GPP and non-3GPP  
access. Oops :)
Suddenly standards do not translate into support for the "non  
integrated UE" scenarios.

In IETF we need to be more generic to accomodate various scenarios and  
deployments. Given that it takes a few years to produce a useful PS,  
we can't work for narrow cases.

Hesham

---

From: "George Tsirtsis" <[email-masked]>
Date: Mon, 31 Mar 2008 12:52:39 +0000

Hesham of course is right.

Also Genadi, you did not talk about AAA system, but you talked about
an even less universal 3GPP specific mechanism which is at best
several years out in terms of deployment.

I believe you are confusing what you as a vendor can do in your
implementation, with what the IETF should recommend as the generic
technique that should be used because it covers all cases. In your
implementation you can of course do whatever you want, even if it is
completlly wrong and/or if it breaks one or the other specification.

I could explain to you why what you want to do makes no sense
whatsoever, even in the specific 3GPP case you are talking about, but
then we would be completlly off-topic and I would also have to charge
you a fee :-)

Regards
George

---

From: "Genadi Velev" <[email-masked]>
Date: Mon, 31 Mar 2008 17:31:31 +0200

Hi Hesham,

your example scenario with non-integrated MN having 3G and non-3G
interface and handover from non-3G->3G does not help a lot in our
discussion about separated MIP BCE and PMIP BCE. Since there is no
"hint" during the attach procedure that the MN performs a handover, the
network could advertise a new prefix to the MN and the session
continuity could be broken. I don't know about specification that
mandates the advertisement of the same prefix (in the prefix-per-MN
models) in such cases. 

Well, I don't want to dig into a specific technology, just wanted to
show that if a handover indicator is present (and this is realistic in
the deployment of a big PMIPv6 customer), why not allowing the PMIP PBU
overwriting the MIP BCE. If the WG thinks that we don't need to cover
such a case, then I'm OK. 

Regards,
Genadi

> From: Hesham Soliman [mailto:[email-masked]] 
> Sent: Monday, March 31, 2008 2:18 PM
> To: Genadi Velev
> Cc: George Tsirtsis; Netlmm
> Subject: Re: [netlmm] [MEXT] 
> Fwd:I-DAction:draft-tsirtsis-logically-separate-lmaha-00.txt
> 
> 
> > Since you don't want to hear about nice AAA protocols, I'm 
> going to  
> > give
> > set to 2) that the MN performs a handover between 
> interfaces, hence,  
> > the
> > MIP BCE can be overwritten. OTOH, if the "Handover" 
> indicator during  
> > LTE
> > attach is not set, the PBU from the MAG would contain HI 
> value 4 and  
> > the
> > LMA would create a PMIP BCE without overwriting the MIP BCE 
> (this is  
> > the

---

From: "Genadi Velev" <[email-masked]>
Date: Mon, 31 Mar 2008 17:32:25 +0200

Hi George,

I well understand what is in the scope of IETF. I was giving an example,
how the network can learn the MN's intention with a current system which
is under standardization. BTW, the handover indicator in the attach
procedure from my previous email is the state-of-the-art from the latest
version of 3GPP TS 23.402 (Figure 8.2.1.3-1). 

> then we would be completlly off-topic and I would also have to charge

If the fee is a couple of beers, then I'd enjoy your lesson, otherwise I
need to talk to my boss :-)

Maybe we can hear the opinion of other folks to get a consensus on that
topic.

Regards,
Genadi

> From: George Tsirtsis [mailto:[email-masked]] 
> Sent: Monday, March 31, 2008 2:53 PM
> To: Hesham Soliman
> Cc: Genadi Velev; Netlmm
> >  > Since you don't want to hear about nice AAA protocols, 
> I'm going to
> >  > give
> >  > LTE access, the MN can set a "Handover" indicator. This 
> would mean
> >  > that
> >  > LMA would create a PMIP BCE without overwriting the MIP 
> BCE (this is
> >  > the

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 1 Apr 2008 10:36:01 +1100

> discussion about separated MIP BCE and PMIP BCE.

=> It helps to show that the scenario you mentioned doesn't work in  
the network you were talking about (3GPP).
You were trying to explain a realistic scenario and obviously it's not  
for many reasons.

> such a case, then I'm OK.

=> So you don't want to dig into a specific deployment scenario but  
happy to mention a very detailed 3GPP example that doesn't really  
work. The point is, your example is not
useful and you need to find a useful example to justify the  
overwriting of MIP BCE. Otherwise we'll go around in circles.

Hesham

---

From: "Genadi Velev" <[email-masked]>
Date: Tue, 1 Apr 2008 11:41:21 +0200

Hi Hesham,
 
> You were trying to explain a realistic scenario and obviously 

The scenario I mentioned suggests overwriting of the MIP BCE by a PBU
only in cases where the MAG can be sure that the MN is performing
handover. If there is no info at the MAG (e.g. your example of
non-integrated terminal) what the MN is performing (handover,
multihoming etc.), the PBU will not overwrite the MIP BCE, but the MN's
deregistration BU will delete it. What is not working and not realistic
in such a scenario?  

> > the deployment of a big PMIPv6 customer), why not allowing 
> the PMIP  
> > PBU

I would buy you a technical argument why an earlier update of the BCE is
not useful (when an integrated MN indicates to the network that it is
performing a hard-handover between interfaces). If the deregistration BU
is delayed for any reason, then packets are not delivered to the MN,
although the MN is ready to receive them (note: the MN is attached via a
point-to-point link, so ND protocol may not be needed).

Genadi

---

From: Hesham Soliman <[email-masked]>
Date: Wed, 2 Apr 2008 01:17:31 +1100

Genadi,

If you answer my comments by going back to the integrated UE scenario  
then we're not having a conversation, we have a circular discussion.
The point of my comments is that even when the solution you mention is  
deployed (long time from now) it is not generic for all terminals
and therefore not much use. So there is no point in telling me how  
useful it is for an integrated terminal.

Hesham

---

From: "Genadi Velev" <[email-masked]>
Date: Tue, 1 Apr 2008 16:47:23 +0200

Hesham,

the solution I mentioned works exactly as good as your solution for
non-integrated MN and better for integrated MN. And this was my point
since the beginning of the discussion. 

Genadi

> From: Hesham Soliman [mailto:[email-masked]] 
> Sent: Tuesday, April 01, 2008 4:18 PM
> To: Genadi Velev
> Cc: Netlmm