Re: [netlmm] Updated MN-MAG interface draft

[Alexandru Petrescu <[e-mail]>]

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.

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

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

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

I'm asking because I am not sure what does mean for you (and co-authors)
"function" and "sub-function".

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.

Can MN_ATTACH happen without MAG_GET_MN_MCAST_GROUPS?

Actually, I am very much surprised by this manner of specifying the
MN-AR interface behaviour.

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

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

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

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

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


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

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