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