Subject: [netlmm] NETLMM Re-Chartering Topics - Seeking Input

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 6 Jun 2008 09:09:11 -0700

All,
Jonne and I are working on the rechartering process.  There is
sufficient consensus from the last meeting and subsequently on the
mailing list on the following topics: 

1) Mobile IPv6 and PMIPv6 interactions
2) GRE keying option to support separation of different flows in one
PMIPv6 tunnel
3) AAA support for PMIP (RADIUS and Diameter)
4) Automated Local Mobility Anchor (LMA) discovery
5) Management Information Base (MIB) for PMIPv6

Additionally, there have been a number of topics proposed on the mailing
list.  As we said at the last meeting, we are trying to scope the
charter for the next 12 months or so.   The above items are likely to
take that level of resources from the working group.  We can probably
take one more item on the list as a task for the WG.  However, there is
no clear consensus on what that item might be.  This is an attempt to
get input from the working group on the relative priorities and expected
participation on the various topics proposed so far.  

A collection of the work items proposed have been included below.
Please respond to this email with your prioritized list of items.
Please also indicate what level of participation you will provide for
each item that you choose, along the following lines: 

[E] Willing to serve as editor of the chosen draft

[C] Willing to co-author or contribute reasonably good amount of text
corresponding to the work item

[R] Review the intermediate versions of drafts corresponding to the work
item 

For instance, your response may be of the form: 

[R] Path Management and Failure Detection for PMIPv6 
[ECR] Inter-MAG handover optimization

Here is the list of the remaining proposed work items, in no particular
order of priority: 

o  Inter-MAG handover optimization: Handling packets in flight upon
abrupt tunnel switch; inter-MAG tunnels, etc. [Note: This particular
work item may be handled by MIPSHOP eventually; however, please include
this in prioritization and indicate your interest in contribution]

o  Path Management and Failure Detection for PMIPv6: Heartbeats to
detect in-path failures

o  NEMO Support for PMIPv6: Supporting mobile routers and networks with
PMIPv6 

o  Route Optimization for PMIPv6: Improving latency by intra-MAG,
inter-MAG and/or inter-LMA route optimization solutions

o  Advanced multihoming: Supporting various multihoming scenarios,
including a single prefix across interfaces model

o  Interaccess handover support: Solutions for handoffs across
interfaces involving different access networks 

o  Shared link support: Supporting the shared link model in PMIPv6

Please provide this input by June 16th, 2008. 

Thanks,
Vidya and Jonne 
_______________________________________________
netlmm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netlmm

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 6 Jun 2008 11:24:14 -0500

Hi Vidya and Jonne,
Here is my prioritized list and participation. IMO, Path management is a
small item and can be included anyway.

o  Inter-MAG handover optimization: Handling packets in flight upon
abrupt tunnel switch; inter-MAG tunnels, etc. [Note: This particular
work item may be handled by MIPSHOP eventually; however, please include
this in prioritization and indicate your interest in contribution] [ECR}

o  Path Management and Failure Detection for PMIPv6: Heartbeats to
detect in-path failures [R, "C if needed"]

[E, C, R]

[C, R]

[R]

o  Shared link support: Supporting the shared link model in PMIPv6 [R]

Regards,
Ahmad

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Narayanan, Vidya
> Sent: Friday, June 06, 2008 11:09 AM
> To: [email-masked]
> Subject: [netlmm] NETLMM Re-Chartering Topics - Seeking Input
> 
> All,
> Jonne and I are working on the rechartering process.  There 
> is sufficient consensus from the last meeting and 
> subsequently on the mailing list on the following topics: 
> 
> Additionally, there have been a number of topics proposed on 
> the mailing list.  As we said at the last meeting, we are 
> trying to scope the
> take that level of resources from the working group.  We can 
> probably take one more item on the list as a task for the WG. 
>  However, there is no clear consensus on what that item might 
> be.  This is an attempt to get input from the working group 
> on the relative priorities and expected participation on the 
> various topics proposed so far.  
> 
> Please also indicate what level of participation you will 
> provide for each item that you choose, along the following lines: 
> 
> [C] Willing to co-author or contribute reasonably good amount 
> of text corresponding to the work item
> 
> [R] Review the intermediate versions of drafts corresponding 
> to the work item 
> 
> [R] Path Management and Failure Detection for PMIPv6 [ECR] 
> Inter-MAG handover optimization
> 
> Here is the list of the remaining proposed work items, in no 
> particular order of priority: 
> 
> o  Inter-MAG handover optimization: Handling packets in 
> flight upon abrupt tunnel switch; inter-MAG tunnels, etc. 
> [Note: This particular work item may be handled by MIPSHOP 
> eventually; however, please include this in prioritization 
> and indicate your interest in contribution]
> 
> o  Path Management and Failure Detection for PMIPv6: 
> Heartbeats to detect in-path failures
> 
> o  Route Optimization for PMIPv6: Improving latency by 
> intra-MAG, inter-MAG and/or inter-LMA route optimization solutions
> 
> o  Advanced multihoming: Supporting various multihoming 
> scenarios, including a single prefix across interfaces model
> 
> o  Interaccess handover support: Solutions for handoffs 
> across interfaces involving different access networks 
>

---

From: Basavaraj Patil <[email-masked]>
Date: Fri, 06 Jun 2008 11:26:09 -0500

Hello,

Just wondering if the scope of the rechartering work items is limited to
only the ones that are proposed below.

At the last IETF, we presented in 6MAN WG an extension to RAs which would
basically flag the prefix(es) in the PIOs to indicate if it is a local
prefix or a PMIP6 prefix. I-D: draft-damic-netlmm-pmip6-ind-discover-03.txt

The feedback from 6MAN was that the Netlmm WG would need to discuss the
proposal and/or advise 6MAN. We believe that in the context of (DS)MIP6 and
PMIP6 co-existence/interactions, it is useful to have the ability for an MN
to determine the prefix type in the RA.

We would like Netlmm WG to consider this in the context of the current
rechartering.

