Re: [Roll] DAO Projection
Rahul Jadhav <rahul.ietf@gmail.com> Thu, 09 March 2017 05:00 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 9B33412961D; Wed, 8 Mar 2017 21:00:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DC_PNG_UNO_LARGO=0.001, 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 wVM_ptO6fWkF; Wed, 8 Mar 2017 21:00:48 -0800 (PST)
Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (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 3C52D124281; Wed, 8 Mar 2017 21:00:48 -0800 (PST)
Received: by mail-ua0-x22f.google.com with SMTP id q7so53584796uaf.2; Wed, 08 Mar 2017 21:00:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6o/6sEk28EK2CcDTFmCrykOZtTYR75gT7x1Duy+PQKE=; b=lzq8wSVBkv89yXBwwG+z90YuyFUFMechsOv2lglWi6LcgXkgdmTFV9uE6Uqc+ZN26W GYrreY+ToYYUXEVEb7jI8ZmlyBMV0bckU6w+uzvvQ/tillMunbaqKKO1l/zwlYQ3jMY3 QaLCjRnbKR+G62L5PtGJSCYeqPSP+L6FmyUyrp5ZdyrV1v+8VNWmeQkYg/gSExNGoqhF fViICg44nJPnn/1ihXwuxl42MrOTyGrMHyrCAxXBwki2/gaadZwklWv8mwblIw95LN5i YUrhC21M1cuGLpciAq6/eTc6/kMl/mJ85gHA6mHGXdjijGxdZYjcxl+dfOGDXwV3p/WF by1g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6o/6sEk28EK2CcDTFmCrykOZtTYR75gT7x1Duy+PQKE=; b=oDDoDbskdB7rMIFdfoXbb+vhS4L8Jx0R4E6Aqub9Ab7KvUP+SUFN4Ai7nNetEca2gD qC5hI8ImGtDOe9EyuC3Ps91rr6SiyZjtJqAiGDiIk4v9O//2X2GGrQNun99gCaaAExeE 9rWpTQzFkf8cIh1F+7yySeiNmxi/KYwErADsHfSgUOUp808yEyUbOeM5ug873t9ryM8s s7rEzWjjXOsowzsk3z2RxwwqE/3uV54Ns4xYtaKVAY0kzwxY2oTayPtWGLfKCCTgrPLp GJlpMNxFKtyFCfdKNVRqHWf9TYD0AbS29dQjmQdLQoFzIrIhF2gxTOBoq67ZSE7AVom7 WpKw==
X-Gm-Message-State: AMke39lOLdXVUGS76GL9loi6ljnqQaHjzy81G5Lmxrccr4u52EnImBw3enzmRaC+wcOZoi98AMDJyOeJOGmhrQ==
X-Received: by 10.159.49.15 with SMTP id m15mr6594859uab.87.1489035646853; Wed, 08 Mar 2017 21:00:46 -0800 (PST)
MIME-Version: 1.0
Received: by 10.103.140.70 with HTTP; Wed, 8 Mar 2017 21:00:45 -0800 (PST)
In-Reply-To: <c1c83e50f843485cbd2b5f73db792efc@XCH-RCD-001.cisco.com>
References: <CAO0Djp0VmJsb=tf6U97ndSLyRfjU99rBZR5axxuxLWOUbqTZMQ@mail.gmail.com> <dd356759713b429b8ab5a749acf11001@XCH-RCD-001.cisco.com> <c1c83e50f843485cbd2b5f73db792efc@XCH-RCD-001.cisco.com>
From: Rahul Jadhav <rahul.ietf@gmail.com>
Date: Wed, 08 Mar 2017 21:00:45 -0800
Message-ID: <CAO0Djp2Wma4prsuGX_oxPVVdEzvZtOuB8Qr4wKjR7h8BM7mrPA@mail.gmail.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Content-Type: multipart/related; boundary="f403045e3012ca054d054a452078"
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/YUsPWeXnq0T_Iees37sKc8TBKxU>
Cc: "draft-ietf-roll-dao-projection@ietf.org" <draft-ietf-roll-dao-projection@ietf.org>
Subject: Re: [Roll] DAO Projection
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: Routing Over Low power and Lossy networks <roll@ietf.org>
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: Thu, 09 Mar 2017 05:00:50 -0000
Hello Pascal, Please find my resp inline... Regards, Rahul On 8 March 2017 at 06:14, Pascal Thubert (pthubert) <pthubert@cisco.com> wrote: > Hello Again Rahul : > > > > For item 1, there was already text indicating that the lifetime in the Via > Information option is similar to that in the Transit Information option > (e.g. in section 3.1). > > Proposal: in the text below, the first sentence was already present and > the suggestion is to add the following one. > > > > A lifetime of 0 in the Via Information option along the segment is > used to > > clean up the state. The DAO is forwarded as described above, but the > DAO > > is interpreted as a No-Path DAO and results in cleaning up existing > state > > as opposed to refreshing an existing one or installing a new one. > [RJ] Yes this works fine. I somehow missed the VIA option with lifetime 0. I assume this NPDAO_via0 (VIA with lifetime=0) flows the same path as DAO. Also consider the following scenario where the previously installed p2p path is not available due to link breakage. Based on foll topology diagram, if B switches path to C, if NPDA0_via0 is sent to B then we know that the route cleanup wont be done at A since NPDAO_via0 will fail since the link is not available. I understand that 6LBR will eventually know about this since it wont receive DAO_ACK from A but m not sure what actions it can take to ensure cleanup... What if the route cleanup is initiated from common parent? i.e. from A and flows downwards... i.e. NPDAO_via0 is sent to A and then it goes to B ... this will result in more efficient cleanup. But i understand that now the semantic changes between DAO and NPDAO_via0. Note that without cleanup there is an impact on P2P traffic, hence it might be needed to ensure cleanup if not much overhead is added. [image: Inline images 1] > > > > > > > > > For item 2 I suggest the following operation: > > The Via Information option MUST contain at least one Via Address. > > The first address in a Via Information option denotes an intermediate > router > > in which a routing state is to be installed to reach the target > indicated in the RPL > > Target Option. > > If there is only one address, then the routing state to be installed > in the > > intermediate node that owns the Via Address is a storing mode route to > the > > target in the RPL Target Option via the source of the DAO. When > forwarding a > > packet to the target, there is no need to add a source route header or > an > > encapsulation > > > > If more than one address is present in the Via Information option, > then the > > additional Via Addresses denote a source routed path to the source of > the > > DAO that must be used to reach the target in the RPL Target Option. > [RJ]: What does "to the source of the DAO" means in this context ? > In > > that case, the routing state to be installed in the intermediate node > that > > owns the first Via Address is a non-storing mode route to the target > via the > > other Via Addresses in the Via Information option and then the source > of the > > DAO. When forwarding a packet to the target, the intermediate node MUST > > encapsulate the packet using Via Address 1 as source and Via Address 2 > > as destination, and add a source routed header that contains any > additional > > Via Addresses in the order of the Via Information option, and the > source of > > the DAO message. > > > > 0 1 2 3 > > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | Type = 0x0A | Option Length | Path Sequence | Path Lifetime | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > + + > > . . > > . Via Address 1 . > > . . > > + + > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > . .... . > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > | | > > + + > > . . > > . Via Address n . > > . . > > + + > > | | > > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > > > > > > > > > We’ll probably need to restructure the doc a bit, but I’d wish to agree on > the operation first. > > > > Does the above work for you? > [RJ]: Yes the scheme works for me. If i m correct, this messaging which involves having one or more addresses in VIO will now allow to install SRH as well as storing mode routes using the same DAO message. Nice! > > Take care, > > > > Pascal > > > > > > *From:* Pascal Thubert (pthubert) > *Sent:* mercredi 8 mars 2017 09:19 > *To:* Routing Over Low power and Lossy networks <roll@ietf.org>; > draft-ietf-roll-dao-projection@ietf.org > *Subject:* RE: [Roll] DAO Projection > > > > Hello Rahul : > > > > Thanks for your comments, all spot on : ) > > > > Please see below > > > > Installing routes by DAO projection in NS-MOP will help in establishing > optimized P2P paths, as well as it will help in containing the 6lo > fragmentation resulting out of bulged SRH at 6LBR. > > Thanks for the work. > > > > There are few observations/Qs: > > > > 1. The draft discusses about projecting DAO for route installations. But i > assume the same projection mechanism can be used for route removal (?). > This might be needed considering that NPDAO is not required in NS-MOP and > that the VIA lifetimes could be high. > > > > [Pascal] Right. A sentence indicating that a lifetime of zero will trigger > a NP DAO and do the cleanup should suffice. Do you agree? > > > > 2. Did you also considered installing an SRH (for downstream dest) at > intermediate 6LR rather that installing routes along a segment (segment as > per defn in the draft)? > > > > [Pascal] This is yet a new mechanism. I’m all for it. The 6LoRH make the > task of encaps/insertion a lot easier now. All: if you disagree to the > addition please let us know now. > > > > 3. There is a redundant paragraph and missing lines at the end of section > 5 which tries explaining the example. Please fix the draft and will be nice > to check that example. > > > > [Pascal] oups! Will fix before cutoff. > > > > Take care, > > Pascal > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > >
- [Roll] DAO Projection Rahul Jadhav
- Re: [Roll] DAO Projection Pascal Thubert (pthubert)
- Re: [Roll] DAO Projection Pascal Thubert (pthubert)
- Re: [Roll] DAO Projection Rahul Jadhav
- Re: [Roll] DAO Projection Pascal Thubert (pthubert)
- Re: [Roll] DAO Projection Michael Richardson
- Re: [Roll] DAO Projection Pascal Thubert (pthubert)