Re: [Roll] FW: New Version Notification for draft-thubert-roll-eliding-dio-information-01.txt

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Fri, 25 October 2019 13:17 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 0331312004E for <roll@ietfa.amsl.com>; Fri, 25 Oct 2019 06:17:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Level:
X-Spam-Status: No, score=-14.5 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, 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 header.b=CUT7jaCR; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=p/bnJCpg
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 ZruhO3seX3Yw for <roll@ietfa.amsl.com>; Fri, 25 Oct 2019 06:17:44 -0700 (PDT)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BBCC120877 for <roll@ietf.org>; Fri, 25 Oct 2019 06:17:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20572; q=dns/txt; s=iport; t=1572009463; x=1573219063; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=H7lwN85j7p/puMbPN8apWmWCAZkvCDhgBUergu/u1uY=; b=CUT7jaCRf1U/EYbQ9baUx/PYgHYzbcaECtOLNE5mV+ZCGABL1NKQizTD IGGQtleXiWCeHSsKf6r7AO0qBaSoov/ImJzDHpiPjhwdYljCpgiH1EZFT 0vXj9OIOVsnvdF+z/AGc7um8JQklpP9XJhDWi8VR15pMrDM+opc4XNjtw 0=;
IronPort-PHdr: =?us-ascii?q?9a23=3Ak86HLB8YVK4Ea/9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+8ZR7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfk0jgZdYBUER?= =?us-ascii?q?oMiMEYhQslVdaZCVDxIeT2Ryc7B89FElRi+iLzPA=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AKAAA09bJd/4wNJK1lGgEBAQEBAQE?= =?us-ascii?q?BAQMBAQEBEQEBAQICAQEBAYFnBQEBAQELAYFKJCwFbFcgBAsqg2hAg0cDhFq?= =?us-ascii?q?GDk6CEH+XBoEugSQDVAkBAQEMAQEYCwoCAQGEQAIXgygkNAkOAgMJAQEEAQE?= =?us-ascii?q?BAgEFBG2FNwyFUAEBAQEDAQEKAgQREQwBASMCBwkDCwQCAQYCEQQBAQECAiY?= =?us-ascii?q?CAgIlCxUICAIEEwgagwGCRgMuAQIMllOQYgKBOIhhdYEygn4BAQWFChiCFwM?= =?us-ascii?q?GgQ4oAYUVhnkYgUA/gRFGgU5JNT6CYgEBgUUeBRAhAoJWMoIsj3idcQqCJIc?= =?us-ascii?q?QjjiCPIdUhC+GX4Q1lmaRIgIEAgQFAg4BAQWBUjmBWHAVO4JsUBAUgwYJGhW?= =?us-ascii?q?DO4UUhT90gSmPBgEB?=
X-IronPort-AV: E=Sophos;i="5.68,228,1569283200"; d="scan'208";a="653767971"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Oct 2019 13:17:42 +0000
Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id x9PDHgfm024735 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for <roll@ietf.org>; Fri, 25 Oct 2019 13:17:42 GMT
Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 25 Oct 2019 08:17:42 -0500
Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 25 Oct 2019 08:17:41 -0500
Received: from NAM04-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 25 Oct 2019 08:17:41 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=P4chXWf9nRHq2i3b7t/UrvkQw6roMTv7l4qSy495n15T4dk57u51IHVvNRM9ekub8JnUIOorkTPR4z+GPGVqXM431EAmVX4a5lc8tAQo9ClaheXhKWrFQnE4Uvx7/iyo+f5YutIpKzlcamnUx6yKyysPvaw4k7a1fbeTtiBhHebV5bhqk7O4x0QkmUWif/SuJOG8FdTKbuTkWAN4Q0n9DvYPzqlR0waOjDA3ExAO9LR7gYiJnV7ETwot8ZP7/tFpSZOWoHeXiCwRCqN83saPfH3s5K6BDcSRC7YkdxXWNEPdrhDJ9xjdiUVGHfzFccVPSE+hnmj9BK3uqV3mae5Pxg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=H7lwN85j7p/puMbPN8apWmWCAZkvCDhgBUergu/u1uY=; b=C0eCAVS3uVIJd9FQV8VxwDfV2MF6SYOVv2JeziCPsTcUMRa3sh3u3rkCHyolLBfnHD/JyVYrhm52nXdtroXRr4HrKSZI+zQswTewSBIHvGt99Z2g7PfU6yWY0y9KZDXkwkLEelI/eR+LuYKc6HedM7IJ5asax7LT1oviKlN2N1voULzqQre9bDRbDxbGg0Zz8J9ebdcUnGyW25rMkRLXryzwlRN5j2S7FxNu1Z3tyL5axsdb72rL52WgdPRXj4Lz/udTG6pz3JcnoI0vPlUvqHOaxXjaYypSGRVWa6sngcKSG6AmgO1bYb1vXME+1TSYeRrda4FA+HJm/uO1nxlKjg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=H7lwN85j7p/puMbPN8apWmWCAZkvCDhgBUergu/u1uY=; b=p/bnJCpgG28Js6h25yJnAB5LvNIxWmp3Jc2JsD/q607EDg0YOEkrHZWZ6Eq1M05JOdWv+WJuyr57mWagi+snXg9fJDIpOwb2NA0QwXn0fjyVZPucE89/GlLHTWKZ1PPHePbXdc5aEVJdca1vFsvk/QYpfokGSlJXh5LznS94oxk=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3727.namprd11.prod.outlook.com (20.178.252.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2387.20; Fri, 25 Oct 2019 13:17:39 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::31c9:3a31:3c07:a920]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::31c9:3a31:3c07:a920%6]) with mapi id 15.20.2387.023; Fri, 25 Oct 2019 13:17:39 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Thread-Topic: [Roll] FW: New Version Notification for draft-thubert-roll-eliding-dio-information-01.txt
Thread-Index: AQHVhWPlvolp6YcUTEixv+i6F591iKdgEgGggAToGAD//9YaYIABq+aA//+0ZACAACu44IAAtj0AgAA08AD//4nTAAAmr9mAAAOtcVAAMWVKAAAHiUCAAC7AkZA=
Date: Fri, 25 Oct 2019 13:17:37 +0000
Deferred-Delivery: Fri, 25 Oct 2019 13:16:46 +0000
Message-ID: <MN2PR11MB356574E686390B57684EC873D8650@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <29223591-193D-46D5-8EE1-0C93C84FABB6@cisco.com> <657F6717-C1BF-47B9-B5CF-7CC543286ACE@cisco.com> <MN2PR11MB356505C7BD4992374FEA50FCD8680@MN2PR11MB3565.namprd11.prod.outlook.com> <55994E79-0BF7-4ADD-B17F-3FAC01A35196@cisco.com> <9337B143-421C-4EAF-9A52-2985F4FB75E0@cisco.com> <MN2PR11MB3565F753E5896AEC70D866DED8680@MN2PR11MB3565.namprd11.prod.outlook.com> <F94FB6D6-E1C1-4DDA-B9BE-0E81FB941A5C@cisco.com> <MN2PR11MB35658EC51B91397AD7844AF2D86B0@MN2PR11MB3565.namprd11.prod.outlook.com> <B48E0219-051A-4C11-908C-EBEB0C3AED97@cisco.com> <8A56E85C-AF71-4BE9-8774-5A8D63BE45A4@cisco.com>
In-Reply-To: <8A56E85C-AF71-4BE9-8774-5A8D63BE45A4@cisco.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com;
x-originating-ip: [2001:420:44f3:1300:fc9e:730:2c16:4060]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 9d4e88fc-c29e-47e0-1b69-08d7594db616
x-ms-traffictypediagnostic: MN2PR11MB3727:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <MN2PR11MB3727C5B8761EE99FD9C15343D8650@MN2PR11MB3727.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 02015246A9
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(39860400002)(396003)(366004)(376002)(346002)(13464003)(43544003)(199004)(189003)(186003)(11346002)(476003)(30864003)(66574012)(5660300002)(76176011)(256004)(7696005)(446003)(46003)(6116002)(6916009)(52536014)(486006)(71200400001)(86362001)(305945005)(14444005)(7736002)(71190400001)(9686003)(2906002)(8676002)(6246003)(966005)(99286004)(102836004)(25786009)(81156014)(81166006)(74316002)(14454004)(66476007)(66946007)(66446008)(76116006)(15650500001)(66556008)(64756008)(33656002)(561944003)(229853002)(316002)(53546011)(6506007)(6306002)(6436002)(55016002)(478600001)(8936002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3727; H:MN2PR11MB3565.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: I2IYsXuiSkb8Ap+kMQqqSxtfyC4qORBCQYChWt/U53IC25v1vooPMP/fE+xS6NVslcxHCMZbW6iuPsFzjyVtH+iX4YuVtx8rctoGl45ZJhfZCYORcc9gg9IBSbEbcbReu3eVE27H8DZKa+McUt2dTHcpuMcUKTyVRxRGyoF5l61Tq3jtKYRY26/5o1T3bUxsmfXUv+QSIeD/LVVVf+QLDJnvbybRVAWHxoqm+hY9Le52GBM9WYR+9EYAmHuckRmngoIEuzoenyW9d5+H8n10afMniSJA/SngiT9ZoTxKblGkNrRLt94LMgJgO/3U0WvyGRU3MDWM/aEL7k7EJ0peiYSOEc+GD1xa3COqD0G/7OSSXGWBJRMs8+X9jTaGZGjYCs3kCJ0gec6CU0d1KmYru+DlEJ4y/6Cy7sxatEZfVJ5SQ0vtqsesG/eOoJl7wRnV0dxIrmqhaWICE8Vifg9xnq28S5ibjwP//a0zW0qanIY=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 9d4e88fc-c29e-47e0-1b69-08d7594db616
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Oct 2019 13:17:39.7561 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: P6Ior1fuObGTi+/yAxruNFOKG5Hd57Z3QJTB3X5ANL+PxIOav1Jtw+v+b4nZFdLWzxwHXWetjG7hg+wv0fSiMA==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3727
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.24, xch-aln-014.cisco.com
X-Outbound-Node: alln-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/2WrVtm4O260DZl5SXDhByzb3fLY>
Subject: Re: [Roll] FW: New Version Notification for draft-thubert-roll-eliding-dio-information-01.txt
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: Fri, 25 Oct 2019 13:17:47 -0000

It's now merged, Li.

We'll probably need a capability to indicate that the abbreviations are supported, in particular for DAO.

All the best

Pascal

> -----Original Message-----
> From: Roll <roll-bounces@ietf.org> On Behalf Of Li Zhao (liz3)
> Sent: jeudi 24 octobre 2019 08:56
> To: Routing Over Low power and Lossy networks <roll@ietf.org>
> Subject: Re: [Roll] FW: New Version Notification for draft-thubert-roll-eliding-
> dio-information-01.txt
> 
> Hello Again Pascal,
> 
> I've written it in https://github.com/roll-wg/eliding-dio-information/pull/2.
> Could you please take a look?
> 
> Best regards,
> Li
> 
> On 2019/10/24, 11:20, "Roll on behalf of Li Zhao (liz3)" <roll-bounces@ietf.org
> on behalf of liz3@cisco.com> wrote:
> 
>     Hello Pascal,
> 
>     Add new flag in DAO is a better option. I'll write it down later.
> 
>     Best regards,
>     Li
> 
>     On 2019/10/23, 20:57, "Roll on behalf of Pascal Thubert (pthubert)" <roll-
> bounces@ietf.org on behalf of pthubert@cisco.com> wrote:
> 
>         Hello Li
> 
>         The AOO abbreviates an option. It is strange to me to use it to abbreviate a
> full RPL control message. And I do not think we need that.
> 
>         Currently there should not be a DAO with no option in it. So we do not
> really have a collision with RFC 6550. Still I understand your point and I'd be
> happy to add a flag in the DAO to say that the DAO is globally abbreviated.
> 
>         Would that work for you?
> 
>         Pascal
> 
>         -----Original Message-----
>         From: Roll <roll-bounces@ietf.org> On Behalf Of Li Zhao (liz3)
>         Sent: mercredi 23 octobre 2019 04:01
>         To: Routing Over Low power and Lossy networks <roll@ietf.org>
>         Subject: Re: [Roll] FW: New Version Notification for draft-thubert-roll-
> eliding-dio-information-01.txt
> 
>         Hello Pascal,
> 
>         The reason why we need AOO in DAO is to distinguish whether this DAO
> carries elide options.
> 
>         Otherwise, there is a compatibility issue if the behavior for DAO with no
> option changes. Because currently when node receives this DAO with no option,
> it does nothing according to RFC6550.
> 
>         For the 2 targets case, can we use Abbreviated Option as 0x00 or 0xff to
> indicate all options unchanged?
> 
>         Best regards,
>         Li
> 
>         On 2019/10/22, 23:44, "Roll on behalf of Pascal Thubert (pthubert)" <roll-
> bounces@ietf.org on behalf of pthubert@cisco.com> wrote:
> 
>             Hello Li
> 
>             My initial thought was that we'd not use AOO at all in DAO messages,
> we'd  elide all options or no option.
>             I do not really see how we could do partial increments of some options
> and not others.
>             I see that your proposal requires AOOs in DAOs as well. Do you have a
> case in mind?
>             If we start replacing stuff with AOO tin DAOs things could get hairy, like I
> have 2 targets with a few transit each. One target changes. Or one transit
> changes. How would we use the AOO?
> 
>             The keep it simple way is to add a section on DAO that does not use AOO
> at all.
> 
>             Take care,
> 
>             Pascal
> 
>             -----Original Message-----
>             From: Roll <roll-bounces@ietf.org> On Behalf Of Li Zhao (liz3)
>             Sent: mardi 22 octobre 2019 16:36
>             To: Routing Over Low power and Lossy networks <roll@ietf.org>
>             Subject: Re: [Roll] FW: New Version Notification for draft-thubert-roll-
> eliding-dio-information-01.txt
> 
>             Hello Again Pascal,
> 
>             I've written it down but it seems that I don't have permission to push it to
> github.
>             The main change is in section 4.3 as following:
> 
>             The abbreviated version of an option is a replacement for any option.
>                It does not advertise the content of the option but indicates the
>                sender's value for the last modified sequence of that option. It
>                is transported in a 4-bytes long Abbreviated Option Option (AOO).
>                AOO MAY be present in DIO and DAO messages as follows:
> 
>                  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 2
>                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                  |  Option Type  | Option Length | Abbrev. opt.  | Last Mod Seq. |
>                  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
>                              Figure 3: Abbreviated Option Option Format
> 
>                Option fields:
> 
>                Option Type
>                   One byte indicating "Abbreviated Option", see Table 2 in
>                   Section 8.2
> 
>                Option Length
>                   MUST be set to 2 indicating Option data of 2 bytes
> 
>                Abbreviated Option
>                   The Option Type of the option being abbreviated
> 
>                Last Modification Sequence
>                   The last modified RCSS when carried in DIO or the last modified
>                   DAOSequence when carried in DAO
> 
>                When a node receives a DAO-ACK for a given DAO sequence, then if the
>                next DAO has the unchanged options, the node MAY reuse the
> DAOsequence
>                and elide all options with AOO. Abbreviated Option SHOULD be ignored.
>                The Last Modification Sequence is the last DAOsequence. The next DAO
>                MAY also unset ‘K’ flag to not expect a DAO-ACK, if node can assume
>                the risk that the DAO is lost and the state times out at the DAO
>                receiver. It is RECOMMENDED in non-storing mode because DAO always
> has
>                the same content.
> 
> 
>             Best regards,
>             Li
> 
>             On 2019/10/22, 19:27, "Roll on behalf of Li Zhao (liz3)" <roll-
> bounces@ietf.org on behalf of liz3@cisco.com> wrote:
> 
>                 Hello Pascal,
> 
>                 Agree with you.
>                 We can use AOO with last Modification DAO sequence to elide all
> options in DAO. In this case, we can ignore the Abbreviated Option field or set it
> to 0xFF. Which do you prefer?
> 
>                 For the DAO lost case, even in normal DAO case, node has the risk of
> lost DAO message. Node should set 'K' flag according to different network
> environment.
>                 It should also work in DAO-AOO case. Admin can balance the risk of lost
> DAO message and 4-bytes DAO-ACK load.
> 
> 
>                 Best regards,
>                 Li
> 
>                 On 2019/10/22, 16:53, "Roll on behalf of Pascal Thubert (pthubert)"
> <roll-bounces@ietf.org on behalf of pthubert@cisco.com> wrote:
> 
>                     Hello Again Li:
> 
>                     I looked at it and an simple step could be that when a node receives a
> DAO-ACK for a given DAO sequence, then if the next DAO has the same content
> the node may reuse the DAO sequence and elide the options. It may also decide
> not refrain from asking an ack, at the risk that the DAO is lost and the state times
> out at the DAO receiver.
> 
>                     All the best;
> 
>                     Pascal
> 
>                     -----Original Message-----
>                     From: Roll <roll-bounces@ietf.org> On Behalf Of Pascal Thubert
> (pthubert)
>                     Sent: mardi 22 octobre 2019 07:58
>                     To: Routing Over Low power and Lossy networks <roll@ietf.org>
>                     Subject: Re: [Roll] FW: New Version Notification for draft-thubert-
> roll-eliding-dio-information-01.txt
> 
>                     Hello Li
> 
>                     Would be great!
> 
>                     The xml is available on github under roll-wg.
>                     My expectation is that the source of the non storing DAO increases a
> sequence nb when there is a change and abbreviates it when there is none.
> 
>                     You need to think of what happens when the updated DAO is lost, eg
> MUST an ack or something and only abbreviate after a positive DAO ACK...
> 
>                     Regards,
> 
>                     Pascal
> 
>                     > Le 22 oct. 2019 à 04:29, Li Zhao (liz3) <liz3@cisco.com> a écrit :
>                     >
>                     > Hello Pascal,
>                     >
>                     > It looks good if router always need these options. And if a node
> wants to act as a leaf, it can only request R/D/P.
>                     >
>                     > I'm interested and it's my pleasure to add some sections for AOO-
> DAO. I'll send it to you later.
>                     >
>                     >
>                     > Best regards,
>                     > Li
>                     >
>                     > On 2019/10/21, 17:58, "Roll on behalf of Pascal Thubert
> (pthubert)" <roll-bounces@ietf.org on behalf of pthubert@cisco.com> wrote:
>                     >
>                     >    Hello Li (and all, please read on as there are additional things we
> could be doing with the draft listed below)
>                     >
>                     >    Let's see below
>                     >
>                     >    [Li] Do you mean that child should know ALL option type it needs
> before select the parent? E.g. one child need R/D/P/M/O to join network but
> another child only need R/D/P.
>                     >    So how does child know this info? Is it pre-defined in child?
>                     >
>                     >    <Pascal> The draft assumes that all R/D/P/M/O are always present
> and always needed. This seems to be the general case. We can make it so that
> one option would not be present by indicating in the DIO if you think that case is
> relevant. Please let me know.
>                     >
>                     >    But how will a child know that it does not need an option that is
> present? Maybe there is something in there that is mandatory to know, e.g., to
> act as a router. We could say that a node that does not pull all the options can
> only act as a leaf. Is that what you have in mind?
>                     >
>                     >
>                     >
>                     >        2. Is AOO necessary? If DIO can fragment options and don't
> always send all options, can we use DIO without options to indicate the AOO?
>                     >            The shortest DIO Base Object without DODAGID is only 8
> bytes.
>                     >
>                     >     <Pascal> AOO is RECOMMENDED to elide the option. A DIO an
> option elided (no option, no abbreviation) and an unchanged RCSS is perfectly
> OK. But if an option is elided AND the RCSS is incremented then after a
> reasonable time-out the children will pull the options to check if they changed
> and the parent will need to send either the AOO or the option in full or both in
> which case the RCSS of the AOO wins. It is always possible to place the option in
> full without a AOO but if it is done with an increased RCSS in the DIO that will
> mechanically increase the "RCSS of the option" as seen by the children and will
> cause the whole subdag to pull the option to no avail.
>                     >
>                     >     [Li] Agree, AOO is better than DIO with no option. It’s a nice
> abbreviated mechanism for RPL Control Message.
>                     >           Can we consider to extend AOO for DAO? Maybe put AOO in a
> new Control Message Options, then DIO/DAO can both leverage it.
>                     >           In some case, child will send large DAO packet to parent
> periodically. E.g. 1. child notifies its capability to parent .2 child has several RPL
> Target or Transit Information (storing mode?).
>                     >
>                     >    <Pascal> Yes we could. Say that the content of a non-storing DAO
> is fully stable, it could be all replaced by a sequence. Would you be interested in
> adding that?
>                     >
>                     >    If we have to abbreviate elements therein, per target, then we still
> need to indicate the target so we'll save little, and a different technique like
> indexing the targets with a BIER bit, would be more efficient.
>                     >
>                     >
>                     >    Many thanks again and again Li, for your excellent comments.
>                     >
>                     >    Pascal
>                     >    _______________________________________________
>                     >    Roll mailing list
>                     >    Roll@ietf.org
>                     >    https://www.ietf.org/mailman/listinfo/roll
>                     >
>                     >
>                     > _______________________________________________
>                     > Roll mailing list
>                     > Roll@ietf.org
>                     > https://www.ietf.org/mailman/listinfo/roll
>                     _______________________________________________
>                     Roll mailing list
>                     Roll@ietf.org
>                     https://www.ietf.org/mailman/listinfo/roll
>                     _______________________________________________
>                     Roll mailing list
>                     Roll@ietf.org
>                     https://www.ietf.org/mailman/listinfo/roll
> 
> 
>                 _______________________________________________
>                 Roll mailing list
>                 Roll@ietf.org
>                 https://www.ietf.org/mailman/listinfo/roll
> 
> 
>             _______________________________________________
>             Roll mailing list
>             Roll@ietf.org
>             https://www.ietf.org/mailman/listinfo/roll
>             _______________________________________________
>             Roll mailing list
>             Roll@ietf.org
>             https://www.ietf.org/mailman/listinfo/roll
> 
> 
>         _______________________________________________
>         Roll mailing list
>         Roll@ietf.org
>         https://www.ietf.org/mailman/listinfo/roll
>         _______________________________________________
>         Roll mailing list
>         Roll@ietf.org
>         https://www.ietf.org/mailman/listinfo/roll
> 
> 
>     _______________________________________________
>     Roll mailing list
>     Roll@ietf.org
>     https://www.ietf.org/mailman/listinfo/roll
> 
> 
> _______________________________________________
> Roll mailing list
> Roll@ietf.org
> https://www.ietf.org/mailman/listinfo/roll