-Raj

---

From: "Mohamed Khalil" <[email-masked]>
Date: Fri, 6 Jun 2008 11:38:59 -0500

1) Automated Local Mobility Anchor (LMA) discovery [C,R]
2) Advanced multihoming: Supporting various multihoming scenarios,
including a single prefix across interfaces model [C,R]

A collection of the work items proposed have been included below. Please
respond to this email with your prioritized list of items. Please also
indicate what level of participation you will provide for each item that
you choose, along the following lines: 

Thanks,
Vidya and Jonne

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Fri, 6 Jun 2008 11:59:28 -0500

I am not sure about the old requirement of "no impact to the MN (host)",
but with the base PMIPv6 protocol out of the way, I believe this
functionality is a very useful enhancement which could simplify a lot of
complexities.

Regards,
Ahmad

> [mailto:[email-masked]] On Behalf Of Basavaraj Patil
> Sent: Friday, June 06, 2008 11:26 AM
> To: ext Narayanan, Vidya; [email-masked]
> Subject: Re: [netlmm] NETLMM Re-Chartering Topics - Seeking Input
> 
> 
> Hello,
> 
> Just wondering if the scope of the rechartering work items is 
> limited to only the ones that are proposed below.
> 
> At the last IETF, we presented in 6MAN WG an extension to RAs 
> which would basically flag the prefix(es) in the PIOs to 
> indicate if it is a local prefix or a PMIP6 prefix. I-D: 
> draft-damic-netlmm-pmip6-ind-discover-03.txt
> 
> The feedback from 6MAN was that the Netlmm WG would need to 
> discuss the proposal and/or advise 6MAN. We believe that in 
> the context of (DS)MIP6 and
> PMIP6 co-existence/interactions, it is useful to have the 
> ability for an MN to determine the prefix type in the RA.
> 
> We would like Netlmm WG to consider this in the context of 
> the current rechartering.
> 
> -Raj
> 
> 
> 
> > Additionally, there have been a number of topics proposed on the 
> > mailing list.  As we said at the last meeting, we are 
> trying to scope the
> > take one more item on the list as a task for the WG.  
> However, there 
> > is no clear consensus on what that item might be.  This is 
> an attempt 
> > to get input from the working group on the relative priorities and 
> > expected participation on the various topics proposed so far.
> > 
> provide for 
> > [R] Review the intermediate versions of drafts corresponding to the 
> > work item
> > 
> > work item may be handled by MIPSHOP eventually; however, please 
> > include this in prioritization and indicate your interest in 
> > contribution]
> >

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 06 Jun 2008 10:53:24 -0700

Here is my list.

[E]

[ECR]

[ECR]

[CR]

Vijay

---

From: Vijay Devarapalli <[email-masked]>
Date: Fri, 06 Jun 2008 10:58:07 -0700

Hi Vidya

> including a single prefix across interfaces model

On this, I believe even basic multi-homing has some issues in the base
PMIPv6 document. It was not possible to fix those in the base PMIPv6 spec.
What if folks want to fix the basic multi-homing scenarios, but not
necessarily work on the advanced scenarios (like sharing an address across
interfaces)?

Vijay

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 6 Jun 2008 17:06:13 -0700

Hi Vijay,
Could you elaborate on the issues with basic multihoming and what needs
to be fixed?  We considered basic multihoming as the model we have
today, where each interface is independent and is governed by its own
prefix with a corresponding BCE.  In this model, the same prefix will
not be assigned to multiple interfaces at a given point of time.  

