Subject: [netlmm] Q about PMIPv6 MN-HNP assignment

From: <[email-masked]>
Date: Sat, 9 Jun 2007 10:57:51 +0200

Hi,

A question related to the PMIPv6 MN-HNP & IPv4-HoA assignments.
Bear in mind these are from -00 versions so I have no idea whether
things will change for -01.

I cases when a MN boots up for the first time in a PMIP6-Domain
or roams to a new MAG for the first time there is imho some room
for clarifications when it comes to MN-HNP & IPv4-HoA assignments.
Sections 6.11 and 7.1 in proxymip6-00 mention briefly that the MAG
may learn the MN-HNP before sending the PBU (e.g. using AAA).
Section 6.11 also describes briefly a mechanism to learn MN-HNP
dynamically (using ::0 in PBU Home Network Prefix Option). Then the
ipv4-support-00 adds also one more alternative (IPv4-HAO is 0.0.0.0
or contains address learned from DHCP). Why there are so many ways
to 'bootstrap' the MN-HNP & IPv4-HOA? This imho complicates the
overall system design. I'd like to understand the reasoning why the
MAG (through e.g. AAA) may be part of the MN-HNP 'bootstrapping' and
not just let the LMA (and possibly the AAA behind it) to handle all
prefix assignment and management? Not that I have any big issues 
with this but I just want to know ;)

Cheers,
	Jouni

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

---

From: "Sri Gundavelli" <[email-masked]>
Date: Sun, 10 Jun 2007 21:10:51 -0700

Hi Jouni,

Please see inline ...

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] 
> Sent: Saturday, June 09, 2007 1:58 AM
> To: [email-masked]
> Subject: [netlmm] Q about PMIPv6 MN-HNP assignment
> 
> 
> Hi,
> 

Bootstrapping mechanisms in the base PMIP6 or in the IPv4-support draft
are pretty much the same. The key difference is the support for 
Per-MN-Prefix model for IPv6 and shared-prefix model support for IPv4
addressing. W.r.t the exchange of this addressing information between
the LMA and MAG, the semantics are identical. There are only possibilities:

Case#1: LMA allocating the MN-HoA or the IPv4-MN-HoA

Case#2: MAG registering a specific IPv6 prefix and/or a IPv4 home address
        that it learnt from a local policy store or from any addressing
        server.

I definitely see your point, LMA should be the entity doing the prefix
management. It any ways needs to manage the route for that prefix/address.
That is the default behavior. The reason for allowing MAG's participation
is for deployment flexibility. It is possible the address allocation may
be managed by a DHCP or other addressing server and in that case, LMA and
MAG are passive entities, just w.r.t the management of the addressing. So,
the MAG must register the allocated address with the LMA. So, its just a
flexibility and we did not want to support just one model. Also, in a system
architecture where this protocol will be used, there may be reasons to allow
the MAG to manage the addressing and just do a registration with the LMA.

Thanks for the input. This is a good comment.

Thanks
Sri

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Mon, 11 Jun 2007 11:18:06 -0700

Sri,

I would actually prefer scrapping the option where the MAG
gets the prefix/address (IPv4 or IPv6) from the "policy
store" or a DHCP server. Just have one mechanism of getting
the addresses from the LMA all the time.

If there are extensions that need to be done to handle 
prefix/address assignment in a different way for some specific
deployment, lets do them as extensions to PMIPv6. Not include 
them in the base PMIPv6 spec.

This goes for the IPv4 support document too.

Vijay

> From: Sri Gundavelli [mailto:[email-masked]] 
> Sent: Sunday, June 10, 2007 9:11 PM
> To: [email-masked]; [email-masked]
> Subject: RE: [netlmm] Q about PMIPv6 MN-HNP assignment
> 
> Hi Jouni,
> 
> Please see inline ...
>  
>

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Tue, 12 Jun 2007 11:53:58 -0400

Hi Sri, 

I would support Vijay's proposal i.e. HoA assignment streamlined at the
LMA only.

This is in alignment with mip6 bootstrapping work that we are doing in
mip6 WG. There was a proposal to allow the AAAH to assign HNP or HoA for
mip6 bootstrapping, but the consensus was to do HoA
assignment/management only by the HA. We should follow the same
principles for PMIP6 as well.

Note that HoA/HNP assignment via DHCP (draft-ietf-mip6-hiopt-04.txt) was
removed.

-Kuntal

> From: Vijay Devarapalli [mailto:[email-masked]]
> Sent: Monday, June 11, 2007 1:18 PM
> To: Sri Gundavelli; [email-masked]; [email-masked]

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 12 Jun 2007 14:31:40 -0700

Hi Vijay,

This scenario allows deployments to offload the address
management to DHCP or other addressing servers, while the
LMA and the MAG manage the data path setup for that address.
Its a feature flexibility and IMO may be leveraged in some
deployments. Secondly, by allowing the prefix information
to be stored in a policy store, the MAG can advertise the
mobile node's prefix on the access link and while its 
doing the signaling with the local mobility anchor at the
same time. The two operations can be done in parallel and
that reduces the handoff latency to some extent.

Also, wondering, if you think this feature is not required
at all or if you think this needs to be solved in a different
draft at a later time. If its the later, then I'd say, this
was in draft since -00 version and we must have a good reason
to defer this.

I realize this is an unresolved issue. I will now open
this up to the WG discussion. I will send out a mail with
the options and the advantages/disadvantages around it. We
can drop this, if that ends up as the recorded consensus.

Thanks
Sri

> Sent: Monday, June 11, 2007 11:18 AM

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 12 Jun 2007 14:34:01 -0700

Hi Kuntal,

Ok. We can now open this up to the WG discussion.

Thanks
Sri 

> From: Chowdhury, Kuntal [mailto:[email-masked]] 
> Sent: Tuesday, June 12, 2007 8:54 AM
> To: Vijay Devarapalli; Sri Gundavelli; 
> [email-masked]; [email-masked]
> "This email message and any attachments are confidential 
> information of Starent Networks, Corp. The information 
> transmitted may not be used to create or change any 
> contractual obligations of Starent Networks, Corp.  Any 
> review, retransmission, dissemination or other use of, or 
> taking of any action in reliance upon this e-mail and its 
> attachments by persons or entities other than the intended 
> recipient is prohibited. If you are not the intended 
> recipient, please notify the sender immediately -- by 
> replying to this message or by sending an email to 
> [email-masked] -- and destroy all copies of 
> this message and any attachments without reading or 
> disclosing their contents. Thank you."

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Tue, 12 Jun 2007 16:28:12 -0700

> that reduces the handoff latency to some extent.

Flexibility makes sense, yes. But this is more like an 
alternate solution. If there is a deployment need for this
solution, then I wouldn't have an issue with specifying the
alternate mechanism too. But that is not the case here. 

I would be in favor of just having one solution, address 
assignment via the exchange of proxy binding update and 
proxy binding ack from the LMA.
 
> at all 

Not required.

> or if you think this needs to be solved in a different
> draft at a later time. 

If there is a need for it, we can specify it in a separate
draft.

> If its the later, then I'd say, this

We had an offline discussion on this before, but it would be
good to hear from the mailing list.

Vijay

---

From: Marco Liebsch <[email-masked]>
Date: Wed, 13 Jun 2007 09:57:22 +0200

Hi Sri, all,

