Re: [Roll] WGLC for draft-ietf-roll-efficient-npdao-03

Rahul Jadhav <rahul.ietf@gmail.com> Mon, 16 July 2018 17:28 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 25FEE130E21 for <roll@ietfa.amsl.com>; Mon, 16 Jul 2018 10:28:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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_PASS=-0.001, URIBL_BLOCKED=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 yTpua6Z3TBa4 for <roll@ietfa.amsl.com>; Mon, 16 Jul 2018 10:28:47 -0700 (PDT)
Received: from mail-vk0-x233.google.com (mail-vk0-x233.google.com [IPv6:2607:f8b0:400c:c05::233]) (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 B8383130E12 for <roll@ietf.org>; Mon, 16 Jul 2018 10:28:47 -0700 (PDT)
Received: by mail-vk0-x233.google.com with SMTP id h22-v6so22077746vke.4 for <roll@ietf.org>; Mon, 16 Jul 2018 10:28:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ZF+6GINPQQlAnIORmYnA9YTgAX6/Pff9lXXiA3o3YHk=; b=YU8CqerpU2n5Rzu0lYLUoJMtUkXReQOaOeaayrCYg0jYmeoKgfuTFH+8t5fcDS47Zu jL9s/4N9o0kmeNXSo6VYAyl6llvqMI79K6g1wVeusHEFKp2rF3H/vPlF8dsVxHsT5kAx eEJDJ/4aSk+FZ85heaetv0FHPLk73hoc49rLmxg8JXWjv38m8qbvDvZbBFN5foRNMlPn 7+lFaWi8CKd0+9ntAaixf3pM8T/7cUO0+kEActDllQFS+n1kFo3v5d9/VLdoGqpr6L/T TSX7Yg+lLpiQ+VA8Gz27URdhGYMqiXK+7n6YcbscxbrDKTPXhQM5TErbTU4zt8L+UL6z JfCg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ZF+6GINPQQlAnIORmYnA9YTgAX6/Pff9lXXiA3o3YHk=; b=dEgLD9zDRkYWm98/k2xIem1H5CyqL2sF3GJdlTg6nrhld3aULJ4lCHvaYk8f9qnS1B eWGsJGCWxBSrMmGmGgAM2Kkm/AGYylBho6FKi0DAg1xsdcqFffwV/kPUp+X1JyDk9GK2 03gxP/NaZoZusKzlCgYu8R0C64FctgDGSEjX9hN22WzxBk0VeoaOBt3tdMtR0ZhVi+G6 T9N4q80xLdvwgB9Fr2GRdA2F85C+Keuqv93R4mTraYomri5zaeMzlecpkzDSVrtYhjXh ng9zfBaXdx/VJDi8bLlvuX13JhbXNqjZssdemQQn/xdA5fzmYgylrnTC3EFBEuq4hwHK OqtA==
X-Gm-Message-State: AOUpUlGmoh2zT4LjK2U8axcb/qQOGRd7sFTeQLmVtNlxaZctw94Vvxoi Eob0uZ1iaC10zpWLj5hz5SQFr87sjdZYmFCG0bs=
X-Google-Smtp-Source: AAOMgpf/R5bPhsr3qiEdYtIsMWCWK2la1ElNtzA8G/J1Eby0ANqFih9mFyKeGaFZdzijxMlTrSqHCF3lDg8mHLJbwas=
X-Received: by 2002:a1f:df42:: with SMTP id w63-v6mr9735765vkg.135.1531762126542; Mon, 16 Jul 2018 10:28:46 -0700 (PDT)
MIME-Version: 1.0
References: <CAP+sJUd16DitmEodnJ9Djee39kr3wV0O4h+xiwjq_w2+MHdZkw@mail.gmail.com> <F4BB7B94-D72F-4F5D-83C3-86D4E7078969@imt-atlantique.fr>
In-Reply-To: <F4BB7B94-D72F-4F5D-83C3-86D4E7078969@imt-atlantique.fr>
From: Rahul Jadhav <rahul.ietf@gmail.com>
Date: Mon, 16 Jul 2018 13:28:35 -0400
Message-ID: <CAO0Djp1EGao4u73ths1Gadgia=Gt6Tc-9z4WNj88CunnpokQDA@mail.gmail.com>
To: "Georgios Z. Papadopoulos" <georgios.papadopoulos@imt-atlantique.fr>
Cc: "Pascal Thubert (pthubert)" <pthubert@cisco.com>, Routing Over Low power and Lossy networks <roll@ietf.org>, Ines Robles <mariainesrobles@googlemail.com>, "consultancy@vanderstok.org" <consultancy@vanderstok.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/Oa-1XK1oKSxnUx9vqBC9T8-6ixg>
Subject: Re: [Roll] WGLC for draft-ietf-roll-efficient-npdao-03
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.27
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: Mon, 16 Jul 2018 17:28:50 -0000

Thank you Georgios for the review.
Please find my response inline below.

Best,
Rahul

On Mon, 16 Jul 2018 at 06:53, Georgios Z. Papadopoulos
<georgios.papadopoulos@imt-atlantique.fr> wrote:
>
> Dear Roll, Rahul and co-authors,
>
> I find this proposal useful, and quite ready to go.
> Please find my (perhaps minor) comments below.
> — —
>
> [1] 1.2. Current No-Path DAO messaging
> "Subsequently parents or ancestors would release any resources (such as the routing entry) it maintains on behalf of target node.”
>
> [GP] What could be other type of resources, apart from a routing entry, that a parent or ancestors may release?
> Could you provide some more examples?

[RJ]: another something usually done in context to route removal is
decreasing the ref-cnt for the corresponding next-hop nbr-table entry
... such that if the ref-cnt reaches 0/zero the neighbor table entry
could as well be deleted.

>
>
> [2] 3.1. Req#1: Tolerant to link failures to the previous parents
> “Therefore, it is required that the NPDAO message MUST be tolerant to the link failure during the switching.”
>
> [GP] How it can be tolerant, when there is a link failure? What could be the potential means to be tolerant?

[RJ]: The text states that any new route-invalidation mechanism
defined should be tolerant to link failures. The link referred here
represents link between the node and its previous parent (from whom
the node is now disassociating). The way the draft achieves this
tolerance is by having the route invalidation get done through the new
route that is newly established and not depend on the previous link
which is failed.

>
>
> [3] 4.1. Change in RPL route invalidation semantics
> “The trigger for the common ancestor node to generate this DCO is the change in the next hop for the target on reception of an update message in the form of regular DAO for the target.”
>
> [GP] I am having some troubles to understand this sentence, is it possible to be rephrased?

[RJ]: "The common ancestor node generates this DCO in response to the
change in the next-hop on receiving a regular DAO for the target."
Do you think this rephrase works better ?

>
>
> [4] 4.3. Destination Cleanup Object (DCO)
> “The DCO message always traverses downstream and cleans up route information and other state information associated with the given target.”
>
> [GP] Similar to comment [1], is it possible to give some examples of state information?

[RJ]: mentioned as part of [1] response.

>
> — —
> Best,
> Georgios
>
> ____________________________________
>
> Georgios Z. Papadopoulos, Ph.D.
> Associate Professor, IMT Atlantique, Rennes
>
> web:   www.georgiospapadopoulos.com
> twitter:  @gzpapadopoulos
> ____________________________________
>
> On Jul 4, 2018, at 11:40, Ines Robles <mariainesrobles@googlemail.com> wrote:
>
> Dear all,
>
> A Working Group Last call (WGLC) starts today (04/07) until 20/07 for draft-ietf-roll-efficient-npdao-03
>
> The draft is available here:
> https://datatracker.ietf.org/doc/draft-ietf-roll-efficient-npdao/
>
> Please review this draft to see if you think that it is ready for publication and send comments to the list stating your view.
>
>
> Thank you very much in advance,
>
> Ines and Peter
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll
>
>