Re: [Roll] DIS for given parent in draft-thubert-roll-eliding-dio-information

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Thu, 21 November 2019 02:47 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 1CD9012018B for <roll@ietfa.amsl.com>; Wed, 20 Nov 2019 18:47:43 -0800 (PST)
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=QRD3Ytwb; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=a5Tv9TCY
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 136ApKZGRMuJ for <roll@ietfa.amsl.com>; Wed, 20 Nov 2019 18:47:40 -0800 (PST)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84684120046 for <roll@ietf.org>; Wed, 20 Nov 2019 18:47:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14546; q=dns/txt; s=iport; t=1574304460; x=1575514060; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=cIqrh6HLUENRLiTm+7qKRfFWZCMXvFuvYqvS65mRkYI=; b=QRD3Ytwb+OstpG6buwoJuzNBe9w1rAxuuV/K92eUITJX8f/0fRv6W/eB VJ6IgQ1V8u4/pHjYcuz3n4cUDOdicSYE26rDqFqWVQXI+ePkmRcjjp0Lv La3RJP+7fkDnBwjFtn10a+Slwrpvf7HWnSyJTf+SSUWVOKv6ZYpTRE5as w=;
IronPort-PHdr: =?us-ascii?q?9a23=3A3gI/9h8dzdzvBP9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+8ZR7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfk0jgZdYBUER?= =?us-ascii?q?oMiMEYhQslVdaZCVDxIeT2Ryc7B89FElRi+iLzPA=3D=3D?=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CXAgA2+tVd/5RdJa1bChsBAQEBAQE?= =?us-ascii?q?BBQEBAREBAQMDAQEBgW0DAQEBCwGBSiQFJwVsWCAECyoKhCCDRgOKa06CEIl?= =?us-ascii?q?YjiiBQoEQA1QJAQEBDAEBGAsKAgEBgSuDFQIXghAkNwYOAgMNAQEEAQEBAgE?= =?us-ascii?q?FBG2FNwyFUQEBAQECAQEBEBERDAEBLAwLBAIBCBEEAQEBAgImAgICHwYLFQg?= =?us-ascii?q?IAgQTCBqDAYJGAw4fAQECDKNDAoE4iGB1gTKCfgEBBYUGDQuCFwMGgQ4oAYU?= =?us-ascii?q?ahnsYgUA/gVdRgU0uPoIbRwEBgTYPBQMWFRWCZDKCLI0IUYI8iAeVVUEKgiu?= =?us-ascii?q?IaohNhDOCPodpj22ZFI9AAgQCBAUCDgEBBYFoI4FYcBU7gmxQERSGRoEnAQm?= =?us-ascii?q?CQoUUhT90gSiNTgEDIoELAYEOAQE?=
X-IronPort-AV: E=Sophos;i="5.69,224,1571702400"; d="scan'208";a="654903220"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Nov 2019 02:47:39 +0000
Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id xAL2ldDe008037 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for <roll@ietf.org>; Thu, 21 Nov 2019 02:47:39 GMT
Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 20 Nov 2019 20:47:38 -0600
Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 20 Nov 2019 21:47:37 -0500
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 20 Nov 2019 20:47:37 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QCDqo+/NEA/hK+V2czONcpbiwUqcIYj3czHdPgUIOgbe+0z4PfxmACI61GIKh+6szNsUNDmbQF2z9S/H7UlsyqLTu+p/P/tLcK3i7R6Za9V4uHTr0Wqw9yZ2aMYfO2W3oZ/kSs+IilaOPvp+jr5y+wkrYMRsbr6xeJOdUq2wDTSAwD0/7byxGqepF9UrlJ6vz1UiX6uok3BatjIsxD26y1CwE0beNtB4fcA6l2F4zZMTTnHXpWByuGed4+EnuW51KYKpR7V5ADtZquQDArByhn5w56/eThee9K/QYar0UGSODgUsJkpi9i2wq/BvxHKWkVK8tKNqNCLtEIwZ+Eu21g==
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=cIqrh6HLUENRLiTm+7qKRfFWZCMXvFuvYqvS65mRkYI=; b=nFQEzX9CRIHaJDTM1InGd7ffI3klgCT+s/wF0Lct7ukCxRtMSLDsCUhwuVVoGx3TAN29jqS33jYiiKRjD6E+mm47XQvwPARi13XxSgC1AcGwL9ZR4A1V2MBwfYdulBVJUz9lifBDCRLoGmAgUhBVQvzb9MFlNVEocdvaD7TcMrqokF7ycrkpivjsuokfuvbHXlrgHxn8nkSqjOom6i8Qlh13FGhnvIQP63RSLQpE3iwTNx/DDsS0CQgTXo2HgGG5hGyrl4DmvFVDJsYkAiZzrlyVb86yhSsgVqmeVkvFE/3gz1RzriplXzhlvlUyO6eCbbV0KbiprR7eSNdqqQdF7Q==
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=cIqrh6HLUENRLiTm+7qKRfFWZCMXvFuvYqvS65mRkYI=; b=a5Tv9TCYnSef4uqiNvwmUghmD3rz8g9PFQwjalCACW90NC8qRGHxaTOqI7aCISpt5W0UoqL5TsNWF8q9LqGnkdWDQ9CxMsMWPme0JtYxDFpMV864L5w7kyiHtJiGZDtRxVbl4kUanC/6RI7eprXyQw+5UevGs6Cteleej+RSs/M=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3664.namprd11.prod.outlook.com (20.178.252.76) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2451.29; Thu, 21 Nov 2019 02:47:35 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::3037:66f1:dc79:b564]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::3037:66f1:dc79:b564%7]) with mapi id 15.20.2451.031; Thu, 21 Nov 2019 02:47:35 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Thread-Topic: [Roll] DIS for given parent in draft-thubert-roll-eliding-dio-information
Thread-Index: AQHVnpr36jrTS5isFE26D+k2w62PDKeSSFMAgAGmcAD//3+bgIAB6TeA//+K9wCAAACfQA==
Date: Thu, 21 Nov 2019 02:47:20 +0000
Deferred-Delivery: Thu, 21 Nov 2019 02:46:49 +0000
Message-ID: <MN2PR11MB3565CF28E0700C4F66C11070D84E0@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <B1178AE9-ACF1-4B20-AE9E-8F6DC888F3FA@cisco.com> <CAO0Djp0kvHD83YeaGPhVeho1AmxxKfY=F4Cnh-QD+f7nzzPe3g@mail.gmail.com> <D8BE9F9F-A6A7-4454-8696-63EF42BE9E14@cisco.com> <CAO0Djp1G1btbxUO3Po7hi2EMz9-JO1bJ2NLn2o6S68Xh8P6otA@mail.gmail.com> <2D1D3600-D779-448B-9DCD-919C7E519362@cisco.com> <CAO0Djp0Jcoik1+JByJVxghg+_gaFVt++d3-dxTp+PWgR9UnV-A@mail.gmail.com>
In-Reply-To: <CAO0Djp0Jcoik1+JByJVxghg+_gaFVt++d3-dxTp+PWgR9UnV-A@mail.gmail.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: [101.100.166.67]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: c44ac6c6-4acb-41c7-daf1-08d76e2d2a50
x-ms-traffictypediagnostic: MN2PR11MB3664:
x-ms-exchange-purlcount: 1
x-microsoft-antispam-prvs: <MN2PR11MB36643EDF4B4FFC94550B2E69D84E0@MN2PR11MB3664.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0228DDDDD7
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(366004)(136003)(346002)(396003)(39860400002)(13464003)(199004)(189003)(53754006)(5660300002)(486006)(2906002)(71200400001)(305945005)(446003)(7696005)(55016002)(76176011)(71190400001)(6306002)(229853002)(53546011)(6506007)(9686003)(14444005)(5024004)(74316002)(26005)(102836004)(14454004)(81166006)(81156014)(25786009)(66946007)(478600001)(64756008)(66556008)(66476007)(66446008)(966005)(52536014)(66066001)(8936002)(6916009)(76116006)(186003)(476003)(8676002)(256004)(6436002)(7736002)(11346002)(3846002)(6116002)(6666004)(86362001)(561944003)(99286004)(316002)(33656002)(6246003); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3664; 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: 7n8QgntLO2SCbLhg4WF5pvHmmdOuLf8HcTd2bfIoiVrZ/G/gWcqjRBF8a41Asbgc3NC9m9jeOnqTLB1Xrn2uz5DFoZGvPtVQgvGTRDb2KF+vwkeMXzF84t9hP/N7D+6Pw8J3tBMzG4gUIg3A3OpOsqMYNDLgCaqZyfMxq213qVcpPRWi3Sa0YxfktyvWl5bachIxxvKtjtI/WfXYwFAAsCVTSHeUhqAleVyb4gjiJc9Nym05PfRhVsXfP9tEiPdK4D4O+HSn4ERnui8iDnChFP7Yl4v9v8o4319+nXcorRAcxW1JUswBBQfqjBMHQ3EYivsDVYoCcoGz3ePrypyYYCf2S+FeW0MUpgjzEQMqRY8lLEc2xwK1GU95/RmY+K2+Do8JWF7hY1d+Jq4GkFsdjhdl804Xb+2IfF5ii7n95NRuDzsJgc2AaM9PRVNvSpY2WgmXVaPlTT0LaM7IhOiyrzLDly5hrd/sWxeHZLtcveg=
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: c44ac6c6-4acb-41c7-daf1-08d76e2d2a50
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Nov 2019 02:47:35.6541 (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: jmVuvsh7X23YFVW9nQZFK09rFvLQxBjJccf13P79qMj41fbok9hlJgy0xnYUizbCU2A2P4YeCzB2IHSNRTvs8A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3664
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.20, xch-rcd-010.cisco.com
X-Outbound-Node: rcdn-core-12.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/5OViYfO9hOklJsXrfiBeIptub4c>
Subject: Re: [Roll] DIS for given parent in draft-thubert-roll-eliding-dio-information
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, 21 Nov 2019 02:47:43 -0000

Hello Rahul

This proposal is an alternate to the proposal of using a multicast address that is derived from the parent address that we discussed at the meeting. Basically after a power outage and with the premise that the nodes can store the RPL state before the outage, the network can reform more quickly with mostly the shape it had before.

What really hurts is the tempest of DIS messages. It interferes with the reformation of the network. Those should be cancelled out with a trickle mechanism. If a node hears DIS messages around, it should refrain from sending it own. RPL does not discuss that aspect. If the parent is not awaken or is gone, the trickle mechanism will exponentially back off the retries till the point where the child reparents anyway.

In this case we want the DIS to be multicast and the other (candidate) children to process it. We should define the trickle Imin of DIS to be longer than that of DIO, so when all nodes reboot there's a chance that DIOs are heard before DIS are.

One desired outcome in that case is that the DIO is responded multicast and arrives soon, which is the case with a multicast DIS. So the particular case does not need a change in the DIS bits that we are still considering for other reasons.

On top of trickling the DIS, the ask here is to specify the specific parent that answers. But we do not want to send a unicast packet to the parent because the other candidate children would miss the DIS. So Li's proposal here is to add that as a filter in the SIO. 

Comparing the 2 proposals:
- the SIO enables to ask from more than one parent by placing more than one address. Also it is simpler if MLD is not implemented
- the multicast address enables the parents to list their children using MLD.

We also need to clarify what resetting trickle mean. If I goes back to Imin, you need to restart the timer as well because it would timeout out of bounds. But if it is already Imin, the timer as it is running is already compatible so it should not be restarted. This way the DIO flies quickly.

If a node does not have persistent storage then it will not specify a parent. The overall trickling stuff remains critically important. The difference is the consistency check, all DIS are consistent with one another.

Does that clarify?

Pascal


> -----Original Message-----
> From: Roll <roll-bounces@ietf.org> On Behalf Of Rahul Jadhav
> Sent: jeudi 21 novembre 2019 10:04
> To: Routing Over Low power and Lossy networks <roll@ietf.org>
> Subject: Re: [Roll] DIS for given parent in draft-thubert-roll-eliding-dio-
> information
> 
> Please find my comments below.
> 
> On Thu, 21 Nov 2019 at 09:03, Li Zhao (liz3) <liz3@cisco.com> wrote:
> >
> > Hello Rahul,
> >
> > Node can store preferred parent's info when outage.
> 
> [RJ] Storing parent info in persistent storage seems costly. But let's go with
> this premise for this discussion.
> 
> > But after reboot, it still need DIO from this parent to confirm whether this
> parent is alive. Because parent may be outage too.
> 
> [RJ] In case of outage if the child node sends multicast DIS with the parent
> address, the parent node itself may not have attached to the network and may
> be still trying. So the DIS may have to be repeated till the point where parent
> node is attached as well. All the other nodes would be trying to do the same
> with their DIS as well.
> 
> > Reset trickle timer can let parent inform all children and accelerate the
> network recovery. Otherwise, all nodes need to run unicast DIS request and
> unicast DIO response. It wastes too much of time.
> 
> [RJ] If we let the trickle time reset then we wouldn't be solving the problem.
> Let me give an example:
> a. Assume 20 nodes using parent P
> b. there's an outage
> c. all 20 nodes sending DIS(with P address) and resetting P's trickle timer.
> P keeps on resetting the trickle because of high child density and never is able
> to dole out DIO.
> 
> >
> > Does it make sense?
> 
> [RJ] It is good to know the options assuming that the preferred parent is
> stored in persistent storage. But making design choices based on this (use of
> storage) assumption may not be the right way. Note that there could be
> multiple preferred parents and the parent info is much more dynamic and
> thus may require frequent updates to persistent storage.
> 
> >
> > Best regards,
> > Li
> >
> >
> > On 2019/11/20, 11:52, "Roll on behalf of Rahul Jadhav" <roll-
> bounces@ietf.org on behalf of rahul.ietf@gmail.com> wrote:
> >
> >     Thanks Li for elaborating.
> >
> >     Regarding the warm boot use-case you mentioned, the nodes certainly do
> >     not know whether they have individually rebooted or rebooted because
> >     of mass-outage.
> >     What I don't get is, if the child node already knows who the parent is
> >     why would it want to reset its Trickle timer?
> >
> >     On Wed, 20 Nov 2019 at 11:31, Li Zhao (liz3) <liz3@cisco.com> wrote:
> >     >
> >     > Hello Rahul,
> >     >
> >     > This is about " we need other nodes sending DIS to backoff on hearing
> other node's DIS ".
> >     > The use case is for warm boot case when hundreds of nodes power
> outage at the same time.
> >     > 1. Child nodes send DIS to inform given parent to reset its trickle.
> (unicast or multicast DIS both work)
> >     > 2. Child nodes suppress or backoff sibling nodes' DIS. Only multicast DIS
> works.
> >     >     And we need enhance Solicited Information option to identify this
> kind of DIS.
> >     >
> >     >
> >     > Best regards,
> >     > Li
> >     >
> >     > On 2019/11/19, 18:20, "Roll on behalf of Rahul Jadhav" <roll-
> bounces@ietf.org on behalf of rahul.ietf@gmail.com> wrote:
> >     >
> >     >     Hi Li,
> >     >
> >     >     What is the use-case where the child node needs to inform the parent
> >     >     to reset its trickle unilaterally when it already knows the parent's
> >     >     address?
> >     >     Please find my comments below.
> >     >
> >     >     Best,
> >     >     Rahul
> >     >
> >     >     On Tue, 19 Nov 2019 at 13:34, Li Zhao (liz3) <liz3@cisco.com> wrote:
> >     >     >
> >     >     > Hello all,
> >     >     >
> >     >     >
> >     >     >
> >     >     > As we discussed today, there is a requirement that node sends out
> multicast DIS to only reset given parent’s Trickle.
> >     >
> >     >     [RJ] We discussed today that we need other nodes sending DIS to
> >     >     backoff on hearing other node's DIS. We also discussed that we need
> >     >     parent node to not keep on resetting the trickle timer all the time on
> >     >     hearing DIS.
> >     >     I am not sure we discussed about sending a multicast DIS to reset a
> >     >     given parent's Trickle. Or may be I didn't get it correctly. Can you
> >     >     please elaborate? Thanks
> >     >
> >     >     >
> >     >     >
> >     >     >
> >     >     > Can we enhance Solicited Information option to add a flag to
> identify given parent’s address as following?
> >     >     >
> >     >     >
> >     >     >
> >     >     >         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
> >     >     >
> >     >     >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +
> >     >     >
> >     >     >        |   Type = 0x07 |Opt Length = 19| RPLInstanceID |V|I|D|P|
> Flags |
> >     >     >
> >     >     >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +
> >     >     >
> >     >     >        |                                                               |
> >     >     >
> >     >     >        +                                                               +
> >     >     >
> >     >     >        |                                                               |
> >     >     >
> >     >     >        +                            DODAGID                            +
> >     >     >
> >     >     >        |                                                               |
> >     >     >
> >     >     >        +                                                               +
> >     >     >
> >     >     >        |                                                               |
> >     >     >
> >     >     >        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
> +
> >     >     >
> >     >     >        |Version Number | Parent Address     (16bytes)                  |
> >     >     >
> >     >     >        +-+-+-+-+-+-+-+-+                                               +
> >     >     >
> >     >     >        +                                                               +
> >     >     >
> >     >     >        |                                                               |
> >     >     >
> >     >     >        +                                                               +
> >     >     >
> >     >     >        |                -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >     >     >
> >     >     >        +-+-+-+-+-+-+-+-+
> >     >     >
> >     >     >
> >     >     >
> >     >     > P flag: One Bit, indicates DIS request response from given parent
> >     >     >
> >     >     >
> >     >     >
> >     >     >
> >     >     >
> >     >     > Best regards,
> >     >     >
> >     >     > Li
> >     >     >
> >     >     > _______________________________________________
> >     >     > 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