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

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

Hello Remy

Source-routed vs. hop-by-hop work for me. Can we do better?
Ideally we'd find a qualifier that differentiates from the main DAG where those qualifiers also apply.

All the best

Pascal

> -----Original Message-----
> From: Roll <[e-mail]> On Behalf Of Liubing (Remy)
> Sent: mardi 7 janvier 2020 04:40
> To: Routing Over Low power and Lossy networks <[e-mail]>
> Subject: [Roll] Suggestions on the naming of the projected routes Re:
> Comments on draft-ietf-roll-dao-projection-09
> 
> 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
> 
> _______________________________________________
> Roll mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/roll