Subject: Re: [Roll] ROLL-NSA extension for PRE

From: Remous-Aris Koutsiamanis <[email-masked]>
Date: Mon, 11 Mar 2019 23:47:01 +0100 (CET)

Hello,

thank you so much Rahul for your very helpful comments. I have responded
inline to each.
We have also published a new version of the draft taking into account
your comments:
draft-ietf-roll-nsa-extension-01
https://datatracker.ietf.org/doc/draft-ietf-roll-nsa-extension/

Kind regards,
Aris

On Sun, Feb 24, 2019 at 6:41 PM Rahul Jadhav <[email-masked]> wrote:

> Hello All,
>
> Following is my review of draft-ietf-roll-nsa-extension-00:
>
> PRE could be an interesting technique that can be applied to subset of
> traffic which is critical or requires low-latency. The draft talks
> about extending NSA to send the node's parent-set in the DIO such that
> the receiving child node could use this information to choose the
> alternate paths appropriately.
>
> 1. Section 3 talks about three policies for alternative parent
> selection. As i understand different nodes could use any of the
> policies (strict, medium, relaxed) without having to worry about
> interop. Also it will be optimum to choose strict policy followed by
> medium and relaxed respectively. Is this correct?
>

Yes, your intuition is correct on the interop issue and we have added some
clarification in Section 3.4 "Usage".

For the method priority, you are correct. First try to find an Alternative
Parent (AP) with the strict method, if you fail try the medium and if you
still fail try the relaxed. However, this draft only lists these methods as
examples to illustrate the use of the proposed PS extension.
I think it is out-of-scope to propose a specific algorithm for the AP
selection process itself.

2. Regarding compression, i didnt find a dispatch-like bit identifying
> whether the PS addresses are compressed or not. Isn't it required for
> the recipient to know whether the PS is compressed?
>

You have a good point. I have implemented this in Contiki and I
enable/disable 6LoRH compression of the addresses with a #define.
So when enabled, it is ALWAYS used and when disabled it is NEVER used. So
in this case all the nodes in the network either use compression or don't.
I didn't consider a mixed environment.
The problem is that adding a dispatch bit - at a minimum - requires 1 byte.
At the same time using 6LoRH compression the overhead is 1 byte, for the
6LoRH type field.
So, it is the same and we could just mandate that 6LoRH compression MUST be
used.
In terms of implementation complexity, this does put an extra burden on
implementers, but if someone wants to avoid implementing full 6LoRH
compression, and are willing to be less interoperable, they can just
support the 6LoRH type = 4 (i.e. full/uncompressed 16 byte IPv6 addresses)
with just the 1 byte overhead.
Is there a chance someone will object to this 1 byte overhead, when sending
even one IPv6 address is so big?

I have added a description in Section 4. of how exactly the field is to be
laid-out and mandated 6LoRH compression in Section 4.2.

3. Most of the text is 6tisch specific and specifically says 6tisch
> nodes whilst explaining the technique. I believe the technique is
> generically applicable to non-6tisch scenarios as well. True?
>

To my mind yes. The idea behind PRE is general and the information in the
PS is strictly RPL specific. It does not have a dependency on 6TiSCH. It's
just we are implementing and testing on 6TiSCH.
I have removed this dependency, although I have left mentions to 6TiSCH.

4. I think a section on reparenting is needed. How would the child
> node behave when its parent is reparenting? During reparenting, the
> parent might send its updated DIO with its new parent set. The
> implications of using CA strict policy in this case might result in
> child choosing a different AP which certainly is not desirable if the
> parent still has connectivity to its old parent and the reparenting is
> done based on metric changes.
>

The scenario you describe is definitely possible. Depending on the case it
might go differently:
- While still using strict, select another AP
- Fallback to Medium, select the same AP
- Fallback to Medium, select another AP
- Fallback to Relaxed, select the same AP
- Fallback to Relaxed, select another AP

It is not clear to me what can be done. Maybe a hysteresis function can be
applied to the AP like it is applied to the preferred parent. However, my
impression from discussing the draft at the last IETF is that this specific
document should be relatively focused on the - relatively small - extension
to the MC NSA fields.
The issue you highlight is important but I think that either we do another
separate document addressing them, or we expand the scope of this document
and we cover not only re-parenting but also specific suggestions for AP
selection methods and maybe other issues.

> 5. I am wondering if it is possible to attach a field "such as
> min-priority [1]" field which is a derivative of the metric
> calculation in context to every parent in the parent-set. This greatly
> helps the child nodes in deciding the CA policy to use even though as
> I understand that the parent-set is already attached in NSA in the
> decreasing preference order.
>

This is an interesting idea. If I understand correctly, you would like a
value which quantifies how "good/available" each parent in the parent set
is. Via [1], you already have this for a node's parent set, with the
inclusion of this information in the PS information, we could have this
information for each node's grandparent set. While the parents in the PS
are ordered, the ordering does not quantify how much better/worse the
parents are.
An idea would be:
We can use one of the unused bits (below P) of the 6LoRH type field (only 5
out of 8 are used) to signify presence of an extra "preference" field.
If P=1 then before each address there is a field (say 1 byte) with
expresses the "goodness/availability" of the corresponding parent.
If P=0, then there is no such field, it's just compressed IP addresses.
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Routing-MC-Type|Res Flags|P|C|O|R| A   |  Prec | Length (bytes)| |=>MC
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Res       |  Flags    |A|O|    PS  type   |   PS  Length  | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |=>NSA
|P| 6LoRH type  | Opt: Pref 1   |IPv6 address 1 ....            | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Opt: Pref 2   |IPv6 address 2 ....                            | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Opt: Pref 3   |IPv6 address 3 ....                              |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Alternatively, we can have a second TLV just for the
"goodness/availability" which would have an overhead of 2 bytes (for the
TLV's Type and Length fields).

What are your thoughts?

Regards,
> Rahul
>
> [1] draft-richardson-6tisch-roll-enrollment-priority-01
>
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>