Subject: [netlmm] Way forward on PMIP multihoming discussion

From: "Soininen Jonne (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 02 Oct 2007 22:28:29 +0300

Hello everybody,

there has been heated debate on the PMIP multihoming issue on the 
mailing list on last couple of days. Perhaps the discussion has now 
entered the state where there isn't a clear way forward anymore.

It seems that there are two opinions now: 1) write down multi-homing is 
out of scope of this document and 2) stating that multihoming is not 
allowed for PMIP.  I hope I got this right.

I would propose the following wording:

"X.X Inter-interface handovers

A handover involving a change in the MN's network interface is not 
supported by this version of PMIP. Hence, a network implementing PMIP 
SHOULD NOT allow intra- or inter-access handovers, which would result to 
the change of the MN's network interface."

I don't know if people like this (or a derivant of the wording). 
However, either we together try to get a common wording based on 
somebody's text, or at least I don't see any other option but go for a 
consensus call.

I hope this helps...

Cheers,

Jonne.

_______________________________________________
netlmm mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/netlmm

---

From: Ashutosh Dutta <[email-masked]>
Date: Tue, 02 Oct 2007 15:39:42 -0400

I think it would not be a good idea to rule out completely PMIP's 
applicability for handover involving different interfaces (e.g, between 
802.11 and CDMA). That is a valid heterogeneous handover scenario future 
wireless service providers might be providing in any case, and they 
should be able to use PMIP to support this scenario.

Thanks
Ashutosh

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 2 Oct 2007 12:47:36 -0700

Hi Jonne,

Thanks for trying to close this thread, appreciate it. Please
see inline.

> -----Original Message-----
> From: Soininen Jonne (NSN - FI/Espoo) [mailto:[email-masked]] 
> Sent: Tuesday, October 02, 2007 12:28 PM
> To: [email-masked]
> Subject: [netlmm] Way forward on PMIP multihoming discussion
> 
> Hello everybody,
> 

I think, this text goes even beyond multi-homing (simultaneous access)
and restricts inter-access handoffs as well even when doing single
interface attachments at any point of time.

I do not think, we should apply any restrictions. Clearly IMO, there
are only 3 or 4 people in the working group, who wants this restriction.
We should do a consensus call and move forward. I believe, 99% of the
WG do not want this restriction and we can check that. The text we
provided on this issue IMO is sufficient, it documents the behavior
clearly and provides the required guidance. 

Regards
Sri

---

From: "Soininen Jonne (NSN FI/Espoo)" <[email-masked]>
Date: Tue, 02 Oct 2007 22:48:33 +0300

Hi Ashutosh,

I think nobody is trying to totally rule out the handover. However, allowing
such a handover would need changes to the MN. That is currently out of scope
of the PMIP base draft.

Cheers,

Jonne.

-- 
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34
E-mail: [email-masked]

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 2 Oct 2007 12:50:23 -0700

> From: Ashutosh Dutta [mailto:[email-masked]] 
> Sent: Tuesday, October 02, 2007 12:40 PM
> To: Soininen Jonne (NSN - FI/Espoo)
> Cc: [email-masked]
> Subject: Re: [netlmm] Way forward on PMIP multihoming discussion
> 

Absolutely !! 

Sri

---

From: Ashutosh Dutta <[email-masked]>
Date: Tue, 02 Oct 2007 15:59:45 -0400

Jonne,
       Thanks. I think, we should not put any restriction on PMIP's use, 
such as inter-access. It may be out-of-scope from the current version, 
but needs to be looked into at some point. The current text you have 
provided somehow puts that restriction, at least the second sentence.

Thanks
Ashutosh

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Tue, 2 Oct 2007 13:08:57 -0700

Hi Sri,

> From: Sri Gundavelli [mailto:[email-masked]]
> Sent: Tuesday, October 02, 2007 9:48 PM
> To: 'Soininen Jonne (NSN - FI/Espoo)'; [email-masked]
> Subject: RE: [netlmm] Way forward on PMIP multihoming discussion
> 
> Hi Jonne,
> 

The motivation of this has been explained by Jonne in a previous email.
Inter-access handoffs (and multihoming) require modifications of the
mobile node which is in conflicts with the charter and RFC 4831. 

> clearly and provides the required guidance.

The restrictions are not artificial. It is just that the protocol does
not meet the goals in RFC 4831 (and does not work) if applied to certain
scenarios. Sorry but I don't think NETLMM WG can specify a document
which does not meet the goals published by the WG itself.

