Re: [Roll] WGLC for draft-ietf-roll-aodv-rpl-02

["Pascal Thubert (pthubert)" <[e-mail]>]

Deal all :

Overall I do not think that the document is ready for the next stage yet. Comparing to draft-perkins-manet-aodvv2<https://datatracker.ietf.org/doc/draft-perkins-manet-aodvv2/> I find the protocol description quite thin and I do not see the inheritance that I expected. E.g. I expected a more direct mapping, like, same behavior, different message formats, this maps to that,  all this ins inherited, or something. Can we do something to provide a better alignment?

I will not be commenting on the asymmetric aspect since a discussion has started already with Rahul.

I do not see lessons learned from experimental RFC6997; Do we have any? In some aspects I even see a (fixable) regression, e.g. the use of target option.

Also, I’m wondering: Do we have implementations?

Please find more  comments below:

5<https://tools.ietf.org/html/draft-ietf-roll-aodv-rpl-02#section-5>.  RREQ Message
I suggest you use a Target option for carry the target and limit your new potion carry the sequence numbers. RFC 6997 does that already. This allows you to do many things, including looking up more than one target with a single RREQ, building more than one RREQ DODAGs for mostly the price of one. Why should we lose that feature?


   In order to establish the upstream route from TargNode to OrigNode,
   OrigNode multicasts the RREQ-Instance message (see Figure 4) to its
   one-hop neighbours.  In order to enable intermediate nodes R_i to
   associate a future RREP message to an incoming RREQ message, the
   InstanceID of RREQ-Instance MUST assign an odd number.

RFC 6997 uses local intances for P2P routes. In fact we defined local instances in RPL RFC 6550 for that specific purpose. The advantage is that the instance number is managed locally by the source. The concept of direction is also already included in a local instance.



   When an intermediate node R_i receives a RREQ message in storing

   mode, it MUST store the OrigNode's InstanceID (RREQ-Instance) along

   with the other routing information needed to establish the route back

   to the OrigNode.  This will enable R_i to determine that a future

   RREP message (containing a paired InstanceID for the TargNode) must

   be transmitted back to the OrigNode's IP address.

Information of lifetime is important here. How long should that transient state be maintained? What happens when a node cannot hold that information because it is temporarily saturated?
RFC6997 has metrics that provide a boundary of how ‘far’ a lookup can get, e.g. the maximum acceptable cost for a route. This avoids a flooding throughout a larger network. What do we have here?


6<https://tools.ietf.org/html/draft-ietf-roll-aodv-rpl-02#section-6>.  RREP Message
Same as the RRAQ, please split to use a target option. This saves you the logic of the T bit, just do not place the target option.



    R determines whether its information is sufficiently recent by

   comparing the value it has stored for the Sequence Number of TargNode

   against the DestSeqno in the incoming RREQ message.

How is the comparison done? You need to explain how you handle wrapping Sequence Number. See RPL  7.2<https://tools.ietf.org/html/rfc6550#section-7.2>.  Sequence Counter Operation




   In order to reduce the need for the TargNode IPv6 Address to be

   included with the RREP message, the InstanceID of the RREP-Instance

   is paired, whenever possible, with the InstanceID from the RREQ

   message, which is always an odd number.  The pairing is accomplished

   by adding one to the InstanceID from the RREQ message and using that,

   whenever possible, as the InstanceID for the RREP message.

This forces the need for a globally unique instance ID. Really a debatable idea and limits the applicability way below what RFC 6997 can do.
How does the instance ID get assigned?

Cheers,

Pascal













From: Roll [mailto:[e-mail]] On Behalf Of Ines Robles
Sent: lundi 6 novembre 2017 15:09
To: roll <[e-mail]>
Cc: peter van der Stok <[e-mail]>
Subject: [Roll] WGLC for draft-ietf-roll-aodv-rpl-02

Dear all,

A Working Group Last call (WGLC) starts today (11/06) until 11/20/2017 for draft-ietf-roll-aodv-rpl-02

The draft is available here:
https://datatracker.ietf.org/doc/draft-ietf-roll-aodv-rpl/

Please review this draft to see if you think that it is ready for publication and send comments to the list stating your view.


Thank you very much in advance,

Peter and Ines.