Re: [Roll] DAO Projection - identifying storing, non-storing P-DAO

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Thu, 14 June 2018 06:44 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 6656D130E7D for <roll@ietfa.amsl.com>; Wed, 13 Jun 2018 23:44:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=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 ExNToHowQQHG for <roll@ietfa.amsl.com>; Wed, 13 Jun 2018 23:44:46 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2DD9130DE7 for <roll@ietf.org>; Wed, 13 Jun 2018 23:44:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7070; q=dns/txt; s=iport; t=1528958685; x=1530168285; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=cjibxE3yao/khZegcWlDtG42uYxoTvnkqez410sEoBs=; b=hL4CHakyKg+cL2pcEPfYFMCECPaJRp7V/WdQKocgwbSykbcfG4UQJACb plP49Ieu/tho7C/1DF+QznjnS20tYl9sDVAEhGYRe3Dzalipl9DhbvS8K Y/gP51+Bovp3JCjVUKd8EpWgZ4t3H+7KhSVic9SYIplWUu82G1UqLyezR A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0DAAACPDiJb/4sNJK1SChkBAQEBAQEBAQEBAQEHAQEBAQGDSGJ/KAqDb4gEjGiBf3WHJYxRFIFkCyOESQIXgiYhNBgBAgEBAQEBAQJtHAyFKAEBAQQjEUUMBAIBCBEEAQEBAgImAgICHxEVCAgCBA4FCIMcgWcDFQ+rP4Ichw0NgSyBYwWBC4dAgVQ/gQ6CD0kHLoJPQgKBNQ8EPoJbglUCkTGHLywJAoV1hgGCf4kihByKDUyGQQIREwGBJB04gVJwFYJ+hX2KUm+OQyqBBIEaAQE
X-IronPort-AV: E=Sophos;i="5.51,222,1526342400"; d="scan'208";a="129441420"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Jun 2018 06:44:45 +0000
Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id w5E6iiAK001052 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 14 Jun 2018 06:44:44 GMT
Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 14 Jun 2018 01:44:44 -0500
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.1320.000; Thu, 14 Jun 2018 01:44:44 -0500
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Rahul Jadhav <rahul.ietf@gmail.com>
CC: Routing Over Low power and Lossy networks <roll@ietf.org>
Thread-Topic: DAO Projection - identifying storing, non-storing P-DAO
Thread-Index: AQHUArmPOlwhv4EjZEKQ3Ahw70fS1aRd5u6wgACDDgD//7V4oIABXriA///O8nA=
Date: Thu, 14 Jun 2018 06:44:14 +0000
Deferred-Delivery: Thu, 14 Jun 2018 06:43:41 +0000
Message-ID: <9c2cd4e89c3f4188b927635727371635@XCH-RCD-001.cisco.com>
References: <CAO0Djp1n9oQ3wDD0TFJZqKD70ZBHP5rXac+Hz7xzS88aQGnYsA@mail.gmail.com> <6b16c897762d4f979b8302022c79bf79@XCH-RCD-001.cisco.com> <CAO0Djp0_1w=-kajs12Cg-yApDqpy1YqLjbPbrxe8uyUxoUoC3Q@mail.gmail.com> <b1282340e5184a34bbd3cb3d2f624997@XCH-RCD-001.cisco.com> <CAO0Djp0_nUSk+V2NyJS-gzZbDdkG_gwYjsDsfiLHs8xuKBSjgA@mail.gmail.com>
In-Reply-To: <CAO0Djp0_nUSk+V2NyJS-gzZbDdkG_gwYjsDsfiLHs8xuKBSjgA@mail.gmail.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.61.71.141]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/MP0xkVkOKVctqQVAd3HYei10cB4>
Subject: Re: [Roll] DAO Projection - identifying storing, non-storing P-DAO
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.26
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: Thu, 14 Jun 2018 06:44:49 -0000

Hello Rahul

I think one intent was to easily snip snap the extra VIOs once they are consumed if we decided to do so. At the moment a node locates itself so it does not matter but that may be impractical.. 
With a single VIO that would mean either massage the VIO to shrink it (and then lose chances to sign from the root in the future) or to have an segment-used field like Routing Headers do.

Another intent was to indicate a shorter lifetime when closer to egress. The point being that the route must disappear at ingress before it disappears at egress, otherwise loops may form. 
We need to add words on that.

What do you think?

Pascal

