Subject: [netlmm] Proposal for going forward on the multihoming issue

From: "Soininen Jonne (NSN FI/Espoo)" <[email-masked]>
Date: Wed, 03 Oct 2007 02:53:12 +0300

Hello everybody,

I discussed with Vidya and we came up with a way forward:

1) Vidya has asked for outside-NETLMM expert opinions about the topic.

2) We will wait until Friday to get answers back from these outside experts.
The results will be then posted on the mailing list for discussion.

3) If the discussion starting on Friday does not result to consensus a
consensus call will be held. I will do the consensus call. This way Vidya
can contribute fully to the technical discussion as technical contributor.
The solution picked will be included in the draft. If there is still an
objection to the consensus it will be noted and the objection will be noted
and the sheparding write-up can carry the objection and issue description.

I will not take any part in the technical discussion on this topic and thus,
I won't try to influence the discussion in the WG.

Vidya will also write up her text proposal for possible inclusion in the
draft. This way everybody will know exactly what is proposed from that camp.
I guess we have a proposal from the other camp, but if the people want to
update it, please, feel free to do so. However, I hope we can wait with the
discussion until Friday.

I hope we can concentrate now on other open topics until Friday. This allows
us to get the doc ready otherwise and to move forward to WGLC as soon as we
have solved this issue.

Cheers,

Jonne.

PS. I wanted to tell everybody what is my take on the issue. I don't
personally feel very strongly about the topic, but I would be happy to just
to declare this out-of-scope. So, now you know my opinion, which should help
you to keep me honest during this process!
-- 
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: Christian Vogt <[email-masked]>
Date: Wed, 03 Oct 2007 22:53:07 +0300

Folks,

after being away from email for a while and doing my best to catch up on 
this thread, I arrived at the following conclusion.

There is consensus that simultaneous use of the same home address on two
interfaces of a mobile host is unacceptable because neither the current
P-MIPv6 spec nor a standard-IPv6 host would be able to handle this.  The 
open question is whether it is OK for a mobile host to use different
home addresses from the same home prefix on multiple interfaces.

Two options:

(1) Permit the use of home addresses from the same home prefix on
multiple interfaces.  This is what the current P-MIPv6 spec does due to
its use of the per-mobile-host home prefix model.

The current approach will work in most multi-homing cases because the 
probability that standard IPv6 address configuration mechanisms will 
produce a home address collision -- and therefore lead to use of the 
same home address on more than one interface -- is negligible.  OTOH, 
the current approach creates a multi-link subnet, albeit a 
mobile-host-internal one without the issues described in RFC 4903.

(2) Move from the per-mobile-host home prefix model to a per-interface
home prefix model.  This would eliminate home address collisions.  It
would also avoid multi-link subnets and hence better conform with IPv6.

Moving to the per-interface prefix model will be a substantial change
conceptually.  But the number of technical changes required to the
current spec may actually be small.  The most important change would be
a mechanism to bind a home prefix to an interface, e.g., by replacing
the mobile host ID by an interface ID, which may be an IEEE MAC address.

Both options leave room for future P-MIPv6 extensions to enable
cross-interface mobility, in which case a home address is moved between
interfaces of a mobile host.  The question is how smoothly such 
extensions will function without support on the mobile host.

My personal opinion is that we should adopt a per-interface home prefix
model for P-MIPv6 because this will lead to a cleaner protocol.  I am
aware that such a move will imply new work for the spec authors, and I 
wish we had discussed this earlier than right before last call...

- Christian

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Wed, 3 Oct 2007 13:11:53 -0700

Hi Christian,
I completely agree with your conclusion.  This is along the lines of
what I suggested earlier on the list and also along the lines of what
Erik has indicated in his response (which I just posted to the list).  

I don't think the spec changes are huge in using a per-interface ID for
prefix assignment.  We need to figure out what that ID is going to be.
It appears that there is a concern with making that an L2 address and
there were some proposals for using the LLA.  But, I'm still not sure if
LLAs over multiple interfaces can be guaranteed to be unique, given that
we have adopted the point-to-point link model.  For e.g., if a host did
DAD for its LLA on one interface, no entity will perform proxy-ND for
that and so, the duplicate (on the other interface) won't be detected -
am I missing something here? 

A few comments inilne on your option 1.  

> -----Original Message-----
> From: Christian Vogt [mailto:[email-masked]] 
> Sent: Wednesday, October 03, 2007 12:53 PM
> To: [email-masked]
> Cc: Soininen Jonne (NSN FI/Espoo); Narayanan, Vidya
> Subject: Per-Mobile-Host or Per-Interface Home Prefix? (Re: 
> [netlmm] Proposal for going forward on the multihoming issue)
> 
> Folks,
> 
> after being away from email for a while and doing my best to 
> catch up on this thread, I arrived at the following conclusion.
> 
> There is consensus that simultaneous use of the same home 
> address on two interfaces of a mobile host is unacceptable 
> because neither the current
> P-MIPv6 spec nor a standard-IPv6 host would be able to handle 
> this.  The open question is whether it is OK for a mobile 
> host to use different home addresses from the same home 
> prefix on multiple interfaces.
> 
> Two options:
> 
> (1) Permit the use of home addresses from the same home 
> prefix on multiple interfaces.  This is what the current 
> P-MIPv6 spec does due to its use of the per-mobile-host home 
> prefix model.
> 
> The current approach will work in most multi-homing cases 
> because the probability that standard IPv6 address 
> configuration mechanisms will produce a home address 
> collision -- and therefore lead to use of the same home 
> address on more than one interface -- is negligible.  OTOH, 

The concern I had above about DAD may be applicable here too.  Also, in
the case of IPv4 support, we are assigning addresses and not prefixes.
So, it appears to me that we'll have to resort to option 2 below for
IPv4, even if we decided to do the above for v6.  

Thanks,
Vidya

