Subject: [netlmm] Conclusion of the discussion so far... Multihoming with PMIP

From: "Soininen Jonne (NSN FI/Espoo)" <[email-masked]>
Date: Fri, 12 Oct 2007 00:50:08 +0300

<Chair hat on>
Everybody,

We have come a long way since last week. Last week our discussion was about
deciding if we should handle the issue of multihoming by leaving it out of
scope or not. However, this week we have concentrated on the discussion, how
to solve the issue in the document. So, I believe that we are in a totally
different situation than we were a week ago: We have reached consensus to
solve the multihoming issue in the document - now the discussion is just
about what is the technical solution to solve the issue.

It seems that the solution has converged into two solutions:

(These solutions are listed in the order of proposal)

1) The editing team of the PMIP base spec have proposed text to the document
for a way forward 
(http://www1.ietf.org/mail-archive/web/netlmm/current/msg03756.html), and
further modified it with (
http://www1.ietf.org/mail-archive/web/netlmm/current/msg03863.html).

2) Christian proposed a different solution
(http://www1.ietf.org/mail-archive/web/netlmm/current/msg03764.html), which
has also gotten support on the list.

On both solutions pros and cons have been stated, and it is clear that
through e-mail discussion a consensus cannot be reached anymore.

We have to now find a way forward as this seems to be one of the few
remaining issues on the draft. I will talk to the people involved to find
out if a solution can be found, or if we would have to go to a consensus
call on the topic.

I will get back to the list with a way forward on Friday evening.

I hope this helps.

Cheers,

Jonne.  
-- 
Jonne Soininen
Nokia Siemens Networks

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

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

---

From: "Tsirtsis, George" <[email-masked]>
Date: Thu, 11 Oct 2007 17:14:15 -0700

I agree there has been significant progress and the two solutions on the
table are in fact fairly close to each other. At this point IMO the two
solutions have one issue that creates some uncertainty and one important
difference.

1) The Issue generating uncertainty:

	- Editing team's solution requires the LMA to know via "policy"
whether the same prefix can be allocated to two different access
technology interfaces. 

	- Christian's solution requires the MAG to somehow know the
Interface ID of a Virtual Interface.

It is clear that how such thing can be known is outside the scope of the
base specification and at this point in time there is some uncertainty
about whether and when the IETF will provide solutions to these issues.
It is, however, reasonable and realistic that other organizations (3GPP,
3GPP2 etc) can define how these issues can be solved within their own
systems.

IMHO, the two solutions require equivalent amount of work outside the
base specification to make PMIP work for inter-technology handoffs.

2) The important difference

	- Editing team's solution differentiates between access
technologies.
	- Christian's solution differentiates between Interfaces.

The difference between the two can be seen as a granularity difference. 

The Interface model normally recognizes individual physical interfaces.
It then allows for such physical interfaces to be explicitly grouped
under a Virtual Interface, for the purposes of inter-technology handoff.

The access technology model, only recognizes access type. The obvious
and undeniable issue with this approach is that two physical interfaces
of the same access type can not be differentiated between and are
recognized as the same thing.  

So, a host with two interfaces of the same type, attached to the same
PMIP domain is guarantied to face the multi-homing issues we are trying
to resolve with this discussion. This is clearly not the case in the
interface model, and for this reason the interface model is a superior
and more generic solution.

Conclusion
----------
Given the clear advantage of the per interface model and the fact that
both solutions have similar level of uncertainty and work to be done,
either in IETF or other SDOs, I do not understand how the Editing team's
solution can be justified.

Best Regards
George
-----Original Message-----
From: Soininen Jonne (NSN FI/Espoo) [mailto:[email-masked]] 
Sent: Friday, October 12, 2007 6:50 AM
To: 'NetLMM Mailing List'
Subject: [netlmm] Conclusion of the discussion so far... Multihoming
withPMIP

<Chair hat on>
Everybody,

We have come a long way since last week. Last week our discussion was
about
deciding if we should handle the issue of multihoming by leaving it out
of
scope or not. However, this week we have concentrated on the discussion,
how
to solve the issue in the document. So, I believe that we are in a
totally
different situation than we were a week ago: We have reached consensus
to
solve the multihoming issue in the document - now the discussion is just
about what is the technical solution to solve the issue.

