Re: [Roll] FW: New Version Notification for draft-thubert-roll-eliding-dio-information-01.txt
"Li Zhao (liz3)" <liz3@cisco.com> Sat, 26 October 2019 00:54 UTC
Return-Path: <liz3@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 39E1212004A for <roll@ietfa.amsl.com>; Fri, 25 Oct 2019 17:54:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 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, 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=L3YxEogv; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Pi7JNOf9
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 KoQr2B8R0te9 for <roll@ietfa.amsl.com>; Fri, 25 Oct 2019 17:54:47 -0700 (PDT)
Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9CDA8120026 for <roll@ietf.org>; Fri, 25 Oct 2019 17:54:47 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22970; q=dns/txt; s=iport; t=1572051287; x=1573260887; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=xarJOgDVFDtTtYdFLChhA8Oig0lNIDixkdhQ2dS4U9g=; b=L3YxEogvzCqfTBXyUIfVQJqYaI/8mAccFKl4USFazgOZC7cjPY6hJEuF AOX+ySVfRzX9SRsjItzEB6sTJ9juNh7ZRt0QriX9GmQsaRl8tOOknc4ns bJY7NdWZhOwS+ELj0JmUNoE16k8YTKNzENbxeBm8lIwOJZDjsg7tc4LTP Q=;
IronPort-PHdr: 9a23:vDu10RM9du/Lc6w+Uqwl6mtXPHoupqn0MwgJ65Eul7NJdOG58o//OFDEuKg/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDOIdJSwdDjMwXmwI6B8vQDUzpd9bhbjcxG4JJU1o2t3w=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ANAAABmbNd/5NdJa1lGgEBAQEBAQEBAQMBAQEBEQEBAQICAQEBAYFnBQEBAQELAYFKJCwFbFcgBAsqCoNeQINHA4RahhNOghB/lmuBLoEkA1QJAQEBDAEBGAsKAgEBhEACF4MoJDQJDgIDCQEBBAEBAQIBBQRthTcMhVABAQEBAwEBCgIEEREMAQEjAgcJAwsEAgEGAhEEAQEBAgImAgICJQsVCAgCBBMigwABgkYDLgEOliSQYgKBOIhhdYEygn4BAQWFCxiCFwMGgQ4oAYUVhnmCF4ERJx+BTkk1PoJiAQGBRSMQIQKCVjKCLIE9AY46nXEGBIIkhxCOHRuCPIdUhC+GX4Q1lmaRIgIEAgQFAg4BAQWBUjmBWHBQKgFzgU5QEBSDBgkaFYM7hRSFP3SBKY1QAYEpAQE
X-IronPort-AV: E=Sophos;i="5.68,230,1569283200"; d="scan'208";a="357297986"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Oct 2019 00:54:45 +0000
Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id x9Q0sjU1008463 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for <roll@ietf.org>; Sat, 26 Oct 2019 00:54:45 GMT
Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 25 Oct 2019 19:54:44 -0500
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 25 Oct 2019 20:54:42 -0400
Received: from NAM05-DM3-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 25 Oct 2019 19:54:42 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NINvjud5J6oA5/gPyzAujAXZv7xaGeUAMnTXRUzYTjegk0wFnDyVJGIHOWczdxzmF0UjBpVL+xPesDS1Q8Z7/6ULswTltik+c9XgGzIh217mK5+NscwGnbi9mGXy5UrUVE2DU4PQ31GBNgykox90LKRX2m1J4zNlcCQY/Yexphu0lRXf7kCQmXfbhtlWktw4ZYodXY2RN17auMKRGdgZqHWd873FuJIM6YqhEoWqLoKp1nGGv6wnFG05AWE/opmQIATgu8Cf2gFg/sveJdzUrxlKmgSq4U3+R6soMky96pMJmOEUUuGZyJWodpCpAHU4ZlQPy+OxbSAx8/rO5KqiKA==
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=xarJOgDVFDtTtYdFLChhA8Oig0lNIDixkdhQ2dS4U9g=; b=Lx/O6tn0vWVZ56RxC/i6dmGKOlmsIPONrqvmKeGu/1RloQzesQQzNQO4gcwuPj87rRQV8j4DTzeHRgPfv40KRu5MvjJecdGjog2X1TlO3mQTMnNvWNZWkN7/AGp6fxGm0Rf+Iv4ogJyZ3tCSCRa4nuowp6GxrbE2WDrWp2jsdv5N3mH6Fq34Ww9gvEpJA+iilNpdyNkUuTjkiF90kq8GpNFbZ4nBQt6UPiBTkdd5uoxh2fVF16fj637d7VGzuUvy1/y26XHRXkStPG4ahub0BGdXbQC53pQPj0jq10eR/hwIy133wGBqEkVQIAbVLEAZHZvz6pj4Y2283ItFUnv2xA==
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=xarJOgDVFDtTtYdFLChhA8Oig0lNIDixkdhQ2dS4U9g=; b=Pi7JNOf9BjXP3sfxMEKb04QnwJw5rw6yqjTiXZCj9RtNBbbIyKA8n0WN7oE9y/XfLm7EVy5JnWtk4DlAXrBBw9cW6YhZy3Sg3+Wuk4h3G7uUzJoya1bJfT4tfJtz0Py34FHqa3sOuORaCiwavbytDmZQnyXL+LJDCMbclyT11vI=
Received: from MWHPR11MB1359.namprd11.prod.outlook.com (10.169.232.22) by MWHPR11MB2030.namprd11.prod.outlook.com (10.169.236.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2387.23; Sat, 26 Oct 2019 00:54:41 +0000
Received: from MWHPR11MB1359.namprd11.prod.outlook.com ([fe80::f896:bd4a:3e62:4819]) by MWHPR11MB1359.namprd11.prod.outlook.com ([fe80::f896:bd4a:3e62:4819%6]) with mapi id 15.20.2387.023; Sat, 26 Oct 2019 00:54:41 +0000
From: "Li Zhao (liz3)" <liz3@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//4nTAAAmr9mAAAOtcVAAMWVKAAAHiUCAAC7AkZAAKTQiAA==
Date: Sat, 26 Oct 2019 00:54:41 +0000
Message-ID: <BCD0EB2A-464A-4CBB-91D7-402F1BD1D74D@cisco.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> <MN2PR11MB356574E686390B57684EC873D8650@MN2PR11MB3565.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB356574E686390B57684EC873D8650@MN2PR11MB3565.namprd11.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=liz3@cisco.com;
x-originating-ip: [64.104.125.231]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 0525dc19-f0fe-4cbd-868c-08d759af15b9
x-ms-traffictypediagnostic: MWHPR11MB2030:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <MWHPR11MB20303D07805FCCBFFD0C0FBD8C640@MWHPR11MB2030.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0202D21D2F
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(376002)(366004)(136003)(396003)(39860400002)(43544003)(13464003)(199004)(189003)(66946007)(53546011)(76176011)(71200400001)(99286004)(186003)(26005)(102836004)(66446008)(30864003)(229853002)(64756008)(6486002)(5660300002)(91956017)(66574012)(6436002)(66476007)(66556008)(446003)(966005)(476003)(2616005)(486006)(478600001)(76116006)(6506007)(14454004)(6246003)(66066001)(25786009)(11346002)(6916009)(14444005)(3846002)(86362001)(256004)(316002)(6306002)(36756003)(305945005)(6512007)(7736002)(8936002)(81166006)(81156014)(8676002)(561944003)(2906002)(33656002)(71190400001)(15650500001)(6116002)(88722002); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR11MB2030; H:MWHPR11MB1359.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: 6UUGvGIVG1/458IWixH1AJXpuJrfDZ5WHh6PpXkf4iqvIRtQI32aDmEoXLcorn57Ekam83ruwxZJzE9GKwdcJ+Xp3+ZWWLoHtMp0dH1xWvo10zwyZkMxaYUyDDVIEbzF2M4l4STTdn/zHuTUmJBb8/qDUWtdQR0mN+oQsvD/L3cfzkIwk3f7bnW/YthPLBB6IvV4jztkozpFYITJSCuCb00sGQ7W1uBaXT73JJiclQQF+20XDcr9wx3raxZQWzLvyro8stIP5K6n1VATaWQltF+CoSPrNXToyBlHwIMwClrg+EI7ZETP3Q85E89dp29FmUBmxz6ddvldq05HlkKY4VIMOD68V9hr2WftxFq10LyAXalc8VEXhf8Jn04jLo9B1WhxSTSvXSvvxQLZo7Y1K1n67+lYmUlqlgZQEAngHiBpRxarXi239gRWkki+m+RNLw+aodpfufNVCdV+mw9isgG5h0y2o8pK0X9Zjf4Hefg=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <A1EFEAA64E593A499C225AEE38738A05@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 0525dc19-f0fe-4cbd-868c-08d759af15b9
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Oct 2019 00:54:41.2724 (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: 8uiYOU/b5dwI+DF8ZGQ+CgCLL2GXa0aoZHnVY43Y9QHq2GjpwevYrPny+UQqAnPe
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB2030
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.24, xch-aln-014.cisco.com
X-Outbound-Node: rcdn-core-11.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/63ycJNoCO7OjwsnJMku4nCpEfHU>
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: Sat, 26 Oct 2019 00:54:51 -0000
Agree. We can use MOPEX to indicate the capability. Hope that MOPEX can move on in 106. Best regards, Li On 2019/10/25, 21:18, "Roll on behalf of Pascal Thubert (pthubert)" <roll-bounces@ietf.org on behalf of pthubert@cisco.com> wrote: 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 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)