Regards
Gerardo

---

From: "Soininen Jonne (NSN FI/Espoo)" <[email-masked]>
Date: Tue, 02 Oct 2007 23:14:30 +0300

Ashutosh,

I don't think my wording disallows inter-access handovers totally. If you
implement the two accesses to look like one network interface for the IP
stack my wording would allow that case. Or at least it wasn't supposed to.

This is the same case as the 2G-3G handover today. It is done completely in
the network, but as the both accesses are behind one network interface and
the IP stack never sees the change. The wording in my proposal should allow
this.

Cheers,

Jonne.

-- 
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 2 Oct 2007 13:23:10 -0700

Hi Gerado,

Please see inline.

> mobile node which is in conflicts with the charter and RFC 4831. 

The specification is providing mobility to any address in a network
prefix. Now, if a host configures the same address on different
access interfaces and does a handoff or if it uses a single interface
and does a handoff, should not be our problem. If some architecture
can handle this, let them do so. They may have a virtual interface
abstracting the physical interfaces and can very well confirm to
the specification. Our explicit note to prevent this is not right.

Regarding the charter, Multi-homing is not in scope. When some thing
is not in scope, why are we discussing that configuration ? The
text we provided documents the scope and thats the best we can do.

> which does not meet the goals published by the WG itself.

There is no need to explicitly document some scenario that is not
in scope and put some articificial restrictions. The document talks
about what is in scope and thats defines the usage scope.

Sri

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Tue, 2 Oct 2007 13:25:46 -0700

Hi Jonne,
Unfortunately, I'm not sure how this text addresses the issue under
discussion.  In the issue under discussion, there is no handover needed
for the problem to occur.  The issue simply has to do with multiple
interfaces of an MN attaching to a given PMIP domain, with no relevance
to whether there is a handoff or not across those interfaces.  Perhaps I
misunderstood your text suggestion? 

Thanks,
Vidya 

> there has been heated debate on the PMIP multihoming issue on 
> the mailing list on last couple of days. Perhaps the 
> discussion has now entered the state where there isn't a 
> clear way forward anymore.
> 
> It seems that there are two opinions now: 1) write down 
> multi-homing is out of scope of this document and 2) stating 
> that multihoming is not allowed for PMIP.  I hope I got this right.
> 
> A handover involving a change in the MN's network interface 
> is not supported by this version of PMIP. Hence, a network 
> implementing PMIP SHOULD NOT allow intra- or inter-access 
> handovers, which would result to the change of the MN's 
> network interface."
> 
> However, either we together try to get a common wording based 
> on somebody's text, or at least I don't see any other option 
> but go for a consensus call.
> 
> I hope this helps...
> 
> Cheers,
> 
> Jonne.
> 
>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 2 Oct 2007 15:43:07 -0500

Hi Jonnie,

Thanks for trying to close this issue in a fair way. I personally
appreciate that!

However, I would like the Co-chairs for netlmm wg to tell all of us, how
they justify splitting the PMIPv6-Client MIPv6 Interaction functionality
from the base protocol and agree that it can be addressed under a
different-ID while at the same time, at least, one of the co-chairs with
the <chair-hat-on> argues that this functionality can not be addressed
in a separate ID unless a clear restriction that causes PMIPv6 to be
born as non-useful and a handicapped protocol is clearly captured and
documented:-( 

In my mind, PMIPv6-Client MIPv6 interaction has a similar situation
where a Client MIPv6 node (existing host) may experience service
interruption If PMIPv6 network does not handle the interaction properly.
Why that is acceptable!

Why it is ok there and it is impossible here. What is the big deal about
addressing multi-homing in a separate ID?

To answer your question, I would support a consensus call for this
functionality to be out-of-scope vs. not been out-of-scope and by that
we close all issues and have a draft that is ready for IESG.

BTW: Incidentally that PMIPv6-Client MIPv6 draft is the only one that
has not been even adopted as wg document! :-(

Thanks.

Regards,
Ahmad

> Sent: Tuesday, October 02, 2007 2:28 PM
> To: [email-masked]

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 02 Oct 2007 23:16:30 +0200

Soininen Jonne (NSN - FI/Espoo) wrote:
> It seems that there are two opinions now: 1) write down multi-homing
> is out of scope of this document and 2) stating that multihoming is
> not allowed for PMIP.  I hope I got this right.
> 
>  SHOULD NOT allow intra- or inter-access handovers, which would
> result to the change of the MN's network interface."
> 
> somebody's text, or at least I don't see any other option but go for
> a consensus call.

