Subject: Re: [Roll] Comments for AODV-RPL protocol

From: Abdussalam Baryun <[email-masked]>
Date: Sat, 10 Feb 2018 10:52:43 +0200

after a month of no reply, this is a second reminder to editor and WG chair,

please discuss,

AB

On Fri, Jan 5, 2018 at 10:04 PM, Abdussalam Baryun <
[email-masked]> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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?
>
> Security section needs to include rfc6552/rfc6553
>
> I suggest to delete future work section.
>
>
> Best Regards
>
> AB
>

---

From: Ines Robles <[email-masked]>
Date: Sat, 10 Feb 2018 11:03:11 +0200

Hi AB,

Apologizes for late reply.

Ticket 184 was created to track those issues:
https://trac.ietf.org/trac/roll/ticket/184#ticket

Please authors, address these comments.

Thanks,

Ines and Peter

2018-02-10 10:52 GMT+02:00 Abdussalam Baryun <[email-masked]>:

>> 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.
>>
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>
>

---

From: Charlie Perkins <[email-masked]>
Date: Sat, 10 Feb 2018 05:24:12 -0800

Hello folks,

We have been debating various updates to the protocol.  Some fairly 
far-reaching modifications have been proposed which we expect to adopt.  
But these discussions among the authors were not reflected on the list.  
We will respond more fully later in the week -- please excuse the delay.

Regards,
Charlie P.

On 2/10/2018 12:52 AM, Abdussalam Baryun wrote:
> On Fri, Jan 5, 2018 at 10:04 PM, Abdussalam Baryun 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     Hi WG,
>
>     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.
>
>     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.
>
>     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.
>
>     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.
>
>     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.
>
>     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.
>
>     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?
>

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 26 Feb 2018 14:04:08 -0800

Hello Abdussalam,

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

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

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

> 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 

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?

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

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

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

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

---

From: Charlie Perkins <[email-masked]>
Date: Mon, 26 Feb 2018 17:21:00 -0800

Hello folks,

Sorry about that...  below, where I had "Figure 15", I meant to say 
"Figure 14".

Regards,
Charlie P.

On 2/26/2018 2:04 PM, Charlie Perkins wrote:
> 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?
>
>
> 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?
>
>
>> then the length format as shown in the dio format specification rfc6550.
>
> 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?
>
>
>>
> 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.
>
>

---

From: "Liubing (Remy)" <[email-masked]>
Date: Thu, 1 Mar 2018 06:34:26 +0000

Hello Abdussalam and Charlie,

Please find my comments inline.

From: Roll [mailto:[email-masked]] On Behalf Of Charlie Perkins
Sent: Tuesday, February 27, 2018 6:04 AM
To: Abdussalam Baryun <[email-masked]>; roll <[email-masked]>; [email-masked]
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.

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.

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.

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.