Subject: Re: [netlmm]( Link Local Addressing Semantics) Decision Taken ?

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 8 Dec 2006 12:47:47 -0800 (PST)

Hi Julien, please refer to the minutes posted at:
http://tools.ietf.org/wg/netlmm/minutes
it is long reading but worth it.

--behcet

----- Original Message ----
From: Julien Bournelle <[email-masked]>
To: Behcet Sarikaya <[email-masked]>
Cc: Julien Laganier <[email-masked]>; [email-masked]
Sent: Friday, December 8, 2006 11:39:45 AM
Subject: Re: [netlmm]( Link Local Addressing Semantics) Decision Taken ?

HI behcet,

sorry if I missed something. What 's exactly the decision that has
been taken at San Diego ?

Thanks,

Julien B.

On 12/8/06, Behcet Sarikaya <[email-masked]> wrote:
>
> Hi Julien,
>   As per the decision taken at San Diego WG meeting, we probably do not have
> to worry about MAG and LMAs any more.
>   However, we might wish to discuss what should be the new link model and I
> guess this was the reason why this thread was opened.
>   In PMIP model, MN does not get its traffic from the netLMM address but
> instead uses its HoA, what are the implications of this from the multilink
> subnet point-of-view?
>   I think that with this new model the multilink subnet is created at the
> home link and the solution (per-MN prefix) should apply to HoA and MN can
> use whatever is available in its present subnet for local address
> configuration of its CoA.
>   What do you think?
>
> --behcet
>
>
> ----- Original Message ----
> From: Julien Laganier <[email-masked]>
> To: [email-masked]
> Cc: "Templin, Fred L" <[email-masked]>
> Sent: Friday, December 8, 2006 8:56:58 AM
> Subject: Re: [netlmm] Link Local Addressing Semantics
>
>
> On Thursday 07 December 2006 20:29, Narayanan, Vidya
> wrote:
> > Fred,
>
> [...]
>
> > I think I've said this in the last couple of emails,
> > but let me try to describe it again. If the
> > link-local semantics were always p2p semantics, the
> > upper layers on the MN never have any expectations
> > on the link-local reachability of neighbors
>
> The upper layer on the MN do have an expectation on the
> link-local reachibility of the (sole) neighbor of the
> MN: its router.
>
> Two ways to avoid that in p2p model:
>
> - The default router never change, it is the LMA
> - The domain fake an unchanging default router, i.e.
> same link-local address and link-layer address on
> every MAG. Plus same public-private key pair in case
> SEND is used.
>
> > to begin with and so, it doesn't matter that the link
> > changed while the MN kept the same prefix/address.
> > OTOH, if the link exhibited shared semantics for
> > link-local and the link changed, the upper layers'
> > and applications' expectations on reachability are
> > really misplaced and that loses the benefits those
> > applications get from having a shared link in the
> > first place.
> >
> > Without knowledge of the requirements to support
> > shared link-local behavior, we are having this
> > discussion in a vaccuum and I'm afraid we will not
> > make any progress. So, I urge you to step back and
> > talk about the requirements before we can have
> > further discussions.
>
> The requirement is to support last hop links which are
> shared, and can't be turned into p2p links (e.g.
> 802.11 w/o VLAN support)
>
> --julien
>
> _______________________________________________
> netlmm mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/netlmm
>
>
> _______________________________________________
> netlmm mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/netlmm
>
>
>

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

---

From: "Mohamed Khalil" <[email-masked]>
Date: Fri, 8 Dec 2006 15:03:47 -0600

Hi Behcet,
 
In NETLMM model the assumption is that the AT doesn't have L3 mobility
client. But. it is still have an IP address which we could call local
HoA which is offered by the serving domain  (this address has no
relation with the CoA which is a MIP terminology). To do both local
(intra domain mobility) and global mobility (inter domain mobility) we
should use 2 addresses; one is a local HoA and the other is the HoA. The
NETLMM model can be implemented by PMIP if we consider HA is equivalent
to LMA and the MN client is residing in one of the network entities
which is keeping track of the MN (e.g. BTS/MAG).
 
 -----Original Message-----
From: Behcet Sarikaya [mailto:[email-masked]] 
Sent: Friday, December 08, 2006 2:48 PM
To: Julien Bournelle
Cc: [email-masked]
Subject: Re: [netlmm]( Link Local Addressing Semantics) Decision Taken ?

	--behcet

	----- Original Message ----
	From: Julien Bournelle <[email-masked]>
	To: Behcet Sarikaya <[email-masked]>
	Cc: Julien Laganier <[email-masked]>; [email-masked]
	Sent: Friday, December 8, 2006 11:39:45 AM
	Subject: Re: [netlmm]( Link Local Addressing Semantics) Decision
