Re: [netlmm] Updated MN-MAG interface draft

On Tuesday 15 May 2007 16:00, Alexandru Petrescu wrote:
> Julien Laganier wrote:
> > On Tuesday 15 May 2007 14:45, Alexandru Petrescu 
wrote:
> >> Here are some random comments...
> >>
> >>> 6.2.  MN_GET_ADDR_PARMS Sub-function
> >>>
> >>> The MN_GET_ADDR_PARMS function allows the MN to
> >>> configure IP addresses.  This can be achieved
> >>> via different means, including:
> >>>
> >>> o  Stateless Address Autoconfiguration (SLAAC)
> >>> [RFC2462]: Allows the MN to configure both link
> >>> local and global unicast address(es).
> >>
> >> In order to derive its link-local address with
> >> SLAAC the MN does not need to obtain any
> >> parameter from anybody.
> >
> > Yes, but it needs an RA to generate a global
> > unicast using SLAAC. And to get quickly that RA,
> > it sends an RS.
>
> YEs, but let's stay with the link-local address case
> (not global) for this discussion.

But you talk global bewow...

> >> 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.

> >> 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.

> >>> 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'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. The number of messages depends on the 
specific realization of the function. For example, 
DHCP address allocation can use two or four message 
exchanges.

> The draft seems to say that the "MN_ATTACH" function
> is constituted of the sub-functions MAG_GET_MN_ID,
> MN_GET_ADDR_PARMS, MN_GET_DEFAULT_ROUTER and
> MAG_GET_MN_MCAST_GROUPS.

Right.

> Can MN_ATTACH happen without
> MAG_GET_MN_MCAST_GROUPS?

No, since MAG_GET_MN_MCAST_GROUPS? is a constituent of 
MN_ATTACH.

> 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.

Independent of the way to realize the function, it is 
always required to configure addresses, get a router, 
etc.

> >> Finally, I am not sure why the MN-AR interface
> >> draft drops the support for shared links.  This
> >> makes a clear assumption about where the netlmm
> >> protocol is going to be deployed.  But at the
> >> same time it is silent about that.
> >
> > No, *this* interface doesn't make assumption about
> > where to deploy NETLMM. This document targets
> > Informative so it cannot restrict the scope of the
> > Standard track NETLMM protocol. It restrict *its*
> > scope to point-to-point link, which doesn't
> > prevent another spec to define another interface
> > suitable for shared links. It is also not silent
> > about why it only supports point-to-point link --
> > the "Link Model" subsection describe the issues
> > with shared link and why as a consequence only p2p
> > links are supported by *this* interface.
>
> Ok, so this document is for use only on
> point-to-point links, and only with prefix-per-MN
> model.

Yes.

> 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? 

> At the same time it is intended as INFORMATIONAL
> status, so it is something that can suggest one
> possible behaviour - I agree.

Fine.

> >> I completely agree with Fred about the fact that
> >> there are many false interpretations of the
> >> multilink subnet drafts.
> >
> > This is your opinion.
>
> Yes.
>
> >> In all cases I don't see why that draft can lead
> >> to a conclusion where the NETLMM protocol does
> >> not need to support shared links.
> >
> > Again this draft does not lead to any conclusion
> > regarding applicability or requirements of the
> > NETLMM protocol.
> >
> > 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 links talks about usage of protocol X 
on a shared links??

-- julien

> >> Or - maybe another draft is planned for shared
> >> links support?
> >
> > I cannot talk for others' plan. Off course you can
> > write a draft if an interface supporting shared
> > link is important to you.
>
> Sure, sorry, I didn't mean to make a disturbing
> question.
>
> Alex

_______________________________________________
netlmm mailing list
netlmm@ietf.org
https://www1.ietf.org/mailman/listinfo/netlmm