Subject: [Roll] Rplinfo WGLC

From: peter van der Stok <[email-masked]>
Date: Fri, 10 Mar 2017 07:22:06 +0100

Hi Roll,

Recently a new version of rplinfo has been submitted.
Major change is to the security section.
We like to do a WGLC before submitting the draft to IESG.

Although many discussions took place, please, have a look at the draft 
and confirm your approval of this document.
This WGLC ends at 24 March.

Greetings, and thanks,

Peter

-- 
Peter van der Stok
vanderstok consultancy
mailto: [email-masked]
www: www.vanderstok.org
tel NL: +31(0)492474673     F: +33(0)966015248

---

From: Rahul Jadhav <[email-masked]>
Date: Sun, 12 Mar 2017 00:19:10 +0530

+1

Following are some comments tagged [RJ] (the numbered lines are from the
draft):
A.
674   | Removed   | --       | --            | IP-in-IP(RPI) | --         |
675   | headers   |          |               |               |            |
676   | Re-added  | --       | --            | --            | --         |
677   | headers   |          |               |               |            |
678   | Modified  | --       | --            | IP-in-IP(RPI) | --         |
679   | headers   |          |               |               |            |
680   | Untouched | --       | --            | --            | RPI        |
681   | headers   |          |               |               | (Ignored)  |
682   +-----------+----------+---------------+---------------+------------+
[RJ] Once the IP-in-IP(RPI) header is removed at 6LR_i … which is the other
IP-in-IP(RPI) header which gets modified ?

B.
[RJ] One of the side-effects of always inserting IP-in-IP RPI header at
6LR_1 (when the traffic originates at ~Raf) is that now all the packets
will go through the 6LBR even though there exists a shorter P2P path to the
destination 6LN in storing mode.
Consider the case where ~Raf sends a packets to 6LN (in RPL domain) and
6LR_i has a shorter P2P path to the 6LN ....

C.
967   +---------------+-------------+---------------+--------------+------+
968   | Header        | 6LBR        | 6LR_i(i=1)    | 6LR_n(i=n)   | IPv6 |
969   +---------------+-------------+---------------+--------------+------+
970   | Inserted      | (opt: RPI), | --            | --           | --   |
971   | headers       | RH3         |               |              |      |
972   | Removed       | --          | RH3           | --           | --   |
973   | headers       |             |               |              |      |
974   | Re-added      | --          | --            | --           | --   |
975   | headers       |             |               |              |      |
976   | Modified      | --          | (opt: RPI),   | (opt: RPI),  | --   |
977   | headers       |             | RH3           | RH3          |      |
978   | Untouched     | --          | --            | --           | RPI  |
979   | headers       |             |               |              |      |
980   +---------------+-------------+---------------+--------------+------+
[RJ] Shouldn’t the RH3 be removed in 6LR_n column ?

D.
1040       | Re-added headers  | --   | --    | --   | --             |
1041       | Modified headers  | --   | RPI   | --   | --             |
1042       | Untouched headers | --   | --    | --   | RPI (Ignored)  |
1043       +-------------------+------+-------+------+----------------+
[RJ] RPI header should be shown in Untouched headers row for 6LBR column ?

E.
1216   | headers |             |      |              |       |             |
1217   | Modifie | --          | --   | --           | --    | --          |
1218   | d       |             |      |              |       |             |
1219   | headers |             |      |              |       |             |
1220   | Untouch | --          | --   | --           | --    | --          |
1221   | ed      |             |      |              |       |             |
1222   | headers |             |      |              |       |             |
1223   +---------+-------------+------+--------------+-------+-------------+
[RJ] Won’t RPI1 be modified in 6LR_ia and RPI2 be modified in 6LR_id ?

F.
1390   [I-D.ietf-roll-routing-dispatch] shows how the destination=root, and
1391   destination=6LN IP-in-IP header can be compressed down to {TBD}
1392   bytes.
[RJ] Don’t understand the relevance of this stmt here … it is already
mentioned that routing-dispatch will help compressing the headers… Based on
my understanding of routing-dispatch, it won’t be possible to come up with
a compression figure as to how many bytes can be reduced in the given
scenario of root—> 6LN routing.

