[Roll] Extension point for node information

Remous-Aris Koutsiamanis <aris@ariskou.com> Tue, 29 May 2018 21:30 UTC

Return-Path: <aris@ariskou.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 E5B4A12EC6E for <roll@ietfa.amsl.com>; Tue, 29 May 2018 14:30:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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=mailfence.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 3NZJATvlBVIm for <roll@ietfa.amsl.com>; Tue, 29 May 2018 14:30:48 -0700 (PDT)
Received: from mailout-l3b-97.contactoffice.com (mailout-l3b-97.contactoffice.com [212.3.242.97]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 700F712EC57 for <roll@ietf.org>; Tue, 29 May 2018 14:30:48 -0700 (PDT)
Received: from smtpauth1.co-bxl (smtpauth1.co-bxl [10.2.0.15]) by mailout-l3b-97.contactoffice.com (Postfix) with ESMTP id CF2CD5B2 for <roll@ietf.org>; Tue, 29 May 2018 23:30:45 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=mailfence.com; s=20160819-nLV10XS2; t=1527629445; bh=10ZFm0WQAjsfBhXOfwKDDkipwDoHqXXOIWvwzh/6bb4=; h=From:Date:Subject:To:From; b=GTjMfl3zV/g8vpsH+Zt+ZHTiOZgzHg1HkL5Z+ZfqkgLFPHpQ81IFH2qux5Uql5Imt nSkOYbBrvAc/qDnhAeuqAZGFLFCu+/M0Z37O8QGQEr2TDUP076bza++ssqFiNNtLog lFzKlSOorJuFylKjSn1ZfW5PjwWpzwLKhBfNNpYSzkkXJ+NxAjkptDAIqkSujJJF+6 6R/8wuUtLzFwVFsQL1E/S/0xWxq9PuL3NjqZvf2jrPDsCOI2pBkrUlBM/PJJe/5es5 rBUfXF4TQTRl5ei6WcBehVstMtjGkwhz2LgdeeawTRynBSisyzPtQ2/Cy+CFdwIb68 UKriSpXl74WlA==
Received: from mail-qk0-f174.google.com ([209.85.220.174]) by smtp.mailfence.com (envelope-from <aris@ariskou.com>) with ESMTPA for <roll@ietf.org> ; Tue, 29 May 2018 23:30:42 +0200 (CEST)
Received: by mail-qk0-f174.google.com with SMTP id k86-v6so12730771qkh.13 for <roll@ietf.org>; Tue, 29 May 2018 14:30:42 -0700 (PDT)
X-Gm-Message-State: APt69E0va8Fgk7ahoXz80wNbIldquW8N2AQ1/olnGkHm0fGzha2YGUWz 8s7SHFrEEt5zRE49SWyEb1odII37vdqgMPdikm4=
X-Google-Smtp-Source: ADUXVKK4L33jOklTHLpsVVMGR8kNZpXp+UFpPb3LCXQoj8ETeDCPxtcGPsFhQzFMhty7U8LbUZAkvZMi5RJOuSQ1TFg=
X-Received: by 2002:a37:3612:: with SMTP id d18-v6mr136100qka.86.1527629441522; Tue, 29 May 2018 14:30:41 -0700 (PDT)
MIME-Version: 1.0
Received: by 2002:a0c:a0e1:0:0:0:0:0 with HTTP; Tue, 29 May 2018 14:30:21 -0700 (PDT)
From: Remous-Aris Koutsiamanis <aris@ariskou.com>
Date: Tue, 29 May 2018 23:30:43 +0200
X-Gmail-Original-Message-ID: <CAK76PrkyyDxvqXqny91UKLiH9iXAr1yhiHd4sOPAre3YcckP1g@mail.gmail.com>
Message-ID: <CAK76PrkyyDxvqXqny91UKLiH9iXAr1yhiHd4sOPAre3YcckP1g@mail.gmail.com>
To: roll <roll@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000035e3ef056d5ef2cd"
X-ContactOffice-Account: com:113819248
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/VenNY2OlNtu5r3yOPOQG7--F_p8>
Subject: [Roll] Extension point for node information
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 29 May 2018 21:30:51 -0000

Dear all,

we are working on issues of parent selection and DODAG selection.
We have already worked on two drafts which add information to the DIO DAG
MC to support these choices.
We are debating where in the DAG MC to put information regarding node state.

In draft draft-koutsiamanis-roll-nsa-extension-01 we put the "Parent Node
Set" information (the list of a node's parent IPv6 addresses) in a new TLV
nested within the NSA metric object.
However, in draft draft-ji-roll-traffic-aware-objective-function-01 we
added the "Packet Transmission Rate" information as a new metric object
type directly withing the DAG MC as  new Routing-MC-Type (i.e., at the same
"level" as the other 6551-defined metric object like ETX, Node Energy,
etc.).
We are now debating if we maybe should re-position the "Packet Transmission
Rate" information nested withing the NSA metric object, as with "the Parent
Node Set", or not.

Both these drafts propose carrying information which is semantically
similar: information internal to a node.
We are wondering what would be more correct to do:
a) ask for new Routing-MC-Type allocation and create new metric objects.
b) ask for new NSA TLV type allocation and create as nested TLV within the
NSA metric object.

We have noted that in RFC6551 there is the NSA metric object and also a
separate node-information metric object specifically for energy, the "Node
Energy (NE) object".
It would seem that the existing NE object should be nested within the NSA
metric object if all node information is to be put within NSA.
If not, we expect that we should be able put our own additions at the same
level (i.e. use case a, above, to ask for new Routing-MC-Type allocation).
Should we do this?

If none of the above, is there a reason why an exception was made
especially for energy information?

Kind regards,
Aris