> (2) Move from the per-mobile-host home prefix model to a 
> per-interface home prefix model.  This would eliminate home 
> address collisions.  It would also avoid multi-link subnets 
> and hence better conform with IPv6.
> 
> Moving to the per-interface prefix model will be a 
> substantial change conceptually.  But the number of technical 
> changes required to the current spec may actually be small.  
> The most important change would be a mechanism to bind a home 
> prefix to an interface, e.g., by replacing the mobile host ID 
> by an interface ID, which may be an IEEE MAC address.
> 
> Both options leave room for future P-MIPv6 extensions to 
> enable cross-interface mobility, in which case a home address 
> is moved between interfaces of a mobile host.  The question 
> is how smoothly such extensions will function without support 
> on the mobile host.
> 
> My personal opinion is that we should adopt a per-interface 
> home prefix model for P-MIPv6 because this will lead to a 
> cleaner protocol.  I am aware that such a move will imply new 
> work for the spec authors, and I wish we had discussed this 
> earlier than right before last call...
> 
> - Christian
> 
> 
> > consensus call will be held. I will do the consensus call. This way 
> > Vidya can contribute fully to the technical discussion as 
> technical contributor.
> > The solution picked will be included in the draft. If there 
> is still 
> > an objection to the consensus it will be noted and the 
> objection will 
> > be noted and the sheparding write-up can carry the 
> objection and issue description.
> > 
> > I will not take any part in the technical discussion on 
> this topic and 
> > thus, I won't try to influence the discussion in the WG.
> > 
> > Vidya will also write up her text proposal for possible 
> inclusion in 
> > the draft. This way everybody will know exactly what is 
> proposed from that camp.
> > I guess we have a proposal from the other camp, but if the 
> people want 
> > to update it, please, feel free to do so. However, I hope 
> we can wait 
> > with the discussion until Friday.
> > 
> > I hope we can concentrate now on other open topics until 
> Friday. This 
> > allows us to get the doc ready otherwise and to move 
> forward to WGLC 
> > as soon as we have solved this issue.
> > 
> > Cheers,
> > 
> > Jonne.
> > 
> > personally feel very strongly about the topic, but I would 
> be happy to 
> > just to declare this out-of-scope. So, now you know my 
> opinion, which 
> > should help you to keep me honest during this process!
> 
> 
> 
> 
>

---

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

Christian,

[snip]

> Sent: 3. lokakuuta 2007 22:53
>

Imho the current text in -06 is already very close to per
interface prefix stuff, actually more or less allowing it.
E.g. the text in section 6.6 would not need too much
clarifications.

> by an interface ID, which may be an IEEE MAC address.

I would be reluctant to define exactly what is the "per interface ID"
and how the MAG comes up with one. That belongs to system design
territory. It is more important to specify what are the properties
of that ID.

[snap]

Cheers,
	Jouni

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 03 Oct 2007 18:59:33 -0700

> the mobile host ID by an interface ID, which may be an IEEE MAC address.

How do you generate the interface ID? We can't assume there exists one 
all the time. Morever, how do you guarantee it is unique across 
interfaces if it is generated?

Also, note that the MN-ID is used for authorization at the LMA. So it 
needs to be carried in the Proxy BU.

Vijay

---

From: Basavaraj Patil <[email-masked]>
Date: Wed, 03 Oct 2007 23:38:14 -0500

Hi Christian,

On 10/3/07 2:53 PM, "ext Christian Vogt" <[email-masked]>
wrote:

> P-MIPv6 spec nor a standard-IPv6 host would be able to handle this.

We concluded that the interfaces would not really have the same address
assigned to them. So even if the same prefix was advertised to the MNs, the
host would generate a unique address from that prefix and hence the
addresses assigned to the interfaces would not be duplicate. Hence the
problem of duplicate addresses assigned to the interfaces does not exist.

> The 

An MN which is multi-homed and connected via MAGs to the same LMA will have
different home addresses from the same home prefix. Please refer to Vidya's
scenario description for the actual issue.

> mobile-host-internal one without the issues described in RFC 4903.

True.

> model for P-MIPv6 because this will lead to a cleaner protocol.

The choice of whether the same home prefix or a different prefix for each
interface is assigned should be made by an LMA which may have the capability
to be aware of an MNs capability to deal with the same prefix being
delivered to multiple interfaces. I don't think we want to go on the path of
unique prefixes for each interface at this time.

-Raj 

> I am

---

From: Christian Vogt <[email-masked]>
Date: Thu, 04 Oct 2007 10:28:37 +0300

Vidya:

> we have adopted the point-to-point link model.

You are right.  Configuring the same link-local address on interfaces 
that attach to different links is both feasible and possible.  So a 
link-local address as such cannot function as a unique interface ID.

My suggestion to use a link-layer (MAC) address as an interface ID was 
merely an example for illustration purpose.  Many other possibilities 
exist.  One of them is for a MAG to derive an interface ID by using 
technology-specific information from the link layer.

More generally, I believe that the definition of the interface ID can be 
deployment-specific, and the retrieval of the interface ID during 
mobile-node attachment is a matter of the mobile-node/MAG interface.

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Thu, 04 Oct 2007 10:39:12 +0300

> E.g. the text in section 6.6 would not need too much

Section 6.6 is IMO the most important part of the spec to change.

> territory. It is more important to specify what are the properties

Absolutely, I agree (as pointed out in my previous email to Vidya).

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Thu, 04 Oct 2007 10:55:12 +0300

> needs to be carried in the Proxy BU.