Any model where the prefix itself is shared across interfaces (note that
this doesn't mean same address across interfaces, just the same prefix)
would be part of what we have termed advanced multihoming here.  

Thanks,
Vidya

> From: Vijay Devarapalli [mailto:[email-masked]] 
> Sent: Friday, June 06, 2008 10:58 AM
> To: Narayanan, Vidya; [email-masked]
> What if folks want to fix the basic multi-homing scenarios, 
> but not necessarily work on the advanced scenarios (like 
> sharing an address across interfaces)?
> 
> Vijay
> 
>

---

From: "Narayanan, Vidya" <[email-masked]>
Date: Fri, 6 Jun 2008 17:07:56 -0700

Hi Raj,
We considered all the items that were sent in response to Jonne's email
on the way forward, after the last meeting.  Did we miss this one or is
this something you are proposing now? 

Thanks,
Vidya 

> From: Basavaraj Patil [mailto:[email-masked]] 
> Sent: Friday, June 06, 2008 9:26 AM

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 6 Jun 2008 17:10:56 -0700 (PDT)

I agree. There is nothing broken in the base spec. The use
of the same prefix across multiple interfaces is not
some thing in the scope of the base spec, nor is the
reachability of a mobile prefix assigned to a given interface
through a different path. These may be a useful extensions,
but not in the scope of the base spec. What was intended to
supported in the base spec, is clearly supported.

We need to decide if these extensions can be made it to the
initial list.

Sri

---

From: "Hui Deng" <[email-masked]>
Date: Sat, 7 Jun 2008 12:12:58 +0800

Hi, Vidya,

[EC]

Thanks

-Hui

---

From: "Jong-Hyouk Lee" <[email-masked]>
Date: Sun, 8 Jun 2008 07:39:18 +0900

Hi, Vidya,

[EC]: Route Optimization for PMIPv6: Improving latency by intra-MAG,
inter-MAG and/or inter-LMA route optimization solutions

[EC]: Advanced multihoming: Supporting various multihoming scenarios,
including a single prefix across interfaces model

[CR]: NEMO Support for PMIPv6: Supporting mobile routers and networks with
PMIPv6

Cheers.

-- 
Internet Management Technology Lab, Sungkyunkwan University.
Jong-Hyouk Lee.

#email: jonghyouk (at) gmail (dot) com
#webpage: http://cv.hurryon.org
_______________________________________________
netlmm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netlmm

---

From: "Julien Bournelle" <[email-masked]>
Date: Sun, 8 Jun 2008 15:12:07 +0200

Hi Vidya, all,

 Just to mention that we already start to work on Diameter support for PMIP6.
You can find the draft at:

 http://tools.ietf.org/html/draft-korhonen-dime-pmip6-03

 Our target was to be accepted as a WG item in DiME WG (as we did for
mip6 aaa draft).

 Obviously any comments/review for netlmm is more than welcome !

 Regards,

 Julien

---

From: Conny Larsson <[email-masked]>
Date: Sun, 08 Jun 2008 16:39:41 +0200

Hi Vidya,

Here is my list:

o  Route Optimization for PMIPv6: Improving latency by intra-MAG,
inter-MAG and/or inter-LMA route optimization solutions [CR]

o  Advanced multihoming: Supporting various multihoming scenarios,
including a single prefix across interfaces model [CR]

o  Path Management and Failure Detection for PMIPv6: Heartbeats to
detect in-path failures [R]

o  Inter-MAG handover optimization: Handling packets in flight upon
abrupt tunnel switch; inter-MAG tunnels, etc. [Note: This particular
work item may be handled by MIPSHOP eventually; however, please include
this in prioritization and indicate your interest in contribution] [R]

o  Interaccess handover support: Solutions for handoffs across
interfaces involving different access networks [R]

/Conny

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Sun, 8 Jun 2008 16:02:39 -0700

Hi Vidya and Jonne,

As far as I can understand, there is a 3GPP dependency for Release 8 EPS

> o  Path Management and Failure Detection for PMIPv6: Heartbeats to

It may be not official but it seems to me that 3GPP CT4 WG is adopting
Vijay's draft or anyway needs this functionality. 

For this reason I think this item should be considered as the remaining
item of the charter. I am fine to review the work on this.

> detect in-path failures [R]

Thanks
Gerardo

> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Narayanan, Vidya
> Sent: Friday, June 06, 2008 9:09 AM
> To: [email-masked]
mailing
> [R] Review the intermediate versions of drafts corresponding to the
work
> Here is the list of the remaining proposed work items, in no
particular
> work item may be handled by MIPSHOP eventually; however, please
include

---

From: Ashutosh Dutta <[email-masked]>
Date: Mon, 09 Jun 2008 07:36:51 -0400

Vidya,
       I am willing to contribute to the following items in the 
following manner.

[ECR] Route Optimization for PMIPv6: Improving latency by intra-MAG,
inter-MAG and/or inter-LMA route optimization solutions

[CR] Inter-MAG handover optimization: Handling packets in flight upon
abrupt tunnel switch; inter-MAG tunnels, etc. [Note: This particular
work item may be handled by MIPSHOP eventually; however, please include
this in prioritization and indicate your interest in contribution]

[CR] Interaccess handover support: Solutions for handoffs across
interfaces involving different access networks

[CR] Shared link support: Supporting the shared link model in PMIPv6

Regards
Ashutosh

---

From: <[email-masked]>
Date: Mon, 9 Jun 2008 14:16:32 +0200

Hi Vidya, all, 

Here's my list.

[CR]  Advanced multihoming: Supporting various multihoming 
      scenarios, including a single prefix across interfaces model

[ECR]  Interaccess handover support: Solutions for handoffs 
       across interfaces involving different access networks 

[ECR]  Shared link support: Supporting the shared link model in PMIPv6

Cheers,
	Jouni

---

From: Frank Xia <[email-masked]>
Date: Mon, 09 Jun 2008 09:39:33 -0500

Vidya,

BR
Frank

---

From: "Sangjin Jeong" <[email-masked]>
Date: Tue, 10 Jun 2008 09:40:45 +0900

Hi Vidya and Jonne,

Here is my list:

Regards,
Sangjin

---

From: Hidetoshi Yokota <[email-masked]>
Date: Tue, 10 Jun 2008 12:24:16 +0900

Hi Vidya,

I would like to devote myself to the following work items:

[ECR] o  Inter-MAG handover optimization: Handling packets in flight
upon abrupt tunnel switch; inter-MAG tunnels, etc. [Note: This
particular work item may be handled by MIPSHOP eventually; however,
please include this in prioritization and indicate your interest in
contribution]

[CR] o  Route Optimization for PMIPv6: Improving latency by intra-MAG,
inter-MAG and/or inter-LMA route optimization solutions

[CR] o  Interaccess handover support: Solutions for handoffs across
interfaces involving different access networks

Regards,
-- 
Hidetoshi

---

From: Julien Laganier <[email-masked]>
Date: Tue, 10 Jun 2008 09:36:44 +0200

Hello Gerardo, Vidya,

On Monday 09 June 2008, Giaretta, Gerardo wrote:
> Hi Vidya and Jonne,
>
> As far as I can understand, there is a 3GPP dependency for Release 8
> EPS for the following item:
> It may be not official but it seems to me that 3GPP CT4 WG is
> adopting Vijay's draft or anyway needs this functionality.

Right, 3GPP CT WG4 needs the functionlaity for PMIPv6, and there are 
proposals on the table (not agreed yet) considering to use Vijay's 
draft for that.

> For this reason I think this item should be considered as the
> remaining item of the charter. I am fine to review the work on this.

Ditto.

Thanks.

--julien

---

From: Julien Laganier <[email-masked]>
Date: Tue, 10 Jun 2008 09:40:32 +0200

Hello Vidya,

This is my input:

[ECR] Path Management and Failure Detection for PMIPv6: Heartbeats to
	detect in-path failures

[CR] Advanced multihoming: Supporting various multihoming scenarios,
	including a single prefix across interfaces model

[R] Route Optimization for PMIPv6: Improving latency by intra-MAG,
inter-MAG and/or inter-LMA route optimization solutions

[R] Inter-MAG handover optimization: Handling packets in flight
upon abrupt tunnel switch; inter-MAG tunnels, etc.

PS: I'm not sure why we're differentiating b/w "Advanced multihoming: 
Supporting various multihoming scenarios, including a single prefix 
across interfaces model" and "Interaccess handover support: Solutions 
for handoffs across interfaces involving different access networks". To 
me the latter seems a subset of the former, but anyway...

--julien

---

From: "Julien Bournelle" <[email-masked]>
Date: Tue, 10 Jun 2008 11:56:01 +0200

Hi vidya, all,

 Here is my list:

[CR] o  Inter-MAG handover optimization: Handling packets in flight upon
 abrupt tunnel switch; inter-MAG tunnels, etc. [Note: This particular
 work item may be handled by MIPSHOP eventually; however, please include
 this in prioritization and indicate your interest in contribution]

[R] o  Path Management and Failure Detection for PMIPv6: Heartbeats to
 detect in-path failures

 [CR] o  Advanced multihoming: Supporting various multihoming scenarios,
 including a single prefix across interfaces model

 [CR] o  Shared link support: Supporting the shared link model in PMIPv6

 -- Julien --

---

From: Basavaraj Patil <[email-masked]>
Date: Tue, 10 Jun 2008 11:24:40 -0500

Hi Vidya,

I think this is a missed item. The proposal for flagging a prefix was
presented to the 6MAN WG at the last IETF meeting and we had also indicated
this as being relevant in the charter discussion as well.
And as I said, 6MAN would prefer to have the discussion about this work in
Netlmm before they would consider the extension to the RA/RS messages.

-Raj

---

From: Basavaraj Patil <[email-masked]>
Date: Tue, 10 Jun 2008 11:44:27 -0500

Hi Vidya,

> 4) Automated Local Mobility Anchor (LMA) discovery

