Re: [netlmm] Updated MN-MAG interface draft

[Alexandru Petrescu <[e-mail]>]

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

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.

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

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

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

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

I don't read this document as a list of implementation instructions.  I 
read it as a documentation of what somebody may have implemented.

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

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

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

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

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