[Roll] NSA PS-set metric/constraint

Rahul Jadhav <rahul.ietf@gmail.com> Tue, 11 February 2020 03:32 UTC

Return-Path: <rahul.ietf@gmail.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 7DC2C120072 for <roll@ietfa.amsl.com>; Mon, 10 Feb 2020 19:32:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id WQxImWkWlaVX for <roll@ietfa.amsl.com>; Mon, 10 Feb 2020 19:32:43 -0800 (PST)
Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (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 53E2B120052 for <roll@ietf.org>; Mon, 10 Feb 2020 19:32:43 -0800 (PST)
Received: by mail-lj1-x232.google.com with SMTP id x7so9916388ljc.1 for <roll@ietf.org>; Mon, 10 Feb 2020 19:32:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=K7ozMjd197A9WMSvM7BRGpT6bymTG7E71RZNFL7beXI=; b=rBwB98U4YkfnGTCpO6EIzH4Xw2XIe07cBQIduFtrpUN+bsQ2KlrOl4Sws2czXD/OGz v3iBae0IBCOyN1L7Aot06rzmKFL6EK0+48q0fX7aaNAdH216099qnZ4pyXpEgfnHtY2l CUiO/IHDt+whO/NvYoifbJ5YxH7EhMTMjIdDgtuTZw99mwDxit7jm56WieQupekP6aur BSHDIx5EIzkFl1SkvMNjil7T4YHZDx5dl0y/vE0jwByK5d+cs+TeczL1VwIkSJQjPR0M D5zDgscpJ0o5lUvbPb2cSm3mt2mDcfp8SYzcbqi7BSqmbqwshuhQTHLbdIdiuyZwaPGE tYOA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=K7ozMjd197A9WMSvM7BRGpT6bymTG7E71RZNFL7beXI=; b=ecf0ls8ZNuRBJaQ0qbcqN1iMVxy8lL44UBOa2g9MBJPSp8Qm8EymqRht6ddpjU2yRS z1tGqHmA4t1APNcf58uE2FNG2njMTnrjf676FVYkwbbEb+56VaCgfzzGudwvDYJqH6uk dVJMDL77uwMNaLwApY2GhIxoYFr/VQUK/N6jhU0RjLFg+tfP6f4VoihQQ5RkuFhG72+B P2rANLlnTGpCcRfIwnOSRbCIK9J1Fy5XJjXxrDpKl19FWbNTIrZMMrexX3EiHQTTQTTP Iy5lkJOvviPNvOTsag2DimsgBpg/bf4G6v+yYe7f7i2CERgdBq6qRQNg+YshfG/LAZPw 6zTQ==
X-Gm-Message-State: APjAAAVUAKz6D6p+TFC29ddPXH54HpQ77Hrlwz29MdVfSr7DoTJvl5gZ mPIFZVpnd6mk0FP+M2aA/VT9FZIDPZiA1FBppsu7wQ==
X-Google-Smtp-Source: APXvYqw1qyEaF5bLy1oITKaOUaRtQspiWEELykPaYjvQGtySDhhpC6fJVaoorkBY5P5zCamaHP/LDX9MwbLji9FeJ0o=
X-Received: by 2002:a2e:b6ce:: with SMTP id m14mr2631724ljo.99.1581391961457; Mon, 10 Feb 2020 19:32:41 -0800 (PST)
MIME-Version: 1.0
From: Rahul Jadhav <rahul.ietf@gmail.com>
Date: Tue, 11 Feb 2020 09:02:29 +0530
Message-ID: <CAO0Djp2W2N-_eACyQNZcapah=AugHRC0fwsg2nhuovZaXa7mUw@mail.gmail.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/QjxW4vwQlnwsVHurkrS2yrP4dZA>
Subject: [Roll] NSA PS-set metric/constraint
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.29
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, 11 Feb 2020 03:32:45 -0000

Hello Authors of NSA extn and all,

One more question in the context:

The draft adds new routing metrics/constraints (PS set) nested as part
of the NSA parent metric.

My question is with regards to what happens if this routing metric is
used outside of the CAOF. Any metrics/constraints could be used by any
OF and thus PS set metric defined by the draft can be used by other

RFC 6551 says that if the metric is not understood by the node and if
it is a 6LR then it may not process it but it has to propagate it.
Unlike other metrics, the PS set metric in this case contains
link-local values that cannot be used beyond link-local. As such upon
propagation, any downstream 6LR that understands the PS set metric
would use the information and get impacted adversely.

Should we tie the PS set metric to CAOF specifically in the draft, in
which case this problem won't be there? Or we can specify this issue
as it is for the readers to understand the problem if the PS set is
used outside of the CAOF. Either way works for me.