> -----Original Message-----
> From: Rahul Jadhav <rahul.ietf@gmail.com>
> Sent: jeudi 14 juin 2018 06:27
> To: Pascal Thubert (pthubert) <pthubert@cisco.com>
> Cc: Routing Over Low power and Lossy networks <roll@ietf.org>
> Subject: Re: DAO Projection - identifying storing, non-storing P-DAO
> 
> Yes, using new type (SRVIO) is a better idea.
> Thus we can have SRVIO and VIO for non-storing and storing mode
> respectively and these options will be mutually exclusive .. i.e. when SRVIO is
> sent, there should not be any VIO in the DAO and vice-versa.
> 
> For storing mode P-DAO,no is there a reason to have multiple VIOs? I mean,
> can we keep multiple vias in the same VIO? The reason for doing this is,
> currently we have different path-seq/lifetime per VIO and having it separately
> does not help. I m not sure what an implementation can do with different
> path-seq values in multiple VIO for the same target from the same originator.
> On Wed, 13 Jun 2018 at 18:06, Pascal Thubert (pthubert)
> <pthubert@cisco.com> wrote:
> >
> > Hello Rahul:
> >
> > As you figured, the original intent was to replace the TIO by a VIO. So yes,
> your proposal is workable.
> > An alternate could be to define a source-routed VIO (SRVIO) with Type = 0xB
> and keep the current VIO for storing mode only.
> >
> > What do you think?
> >
> > Pascal
> >
> >
> > > -----Original Message-----
> > > From: Rahul Jadhav <rahul.ietf@gmail.com>
> > > Sent: mercredi 13 juin 2018 13:58
> > > To: Pascal Thubert (pthubert) <pthubert@cisco.com>
> > > Cc: Routing Over Low power and Lossy networks <roll@ietf.org>
> > > Subject: Re: DAO Projection - identifying storing, non-storing P-DAO
> > >
> > > One thing that comes to my mind is using DAO base object bits... But
> > > i m not sure if they can/should be expended for such purpose.
> > > Another option is to use TIO bits and make TIO mandatory preceding
> > > the VIOs ... Other fields such as path-seq/lifetime can also be
> > > removed from VIO and can be kept only in TIO. Anyways having a
> > > different Path-Sequence in individual VIOs does not help (not sure
> > > if having a different path lifetime in individual VIO is needed?).
> > > For current implementation, i m planning to go ahead with an extra
> > > pass/traversal over the options to check for multiple VIOs.
> > >  On Wed, 13 Jun 2018 at 14:54, Pascal Thubert (pthubert)
> > > <pthubert@cisco.com> wrote:
> > > >
> > > > I agree Rahul,
> > > >
> > > > I picked that method as a starting point but as I presented at the
> > > > IETF
> > > meeting I do not like it either, and it would be great that the
> > > group come up with something better.
> > > >
> > > > Would you have a particular preference based on your experience here?
> > > >
> > > > Pascal
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: Rahul Jadhav <rahul.ietf@gmail.com>
> > > > > Sent: mercredi 13 juin 2018 03:55
> > > > > To: Routing Over Low power and Lossy networks <roll@ietf.org>;
> > > > > Pascal Thubert (pthubert) <pthubert@cisco.com>
> > > > > Subject: DAO Projection - identifying storing, non-storing P-DAO
> > > > >
> > > > > Hello Pascal, WG,
> > > > >
> > > > > When i started implementing storing mode P-DAO, i faced one
> > > > > problem, ... as per the draft the only way to identify storing
> > > > > P-DAO from non-storing P-DAO is that storing P-DAO has at-least
> > > > > 2 VIOs whereas non-storing P-DAO has only one VIO.
> > > > > The problem with implementation is that i need to traverse the
> > > > > whole P-DAO before i know whether it is storing or non-storing
> > > > > P-DAO and populate the route table accordingly. This way either
> > > > > i have to buffer VIO/via temporarily and then act. Otherwise i
> > > > > have to have a 2-pass traversal through the P-DAO to check
> > > > > whether it is storing or non-storing first and then act on the fields in
> later pass.
> > > > >
> > > > > If we can have a flag somewhere in the P-DAO header to signal
> > > > > storing or non- storing then it would make implementation much
> simpler.
> > > > >
> > > > > For interested ones, part implementation of DAO projection code is at:
> > > > > https://github.com/whitefield-framework/contiki/tree/dao_project
> > > > > ion It currently supports registration/unregistration of
> > > > > projected routes using non-storing P-DAO with +/- ACKing.
> > > > >
> > > > > Regards,
> > > > > Rahul