Subject: [Roll] MOPex CAPs splitup

From: Rahul Jadhav <[email-masked]>
Date: Tue, 19 Nov 2019 18:45:58 +0800

Hello All,

During IETF106 we discussed splitting up MOPex and capabilities,
reasons have been:
1. MOPex and capabilities are not dependent on each other
2. Capabilities draft may take a while for WGLC, while MOPex can be
shipped sooner.

Please let us know of your opinions.

The following is the link for the separated draft.
https://datatracker.ietf.org/doc/draft-jadhav-roll-mopex/

Reviews are highly appreciated.

Thanks,
Rahul

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 19 Nov 2019 14:09:01 +0000

I fully agree with the split, and suggest we quickly handle mopext as the infrastructure for RPLv2

Regards,

Pascal

> Le 19 nov. 2019 à 18:46, Rahul Jadhav <[email-masked]> a écrit :
> 
> Hello All,
> 
> _______________________________________________
> Roll mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/roll

---

From: "Georgios Z. Papadopoulos" <[email-masked]>
Date: Tue, 19 Nov 2019 22:18:11 +0800

+1
Georgios

> On Nov 19, 2019, at 22:09, Pascal Thubert (pthubert) <[email-masked]> wrote:
>

---

From: rabi narayan sahoo <[email-masked]>
Date: Wed, 20 Nov 2019 08:27:36 +0530

I am Sorry  i was unable to attend the sessions remotely.
I do agree with the split. MOPEx and Capabilities should be two separate
draft.
For capabilities i have a suggestion. We can split the capabilities into
two different categories.
1-- Network Capabilities (Global) . Capabilities, those all nodes in the
network need to support to act as a LR. Ex support of SRH Compression
2-- Node Specific capabilities (Local). Ex. NBR Cache size, route table
size, DAO Projection etc

This will help us to identify which capabilities should be disseminated
through out the network and which shouldn't.

Thanks
Rabi

---

From: Rahul Jadhav <[email-masked]>
Date: Thu, 21 Nov 2019 10:24:06 +0800

> 1-- Network Capabilities (Global) . Capabilities, those all nodes in the
network need to support to act as an LR. Ex support of SRH Compression
> 2-- Node Specific capabilities (Local). Ex. NBR Cache size, route table
size, DAO Projection, etc
> This will help us to identify which capabilities should be disseminated
throughout the network and which shouldn't.

Thanks, Rabi for the suggestion. And yes you are right, Global vs local
differentiation needs to be done and the eliding-dio-information draft
already has differentiated handling for global cap option. The same needs
to be clarified in the cap-draft.
Would it be possible for you to propose the text for the cap-draft as you
see fit as a PR on GitHub repo?
I have added an issue <https://github.com/roll-wg/Capabilities/issues/5> in
GitHub repo for this.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 21 Nov 2019 02:56:22 +0000

Agreed as well. Basically there will be a parent local pull and a global pull. The multicast address of all children of  apparent might be useful there.

From: Roll <[email-masked]> On Behalf Of Rahul Jadhav
Sent: jeudi 21 novembre 2019 10:24
To: Routing Over Low power and Lossy networks <[email-masked]>
Subject: Re: [Roll] MOPex CAPs splitup

> For capabilities i have a suggestion. We can split the capabilities into two different categories.
> 1-- Network Capabilities (Global) . Capabilities, those all nodes in the network need to support to act as an LR. Ex support of SRH Compression
> 2-- Node Specific capabilities (Local). Ex. NBR Cache size, route table size, DAO Projection, etc
>
> This will help us to identify which capabilities should be disseminated throughout the network and which shouldn't..
>

Thanks, Rabi for the suggestion. And yes you are right, Global vs local differentiation needs to be done and the eliding-dio-information draft already has differentiated handling for global cap option. The same needs to be clarified in the cap-draft.
Would it be possible for you to propose the text for the cap-draft as you see fit as a PR on GitHub repo?
I have added an issue<https://github.com/roll-wg/Capabilities/issues/5> in GitHub repo for this.

---

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

Hi Rahul
ok i will write it and share the initial draft in the github..

On Thu, Nov 21, 2019 at 7:54 AM Rahul Jadhav <[email-masked]> wrote:

> throughout the network and which shouldn't..
> >
>

---

From: Abdussalam Baryun <[email-masked]>
Date: Thu, 21 Nov 2019 08:50:06 +0200

I support that.

AB

---

From: <[email-masked]>
Date: Thu, 21 Nov 2019 08:41:25 +0000

Hello all,

As an individual, I support the split, which will allow the easier part to
move forward quickly.
However, we should agree quickly what to do about 3.2, which currently
contradicts 3.1 and also ties MOPex and CAPabilities back together.
Best regards

Dominique

>Reviews are highly appreciated.

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Rahul Jadhav <[email-masked]>
Date: Thu, 21 Nov 2019 22:30:28 +0800

Hi Dominique,

> contradicts 3.1 and also ties MOPex and CAPabilities back together.

[RJ] Which is the contradictory stmt in 3.1 you are referring to?

Thanks,
Rahul

---

From: <[email-masked]>
Date: Fri, 22 Nov 2019 04:33:14 +0000

Hello Rahul, all,

In Section 3.1, I read
"The MOPex option MUST be used only if the base DIO MOP is 7."

And the title of Section 3.2 is "Use of MOPex for MOP less than equal to 6", which I found to be a contradiction to the above statement.
The body text further says "The current set of MOPs (values 0-6) could also be used in MOPex."

Now that you are asking, I realize that I mistook your text body to mean "we could even use the mechanism of MOPex with base MOP values of 0-6", and this misunderstanding was induced by the title, which is plain misleading.

In order to avoid a misunderstand similar to mine by future readers, can I suggest you rewrite 3.2 the following way
Title "Use of values 0-6 in the MOPex option"
Text body "The MOPex option could also be allowed to re-use the values 0-6, which have been used for MOP so far. …"

Best regards

Dominique

De : Roll <[email-masked]<mailto:[email-masked]>> on behalf of Rahul Jadhav <[email-masked]<mailto:[email-masked]>>
Répondre à : "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date : Thursday 21 November 2019 22:30
À : "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Objet : Re: [Roll] MOPex CAPs splitup

Hi Dominique,

Thanks,
Rahul

---

From: Rahul Jadhav <[email-masked]>
Date: Fri, 22 Nov 2019 12:43:40 +0800

> In order to avoid a misunderstand similar to mine by future readers, can I
> suggest you rewrite 3.2 the following way
> Text body "The MOPex option could also be allowed to re-use the values
> 0-6, which have been used for MOP so far. …"
>

[RJ] Thanks Dominique . This text definitely sounds better. Following is
the PR which fixes this (https://github.com/roll-wg/mopex/pull/1)