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

Hi Pascal
I am sorry for the late reply.
[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.

*<Rabi>It is good to know that you have already considered it. *

[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?
*<Rabi> Its very clear now. *

[Query] If PCE is a separate physical entity how the Sibling
information will be shared with it, as DAO messages will always terminate
at BR?
*<Rabi> I agree with you, communication between BR and PCE (In case its a
separate entity) need to be defined in separate doc. *

[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?
*<Rabi> I suggest the metrics requirement for P-Route to be advertised as
part P-DAO capability enquiry/negotiation.  This will modify the SIO too to
send the metric information to PCE. I feel in normal RPL operation no
change is needed with respect to OF or metric container. Metric container
can be re-used with SIO. *

Thanks
Rabi

On Mon, Nov 4, 2019 at 9:58 PM Pascal Thubert (pthubert) <pthubert@cisco.com>
wrote:

> Hello Rabi :
>
>
>
> Many thanks, this is really helpful: I used them an pushed an 08 before
> cutoff. Please see below.
>
>
>
>
>
>
>
> *From:* Roll <roll-bounces@ietf.org> *On Behalf Of *rabi narayan sahoo
> *Sent:* lundi 4 novembre 2019 07:54
> *To:* Routing Over Low power and Lossy networks <roll@ietf.org>
> *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
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>