Just wondering about specifically what is the discovery component needed for
PMIP6? Is it not sufficient that the policy store indicates the LMA to be
assigned for an MN to the MAG?
Or are we considering the ability for an MN to indicate via some means an
LMA to which it requires a prefix from?

-Raj

---

From: Basavaraj Patil <[email-masked]>
Date: Tue, 10 Jun 2008 11:47:23 -0500

Jonne/Vidya,

The current charter scope does not allow any changes to the MN itself.
However I think this is an issue that we need t revisit. I think the rule on
"No chhanges to MN" needs to be relaxed in the charter.
This will better enable features such as inter-tech HO among others.
I hope you will consider this when you do the charter revision.

-Raj

---

From: Frank Xia <[email-masked]>
Date: Tue, 10 Jun 2008 12:01:59 -0500

Hi Raj

 AAA is not sufficient enough for HA discovery
in MIP6, and DHCP solution is thus proposed.

Vijay and I had many discussion in the mailing list
about dynamic LMA discovery  mechanisms which
are out of the scope of basic specification.

IMHO, DHCP soultion is expected to be one part of it.

BR
Frank

---

From: Basavaraj Patil <[email-masked]>
Date: Tue, 10 Jun 2008 13:04:30 -0500

Frank,

I don't know if you can equate LMA discovery with HA discovery in the case
of MIP6 primarily because the MN is not involved in the case of PMIP6.
The MN is unaware of PMIP6 elements (MAG/LMA) as per the current spec. So
what would the DHCP options be?

-Raj

---

From: Frank Xia <[email-masked]>
Date: Tue, 10 Jun 2008 13:27:41 -0500

Hi Raj

Here is a simple scenario.

Local breakout of IP traffic via the visited PLMN is supposed be supported,
when network policies and user subscription allow it.

In this case,  HPLMN can't not assign any LMA for MN during
the authentication procedure.   So, MAG acting as DHCP client
asks for  LMA information by resuing the option defined
in the document http://tools.ietf.org/id/draft-ietf-mip6-hiopt-17.txt

BR
Frank

----- Original Message ----- 
From: "Basavaraj Patil" <[email-masked]>
To: "ext Frank Xia" <[email-masked]>; "ext Narayanan, Vidya" 
<[email-masked]>; <[email-masked]>
Sent: Tuesday, June 10, 2008 1:04 PM
Subject: Re: [netlmm] NETLMM Re-Chartering Topics - Seeking Input

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Tue, 10 Jun 2008 14:39:55 -0400

Hi Raj,

> LMA to which it requires a prefix from?

Please see the following threads for previous discussion on this topic.

http://www.ietf.org/mail-archive/web/netlmm/current/msg04085.html

I followed this up with another thread a few days later.

http://www.ietf.org/mail-archive/web/netlmm/current/msg04103.html

Finally the email from the chairs.

http://www.ietf.org/mail-archive/web/netlmm/current/msg04133.html

I think it is just a matter of writing up text from the above threads in
a draft. We also need to mention storing the IP address of the LMA in
the policy profile, so that the new MAG can fetch the IP address of the
same LMA during a handover.

I have been intending to write a draft on this, but never got it. I also
noticed that there are some existing documents that talk about some of
these topics, but those documents have other stuff in them as well.

Vijay

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Tue, 10 Jun 2008 14:41:24 -0400

Frank,

> in the document http://tools.ietf.org/id/draft-ietf-mip6-hiopt-17.txt

The MAG would be the NAS. As a NAS, it would get the LMA information
from the AAA server. There is no need for any DHCP extensions here, only
RADIUS and Diameter extensions.

Vijay

> >>> Just wondering about specifically what is the discovery 
> component needed
> >>> for
> >>> PMIP6? Is it not sufficient that the policy store 
> indicates the LMA to 
> >>> be
> >>> Or are we considering the ability for an MN to indicate 
> via some means 
> >>> an

---

From: Basavaraj Patil <[email-masked]>
Date: Tue, 10 Jun 2008 14:16:09 -0500

Frank,

I think there are some flaws in the scenario that you mention below.
Local breakout is a topic in other SDOs. So I don't know if we need to
discuss that here. But anyway, in the case of local breakout, the MAG would
know the LMA to be assigned to the MN via configuration or other means. So I
don't see this as being a valid reason for LMA discovery.
Also, the MAG acting as a DHCP client is a new proposition. I don't believe
we have contemplated such functionality in PMIP6 at the present time and I
don't know if it makes sense either.

