IETF Logo Mail Archive

Re: [Roll] RPLinfo review

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Fri, 03 June 2016 14:23 UTC

Return-Path: <pthubert@cisco.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 0D85112D10F for <roll@ietfa.amsl.com>; Fri, 3 Jun 2016 07:23:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.946
X-Spam-Level:
X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 3tsqFCTeno03 for <roll@ietfa.amsl.com>; Fri, 3 Jun 2016 07:23:17 -0700 (PDT)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 725F612D6A8 for <roll@ietf.org>; Fri, 3 Jun 2016 07:23:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15558; q=dns/txt; s=iport; t=1464963797; x=1466173397; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=nfAWQMzyiYuyLwFLk3u5Rz0IXNywEBLwbIlIqokPy90=; b=gJsuaLOZ8tVyIBeZfd2sAtF0sCufEqJQF1uCR+w+YOcU9r3AGhDaS1zC GTUiHJ61Rs/hIS6VoevESVjhWnKZ4Cc07zN7gjcal3/I/Mp0TSBQId4Xt FNpVluzuH9Sgx6zayHL+Rwxwb1JfwmSUPI9ULQH/2hCJPoXs6Fucnky10 k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CWBQCNklFX/5FdJa1cgm1NVn0GtVWEfYF5hhICHIEYORMBAQEBAQEBZSeERQEBAQQjClwCAQgRBAEBKAMCAgIwFAkIAgQBEgiIDQMXsUiNBQ2EHwEBAQEBAQEBAQEBAQEBAQEBAQEBARyGJ4RNgkOBYzEfgkuCWQWTOIUNAY4cgXCET4hkj1EBHwE0ggccgUtuiRN/AQEB
X-IronPort-AV: E=Sophos;i="5.26,412,1459814400"; d="scan'208,217";a="281401517"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Jun 2016 14:23:16 +0000
Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u53ENGKV030603 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 3 Jun 2016 14:23:16 GMT
Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 3 Jun 2016 09:23:15 -0500
Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1104.009; Fri, 3 Jun 2016 09:23:15 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>, "consultancy@vanderstok.org" <consultancy@vanderstok.org>
Thread-Topic: [Roll] RPLinfo review
Thread-Index: AQHRtZljiu7reBuxikGNQsGOvP8+eZ/IIsCAgAAQbwCAAAHlgIAAARsAgAAEgYCAD5/5wA==
Date: Fri, 03 Jun 2016 14:23:11 +0000
Deferred-Delivery: Fri, 3 Jun 2016 14:23:00 +0000
Message-ID: <517a2d666e78421cbe7d5c24b2efef3f@XCH-RCD-001.cisco.com>
References: <09c3e3fc17b5de9b7366d226c034da28@xs4all.nl> <CAP+sJUePiV+_Nd+f-H-x_zNoTgkS0Cqe1rq7qD7ie_H3MyOorw@mail.gmail.com> <bc96b8913fff031fc1f41eedfdb6bee3@xs4all.nl> <CAP+sJUe=t7MwkVAUd33+tz_M7J6sqmHKahCQsiBm_e86eHb6cA@mail.gmail.com> <1747ba1478659868c3b715ff8b807c6c@xs4all.nl> <CAP+sJUep6u43OtAtwSw8stPVCT-r2Mfssp2=Va8sXvtL7f8vQQ@mail.gmail.com> <CAP+sJUcnxBbpNFpRxLWfp=WDmL2S=MeS1bF0jvgqTjPtwYgr4w@mail.gmail.com>
In-Reply-To: <CAP+sJUcnxBbpNFpRxLWfp=WDmL2S=MeS1bF0jvgqTjPtwYgr4w@mail.gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.49.80.17]
Content-Type: multipart/alternative; boundary="_000_517a2d666e78421cbe7d5c24b2efef3fXCHRCD001ciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/ElMZ9vgORVrxfYseEATaWSeLKHE>
Subject: Re: [Roll] RPLinfo review
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: Fri, 03 Jun 2016 14:23:20 -0000

Hello Ines:

Interworking between instances would be like redistributing a protocol within another. This yields loops and requires prioritization like admin distance in Cisoc routers. So far, we do not support that. Related: the draft on asym links added a capability for an upward instance (optimizing link metrics towards the root) to be coupled with a downwards instance, in case we have links with widely unbalanced metrics in both directions.

Cheers,

Pascal

From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Ines Robles
Sent: mardi 24 mai 2016 12:43
To: consultancy@vanderstok.org
Cc: Routing Over Low power and Lossy networks <roll@ietf.org>
Subject: Re: [Roll] RPLinfo review

btw, I just found a proposed approach for interaction between RPL Instances

Barcelo, Marc, Alejandro Correa, Jose Lopez Vicario, and Antoni Morell. "Cooperative interaction among multiple RPL instances in wireless sensor networks." Computer Communications (2015).

Cheers,

Ines.

2016-05-24 13:26 GMT+03:00 Ines Robles <mariainesrobles@googlemail.com<mailto:mariainesrobles@googlemail.com>>:
Ah, got it, thank you very much.

Ines

2016-05-24 13:22 GMT+03:00 peter van der Stok <stokcons@xs4all.nl<mailto:stokcons@xs4all.nl>>:
Hi,

that means writing "one RPL instance" in figure 3 in stead of "RPL instance" to remove that ambiguity.
Writing in the use case section a phrase as the one below will be more than sufficient for me.

peter

Ines  Robles schreef op 2016-05-24 12:16:

Hi,

Thanks for the clarification.

We are just considering here one RPLInstance.

Working with different RPLInstances, involves deeply analysis, which
we could do in the future. But, actually I dont know if it is
possible/useful to send a message from one RPL Instance to another one
, since for example a RPL node may belong to multiple RPL Instances,
and it may act as a router in some and as a leaf in others[1], for
this reason it does not make sense to me sending packet from one
RPLInstance to other RPLInstance. Besides the control messages has one
field for RPLInstanceID, it does not have RPLInstanceID origen or
RPLInstanceID dst.

What do you think?

Thank you,

Ines

[1] RFC6550. Section 5. RFC 6550 describes only how a single instance
behaves

2016-05-24 12:17 GMT+03:00 peter van der Stok <stokcons@xs4all.nl<mailto:stokcons@xs4all.nl>>:
I also did not see a mapping of flow from one RPL instance to
another instance.

I do not understand this. Could you please clarify?

 A node belonging to one RPL instance sends a message to a node
belonging to another RPL instance.
This seems possible in Figure 3, with 3 RPL instances?

If possible, it means an additional use case.

Peter

v2.23.0 | Report a Bug | By Email