Re: [Roll] Comments on draft-ietf-roll-dao-projection-09

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

Hello Remy

Many thanks for your review!

Please see below:

> I've read the latest version of the draft. Great efforts! Please find my comments
> below for your consideration.
> 
> 1. Why do you choose to extend RPL instead of designing a new separate
> protocol to realize the establishment of a path? Technically, extending RPL
> works for sure. But if you look outside the IOT domain, the PCE have a separate
> protocol, i.e. PCEP, to establish the paths on the devices.


PCEP to the device acting as PCC was considered in the history of 6TiSCH. So was RSVP-TE. The Okham razor we used was code footprint. 
Most implementations we are aware of do not provide TCP that PCEP needs, and RSVP-TE would be a whole new protocol to support. 
We'd have needed both plus a TE extension to RPL anyway. Extending RPL for the whole thing was a simpler and smaller update.
Also we wanted to maintain the device<->root relationship that we use in non-storing mode and that may be secured separately in the future.
It is still possible to use PCEP for the southbound interface root<->PCE and have the Root acting as PCC translate in P-DAO terms as opposed to RSVP-TE. 

> 2. The titles of the subsections in section 6 are misleading. When I looked at the
> title "Non-storing/Storing mode projected route", I misunderstood them into
> "Route projection in non-storing/storing mode". Actually, until I reached at the
> appendix, I realized that they means the projected route itself is source-routed
> or hop-by-hop (no matter strict or loose).  Do you think it is necessary to add
> some clarification or to change the titles?

Yes, that makes sense to me. Would you have a suggestion? Could you make that a separate thread to attract a better attention from the group?

> 3. The following specification is not accurate in some cases: " In the
> uncompressed form the source of the packet would be self, the destination
> would be the first Via Address in the SRVIO, and the SRH would contain the list
> of the remaining Via Addresses and then the Target".
> It is true if RPL is running in storing mode, otherwise, another encapsulation
> takes place to indicate the explicit route to the via address, just like you have
> said in the preceding paragraph. And the said explicit route should be projected
> as well. Please consider combining the two paragraphs to make it correct.

Great suggestion! Reordering things give:

"

   When forwarding a packet to a destination for which the router
   determines that routing happens via the Target, the router inserts
   the source routing header in the packet to reach the Target.  In
   order to add a source-routing header, the router encapsulates the
   packet with an IP-in-IP header and a non-storing mode source routing
   header (SRH) [RFC6554].  In the uncompressed form the source of the
   packet would be self, the destination would be the first Via Address
   in the SRVIO, and the SRH would contain the list of the remaining Via
   Addresses and then the Target.

   In the case of a loose source-routed path, there MUST be either a
   neighbor that is adjacent to the loose next hop, on which case the
   packet is forwarded to that neighbor, or a source-routed path to the
   loose next hop; in the latter case, another encapsulation takes place
   and the process possibly recurses; otherwise the packet is dropped.

"

Works?

> 4. You've mentioned that the root can be the egress of a path. Does it mean
> that the upward route needs to be projected in some cases, given the fact that
> most of the examples given in the draft are downward or transversal routes?
> Could you give an example on that situation?

The P-DAO routes are separate RPL instances. They can be computed based on an alternate choice of metrics.
This means that the "short" path along the DODAG for the main OF may differ from the preferred one for the objective of the P-DAO route.
e.g., if reliability is required for the P-DAO route, the root may enforce B-A->root through in the main DODAG B is a child of root.

All the best,

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