The MN-ID is currently used for both, authentication/authorization and 
mobility support (i.e., routing of the mobile node's packets).

We have seen that providing mobility support at the host level leads to 
issues when the host is multi-homed because the host's multiple 
attachment points can then no longer be tracked by a single MN-ID.

To eliminate the issues related to multi-homing, I have proposed to 
adopt the per-interface home prefix model.  Each attachment point of a 
mobile node will then be tracked by its own interface ID.

Mobility support is orthogonal to authentication/authorization, though. 
  It would be perfectly feasible to continue using the MN-ID for the 
latter, while using interface IDs for the former.  The alternative would 
be to use interface IDs for both, mobility support and 
authentication/authorization.  I don't have a strong opinion on this.

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Thu, 04 Oct 2007 11:04:50 +0300

> problem of duplicate addresses assigned to the interfaces does not exist.

Don't get me wrong.  The current spec does not have a problem with home 
address duplicates.  I was stating that there is common ground on this 
specific aspect -- to clarify my argumentation in the rest of my email.

- Christian

---

From: Shinta Sugimoto <[email-masked]>
Date: Thu, 04 Oct 2007 21:18:11 +0900

Hi Christian and all,

I think this is a good summary of the issue and I also think
that assigning unique prefix for each interface is good way
to go to support multihomed mobile node (a node with multiple
network interfaces).

I have one clarifying question though.  Does the current
PMIPv6 draft (-06) allow mobile node to be multihomed
with a single interface?  Sorry, if this question has already
been raised/clarified.
I mean, there might be a scenario where multiple home
network prefixes are assigned to a mobile node, possibly by
different LMAs.  In such case, home network emulation to be
done by the MAG works just fine?  I assume yes.

Regards,
Shinta

---

From: "Kalin Getov" <[email-masked]>
Date: Thu, 04 Oct 2007 15:57:32 +0200

Hi Christian,

please see inline...

> the current approach creates a multi-link subnet

[KG] Yes, unless care is taken so, that this is only a temporary state...LMA could start detach procedure with one of the two MAGs...

, albeit a 
> the mobile host ID by an interface ID, which may be an IEEE MAC address.
 
[KG] Yes, but this would automatically restrict a PMIP domain within only one technology(interface), since interface change would require IP address change also. As I see it, the question is if to restrict inter-interface handover or simultaneous connections to the same PMIP domain over different interfaces. As PMIP tries to emulate a home network for the MN, I think it is natural, that it is not capable of saying: "You are at home over Interface 1 AND you are at home over Interface 2", where is the benefit of making this? I think it is better to restrict MN to have only one connection to a given PMIP domain at a time and this should be the way to solve the multihoming issue.

Regards,
Kalin

-- 
******************************************
Best Regards
Kalin Getov

[email-masked]
******************************************

Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kanns mit allen: http://www.gmx.net/de/go/multimessenger

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 4 Oct 2007 07:17:08 -0700

Hi Shinta,

> done by the MAG works just fine?  I assume yes.

No. There is a 1:1 relation between a LMA and a MN. 

Sri

---

From: "Tsirtsis, George" <[email-masked]>
Date: Thu, 4 Oct 2007 07:43:24 -0700

-----Original Message-----
From: Kalin Getov [mailto:[email-masked]] 
Sent: Thursday, October 04, 2007 2:58 PM
To: Christian Vogt
Cc: [email-masked]
Subject: Re: Per-Mobile-Host or Per-Interface Home Prefix? (Re: [netlmm]Proposal for going forward on the multihoming issue)

  Hi Christian,

please see inline...

GT> As far as I can tell the detach procedure defined in Fig3 of v06 is initiated by the MAG. The protocol does not currently have a detach procedure that can be initiated by the LMA. Am I missing something?

, albeit a 

GT> If the scope of a PMIP domain is not that of a single technology, then how can an MN know which accesses/technologies/networks are or are not part of the same PMIP domain, so that it does not connect to it over two interfaces?

Regards
George 

Regards,
Kalin

[email-masked]

---

From: Christian Vogt <[email-masked]>
Date: Thu, 04 Oct 2007 19:04:40 +0300

> No. There is a 1:1 relation between a LMA and a MN. 

Right.  A mobile node's policy profile includes only one LMA's IP address, and
PBU and PBA messages contain at most one home prefix.

- Christian

---

From: Shinta Sugimoto <[email-masked]>
Date: Fri, 05 Oct 2007 01:07:58 +0900

On Thu, 4 Oct 2007 07:17:08 -0700

> No. There is a 1:1 relation between a LMA and a MN. 

Hi Sri,

Thanks for your reply.  May I ask why it is not supported?
Is it because outside the scope?  Or is there any flaw?

In plain IPv6, a host may assign multiple IP addresses
to a single interface under a multihomed environment.

In PMIPv6, the mobility service provided should be
transparent to the MN, if I understand it correctly.
That is, a MN should not care about its mapping to
specific LMA.  So, I assume that it should be logical
that multiple LMAs serve for a MN.  I don't consider
it 1:N relation between a LMN and a MN but rather I
see it as multiple sets of 1:1 relation between a
LMA and the MN.  Does this make sense?

FYI, in Mobile IPv6, some implementation allows a mobile
node to have multiple home addresses.  RFC 3775 does not
prohibit a MN from enojoying multiple home addresses.
In such a case, binding management of each home address
is maintained independently each other.

Regards,
Shinta

---

From: Shinta Sugimoto <[email-masked]>
Date: Fri, 05 Oct 2007 01:16:34 +0900

On Thu, 04 Oct 2007 19:04:40 +0300

> PBU and PBA messages contain at most one home prefix.

Is it stated somewhere in the spec that a mobile node should
have a single policy profile?  I agree that in a policy profile
there should be a single LMA and a single home network prefix
is associated with it.  But I don't see why a mobile node
cannot have multiple policy profiles at a time.

I am not saying that PBU/PBA should contain multiple home
prefixes.  I assume that MAG handles each PBU/PBA exchanges
separately.  That is, each PBU/PBA contains a single multiple
home prefix as usual.

Regards,
Shinta

---

From: "Sri Gundavelli" <[email-masked]>
Date: Thu, 4 Oct 2007 09:27:20 -0700

Hi Shinta, 

> From: Shinta Sugimoto [mailto:[email-masked]] 
> Sent: Thursday, October 04, 2007 9:08 AM
> To: Sri Gundavelli
> Cc: 'Christian Vogt'; [email-masked]
> Subject: Re: Per-Mobile-Host or Per-Interface Home Prefix? 
> (Re: [netlmm]Proposal for going forward on the multihoming issue)
> 

Its outside the scope of the base document.

> LMA and the MN.  Does this make sense?

This is a good point. But, this requires the MAG to
refer to the specific profile and contact the serving
HA. IMO, this is an advanced scenario.

> is maintained independently each other.

There is a difference though. Multiple HNP's vs multiple
LMA's serving the mobile node at the same point of time.
Although, we dont explicitly talk about multiple HNP's,
from the same LMA, but, implementations can always achieve
that. I think, in general these should be part of some
extension documents. Each of this feature comes with a
baggage and delays the base document.

Sri

---

From: <[email-masked]>
Date: Thu, 4 Oct 2007 19:04:42 +0200

[snip]

> > That is, a MN should not care about its mapping to specific 
> > LMA.  So, I assume that it should be logical that multiple LMAs
serve 
> > for a MN. I don't consider it 1:N relation between a LMN and a MN
but 
> > rather I see it as multiple sets of 1:1 relation between a LMA and
the MN.  
> > Does this make sense?
> 
> This is a good point. But, this requires the MAG to refer to 
> the specific profile and contact the serving HA. IMO, this is 
> an advanced scenario.

This is a viable real life scenario with laptops. E.g. each
wireless interface may be bundled with a subscription and there
is _no_ way to ensure that each subscription is for the same
operator (and not all operators have roaming with everyone).

[snap]

> documents. Each of this feature comes with a baggage and 
> delays the base document.

Second that.

Cheers,
	Jouni

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Thu, 4 Oct 2007 12:48:18 -0700

Agreed.  The protocol only needs to mandate a prefix per interface model
- how the interface specific ID is obtained at the MAG is not important
(except for providing hints maybe).  This also doesn't preclude having
virtual interfaces that hide multiple physical interfaces - the ID used
in PMIP will then be specific to that virtual interface instead of each
physical interface. 

Vidya 

> Sent: Thursday, October 04, 2007 12:29 AM
> To: Narayanan, Vidya
> Cc: [email-masked]; Soininen Jonne (NSN FI/Espoo)
> (Re: [netlmm] Proposal for going forward on the multihoming issue)
> 
> Vidya:
> 
> > there were some proposals for using the LLA.  But, I'm 
> still not sure 
> > if LLAs over multiple interfaces can be guaranteed to be 
> unique, given 
> > that we have adopted the point-to-point link model.
> 
> You are right.  Configuring the same link-local address on 
> interfaces that attach to different links is both feasible 
> and possible.  So a link-local address as such cannot 
> function as a unique interface ID.
> 
> My suggestion to use a link-layer (MAC) address as an 
> interface ID was merely an example for illustration purpose.  
> Many other possibilities exist.  One of them is for a MAG to 
> derive an interface ID by using technology-specific 
> information from the link layer.
> 
> More generally, I believe that the definition of the 
> interface ID can be deployment-specific, and the retrieval of 
> the interface ID during mobile-node attachment is a matter of 
> the mobile-node/MAG interface.
> 
> - Christian
> 
>

---

From: Christian Vogt <[email-masked]>
Date: Fri, 05 Oct 2007 08:54:08 +0300

> cannot have multiple policy profiles at a time.

Shinta,

this scenario is not directly supported by base P-MIPv6 because the spec 
does not specify how a MAG would retrieve and handle multiple policy 
profiles for a particular mobile host.  OTOH, there isn't anything that 
would prevent a P-MIPv6 extension from accomplishing just that.

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Fri, 05 Oct 2007 08:55:17 +0300

> This also doesn't preclude having virtual interfaces that hide
> multiple physical interfaces - the ID used in PMIP will then be
> specific to that virtual interface instead of each physical
> interface.

Right.
- Christian

---

From: Shinta Sugimoto <[email-masked]>
Date: Fri, 05 Oct 2007 15:47:31 +0900

Hi Sri,

Thanks for your reply. please find my comments inline.

On Thu, 4 Oct 2007 09:27:20 -0700

> Its outside the scope of the base document.

Ok.

> HA. IMO, this is an advanced scenario.

Ok.

> that.

Ok, I see.  That's what I wanted to clarify.
So, nothing prevents a MN from being served by multiple
LMAs at a time.

> I think, in general these should be part of some

Yes, I understand.  I am not suggesting to add new texts
describing the scenairo.

Regards,
Shinta

---

From: Shinta Sugimoto <[email-masked]>
Date: Fri, 05 Oct 2007 15:50:28 +0900

On Fri, 05 Oct 2007 08:54:08 +0300

Hi Christian,

Yes, the above is exactly the same as what I assume.  Thanks for the
clarification.

Regards,
Shinta

---

From: "Kalin Getov" <[email-masked]>
Date: Fri, 05 Oct 2007 09:22:58 +0200

Hi George,

my comments are inline...

> [KG] Yes, unless care is taken so, that this is only a temporary
> state...LMA could start detach procedure with one of the two MAGs...
> 
> GT> As far as I can tell the detach procedure defined in Fig3 of v06 is
> initiated by the MAG. The protocol does not currently have a detach procedure
> that can be initiated by the LMA. Am I missing something?

[KG] No it is so, but the idea was if it could be done from LMA side also...

> [KG] Yes, but this would automatically restrict a PMIP domain within only
> one technology(interface), since interface change would require IP address
> change also. As I see it, the question is if to restrict inter-interface
> handover or simultaneous connections to the same PMIP domain over different
> interfaces. As PMIP tries to emulate a home network for the MN, I think it
> is natural, that it is not capable of saying: "You are at home over
> Interface 1 AND you are at home over Interface 2", where is the benefit of making
> this? I think it is better to restrict MN to have only one connection to a
> given PMIP domain at a time and this should be the way to solve the
> multihoming issue.
> 
> GT> If the scope of a PMIP domain is not that of a single technology, then
> how can an MN know which accesses/technologies/networks are or are not
> part of the same PMIP domain, so that it does not connect to it over two
> interfaces?

[KG] As far as I know, the MN doesn't know anything, the MAG must decide if PMIP is executed or not (unchanged IP stack on MN)

Thanks,
Kalin

> > > update it, please, feel free to do so. However, I hope we can wait
> with
> > the
> > > discussion until Friday.
> > > 
> > > us to get the doc ready otherwise and to move forward to WGLC as soon
> as
> > we
> > > have solved this issue.
> > > 
> > > Cheers,
> > > 
> > > Jonne.
> > > 
> > > to declare this out-of-scope. So, now you know my opinion, which
> should
> > help

[email-masked]

Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser

---

From: Marco Liebsch <[email-masked]>
Date: Fri, 05 Oct 2007 10:32:09 +0200

Hi Vidya, all,

I am not sure if the base protocol should be specific to that at all.
I think the specification should provide a flexible framework around
IDs and leave the details to the particular system, where PMIPv6 might
be integrated.

In my opinion we should provide both, an option for the MNID, which can
carry a NAI and being unique for the mobile/user, as well as interface
specificidentifiers. Interface ID options could be specified according
to a generic format, which can identify the techno type and possibly
the MAC address. Reason is that this might also help to detect and
support inter-technology handover at the LMA. For multi-homing it's
useful anyway.

Regarding same or different home prefix, I think the base spec should
not care too much about this. Scenarios where multiple interface on
a mobile use the same address (same HNP + same suffix) can be very
useful and should not be precluded by the base spec.

marco

Narayanan, Vidya wrote:
>>> It appears that there is a concern with making that an L2 
>>>       
>> address and 
>>

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 05 Oct 2007 10:53:54 +0200

>> specific to that virtual interface instead of each physical

You mean NAI, right?  There's nothing else in PMIP PBU.

Alex

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

---

From: Marco Liebsch <[email-masked]>
Date: Fri, 05 Oct 2007 10:25:36 +0200

Hi Vidya, all,

In my opinion we should provide both, an option for the MNID, which can
carry a NAI and being unique for the mobile/user, as well as interface
specific
identifiers. Interface ID options could be specified according to a generic
format, which can identify the techno type and possibly the MAC address.
Reason is that this might also help to detect and support inter-technology
handover at the LMA. For multi-homing it's useful anyway.

marco

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Fri, 5 Oct 2007 02:07:38 -0700

Hi Marco,

> From: Marco Liebsch [mailto:[email-masked]]
> Sent: Friday, October 05, 2007 10:32 AM
> To: Narayanan, Vidya
> Cc: Christian Vogt; [email-masked]
(Re:[netlmm]
> Proposal for going forward on the multihoming issue)
> 
> Hi Vidya, all,
> 

I think the base protocol should be specific about the scope of the HNP
and PMIP session (i.e. if it is per interface or per node).

If you are referring to the definition of interface IDs, then I agree
PMIPv6 base protocol should not define them. 

> specific identifiers. 

I think there were some comments earlier in the list that the MNID may
be needed anyway for authorization at the LMA. So it may be possible
that the PBU carries two IDs, one tied to an interface for the binding
processing and one tied to the MN for authorization purposes

What we need to understand and we are discussing here is if the ID used
for the binding processing should be per-interface or per-node. I think
the proposal by Christian that the HNP is per-interface and the ID for
binding processing is per-interface is the correct one. 

> Interface ID options could be specified according

Can you elaborate further please? 

I tend to agree with Jouni that interface IDs should be system specific
and not defined by IETF. However, I would like to understand better your
point.

> useful and should not be precluded by the base spec.

I disagree. The base spec should be clear about this (whatever will be
decided by consensus) and should not leave the HNP assignment open.

Which scenarios are you referring to?

Ciao
Gerardo

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 5 Oct 2007 13:28:52 +0300

> be needed anyway for authorization at the LMA. 

As I explained earlier, the way it is defined in the spec, MN-Id does not
help with authorization. "MN-id" is not associated with an proof that "MN"
is really there. 

The real authorization is for the "MAG" to have the right to receive traffic
destined for the HNP. 

Alper

> So it may be possible

---

From: "DE JUAN HUARTE FEDERICO" <[email-masked]>
Date: Fri, 5 Oct 2007 14:34:42 +0200

Hi,

Vidya> The protocol only needs to mandate a prefix per interface model

Why mandate? I can agree to enabling the functionality, so that a given deployment can use it if so wanted
But if we are talking about mandating it, then we'd have to take a deep dive in the multihoming discussion

Regards

federico

-----Message d'origine-----
De : Narayanan, Vidya [mailto:[email-masked]] 
Envoyé : jeudi 4 octobre 2007 21:48
À : Christian Vogt
Cc : [email-masked]
Objet : RE: Per-Mobile-Host or Per-Interface Home Prefix? (Re: [netlmm]Proposal for going forward on the multihoming issue)

Agreed.  The protocol only needs to mandate a prefix per interface model
- how the interface specific ID is obtained at the MAG is not important (except for providing hints maybe).  This also doesn't preclude having virtual interfaces that hide multiple physical interfaces - the ID used in PMIP will then be specific to that virtual interface instead of each physical interface. 

Vidya 

> merely an example for illustration purpose.
> Many other possibilities exist.  One of them is for a MAG to derive an 
> interface ID by using technology-specific information from the link 
> layer.
> 
> More generally, I believe that the definition of the interface ID can 
> be deployment-specific, and the retrieval of the interface ID during

---

From: Jari Arkko <[email-masked]>
Date: Fri, 05 Oct 2007 16:28:31 +0300

Marco,

> IDs and leave the details to the particular system, where PMIPv6 might

Yes. But see below.

> useful and should not be precluded by the base spec.

I think it is important to allow different deployments. Obviously
e.g., requiring specifically IEEE MAC identifiers would be
wrong.

However, if we leave things such as whether multiple (IP) interfaces
use the same or different prefix open then I think we owe it to
readers to define what the implications are. When does this work?
When does it not work?

Jari

---

From: "Tsirtsis, George" <[email-masked]>
Date: Fri, 5 Oct 2007 06:50:05 -0700

On the contrary, I think the prefix per interface model successfully clarifies and overcomes the multi-homing issue.

It clarifies it, because when a mobile knows nothing about PMIP (unchanged end-node), each of the mobile's interfaces, identified by different interface IDs, create a separate PMIP session. This guaranties PMIP's compatibility with unchanged hosts and even hosts with multi-homing capabilities.

It overcomes it, because it allows a mobile with a Virtual Interface (PMIP aware end-node) to utilize multiple physical interfaces under the same PMIP domain, as long as the Interface ID can be made to correspond to the Virtual Interface rather than any if the physical interfaces. How this is done becomes out of scope of the base specification, and the responsibility of 3rd party SDOs and/or future NETLMM work.

George

-----Original Message-----
From: DE JUAN HUARTE FEDERICO [mailto:[email-masked]] 
Sent: Friday, October 05, 2007 1:35 PM
To: Narayanan, Vidya; Christian Vogt
Cc: [email-masked]
Subject: RE: Per-Mobile-Host or Per-Interface Home Prefix? (Re:[netlmm]Proposal for going forward on the multihoming issue)

Hi,

Regards

federico

-----Message d'origine-----
De : Narayanan, Vidya [mailto:[email-masked]] 
Envoyé : jeudi 4 octobre 2007 21:48
À : Christian Vogt
Cc : [email-masked]
Objet : RE: Per-Mobile-Host or Per-Interface Home Prefix? (Re: [netlmm]Proposal for going forward on the multihoming issue)

Vidya

---

From: "Hesham Soliman" <[email-masked]>
Date: Sat, 6 Oct 2007 00:00:56 +1000

> From: DE JUAN HUARTE FEDERICO 

 > Why mandate? I can agree to enabling the functionality, so 
 > that a given deployment can use it if so wanted

=> It's a little late for this, IPv6 already requires a unique prefix per
link. I don't understand why this is surprising people in NETLMM. 

Hesham

---

From: "DE JUAN HUARTE FEDERICO" <[email-masked]>
Date: Fri, 5 Oct 2007 16:12:19 +0200

Hi Jari,

Jari> However, if we leave things such as whether multiple (IP) interfaces use the same or different prefix open then I think we owe it to readers to define what the implications are

That's fair, except that I don't see how that belongs into the base PMIP6 specification
Using a DHCP4 analogy, I don't think that DHCPv4 enters in this level of detail (same IP@ assigned or not to different chaddr)

I wonder if there's any specification that describes how a multihomed terminal is supposed to work (without PMIP6)
If we had a reference, then we could validate that PMIP6 doesn't break it (in a context out of the base specification)
Right now, all I see is loads of assumptions in all directions 

Regards

federico

-----Message d'origine-----
De : Jari Arkko [mailto:[email-masked]] 
Envoyé : vendredi 5 octobre 2007 15:29
À : Marco Liebsch
Cc : Christian Vogt; [email-masked]
Objet : Re: Per-Mobile-Host or Per-Interface Home Prefix?(Re: [netlmm] Proposal for going forward on the multihoming issue)

Marco,

Yes. But see below.

> In my opinion we should provide both, an option for the MNID, which 
> can carry a NAI and being unique for the mobile/user, as well as 
> interface specific identifiers. Interface ID options could be 
> specified according to a generic format, which can identify the techno 
> type and possibly the MAC address.
> Reason is that this might also help to detect and support 
> inter-technology handover at the LMA. For multi-homing it's useful anyway.
>
> not care too much about this. Scenarios where multiple interface on a 
> mobile use the same address (same HNP + same suffix) can be very 

I think it is important to allow different deployments. Obviously e.g., requiring specifically IEEE MAC identifiers would be wrong.

However, if we leave things such as whether multiple (IP) interfaces use the same or different prefix open then I think we owe it to readers to define what the implications are. When does this work?
When does it not work?

Jari

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 5 Oct 2007 08:17:38 -0700

All,
Please see RFC4291 for the IPv6 addressing architecture.  Section 2
states how a unicast address is an identifier for a single interface and
section 2.5.4. states how the subnet ID in a global unicast address is
an identifier of a link.  It follows that a prefix cannot span multiple
links in IPv6. 

Given that we have chosen the point-to-point link model in NETLMM,
multiple interfaces on a given MN cannot be on the same link and hence,
cannot share the same prefix.  The result is a prefix per interface
model for the purpose of this protocol.  Once we have this, it
automatically solves the issue at hand.  

Thanks,
Vidya

> From: Hesham Soliman [mailto:[email-masked]] 
> Sent: Friday, October 05, 2007 7:01 AM
> To: 'DE JUAN HUARTE FEDERICO'; Narayanan, Vidya; 'Christian Vogt'
> Cc: [email-masked]
> Subject: RE: Per-Mobile-Host or Per-Interface Home 
> Prefix?(Re:[netlmm]Proposal for going forward on the 
> multihoming issue)
> 
>  > Vidya> The protocol only needs to mandate a prefix per  > 
> interface model  >  > Why mandate? I can agree to enabling 
> the functionality, so  > that a given deployment can use it 
> if so wanted
> 
> => It's a little late for this, IPv6 already requires a 
> unique prefix per link. I don't understand why this is 
> surprising people in NETLMM. 
> 
> Hesham
> 
> 
>

---

From: Marco Liebsch <[email-masked]>
Date: Fri, 05 Oct 2007 17:54:34 +0200

Ciao Gerardo,

> and PMIP session (i.e. if it is per interface or per node).
I just think it's not appropriate to explicitly exclude that the
same HNP is assigned to different interfaces of the same mobile.
So, HNP-binding per interface is ok, but it's up to a system whether to
assign the same or different HNP to multiple interfaces of a
mobile. Base operation should have different HNP per interface.
What is a PMIP session?
> PMIPv6 base protocol should not define them. 
It would be one possibility to identify an interface of a mobile at
the LMA. I did not propose to have this in the base spec. But we should
not try to solve all identification tasks with the MNID.

> can
That's what I meant. If the MNID is for mobile/user identification,
which might serve for authentication purposes as well, then we should
consider further options (in the future) to identify a mobile's
interface/technology.

> binding processing is per-interface is the correct one. 
For the basic operation both will work, whether you anchor a binding
to a mobile or interface specific ID. If you think binding the HNP to
an interface is saver to avoid that the same HNP is assigned to different
interfaces, ok. We should just leave hooks for future extensions.
> Can you elaborate further please? 
Referring to what you summarized above, there could be more options
in a PBU to identify a mobile and its technologies. I can think about
extensions to base PMIPv6, where the LMA treats a proxy binding update
differently dependent on the access technology used by the mobile.

> and not defined by IETF. However, I would like to understand better your
But we should consider and not disallow such IDs. Even though they
might not be specified in the IETF.

> decided by consensus) and should not leave the HNP assignment open.
Ok, so we have different opinions.
> Which scenarios are you referring to?
Now we enter the scope of a different thread, which is more about
multi-homing.