Jonne, the text you propose sounds logical to me.

But I think it makes no sense to pursue the document with that X.X
section in it; to put it simply: how can we advance a document not
supporting handovers between two interfaces when MIP4 can, MIP6 can,
DHCP can and every other protocol has no such restriction.

Do we know any protocol that has such restriction on it?

This doesn't mean the document looks 'useless', not at all: most if not
all features are needed and already agreed.

I think there is technical solution out of it, provided we are not under
deadline pressure.

Alex

> 
> I hope this helps...
> 
> Cheers,
> 
> Jonne.
> 
> 
> _______________________________________________ netlmm mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/netlmm
> 

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 02 Oct 2007 23:18:03 +0200

> such a handover would need changes to the MN. That is currently out of scope

This sounds as if two PMIP instances on MAG and two PMIP instances on 
LMA could support a multi-interface MN - do we want that?

Alex

---

From: <[email-masked]>
Date: Wed, 3 Oct 2007 00:04:18 +0200

Sorry picking up this late on this.. far too long thread. I still
think the base spec should be as simple as possible and not trying
to tackle every possible feature there is like the multihoming part.
This very multihoming issue can and should be solved in a separate
I-D.. later. 

For example, MAGs and AAA etc can come up with whatever pseudo
identifier per interface granularity if it is needed to assure that every
interface gets their own prefix. After all the mobile node's identifier
that is used in PBUs gets managed on network side - it does not need to
be the same the mobile thinks as of its own identity. And still the
mobile would use only one identity for authentication purposes (if so
desired). The backend (not necessarily LMAs) can do the required mapping
and coordination between identities, if needed and so desired.

The current spec would work in the above example.

My 0.014€,
	Jouni

> Sent: Tuesday, October 02, 2007 10:48 PM
> multi-homing 
> > SHOULD NOT allow intra- or inter-access handovers, which 
> would result 
> > to the change of the MN's network interface."
> > 
> 
> I think, this text goes even beyond multi-homing 
> (simultaneous access) and restricts inter-access handoffs as 
> well even when doing single interface attachments at any 
> point of time.
> 
> I do not think, we should apply any restrictions. Clearly 
> IMO, there are only 3 or 4 people in the working group, who 
> wants this restriction.
> We should do a consensus call and move forward. I believe, 
> 99% of the WG do not want this restriction and we can check 
> that. The text we provided on this issue IMO is sufficient, 
> it documents the behavior clearly and provides the required guidance. 
> 
> Regards
> Sri
> 
> 
>

---

From: Hidetoshi Yokota <[email-masked]>
Date: Wed, 03 Oct 2007 11:34:05 +0900

Hi all,

> Do we know any protocol that has such restriction on it?

This is a good point. We have found several ways to resolve this issue 
like a virtual interface as Sri once suggested. It may be a good idea to 
address the implication of multi-interfaces, but the base document 
should not restrict how to use this protocol. As a side note, 3GPP and 
3GPP2 are expecting to use PMIPv6 for inter-technology handover as well 
as intra-technology handover, so don't let them down:-)

Regards,
-- 
Hidetoshi

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 03 Oct 2007 11:17:39 +0200

[email-masked] wrote:
> think the base spec should be as simple as possible and not trying to
> tackle every possible feature there is like the multihoming part. 
> identifier per interface granularity if it is needed to assure that
> every interface gets their own prefix. After all the mobile node's
> identifier that is used in PBUs gets managed on network side - it
> does not need to be the same the mobile thinks as of its own
> identity. And still the mobile would use only one identity for
> authentication purposes (if so desired). The backend (not necessarily
> LMAs) can do the required mapping and coordination between
> identities, if needed and so desired.
> 

Jouni, but PBU contains NAI right now, nothing else: "The local mobility
anchor MUST identify the mobile node from the identifier present in the
NAI option [RFC-4283] of the Proxy Binding Update request."

How can the MAG distinguish and make different NAIs for the same MN, out
of which identifier coming from MN?

Do you think this could be left out of the specification too?

Alex