-Raj

---

From: Frank Xia <[email-masked]>
Date: Tue, 10 Jun 2008 14:38:42 -0500

Hi Raj

Firstly,  it is necessary that  MN's traffic is anchored by
visited LMA not home LMA.   Local breakout in 3GPP
is a typical deployment scenario.

Secondly, It makes sense that a router has DHCP client
functionality.

Please refer to the following practices in which a router has
DHCP function.

1)In RFC 3633, the requsting router acts as a DHCP client for
  prefix delegation
2)In NEMO DHCP PD (http://tools.ietf.org/id/draft-droms-mext-nemo-pd-00.txt)
   MR should has DHCP client function
3)In 3GPP TS23.401/TS23.402.
  The serving gateway and PDN gatway should have DHCP
  client function.

BR
Frank

----- Original Message ----- 
From: "Basavaraj Patil" <[email-masked]>
To: "ext Frank Xia" <[email-masked]>; "ext Narayanan, Vidya" 
<[email-masked]>; <[email-masked]>
Sent: Tuesday, June 10, 2008 2:16 PM
Subject: Re: [netlmm] NETLMM Re-Chartering Topics - Seeking Input

>>>>> Just wondering about specifically what is the discovery component 
>>>>> needed
>>>>> for

---

From: Basavaraj Patil <[email-masked]>
Date: Tue, 10 Jun 2008 15:10:13 -0500

Hi Vijay,

Thanks for the links... Comments below:

On 6/10/08 1:39 PM, "ext Vijay Devarapalli" <[email-masked]> wrote:

>> component needed for

Agree with the context of this message which proposes 3 mechanisms by which
a MAG can choose an LMA for an MN. The policy profile based mechanism IMO
already exists as part of the current Rev 18 I-D. I don't know if there is
anything to be specified in the case of preconfiguring the address of an LMA
(for MNs that have a specific realm or some similar rule). The only thing
which may be worth mentioning somewhere is the ability of the MAG to query
DNS to obtain the address of an LMA for an MN.

> these topics, but those documents have other stuff in them as well.

In retrospect, maybe it would have been best to mention the DNS based
mechanism in the base protocol spec itself. Because I don't think there is
much to be really specified in a separate I-D. But that is anyway not an
option now and I wonder if this can be maybe included as an appendix
(non-normative) at the Auth48 stage.

-Raj

---

From: Basavaraj Patil <[email-masked]>
Date: Tue, 10 Jun 2008 15:17:47 -0500

Hi Frank,

I am reluctant to discuss 3GPP specific scenarios on this ML because the
scope of the PMIP6 I-D and the work here is much more generic with broader
applicability. 
The PMIP6 I-D specifies a mechanism to assign an LMA. Whether that LMA
happens to be in the home of visited network is immaterial. So if policy for
an MN indicates that an LMA needs to be assigned in a specific realm, the
MAG has the ability to do so.

I am not disputing router/gw entities acting as DHCP clients. But in the
context of PMIP6 MAG function, we have not necessarily thought of it as
being essential for LMA assignment.

-Raj

---

From: Frank Xia <[email-masked]>
Date: Tue, 10 Jun 2008 15:39:20 -0500

Hi Raj

Just because of your reluctancy, I streamlined my scenario which
is very simple, that is, " it is necessary that  MN's traffic is anchored by
visited LMA not home LMA in some scenarios"

Now, I am a little bit confused.

At one hand you , you said "the MAG would know the LMA to be
assigned to the MN via configuration or other means"

When I proposed one of  the "other means", you said
"we have not necessarily thought of it as being essential
for LMA assignment".

I will be very happy if you can share your constructive ideas to deal with
the problem.

BR
Frank

----- Original Message ----- 
From: "Basavaraj Patil" <[email-masked]>
To: "ext Frank Xia" <[email-masked]>; "ext Narayanan, Vidya" 
<[email-masked]>; <[email-masked]>
Sent: Tuesday, June 10, 2008 3:17 PM
Subject: Re: [netlmm] NETLMM Re-Chartering Topics - Seeking Input