I am also in favour of relying on the LMA to perform
HNP assignment, as it makes a lot of sense. To compare
with MIPv6 bootstraping is not the right rationale, as
the HA is the only and central mobility management
component, wereas PMIPv6 offers a MAG, which also
suits HNP assignment.

Well, I'd propose to mention LMA-based assignment
as default, but not explicitly exclude MAG-based
assignment. I see details about this anyway out of scope
of the base spec. And I am not sure, if this WG should
specify details, such as the use of DHCP from the MAG
etc. at all.

marco

Sri Gundavelli wrote:

>>>>>Bear in mind these are from -00 versions so I have no 
>>>>>          
>>>>>
>>idea whether
>>    
>>
>>>>>for clarifications when it comes to MN-HNP & IPv4-HoA 
>>>>>          
>>>>>
>>assignments.
>>    
>>
>>>>>Sections 6.11 and 7.1 in proxymip6-00 mention briefly 
>>>>>          
>>>>>
>>that the MAG
>>    
>>
>>>>>dynamically (using ::0 in PBU Home Network Prefix Option). Then
>>>>>          
>>>>>
>>the
>>    
>>
>>>>>ipv4-support-00 adds also one more alternative (IPv4-HAO is
>>>>>          
>>>>>
>>0.0.0.0
>>    
>>
>>>>>or contains address learned from DHCP). Why there are 
>>>>>          
>>>>>
>>so many ways
>>    
>>
>>>>>overall system design. I'd like to understand the reasoning why
>>>>>          
>>>>>
>>the
>>    
>>
>>>>>MAG (through e.g. AAA) may be part of the MN-HNP 'bootstrapping'
>>>>>          
>>>>>
>>and
>>    
>>
>>>>>not just let the LMA (and possibly the AAA behind it) to handle
>>>>>          
>>>>>
>>all
>>    
>>
>>>>Per-MN-Prefix model for IPv6 and shared-prefix model support for
>>>>        
>>>>
>>IPv4
>>    
>>
>>>>addressing. W.r.t the exchange of this addressing information
>>>>        
>>>>
>>between
>>    
>>
>>>>I definitely see your point, LMA should be the entity doing the
>>>>        
>>>>
>>prefix
>>    
>>

---

From: <[email-masked]>
Date: Wed, 13 Jun 2007 11:44:23 +0200

Hi Sri,

My preference would be letting the LMA perform the MN-HNP &
IPv4-HoA management and removing the explicit notes in the
text stating that a MAG _may_learn-_ the MN-HNP from the
policy store or IPv4-HoA from DHCP. This would concern both
-proxymip6 and -pmip6-ipv4-support I-Ds. IMHO, having one
well defined way makes sense and clarifies the basic protocol.

Having said the above, I would leave it open how the LMA acquires
the MN-HNP or the IPv4-HoA - in the base protocol I-Ds. IMHO,
those may be managed locally by the LMA, by an external policy
store or a DHCP etc. Just like some popular HAs do today.

Cheers,
	Jouni

> Sent: Wednesday, June 13, 2007 12:34 AM
> To: 'Chowdhury, Kuntal'; 'Vijay Devarapalli'; Korhonen, Jouni 
> /TeliaSonera Finland Oyj; [email-masked]
> > I would support Vijay's proposal i.e. HoA assignment streamlined at 
> > the LMA only.
> > 
> > mip6 WG. There was a proposal to allow the AAAH to assign 
> HNP or HoA 
> > for
> > > I would actually prefer scrapping the option where the 
> MAG gets the 
> > > prefix/address (IPv4 or IPv6) from the "policy store" or a DHCP 
> > > server. Just have one mechanism of getting the addresses from the 
> > > LMA all the time.
> > > 
> > > deployment, lets do them as extensions to PMIPv6. Not 
> include them 
> > > in the base PMIPv6 spec.
> > > 
> > > > Bootstrapping mechanisms in the base PMIP6 or in the 
> IPv4-support 
> > > > draft are pretty much the same. The key difference is 
> the support 
> > > > for Per-MN-Prefix model for IPv6 and shared-prefix 
> model support 
> > > > for
> > IPv4
> > > > Case#2: MAG registering a specific IPv6 prefix and/or a 
> IPv4 home 
> > > > address
> > > > That is the default behavior. The reason for allowing MAG's 
> > > > participation is for deployment flexibility. It is possible the 
> > > > address allocation may be managed by a DHCP or other addressing 
> > > > server and in that case, LMA and MAG are passive entities, just 
> > > > w.r.t the management of the addressing. So, the MAG 
> must register 
> > > > the allocated address with the LMA. So, its just a 
> flexibility and 
> > > > we did not want to support just one model.
> > > > Also, in a system
> > > > architecture where this protocol will be used, there may be 
> > > > reasons to allow the MAG to manage the addressing and just do a 
> > > > registration with the LMA.
> > > >
> information 
> > of Starent Networks, Corp. The information transmitted may 
> not be used 
> > to create or change any contractual obligations of Starent 
> Networks, 
> > Corp.  Any review, retransmission, dissemination or other 
> use of, or 
> attachments 
> > by persons or entities other than the intended recipient is 
> > prohibited. If you are not the intended recipient, please 
> notify the 
> > sender immediately -- by replying to this message or by sending an 
> > email to [email-masked] -- and destroy all 
> copies of

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Thu, 14 Jun 2007 00:57:43 +0900

Hi all,

Let me respond to IPv4 address assignment only.
In the v4 support document,I have another concern,
whether MAG acts as a DHCP server or a DHCP relay.

- MAG is a DHCP server and learns the address from LMA
- MAG is a DHCP relay and learns the address from a DHCP server (it  
maybe collocated with LMA)

It is obvious that DHCP relay is much easier and simpler to support  
on every MAG.
Specially, MAG (DHCP-Relay) does not have any local states.
On the other hand, DHCP-Server must manage the state of assigned  
addresses.
Requiring the DHCP server support on every MAG isn't too strict for  
some operators?

In addition, how can you deliver the other local parameters (DNS  
server, etc) from LMA?
If LMA does not provide such parameters through PBU, these parameters  
should be statically
configured on every MAG. I think this is not flexible operation.
If MAG is DHCP relay, these information can be easily managed by a  
DHCP server.

> specify details, such as the use of DHCP from the MAG

Even if we rely on LMA address assignment only, we have to define
the interaction between DHCP server (MAG) and LMA anyway.
The assigned addresses' state must be consistently managed by both  
MAG and LMA.
DHCP server should not send NAK unless LMA rejects BU.
This is not specified in DHCP document and must be specified in this  
group.

regards,
ryuji

On 2007/06/13, at 16:57, Marco Liebsch wrote:

>>>>> IPv4-support draft
>>>>> participation
>>>>> reasons to allow
>>> transmitted may not be used to create or change any contractual  
>>> obligations of Starent Networks, Corp.  Any review,  
>>> retransmission, dissemination or other use of, or taking of any  
>>> action in reliance upon this e-mail and its attachments by  
>>> persons or entities other than the intended recipient is  
>>> prohibited. If you are not the intended recipient, please notify  
>>> the sender immediately -- by replying to this message or by  
>>> sending an email to [email-masked] -- and destroy  
>>> all copies of this message and any attachments without reading or

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Wed, 13 Jun 2007 11:39:07 -0700

