Re: [netlmm] Updated MN-MAG interface draft

[Julien Laganier <[e-mail]>]

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.

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

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

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

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

> I completely agree with Fred about the fact that
> there are many false interpretations of the
> multilink subnet drafts.  

This is your opinion.

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

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

--julien

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