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

[Charlie Perkins <[e-mail]>]

Hello Pascal,

Thanks for the comments!  Please find some follow-up below.


On 12/1/2017 7:35 AM, Pascal Thubert (pthubert) wrote:
>
> 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?
>


AODVv2 has a number of useful features that could be imported into 
AODV-RPL.  As mentioned in another email, we could widen the 
applicability to include unidirectional links by specifying AODVv2's 
black hole detection mechanism.  But this would take a while.  If the WG 
is O.K. with that, I am also O.K. - I am author of AODVv2, and I do not 
see any technical barriers.  If you have particular features of 
interest, please do not hesitate to suggest.  Recent revisions specify 
nicer handling for multi-gateway solutions, multiple metrics, and so on.


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

We don't have text for that comparison.  I hope that it is not a 
requirement.  Perhaps one valuable lesson learned is that no one has 
pointed out how RFC 6997 methods are damaging to implement, so that the 
general idea is not dangerous.  But this is speculation on my part.

I don't see any reason why we cannot specify the target option for use 
within AODV-RPL.  It could be that this will not be completed before the 
submission deadline for IETF 101, but we will work on it.


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

I can only say that the issue was not raised before.  I do not have any 
objection to including the 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.
>

We do have the instance number managed locally by the source, so I think 
this is O.K.


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

I agree it will be a good idea to specify a lifetime for this purpose.

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

This is also a good idea.

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

O.K.  Thanks for the suggestion.

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

Will do.

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

I really do not think that it forces a globally unique instance ID. It 
can occasionally (?rarely?) be limited by what local instance ID numbers 
have already been used by the target node, though.


> How does the instance ID get assigned?
>

Can't OrigNode just pick whatever ID it wants?

Regards,
Charlie P.