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

"Li Zhao (liz3)" <liz3@cisco.com> Thu, 24 October 2019 06:56 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 952D1120824 for <roll@ietfa.amsl.com>; Wed, 23 Oct 2019 23:56:21 -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=D8fmRAa1; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=tOtt2BpD
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 RhodHeAsjTsG for <roll@ietfa.amsl.com>; Wed, 23 Oct 2019 23:56:19 -0700 (PDT)
Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 005B012080D for <roll@ietf.org>; Wed, 23 Oct 2019 23:56:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19874; q=dns/txt; s=iport; t=1571900178; x=1573109778; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=gFlFbBUFPZBPOZOEKuF5udYolaGhMYDLDK+DNIaDPhU=; b=D8fmRAa1DnpNA+0AvTTr7F/Dc0DMiLaR3GOrP7p3xt3qSxVypfcbZbvc fTGVT2VSNu8Ts7qX/3QSYDL7ETywUN/uZNpc100A2yI8SJA/2WEIaqE03 pNN7i0p6RoLnVMTULxiFMHWB4sE7edgYPETiAgFh0ujeEphFWqiNd28w5 o=;
IronPort-PHdr: 9a23:TxyuwRWE07P4Or8NiXVl8mA0r4bV8LGuZFwc94YnhrRSc6+q45XlOgnF6O5wiEPSANiJ8OpK3uzRta2oGXcN55qMqjgjSNRNTFdEwd4TgxRmBceEDUPhK/u/ay0oR+xJVURu+DewNk0GUMs=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AMAAA+SrFd/5tdJa1lGgEBAQEBAQEBAQMBAQEBEQEBAQICAQEBAYFnBQEBAQELAYFKJCwFbFcgBAsqg2hAg0cDhFiGBE6BayV/lwSBLoEkA1QJAQEBDAEBGAsKAgEBhEACF4MeJDQJDgIDAQMCAwEBBAEBAQIBBQRthTcMhVABAQEBAgEBAQoCBBERDAEBIwIHCQMLBAIBBgIRBAEBAQICJgICAiULFQgIAgQTIoMAAYJGAw4gAQ6WPZBiAoE4iGF1gTKCfgEBBYUPGIIXAwaBDigBhRWGeYIXgREnDBOBTkk1PoJiAQGBRRwHECECglYygiyBPQGOOo5ujwEGBIIkhw+OGxuCO4dUhC+GX4Q1lmKRIwIEAgQFAg4BAQWBUjmBWHBQKgFzgU5QEBSDBgkaFYM7hRSFP3SBKY8FAQE
X-IronPort-AV: E=Sophos;i="5.68,223,1569283200"; d="scan'208";a="364011614"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Oct 2019 06:56:17 +0000
Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x9O6uHaw029334 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for <roll@ietf.org>; Thu, 24 Oct 2019 06:56:17 GMT
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 24 Oct 2019 01:56:17 -0500
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 24 Oct 2019 01:56:16 -0500
Received: from NAM01-SN1-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; Thu, 24 Oct 2019 01:56:16 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=KfKlCU1WeY3kysYFiJRrCHeOE+f9YTU2WD6NoQsdSxWWcDnfVQg9aI38+TLhqcEb30vzpIirWNMl4v2HR1QhQ2Sgk+S9FPcrpWL1ugOL2w6WPAG6/9w9DBr9BjbzpbLOoKftokF2NPOS0qO7O/hdgTuGjmeZ3I2zpfRAQl8P9ayQOH2bIeO84L5561W6ra7WEzLyK2BnryaK0CHnYg4fSPxJJDQVg9jgDo3KIYaXBzBjBzC81GR54VTOaeUj5BPDPPXH40qiTaoF1j2Uzm97c2/PiMj+yIRIkg0GP62if6TXOUtF97Go32M955vaUuY20JsNVZe1jhir/hVNDR7VpQ==
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=gFlFbBUFPZBPOZOEKuF5udYolaGhMYDLDK+DNIaDPhU=; b=cOUW1uk54D7VOVXKjZz2Ynao2nYk5Iayv3l49cKzi3BxXs4Vuey1CWONMTgnb2ILU6fysOQXOH9ZeUgbouiizcd2nf8FfjFp/6f22ybGlcvf6Dvg9dKRXRrpaRfsCG+91rlrzegXf/rxwSYlK+2b8TiDwW8t2iOaabikLPxmQRPWOCrAbF9VNkocyFgYRqQgbl4w49GlqubLczLl7hHtdiriYlOjZhji2yS12wZhPfMBvLvYg+lAtrIoTEelGo6CJ3HgDbaKmp7W1tFX2yOhzMjU7XvodrdFKtEimEZAfKHKi36WaaS2ej53dhWFrqKAzqaJ+eCj3glX3gPbdNk7iQ==
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=gFlFbBUFPZBPOZOEKuF5udYolaGhMYDLDK+DNIaDPhU=; b=tOtt2BpD0Bqg4I308AM64akqkKyOEhM+XLm+nZbpzmKPIMWbNb0zpBKQ4d8v9Kdy3i8QvYuVZ5YyjUKaATDeqJ6g3vBKwFznQ4kSxUI1VEskPbAnj+a/UK89GVWC9xgFNIn530cfnPbaSA3yyHYGHriBy1q5NPkK9lQZER+anKQ=
Received: from MWHPR11MB1359.namprd11.prod.outlook.com (10.169.232.22) by MWHPR11MB1600.namprd11.prod.outlook.com (10.172.53.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2367.24; Thu, 24 Oct 2019 06:56:15 +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; Thu, 24 Oct 2019 06:56:14 +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//4nTAAAmr9mAAAOtcVAAMWVKAAAHiUCA
Date: Thu, 24 Oct 2019 06:56:14 +0000
Message-ID: <8A56E85C-AF71-4BE9-8774-5A8D63BE45A4@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>
In-Reply-To: <B48E0219-051A-4C11-908C-EBEB0C3AED97@cisco.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: [2001:420:588c:1252:8109:e107:9747:4e8d]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 402f8903-e9a5-414d-1078-08d7584f4331
x-ms-traffictypediagnostic: MWHPR11MB1600:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <MWHPR11MB160062C0666352B1137A6D0C8C6A0@MWHPR11MB1600.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 0200DDA8BE
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(39860400002)(136003)(396003)(346002)(376002)(189003)(199004)(13464003)(43544003)(8936002)(76176011)(14454004)(446003)(486006)(6512007)(256004)(2616005)(478600001)(6436002)(8676002)(99286004)(6306002)(71200400001)(25786009)(476003)(6486002)(14444005)(11346002)(66574012)(5660300002)(46003)(6116002)(2906002)(229853002)(71190400001)(186003)(15650500001)(81156014)(81166006)(66556008)(86362001)(561944003)(305945005)(66446008)(64756008)(66476007)(66946007)(76116006)(91956017)(6916009)(53546011)(6506007)(33656002)(316002)(102836004)(7736002)(36756003)(6246003)(966005)(88722002); DIR:OUT; SFP:1101; SCL:1; SRVR:MWHPR11MB1600; H:MWHPR11MB1359.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A: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: UiF7EejmRK/rhYNajEQ39fZQL3Y/bZrWNesnWhnB9tTyS7+hU6/F0+gNt93BT9O6xecv+uQP5dVjfd5c0qFoUCXAkk1i3OoofHNuXrOfhdQ4EtU2VhzrpQGG4BzbF9wE30aVtGRPaOcfukRWs+nyHIBZDztXLH3B6ff3XbeaNO6CvUwU7S/6zIz7Q4McolhVWWZj2STG2StMYpgW/msfIEzzzcfYqV4gSmtEZ/CAn30DWwHvU16aA0tiRIBv2fLKXlum5wJlsWaYYcZvMQQWPu0+V3eqV0zwFCGFtjbhYWcdcfBjqWsYJnggP6pOkA0Wbbh4Ij9pk2CkRAXyVkIwTgUuOYqW8k7CEWPd+OkbhBHxM61y2lVVrAHjw5p/pyZZiuc2Mec459y2tDSqz2UyMwb9MVtDRmJmf/l+KACKP36DjofC2aJcnJ5X3obC3+cvO2b5yvxervfg0b8MMzcc8TFEGsQX1CzBg8+pvr6fe7k=
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <3534DD0534C4EE43BBC47075ECCFD550@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 402f8903-e9a5-414d-1078-08d7584f4331
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Oct 2019 06:56:14.6095 (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: mQwicGX1vsP6Xr+JWsCGRyDZ9728JYMTWzb0h2PGIgNqtbywT15VvCyzb193RQWZ
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1600
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.17, xch-rcd-007.cisco.com
X-Outbound-Node: rcdn-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/vM40oCi-7HGHaN9PhHoRfoEv8vI>
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: Thu, 24 Oct 2019 06:56:22 -0000

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