[Roll] nsa extension comments

Rahul Jadhav <rahul.ietf@gmail.com> Sat, 07 December 2019 08:06 UTC

Return-Path: <rahul.ietf@gmail.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 92996120088 for <roll@ietfa.amsl.com>; Sat, 7 Dec 2019 00:06:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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_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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qwGIS4JRO4-k for <roll@ietfa.amsl.com>; Sat, 7 Dec 2019 00:05:59 -0800 (PST)
Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (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 251AC12004D for <roll@ietf.org>; Sat, 7 Dec 2019 00:05:59 -0800 (PST)
Received: by mail-lj1-x22a.google.com with SMTP id e28so10103278ljo.9 for <roll@ietf.org>; Sat, 07 Dec 2019 00:05:59 -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=Qk59N8N6irdlvEvixiRaIj8q9x3AuLoT5sIPM9KxlKk=; b=TkNjl5ayYVQCRGKpMZB5KammR609SFRMpU3od3PmuEWhz4U3gJ762UY2Zv7JA8nh6K nN+wZFtXwX5PVGjUtCIkm6IjlhdJKsnejebQp7+27j1DAlO9dSBDt75T8LpNmNg+1Sfa cxRiUIeZPrWRIo+Wm/difRL66WGiCbnkrQXkWIHReEPf+h+BENtqEqwcKtI5epHfmcfq xz22OYctoARIBwzgqjBmI/cOkYVE6Juyvte548vhJLQ7yVrbLTCHm54Pcg5wpWPLhMD4 ilRv70zNitesaAkzlo/evNsKAetPSoTBY4X0ja/k1ZRmza86jmz42G+58Bbq/2BJRJcp BNxA==
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=Qk59N8N6irdlvEvixiRaIj8q9x3AuLoT5sIPM9KxlKk=; b=qJBLm/pvGfo/xhG/b2WqPe77g8uCFmUpOFpAinuw5Mrha8z7ZBZUOREBOv9eu9P1Fo Xx3i5BcR9bzxR2vPnbhpNmVZ7e6FeTjD10So8kmhGZZRyA3N1KYLVlh3f9FuuHgnfjaa t1dh+W4oAEyBfHJrgXytDj1GnQ9M19IKHDXf+Vc8kuwsnPiH8XLg/ZpkFGeBnxJ0UsXA nQRh8A/IbTZTgGFPJPIIkZA739g8tfIXftZpT87rdlsvJMfMNljWketB/sk22gXYfsds QOI199SBz9uUKZCjjtZ479fP5UZVt1ZjOgJO4pMwQ0u9XmMO+7/ojeANP22kEj6uDFmn hEWQ==
X-Gm-Message-State: APjAAAXlja02LqWVDFfhzng9jQas2mE93nqBGucNTHkJtIQKMhmuF+si VsNYR3FrtRNteE9PY52YUlyi/y7dOw5/WsIc1hNfdLT7urQ=
X-Google-Smtp-Source: APXvYqxL6tY0TCW53Uh+AEh71dDZqy7FOLpjzwUWiAY8sxCDhmOs5VpTU35zCK+UoOIaGWQobyPNMehSdyPbXylDtYE=
X-Received: by 2002:a2e:2d11:: with SMTP id t17mr2783992ljt.177.1575705957143; Sat, 07 Dec 2019 00:05:57 -0800 (PST)
MIME-Version: 1.0
From: Rahul Jadhav <rahul.ietf@gmail.com>
Date: Sat, 07 Dec 2019 16:05:45 +0800
Message-ID: <CAO0Djp1p9m7KK-r+zAYhOXFf8NGxTxxtcmhjWPgv4VeEvo_cOw@mail.gmail.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000d8989d059918a1d9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/SHuKMsYCMQ5VHXSzNUsC6eHKKtc>
Subject: [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 08:06:01 -0000

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