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

From: [email-masked]
Date: Sun, 03 Nov 2019 06:08:44 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Routing Over Low power and Lossy networks WG of the IETF.

        Title           : Root initiated routing state in RPL
        Authors         : Pascal Thubert
                          Rahul Arvind Jadhav
                          Matthew Gillmore
	Filename        : draft-ietf-roll-dao-projection-07.txt
	Pages           : 27
	Date            : 2019-11-03

Abstract:
   This document proposes a protocol extension to RPL that enables to
   install a limited amount of centrally-computed routes in a RPL graph,
   enabling loose source routing down a non-storing mode DODAG, or
   transversal routes inside the DODAG.  As opposed to the classical
   route injection in RPL that are injected by the end devices, this
   draft enables the Root of the DODAG to projects the routes that are
   needed on the nodes where they should be installed.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-roll-dao-projection/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-roll-dao-projection-07
https://datatracker.ietf.org/doc/html/draft-ietf-roll-dao-projection-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-dao-projection-07

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sun, 3 Nov 2019 14:22:16 +0000

This is an important update with changes addressing major points that we discussed at last IETF.

The changes are proposals to the group that we have to discuss. I wanted to publish before cut off, and possibly incorporate changes by tomorrow if we get comments by then.

https://mailarchive.ietf.org/arch/msg/roll/Z-ZZzL-NAVfgJAir35gG6YtCpkU Sibling information
We discussed the need to provide not only alternate parents but also links to siblings to the root. The siblings links would be for computing P2P routes that are not along the DODAG, e.g., non storing p-routes. We need meta like step of rank signaled for both parents and siblings. Also, we probably want that only one of the siblings advertises the link. Following Rabi's suggestion, a metrics container can be added.

https://mailarchive.ietf.org/arch/msg/roll/b4D20dCabKgFrpxDuxs-1bZJRxQ Querying PDAO
We discussed the need for a node to ask for a path with one or more destination and constraints. We discussed the use of a DIS with constraints that we could express using RFC 6551 I guess. DIS did not fit as a format and as a method, and it was missing an ACK. A new PDR / PDR Ack is introduced.

https://mailarchive.ietf.org/arch/msg/roll/59IYmAmLoC1eLvS3GO8zYfTG7c0 Stitching PDAO segments 
It takes a collection of segments to build a 6TiSCH Track. We need to signal that segments that we install separately belong to a same Track. There's a bunck of new text on that, and a TrackID is introduced. How to indicate a Track in the packet is also added, conforming the 6TiSCH architecture.

https://mailarchive.ietf.org/arch/msg/roll/KkcJYTjpMrOFvLbPhbLME0o1E1w Compressing the PDAO natively
Basically use RFC 8138 to compress the new options (VIO, SRVIO and Sibling).

There we go, fire at will!

Pascal

-----Original Message-----
From: Roll <[email-masked]> On Behalf Of [email-masked]
Sent: dimanche 3 novembre 2019 15:09
To: [email-masked]
Cc: [email-masked]
Subject: [Roll] I-D Action: draft-ietf-roll-dao-projection-07.txt

Abstract:

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: rabi narayan sahoo <[email-masked]>
Date: Mon, 4 Nov 2019 12:24:08 +0530

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.
      - [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?
   - 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?
      - [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?
      - [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.

Thanks
Rabi

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 4 Nov 2019 16:27:31 +0000

Hello Rabi :

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

From: Roll <[email-masked]> On Behalf Of rabi narayan sahoo
Sent: lundi 4 novembre 2019 07:54
To: Routing Over Low power and Lossy networks <[email-masked]>
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

---

From: rabi narayan sahoo <[email-masked]>
Date: Thu, 21 Nov 2019 10:53:36 +0530

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) <[email-masked]>
wrote:

> *From:* Roll <[email-masked]> *On Behalf Of *rabi narayan sahoo
> *Sent:* lundi 4 novembre 2019 07:54
> *To:* Routing Over Low power and Lossy networks <[email-masked]>
> *Subject:* Re: [Roll] I-D Action: draft-ietf-roll-dao-projection-07.txt
>
>
>
> Dear authors
>
>       P-Route. Like A node can request for a TE path based of Hop Count or based
> <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.
>
> <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.
>
> “
>
>       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>
>
>       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
>   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