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

[Rahul Arvind Jadhav <[e-mail]>]

Thanks Remy,

Thus I assume T bit will be removed? 

Another Question: Section 6.3.3. last para talks about handling paired instanceID collision on TargNode. The details are insufficient regarding how to handle "shifting of instanceID".  RREP option has SHIFT field to indicate the shifting, but when it reaches OrigNode and if the resulting shifted instanceID is already in use by OrigNode then how should the handling be? How to clean-up the states established on 6LRs because of previous RREQ-DIO instance? Will shifting result in another round of RREQ-DIO, RREP-DIO ?
IMO, this warrants a separate section.

Regards,
Rahul


-----Original Message-----
From: Roll [mailto:[e-mail]] On Behalf Of Liubing (Remy)
Sent: 23 April 2018 18:07
To: Routing Over Low power and Lossy networks <[e-mail]>
Subject: 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:[e-mail]] On Behalf Of Rahul Arvind 
> Jadhav
> Sent: Saturday, April 21, 2018 11:51 AM
> To: Routing Over Low power and Lossy networks <[e-mail]>
> 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:[e-mail]] On Behalf Of Liubing (Remy)
> Sent: 10 April 2018 09:35
> To: [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll
> 
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll

_______________________________________________
Roll mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/roll