Re: [Roll] Comments for AODV-RPL protocol [Issue #184]

[Charlie Perkins <[e-mail]>]

Hello Abdussalam,

Thanks for your comments and suggestions.  Please find some follow-up 
comments below.


On 1/5/2018 12:04 PM, Abdussalam Baryun wrote:
> Hi WG,
>
> The abstract needs to delete any indication that this is a routing 
> protocol. IMHO, this is a route discovery for the RPL protocol.
>

To me AODV-RPL is a variation on RPL.  But I am curious to know more 
about the distinction between a routing protocol and a route discovery 
mechanism that uses routing protocol control messages.


> The discovery of route is part of the routing protocol so we have a 
> different routing which is AODV-RPL routing protocol. The draft needs 
> to mention if this AODV-RPL can work with RPL or not in the same network.
>

Yes, AODV-RPL should interoperate quite well with RPL in the same 
network.  If there is some case that presents difficulty please let us 
know and we will analyze it further.

> IMO, the draft needs to describe the neighbor discovery combined with 
> AODV-RPL route discovery. Also needs to refer to sections 18.4.1 and 
> 18.6 in rfc6550. Or the draft shows the difference from RFC6650 
> discovery. Please refer to sections in RFC6550 RPL.
>

I don't really know what to make of this, until after I can better 
understand the difference between a routing protocol and a route 
discovery mechanism that uses routing protocol control messages.

> AODV-RPL instance are another type of RPL-Instances, so why you write 
> the AODV instance.
>



> Please note that this will conflict with MANET routing instances. 
> Please delete AODV instance. This draft needs to have only RPL 
> instances or this AODV-RPL instance defined as RPL instance.
>

I looked for the strings "AODV instance" and "AODV-RPL instance" but did 
not find.  Could you point to the particular occurrence so that I can 
understand the conflict?


> Delete the writing words 'AODV routing' from the draft, and delete 
> AODV reference as the IPv4-RFC mentioned (can be confusing). The AODV 
> is already well known.
>

Thanks for acknowledging the work on AODV.  I am hoping AODVv2 completes 
Last Call soon.  However, I searched for "AODV routing" but did not 
find.  Could you point to the particular occurrence so that I can 
understand the confusion?


> IMO the operation mode is not used correctly, we need to identify the 
> protocol not by the MoP, we will use them all then, it should be 
> reserved for network operations not for protocols.
>

I am O.K. with recasting the new messages so that they do not use 
another MoP.  That is a very easy change to make.  I will await to see 
if others agree.

> IMHO, the Message format of dio is not correct needs to have type then 
> the length format as shown in the dio format specification rfc6550.

Looking at Figure 14 in RFC 6550, I do not see a length field.   The DIO 
shown in Figure 1 of the AODV-RPL draft strongly resembles Figure 15 of 
RFC 6550.   Did you have something else in mind about this?


>
> IMO, this protocol Sequence number is not different than the sequence 
> number of destination mentioned in RFC6550. You must include the DTSN 
> in this draft. If you thinks I am wrong please mention why here and 
> then it should be clear what is the different than RPL in the draft?
>

I will get back to you on this point.


> Security section needs to include rfc6552/rfc6553
>

RFC 6552 is about the Objective Function Zero, which isn't directly 
related to security.  RFC 6553 is about putting RPL control information 
in Data-Plane packets, which we do not use for AODV-RPL.  However that 
is an interesting idea worth discussion, albeit not necessarily in the 
security section.  I would be very curious to find out if RFC 6553 has 
attracted much implementation.


> I suggest to delete future work section.
>

It's not normative, and fairly reflects some useful discussion that we 
have had.  Do you think it is confusing for the rest of the document?

Regards,
Charlie P.