Thanks,
marco

> Ciao
> Gerardo
>
>   
>> marco
>>
>>
>>
>> Narayanan, Vidya wrote:
>>     
>>> Agreed.  The protocol only needs to mandate a prefix per interface
>>>       
> model
>   
>>> - how the interface specific ID is obtained at the MAG is not
>>>       
> important
>   
>>> (except for providing hints maybe).  This also doesn't preclude
>>>       
> having
>   
>>> virtual interfaces that hide multiple physical interfaces - the ID
>>>       
> used
>   
>>> in PMIP will then be specific to that virtual interface instead of
>>>       
> each
>   
>>> physical interface.
>>>
>>> Vidya
>>>
>>>
>>>

---

From: Marco Liebsch <[email-masked]>
Date: Fri, 05 Oct 2007 18:10:23 +0200

Hi Jari,

> e.g., requiring specifically IEEE MAC identifiers would be
Yes, I get your point and I agree. I did not plan to build PMIPv6
around 802.1x MACs. I just indicated that we should consider
technology specific IDs in the future, which might impact
binding processing. The IETF should not dig into these technology
details, but could specify a generic format for such IDs.
No statement about when this could be done.
> readers to define what the implications are. When does this work?
Yes, I agree with you. Here, I am just scared about mandating
things. We should not close the door in the base spec for
useful future extensions.

