Re: [netlmm] Updated MN-MAG interface draft

[Julien Laganier <[e-mail]>]

On Tuesday 15 May 2007 22:16, Alexandru Petrescu wrote:
> [The reference you posted to this draft is no longer
> valid:
> http://julien.laganier.free.fr/draft-ietf-netlmm-mn-
>ar-if-pre02_20070514.txt changed to:
> http://julien.laganier.free.fr/draft-ietf-netlmm-mn-
>ar-if-pre02_20070515.txt]

Right: Fred wanted his name out of the draft, hence the 
update.

> Julien Laganier wrote:
> >>>> So no need to send any message.  I'm not sure
> >>>> whether MN_GET_ADDR_PARMS corresponds to
> >>>> actually sending a message over the wire.
> >>>
> >>> See above RS and RA. And w.r.t. link local
> >>> unicast, the MN needs to do DAD, so again
> >>> message are sent over the wire.
> >>
> >> Yes, I agree.  So does this mean that
> >> MN-GET-ADDR-PARMS can actually be a sequence of 3
> >> messages (not just one) and a pre-determined
> >> amount of wait time, ie DAD.
> >
> > Note that waiting time can be done in parallel
> > with other steps if optimistic DAD is done.
>
> Right... I think other sub-functions of the
> MN_ATTACH function can also be intertwined, making
> the the separation of functions in sub-functions
> probably superfluous.

Yes they can be interlaced. I do not think the 
separation is superfluous since these are independent 
elementary tasks that need to occurs. Of course two 
tasks might be implemented with a single protocol 
(e.g. RS/RA exchange for router configuration and 
stateless address configuration), but also with 
distinct protocols (e.g. RS/RA exchange for router 
configuration and DHCP for statefull address 
configuration).

> >>>> In same bulleted item maybe one needs to
> >>>> reference rfc2464 for Ethernet, draft-for-16ng
> >>>> and any other rfc corresponding to IPv6 over
> >>>> wireless link-layers for which NETLMM is
> >>>> pertinent.
> >>>>
> >>>> Also, rfc2462 is being updated by
> >>>> draft-ietf-ipv6-rfc2462bis-08.
> >>>
> >>> s/is being/will be/ (2462bis isn't published
> >>> yet)
> >>
> >> YEs, I agree.  Just to say good to mention it.
> >
> > Will be when it's published. It doesn't change
> > much anyway.
>
> Well... I'm not sure.
>
> We are here on the MN-AR interface, so for example
> we should say what AR sends to MN in order for MN to
> use DHCP instead of SLAAC.  The preferred method in
> 2462 is to use 'M' bit whereas in 2462bis the
> tendency seems to be no longer use that 'M' bit for
> this purpose.
>
> It's probably true that this draft doesn't talk
> about 'M' bit in RA, or 'A' bit in prefix option...
> but the 16ng corresponding draft does talk about it.
>  And, if you agree that 16ng draft should be
> referenced here then we end up with the necessity of
> commonly specifying (commonly between this draft and
> the 16ng draft) that AR behaviour...
>
> There are probably other news in 2462bis (compared
> to 2462) that may influence the way MN-AR interface
> should happen.

IMHO these are details, and we should reference 2462bis 
once it obsoletes 2462.

> >>>>> o Dynamic Host Configuration Protocol for IPv6
> >>>>> (DHCPv6) [RFC3315]: Allows the MN to configure
> >>>>> global unicast address(es). Typically not used
> >>>>> to configure link local unicast address(es).
> >>>>>
> >>>>> o IP Version 6 over PPP
> >>>>> [I-D.ietf-ipv6-over-ppp-v2]: Allows the MN to
> >>>>> configure link local unicast address(es).
> >>>>
> >>>> For deriving its link-local address with PPP
> >>>> the MN MUST send messages to negotiate the IID.
> >>>> Again, I'm not sure whether MN_GET_ADDR_PARMS
> >>>> corresponds to an operation of sending a
> >>>> message.
> >>>
> >>> Yes it needs to send message.
> >>
> >> One message? Several?
> >
> > This is specified in IPv6 over PPP and PPP spec.
> > This document is not supposed to specify PPP.
>
> I agree... I think I'm understanding it better the
> more I'm reading it. It looks more and more that
> this is not a protocol specification but more a
> documentation of software running on machines. 
> Probably its informational status is fine.

