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

From: "Mohamed Khalil" <[email-masked]>
Date: Thu, 14 Jun 2007 15:31:48 -0500

I think, it is better, to leave the address/prefixes assignment
allocation options generic to allow for different mechanism for
address/prefix allocation.

Hi Kuntal,

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

Thanks
Sri 

> -----Original Message-----
> From: Chowdhury, Kuntal [mailto:[email-masked]]
> Sent: Tuesday, June 12, 2007 8:54 AM
> To: Vijay Devarapalli; Sri Gundavelli; [email-masked];
> [email-masked]
> Subject: RE: [netlmm] Q about PMIPv6 MN-HNP assignment
> 
> 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
> 
> 
> > -----Original Message-----
> > From: Vijay Devarapalli [mailto:[email-masked]]
> > Sent: Monday, June 11, 2007 1:18 PM
> > To: Sri Gundavelli; [email-masked]; [email-masked]
> > Subject: RE: [netlmm] Q about PMIPv6 MN-HNP assignment
> > 
> > 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
> > 
> > > -----Original Message-----
> > > 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 ...
> > >
> > >
> > > > -----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,
> > > >
> > > > 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 ;)
> > > >
> > >
> > > 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
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > > Cheers,
> > > > 	Jouni
> > > >
> > > > _______________________________________________
> > > > netlmm mailing list
> > > > [email-masked] https://www1.ietf.org/mailman/listinfo/netlmm
> > >
> > > _______________________________________________
> > > netlmm mailing list
> > > [email-masked] https://www1.ietf.org/mailman/listinfo/netlmm
> > >
> > 
> > _______________________________________________
> > netlmm mailing list
> > [email-masked] https://www1.ietf.org/mailman/listinfo/netlmm
> 
> 
> "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."

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

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