Subject: RE: [netlmm] PMIP-MIP interactions

From: <[email-masked]>
Date: Tue, 1 May 2007 16:22:10 +0200

Hi Gerardo,

See inline...

> -----Original Message-----
> From: Gerardo Giaretta [mailto:[email-masked]] 
> Sent: Monday, April 30, 2007 12:12 PM
> To: Korhonen, Jouni /TeliaSonera Finland Oyj
> Cc: [email-masked]; [email-masked]
> Subject: Re: [netlmm] PMIP-MIP interactions
> 
> Hi Jouni,
> 
> thanks for your comments. Please see inline..
> 
> On 4/26/07, [email-masked] 
> <[email-masked]> wrote:
> > Hi Hesham,
> >
> > > -----Original Message-----
> > > From: Hesham Soliman [mailto:[email-masked]]
> > > Sent: 26. huhtikuuta 2007 15:39
> > > To: Korhonen, Jouni /TeliaSonera Finland Oyj; [email-masked]
> > > Subject: RE: [netlmm] PMIP-MIP interactions
> > >
> > > Hi Jouni,
> > >
> > >  > Thanks for a very interesting draft. After a quick 
> look at it I 
> > > got  > few initial questions for my clarification.
> > >  >
> > >  > Firstly, why rfc4283 & 4285 are ruled out of this analysis?
> > >
> > > => Not necessarily, I'm not sure about the context of 
> your question 
> > > though.
> >
> > As far as I understood some of the issues that were brought 
> up could 
> > be solved e.g. by including MN-ID into Bus. If this is the case why 
> > not stating it (my assumption is that the MN-ID for CMIP and PMIP 
> > would be the same anyway, which makes sense when LMA/HA are 
> the same 
> > entity managed by the same operator).
> >
> 
> I agree with you that this specific issue can be solved 
> including MN-ID in the BUs. There may be other solutions too. 
> But this is exactly what we did not want to discuss in the 
> draft at least in the first version.

I see.. However, in my opinion the draft should discuss more
about solutions (after a short problem introduction) as they
are readily available. We are not changing the protocol etc
but rather relying on existing extensions and some, hopefully
minor, code changes on the LMA/HA side to get things run
smoothly.

> The draft is listing the issues (most of them may be solved 
> as you stated). A consequence of this issue, if solved as you 
> suggested, is that we need to change a rfc3775-compliant MN 
> to work in scenario C. I think this is an important 

Honestly, I would assume that any commercial MIP6 client is
something more advanced than just rfc3775. Just what happened
on the MIP4 clients.

> requirement: the WG should discuss if this is the right way 
> to proceed (i.e. putting requirements on MIPv6 MNs in order 
> to support a scenario where PMIPv6 is also used).

I think exact client requirements belong to other SDOs that wish
to deploy these hybrid solutions. However, having a document
listing known well analyzed solutions, or rather minimum set of
requirements, for different deployment scenarios would be most
useful.

> Gerardo

Cheers,
	Jouni

-- 
Jouni Korhonen
TeliaSonera  

> 
> > >  > Secondly, the assumption in scenario C (cases in 
> figures 9a and 
> > > 9b)  > for "HoA management and lookup key in the BC"
> > > looks a bit odd.
> > >  > The LMA/HA are the same box; thus they then should be able to 
> > > share  > the same 'policy store'/'subscriber db'. So I 
> would assume 
> > > having a  > mapping HoA -> MN-ID on HA side internally should be 
> > > easily doable,
> > >
> > > => Functionally they are separated, but sure, any two boxes can 
> > > share the same credentials in a common database. But, the 
> id of a MN 
> > > may not be the same (regardless of shring the db)
> >
> > And also sharing the same BC..
> >
> > > as far as both functions are concerned.
> > > In other words, within a local domain, every MN may be given a 
> > > different id to use from its home domain's id.
> >
> > Why would those identities be different? Any particular 
> reason to do 
> > so as the LMA/HA is the same entity hosted by the same operator?
> >
> > >  > depending what prefix was allocated to the MN (and 
> MN-ID) on the 
> > > LMA  > side. I would assume MPD handling requires similar 
> > > functionality  > anyway. Or did I miss something?
> > >
> > > => I didn't follow this part, can you elaborate?
> >
> > Just were wondering how mobile prefix solicitations are 
> supposed to be 
> > handled.
> >
> >
> > Cheers,
> >         Jouni
> >
> >
> > >
> > > Thanks,
> > > Hesham
> > >
> > >
> > >  >
> > >  >
> > >  > Cheers,
> > >  >    Jouni
> > >  >
> > >  >
> > >  >
> > >  >
> > >  > -----Original Message-----
> > >  > From: Hesham Soliman [mailto:[email-masked]]  >
> > > Sent: 25. huhtikuuta 2007 12:24  > To: [email-masked]  >
> > > Subject: [netlmm] PMIP-MIP interactions  >  > Folks,  >  > FYI:
> > >  >
> > >  > http://www.ietf.org/internet-drafts/draft-giaretta-netlmm-mip
> > >  > -interactio
> > >  > ns-0
> > >  > 0.txt
> > >  >
> > >  > I didn't see an announcement on the list.
> > >  >
> > >  > Hesham
> > >  >
> > >  >
> > >  >
> > >  > _______________________________________________
> > >  > netlmm mailing list
> > >  > [email-masked]
> > >  > https://www1.ietf.org/mailman/listinfo/netlmm
> > >  >
> > >
> > >
> > >
> >
> > _______________________________________________
> > netlmm mailing list
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/netlmm
> >
> 

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

---

From: "Gerardo Giaretta" <[email-masked]>
Date: Tue, 1 May 2007 18:07:44 +0200

Hi Jouni,

see inline please...

> minor, code changes on the LMA/HA side to get things run

I agree that at the end the draft should also provide some hints about
available solutions. In this first version we just wanted to make sure
we have the full pictures and a common understanding about the
scenarios.

I think draft-devarapalli gives some discussion about the solution
space. We may merge the drats into a WG document.

> something more advanced than just rfc3775. Just what happened

Agree. But we must understand which functionality are specifically
needed to implement the scenarios described in the draft.

> requirements, for different deployment scenarios would be most

Agree.

Gerardo