> 
> My 0.014€, Jouni
> 
> 
>> -----Original Message----- From: Sri Gundavelli
>> [mailto:[email-masked]] Sent: Tuesday, October 02, 2007 10:48
>> PM To: 'Soininen Jonne (NSN - FI/Espoo)'; [email-masked] Subject:
>> RE: [netlmm] Way forward on PMIP multihoming discussion
>> 
>> 
>> Hi Jonne,
>> 
>> Thanks for trying to close this thread, appreciate it. Please see
>> inline.
>> 
>> 
>> 
>>> -----Original Message----- From: Soininen Jonne (NSN - FI/Espoo)
>>> 
>> [mailto:[email-masked]]
>>> Sent: Tuesday, October 02, 2007 12:28 PM To: [email-masked] 
>>>  mailing list on last couple of days. Perhaps the discussion has
>>> now entered the state where there isn't a clear way forward
>>> anymore.
>>> 
>>> is out of scope of this document and 2) stating that multihoming
>>> is not allowed for PMIP.  I hope I got this right.
>>> 
>>> A handover involving a change in the MN's network interface is
>>> not supported by this version of PMIP. Hence, a network
>> implementing PMIP
>> I think, this text goes even beyond multi-homing (simultaneous
>> access) and restricts inter-access handoffs as well even when doing
>> single interface attachments at any point of time.
>> 
>> I do not think, we should apply any restrictions. Clearly IMO,
>> there are only 3 or 4 people in the working group, who wants this
>> restriction. We should do a consensus call and move forward. I
>> believe, 99% of the WG do not want this restriction and we can
>> check that. The text we provided on this issue IMO is sufficient, 
>> Regards Sri
>>> _______________________________________________ netlmm mailing
>>> list [email-masked] 
>> ------------------------------------------------------------------------
>> 
>>

---

From: <[email-masked]>
Date: Wed, 3 Oct 2007 15:59:25 +0200

Alex,

See inline.

> From: Alexandru Petrescu [mailto:[email-masked]] 
> Sent: Wednesday, October 03, 2007 12:18 PM
> To: Korhonen, Jouni /TeliaSonera Finland Oyj
> Cc: [email-masked]; [email-masked]; [email-masked]
> > identifier that is used in PBUs gets managed on network 
> side - it does 
> > not need to be the same the mobile thinks as of its own 
> identity. And 
> > still the mobile would use only one identity for authentication 
> > purposes (if so desired). The backend (not necessarily
> Jouni, but PBU contains NAI right now, nothing else: "The 
> local mobility anchor MUST identify the mobile node from the 
> identifier present in the NAI option [RFC-4283] of the Proxy 
> Binding Update request."

I did not mean we would get rid of NAI. That is still needed.

> How can the MAG distinguish and make different NAIs for the 
> same MN, out of which identifier coming from MN?

Say, the MN has to do some EAP-based authentication with
identity privacy enabled before it can attach to PMIP domain.
The MAG acts as an authenticator. In this situation all MAG
knows about the MN is its link layer identifier (different on
each physical interface) and the realm where to forward
subsequent AAA requests. Obviously I assume now that an AAA
backend exists.

During auth the MAG includes the unique link layer identifier
to AAA req. As a result of successful auth the AAA returns a
pseudo identity to the MAG that the AAA somehow came up with
using the provided link layer identifier and MN's real identity
(that is known by the AAA). With this info MAG can construct a
NAI, which then can be put into PBU. This was one example..

> Do you think this could be left out of the specification too?

Current text in -06 says:

   o  The identifier of the mobile node that the mobile access gateway
      obtains as part of the access authentication or from the notified
      network attachment event, can be a temporary identifier and this
      identifier may also change at each re-authentication.  However,
      the mobile access gateway MUST be able to authenticate the mobile
      node based on this identifier and MUST be able to obtain the MN-
      Identifier from the policy store, such as from the RADIUS
      attribute, Chargeable-User-Identifier.

which fits my example above. So no changes needed in current text.

My 0.014€,
	Jouni

> >> [mailto:[email-masked]] Sent: Tuesday, October 02, 
> 2007 10:48 PM 
> >> To: 'Soininen Jonne (NSN - FI/Espoo)'; [email-masked] Subject:
> IMO, there 
> >> are only 3 or 4 people in the working group, who wants this 
> >> believe, 99% of the WG do not want this restriction and we 
> can check 
> >> that. The text we provided on this issue IMO is sufficient, it 
> >> documents the behavior clearly and provides the required guidance.
> >> 
> >> Regards Sri
> >> 
> >> 
> >>