Thanks,
marco

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Fri, 5 Oct 2007 09:49:04 -0700

Hi Marco,
 
> mobile. Base operation should have different HNP per interface.

I don't see the reason to assign the same HNP to different interfaces. I
think that PMIP base spec should be precise in which prefix is assigned
after a handover.

> consider further options (in the future) to identify a mobile's

Sorry I don't understand your point here. Can you clarify?

The point I was trying to make is that the identifier used for prefix
assignment and binding processing should be per interface.
If we need a MN-ID for authorization purposes, this is fine (even though
Alper made some comments on this)

> interfaces, ok. We should just leave hooks for future extensions.

What is basic operation?

I think binding the HNP to an interface is a cleaner solution and it
solves also the multihoming issue. I think this does not prevent future
extensions.  

> differently dependent on the access technology used by the mobile.

Right

> might not be specified in the IETF.

Agree. 

Gerardo

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 05 Oct 2007 11:27:14 -0700

> GT> As far as I can tell the detach procedure defined in Fig3 of v06 is initiated by the MAG. The protocol does not currently have a detach procedure that can be initiated by the LMA. Am I missing…

Thats where the revocation mechanism described in
http://www.ietf.org/internet-drafts/draft-muhanna-mip6-binding-revocation-01.txt 
would fit in, I guess.

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 05 Oct 2007 11:29:31 -0700

