Re: [Roll] DIS Multicast behaviour

<dominique.barthel@orange.com> Wed, 11 May 2016 09:51 UTC

Return-Path: <dominique.barthel@orange.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D812212D62D for <roll@ietfa.amsl.com>; Wed, 11 May 2016 02:51:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.618
X-Spam-Level:
X-Spam-Status: No, score=-1.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XFhKyUHX1_aX for <roll@ietfa.amsl.com>; Wed, 11 May 2016 02:51:36 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0BB412D626 for <roll@ietf.org>; Wed, 11 May 2016 02:51:34 -0700 (PDT)
Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 0854218C1E4; Wed, 11 May 2016 11:51:33 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.32]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id D981127C079; Wed, 11 May 2016 11:51:32 +0200 (CEST)
Received: from OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1]) by OPEXCLILM32.corporate.adroot.infra.ftgroup ([fe80::8924:188:2124:a046%19]) with mapi id 14.03.0294.000; Wed, 11 May 2016 11:51:32 +0200
From: <dominique.barthel@orange.com>
To: "shobhit.bits@gmail.com" <shobhit.bits@gmail.com>
Thread-Topic: [Roll] DIS Multicast behaviour
Thread-Index: AQHRq2lTOe9rymTJOk+YV0e4eg7AEZ+zfpcA
Date: Wed, 11 May 2016 09:51:32 +0000
Message-ID: <10723_1462960292_573300A4_10723_17072_1_D358CBB2.32C78%dominique.barthel@orange.com>
References: <CAN5cqrW1eNtUpDGPUmowkiVaPKkWXF4io5ZSSa6OXpo+=aJGRQ@mail.gmail.com>
In-Reply-To: <CAN5cqrW1eNtUpDGPUmowkiVaPKkWXF4io5ZSSa6OXpo+=aJGRQ@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.6.3.160329
x-originating-ip: [10.168.234.5]
Content-Type: multipart/alternative; boundary="_000_D358CBB232C78dominiquebarthelorangecom_"
MIME-Version: 1.0
X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.5.11.91516
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/E3gd36qSld8BA3GprGTJ_tmT41o>
Cc: =?iso-8859-1?Q?Cenk_G=FCndogan?= <cenk.guendogan@fu-berlin.de>, Routing Over Low power and Lossy networks <roll@ietf.org>
Subject: Re: [Roll] DIS Multicast behaviour
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
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: Wed, 11 May 2016 09:51:39 -0000

Shobbit,

Thank you so much for your interest in more diverse responses to DIS reception.
The DIS flag mentioned in RFC6550 and its interpretation is still work in progress.
You can see the most recent proposal in draft-zhong-roll-dis-modifications that expired just a few days ago.
https://tools.ietf.org/html/draft-zhong-roll-dis-modifications-00
I would very much appreciate if you could describe to us the kind of deployment that prompts for your stated requirement.
This would help up in finalising the draft.
With best regards

Dominique

De : Roll <roll-bounces@ietf.org<mailto:roll-bounces@ietf.org>> on behalf of Shobhit <shobhit.bits@gmail.com<mailto:shobhit.bits@gmail.com>>
Répondre à : "roll@ietf.org<mailto:roll@ietf.org>" <roll@ietf.org<mailto:roll@ietf.org>>
Date : Wednesday 11 May 2016 11:41
À : "roll@ietf.org<mailto:roll@ietf.org>" <roll@ietf.org<mailto:roll@ietf.org>>
Objet : [Roll] DIS Multicast behaviour

Hi,

I have requirement to receive multicast DIS messages from any node without resetting the trickle timer.

As standard indicates that if any node will receive the multicast DIS message , it will be considered as inconsistency with respect to trickle timer of recipient(RFC 6550 ,Sec 8.3).
It also indicates this behavior can be controlled by DIS flag.

But after checking the DIS flag option , it is mentioned that it is unused filed (Sec 6.2.1).
"Flags: 8-bit unused field reserved for flags.  The field MUST be
         initialized to zero by the sender and MUST be ignored by the
         receiver."

Please suggest if there is any way to stop the reset of trickle timer in case of reception of multicast DIS message.

--
Regards,
Shobhit

_________________________________________________________________________________________________________________________

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.