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: 9a23:k86HLB8YVK4Ea/9uRHGN82YQeigqvan1NQcJ650hzqhDabmn44+8ZR7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfk0jgZdYBUERoMiMEYhQslVdaZCVDxIeT2Ryc7B89FElRi+iLzPA==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AKAAA09bJd/4wNJK1lGgEBAQEBAQEBAQMBAQEBEQEBAQICAQEBAYFnBQEBAQELAYFKJCwFbFcgBAsqg2hAg0cDhFqGDk6CEH+XBoEugSQDVAkBAQEMAQEYCwoCAQGEQAIXgygkNAkOAgMJAQEEAQEBAgEFBG2FNwyFUAEBAQEDAQEKAgQREQwBASMCBwkDCwQCAQYCEQQBAQECAiYCAgIlCxUICAIEEwgagwGCRgMuAQIMllOQYgKBOIhhdYEygn4BAQWFChiCFwMGgQ4oAYUVhnkYgUA/gRFGgU5JNT6CYgEBgUUeBRAhAoJWMoIsj3idcQqCJIcQjjiCPIdUhC+GX4Q1lmaRIgIEAgQFAg4BAQWBUjmBWHAVO4JsUBAUgwYJGhWDO4UUhT90gSmPBgEB
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
- [Roll] FW: New Version Notification for draft-thu… Pascal Thubert (pthubert)
- Re: [Roll] FW: New Version Notification for draft… Li Zhao (liz3)
- Re: [Roll] FW: New Version Notification for draft… Pascal Thubert (pthubert)
- Re: [Roll] FW: New Version Notification for draft… Li Zhao (liz3)
- Re: [Roll] FW: New Version Notification for draft… Pascal Thubert (pthubert)
- Re: [Roll] FW: New Version Notification for draft… Li Zhao (liz3)
- Re: [Roll] FW: New Version Notification for draft… Pascal Thubert (pthubert)
- Re: [Roll] FW: New Version Notification for draft… Pascal Thubert (pthubert)
- Re: [Roll] FW: New Version Notification for draft… Li Zhao (liz3)
- Re: [Roll] FW: New Version Notification for draft… Li Zhao (liz3)
- Re: [Roll] FW: New Version Notification for draft… Pascal Thubert (pthubert)
- Re: [Roll] FW: New Version Notification for draft… Pascal Thubert (pthubert)
- Re: [Roll] FW: New Version Notification for draft… Li Zhao (liz3)
- Re: [Roll] FW: New Version Notification for draft… Li Zhao (liz3)
- Re: [Roll] FW: New Version Notification for draft… Rahul Jadhav
- Re: [Roll] FW: New Version Notification for draft… Li Zhao (liz3)
- Re: [Roll] FW: New Version Notification for draft… Pascal Thubert (pthubert)
- Re: [Roll] FW: New Version Notification for draft… Li Zhao (liz3)
- Re: [Roll] FW: New Version Notification for draft… Li Zhao (liz3)
- Re: [Roll] FW: New Version Notification for draft… Pascal Thubert (pthubert)
- Re: [Roll] FW: New Version Notification for draft… Li Zhao (liz3)