Same comments could be found inline in the attached draft..

Regards,
Rahul

On 10 March 2017 at 11:52, peter van der Stok <[email-masked]> wrote:

> Although many discussions took place, please, have a look at the draft and
> confirm your approval of this document.
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll
>

---

From: Michael Richardson <[email-masked]>
Date: Sat, 11 Mar 2017 17:09:51 -0500

Rahul Jadhav <[email-masked]> wrote:
    > Following are some comments tagged [RJ] (the numbered lines are from

I couldn't understand your comments because your mail program removed all the
spaces from the diagrams.  I wasn't sure if you were editing the diagram or
not.

    > Same comments could be found inline in the attached draft..

okay, that's perhaps easier.

652	5.8.  Example of Flow from Internet to non-RPL-aware-leaf
...
669	   +-----------+----------+---------------+---------------+------------+
670	   | Header    | Internet | 6LBR          | 6LR_i         | IPv6       |
671	   +-----------+----------+---------------+---------------+------------+
672	   | Inserted  | --       | IP-in-IP(RPI) | --            | --         |
673	   | headers   |          |               |               |            |
674	   | Removed   | --       | --            | IP-in-IP(RPI) | --         |
675	   | headers   |          |               |               |            |
676	   | Re-added  | --       | --            | --            | --         |
677	   | headers   |          |               |               |            |
678	   | Modified  | --       | --            | IP-in-IP(RPI) | --         |
679	   | headers   |          |               |               |            |
680	   | Untouched | --       | --            | --            | RPI        |
681	   | headers   |          |               |               | (Ignored)  |
682	   +-----------+----------+---------------+---------------+------------+
[RJ] Once the IP-in-IP(RPI) header is removed at 6LR_i … which is the other IP-in-IP(RPI) header which gets modified ?

The diagram may be in error.
The IPIP header is added at 6LBR, it is modified (rank#) at each 6LR, but
never removed.  I've pushed a fixed.

[RJ] One of the side-effects of always inserting IP-in-IP RPI header at 6LR_1
     (when the traffic originates at ~Raf) is that now all the packets will go
     through the 6LBR even though there exists a shorter P2P path to the
     destination 6LN in storing mode. Consider the case where ~Raf sends a
     packets to 6LN (in RPL domain) and 6LR_i has a shorter P2P path to the
     6LN ....

Yes, that's a good point.  I don't see a way to fix that, do you?

Well, no.  The packet is not addresses to 6LR_n, so we can't consume headers.

> [RJ] RPI header should be shown in Untouched headers row for 6LBR column ?

fixed.

1171	6.9.  Example of Flow from RPL-aware-leaf to RPL-aware-leaf
> [RJ] Won’t RPI1 be modified in 6LR_ia and RPI2 be modified in 6LR_id ?
fixed.

> [RJ] It should be RFC 2460
thanks!

> [RJ] Don't understand the relevance of this stmt here.  it is already
> mentioned that routing-dispatch will help compressing the headers. Based on
> my understanding of routing-dispatch, it won't be possible to come up with
> scenario of root 6LN routing.

I guess if we don't know, we should remove the claim!

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 13 Mar 2017 08:03:39 +0000

Dear all:

[MCR] Yes, that's a good point.  I don't see a way to fix that, do you?

[Pascal] Once we have route projection, the root can find that this traffic deserves optimization (based on volume and path length, or additional knowledge on that particular flow)  and project a DAO into 6LR_1.

Take care,

Pascal

---

From: Ines Robles <[email-masked]>
Date: Mon, 13 Mar 2017 14:35:51 -0300

Hi,

A new version (version 12) was just submitted to address these comments.

Thank you very much Rahul,

Michael, Pascal and Ines.

2017-03-13 5:03 GMT-03:00 Pascal Thubert (pthubert) <[email-masked]>:

> 6LR_1
> [Pascal] Once we have route projection, the root can find that this
> traffic deserves optimization (based on volume and path length, or
> additional knowledge on that particular flow)  and project a DAO into 6LR_1.
>
> Take care,
>
> Pascal
>