Subject: Re: [netlmm] Re: I-D ACTION:draft-ietf-netlmm-mn-ar-if-02.txt

From: Julien Laganier <[email-masked]>
Date: Fri, 1 Jun 2007 16:21:35 +0200

On Wednesday 23 May 2007 11:56, Bruno Mongazon-Cazavet 
wrote:
> Hi Julien & Sathya,

Hi Bruno,

> I took some time to read your draft at: 
<http://www.ietf.org/internet-drafts/draft-ietf-netlmm-mn-ar-if-02.txt>

Thanks for doing so!

> Generally speaking, i think your draft contains
> interesting "informational" data related to the
> operation of PMIPv6. In particular, where the PMIPv6
> draft only refers to existing IPv6 standards (for
> the sake of concision), your draft provides
> pertinent details and useful protocol charts that
> may help to understand the whole picture. There are
> also some interesting points regarding deployment
> architecture and issues.

Good to hear that the document has interesting 
informational data -- as per our charter we target 
publication as an informational RFC.

> However i really don't understand the need for
> defining something you call "an interface"  between 
> MN and MAG.

That's what our charter calls for.

> My understanding of PMIPv6 is that "the interface"
> between MN and MAG is just regular IPv6.

No it's not. If you look in the document some of the 
things just don't work like in regular IPv6, e.g. all 
MAGs are required to have same link-local address, a 
MAG needs to sollicit a MN after receiving an RS if 
SEND is used to secure movement detection in the 
NETLMM domain.

> I guess what you describe as an interface (with
> MN_ATTACH, MN_DETACH functions and sub-functions) is
> more a local and logical interaction trigger than a
> protocol interface. Having a paragraph with title
> "Attachment of mobile to the network"  would have
> been sufficient for me to describe what you call
> MN_ATTACH function.

Well, the interface really has 2 functions (ATTACH and 
DETTACH) that needs to be implemented, no matter which 
are the protocols in use. 

> In that sense, the "interface" term and related
> talks as carried in the title and along the draft is
> IMHO confusing and deserves the pertinent
> "information" you otherwise provide in the draft.
>
> To summarize, i would think your draft can gain
> interest (it definitely has interesting information)
> if the "interface"-oriented terminology and focus is
> replaced by a "behavior"-oriented terminology. If
> you evolve in that sense, i would appreciate your
> draft to cover other operational aspects of PMIPv6
> such as shared-link aspects.

As I said already the charter calls for publication of 
an Informational interface between MAG and MN. This 
document is a placeholder for that. If you think 
something is missing from the document, feel free to 
suggest additions to the document. 

As for shared links, the WG consensus is that first 
deliverables of this WG assume point-to-point link and 
that shared link support is out-of-scope.

Thanks for the comments. Best,

--julien

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

---

From: Marco Liebsch <[email-masked]>
Date: Mon, 04 Jun 2007 14:29:02 +0200

Hi Julien, Bruno,

>are the protocols in use. 
I think I understand what's confusing here.  In my understanding,
MN_ATTACH and MN_DETACH could really be local indications on the
component, which implements the MAG (well, such as the AR). The means
to provide this information results from operation of NDP, SEND, DNA, etc
on the MN-AR interface. This might conflict somehow with Figure 3.

Just a proposal for clarification: MN_ATTACH and MN_DETACH could be
a 'procedure' instead of a 'function'. As part of each procedure,
MAG_GET_MN_ID, MN_GET_ADDR_PARMS, MN_GET_DEFAULT_ROUTER as well as
MAG_GET_MN_MCAST_GROUPS could represent a real API function, which
either provides information to the NetLMM module by means of an
indication or allows the NetLMM module to feedback info to the
components (by means of an API call), which operate the MN-AR interface.

I think you need to provide a bi-directional API here, as for example
the LMA might choose the MN's home network prefix, which is then
to be given from the MAG's NetLMM module to the NDP, SEND, DNA, etc 
components.

Regarding the figures, I think Figure 2 perfectly illustrates what's
meant with this draft. If you agree to what I wrote above, then the
indication and API call could be included to this figure.
Figure 3 does not say too much and confuses what the draft focuses
on, in my opinion.

marco