Taken ?

	HI behcet,
	
	sorry if I missed something. What 's exactly the decision that
has
	been taken at San Diego ?
	
	Thanks,
	
	Julien B.

---

From: "Julien Bournelle" <[email-masked]>
Date: Sun, 10 Dec 2006 13:34:07 +0100

HI behcet,

 basically I read the minutes before asking the question :)
 From what I read, it's difficult to know what has been decided
exactly. That's why I ask the question.

 Julien

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 11 Dec 2006 10:12:05 +0100

Julien Bournelle wrote:
> HI behcet,
> 
> basically I read the minutes before asking the question :) From what
> I read, it's difficult to know what has been decided exactly. That's
> why I ask the question.

That is a very good question.  How does that PMIP vote materialize in
terms of next steps?  During the meeting it was said that the
face-to-face discussion is to be confirmed on the mailing list.

What protocol to use as base.  What status to be followed.  What's the
new timeline.

This is basically unclear at this time.  And I don't see how this can
get clarified by clarifying the link-local address semantics.  Maybe the
two have nothing to do with each other.

Alex

>> http://tools.ietf.org/wg/netlmm/minutes it is long reading but
>> worth it.
>> 
>> --behcet
>> 
>> 
>> ----- Original Message ---- From: Julien Bournelle
>> <[email-masked]> To: Behcet Sarikaya
>> <[email-masked]> Cc: Julien Laganier <[email-masked]>;
>> [email-masked] Sent: Friday, December 8, 2006 11:39:45 AM Subject:
>> Re: [netlmm]( Link Local Addressing Semantics) Decision Taken ?
>> 
>> 
>> HI behcet,
>> 
>>> Hi Julien, As per the decision taken at San Diego WG meeting, we
>>> probably do not
>> have
>>> to worry about MAG and LMAs any more. However, we might wish to
>>> discuss what should be the new link
>> model and I
>>> guess this was the reason why this thread was opened. In PMIP
>>> model, MN does not get its traffic from the netLMM address
>> but
>>> instead uses its HoA, what are the implications of this from the
>>> 
>> multilink
>>> subnet point-of-view? I think that with this new model the
>>> multilink subnet is created
>> at the
>>> home link and the solution (per-MN prefix) should apply to HoA
>>> and
>> MN can
>>>  configuration of its CoA. What do you think?
>>> 
>>> --behcet
>>> 
>>> 
>>> ----- Original Message ---- From: Julien Laganier
>>> <[email-masked]> To: [email-masked] Cc: "Templin, Fred
>>> L" <[email-masked]> Sent: Friday, December 8, 2006
>>> 8:56:58 AM Subject: Re: [netlmm] Link Local Addressing Semantics
>>> 
>>> 
>>> On Thursday 07 December 2006 20:29, Narayanan, Vidya wrote:
>>>> Fred,
>>> 
>>> [...]
>>> 
>>>> I think I've said this in the last couple of emails, but let me
>>>> try to describe it again. If the link-local semantics were
>>>> always p2p semantics, the upper layers on the MN never have any
>>>> expectations on the link-local reachability of neighbors
>>> 
>>> link-local reachibility of the (sole) neighbor of the MN: its
>>> router.
>>> 
>>> - The default router never change, it is the LMA - The domain
>>> fake an unchanging default router, i.e. same link-local address
>>> and link-layer address on every MAG. Plus same public-private key
>>> pair in case SEND is used.
>>> 
>>>> to begin with and so, it doesn't matter that the link changed
>>>> while the MN kept the same prefix/address. OTOH, if the link
>>>> exhibited shared semantics for link-local and the link changed,
>>>> the upper layers' and applications' expectations on
>>>> reachability are really misplaced and that loses the benefits
>>>> those applications get from having a shared link in the first
>>>> place.
>>>> 
>>>> Without knowledge of the requirements to support shared
>>>> link-local behavior, we are having this discussion in a vaccuum
>>>> and I'm afraid we will not make any progress. So, I urge you to
>>>> step back and talk about the requirements before we can have 
>>>> further discussions.
>>> 
>>> The requirement is to support last hop links which are shared,
>>> and can't be turned into p2p links (e.g. 802.11 w/o VLAN support)
>>> 
>>> 
>>> --julien
>>> 
>>> _______________________________________________ netlmm mailing
>>> list [email-masked] 
>>> _______________________________________________ netlmm mailing
>>> list [email-masked] 
> _______________________________________________ netlmm mailing list 
> [email-masked] https://www1.ietf.org/mailman/listinfo/netlmm
>

---

From: Jari Arkko <[email-masked]>
Date: Mon, 11 Dec 2006 23:59:45 +0200

Alexandru,
> How does that PMIP vote materialize in
> terms of next steps?
>
The poll from San Diego will be confirmed on
the list.