> think that PMIP base spec should be precise in which prefix is assigned

Are we talking about a multi-homing here or a handover scenario?

Vijay

---

From: Basavaraj Patil <[email-masked]>
Date: Fri, 05 Oct 2007 13:50:58 -0500

Hi Gerardo,

> think that PMIP base spec should be precise in which prefix is assigned

Why??? What is the issue if the same HNP were to be advertised to different
interfaces of an MN? The discussion so far has been that an interface which
does SLAAC based on the prefix in the RA will configure a unique address
(generally). So address conflict on multiple interfaces is not really an
issue.

-Raj

---

From: Jari Arkko <[email-masked]>
Date: Fri, 05 Oct 2007 21:54:26 +0300

> Right now, all I see is loads of assumptions in all directions 
Well, there are of course a number of known problems in the multihoming
space. But please do not consider it as something very special or rare.
My cell phone has eight radio interfaces some of which work independently
from an IP perspective, many capable of being authenticated using the same
subscription and NAI. I think its capable of web browsing via WLAN while
sending MMS over cellular, for instance.

And IPv6 allows to multiple interfaces  and  addresses and lets the host
decide which interface it wants to use.

Jari

---

From: "Sri Gundavelli" <[email-masked]>
Date: Sat, 6 Oct 2007 00:17:35 -0700