1) The editing team of the PMIP base spec have proposed text to the
document
for a way forward 
(http://www1.ietf.org/mail-archive/web/netlmm/current/msg03756.html),
and
further modified it with (
http://www1.ietf.org/mail-archive/web/netlmm/current/msg03863.html).

2) Christian proposed a different solution
(http://www1.ietf.org/mail-archive/web/netlmm/current/msg03764.html),
which
has also gotten support on the list.

We have to now find a way forward as this seems to be one of the few
remaining issues on the draft. I will talk to the people involved to
find
out if a solution can be found, or if we would have to go to a consensus
call on the topic.

I hope this helps.

Cheers,

Jonne.  
-- 
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 11 Oct 2007 17:29:18 -0700

> solutions have one issue that creates some uncertainty and one important

There are a couple of more points to consider.

> 	- Editing team's solution requires the LMA to know via "policy"

"policy" or with MN involvement. It could be an administrative
decision too for a particular PMIPv6 domain.

> Interface ID of a Virtual Interface.

Not only that, we also need to transfer the interface ID between
the MAGs. The Interface ID needs to be the same across all MAGs
in a PMIPv6 domain.

> base specification to make PMIP work for inter-technology handoffs.

IMO, assigning a prefix per interface does not work for inter-access
technology handovers. So I would say it prevents the inter-access
technology handovers.

Vijay

---

From: "Tsirtsis, George" <[email-masked]>
Date: Thu, 11 Oct 2007 17:43:31 -0700

-----Original Message-----
From: Vijay Devarapalli [mailto:[email-masked]] 
Sent: Friday, October 12, 2007 9:29 AM
To: Tsirtsis, George
Cc: Soininen Jonne (NSN FI/Espoo); NetLMM Mailing List
Subject: Re: [netlmm] Conclusion of the discussion so far... Multihoming
withPMIP

GT> Vijay, all this is part of the work to be done. Whether policy is
known by telepathy or by mobile involvement, whether the VIID is moved
by teleportation or it is sent by the mobile, it is all work TBD and
contributes to uncertainty towards both solutions.

GT> Now you say such things at this point of the discussion and I do not
know what to say. I do not believe you do not understand Christian's
solution at this basic level....shame...

Vijay

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 11 Oct 2007 18:39:14 -0700 (PDT)

Hi George,

> and more generic solution.

You should bring some valid and practical use cases. We can
argue on any thing, but this is not a realistic use case.
Atleast not from you George !
Any case, the serving MAG can detect the mobile's secondary
attachment and block the access on that interface. Please
also note the FCC's 20cm rule for interference prevention,
when collocating multiple radios of same type in the same
device.

> Conclusion

I do not see a single valid argument as why this should be enforced.
I understand and believe in allowing deployments to allocate a unique
prefix for each interface. That flexibiltiy is good. But, the entire
efforts to restrict the LMA from not allocating the same prefix is
not justified.

We made sincere efforts to converge and we agreed to allow the LMA
to allocate a unique prefix for each interface, but under a policy
consideration and also leave the hook to allocate the same prefix
and you have a problem with that hook. And we are not able to converge, 
because of this one goal to prevent that flexibility. I'm sure, you
have good reasons for this, from your own point of view, but I dont
agree.

Thanks
Sri

---

From: "Tsirtsis, George" <[email-masked]>
Date: Thu, 11 Oct 2007 19:03:17 -0700

Sri/Ahmad and others...see some comments inline...
Thanks

-----Original Message-----
From: Sri Gundavelli [mailto:[email-masked]] 
Sent: Friday, October 12, 2007 10:39 AM
To: Tsirtsis, George
Cc: Soininen Jonne (NSN FI/Espoo); NetLMM Mailing List
Subject: RE: [netlmm] Conclusion of the discussion so far... Multihoming
withPMIP

Hi George,

GT> I will let that one go :-)

GT> Sri, Please do not be presumptuous about what carries an IP
interfaces. Not all internet hosts are mobile phones or even
PCs/Laptops. There are cars, trains, airplanes....hopefully anything
larger than a grain of sand some day.

GT> Also please understand that "unmodified hosts" does not mean
"existing host". Even after PMIP is an RFC and deployed in the networks.
Support for PMIP in the hosts will NOT be mandatory. So PMIPv6 will have
to work with "unmodified hosts" for ever!!!

GT> For this reason it is important the solution we provide today works
for all types of hosts modified and unmodified for the projected
lifetime of the protocol. Thus, the discussion of how "common" a case is
today for a host to have two interfaces of the same technology connected
to the network is entirely irrelevant.

GT> Having said that, in the context of 3GPP it is already possible to
connect multiple interfaces of the same and/or different technologies to
the network using the same credentials/identity via an external
SIM....there might be other valid scenarios already...but as I said
above I really do not think it matters at all.

GT> Now I am sorry to say you sound like Vijay. Do you really not
understand how Christian's proposal allows for this to happen? 

GT> Earlier on in this discussion, there was a level of denial in this
group regarding the existence of the problem. Now after a lot of effort,
this denial has been lifted but it has been replaced with denial
regarding the fact that Christian's solution also allows use of PMIPv6
Inter-technology handoff.

Thanks
Sri

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 11 Oct 2007 21:52:54 -0500

Hi George,

Please see inline.

Regards,
Ahmad

> GT> I will let that one go :-)

[Ahmad]
Thanks:-)))

> larger than a grain of sand some day.

[Ahmad]
Excellent. I agree. An airplane wireless router is supposed to serve
200-500 users. A train may serve a 1000.
My other question is the following: How many airplane are out there?

When there are very limited airplanes per operator, then I believe
configuring each of these interfaces with a different MN-ID or RT-ID is
quite very reasonable assumption. Now, if that scenario is applicable to
a wireless phone, where there are millions of them, then I understand,
configuration may become a problem. But that not the case in your
example. 

> to work with "unmodified hosts" for ever!!!

[Ahmad]
This one is tuff for me to understand, so what you are saying, an
operator currently deploy MIPv6 in its network and decides to deploy
PMIPv6 to provide a clean network mobility solution in order to save on
the cost of the handset, for example, would continue to deploy the same
handsets?

What is this called George a backward-forward-backward compatibility?

> to the network is entirely irrelevant.

[Ahmad]
WOW! I will too let this one go:-)

> above I really do not think it matters at all.

[Ahmad]
George, I am sorry I do not understand your argument above and at the
same time I am confused here!
All what I am asking for is a real example. I understand the high speed
TRAIN one; any others?