Ryuji,

The IPv4 address that the LMA assigns to the mobile node is sent
to the MAG via the proxy binding ack message. Why do we need
anything else?

Regarding making the MAG being a DHCP relay, IMO, we should not
support the scenario where the MAG relays DHCP messages all the
way to the LMA.

Vijay

> From: RYUJI WAKIKAWA [mailto:[email-masked]] 
> Sent: Wednesday, June 13, 2007 8:58 AM
> To: Marco Liebsch
> Cc: Sri Gundavelli; [email-masked]; Vijay Devarapalli
> Subject: Re: [netlmm] Q about PMIPv6 MN-HNP assignment
> 
> Hi all,
>

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Thu, 14 Jun 2007 10:02:06 +0900

Hi Vijay

> to the MAG via the proxy binding ack message. Why do we need

I sent my concerns, see below.
please answer to that:-)

> support the scenario where the MAG relays DHCP messages all the

why, because of security?
DHCP server can also put near MAG.

regards,
ryuji

---

From: Marco Liebsch <[email-masked]>
Date: Thu, 14 Jun 2007 12:38:14 +0200

Hi Ryuji,

for IPv4 and DHCP-based solution, you may be right. But there should be more
possibilities to allow address or prefix assignment. LMAs (in a multi-LMA
domain) could get assigned a pool of IPv6 prefixes. From that pool, address
prefixes could be assigned to terminals during the registration procedure.
For route optimization, this could enable LMAs to learn whether
a packet's destination address is assigned inside or outside the domain and
whether or not routes could be optmization within the LMA's domain
(just as example why this could be beneficial).

I did not say that the MAG should not play any role in address/prefix
assignment. I just see the LMA as components, which should play a
major role in that compared to the MAG.

What about a discussion we had some time ago, where some MAG
components (in particular control plane) could be relocated from the
AR to a more centric component (classified as future work)? Mainly
because of various deployment scenarios and implementation specific
details, I am hesitating to specify address/prefix assignment for one
particular solution in this group. I prefer keeping this generic.

marco

RYUJI WAKIKAWA wrote:

> It is obvious that DHCP relay is much easier and simpler to support on
> every MAG.
> The assigned addresses' state must be consistently managed by both MAG
> and LMA.
>>>> information of Starent Networks, Corp. The information transmitted
>>>> may not be used to create or change any contractual obligations of
>>>> Starent Networks, Corp. Any review, retransmission, dissemination
>>>> or other use of, or taking of any action in reliance upon this
>>>> e-mail and its attachments by persons or entities other than the
>>>> intended recipient is prohibited. If you are not the intended
>>>> recipient, please notify the sender immediately -- by replying to
>>>> this message or by sending an email to
>>>> [email-masked] -- and destroy all copies of this
>>>> message and any attachments without reading or disclosing their
>>>> contents. Thank you."
>>>>
>>>

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Thu, 14 Jun 2007 07:40:49 -0500

Hi Marco,

I agree with Marco comments here. I do think that we need to leave the
address/prefixes assignment generic that would allow each deployment to
use whatever means they have to enable this functionality. (The draft
can list some examples which include the use PBU/PBA for the address
allocation) However, I believe that the draft MUST capture the specific
requirements for that generic approach.
For example, MAG should not assign or advertise a HNP to the MN before
establishing the PMIP tunnel for that HNP prefix/address with the LMA.
Or in case we need to make the solution optimized, we may require if the
MN sends traffic using a source IP address that belong to the HNP, MAG
either drops the traffic or buffers it until PMIP tunnel is confirmed.
Also, in case the LMA rejects the PBU, MAG must send a new RA with HNP
with lifetime of zero.

These are some thoughts which, IMO, may need wg consensus.

Regards,
Ahmad

> From: Marco Liebsch [mailto:[email-masked]] 
> Sent: Thursday, June 14, 2007 5:38 AM
> To: RYUJI WAKIKAWA
> Cc: [email-masked]; 'Vijay Devarapalli'
> for IPv4 and DHCP-based solution, you may be right. But there 
> should be more possibilities to allow address or prefix 
> assignment. LMAs (in a multi-LMA
> domain) could get assigned a pool of IPv6 prefixes. From that 
> pool, address prefixes could be assigned to terminals during 
> the registration procedure.
> For route optimization, this could enable LMAs to learn 
> whether a packet's destination address is assigned inside or 
> outside the domain and whether or not routes could be 
> optmization within the LMA's domain (just as example why this 
> could be beneficial).
> 
> I did not say that the MAG should not play any role in 
> address/prefix assignment. I just see the LMA as components, 
> which should play a major role in that compared to the MAG.
> 
> components (in particular control plane) could be relocated 
> from the AR to a more centric component (classified as future 
> work)? Mainly because of various deployment scenarios and 
> implementation specific details, I am hesitating to specify 
> address/prefix assignment for one particular solution in this 
> group. I prefer keeping this generic.
> 
> marco
> 
> 
> RYUJI WAKIKAWA wrote:
> 
> > Hi all,
> >
> > In the v4 support document,I have another concern, whether 
> MAG acts as 
> > a DHCP server or a DHCP relay.
> >
> > should be statically configured on every MAG. I think this is not 
> > flexible operation.
> >> of the base spec. And I am not sure, if this WG should specify 
> >> details, such as the use of DHCP from the MAG etc. at all.
> >
> >
> transmitted

---

From: "Vijay Devarapalli" <[email-masked]>
Date: Thu, 14 Jun 2007 13:37:35 -0700

Ryuji,

> DHCP server can also put near MAG.

The DHCP server can ofcourse be near a MAG. But with some planned
deployments of PMIPv6 where the MAG is in the visited PLMN and the
LMA in the home PLMN, I don't want the DHCP requests crossing PLMNs.
Lets use only the proxy BU and proxy BAck for transporting addresses
for the mobile node.

> >> Requiring the DHCP server support on every MAG isn't too strict for

Please see draft-ietf-mip6-bootstrapping-integrated. The interaction
between the MAG and a local DHCP server would be similar to the
interaction between the NAS and the local DHCP server as described
in the integrated scenario document.