> From: Narayanan, Vidya [mailto:[email-masked]] 
> Sent: Friday, October 05, 2007 8:18 AM
> To: Hesham Soliman; DE JUAN HUARTE FEDERICO; Christian Vogt
> Cc: [email-masked]
> Prefix?(Re:[netlmm]Proposalfor going forward on the multihoming issue)
> 
> 
> All,

Still that is the case. The mobile node will not configure
the same unicast address on more than one interface as we discussed.

> an identifier of a link.  
> It follows that a prefix cannot span multiple links in IPv6. 

However, in RFC-3775, each node from a given home network prefix spans
multiple physical links. PMIP6 is an exension to RFC-3775.

> multiple interfaces on a given MN cannot be on the same link 
> and hence, cannot share the same prefix.  
> The result is a prefix per interface

No. Its an unwanted restriction.

Sri

---

From: "Marco Liebsch" <[email-masked]>
Date: Sat, 6 Oct 2007 16:36:36 +0200

Gerardo,

-----Original Message-----
From: Giaretta, Gerardo [mailto:[email-masked]]
Sent: Fri 10/5/2007 6:49 PM
To: Marco Liebsch
Cc: Narayanan, Vidya; Christian Vogt; [email-masked]
Subject: RE: Per-Mobile-Host or Per-Interface Home Prefix? (Re:[netlmm]	Proposal for going forward on the multihoming issue)

