Re: [Roll] Rplinfo WGLC

[Michael Richardson <[e-mail]>]

Rahul Jadhav <[e-mail]> 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?

980	   +---------------+-------------+---------------+--------------+------+
[RJ] Shouldn’t the RH3 be removed in 6LR_n column ?

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!

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.

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






--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-