Re: [Roll] I-D Action: draft-ietf-roll-dao-projection-07.txt

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

Hello Rabi :

Many thanks, this is really helpful: I used them an pushed an 08 before cutoff. Please see below.



From: Roll <[e-mail]> On Behalf Of rabi narayan sahoo
Sent: lundi 4 novembre 2019 07:54
To: Routing Over Low power and Lossy networks <[e-mail]>
Subject: Re: [Roll] I-D Action: draft-ietf-roll-dao-projection-07.txt

Dear authors

I reviewed the changes (only) and have some queries and suggestions for the PDR and Sibling Information Option

  *   P-DAO Request Message

     *   [Suggestion] When a LN/LR requests for TE path using PDR  it can mention the Network Metric that PCE need to consider while computing the P-Route. Like A node can request for a TE path based of Hop Count or based on Minimum latency or Minimum EXT or Maximum Battery Life. I think this will provide more flexibility for application.
<Pascal> Yes, I agree. I already had a todo for that in the xml. We need to define together what metrics we want in there. That will be a new option I guess.

     *   [Query] Can PCE be a separate Physical Node Other than BR? If Yes how LR/LN will learn about it and send the PDR to it?
<Pascal> I added text for that already. The agreement we had so far is that the Root is the only node that the RPL device knows. If there’s a PCE and a protocol like PCEP, the Root should proxy. The current text reads:
“    This specification uses the RPL Root as a proxy to the PCE.  If the actual PCE is a separate entity, then a protocol that is out of scope for this specification is needed to relay the control elements between the RPL Root and the PCE.
“
I can move that to the intro and elaborate, e.g.:
“
   Projected Routes must be used with the parsimony to limit the amount
   of state that is installed in each device to fit within its
   resources, and to limit the amount of rerouted traffic to fit within
   the capabilities of the transmission links.  The method to learn the
   node capabilities and the resources that are available in the devices
   and in the network are out of scope for this document.

   In RPL Non-Storing Mode, the Root has enough information to build a
   basic DODAG topology.  This document adds the capability for nodes to
   advertise sibling information in order to improve the topological
   awareness of the Root.  This specification uses the RPL Root as a
   proxy to the PCE.  The algorithm to compute the paths and the
   protocol used by an external PCE to obtain the topology of the
   network from the Root are out of scope for this document.
“
Works?
</Pascal>

  *   Sibling Information Option (SIO)

     *   [Query] If PCE is a separate physical entity how the Sibling informations will be shared with it, as DAO messages will always terminate at BR?
<Pascal>
As of now, the Root and the PCE talk in whichever way they feel like, but that is out of scope. We could define a separate RPL-TE mode whereby the Root exports the DODAG and sibling links to the PCE. The PCE could appear as a Root of Roots (or a virtual Root, see RPL section 3.1.3<https://tools.ietf.org/html/rfc6550#section-3.1.3>). Or whereby it builds a fake LSDB to reuse a PCE that talks OSPF TE.
</Pascal>

     *   [Query] If the metric of P-Route need to be different from the Network Metric used for the global mesh network, how a LN/LR is going to learn about that so that it can send the correct metric information in SIO?
<Pascal>
To be defined. In normal RPL, the metrics to use come with the knowledge of the OF and there is nothing specified that uses the metrics container. Do we want to do more here? I do not see that the measure of the sibling link should differ to that of parent / child.
</Pascal>



     *   [Issue] Description of Sibling Address filed of SIO is exact copy of VIA address filed in VIO (2 to 16 bytes, a compressed IPv6 Address. a Via Address indicates the next hop towards the destination(s).....). This need to be changed.

<Pascal>
  Oups. Tired was I. I’ll fix and republish. Also removed the IANA on MOP per your other mail, we need to discuss capability vs. MOP. And added the missing IANA for the new stuff…
</Pascal>

All the best,
Pascal