> >> In addition, how can you deliver the other local parameters (DNS

Why would you want a DNS server from the LMA? You can still use your
favorite DNS server discovery mechanism.

> >> configured on every MAG. 

What other parameters does the LMA need to provide the mobile node?

Vijay

I think this is not flexible operation.

---

From: Christian Vogt <[email-masked]>
Date: Fri, 15 Jun 2007 11:05:52 +0300

> However, I believe that the draft MUST capture the specific 
> requirements for that generic approach. For example, MAG should not
> assign or advertise a HNP to the MN before establishing the PMIP
> tunnel for that HNP prefix/address with the LMA.

Ahmad,

I would actually prefer to leave even this open.  Preventing the MAG
from advertising the MN's HNP early on could collide with optimizations.
 E.g., context transfer might inform a new MAG about the HNP before the
LMA registration completes.

What might be valuable to add to the specification is a description of
which action premature HNP advertisements might call for -- such as
having to withdraw a HNP with zero lifetime, as you mentioned.

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Mon, 18 Jun 2007 09:48:04 +0300

Folks,

I have added this issue to the tracker:

  #165: Responsibility of Home Prefix Assignment

  Should the base PMIPv6 spec leave MN-HNP assignment exclusively to the
  LMA, or should it provide an option for the MAG to assign/retrieve the
  MN-HNP before it contacts the LMA?

  This issue affects both v6 and v4 support.  It was raised by Jouni
  Korhonen on 2007/06/09.

According the discussion that we had so far, it seems that a majority of
folks would prefer to leave MN-HNP assignment to the LMA in the v6 and
v4 base documents, and to handle other assignment means as
extensions/optimizations.  If there are no complaints, I would note this
on the issue tracker.

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Mon, 18 Jun 2007 10:31:41 +0300

Ryuji,

maybe here, too, we can stick to a simple technique for the base spec,
and handle more complex techniques by extensions/optimizations.

I agree with Vijay that DHCP relay incurs undesired overhead (and
possibly administrative issues) when the LMA is in a different domain
than the MAG.  I further think that the home address transported in a
PBA should be sufficient for a MAG to form a DHCP Offer message.

Other DHCP configuration parameters could, as you say, be preconfigured
into the MAG -- at least as far as the base spec default is concerned.
It even seems that, for most of those parameters, it actually makes
sense to tailor them to the local (visited) access network rather then
fetching them from a possibly remote LMA.  E.g., it allows the MAG to
point the MN to topologically more optimal services, such as a close-by
DNS server.

What do you think?

- Christian

---

From: "Premec, Domagoj" <[email-masked]>
Date: Mon, 18 Jun 2007 23:47:58 +0200

Hi Christian,

Sorry for jumping into discussion,  

>  E.g., it allows the MAG to point the MN to topologically 
> more optimal services, such as a close-by DNS server.

This sounds as a local breakout. Would MAG bypass the LMA and deliver the traffic localy also in other cases when it is topologicaly closer to the actual destination then the LMA?

thanks
domagoj

> From: Christian Vogt [mailto:[email-masked]] 
> Sent: 18. lipanj 2007 09:32
> To: RYUJI WAKIKAWA
> Cc: Netlmm; Marco Liebsch; 'Vijay Devarapalli'
> Subject: DHCP Server or Relay on MAG in v4? (Re: [netlmm] Q 
> about PMIPv6 MN-HNPassignment)
> 
> Ryuji,
> 
> maybe here, too, we can stick to a simple technique for the 
> base spec, and handle more complex techniques by 
> extensions/optimizations.
> 
> I agree with Vijay that DHCP relay incurs undesired overhead 
> (and possibly administrative issues) when the LMA is in a 
> different domain than the MAG.  I further think that the home 
> address transported in a PBA should be sufficient for a MAG 
> to form a DHCP Offer message.
> 
> Other DHCP configuration parameters could, as you say, be 
> preconfigured into the MAG -- at least as far as the base 
> spec default is concerned.
> It even seems that, for most of those parameters, it actually 
> makes sense to tailor them to the local (visited) access 
> network rather then fetching them from a possibly remote LMA. 
>  E.g., it allows the MAG to point the MN to topologically 
> more optimal services, such as a close-by DNS server.
> 
> What do you think?
> 
> - Christian
> 
> 
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 18 Jun 2007 14:53:43 -0700

> This sounds as a local breakout. Would MAG bypass the LMA and deliver the traffic localy also in other cases when it is topologicaly closer to the actual destination then the LMA?

Perhaps. But in this case, I think Christian is talking about services
like DNS, etc.. Not services as in "IP services".

Vijay

---

From: "Sri Gundavelli" <[email-masked]>
Date: Mon, 18 Jun 2007 21:52:53 -0700

I think there is some confusion here and we are mixing
few cases here. I assume, we don't have an issue with the
below two cases. Just to make sure...

1. The MAG sends a PBU with the Home Network Prefix Option,
   0::/0 and the LMA allocates a prefix. How the LMA allocates
   the prefix is out of scope.

2. The MAG sends a PBU with a specific value for the Home
   Network Prefix Option. How the MAG obtains that prefix is
   out of scope.

Now, between #1 and #2, what is the difference ? We are still
using PMIP signaling for exchanging this information. In one
case the LMA does the allocation and in the other case, the 
MAG registers a specific prefix. Why is it semantically so 
wrong if allow this model. Its a flexibility.

The LMA can always reject a request. DSMIP supports a case
the MN can send a specific value in the IPv4 HoA Option. Its
the same concept that is applied here. Some operators may
choose to offload the addressing functionality to an
addressing server such as DHCP, they may not want to
overload the LMA with the address management. In that case
the MAG, if it predictably learn the allocated prefix, let
it register with the LMA. Why restrict this ? 

Sri

---

From: "Sri Gundavelli" <[email-masked]>
Date: Mon, 18 Jun 2007 22:19:43 -0700

Now, on the issue related to DHCP Relay.

1. In Proxy Mobile IPv6 base document, we are not using 
   DHCP for the prefix allocation. Its only for the
   mobile node to obtain an address from its prefix. How
   the LMA or the MAG obtains the prefix is out of scope.
   It may be based on DHCP PD or local pools.

2. The mobile node's prefix is hosted on the access link.
   RA's are sent with that prefix as the hosted on-link
   prefix. Now, if the mobile sends a DHCPv6 request, the
   DHCP Relay Agent on the access link must set the 
   link-address option to the prefix configured on the
   input interface where the packet originated from. This
   is 3315 behavior. 

Now, how one configures the DHCP server and if it is 
located in the access network or in the home network is
upto the deployment. If we assume the DHCP server is in
the home network and so its a bad idea to relay the
request "all the way" to the home network, that may be
incorrect as that assumption reflects a specific 
deployment topology, in some network configurations the
LMA and MAG may be one hop away. 

Bottom line, there is no issue here and we are not 
adding any thing to the protocol, other than allowing
the MAG to send a valid prefix info in the HNP Option,
form of a registration as supposed to making a request
for a specific prefix.

Sri 

> Sent: Monday, June 18, 2007 9:53 PM
> To: 'Christian Vogt'; 'RYUJI WAKIKAWA'
> Cc: 'Marco Liebsch'; 'Netlmm'; 'Vijay Devarapalli'
> Subject: RE: DHCP Server or Relay on MAG in v4? (Re: [netlmm] 
> Q about PMIPv6MN-HNPassignment)
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 19 Jun 2007 10:47:22 +0200

>    It may be based on DHCP PD or local pools.

In this case one doesn't need that '0::/0' in PBU, right?  DHCP Req will 
request the prefix, not the PBU.

> form of a registration as supposed to making a request

But does one need that '0::/0' in PBU?

Alex

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

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 19 Jun 2007 07:46:29 -0700

Hi Alex,

> From: Alexandru Petrescu [mailto:[email-masked]] 
> Sent: Tuesday, June 19, 2007 1:47 AM
> To: Sri Gundavelli
> Cc: 'Christian Vogt'; 'RYUJI WAKIKAWA'; 'Netlmm'; 'Marco 
> Liebsch'; 'Vijay Devarapalli'
> Subject: Re: DHCP Server or Relay on MAG in v4? (Re: [netlmm] 

MAG specifying the HNP prefix option with 0::/0 is a request
to the LMA asking for a IPv6 home network prefix for the mobile
identified by the NAI. Once the registration is complete, the
MAG advertises the prefix on the access link. Now, if the
mobile sends a DHCP request on the link, the request is not
for a prefix, its for the interface address configuration and
the DHCP server will allocate an address from the prefix where
the request is originating from. So, the draft is not discussing
DHCP PD either at the MAG, LMA or at the MN.

> But does one need that '0::/0' in PBU?

The presence of the option is a request indicator. The IPv4
support draft allows the MAG to request an IPv4 address for
the mobile node. Using these two options, we can selectively
ask if we need IPv4-only, IPv6-only or dual addresses. So,
we need that indicator with the 0::/0.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 19 Jun 2007 17:31:52 +0200

> DHCP PD either at the MAG, LMA or at the MN.

Right... I meant MAG sends DHCP Req for a prefix (not meant MN sends 
DHCP Req).

Alex

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 19 Jun 2007 08:46:21 -0700

> Right... I meant MAG sends DHCP Req for a prefix (not meant MN sends 

We dont specify how the MAG obtains the Prefix. I'm fine with
that. I agree, its out of scope. That was the confusion. 

What is currently there in the draft and what my preference is
to retain the ability for the MAG to specify a specific prefix
in the HNP Option. How it learnt that prefix is not the business
of the base draft. The same HNP Option that the MAG sends, can
be either 0::/0 or a valid prefix. Request vs Registration.

Sri

---

From: Christian Vogt <[email-masked]>
Date: Tue, 19 Jun 2007 19:03:36 +0300

>> This sounds as a local breakout. Would MAG bypass the LMA and deliver
>> the traffic localy also in other cases when it is topologicaly closer
>> to the actual destination then the LMA?
> 

Right, this is what I was having in mind.  Thanks for clarifying.

- Christian

---

From: "Premec, Domagoj" <[email-masked]>
Date: Tue, 19 Jun 2007 18:16:39 +0200

It may not be easy to differentiate between local services like DNS and general IP services. Would the MAG filter the trafic for specific ports and deliver this traffic localy?

A question on routing such localy delivered traffic: how would the DNS server deliver the response to the right MAG where the MN is located?  If it sends reply to the source address, this will be routed to the LMA, right?

thanks
domagoj 

> Sent: 19. lipanj 2007 18:04
> To: Vijay Devarapalli
> Cc: Premec, Domagoj; Netlmm; Marco Liebsch
> Q about PMIPv6 MN-HNPassignment)
>

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 19 Jun 2007 09:33:55 -0700

>    Network Prefix Option. How the MAG obtains that prefix is

No. There is lot more text in the base spec that goes beyond
and says the MAG obtains the home network prefix from a policy
store or a DHCP server. I would prefer restricting it to the
LMA assigning the home network prefix.

Vijay

---

From: "Sri Gundavelli" <[email-masked]>
Date: Tue, 19 Jun 2007 10:38:41 -0700

> LMA assigning the home network prefix.

The base spec is not specifying the specific details on how
the MAG obtains that prefix info. It can be from DHCP, Policy
Store or other means.  I'm fine with the base spec not providing
the details on how it obtains that info. But, IMO, it should
have the ability to suggest a specific prefix and its upto the
LMA to honour request or not.

Sri

---

From: "Chowdhury, Kuntal" <[email-masked]>
Date: Tue, 19 Jun 2007 14:01:53 -0400

> Sent: Monday, June 18, 2007 11:53 PM
> Subject: RE: DHCP Server or Relay on MAG in v4? (Re: [netlmm] Q about
> PMIPv6MN-HNPassignment)
> 
[KC>] Sri, the same type of question was raised when we were discussing
mip6 bootstrapping. The consensus (in mip6 WG of course) was NOT to do
IP address/ HNP management from different locations and ONLY let the HA
to do that in ALL cases. That's where we are headed in MIP6. I don't
think we should do this differently in PMIP6.

---

From: Julien Laganier <[email-masked]>
Date: Thu, 21 Jun 2007 11:11:16 +0200

Hi Sri, Vijay,

I support having only one way of doing prefix/address 
assignment vs. two different ways.

In some contexts the argument about flexibility is 
valid, but in that specific case, for the sake of 
interoperability I think the standard should specify 
one one way of doing prefix/address allocation. Other 
ways might come as extensions as Vijay suggest.

Having multiple ways of doing prefix/address assignment 
without mechanisms to negotiate them between MAG and 
LMA risks compromising interoperability IMHO.

Now if I take the flexibility argument to choose which 
way is best, I definitely prefer the option were 
address/prefix assignment is done at LMA, and the 
prefix/address then transported to MAG. This is 
because it allows the LMA to perform the asssignment 
by being interfaced with DHCP server/policy 
store/AAA/etc. in ways that do not impact the PMIPv6 
protocol (or equivalently the MAG/LMA interface).

Best,

--julien

On Monday 11 June 2007 20:18, Vijay Devarapalli wrote:
> Sri,
>
> I would actually prefer scrapping the option where
> the MAG gets the prefix/address (IPv4 or IPv6) from
> the "policy store" or a DHCP server. Just have one
> mechanism of getting the addresses from the LMA all
> the time.
>
> If there are extensions that need to be done to
> handle prefix/address assignment in a different way
> for some specific deployment, lets do them as
> extensions to PMIPv6. Not include them in the base
> PMIPv6 spec.
>
> > To: [email-masked];
> > [email-masked] Subject: RE: [netlmm] Q about
> > PMIPv6 MN-HNP assignment
> >
> > Hi Jouni,
> >
> > Please see inline ...
> >
> > > A question related to the PMIPv6 MN-HNP &
> > > IPv4-HoA assignments. Bear in mind these are
> > > from -00 versions so I have no idea whether
> > > I cases when a MN boots up for the first time in
> > > a PMIP6-Domain or roams to a new MAG for the
> > > first time there is imho some room for
> > > clarifications when it comes to MN-HNP &
> > > IPv4-HoA assignments. Sections 6.11 and 7.1 in
> > > proxymip6-00 mention briefly that the MAG may
> > > learn the MN-HNP before sending the PBU (e.g.
> > > using AAA). Section 6.11 also describes briefly
> > > a mechanism to learn MN-HNP dynamically (using
> > > ::0 in PBU Home Network Prefix Option). Then the
> > > ipv4-support-00 adds also one more alternative
> > > (IPv4-HAO is 0.0.0.0 or contains address learned
> > > from DHCP). Why there are so many ways to
> > > 'bootstrap' the MN-HNP & IPv4-HOA? This imho
> > > complicates the overall system design. I'd like
> > > to understand the reasoning why the MAG (through
> > > e.g. AAA) may be part of the MN-HNP
> > > 'bootstrapping' and not just let the LMA (and
> > > possibly the AAA behind it) to handle all prefix
> > > assignment and management? Not that I have any
> > > big issues with this but I just want to know ;)
> >
> > are pretty much the same. The key difference is
> > the support for Per-MN-Prefix model for IPv6 and
> > shared-prefix model support for IPv4 addressing.
> > W.r.t the exchange of this addressing information
> > between the LMA and MAG, the semantics are
> > identical. There are only possibilities:
> >
> >
> > I definitely see your point, LMA should be the
> > entity doing the prefix management. It any ways
> > needs to manage the route for that prefix/address.

---

From: Julien Laganier <[email-masked]>
Date: Thu, 21 Jun 2007 11:23:16 +0200

Hi Sri,

On Tuesday 12 June 2007 23:31, Sri Gundavelli wrote:
> Hi Vijay,
>
> This scenario allows deployments to offload the
> address management to DHCP or other addressing
> servers, while the LMA and the MAG manage the data
> path setup for that address. Its a feature
> flexibility and IMO may be leveraged in some
> deployments. 

If we're going along the path of providing maximum 
flexibility for every mechanism so that it can be 
leveraged in *some* deployment, I have doubts that 
we'll be able to call the specification a standard.

We'd better do engineering and design a protocol that 
interoperates so that it can indeed be called a 
standard.

[ Also, maybe you could you point us to what could be 
some of these deployments that need flexibility? ]

> Secondly, by allowing the prefix 
> information to be stored in a policy store, the MAG
> can advertise the mobile node's prefix on the access
> link and while its doing the signaling with the
> local mobility anchor at the same time. The two
> operations can be done in parallel and that reduces
> the handoff latency to some extent.

This is an optimization. There's many ways to optimize 
things, and I think this is better left as extensions 
to a base protocol.

Beside, presumably the policy store is going to be in 
the home domain, right? So it's going to be as long to 
get the prefix from the policy store (1RTT to home) 
than to get the prefix from LMA (1RTT to home). So I 
don't see latency reduction.

If we want to talk latency reduction let's define 
extensions. I'm sure there's plenty of ways to do that 
(e.g. advertize the prefix contained as a landmark 
prefix in the RtSol immediately when RtSol is 
received. Then try to register that prefix to LMA with 
pBU. If LMA finds the prefix to be valid it sends a 
pBAck and we're done. If LMA finds the prefix to be 
invalid, it allocate a correct one and sends it into 
pBAck, and MAG advertize the appropriate prefix and 
invalid the old one with lifetime set to zero.)

Best,

--julien

---

From: Julien Laganier <[email-masked]>
Date: Thu, 21 Jun 2007 11:37:43 +0200

On Tuesday 19 June 2007 19:38, Sri Gundavelli wrote:
> > Sri Gundavelli wrote:
> > > I think there is some confusion here and we are
> > > mixing few cases here. I assume, we don't have
> > > an issue with the below two cases. Just to make
> > > sure...
> > >
> > > 1. The MAG sends a PBU with the Home Network
> > > Prefix Option, 0::/0 and the LMA allocates a
> > > prefix. How the LMA allocates the prefix is out
> > > of scope.
> > >
> > > 2. The MAG sends a PBU with a specific value for
> > > the Home Network Prefix Option. How the MAG
> > > obtains that prefix is out of scope.
> >
> > No. There is lot more text in the base spec that
> > goes beyond and says the MAG obtains the home
> > network prefix from a policy store or a DHCP
> > server. I would prefer restricting it to the LMA
> > assigning the home network prefix.
>
> The base spec is not specifying the specific details
> on how the MAG obtains that prefix info. It can be
> from DHCP, Policy Store or other means.  I'm fine
> with the base spec not providing the details on how
> it obtains that info. But, IMO, it should have the
> ability to suggest a specific prefix and its upto
> the LMA to honour request or not.

Pardon the sarcasm, but the policy store looks to me 
like a pixie dust. I think we should remove any 
reference to it from the base draft (we don't know 
what is in the policy store, what's the protocol 
between MAG and policy store, where the policy store 
is -- in access network, in core, in visited, at home, 
etc.) .

Now regarding the ability for a MAG to suggest a 
specific prefix to the LMA, that could be okay. 

--julien

---

From: Sri Gundavelli <[email-masked]>
Date: Thu, 21 Jun 2007 08:12:11 -0700 (PDT)

Hi Julien,

> specific prefix to the LMA, that could be okay.

Ok. So, you prefer one method of address assignment and
that is through LMA, as Kuntal, Vijay .. prefer. That
is fine. You are ok with the MAG suggesting a specific
prefix value as a hint.

On the comment on policy data, for the MAG to send a PBU
to the mobile node's LMA, it should have that information
some where. This is a configurational or operational data,
you can say, it comes from the mobile node's profile,
from CLI configuration on the MAG, AAA or from other place.
But, that information is essential for the protocol
operation and it should be some where.

Sri

---

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 21 Jun 2007 08:21:13 -0700

> is -- in access network, in core, in visited, at home, 

It is not "pixie" dust. We had called it the AAA server before,
assuming that MAG authenticating the mobile node involves the
AAA infrastructure. Some folks wanted to remove references to
the AAA infrastructure in the base document. So then we started
using "policy store". I don't like it either.

Vijay

---

From: Julien Laganier <[email-masked]>
Date: Thu, 21 Jun 2007 17:42:20 +0200

Hi Sri, 

On Thursday 21 June 2007 17:12, Sri Gundavelli wrote:
> Ok. So, you prefer one method of address assignment
> and that is through LMA, as Kuntal, Vijay .. prefer.
> That is fine. You are ok with the MAG suggesting a
> specific prefix value as a hint.

Yes.

> On the comment on policy data, for the MAG to send a
> PBU to the mobile node's LMA, it should have that
> information some where. This is a configurational or
> operational data, you can say, it comes from the
> mobile node's profile, from CLI configuration on the
> MAG, AAA or from other place. But, that information
> is essential for the protocol operation and it
> should be some where.

This is maybe where I disagree with you (and Vijay it 
seems). What you are saying is that the MAG needs the 
policy store to find the LMA's IP address to which it 
sends the pBU, right?

If so, then let me offer the following reasoning why we 
don't need to mention the policy store (or AAA 
infrastructure for that matter) in the base draft.

