Re: [Roll] nsa extension comments

Remous-Aris Koutsiamanis <aris@ariskou.com> Sat, 07 December 2019 10:52 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 8614812018D for <roll@ietfa.amsl.com>; Sat, 7 Dec 2019 02:52:55 -0800 (PST)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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=mailfence.com header.b=lY7vC9t3; dkim=pass (2048-bit key) header.d=ariskou.com header.b=gKXJpWTL
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 o94bxiH4SFHr for <roll@ietfa.amsl.com>; Sat, 7 Dec 2019 02:52:53 -0800 (PST)
Received: from mailout-l3b-97.contactoffice.com (mailout-l3b-97.contactoffice.com [212.3.242.97]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A67A0120142 for <roll@ietf.org>; Sat, 7 Dec 2019 02:52:52 -0800 (PST)
Received: from smtpauth1.co-bxl (smtpauth1.co-bxl [10.2.0.15]) by mailout-l3b-97.contactoffice.com (Postfix) with ESMTP id 7AE1515AF for <roll@ietf.org>; Sat, 7 Dec 2019 11:52:49 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mailfence.com; s=20160819-nLV10XS2; t=1575715969; bh=zQrWeesu2lIITNZQCP6jZGAFzQkpad4/I3iPZkHtAXE=; h=References:In-Reply-To:From:Date:Subject:To:From; b=lY7vC9t3kiE3NeNx5+gZCbRwaVilR6VA43aZ5CVACYf7zJlKyenj7em7YJZrq2A65 5uDKkIVRr4GckVhfUFUobSXwyewPzNvqBJOvSIS1WO8qsvMvlau6vZFzO7VqlGIkEB KkocdaBx9b0kjx6OzhkwgD6/qjkDXJWT9c/pIYo0StaqkgkIHSr3qNIXPacXJK1SBR nuXznKteIMO/Ab3vrsiRACLb6PL96iR9jA8uA/HXY1cpL2XcormPjCSJs05RyarDut Q5xXBanpOk0nmu6ILOmHOs/0KZ73WunYwqKVsEkxtB3lAcd0qful4+M1Z1nrTDGXiD 3YfKb/qBV+lZg==
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1575715969; s=20191001-wvim; d=ariskou.com; i=aris@ariskou.com; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject:To:Content-Type; l=7472; bh=zQrWeesu2lIITNZQCP6jZGAFzQkpad4/I3iPZkHtAXE=; b=gKXJpWTLRpYRFgUykvlsfHYwyH6+agdRuByES3B9cvvaWsr2YniR1DR0+rfKiMf/ iXN3NGFNANIaS+NHvL9G9lRsTCsDhDB34Rn3kUwICgXWWC8HMTzTeSWk5IzaNKAEE/9 tOkMtLgWNXbAuNYTVG5cd+d9oLwL/UZ+ui+CCGUzQX/tGJleWyLoGyh6PlRfn+D/Oun 9l/YCIz2Lyr1KWyPdXotxjZZasys3IGrTSi4U12FoB9W7wrO1A65q+e/qaQj5lF3twI eZey5rT9+2rgb36PgHUv29/NZT1ghDi1asQ6EHCyY5xRfusNZSAgYTHIf65cYc+JVFu A6G5jJjbEQ==
Received: by smtp.mailfence.com with ESMTPA for <roll@ietf.org> ; Sat, 7 Dec 2019 11:52:45 +0100 (CET)
Received: by mail-io1-f51.google.com with SMTP id v18so10007024iol.2 for <roll@ietf.org>; Sat, 07 Dec 2019 02:52:45 -0800 (PST)
X-Gm-Message-State: APjAAAV5ntc4q7NoheuqqALfT0pCWoyghge8gbuMr+Gda2N0lO2K6gaQ f0FeGlheL0Q5iMrhRtUSjiwH3eG9auHwv52b3uI=
X-Google-Smtp-Source: APXvYqzr3sMZTsiPVsDKXHrlT9qyP2+to/3PUwdUDgbirSuM/OkWO/Kus9e3WbWqMu/V/rAc9wfsXX5v8z553sD12h4=
X-Received: by 2002:a02:a599:: with SMTP id b25mr36599jam.71.1575715964029; Sat, 07 Dec 2019 02:52:44 -0800 (PST)
MIME-Version: 1.0
References: <CAO0Djp1p9m7KK-r+zAYhOXFf8NGxTxxtcmhjWPgv4VeEvo_cOw@mail.gmail.com>
In-Reply-To: <CAO0Djp1p9m7KK-r+zAYhOXFf8NGxTxxtcmhjWPgv4VeEvo_cOw@mail.gmail.com>
From: Remous-Aris Koutsiamanis <aris@ariskou.com>
Date: Sat, 7 Dec 2019 11:52:47 +0100 (CET)
X-Gmail-Original-Message-ID: <CAK76PrnHyxPzVfWp0GGmfDVUhchBDY1-SYmStppYgcQmVSVYoA@mail.gmail.com>
Message-ID: <CAK76PrnHyxPzVfWp0GGmfDVUhchBDY1-SYmStppYgcQmVSVYoA@mail.gmail.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004d91e005991af61d"
X-ContactOffice-Account: com:113819248
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/n3K7eUimhL7Og_sbXXsA405MInM>
Subject: Re: [Roll] nsa extension comments
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: Sat, 07 Dec 2019 10:52:55 -0000

Hello Rahul,

thank you very much for the commens and editing.
We'll go through everything and update here.

Best,
Aris

On Sat, Dec 7, 2019 at 9:06 AM Rahul Jadhav <rahul.ietf@gmail.com>; wrote:

> Hello authors,
>
> I have pushed my PR[1] to the corresponding roll-wg repo.  However, there
> are other
> points which require your attention. Following are my comments:
>
> o Carrying TLVs in NSA
> RFC 6551 explains that an NSA can be used to carry TLVs but it falls short
> of
> specifying the format for these TLVs. This document assumes the format of
> 8-bit
> type and 8-bit length. This format is fine but future specifications will
> have
> to refer to this document if they got to add new TLVs. Thus the generic TLV
> format should be made part of different section and an IANA registry needs
> to
> be created for the NSA TLV type.
>
> o Preference in PS set
> The document assumes that the parent addresses in the PS set have been
> added in
> the decreasing order of preference, without making it explicit. The PS IPv6
> address(es) field requires an explanation in Section 4.
>
> o DIO length
> As per the draft, the DIO needs to carry NSA (Node State and Attributes)
> metric
> with PS (parent set) TLV. As per my understanding without compression, it
> would
> be a challenge to carry even two parent addresses in the PS. There has
> been a
> discussion about compression and as I remember we discussed doing it.
> Regardless, I feel we should do it if we want this to be a practical
> proposition.
>
> o Section 3.4 Usage:
> "For example, using different methods can be used to vary the transmission
> reliability in each hop."
> This statement implies that using different CA policy implementation can
> "control" the transmission reliability. As I understand, the strict policy
> is
> the best policy (in terms of all performance metrics), the nodes will go
> for
> other policy only when the strict policy cannot be used given their parent
> sets.
> The above statement implies that nodes may still go for a relaxed policy
> when
> strict can be used.
>
> o Configuration parameters
> The document specifies configuration parameters such as
> a. PARENT_SET_SIZE ... Not defined
> b. cur_ap_min_path_cost: How can the cur_ap_min_path_cost be equated with
> PARENT_SWITCH_THRESHOLD as mentioned in section 3.2.2
> c. MAX_PATH_COST: No definition for this.
> The parameters warrant a rationale and a default value. Also more
> importantly,
> is it required that different nodes use the same value and if not what
> could be
> the impact.
>
> o Terminology section
> Terminology section should explain Alternative Parent, Parent Set,
> Preferred
> Grand Parent.
>
> o Section realignment
> It is better to explain CA Strict/Medium/Relax policies before explaining
> the
> CAOF because as a reader one needs to be familiar with these policies
> before
> understanding the OF.
>
> Regards,
> Rahul
>
> [1] https://github.com/roll-wg/draft-ietf-roll-nsa-extension/pull/1
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>