Re: [Roll] DAO Projection

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Wed, 08 March 2017 14:15 UTC

Return-Path: <pthubert@cisco.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 4866C12969C; Wed, 8 Mar 2017 06:15:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level:
X-Spam-Status: No, score=-14.522 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_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 3VsAE_3Rv63u; Wed, 8 Mar 2017 06:15:07 -0800 (PST)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84A581296A3; Wed, 8 Mar 2017 06:15:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=46946; q=dns/txt; s=iport; t=1488982507; x=1490192107; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=PcX4YNQjsf2xQ1cGCwLxafpk3ksfZtByghxw5G3dxrA=; b=b4+JNsx4hUs8GnLQOGVDaujYhzSnM7YLHqhAjHnDVuxyx4VkfzArub/n GkkYik4pCMmro/gEJDiJXegF3IuCiNbvQ3NgsuB0bYMpcd54zrV92hGkl djhY8otm05VFJOVV/xMZNzO5idH/55OsHyp4mq/22uDRYic0f31xuc+4d 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CJAQDVEMBY/5xdJa1dGQEBAQEBAQEBAQEBBwEBAQEBgm45KmGBCgeDWYoMkUyVOIINhiICGoIhPxgBAgEBAQEBAQFrKIUVAQEBAQMjClwCAQgRBAEBIQEJAgICMB0IAgQBEgiJd7A0giaKfgEBAQEBAQEBAQEBAQEBAQEBAQEBAR2GToRvhDoxgm+CXwWVeoY8AYodiBGCBIUjigKTPQEfOIEDVhWFEx2BY3WJBoENAQEB
X-IronPort-AV: E=Sophos;i="5.36,264,1486425600"; d="scan'208,217";a="221355595"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Mar 2017 14:15:06 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v28EF6xa005464 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 8 Mar 2017 14:15:06 GMT
Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 8 Mar 2017 08:15:05 -0600
Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Wed, 8 Mar 2017 08:15:05 -0600
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>, "draft-ietf-roll-dao-projection@ietf.org" <draft-ietf-roll-dao-projection@ietf.org>
Thread-Topic: [Roll] DAO Projection
Thread-Index: AQHSl9MeIh8COJ/4sE2irW1/vvjuUKGKlx1ggABjkZA=
Date: Wed, 08 Mar 2017 14:14:38 +0000
Deferred-Delivery: Wed, 8 Mar 2017 14:14:16 +0000
Message-ID: <c1c83e50f843485cbd2b5f73db792efc@XCH-RCD-001.cisco.com>
References: <CAO0Djp0VmJsb=tf6U97ndSLyRfjU99rBZR5axxuxLWOUbqTZMQ@mail.gmail.com> <dd356759713b429b8ab5a749acf11001@XCH-RCD-001.cisco.com>
In-Reply-To: <dd356759713b429b8ab5a749acf11001@XCH-RCD-001.cisco.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.228.216.10]
Content-Type: multipart/alternative; boundary="_000_c1c83e50f843485cbd2b5f73db792efcXCHRCD001ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/QFqSEHXtFGCIJcHhPuuV8G1sDrg>
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: Wed, 08 Mar 2017 14:15:09 -0000

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.




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. 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?

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