Our charter says:

> Out of scope for the first design are: [...] multiple 
mobility anchor points.

Now if some system architectures want to uses multiple 
LMAs, and thus need to resolve a MN identifier into a 
LMA IP address on the MAG, I'd argue that according to 
our charter this is an extension to the first design, 
and hence out of scope of our base draft. Support for 
such scenarios could be either defined in extension 
drafts, or left to be specified by the specific SDOs 
developing such system architectures.

When there's only one LMA in the domain, the MAG just 
need to be configured with its IP address. That's it, 
no need for policy store.

--julien

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Fri, 22 Jun 2007 02:38:32 +0900

Hi Vijay,

sorry for my late response.
please see my comment inline.

> Lets use only the proxy BU and proxy BAck for transporting addresses

Right, but this is not PMIP specific problem, but DHCP generic issue.
Operators can use the IPsec between DHCP relay and server.
I don't have any intention to specify how to protect messages here.

The most important fact is that we don't need any protocol  
modifications to DHCP and PMIP
when DHCP server assigns address via MAG being DHCP relay.

On the other hand, we need certain modification to DHCP if LMA  
assigns address.
See the Sangjin's mail. The DHCP server ID (MAG's IP address) must be  
updated
when a mobile node changes its attached MAG.
http://www1.ietf.org/mail-archive/web/netlmm/current/msg02225.html

