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

From: "Liubing (Remy)" <[email-masked]>
Date: Tue, 7 Jan 2020 03:39:42 +0000

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:[email-masked]] On Behalf Of Pascal Thubert
> (pthubert)
> Sent: Monday, January 06, 2020 5:54 PM
> To: Routing Over Low power and Lossy networks <[email-masked]>
> 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
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/roll
> 
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 7 Jan 2020 09:10:01 +0000

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

> From: Roll <[email-masked]> On Behalf Of Liubing (Remy)
> Sent: mardi 7 janvier 2020 04:40
> Subject: [Roll] Suggestions on the naming of the projected routes Re:
> Comments on draft-ietf-roll-dao-projection-09
> 
> Hello Roll,
> 
> > > 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?
> >
> [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.
> 
> > > 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.
> > 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.
> >
> > > 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
> > > 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?
> > The P-DAO routes are separate RPL instances. They can be computed
> > based on an alternate choice of metrics.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 07 Jan 2020 11:11:47 -0500

> where those qualifiers also apply.

I think that the terms are fine for the document in question.

I think that we are overall (as a WG), we going towards various kinds of
hybrid forms and the words storing/non-storing need to go away from our
lexicon completely. (p2pRPL comes to mind)

We may want to distinguish between nodes in a network that have complete or
incomplete knowledge of their subtrees.

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