[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
- [Roll] Extension point for node information Remous-Aris Koutsiamanis
- Re: [Roll] Extension point for node information Georgios Z. Papadopoulos