Subject: Re: [Roll] [ROLL] Projected DAO and Extended MOP

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Fri, 1 Nov 2019 08:01:42 +0000

This is all very convincing Rabi.

Let’s discuss in Singapore. Will you be present ?

I plan to publish an update today or Monday.
The update will have proposals for a number of items that were in the table, advertising siblings, requesting a route, compressing the VIO based on RFC 8138 and building Tracks.

This is a lot of stuff and I expect we’ll need more time than I initially expected at the WG meetings.

Regards,

Pascal

Le 1 nov. 2019 à 01:24, rabi narayan sahoo <[email-masked]> a écrit :

Hello All

If my understanding is not wrong ID draft-ietf-roll-mopex-cap-00 is introduced to support Projected DAO. I think Extended MOP is not required for projected DAO.
Objective of P-DAO is to enable a path computing element (PCE) with global topological view of the network, knowledge of device capabilities and various network parameters to compute and install optimized (TE) routes to meet certain application requirements (Application scenarios requiring P2P path between devices).
Why Projected DAO is more of a Capability Compare to the Mode of Operation?

1-     The core mesh network will always operate either in Storing or Non-Storing mode. Projected DAO will use the underlying topology to compute more efficient p-routes and install them either in storing or non-storing mode. A new LR, irrespective of it supports projected DAO or not it has to join the network. This joining decision is completely based on which mode global network is operating and the new LR supports it or not.

2-     P-DAO is more like a capability. This capability mostly includes if the LR has enough memory to store the P-Routes and support to do SRH based packet forwarding.
Let’s consider the below scenarios
1—Global Network is Storing

     *   P-Route to be installed in Storing mode

For this to work all the LR need to have P-Route table

  *     P-Route to be installed is non-storing

Just the Ingress node must store the route entry in the P-Route table and all other intermediate LRs in the P-Route process the SRH header and forward the packet.
2—Global Network is Non-Storing
               Same requirement as above mentioned in storing mode case.
So P-DAO is independent of global mode of operation of the LLN.

What do you all think?

Thanks
Rabi

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

---

From: Ines Robles <[email-masked]>
Date: Fri, 1 Nov 2019 10:19:10 +0200

Hi,

This is a lot of stuff and I expect we’ll need more time than I initially
> expected at the WG meetings.
>

We will take that into account when we build the agenda ;-)

Thanks,

Ines.

> If my understanding is not wrong ID draft-ietf-roll-mopex-cap-00 is
> introduced to support Projected DAO. I think Extended MOP is not required
> for projected DAO.
>
> Objective of P-DAO is to enable a path computing element (PCE) with
> global topological view of the network, knowledge of device capabilities
> and various network parameters to compute and install optimized (TE) routes
> to meet certain application requirements (Application scenarios requiring
> P2P path between devices).
>
> 1-     The core mesh network will always operate either in Storing or
> Non-Storing mode. Projected DAO will use the underlying topology to compute
> more efficient p-routes and install them either in storing or non-storing
> mode. A new LR, irrespective of it supports projected DAO or not it has to
> join the network. This joining decision is completely based on which mode
> global network is operating and the new LR supports it or not.
>
>
> 2-     P-DAO is more like a capability. This capability mostly includes
> if the LR has enough memory to store the P-Routes and support to do SRH
> based packet forwarding.
>
>    - P-Route to be installed in Storing mode
>
>    -   P-Route to be installed is non-storing
>
> Just the Ingress node must store the route entry in the P-Route table and
> all other intermediate LRs in the P-Route process the SRH header and
> forward the packet.
>

---

From: rabi narayan sahoo <[email-masked]>
Date: Sat, 2 Nov 2019 10:32:41 +0530

Hi
I won't be coming to Singapore. I will attend the sessions remotely.
I hope sibling advertisement will have network metric information too. We
should also consider adding a option to DIO for disseminating PCE
information if PCE is not part of BR.
Looking forward for the new version of the draft.
Thanks
Rabi

On Fri, 1 Nov, 2019, 1:31 PM Pascal Thubert (pthubert), <[email-masked]>
wrote:

> The update will have proposals for a number of items that were in the
> table, advertising siblings, requesting a route, compressing the VIO based
> on RFC 8138 and building Tracks.
>

---

From: Michael Richardson <[email-masked]>
Date: Sat, 02 Nov 2019 16:37:22 -0400

This is how I see the state of things:

1) unaware-leaves + useofrplinfo are synchronized, and this frees up some mind
   bandwidth, and I confess to have been overwhelmed by this part.

2) we came to the capability problem from rfc8138-turn-on and DAO-projection.

3) I'd really like implement rfc8138-turn-on with the capabilities.
   I don't like the use of the T-bit here, because we have other stuff that
   we also need.

4) I don't feel like we have properly concluded about whether or not
   DAO-projection is a new MOP or not.

I have a todo item which is to write sample text on how to express
DAO-projection in terms of mopex.  I haven't done this yet.

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