Re: [netlmm] Updated MN-MAG interface draft

Julien Laganier wrote:
> Folks,
> 
> I've updated the MN-*MAG* interface draft to reflect 
> discussions we had in the WG (per-MN subnet, pt-2-pt 
> link, etc.). You can read a pre-version there:
> 
> <http://julien.laganier.free.fr/draft-ietf-netlmm-mn-ar-if-pre02_20070514.txt>
> 
> Please read and comment on the mailing list.

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

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.

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

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.

I completely agree with Fred about the fact that there are many false 
interpretations of the multilink subnet drafts.  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.

Or - maybe another draft is planned for shared links support?

Alex

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________

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