Re: [Roll] in non-storing mode how do leaf nodes know where the root is?

Ines Robles <mariainesrobles@googlemail.com> Mon, 04 April 2016 14:19 UTC

Return-Path: <mariainesrobles@googlemail.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 B24C712D71F for <roll@ietfa.amsl.com>; Mon, 4 Apr 2016 07:19:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Level:
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.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 cq34--ay9FkX for <roll@ietfa.amsl.com>; Mon, 4 Apr 2016 07:19:36 -0700 (PDT)
Received: from mail-vk0-x229.google.com (mail-vk0-x229.google.com [IPv6:2607:f8b0:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38BA012D719 for <roll@ietf.org>; Mon, 4 Apr 2016 07:19:36 -0700 (PDT)
Received: by mail-vk0-x229.google.com with SMTP id k1so181459704vkb.0 for <roll@ietf.org>; Mon, 04 Apr 2016 07:19:36 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=hCCBkqz5rneL1s3M/bwwsOB+1BEnfP4bIYuuTs0lODM=; b=Em/J8jBGj8nRYFcFRenOQKlAlnGV5zI7WKEA3G+QO2PH/w9s94izTe3CwMTOTc3Q84 9VL+4z5sPktqv2mr8tHwVJP5ZdWWel6F8Dn8MGDUzkeNOGazh+vnIRIsrWP+VLE3E31H Wjqwdx7mSc8BrQHi5+2kh6JFD9kjEroXyqQ3T8sTgTONthizU0TNc4eHUxNzXfNEBv9i ErtXU3FP3hsmiv3zqnWZjvYV3yNtmD4ZJ82LKhTd16MCPSA8Vr9lSua/sqK34GvgqGzm fgfqMct1svMkVZcBIWMo+KXWkn1F/nYMnW5P+qDmIGStVroVvVh8l5s54qyndEYd2YA2 sNzA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=hCCBkqz5rneL1s3M/bwwsOB+1BEnfP4bIYuuTs0lODM=; b=DCyX+7NMFSBdJqbbgrvA5yIMDTjtbc96baVFQFXpLfPUxFpN4D8aDt9Y7ynAyqT98f wvGvRK+U2qn5ypny2VoCVPshojgFVcEPxerzpikxRkwzQHOEjAn6rkmkrQrGpnP6R2gt 0mJlppNSaY/nijAK5+6HT+XhqQXSDwgIRLEFG0og1BgYWacNTrAZw/nzvmZYktzUWqjG 9ecStSMvQsUDObq8cdgxswowNnJdsMbVAQiBY6W4vS3jmgcBFV8Z0v6C7Lbou7QGMaYz neQ/77KJSyzsxfYyUrI3rDANsNKdn+apKZsQN546sT9FvpWps1DicDytLPb0DJcdkTNZ i+gg==
X-Gm-Message-State: AD7BkJJKMYHphFcsY8nNXj/gxaJ3sHadGDtH/BCilvaPcEWFnq9dho3IE6SI0ndNPwAjqmE6PEQCNi200p05cQ==
MIME-Version: 1.0
X-Received: by 10.159.37.242 with SMTP id 105mr3939436uaf.73.1459779575338; Mon, 04 Apr 2016 07:19:35 -0700 (PDT)
Received: by 10.176.66.162 with HTTP; Mon, 4 Apr 2016 07:19:35 -0700 (PDT)
In-Reply-To: <a8af2fa56e9c139c148c1288603e541c@xs4all.nl>
References: <15326.1459723539@obiwan.sandelman.ca> <CAP+sJUcPakqrxRYAca+Ni33XEsQCAXsA7NmkmNdE53u5BmG6zQ@mail.gmail.com> <32685.1459773194@obiwan.sandelman.ca> <a8af2fa56e9c139c148c1288603e541c@xs4all.nl>
Date: Mon, 04 Apr 2016 11:19:35 -0300
Message-ID: <CAP+sJUenx-zfB5QZ59O9NVC_OE1oWzwd_d2TC0q8fUQxJUiTXg@mail.gmail.com>
From: Ines Robles <mariainesrobles@googlemail.com>
To: "consultancy@vanderstok.org" <consultancy@vanderstok.org>, Routing Over Low power and Lossy networks <roll@ietf.org>
Content-Type: multipart/alternative; boundary="001a113ac86a09dcf9052fa96b20"
Archived-At: <http://mailarchive.ietf.org/arch/msg/roll/x9Cgv30vSYtQ0fl3kK8aokw0XQ8>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>
Subject: Re: [Roll] in non-storing mode how do leaf nodes know where the root is?
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: Mon, 04 Apr 2016 14:19:39 -0000

>    > DODAGID: ....The DODAGID MUST be a routable IPv6 address...
>>
>> That definision is in 6.3.1, while the definition in section 2 says:
>>
>>    DODAGID: A DODAGID is the identifier of a DODAG root.  The DODAGID is
>>          unique within the scope of a RPL Instance in the LLN.  The
>>          tuple (RPLInstanceID, DODAGID) uniquely identifies a DODAG.
>>
>> I think that the second definition should be moved/copied to the top, and
>> I
>> suggest an errata.
>>
>> According to me, that does not solve your original question,
> moving up and merging the two definitions does.
>
> So, the merging (taking in consideration definition in section 8 as well)
would be something like this:

DODAGID: 128-bit (Global or Unique Local ) IPv6 address  set by a DODAG
root that uniquely identifies a DODAG. The DODAGID MUST be a routable (1)
IPv6 address belonging to the DODAG root. A DODAGID is the identifier of a
DODAG root.  The DODAGID is unique within the scope of a RPL Instance in
the LLN.  The tuple (RPLInstanceID, DODAGID) uniquely identifies a DODAG.


(1)Unique Local They are not expected to be routable on the global
Internet.  They are routable inside of a more limited area such as a
site. They may also be routed between a limited set of sites [ RFC
4193]


Cheers,

Ines.