Assuming the result is the same in the
confirmation, there will at some point
be a WG draft. For that to happen, we
need a specification proposal that is
far enough for the WG to adopt it. People
should be working on such a proposal
if they are not already.

--Jari

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 11 Dec 2006 17:00:11 -0800

> should be working on such a proposal

we are now working on combining the good parts
from draft-sgundave-mip6-proxymip6-00 and
draft-chowdhury-netmip6-01. we will submit the
new version soon.

Vijay

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 12 Dec 2006 16:30:50 +0100

What are the netlmm PMIP goals?

A relevant netlmm PMIP goal is to not modify the mobile software.  Also
to support std mobile software.  Although not entirely clear what that
may mean, I think an important goal for netlmm PMIP is to support
mobiles that do run rfc3775 Mobile IPv6, without modifying them.

Argument was made about reusing MIP6 HAs in PMIP.  So which HA goal is
that: PMIP HA must run on unmodified HA?  Unmodified MIP HA must accept
Proxy BUs?  PMIP HA must accept a MIP BU?

Draft-ietf-netlmm-nohost-req makes it clear that MN runs Mobile IPv6,
and that the mobile is not involved much in netlmm.

I think a PMIPv6 deployment should not prohibit MN to run std Mobile
IPv6.  This has lots of implications on PMIPv6 protocol design, I think.

Alex

Vijay Devarapalli wrote:
> Jari Arkko wrote:
>> Alexandru,
>>> How does that PMIP vote materialize in terms of next steps?
>>> 
>> The poll from San Diego will be confirmed on the list.
>> 
>> Assuming the result is the same in the confirmation, there will at 
>> some point be a WG draft. For that to happen, we need a 
>> specification proposal that is far enough for the WG to adopt it. 
>> People should be working on such a proposal if they are not 
>> already.
> 
> we are now working on combining the good parts from 
> draft-sgundave-mip6-proxymip6-00 and draft-chowdhury-netmip6-01. we 
> will submit the new version soon.
> 
> Vijay
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 12 Dec 2006 08:23:28 -0800

> What are the netlmm PMIP goals?

I would assume any solution would need to satisfy
the requirements in draft-ietf-netlmm-nohost-req-05.txt

> IPv6.  This has lots of implications on PMIPv6 protocol design, I think.

A stated goal has always been to allow the same
home agent to support hosts that run MIPv6 and
hosts that depend on PMIPv6 for mobility.

Vijay

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 12 Dec 2006 18:53:21 +0100

Vijay Devarapalli wrote:
> I would assume any solution would need to satisfy the requirements in
> draft-ietf-netlmm-nohost-req-05.txt

Yes, I agree.

>> A relevant netlmm PMIP goal is to not modify the mobile software.
>> Also to support std mobile software.  Although not entirely clear
>> what that may mean, I think an important goal for netlmm PMIP is to
>> support mobiles that do run rfc3775 Mobile IPv6, without modifying
>> them.
>> 
>> Argument was made about reusing MIP6 HAs in PMIP.  So which HA goal
>> is that: PMIP HA must run on unmodified HA?  Unmodified MIP HA must
>> accept Proxy BUs?  PMIP HA must accept a MIP BU?
>> 
>> Draft-ietf-netlmm-nohost-req makes it clear that MN runs Mobile
>> IPv6, and that the mobile is not involved much in netlmm.
>> 
>> I think a PMIPv6 deployment should not prohibit MN to run std
>> Mobile IPv6.  This has lots of implications on PMIPv6 protocol
>> design, I think.
> 
> A stated goal has always been to allow the same home agent to support
> hosts that run MIPv6 and hosts that depend on PMIPv6 for mobility.

Yes, it's good to have it clear, separately.

Alex

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 12 Dec 2006 14:16:16 -0600

Hi Vijay,
One comment inline.

Regards,
Ahmad

> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Tuesday, December 12, 2006 10:23 AM
> To: Alexandru Petrescu
> Cc: [email-masked]
> Subject: [netlmm] Re: netlmm PMIP goals
> 
> I would assume any solution would need to satisfy the 
> requirements in draft-ietf-netlmm-nohost-req-05.txt
> 
> > Also to support std mobile software.  Although not entirely 
> clear what 
> > that may mean, I think an important goal for netlmm PMIP is 
> to support 
> > that: PMIP HA must run on unmodified HA?  Unmodified MIP HA must 
> A stated goal has always been to allow the same home agent to 
> support hosts that run MIPv6 and hosts that depend on PMIPv6 
> for mobility.

[Ahmad]
I assume that we are talking about MIPv6 and PMIPv6 coexistence/support
on the same HA not necessarily for the same user. Right?

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 12 Dec 2006 13:47:12 -0800

> on the same HA not necessarily for the same user. Right?

Yes.

Vijay