Re: [Roll] (no subject)

Rahul Jadhav <nyrahul@outlook.com> Mon, 27 April 2020 01:06 UTC

From: Rahul Jadhav <nyrahul@outlook.com>
To: rabi narayan sahoo <rabinarayans0828@gmail.com>, "roll@ietf.org" <roll@ietf.org>
Thread-Index: AQHWG99SNjzpCH2Je0KHLmaELyuqNqiMH6V8
Date: Mon, 27 Apr 2020 01:06:05 +0000
Message-ID: <BM1PR01MB4020DD7B65B3859A14376D83A9AF0@BM1PR01MB4020.INDPRD01.PROD.OUTLOOK.COM>
References: <CAPT0++1Vb89zVQY_GbHaotq50=GxeF5sNEbEKdd_C92x52-U0Q@mail.gmail.com>
In-Reply-To: <CAPT0++1Vb89zVQY_GbHaotq50=GxeF5sNEbEKdd_C92x52-U0Q@mail.gmail.com>
Accept-Language: en-IN, en-US
Content-Language: en-IN
Content-Type: multipart/alternative; boundary="_000_BM1PR01MB4020DD7B65B3859A14376D83A9AF0BM1PR01MB4020INDP_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: 53f641a4-1d7c-4555-0dd0-08d7ea4729af
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Apr 2020 01:06:05.8570 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2APC01HT122
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/7iBUnd9FLVtTRPbxiDzeltUq3rM>
Subject: Re: [Roll] (no subject)
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Apr 2020 01:06:13 -0000

<<adding ROLL in the thread>>

Regarding removal of Mandatory bit:
We have two bits 'J'oin bit and 'C'opy bit which takes care of the point you mentioned.
If the node thinks that the Capability should be copied regardless of whether other nodes understand it then it will set this bit.
If node thinks, other nodes that do not understand the capability should not join then the J bit should be set appropriately.
These two bits combined will take care of the problem you mentioned.

Regarding removal of Projected Route Capability:
Capabilities should be used for nodes to advertise what (features/capabilities) they possess.
Projected Route Capability was used to enforce constraints on other nodes. This should be handled using routing metrics/constraints.
This rationale is explained in the introduction section of the document.

Thanks,
Rahul

________________________________
From: rabi narayan sahoo <rabinarayans0828@gmail.com>
Sent: 26 April 2020 11:28 PM
To: Rahul A. Jadhav <nyrahul@gmail.com>
Subject:

Hi Rahul
In the latest version of the Capability Draft, in capability control message option we have just mentioned
"Every capability is identified by its type and it may have an optional Capability Info"
We have removed the below description

"The first Bit of the CAPType indicates if the capability is mandatory or optional Value of 1 indicates its a mandatory capability and 0 indicates its an optional capability"

I understand you think, corresponding feature should add capability information option ,if they think this feature need to be negotiated.
If we mention the above rule in this draft then all have to follow this format.

For 6LORH capability negotiation do you 6low group docs will add this capability info.
We have removed Projected Route Capability. I think it was a useful one.

Thanks
Rabi

[Roll] (no subject) Michael Richardson
[Roll] (no subject) Qasem, Mamoun
Re: [Roll] (no subject) Rahul Jadhav