Even if the current PMIP and DHCP can naturally support the use of
DHCP server address assignment (without any protocol modifications),
why do we need to prohibit this?
If I can see technical reason, I am totally fine to drop the use of  
DHCP server.

But the issues people raised are:
- one way is simpler
- concerns when MAGs and LMA are located in different administrative  
domains.
- the use of DHCP server is complex. (I don't agree)

I don't see any technical reason here. It sounds like
We specify the PMIP address assignment and want to use it,
let's forget about DHCP and just reject the DHCP server for v4 HoA  
assignment on PMIP.

We did not push the use of DHCP server for IPv4 address assignment in  
the current document.
So let's stay the decision for operators. It is only matter of  
administrative and operational policy.

The current specification provides three ways:
-Static IPv4 HoA assignment
-IPv4 HoA assignment from LMA
-IPv4 HoA assignment from DHCP server via DHCP relay

We can suggest to use LMA as a default in the spec and may give some  
concerns (you raised) for the DHCP server use.
This WG should not prevent any possible deployment configurations  
unless there is strong technical issue.

regards,
ryuji

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Fri, 22 Jun 2007 02:43:32 +0900

Hi Christian

> PBA should be sufficient for a MAG to form a DHCP Offer message.

This is not the only deployment scenario of LMA and MAG.
LMA and MAGs can be located in the same administrative domain.

Again, the use of LMA for IPv4 HoA assignment is not such simple  
technique.
We have to solve the issue of DHCP identifier raised by Sangjin.
If DHCP server is used, we don't have such problem. The server  
identifier stays same.
With DHCP server, PMIP can deal with only mobility support.

As I mentioned in the previous mail, we can add some concerns to the  
DHCP server case in the spec.
We can even suggest to use of LMA address assignment as a default,
but I don't see any strong reasons to prevent DHCP server use for  
IPv4 HoA assignment.

regards,
ryuji

> preconfigured

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Fri, 22 Jun 2007 02:44:42 +0900

Hi Christian

>   MN-HNP before it contacts the LMA?

For IPv4 support, MAG never tries address assignment.
MAG acts as DHCP relay and DHCP server assigns IPv4 HoA  to MN.

> extensions/optimizations.  If there are no complaints, I would note  

There is no technical issue here for IPv4 HoA assignment.
I don't think this WG should prevent this configuration only for  
deployment policy.
The operators should decide it.

regards,
ryuji

---

From: RYUJI WAKIKAWA <[email-masked]>
Date: Fri, 22 Jun 2007 02:47:40 +0900

Hi Julien,

> ways might come as extensions as Vijay suggest.

Interoperability is not the issue here.
If LMA assigns the address, MAG sends PBU (::/0).
If other schemes (DHCPserver or static) are used,
MAG sends PBU with assigned IPv4 address.
The protocol is clearly defined.
This is fully transparent operations to mobile nodes, too.

> protocol (or equivalently the MAG/LMA interface).

If LMA and MAG are in the same administrative domain,
DHCP server can be co-located in LMA.
In this case, the use of DHCP relay agent on MAG is much simpler.

Why do we need to use PBU/PBA between MAG and LMA to request address  
assignment to LMA?
MAG (DHCP relay) just relay the DHCP request message to LMA (DHCP  
server)
and LMA returns DHCP offer back to client via MAG.
No reason to involve PMIP here.

This argument is up to how operators deploy MAG, LMA and DHCP  
entities in their network.
We should leave the door open for operators' decision.

regards,
ryuji

ps. BTW, all my replies are for IPv4 address assignment.

---

From: "Sri Gundavelli" <[email-masked]>
Date: Fri, 22 Jun 2007 00:38:12 -0700

Hi Julien,

> From: julien laganier [mailto:[email-masked]] On 
> Behalf Of Julien Laganier
> Sent: Thursday, June 21, 2007 8:42 AM
> To: Sri Gundavelli

I'm not sure, if we can assume that there is no information
that a MAG needs for serving the mobile node or for creating
the state. There could be roaming policy, on if a MN is allowed
to acnhor at a MAG, if the MAG should enable local direct
routing for the MN's traffic to other mobiles attached to
the MAG, or default binding lifetime for the mobile ...etc.
All of this may come from that profile.

Note that we are not defining any specifics on what this
policy is or how a MAG obtains this. We always state, it
can be from local/remote policy store. It could be AAA or
a local CLI configured data. Our focus is on the messaging
and the routing between the network entities. In the process
of covering this, we need to look at this protocol in the
perspective of a system behaviour. I see some uneasyness when
we use the phrase "policy profile". Its just some config data.
Its a blob, there is no interoperability there and no need
for the blob definition. MAG needs to know, if it can do
a specific operation for a MN, where that data comes, its
upto the implementation.

Also, in the process of standardising this protocol, we may
choose to do only few things in the base document, ex:
shared link support, it does not imply we should not provide
the basic required knobs in the base document for some very
obvious features. We should have some vision on the extensions
for this work, IMHO, that will be comming in the next 1 year.
Else, we may have to obsolete this doc, right after it comes
out. If there is any entry in the charter that restricts some
fundamental work, it can be fixed working with the Chairs
and the AD, as long as it makes sense and we are not
overstepping too much. My 2c.

Sri

---

From: "Sri Gundavelli" <[email-masked]>
Date: Fri, 22 Jun 2007 00:56:22 -0700

Hi Kuntal, 

> Sent: Tuesday, June 19, 2007 11:02 AM
> To: Sri Gundavelli; Christian Vogt; RYUJI WAKIKAWA
> Cc: Marco Liebsch; Netlmm; Vijay Devarapalli

Ok. Are you ok, if we allow the MAG to specify a specific value as
a hint or as a request, like a DHCP client can request for a specific
address ? 

MAG can send either 0::/0 or a specific, say, CAFE::/64 to the LMA
LMA MAY allocated CAFE::/64 or BABA::/64. Its upto the LMA.

Just as in DHCP. Are you ok with this ?

Sri

---

From: "Sri Gundavelli" <[email-masked]>
Date: Fri, 22 Jun 2007 00:57:58 -0700

Hi Damagoj,

> From: Premec, Domagoj [mailto:[email-masked]] 
> Sent: Tuesday, June 19, 2007 9:17 AM
> To: Christian Vogt; Vijay Devarapalli
> Cc: Marco Liebsch; Netlmm
> It may not be easy to differentiate between local services 
> like DNS and general IP services. Would the MAG filter the 
> trafic for specific ports and deliver this traffic localy?
> 
> A question on routing such localy delivered traffic: how 
> would the DNS server deliver the response to the right MAG 
> where the MN is located?  If it sends reply to the source 
> address, this will be routed to the LMA, right?
> 

Not sure, I follow this. There is no local break out. The
mobile does not have any address from the local prefix to
do a breakout. The mobile has only one address and that
is owned by the LMA, so the traffic MUST go through the
LMA. However, there can be direct routing between two
visiting mobile nodes attached to the same MAG, this is
just an optimization and not exactly a local breakout. 

The local breakout is relevant in the multilayer mobility
management scenario, where the home address of the mobile
in the PMIP6 domain is a care-of address from the global
mobility perspective. See Appendix section of the
draft-sgundave-pmip6 (Pre-WG doc). Now, the mobile node
has the ability to use the global address or the home
address from the PMIP6 domain) and do a break out. The
base draft focus is the PMIP6 domain and so the local
breakout in that context is not applicable, with out
combining with global mobility.