>> 2)In NEMO DHCP PD 
>> (http://tools.ietf.org/id/draft-droms-mext-nemo-pd-00.txt)
>>> know the LMA to be assigned to the MN via configuration or other means. 
>>> So
>>> I
>>>>>>> PMIP6? Is it not sufficient that the policy store indicates the LMA 
>>>>>>> to
>>>>>>> be
>>>>>>> Or are we considering the ability for an MN to indicate via some 
>>>>>>> means
>>>>>>> an

---

From: Basavaraj Patil <[email-masked]>
Date: Tue, 10 Jun 2008 15:47:33 -0500

Hi Frank,

Vijay's email proposed basically 3 mechanisms for assignment of an LMA:
1. via DNS
2. Policy profile -  indicating the LMA to be assigned during access
authentication
3. Preconfigured at the MAG (based on some rules)

I think the above mechanisms will be able to cover most scenarios.

-Raj

---

From: Frank Xia <[email-masked]>
Date: Tue, 10 Jun 2008 16:07:41 -0500

Hi Raj,

I support the mechanisms that Vijay proposed.
In fact, I mentioned the first two in the draft
http://tools.ietf.org/id/draft-xia-netlmm-radius-02.txt.

Further, I would like to propose DHCP solution to
solve the following scenario.

During bootstraping in a visited network, the
MN is allowed to access visited LMA based on
the user's profile and operators' agreement.
How does the MAG  identify a visited LMA?

Raj, If you give men some technical suggests
based on the above scenario, I will appriciate them.

BR
Frank

----- Original Message ----- 
From: "Basavaraj Patil" <[email-masked]>
To: "ext Frank Xia" <[email-masked]>; "ext Narayanan, Vidya" 
<[email-masked]>; <[email-masked]>
Sent: Tuesday, June 10, 2008 3:47 PM
Subject: Re: [netlmm] NETLMM Re-Chartering Topics - Seeking Input

>>>>> we have contemplated such functionality in PMIP6 at the present time 
>>>>> and
>>>>> I
>>>>>>> I don't know if you can equate LMA discovery with HA discovery in 
>>>>>>> the
>>>>>>> case
>>>>>>> The MN is unaware of PMIP6 elements (MAG/LMA) as per the current 
>>>>>>> spec.
>>>>>>> So

---

From: Basavaraj Patil <[email-masked]>
Date: Tue, 10 Jun 2008 16:22:05 -0500

Frank,

The address of an LMA(s) in a visited network can be configured at a MAG for
example or the MAG can do a DNS query to obtain the address of an LMA in the
visited network. 
So if the MNs profile indicates assignment of an LMA in the visited network,
there are mechanisms already to obtain the address of the LMA.

Don't you think the above solves the problem?

-Raj

---

From: Frank Xia <[email-masked]>
Date: Tue, 10 Jun 2008 16:32:00 -0500

Hi Raj

Why do we need DHCP HA discovery  while
DNS solution is there in MIP6 bootstrapping?

DHCP LMA discovery is a naturally application
of option defined in http://tools.ietf.org/id/draft-ietf-mip6-hiopt-17.txt,
while gaining big flexibility.

BR
Frank

----- Original Message ----- 
From: "Basavaraj Patil" <[email-masked]>
To: "ext Frank Xia" <[email-masked]>; "ext Narayanan, Vidya" 
<[email-masked]>; <[email-masked]>
Sent: Tuesday, June 10, 2008 4:22 PM
Subject: Re: [netlmm] NETLMM Re-Chartering Topics - Seeking Input

>>>> is very simple, that is, " it is necessary that  MN's traffic is 
>>>> anchored
>>>> by
>>>>> happens to be in the home of visited network is immaterial. So if 
>>>>> policy
>>>>> for
>>>>>>> discuss that here. But anyway, in the case of local breakout, the 
>>>>>>> MAG
>>>>>>> would
>>>>>>>> in the document 
>>>>>>>> http://tools.ietf.org/id/draft-ietf-mip6-hiopt-17.txt
>>>>>>>>
>>>>>>>> BR
>>>>>>>> Frank
>>>>>>>>
>>>>>>>>>>> component

---

From: Basavaraj Patil <[email-masked]>
Date: Tue, 10 Jun 2008 17:34:13 -0500

Frank,

DHCP is a commonly used by hosts for bootstrapping and hence it made sense
to specify a DHCP option for obtaining the HA address in the case of MIP6.
But the same logic does not apply in this case.

I don't know if there is any flexibility gained by using DHCP in the PMIP6
LMA discovery scenario. At least the scenario you have described so far has
not really demonstrated a need for such. If you can illustrate a valid
scenario where DHCP would make sense, I guess you could specify DHCP based
LMA discovery. But in the absence of such, I think specifying DHCP based
discovery only because MIP6 uses it does not make sense.

-Raj

---

From: Frank Xia <[email-masked]>
Date: Tue, 10 Jun 2008 17:56:19 -0500

Hi Raj

Please see my inline reply

BR
Frank

----- Original Message ----- 
From: "Basavaraj Patil" <[email-masked]>
To: "ext Frank Xia" <[email-masked]>; <[email-masked]>
Sent: Tuesday, June 10, 2008 5:34 PM
Subject: Re: [netlmm] NETLMM Re-Chartering Topics - Seeking Input

> But the same logic does not apply in this case.
Frank=>I don't know what your same logic exactly  means.  But if it means
"As a router, the MAC can't be a DHCP client ",  I think I have given
you enough reference to justify that a router can  have DHCP client 
function.
Please refer to our previous discussion.

> discovery only because MIP6 uses it does not make sense.
Frank=>I try to convince you in such way.
Vistied LMA(HA) information is managed by DHCP servers ( not in DNS)
in hybrid deployment scenario where MIPv6 and PMIPv6 co-exist.
How can MAGs retrieve the LMA information from the same DHCP servers?

>> of option defined in 
>> http://tools.ietf.org/id/draft-ietf-mip6-hiopt-17.txt,
>>>>>>> an MN indicates that an LMA needs to be assigned in a specific 
>>>>>>> realm,
>>>>>>> the
>>>>>>>>> Local breakout is a topic in other SDOs. So I don't know if we 
>>>>>>>>> need
>>>>>>>>> to
>>>>>>>>> Also, the MAG acting as a DHCP client is a new proposition. I 
>>>>>>>>> don't
>>>>>>>>> believe
>>>>>>>>>>>>> On 6/6/08 11:09 AM, "ext Narayanan, Vidya" 
>>>>>>>>>>>>> <[email-masked]>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> PMIP6? Is it not sufficient that the policy store indicates 
>>>>>>>>>>>>> the
>>>>>>>>>>>>> LMA
>>>>>>>>>>>>> to
>>>>>>>>>>>>> be

---

From: Basavaraj Patil <[email-masked]>
Date: Tue, 10 Jun 2008 18:27:40 -0500

Frank,

If you read my comment, it does not say anything about whether a router can
or cannot be a DHCP client. I was basically explaining why DHCP makes sense
in the case of MIP6.

Information about an HA or LMA can exist in DNS. In the case of MIP6 it can
also exist in a DHCP server. I don't see a problem when you have the hybrid
deployment scenario. The MAG can query DNS for LMA (visited) information or
can be configured with LMA addresses, while the MN can use DHCP (or DNS) to
obtain a local HA address. I don't see a problem. But if you think DHCP is
essential, then fine.

-Raj

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Tue, 10 Jun 2008 19:30:33 -0400

> (non-normative) at the Auth48 stage.

I think it is best to have a separate document on this, considering all
the discussion that has happened in the past on this topic.

Vijay

---

From: "Frank Xia" <[email-masked]>
Date: Tue, 10 Jun 2008 18:52:34 -0500

Hi Raj

I am sorry for some misunderstanding.
There is no any problem with DNS solution.

However, if the visited LMA information is dynamically
managed by DHCP servers in PMIPv6 and MIPv6
hybrid deployment scenarios,  IMO, it makes
sense to have MAG retreive LMA information
through DHCP.

BR
Frank

----- Original Message ----- 
From: "Basavaraj Patil" <[email-masked]>
To: "ext Frank Xia" <[email-masked]>; <[email-masked]>
Sent: Tuesday, June 10, 2008 6:27 PM
Subject: Re: [netlmm] NETLMM Re-Chartering Topics - Seeking Input

>>>>> The address of an LMA(s) in a visited network can be configured at a 
>>>>> MAG
>>>>> for
>>>>> example or the MAG can do a DNS query to obtain the address of an LMA 
>>>>> in
>>>>> the
>>>>> visited network.
>>>>>>>> I will be very happy if you can share your constructive ideas to 
>>>>>>>> deal
>>>>>>>> with
>>>>>>>> the problem.
>>>>>>>>
>>>>>>>> BR
>>>>>>>> Frank
>>>>>>>>
>>>>>>>>> I am reluctant to discuss 3GPP specific scenarios on this ML 
>>>>>>>>> because
>>>>>>>>> the
>>>>>>>>> I am not disputing router/gw entities acting as DHCP clients. But 
>>>>>>>>> in
>>>>>>>>> the
>>>>>>>>> context of PMIP6 MAG function, we have not necessarily thought of 
>>>>>>>>> it
>>>>>>>>> as
>>>>>>>>>>>> Local breakout of IP traffic via the visited PLMN is supposed 
>>>>>>>>>>>> be
>>>>>>>>>>>> supported,
>>>>>>>>>>>>> of MIP6 primarily because the MN is not involved in the case 
>>>>>>>>>>>>> of
>>>>>>>>>>>>> PMIP6.

---

From: "Premec, Domagoj" <[email-masked]>
Date: Wed, 11 Jun 2008 10:44:08 +0200

Hi Vidya,

Here is my list:

[ECR] o  Interaccess handover support: Solutions for handoffs across interfaces involving different access networks 

[CR] o  Inter-MAG handover optimization: Handling packets in flight upon abrupt tunnel switch; inter-MAG tunnels, etc. 

[CR] 1) Mobile IPv6 and PMIPv6 interactions 

