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

["Liubing (Remy)" <[e-mail]>]

Hello Abdussalam and Charlie,

Please find my comments inline.

From: Roll [mailto:[e-mail]] On Behalf Of Charlie Perkins
Sent: Tuesday, February 27, 2018 6:04 AM
To: Abdussalam Baryun <[e-mail]>; roll <[e-mail]>; [e-mail]
Subject: Re: [Roll] Comments for AODV-RPL protocol [Issue #184]


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.
[Remy] Since AODV-RPL defines new RPL control message option in the framework of core RPL. The two protocols should work well in the same network.


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?
[Remy] In the version that we are going to submit, we will clearly say in the terminology that AODV-RPL instance (RREQ-Instance and RREP-Instance) are RPL instances.





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.
[Remy] It should be indicated that RFC6997 P2P-RPL has a new MoP besides the four MoPs in core RPL, because none of them can fulfil the requirements of P2P route discovery. It is the same case for AODV-RPL. But maybe it is a solution to let AODV-RPL share the same MoP with P2P-RPL, and we can distinguish these two by identifying the type of the options. However, it is not as convenient as identifying them directly by the MoP.

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?
[Remy] Indeed, for the options in DIO message, a length field should be included.



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.
[Remy] The DTSN is used to trigger DAO transmission, and it is not a sequence number for a route. The actual sequence number for a route is in the Transit Information option which is included in a DAO. Since there is no DAO in AODV-RPL, the DTSN should be set to 0 and ignored, which is also the settings in RFC6997. The two sequence numbers in AODV-RPL inherit AODV.



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.