Sri

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 22 Jun 2007 11:56:19 +0200

Vijay Devarapalli wrote:
>> like a pixie dust. I think we should remove any reference to it from 
>> the base draft (we don't know what is in the policy store, what's the 
>> protocol between MAG and policy store, where the policy store is -- in 
>> access network, in core, in visited, at home, etc.) .
> 

Just a IMHO.

I do not agree either to use policy store, or the basic PMIP mechanism
to rely on AAA functioning.  (I mean 'basic' PMIP in that without the
home network prefix PMIP wouldn't work).

I also would like to say that deployed cellular systems (and probably
future WiMax too) do rely on well deployed and very functional AAA
infrastructures.  But they do so in different manners, network to
network.  I think each network deployer sees a place of added value in
the way it deploys the access control infrastructure.

Just a thought...

Alex

> 
> Vijay
> 
>>
>> Now regarding the ability for a MAG to suggest a specific prefix to 
>> the LMA, that could be okay.
>> --julien
> 
>

---

From: Suresh Krishnan <[email-masked]>
Date: Fri, 22 Jun 2007 14:01:46 -0400

Hi Julien,
   Like Sri and Vijay, I think it is important to retain the ability to 
select between multiple LMAs, but I agree with you that it should not be 
mandated. One solution maybe to move the LMAA from the mandatory part of 
the MN policy profile into the optional part of the profile.

Cheers
Suresh

---

From: Julien Laganier <[email-masked]>
Date: Mon, 25 Jun 2007 15:55:19 +0200

Hi Suresh,

If the LMA Address goes into the optional part of the 
profile then the mandatory part of the profile will be 
nearly empty:

>   The following are the mandatory fields of the
>   policy profile: 
>
>   o  The mobile node's identifier (MN-Identifier)
>
>   o  The IPv6 address of the local mobility anchor
>      (LMAA) 
>
>   o  Supported address configuration procedures on
>      the link (Stateful, Stateless or both) 

Anyway my point w.r.t. to support of multiple LMAs is 
that we can either:

- specify a protocol that does it. this can be in the 
base protocol if we change the charter or talk to ADs, 
or in an extension. 

- not specify anything and let system architecture 
designer do it for themselve.

But IMHO we should not pretend that we support multiple 
LMAs because we can fetch at the MAG the MN's policy 
profile which contains the LMA's IP address. 

Either we support and we have a protocol, or we don't 
support and we have no protocol. Saying "we can do it" 
without saying how has little value IMHO.

Cheers,

--julien

On Friday 22 June 2007 20:01, Suresh Krishnan wrote:
> Hi Julien,
>    Like Sri and Vijay, I think it is important to
> retain the ability to select between multiple LMAs,
> but I agree with you that it should not be mandated.
> One solution maybe to move the LMAA from the
> mandatory part of the MN policy profile into the
> optional part of the profile.
>
> Cheers
> Suresh
>
> Julien Laganier wrote:
> > Our charter says:
> > Now if some system architectures want to uses
> > multiple LMAs, and thus need to resolve a MN
> > identifier into a LMA IP address on the MAG, I'd
> > argue that according to our charter this is an
> > extension to the first design, and hence out of
> > scope of our base draft. Support for such
> > scenarios could be either defined in extension
> > drafts, or left to be specified by the specific
> > SDOs developing such system architectures.
> >
> > When there's only one LMA in the domain, the MAG
> > just need to be configured with its IP address.
> > That's it, no need for policy store.
> >
> > --julien
> >

---

From: "Sri Gundavelli" <[email-masked]>
Date: Mon, 25 Jun 2007 08:44:17 -0700

Hi Suresh,

I think, this is fine too. We can move the LMAA to the optional
section, assuming the MAG knows where to send the PBU's. In any
case, the MAG needs to know the LMAA address. This can be just
one for all the visiting mobiles and so managed outside the 
profile. If this change makes the draft clear that we clearly
allow allow a scenario where there is just 1 LMA in the domain,
this should be fine.

Thanks
Sri

> From: Suresh Krishnan [mailto:[email-masked]] 
> Sent: Friday, June 22, 2007 11:02 AM
> To: Julien Laganier
> Cc: Sri Gundavelli; [email-masked]
> Subject: Identifying the LMA (was Re: DHCP Server or Relay on 
> MAG in v4?)
> 
> Hi Julien,

---

From: Christian Vogt <[email-masked]>
Date: Tue, 26 Jun 2007 01:32:58 +0300

> but I don't see any strong reasons to prevent DHCP server use for IPv4
> HoA assignment.

Hello Ryuji,

I was referring to the DHCP relay case, where the DHCP messages might
end up crossing administrative domains and hence have an adverse impact
on handover delays.  I wasn't arguing against DHCP per se.  Does this
resolve the issue?

- Christian

---

From: Christian Vogt <[email-masked]>
Date: Tue, 26 Jun 2007 01:37:29 +0300

Ryuji,

but isn't exactly this a means for the MAG to get hold of the mobile
node's IPv4 HoA without the LMA?

- Christian

---

From: "Ahmad Muhanna" <[email-masked]>
Date: Tue, 26 Jun 2007 09:44:26 -0500

Hi Ryuji,

Regards,
Ahmad

> 
> I don't see any technical reason here. It sounds like We 
> specify the PMIP address assignment and want to use it, let's 
> forget about DHCP and just reject the DHCP server for v4 HoA 
> assignment on PMIP.
> 
> We did not push the use of DHCP server for IPv4 address 
> assignment in the current document.
> So let's stay the decision for operators. It is only matter 
> of administrative and operational policy.
> 

[Ahmad]
Never too late, I support keeping all of these options available.

> 
> We can suggest to use LMA as a default in the spec and may 
> give some concerns (you raised) for the DHCP server use.
> This WG should not prevent any possible deployment 
> configurations unless there is strong technical issue.
> 
> regards,
> ryuji
>

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 20 Mar 2007 13:49:24 -0400

Hi Julien,

> without saying how has little value IMHO.

Not really true. Getting it from the MN's policy profile is one 
specified way of doing it, right? Thus the PMIP draft is specifying one 
(optional) way to do it in the base spec. I require this functionality 
to be in the MAG. I do not feel strongly about how to go about achieving 
this, though. Either of the solutions you suggested or status quo (just 
policy profile) are all acceptable to me. But a MAG communicating with 
multiple LMAs is a real and valid use case and MUST NOT be swept under 
the rug just because someone's deployment model just needs one.

Cheers
Suresh

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 20 Mar 2007 14:00:00 -0400

Hi Sri,

> allow allow a scenario where there is just 1 LMA in the domain,

That sounds good to me. I just need these two things to be possible

* The MAG can choose between multiple LMAs
* The MAG can use the MN's policy profile for that purpose.

As long as the draft supports these two items, I am fine with the changes.

Cheers
Suresh

---

From: Sri Gundavelli <[email-masked]>
Date: Tue, 26 Jun 2007 11:02:24 -0700 (PDT)

Hi Suresh,

> As long as the draft supports these two items, I am fine with the changes.

I agree, the ability to query the LMA associated to a MN is
essential and one mechanism is to find that info from the
profile. That's what we have in the draft. This does not
disallow a scenario where there is just one LMA in the domain.

Sri

---

From: <[email-masked]>
Date: Thu, 28 Jun 2007 07:12:40 +0200

> disallow a scenario where there is just one LMA in the domain.

I also want to see what Suresh summarized in the base spec. I
also would add:

 * The MAG can choose between multiple LMAs based on the
   local configuration (e.g. I could configure a LMA per
   realm.. etc)

These are important features for operators. However, as noted
earlier these don't prohibit deployments with a single LMA.

Cheers,
	Jouni