Ok.

>Sorry I don't understand your point here. Can you clarify?

If the MNID does not carry technology specific info but
for example a NAI, additional message options might be
needed to carry technology specific information to
convey the technology type and ID to the LMA by means
of the PBU. That's all. 

Ok.

>What is basic operation?

The scenario that the base protocol is supposed to support..
But I understand that the base spec should try to avoid running
into undesirable situations.

>solves also the multihoming issue. I think this does not prevent future

Good.

Thanks,
marco

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Sun, 7 Oct 2007 17:29:11 -0700

Hi Raj,

> (generally). So address conflict on multiple interfaces is not really
an

Sorry for not being precise in my earlier email. 

I was referring to the sentence from Marco about leaving flexibility on
the prefix to be assigned. I think the prefix to be assigned to the MN
is tied to the identifier used in the PMIP signalling. If the identifier
is per-interface as proposed recently, then the same prefix should not
be assigned.

Gerardo

---

From: "Sri Gundavelli" <[email-masked]>
Date: Mon, 8 Oct 2007 09:00:33 -0700

Hi Gerardo,

> 
> I was addressing the sentence from Marco that the specification should
> leave flexibility whether the same prefix or a different 
> prefix will be
> assigned to different interfaces. I think this may cause 
> issues, as also
> Jari mentioned. 
> 
> The point is that if the identifier used in PMIP is 
> per-interface then a
> different prefix should always be assigned to different interfaces.
> 
> Note that this does not rule out the inter-technology 
> handover scenario:
> the interface I'm referring to could be a virtual interface, if the MN
> supports such functionality.
> 

Couple of points. Host implementations can handle inter-access handoff
in multiple ways:

- Virtual interface implementation abstracting physical interfaces 
  (as DoCOMO proposed)
- Populating the same address configuration on different interfaces,
  but keeping only one interface in the active state. Swapping them
  at the time of handoff.
- Obtaining the same address configuration from DHCPv6. By using a
  Client-DUID with a common IAID which is not interface specific
  and this obtaining the same addres configuration using any physical
  interfaces.

Secondly, the MAG would not have the knowledge on the mobile's 
capability on how this is implemented. Given that, its important
we associate the prefix to the MN-Identifier, as supposed to an 
interface specific id. 

Sri

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 8 Oct 2007 11:01:30 -0700

Sri, 
A few points below.  

> From: Sri Gundavelli [mailto:[email-masked]] 
> Sent: Saturday, October 06, 2007 12:18 AM
> To: Narayanan, Vidya; 'Hesham Soliman'; 'DE JUAN HUARTE 
> FEDERICO'; 'Christian Vogt'
> Cc: [email-masked]
> > states how a unicast address is an identifier for a single 
> interface 
> > and
> 

Note that we can only say that this is typically the case.  Typically,
the end host uses some interface specific parameter in the IID
calculation and hence, the above is likely to be true.  If, however, the
host uses the same parameters for the IID generation on multiple
interfaces, DAD will not detect the duplicates here.  This is because
the MAG assumes it is a point-to-point link and will not forward the DAD
packets anywhere.  

Also, as we have discussed, just having the same prefix on multiple
interfaces is sufficient to cause unstable IP connectivity to the host. 

> multiple physical links. 

By the above, it seems to imply that RFC3775 has the multi-link subnet
issues :) There were emails on the MIP6 mailing list describing why
those issues don't apply to MIP6. 

> PMIP6 is an exension to RFC-3775.
> 

However, we already have chosen a deviation in the link and addressing
models from RFC3775 in order to avoid the multi-link subnet issues which
will apply to PMIP6, unlike the MIP6 case.  If we are now proposing a
modification there, it is a bigger issue. 

> No. Its an unwanted restriction.

It isn't and the reasons are described in a couple of emails from
Christian, George and me.  

Vidya

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 08 Oct 2007 11:07:25 -0700

>   and this obtaining the same addres configuration using any physical

I agree with this. I would appreciate it if folks stop insisting on 
implementing a virtual interface on a mobile node. It is implementation 
specific.

Vijay

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Mon, 8 Oct 2007 11:37:00 -0700

> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Monday, October 08, 2007 11:07 AM
> To: Sri Gundavelli
> Subject: Re: Per-Mobile-Host or Per-Interface HomePrefix? 
> (Re:[netlmm] Proposalfor going forward on themultihoming issue)
> 
> Sri Gundavelli wrote:
> 
> >> The point is that if the identifier used in PMIP is per-interface 
> >> then a different prefix should always be assigned to different 
> >> interfaces.
> >>
> >> Note that this does not rule out the inter-technology handover 
> >> scenario:
> >> the interface I'm referring to could be a virtual 
> interface, if the 
> >> MN supports such functionality.
> >>
> > 
> I agree with this. I would appreciate it if folks stop 
> insisting on implementing a virtual interface on a mobile 
> node. It is implementation specific.
> 

Yes, but, in all the above options, *some* changes to the MN are needed.
None of the above is referring to an unmodified host.  I think what is
being said is that in order to use the same prefix on multiple
interfaces and obtain stable IP connectivity, the MN needs to be
modified.  

Once the MN can be modified, AFAICT, the per-interface prefix model also
works. The good thing is that it works for unmodified MNs too. 

Vidya

> > capability on how this is implemented. Given that, its important we 
> > associate the prefix to the MN-Identifier, as supposed to 
> an interface 
> > specific id.
> > 
> > 
> > Sri
> 
> 
>