Re: [Roll] DAO-Projection loop handling

Rahul Jadhav <rahul.ietf@gmail.com> Mon, 10 December 2018 17:23 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 9DF531310E1 for <roll@ietfa.amsl.com>; Mon, 10 Dec 2018 09:23:11 -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_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 dQI5eW5I4j1J for <roll@ietfa.amsl.com>; Mon, 10 Dec 2018 09:23:09 -0800 (PST)
Received: from mail-vs1-xe34.google.com (mail-vs1-xe34.google.com [IPv6:2607:f8b0:4864:20::e34]) (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 35CE91310DC for <roll@ietf.org>; Mon, 10 Dec 2018 09:23:09 -0800 (PST)
Received: by mail-vs1-xe34.google.com with SMTP id h18so7129174vsj.4 for <roll@ietf.org>; Mon, 10 Dec 2018 09:23:09 -0800 (PST)
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; bh=t1kszy/JJkwdUJ9zwx6LQrnYb7f338cjTkdR4AAlVKY=; b=LMVQ/wdfwwrLJVYG0f4tJYUgN+RNQ6XaHEoO10PFWqMyMxjgTFNBTXDXvSq0E2tbQx Ug+mLa4G5xeXlfStWrvdgXvyysBRwuvpmC8vBNWqqUe5U2ogjDJWHiTVFxQDyRLoNSiS ytxMfEqr+KfRzCfEd5iuwAEe6vkwG/VrjCGP91vSMcWEZj5aK0DzKc1lPjVOJAK78Z2I tdiMIEM/LEb9ZXby+C2gfBZ4bJepekJgYO5OI5+l+agEN0yJv4WWwjU+AgWVnNtwedjw ylsdmc5QP3uCiiVCw62c76tMV5eX2ExCVFgdFN2N2bHwBqzYw4mdI7UdKma0akxLnlJY y6Bg==
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; bh=t1kszy/JJkwdUJ9zwx6LQrnYb7f338cjTkdR4AAlVKY=; b=MwayVZk//+8Ag+ul3ODMswk/OnEiSrflQ18ZdULXXwF7WLVCma4POByiP3/h2SmvB1 +i+HIFwHj8OZO6QGjPwkAhrzjfE2dNraCUhAwZEB+kCa9gVSugmkVQ6PffoM05oYw2xc 3EyxTkkS07AZyKCfXnd70J4UYmT9YhgcJ2LW7JWzN8FFSEccXoCzgqLH1ILR60xAyS7Z NMEhOApd3PZwkKr5++DHt7Fh4DPg8wBLC2+nKb2GwHhmgKWbxWb7RXr6SsmFnk9pPsFh Y7zEVJEEIkLy6o8JC+3MVkzGxme5/4XixbsOsXft+/a+PDeNfEhImQNtWkr1YqdQvXjy 9/bw==
X-Gm-Message-State: AA+aEWZJzjpusdS3E8WXboHKryuy9NF8Y3VB5Czfoxes7Zs6BS7JfXFq UdnLQdyRqdRarxY+3YdRUr8rwz5O9tSKLmN3xkw=
X-Google-Smtp-Source: AFSGD/XdFSKOyl8O5Q19fhACXbAdedOqtZ+BePW5JD3vqH/4K4gOFFDWB69/AodIspbbFSTQEgVGbPufmmAEmSCZGNg=
X-Received: by 2002:a67:2704:: with SMTP id n4mr5701978vsn.208.1544462587880; Mon, 10 Dec 2018 09:23:07 -0800 (PST)
MIME-Version: 1.0
References: <CAO0Djp3j_BQKhU_+MzLuWQ2rdK4Jep+3VNBASmxWNnR-uNmLmA@mail.gmail.com> <532D623B-92FD-4298-B6E6-0B5625CEA4C6@cisco.com> <CAO0Djp0i_fLsXLi1vF0ouDPku1L=Yi6ZzT3=PhCGJkarzvzO_Q@mail.gmail.com> <1fe6d1a97f5d4150b6efc8519075e53c@XCH-RCD-001.cisco.com>
In-Reply-To: <1fe6d1a97f5d4150b6efc8519075e53c@XCH-RCD-001.cisco.com>
From: Rahul Jadhav <rahul.ietf@gmail.com>
Date: Mon, 10 Dec 2018 22:52:56 +0530
Message-ID: <CAO0Djp1R0dg06z=UoGyE72Xx30kXzc=J=CJC8uC2B8-Sko6Okw@mail.gmail.com>
To: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
Cc: Rahul Arvind Jadhav <rahul.jadhav@huawei.com>, Routing Over Low power and Lossy networks <roll@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000eb69ae057cae377d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/B6V_7KKWOH0R6BVAI87Fu8FlHfs>
Subject: Re: [Roll] DAO-Projection loop handling
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: Mon, 10 Dec 2018 17:23:12 -0000

Hello Pascal,

<<CCing ROLL herewith>>
@ROLL, This mail discussion is related to loop handling with DAO
projection. There are some design decisions that have to be taken and we
would appreciate any feedback.

Continuing the discussion... Please find my comments inline below.

Regards,
Rahul

On Mon, 10 Dec 2018 at 19:29, Pascal Thubert (pthubert) <pthubert@cisco.com>
wrote:

> Hello Rahul
>
>
>
> *From:* Rahul Jadhav <rahul.ietf@gmail.com>
> *Sent:* lundi 10 décembre 2018 17:29
> *To:* Pascal Thubert (pthubert) <pthubert@cisco.com>; Rahul Arvind Jadhav
> <rahul.jadhav@huawei.com>
> *Subject:* Re: DAO-Projection loop handling
>
>
>
> Interesting! If we disallow placing the packet back in normal routing,
> then it does solve the loop problem in case of hop-by-hop projected routing.
>
> As you mentioned, RPI can be put to use. Single bit should suffice.
> Anyways this RPI bit is in context to the corresponding RPLInstanceId.
>
> *[PT>] yes. The alternate is to use a separate instance. A packet can be
> placed from the normal instance to the RP one but not the other way around.
> We need to cc the list on a conversation like this. Do you mind?*
>
[RJ]: I didn't understand how can a separate instance be used. Which
message will declare a separate instance? Do you mean the P-DAO will be
sent on a separate instance? Not clear on how these semantics be handled.
The RPLInstanceID in DAO is learned from DIO and cannot be changed (because
it carries corresponding metrics/constraints/OF association).


>   One more doubt i have is in context to proactive clearing of routing
> entries directly on realizing that the target on the projected-path is not
> reachable.
>
> *[PT>] the ‘F’ bit can be used as specified in RFC 6550*
>

>
> The problem here is that there could be two targets with common network
> segment (with hop-by-hop routing) in between and thus proactive cleanup may
> not be possible. What do you think? There are some ways to handle these
> scenarios.
>
> Do you think this warrants a text in the draft?I have this point in my
> todo list.
>
> *[PT>] Yes.*
>

>
> Also do you think i should add text for disallowing the packet back in
> normal routing and corresponding RPI semantics?
>
> *[PT>] Yes, please check the text I already wrote on that matter. Not sure
> I wrote it but I thought so load that maybe it got there!*
>
[RJ] Ok

>
>
> *Take care;*
>
>
>
> *Pascal*
>
>
>
> Regards,
>
> Rahul
>
> p.s. i got a mail rgding draft expiry. so i can target end of this week
> for an update.
>
>
>
>
>
> On Mon, 10 Dec 2018 at 11:59, Pascal Thubert (pthubert) <
> pthubert@cisco.com> wrote:
>
> We need to talk Rahul!
>
>
>
> This is important text; I tried to put provisions for loop avoidance
> already by forcing strict hop by hop routes, loose only if the hops are
> separated by strict source routes.
>
>
>
> If the packets can be tagged as following a projected route then we can
> disallow placing the packet back in normal routing and thus avoid loops.
>
> It would be good to move the existing text I had to your session. Then we
> need to decide how to tag the packets placed into projected routes. Maybe
> the last bit in the RPI?
>
>
>
> Pascal
>
>
> Le 7 déc. 2018 à 09:50, Rahul Jadhav <rahul.ietf@gmail.com> a écrit :
>
> Hi Pascal,
>
>
>
> I have started adding loop-handling section in the dao-projection draft.
>
>
>
> Please review the PR and would like to get any feedback.
>
> https://github.com/roll-wg/dao-projection/pull/1
>
>
>
> Please note there will be more updates to these sections in next few days.
>
>
>
> Regards,
>
> Rahul
>
>
>
>