[Roll] Suggestions on the naming of the projected routes Re: Comments on draft-ietf-roll-dao-projection-09

["Liubing (Remy)" <[e-mail]>]

Hello Roll,

In the previous discussion with Pascal, we have the following question better to discuss separately.

> > 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?
> 
[Pascal] 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?

[Remy ]My suggestion would be, change "non-storing" to "source-routed" and "storing" to "hop-by-hop", to distinguish from the non-storing/storing mode of RPL.

Here "source-routed" means more than one Via addresses in the Route Projection Options, and "hop-by-hop" means exactly one Via address. 

Any suggestion from Pascal and others?

Best regards,
Remy 




> -----Original Message-----
> From: Roll [mailto:[e-mail]] On Behalf Of Pascal Thubert
> (pthubert)
> Sent: Monday, January 06, 2020 5:54 PM
> To: Routing Over Low power and Lossy networks <[e-mail]>
> Subject: Re: [Roll] Comments on draft-ietf-roll-dao-projection-09
> 
> 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
> 
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll