Re: [6tisch] MSF Shepherd review

"Pascal Thubert (pthubert)" <pthubert@cisco.com> Fri, 29 November 2019 23:31 UTC

Return-Path: <pthubert@cisco.com>
X-Original-To: 6tisch@ietfa.amsl.com
Delivered-To: 6tisch@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C489812008A for <6tisch@ietfa.amsl.com>; Fri, 29 Nov 2019 15:31:31 -0800 (PST)
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=VLRIxEFQ; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=YV5Sef9x
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 qD1pJcj0MNUa for <6tisch@ietfa.amsl.com>; Fri, 29 Nov 2019 15:31:30 -0800 (PST)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0580C120033 for <6tisch@ietf.org>; Fri, 29 Nov 2019 15:31:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4836; q=dns/txt; s=iport; t=1575070290; x=1576279890; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=eDfX0h/dv2XIU4RKBZoAM4uth2Alblip4UW4azxm2qA=; b=VLRIxEFQcQkwAsPjkePyJC7dGOIYTpH+pHERqXe20V/dDaxJ5cRnWPF6 tBgNaoFTvg/s9y5+felhO8lHrzMSXcbYOOa3si+3gW0ic+sRMDsQ/YtpX L74oudj8KSMs1y+MWDdo0kNZ7xicp+DoBQrUf1XOHvE/vsuydqEKMViSa E=;
IronPort-PHdr: 9a23:NPEzJhXYi4yLDVimqMeCbqDfoAPV8LGuZFwc94YnhrRSc6+q45XlOgnF6O5wiEPSA9yJ8OpK3uzRta2oGXcN55qMqjgjSNRNTFdE7KdehAk8GIiAAEz/IuTtankiAMRfXlJ/41mwMFNeH4D1YFiB6nA=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AqAADcqeFd/4sNJK1lGgEBAQEBAQEBAQMBAQEBEQEBAQICAQEBAYFtAgEBAQELAYFKUAVsWCAECyoKhCGDRgOKcoJfmASCUgNUCQEBAQwBARgLCgIBAYN7RQIXgXMkNwYOAgMNAQEEAQEBAgEFBG2FNwyFUgEBAQMBAQEQEREMAQElBwsBBAsCAQgYAgImAgICJQsVEAIEDgUbB4MAAYJGAw4gAQIBC6ckAoE4iGB1gTKCfgEBBYE1AYEUgjcYghcDBoEOKAGFGoZ7GoFBP4ERJyBRgXs+gmQBAYFjF4J5MoIsjSuCb54oCoIulVkbmiOoYQIEAgQFAg4BAQWBaCOBWHAVOyoBgkFQERSIVAwXg1CFFIU+AXSBKIwiAYEPAQE
X-IronPort-AV: E=Sophos;i="5.69,259,1571702400"; d="scan'208";a="373896310"
Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Nov 2019 23:31:28 +0000
Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id xATNVS64018765 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 29 Nov 2019 23:31:28 GMT
Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 29 Nov 2019 17:31:28 -0600
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 29 Nov 2019 17:31:27 -0600
Received: from NAM02-BL2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Fri, 29 Nov 2019 17:31:27 -0600
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=I2NqwZq8xlzM8M+tAalRQOd7MqalQngnUxVOMQgZKzhsPXYJLWIBfGvtUnDJJQJANEJalE6BFkSg0PkZypkcyOICgn+Ec6BGvB2waDp7upvTmeEof/XIAoQCAXiSJXK3ZH3hLWsJBhf1S+nczAip4JdaRDV+nvlJLTPMWybSzK/vmmzuPlqi5u8DBJbBVkVjHDX2+wbEbVPAoHcQgsO9mZnEZsYlj2jc2X5H3zIy6t1APQe0vpE9c6qtfjfVo+YUr2+nWacTnLViKwErqLhdEryvzueF2Bjz7o16oQ7I4Rtz1AmjHr3M18kqaQl7X376Zvg+L0+zGLsxOqwWPjuSsw==
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=eDfX0h/dv2XIU4RKBZoAM4uth2Alblip4UW4azxm2qA=; b=LPDDBqT/fqohagHo4ZWXLCfLJm7QDwgzRJ5bqkqN2XomcBbJ0XdgRMk6mZDtTzM7OlLpRAvjebEG4DyMA4AYKN3wKXA0j4k4Xt5S8OhL/IaLt4FjFaFTTHIH1RX9aM9bZRs6gr1UcfZ/v0B8Cq3+u+kUmId32gXF076RnAD1V2Xuk8VPBPNiiPX4pNE18zM/SxUB+XxpocV+ayVoZmIdpA+rwzPtY2T7PpEO/vSNUv/2iufeAcR5xtz4qartfOwtMoU68/jNvX2hK718Bwj5OHptYLAKO6L1osHyfIWY6OI79bbfrv+CrnqnG1mZL6XXBXP36alS/E8LXrnClHLk1w==
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=eDfX0h/dv2XIU4RKBZoAM4uth2Alblip4UW4azxm2qA=; b=YV5Sef9xtc+a3k/Xb2Yy2XPWYcrAfVorrtkCih/nRptj4vSbtg+Br6SC1zfjT5b2KEUfyl+xfdY1QBNfCAVAHu/BH5PsYUnzOEto2/6eq71pN2rX4F9JPbfMfmwF79qarxm6jrfVUMvSEJL/fRyCQFhrbmzWBUcWZCclVQnW4ac=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4256.namprd11.prod.outlook.com (52.135.36.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2495.22; Fri, 29 Nov 2019 23:31:26 +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.2495.014; Fri, 29 Nov 2019 23:31:25 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Yasuyuki Tanaka <yasuyuki.tanaka@inria.fr>
CC: "6tisch@ietf.org" <6tisch@ietf.org>
Thread-Topic: [6tisch] MSF Shepherd review
Thread-Index: AdWjt32cGBMVZwIGSJOTOBd/TtCApABq++aAAADPtX0AWG0eAAAAIxWEAAkDh4AAAdsskwACi4EAAAOiD2k=
Date: Fri, 29 Nov 2019 23:31:25 +0000
Message-ID: <C2217F07-2C7E-4DB4-80E3-7AD6A9136DAA@cisco.com>
References: <MN2PR11MB3565642A73EC6629FA68137DD84A0@MN2PR11MB3565.namprd11.prod.outlook.com> <CAAdgstRhP2aOfekS5swmXPbD1rwnR-bAAm9ToBQnwmv77KCSEw@mail.gmail.com> <27392BE1-0C67-410D-B1BC-1F751CC8656C@cisco.com> <CAAdgstRQGMg0fDUH94T+NZQ+s4JM8Wo=xDb+VMQ-sHDKvh8oiQ@mail.gmail.com> <6F9E85A6-B561-41CD-9E3C-7E6E761349B7@cisco.com> <80a20be0-c495-bed6-548c-f909161a7102@inria.fr> <C9BB553F-4531-4875-AE17-68237DCD576F@cisco.com>, <4648c9eb-8b44-e62e-970a-6a8ceed800ce@inria.fr>
In-Reply-To: <4648c9eb-8b44-e62e-970a-6a8ceed800ce@inria.fr>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=pthubert@cisco.com;
x-originating-ip: [91.69.164.91]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: d515f8fc-3b26-451a-26cc-08d775244094
x-ms-traffictypediagnostic: MN2PR11MB4256:
x-microsoft-antispam-prvs: <MN2PR11MB42564A5745CFCA4E1B349D2ED8460@MN2PR11MB4256.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0236114672
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(396003)(376002)(39860400002)(366004)(346002)(199004)(189003)(66476007)(66446008)(66556008)(64756008)(102836004)(53546011)(66946007)(2906002)(2616005)(8936002)(6506007)(5660300002)(8676002)(76116006)(81156014)(81166006)(99286004)(26005)(966005)(86362001)(478600001)(186003)(316002)(91956017)(229853002)(4326008)(3846002)(6116002)(14454004)(66066001)(6436002)(71200400001)(71190400001)(33656002)(6246003)(6512007)(6306002)(6486002)(25786009)(76176011)(305945005)(6916009)(7736002)(446003)(36756003)(256004)(11346002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4256; 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: mDAGg/e+BOGvO9H0JtDArVUOMY55vxcyQnMjvBuDAbA/kZSDIeQpOJp4xwY+9RauWO2NzH7EpSY0yiECyy/OCP/cxkGZdmFL0EQbxeF5gbtJIzkx9LEqY41CDT597VvNS+9m8PdC9W9UVSdSINWxotsnIAA3WdhVHqz1pHRX89KWkGWyG5vu7W9VS8doCqE+wgJR8enpaEB4qa42d79MEPZPHzTZ6rZvkQicc40h8pTt5HK+UE0lTGzioABmSmlvvAgox4fQszMkPl/63YwO1DGhpTaWXiBsrlcGhNwu4qNBeY1CFr6r6JQ1RlTELJOOTie44T/fpAUEDhWON5CCFDsVQOrmQh6UM8ZeuxZfINDNG0HLFG+fiKrUL2HqjrXGmwdf7wEYxI8Vldu1otqMK1ixLY7T4RK4KwCP+vxeoMJN2y/t2usU27tfltdY+vt/9JcL/zu5D1xydGQIb4xrbgTgG4u8YY5ty6kzhlKCRsI=
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: d515f8fc-3b26-451a-26cc-08d775244094
X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Nov 2019 23:31:25.7348 (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: 0vXQzfU4NJyBjKLDXYms+yrhbVZCfOZiQfh+rq7E9LDH9BM/TqjzjACpXZ7Y4V5Ggl3FYuJ6wHpFiGPmKZhfsg==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4256
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com
X-Outbound-Node: alln-core-6.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/6tisch/SBkCLDtyd871vlROcb03txcUrbM>
Subject: Re: [6tisch] MSF Shepherd review
X-BeenThere: 6tisch@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Discuss link layer model for Deterministic IPv6 over the TSCH mode of IEEE 802.15.4e, and impacts on RPL and 6LoWPAN such as resource allocation" <6tisch.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/6tisch>, <mailto:6tisch-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/6tisch/>
List-Post: <mailto:6tisch@ietf.org>
List-Help: <mailto:6tisch-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/6tisch>, <mailto:6tisch-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Nov 2019 23:31:32 -0000

Hello Yatch



> Le 29 nov. 2019 à 22:48, Yasuyuki Tanaka <yasuyuki.tanaka@inria.fr> a écrit :
> 
> Thank you, Pascal for your comment.
> 
>> On 11/29/2019 9:34 PM, Pascal Thubert (pthubert) wrote:
>> RPL underneath is designed to operate with multiple parents, and for a good reason.
> 
> I understand that point.
> 
> My point is, rephrasing the word alone couldn't be enough.
> 
>> Bandwidth allocation doesn’t care what traffic that is or it’s direction. It cares about the amount of traffic that needs to circulate over the hop.
> 
> In general, yes. According to the current text of MSF, the direction is relevant. For a upward neighbor, MSF allocates one negotiated TX cell just after recognizing it. For a downward neighbor, it doesn't.
> 
> On parent switch, the number of negotiated cells is carried over to a new parent. But what if a node has one parents at some point, then it selects an additional parent to handle some portion of traffic? How many negotiated cells should be scheduled with the new (additional) parent? MSF would have no idea.
> 
> To me, this seems a totally new thing to MSF.
> 

Not that new just the logical continuation. 

If a child has 2 parents a and b these are independent links, each with a number of cells. If it loses one parent a then the traffic on that link is rerouted. The cells on that link have to be moved to other parents which can include b. 

The existing cells to the parent b are not touched. If some traffic is rerouted to parent b then new cells are allocated there.


> Again, having multiple MSF instances could be a solution, which doesn't need the rephrasing.

For me instance is related to RPL I do not want to run multiple instances of RPL with one preferred parent each.

What I want is to run what the draft describes but several times in parallel once per active parent.

That’s what I called session. RPL says that a node can run separate instances like ship in the night and then describes the operw of one instance. Similarly MSF can run multiple sessions one per link as ship in the night. pretty much the draft needs to do is say that in introduction and then say that the rest of the draft describes one session with one parent. 

>> And it is possible to run an MSF session at L2 with each of them totally independently.
> 
> What do you mean by "MSF session"? If you have multiple MSF instances with different SFIDs or values for the Metadata field, they can be associated with different RPL DODAGsm and they will work independently.
> 

The draft describes a session between a parent and a child. They start the session, allocate resources in unison and when the session is broken they release the resources on each side. This happens within a L2 link. Sessions can live independently on different L2 links.



> On 11/29/2019 9:40 PM, Prof. Diego Dujovne wrote:
> > Would it be then a neighbour instead of a parent? (Assuming the
> > neighbour has joined the network)
> 
> I don't think so.
> 

As Yatch said the draft describes a child handling both sides so the link is directional, there’s a master and a slave. 

This may become a problem for east west traffic with PDAO. But there’s still a direction so it’s doable just need to agree that the parent is towards the destination.

All the best,

Pascal 


> Best,
> Yatch
> 
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch