Subject: [netlmm] Closing the multihoming issue

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

Hello everybody,

<chair hat on>
It seems that the discussion of the multihoming issue and also the other
issues have more or less finished on the mailing list. So, I guess it is
time to more forward.

I hope now that the editors of the base spec would revise the specification,
and we could more to last call of the draft.

I hope that as soon as we get the new revision of the draft we're able to
move to the WG last call.

How soon does the editing team they can produce the next version of the
draft? 

Cheers,

Jonne.
-- 
Jonne Soininen
Nokia Siemens Networks

Tel: +358 40 527 46 34
E-mail: [email-masked]

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

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 24 Oct 2007 18:30:18 -0700 (PDT)

Yes. We will publish the doc in the next couple of
days, possibly by the weekend.

Thanks
Sri

---

From: "Ved Kafle" <[email-masked]>
Date: Thu, 25 Oct 2007 11:11:02 +0900

Sri,

Good that the multihoming issue seems to have settled down. 

I have the following suggestive comments on the draft v-06.

1. Comments on terminology:
As MIPv6 and PMIPv6 are supposed to coexist for supporting global and
location mobility, it is better to use a separate set of terms in PMIPv6
for Home Network Prefix, MN-HoA, MN Home Link, etc.

Definition of MN Home Link is not clear, maybe not required, as there is
no single physical link that actually hosts MN's HNP.  (page 7)

RFC 4830 (NETLMM Problem statements) says that local mobility is
mobility over an access network. The definition of a PMIPv6 domain does
not say anything about the access network.

2. Other minor comments:
Section 6.2 says policy profile mandatory stores "supported address
configuration procedure on the link". Which link? Or the profile stores
many entries for different links? It's not clear.

Section 6.5 talks about three confusing identifiers: stable identifier,
temporary identifier and true identifier. The second bullet says "The
MN-identifier that the policy store delivers to the mobile access
gateway may not be the true identifier of the mobile node." However the
first paragraph says: "this identifier must be stable across the Proxy
Mobile IPv6 domain." Are the "not true" and "stable identifier" the
same?

Many figure captions are missing (Fig. 4, 5, 6, .); 
Captions of Figs 15, 16, 17 are not in proper place. 

You have repeatedly used "it obtained its initial address
configuration". What items are included in an "address configuration" is
not mentioned anywhere. If it's just an address then how about replacing
with "it configured its initial address."

Other minor editorial comments are embeded in the attached file.
Comments start with VK> tags. 

Ved Kafle

> -----Original Message-----
> From: Sri Gundavelli [mailto:[email-masked]] 
> Sent: Thursday, October 25, 2007 10:30 AM
> To: Soininen Jonne (NSN FI/Espoo)
> Cc: [email-masked]
> Subject: Re: [netlmm] Closing the multihoming issue
> 
> 
> 
> > It seems that the discussion of the multihoming issue and also the 
> > other issues have more or less finished on the mailing list. So, I 
> > guess it is time to more forward.
> >
> > I hope now that the editors of the base spec would revise the 
> > specification, and we could more to last call of the draft.
> >
> > I hope that as soon as we get the new revision of the draft 
> we're able 
> > to move to the WG last call.
> >
> > How soon does the editing team they can produce the next version of 
> > the draft?
> >
> > Cheers,
> >
> > Jonne.
> > --
> > Jonne Soininen
> > Nokia Siemens Networks
> >
> > Tel: +358 40 527 46 34

---

From: Sri Gundavelli <[email-masked]>
Date: Wed, 24 Oct 2007 19:21:22 -0700 (PDT)

Hi Ved,

Thanks for the comments. Please see inline.

Regards
Sri

> for Home Network Prefix, MN-HoA, MN Home Link, etc.

We cannot change terminology. This is one area, almost
every one in the WG has opinions and a different from
the rest. So, we cannot rake this up. But, I will ensure
there is no ambiguity any where.

> no single physical link that actually hosts MN's HNP.  (page 7)

I will try to clarify this.

> not say anything about the access network.

This definition was adopted after the discussions in the WG.
But, from the adopted definition, the scope of the domain is
tied to existing the security credentials between the entities.
But, the access network is where the MAG resides. I think its
obvious, I will see if I can clarify this with one additional
line.

> many entries for different links? It's not clear.

This changed with the multi-homing stuff. I'm updating it.

> Mobile IPv6 domain." Are the "not true" and "stable identifier" the

Please see the thread from Jari on this. Essentially, the
identifier passed as part of the access auth MAY NOT always
be the true identifier, it can be a seed for deriving the
true identifier, such as the CUI from RADIUS.

> Captions of Figs 15, 16, 17 are not in proper place.

Yes. XML tag problem. I have this in my list.

> with "it configured its initial address."

Ok. Will clarify it.

> Comments start with VK> tags.

Ok. Will review it.
Thanks a lot for the comments.

---

From: "Alper Yegin" <[email-masked]>
Date: Thu, 25 Oct 2007 06:19:02 +0300

Jonne,

I thread about sufficiency of out-of band HNP is still hanging. 

Here is my unanswered e-mail:
http://www1.ietf.org/mail-archive/web/netlmm/current/msg03956.html

I'm hoping someone can explain why the out-of band mechanisms we rely on
cannot handle HNP assignment, and why we absolutely need an in-band HNP
assignment mechanism.

Alper 

> From: Soininen Jonne (NSN FI/Espoo) [mailto:[email-masked]]
> Sent: Thursday, October 25, 2007 3:40 AM
> To: [email-masked]
> Subject: [netlmm] Closing the multihoming issue
> 
> Hello everybody,
> 
> <chair hat on>
> specification,

Subject: RE: [netlmm] Solution proposal for accommodating multihomed IP nodesinPMIP6
From: "Alper Yegin" <[email-masked]>
To: "'Narayanan, Vidya'" <[email-masked]>, "'Netlmm'" <[email-masked]>
Date: Fri, 19 Oct 2007 12:00:39 +0300

Vidya,

Actually we don't have to name AAA. We can say that HNP is assigned out-of
band. 

There are already few things happening out-of band.
For example, how does MAG discover the LMA for the given MN?
How does the LMA authorize the MAG for sending a (P)BU on behalf of the
given MN?

I'd say these are taken care of by the AAA. But if you want to be more
open-minded in the base spec, you can classify this as the "out-of band"
mechanism, and not lock-in to AAA.

So, what I'm saying is, if the out-of band mechanism is doing those things,
it can also perform HNP assignment.

Alper

> From: Narayanan, Vidya [mailto:[email-masked]]
> Sent: Thursday, October 18, 2007 10:51 PM
> To: Alper Yegin; Netlmm
> Subject: RE: [netlmm] Solution proposal for accommodating multihomed IP
> nodesinPMIP6
> 
> Hi Alper,
> There is no requirement on even having a AAA infrastructure in place to
> deploy PMIP.  So, tying address assignment to AAA is not in the scope of
> the base spec.  It is certainly possible that a given deployment may
> choose to use the AAA for this purpose, but, this cannot be a
> requirement on the protocol.
> 
> Regards,
> Vidya
> 
> > From: Alper Yegin [mailto:[email-masked]]
> > Sent: Thursday, October 18, 2007 12:27 PM
> > To: 'Netlmm'
> > Subject: RE: [netlmm] Solution proposal for accommodating
> > multihomed IP nodesinPMIP6
> >
> >
> > I presume people would agree that we cannot assume there is a
> > single LMA for a whole domain. It is likely that multiple
> > LMAs would be serving a PMIP6 domain.
> >
> > And I presume people also agree that we are talking about
> > identity-based HNP assignment. Not random assignment.
> >
> > Let's go with the assumption that each HNP is pre-assigned to
> > exactly one LMA... like folks are claiming.
> >
> > So, when the MAG needs to send the PBU, how does it know
> > which one of the LMAs it shall send it to? Well, the AAA
> > tells MAG the target LMA. The AAA cannot be telling the id of
> > the LMA without knowing the HNP to be assigned and which LMA
> > that HNP is currently pre-assigned to.
> >
> > See, it comes back to AAA knowing the HNP.
> >
> > So, why not the AAA tell the MAG the HNP as well?
> >
> > That way LMAs and HNPs are not coupled via pre-assignment,
> > which is less efficient and less manageable.  And I'm also
> > under the impression that a lot of problems associated with
> > in-band HNP assignment go away (the problem that currently
> > requires a multi-dimensional ID representation).
> >
> >
> > Alper
> >
> >
> >
> >

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 24 Oct 2007 22:02:56 -0700

> obvious, I will see if I can clarify this with one additional

I think the definition of the Proxy Mobile IPv6 domain is pretty
clear now in the document. I would suggest not adding/modifying
the definition. :)

Vijay

---

From: Christian Vogt <[email-masked]>
Date: Thu, 25 Oct 2007 17:41:29 +0200

> http://www1.ietf.org/mail-archive/web/netlmm/current/msg03956.html

Alper,

from a higher perspective, you seem to be unhappy with the
MAGs being the only entities that can decide whether a home
prefix is moved to a new interface, or whether the new
interface gets a new home prefix.

Would it be sufficient for your scenario to...

(a) pre-configure MAGs to use the "no information" value in
     the Handover Information field of PBU messages, and thus

(b) leave the home prefix selection up to the LMA?

The LMA can then retrieve the home prefix from AAA.  This 
would be compatible with the text that Vidya sent.

- Christian

---

From: "Alper Yegin" <[email-masked]>
Date: Fri, 26 Oct 2007 03:37:14 +0300

Hi Christian,

> interface gets a new home prefix.

Actually, I was not thinking in those terms.

My thinking is this. We are talking about the scheme Vidya sent, which btw
adds to complexity, only because we are trying hard to perform HNP
assignment in-band with PMIP. And I'm arguing that maybe in-band HNP is not
necessary at all. 

I'm seeking a justification that support for in-band HNP assignment is an
absolute necessity. 

Alper