No this is not a protocol specification, protocol are 
specified in their standard track RFCs. This is a 
documentation of what should be implemented at minimum 
on this interface. A document with a somehow similar 
intent documents "Internet Protocol Version 6 (IPv6)
for Some Second and Third Generation Cellular 
Hosts" [RFC3316].

> >> I'm asking because I am not sure what does mean
> >> for you (and co-authors) "function" and
> >> "sub-function".
> >
> > The MN_ATTACH function happens is executed when
> > the MN attaches. It is composed of sub function
> > realizing distinct tasks. It's unrelated to the
> > number of messages.
>
> I don't think all tasks are distinct.
>
> Getting the MN ID happens at the same time as ND or
> DHCP, if the ID is the MAC address.

As I said earlier, the fact the a task is distinct from 
another task doesn't mean both tasks can't happen by 
way of a single protocol.

Take the example of address configuration vs. router 
configuration. DHCPv4 does both. DHCPv6 does only the 
former, while Router Discovery does the latter.

[...]

> >> Actually, I am very much surprised by this manner
> >> of specifying the MN-AR interface behaviour.
> >
> > Well, as I said above, the interface isn't the
> > place to specify DHCP, PPP, SLAAC, etc. These are
> > defined in their own specifications.
> >
> > The interface specification is the place
> > describing what functions should be implemented at
> > the interface, not how. How these are realized is
> > dependent on the underlying link technology and on
> > the deployment.
>
> I don't read this document as a list of
> implementation instructions.  I read it as a
> documentation of what somebody may have implemented.

This is a documentation of what function *needs* to be 
implemented in the interface.

> Also, I wanted to suggest that if this document is
> the result of a EU project Ambient Networks then it
> makes sense to have that project name in the title,
> maybe something like "Network-based Localized
> Mobility Management Interface between Mobile Node
> and Mobility Access Gateway in Ambient Networks".

No it doesn't make sense. This interface isn't 
restricted to Ambient Networks. It's valid for 
point-to-point links between MAGs and MNs of a NETLMM 
domain.

Besides, this document is not the *result* of an EU 
projects, and nothing in it suggests so (If you read 
carefully the Acknowledgment Section, it says that 1. 
I'm "partly funded by Ambient Networks" and 2. the 
"views and conclusions contained herein are those of 
the authors and should not be interpreted as 
necessarily representing the official policies or 
endorsements, either expressed or implied, of the 
Ambient Networks project")

> >> It is strange though that same document refers to
> >> DHCP and to SEND and to DNA, all three being
> >> widely used on shared links and
> >> shared-prefixes-per-MN (not prefix-per-MN).
> >
> > I don't see what's strange in this. Do you mean
> > DHCP/SEND/DNA shall be used only on shared links
> > and shared subnet per link?
>
> Has one ever seen DHCP/SEND/DNA running on
> non-tunnel point to point links?  I haven't that's
> why I expressed my surprise.

You can't have seen everything. Even if you had, 
something new may appear in the future.

> I have seen DHCP and RS/RA over tunnel interfaces,
> but not on point-to-point links like ppp.

Ah. How do you think address configuration is done on 
the MN when PPP is used then?

> >>> It simply define *one* interface which works for
> >>> p2p links.
> >>
> >> Could one please state in the document somewhere
> >> that DNA, DHCP and SEND have been widely used on
> >> shared links (not p2p).
> >
> > Why should a document describing an interface for
> > point-to-point link talk about usage of protocol X
> > on a shared links??
>
> Right... maybe then put in the title "for
> point-to-point links".

This makes sense. However the title gets verbose:

"Network-based Localized Mobility Management Interface 
between Mobile Node and Mobility Access Gateway for 
Point-to-Point Link"

--julien

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