Re: [Roll] Updates of AODV-RPL since IETF101

Hello Rahul,

Thank you for your comments. 

Yes, the RREP-DIO should be unicast hop-by-hop from the TargNode to the OrigNode.

I just realized that for the second scenario that I've described, even for symmetric route, it can also happen. Therefore, the RREP-DIO MUST carry exactly one target option for both symmetric and asymmetric routes.

Best regards,
Remy

> -----Original Message-----
> From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Rahul Arvind Jadhav
> Sent: Saturday, April 21, 2018 11:51 AM
> To: Routing Over Low power and Lossy networks <roll@ietf.org>
> Subject: Re: [Roll] Updates of AODV-RPL since IETF101
> 
> Yes I understand that the 'T' bit in RREP-DIO cannot be elided because of the
> reasons you mentioned. It's fairly reasonable to assume that different nodes
> might end up choosing the same local instance id (given that it is merely 6 bits)
> to the same TargNode.
> 
> Also I don't think using global InstanceID for solving this makes sense at all.
> One scenario is, some 6LRs choose to be a 6LR only for global instances and
> avoid been 6LR for local instances, such scenarios will break. I'm sure there
> will be many more reasons for not using global instance ids for such use-case.
> 
> One more point... You mentioned,  " For symmetric route, the RREP-DIO is
> unicast to the OrigNode, the Target Option can be elided, because the
> addresses can be learnt from the IPv6 header of RREP-DIO."
> Unicasting to OrigNode will not work because intermediate 6LRs won't
> process it anymore. You need unicast hop-by-hop DIO to be used for this so
> that intermediate 6LRs can process it.
> 
> Regards,
> Rahul
> 
> -----Original Message-----
> From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Liubing (Remy)
> Sent: 10 April 2018 09:35
> To: roll@ietf.org
> Subject: [Roll] Updates of AODV-RPL since IETF101
> 
> Hello ROLL,
> 
> We are working on the revision of AODV-RPL. Hopefully, we will submit the
> next version very soon.
> 
> In the current draft, a 'T' bit is used in the RREP-DIO, when it is clear, the
> Target Option encapsulating the OrigNode's address can be elided. Recently,
> we discovered that if local InstanceID is used for the RREQ and RREP
> instances, in RREP-DIO the Target Option MUST be present.
> 
> This is due to the following two reasons:
> 
> 1. The first reason is related to the route entries built in hop-by-hop mode.
> We think one route entry should have at least the following items: the
> route's source and destination addresses, InstanceID, next-hop, lifetime.
> Because the Instance ID is locally assigned, so it should be used with the
> source address, which is the DODAGID. For the a upward route entry, all the
> items can be learnt by related fields in the RREQ-DIO. For an intermediate
> node not on the upward route, it won't get the source address for the
> downward route entry if the Target Option (including the OrigNode's address)
> is elided in the RREP-DIO, even though the InstanceID is well paired without
> any conflict.
> 
> 2. The second reason is to solve the corner case when two router happen to
> use the same local instanceID to do RD to the same TargNode. For example,
> Node A and B are trying to find routes to C, coincidentally, they use the same
> InstanceID. They both are not aware of this situation when they send out the
> RREQs, because the InstanceID is assigned locally.  When A's RREQ arrives at
> C earlier than B' RREQ, C will send out the RREP-DIO to build route to A. The
> InstanceID of RREP-DIO is paired to A's RREQ-DIO, and A's address is elided
> ('T'=0). When receive B's RREQ, C will use another number shifted from the
> original one as the instanceID is already used by the RREP for A. (But B is not
> aware of this.) When the RREP-DIO dedicated for A arrives at B, B thinks this
> RREP-DIO is for itself by identify the paired InstanceID and the DODAGID
> (which is C's address). In this case, B will build route to C, but the routes
> follows A's requirements not B's. And B will not forward the RREP-DIO
>   to A. P
>  r  obably, A will never get its RREP.
> 
> Therefore, if local instanceID is used, the RREP-DIO for asymmetric route
> MUST have exactly one target option, and the 'T' bit in RREP option is no
> longer needed in this case. For symmetric route, the RREP-DIO is unicast to
> the OrigNode, the Target Option can be elided, because the addresses can
> be learnt from the IPv6 header of RREP-DIO.
> 
> Another solution to solve this problem is to use global InsanceID, which is 128
> in total. Is this a feasible solution?
> 
> Looking forward to your comments.
> 
> Best regards,
> Remy
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll