Re: [Roll] RUL and RootACK

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

Hello Rahul

You should look at fig. 5 in https://tools.ietf.org/html/draft-ietf-roll-unaware-leaves-15#section-9.1.1 not fig. 9 since we are using Non Storing signalisation for RULs in all cases. IOW the root ack problem does not exist for RULs.

More details:

The idea is for the root to answer a non storing DAO with a DAO ack to the sender.

Normally In NS mode the sender is the RAL that advertises its parent as transit and the DAO Ack serves as root ack and confirms reachability.

In the RUL case, the Root answers to the parent. That answer confirms to the parent that the RUL is reachable and serves as root ack. Then the parent sends the NA(EARO) which confirms reachability to the RUL.

Are we good or do I miss something?

Pascal

Le 4 juin 2020 à 15:00, Rahul Jadhav <[e-mail]> a écrit :


Hi Pascal,

Last we discussed handling storing mode RUL flow with RootACK in a way that NA is sent to the RUL after it gets the RootACK. This way RUL can initiate its app traffic once e2e path is established.

Figure 9 in https://tools.ietf.org/html/draft-ietf-roll-unaware-leaves-15#section-9.1.2 handles Storing mode First registration flow for RULs.

My problem is (consider the figure 9), how will the Root know whom to send the RootACK. In the regular cases, the target node in DAO is the destination for RootACK. But in this case, the target is RUL and RootAck cannot be sent to RUL. For external targets, can we use ParentAddr in Transit Information Option to send this field? Anyways the 6LR indeed is the parent node for RUL.

Any thoughts/suggestions?

Thanks,
Rahul