[CR] 2) GRE keying option to support separation of different flows in one PMIPv6 tunnel 

domagoj

> Sent: 06. lipanj 2008 18:09
> To: [email-masked]

---

From: "John.zhao" <[email-masked]>
Date: Wed, 11 Jun 2008 10:35:25 +0800

Hi,Vidya

[ECR] oNEMO Support for PMIPv6: Supporting mobile routers and networks with
 PMIPv6
	Best Rgds,
Thanks
John.zhao
2008-06-10
> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表
> Narayanan, Vidya
> 发送时间: 2008年6月7日 0:09
> 收件人: [email-masked]
> 主题: [netlmm] NETLMM Re-Chartering Topics - Seeking Input
> 
> All,

---

From: "John.zhao" <[email-masked]>
Date: Tue, 10 Jun 2008 17:55:38 +0800

Hi,all

[ECR] o  NEMO Support for PMIPv6: Supporting mobile routers and networks
with
 PMIPv6

---

From: Marco Liebsch <[email-masked]>
Date: Thu, 12 Jun 2008 18:13:31 +0200

My vote is for handover optimization, as we proposed during last 
meeting. Associated candidate
work items are a bit confusing and should clearly separate optimization 
by means of touching MAGs
(e.g. inter-MAG tunnel according to FHO mechanisms) from optimization by 
means of touching
the LMA (e.g. oprimized paths switch timing and forwarding rules).

Item "Interaccess handover support" implies handover between MAGs, which 
is actually
covered in item "Inter-MAG handover optimization". I think it's better 
to clarify the scope of
these work items before voting. Otherwise we run into this discussion 
after an item
has been selected according to votes.

Now, assuming that LMA-based handover optimization is part of the 
"Interaccess handover support"
work item, could my first vote on this.

[ECR] "Interaccess handover support".

But based on my arguments above, maybe this work item should be merged with
"Inter-MAG handover optimization".

There has been quite a lot of work submitted to NetLMM about LMA-based 
handover
optimization. This work is currently visible in 3GPP and the demand for 
such solutions is
obvious. Associated proposals can be specified easily within the 12 
months timeframe.

My second and third priority is:

marco

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Thu, 12 Jun 2008 15:01:42 -0400

Hello Marcho,

> work item, could my first vote on this.

Probably not. I think we should keep inter-access technology handovers
separate from the optimizations. FWIW, PMIPv6 is supposed to be used for
handovers in a particular access network involving just one interface on
the mobile node. The reality is that it is used for inter-access
technology handovers elsewhere. This does result in some requirements on
the mobile node and MAG to be able to perform an inter-access technology
handover. 3GPP and other SDOs that are using PMIPv6 for inter-access
technology handovers did not need anything from the IETF, they specified
it themselves.

Please see section 4 in draft-devarapalli-netlmm-multihoming-02.txt. It
talks about inter-access technology handovers using PMIPv6 *without* any
optimizations.

> "Inter-MAG handover optimization".

IMO, this should be kept separate for now.

> obvious. Associated proposals can be specified easily within the 12 

Sure. 

Vijay

---

From: "Premec, Domagoj" <[email-masked]>
Date: Fri, 13 Jun 2008 10:58:11 +0200

Hi Vijay, Marco,

>  I think we should keep inter-access technology 
> handovers separate from the optimizations.

agree.

> 3GPP and other SDOs that are using 
> PMIPv6 for inter-access technology handovers did not need 
> anything from the IETF, they specified it themselves.

I thought that handoff indicator was introduced specifically to support multi-interface MNs and inter-tech handovers. IMO IETF should continue this work and specify a complete solution for inter-tech HO, otherwise each SDO could come up with its own flavor of PMIP6 inter-tech handover, and we want to avoid that.

domagoj

> [mailto:[email-masked]] On Behalf Of Vijay Devarapalli
> Sent: 12. lipanj 2008 21:02
> To: Marco Liebsch; Narayanan, Vidya
> Cc: [email-masked]
> > Item "Interaccess handover support" implies handover between MAGs, 
> > which is actually covered in item "Inter-MAG handover 
> optimization". I 
> > think it's better to clarify the scope of these work items before 
> > voting. Otherwise we run into this discussion after an item 
> has been 
> Probably not. I think we should keep inter-access technology 
> handovers separate from the optimizations. FWIW, PMIPv6 is 
> supposed to be used for handovers in a particular access 
> network involving just one interface on the mobile node. The 
> reality is that it is used for inter-access technology 
> handovers elsewhere. This does result in some requirements on 
> the mobile node and MAG to be able to perform an inter-access 
> technology handover. 3GPP and other SDOs that are using 
> PMIPv6 for inter-access technology handovers did not need 
> anything from the IETF, they specified it themselves.
> 
> Please see section 4 in 
> draft-devarapalli-netlmm-multihoming-02.txt. It talks about 
> inter-access technology handovers using PMIPv6 *without* any 
> optimizations.
> 
> > But based on my arguments above, maybe this work item 
> should be merged 
> > with "Inter-MAG handover optimization".
> 
> > handover optimization. This work is currently visible in 
> 3GPP and the 
> > demand for such solutions is obvious. Associated proposals can be 
> > specified easily within the 12 months timeframe.
> 
> Sure. 
> 
> Vijay

---

From: Marco Liebsch <[email-masked]>
Date: Fri, 13 Jun 2008 15:15:36 +0200

Hi Vijay,

Vijay Devarapalli wrote:
> the mobile node.
Well, the base spec comprises a lot of text how to handle inter-technology
handover. I don't think this has been included hoping that nobody uses it.

>  The reality is that it is used for inter-access
Issues with using the PMIPv6 base protocol for inter-technology handover 
have been
identified and described, in the IETF as well as in 3GPP. Sure, you can 
perform
an inter-tech handover, but the performance may be bad. Why not using simple
extensions to the base protocol to improve the situation? Work on such
extensions has been proposed to the IETF.

> IMO, this should be kept separate for now.
Ok, but I still don't see the major difference.

Thanks,
marco

---

From: "Joo-Chul Kevin Lee" <[email-masked]>
Date: Sat, 14 Jun 2008 01:04:55 +0900

Hi, Vidya

I can contribute following:

[CR] oNEMO Support for PMIPv6: Supporting mobile routers and networks with
 PMIPv6

Best regards,
-jclee.

-- 
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+
Joo-Chul Kevin Lee (ETRI)
Electronics and Telecommunications Research Institute.
161 Kajong-dong, Yusong-Gu, TAEJON, 305-350, KOREA
E-mail : [email-masked]/[email-masked] Tel : +82-042-860-1021
-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
_______________________________________________
netlmm mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netlmm

---

From: "fan zhao" <[email-masked]>
Date: Fri, 13 Jun 2008 16:02:08 -0700

Hi Vidya and Jonne,

IMO, the draft of the heartbeat message for PMIP Path Management and Failure
Detection is in good shape and the WG can complete this work without taking
too much time.

The following is my list of additional work items that should be
considered by the WG:

[CR] NEMO Support for PMIPv6: Supporting mobile routers and networks with
PMIPv6

[R] Interaccess handover support: Solutions for handoffs across
interfaces involving different access networks

Sincerely,
fan

---

From: <[email-masked]>
Date: Mon, 16 Jun 2008 11:01:26 +0200

Hi vidya, all,

 Here is my list:

[CR] o  Interaccess handover support: Solutions for handoffs across  interfaces involving different access networks

[R] o  Advanced multihoming: Supporting various multihoming scenarios,  including a single prefix across interfaces model

[R] o  Path Management and Failure Detection for PMIPv6: Heartbeats to  detect in-path failures

Regards,
Pierrick

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la part
> de Narayanan, Vidya
> Envoyé : vendredi 6 juin 2008 18:09
> À : [email-masked]
> Objet : [netlmm] NETLMM Re-Chartering Topics - Seeking Input
> 
> All,

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 16 Jun 2008 11:22:01 -0700

Hello folks,

My new job has a major emphasis on the use of
[netlmm] protocols, due to its adoption as part
of some potentially important new standards.

So, I'd be willing to review, edit, and/or co-author
the following efforts:

[ECR] 1) Mobile IPv6 and PMIPv6 interactions

[R]   3) AAA support for PMIP (RADIUS and Diameter)

[R]   4) Automated Local Mobility Anchor (LMA) discovery

[CR]  o  Inter-MAG handover optimization: Handling packets in flight upon
         abrupt tunnel switch; inter-MAG tunnels, etc.

        
[ECR] o  Interaccess handover support: Solutions for handoffs across
         interfaces involving different access networks

Regards,
Charlie P.

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 17 Jun 2008 15:16:55 -0400

Hi Chairs,
   Here is my ordered list.

Thanks
Suresh

---

From: "Giaretta, Gerardo" <[email-masked]>
Date: Thu, 19 Jun 2008 08:40:35 -0700

Completing my list of preference with additional information:

o  Path Management and Failure Detection for PMIPv6: Heartbeats to
detect in-path failures [R][C] - as mentioned there may be a 3GPP
dependency on this

o  NEMO Support for PMIPv6: Supporting mobile routers and networks
with PMIPv6 [R][C]

o  Route Optimization for PMIPv6: Improving latency by
intra-MAG,inter-MAG and/or inter-LMA route optimization solutions [R]

Thanks
Gerardo

Behalf
> Of Giaretta, Gerardo
> Sent: Sunday, June 08, 2008 4:03 PM
EPS
> For this reason I think this item should be considered as the
remaining
> > take that level of resources from the working group.  We can
probably