From nobody Mon Jan 6 01:54:05 2020 Return-Path: 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 EECBF120122 for ; Mon, 6 Jan 2020 01:54:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.52 X-Spam-Level: X-Spam-Status: No, score=-14.52 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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=i+u9/Y+Z; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=oF/3oZVY 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 xlM-496BPUeg for ; Mon, 6 Jan 2020 01:54:01 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A66A120106 for ; Mon, 6 Jan 2020 01:54:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4365; q=dns/txt; s=iport; t=1578304441; x=1579514041; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=TylscyZh5Xpt550Nx4zcXmzLjum61DAsID/yGn6fLzc=; b=i+u9/Y+ZEddTv8yQUIt3UscZV/5l7J134FHJQbMuoBhmwFojGjgoFEB2 mOhZcFW/QkjQwNL1RdL4hrLsKQt6jc+4nvecDSYrIqM03MycEIkgHiCB/ /u7fYiLXWZdD42Tk7CG7zra3r20dfnBe8vKcQKixBph60IY23+zlZEvze 0=; IronPort-PHdr: =?us-ascii?q?9a23=3AZ7ZwFx1ODSbJdY74smDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxKGt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQEVH7MfTndTASF8VZX1gj9Ha+YgBY?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AzFQBpAhNe/5FdJa1mHgELHINQUAV?= =?us-ascii?q?sWCAECyqHTwOKf06CEYEBlwyCUgNUCQEBAQwBARgLCgIBAYRAAoFpJDgTAgM?= =?us-ascii?q?NAQEEAQEBAgEFBG2FCwclDIVeAQEBAQIBAQEQFRMGAQEsBAgECwIBCDYQJws?= =?us-ascii?q?lAQEEEwgagwGCRgMOIAECDKIAAoE4iGGBdDOCfgEBBYR/GIIMAwaBNoUdhnw?= =?us-ascii?q?agUE/gRABR4FOSTU+gmQBAYFlg0CCLIl3lgGONm8KgjaMb4QqhRyCRod9hEG?= =?us-ascii?q?HFYRCkBqZEgIEAgQFAg4BAQWBaSKBWHAVGiGCbFAYDYwJgQkMF4NQhRSFP3S?= =?us-ascii?q?BKIxzYAEB?= X-IronPort-AV: E=Sophos;i="5.69,402,1571702400"; d="scan'208";a="697226319" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 06 Jan 2020 09:54:00 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 0069s01w018897 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 6 Jan 2020 09:54:00 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 6 Jan 2020 03:53:59 -0600 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 6 Jan 2020 03:53:58 -0600 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 6 Jan 2020 03:53:58 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=I/jotowvFVAv+Jh1kzIOC3TIN79UYf2aos4x8O5Li4AlN+DWMze1+9aYzcT6MZ9HLyr+j2yDIhEK9QBxywtZcPDkI/3n61TlLN8v6+EOVZ7QPxaWNgCJjbAnwjQI3T8rnzyHs44A9bChnqMPo/Drg+A+aXZl9xxGd4WWTl22QC192U8rQ0T6wA5ao6nPaz57ryZCjZbzAwSBp/VPSjh6ZOpJJHf2WnCMViiq1RlGLUEeWjDyDaIsoJsCXUe3tmh/hiP083IYEnZUd8KLDFdkigIAMHsreiEsQXcOEsK1HHn4UsO0KIYX/+XcwG+Y/EWKkjFKY3Fqiog36R1p1EhfGA== 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=TmIQRy5b/m/NhUj2FztixcTOzO9zgaRr83bzJbOOl3o=; b=dNljIgvvvgcAaO1g5CQcHWOJkPgAK7zE2K5zj1eBQQUmKjMBF1J+Rzq7Fkb8AIil2tQz6XRHfxXUI9skv229/OVef6UoDTmIWtIddQjNLiCT/X9WPFc7Fk5uhRp2AtqrejvLP0hsQmyUEyqXPwTdyGKP4fDFZZne+lQrUIaonKLhWkrClyJ6C08lMENSQ4eIJecKLTpKUMPh4MInWzXPg5eh0AezNtaRS62wyNkWUpU86gyAQvBsxGHYpbIUWaztVekMsnJIHW2gzC2EOfBI/6m+y9v8/B818DXMjPXzkpUOMXPBpWeyzrIw9WAs8jh+rpYneavzL/U+TpIeDRVVtA== 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=TmIQRy5b/m/NhUj2FztixcTOzO9zgaRr83bzJbOOl3o=; b=oF/3oZVYkRuggBDoLXEELa9ILVJQfCCX03EpzJfWv+xbc5bdjMXUp1C0QF+YLeYEG1MaNEqWdWPs2W37emF2HA8asXbBNIt33Ob4ab2Ds+SbvHZhX2kzwh+9gf40gKfEpVMQYpfGqOjG+eMrEAeHpy63JAks4Ifet3QQCGkL7rU= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4511.namprd11.prod.outlook.com (52.135.37.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.13; Mon, 6 Jan 2020 09:53:57 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::fd76:1534:4f9a:452a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::fd76:1534:4f9a:452a%3]) with mapi id 15.20.2602.015; Mon, 6 Jan 2020 09:53:57 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: Comments on draft-ietf-roll-dao-projection-09 Thread-Index: AdW5cQcc12mzHhBPSAydPP/oeu3NqgK9Sp3A Date: Mon, 6 Jan 2020 09:53:48 +0000 Deferred-Delivery: Mon, 6 Jan 2020 09:53:40 +0000 Message-ID: References: In-Reply-To: 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: [2001:420:c0c0:1001::111] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e5ac9c20-20ad-4eb3-37ba-08d7928e5941 x-ms-traffictypediagnostic: MN2PR11MB4511: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 0274272F87 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(396003)(366004)(39860400002)(376002)(346002)(37854004)(199004)(189003)(81166006)(81156014)(6916009)(316002)(71200400001)(5660300002)(66574012)(8936002)(8676002)(2906002)(86362001)(52536014)(6506007)(966005)(186003)(33656002)(66556008)(66476007)(64756008)(66446008)(66946007)(7696005)(76116006)(6666004)(9686003)(478600001)(55016002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4511; 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: bWcSGpxHI+ShwHteGWtOhkP+PbDqcM/iwvaOHdWmNidkM4RChDPUPbJw4THyRfb/hy2ucgva9L60UsRdV9TRQabhB5wDDZU6N/7BsLILQrVaY1zxu5JBsOS+QC7AKM37Ct1QIpZAQCxcSqZeFBJyCpZhKUNPBIkNlFf2AR4Fdfhy5xu4JVj6ViNLzLzvuggcaDgg9+7iMcC9DAjJ9lPVqq7u4ukp949bonS2zgtPsOkParbTK2YGgEo57UZrCJbx490YglF7uE/hN0+oC0pB3wviX+xGLa34W44Ji1ELkvNMxUoYjKmIjihmeZhP/JgWMS5k+AUSfSDoc/l8Cno7IXPW9xBWJ+HuCa83tA2RyfqbO/zqr2d5jlR1VCEymDCc/e1hk9qpLJuJcnTX9VRpbwGQ91XwV6K97maan4PjV0Boc2b9VBwgmsXV5A+c5zvUOUl3NcZMjHY301eg/qV1tlnBDHKYYT0ZuEKVHe84QAH6Zzw0SC82sY3+EnMZeVG/3FZUeKUzKr6UY8wCtU15biiT/e4yATgd7ZgZKKWvhVU= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e5ac9c20-20ad-4eb3-37ba-08d7928e5941 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jan 2020 09:53:57.5113 (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: ZLabn+GJ6ge7LH51zHBmeEYyVlOQjl2j0umWwKl8rKbWehIw9aG/YfAeiMtvbMFRcdEtAipu5mnp6t5rPQL9Pw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4511 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com X-Outbound-Node: rcdn-core-9.cisco.com Archived-At: Subject: Re: [Roll] Comments on draft-ietf-roll-dao-projection-09 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jan 2020 09:54:04 -0000 Hello Remy Many thanks for your review! Please see below: > I've read the latest version of the draft. Great efforts! Please find my = comments > below for your consideration. >=20 > 1. Why do you choose to extend RPL instead of designing a new separate > protocol to realize the establishment of a path? Technically, extending R= PL > works for sure. But if you look outside the IOT domain, the PCE have a se= parate > protocol, i.e. PCEP, to establish the paths on the devices. PCEP to the device acting as PCC was considered in the history of 6TiSCH. S= o was RSVP-TE. The Okham razor we used was code footprint.=20 Most implementations we are aware of do not provide TCP that PCEP needs, an= d RSVP-TE would be a whole new protocol to support.=20 We'd have needed both plus a TE extension to RPL anyway. Extending RPL for = the whole thing was a simpler and smaller update. Also we wanted to maintain the device<->root relationship that we use in no= n-storing mode and that may be secured separately in the future. It is still possible to use PCEP for the southbound interface root<->PCE an= d have the Root acting as PCC translate in P-DAO terms as opposed to RSVP-T= E.=20 > 2. The titles of the subsections in section 6 are misleading. When I look= ed at the > title "Non-storing/Storing mode projected route", I misunderstood them in= to > "Route projection in non-storing/storing mode". Actually, until I reached= at the > appendix, I realized that they means the projected route itself is source= -routed > or hop-by-hop (no matter strict or loose). Do you think it is necessary = to add > some clarification or to change the titles? Yes, that makes sense to me. Would you have a suggestion? Could you make th= at a separate thread to attract a better attention from the group? > 3. The following specification is not accurate in some cases: " In the > uncompressed form the source of the packet would be self, the destination > would be the first Via Address in the SRVIO, and the SRH would contain th= e list > of the remaining Via Addresses and then the Target". > It is true if RPL is running in storing mode, otherwise, another encapsul= ation > takes place to indicate the explicit route to the via address, just like = you have > said in the preceding paragraph. And the said explicit route should be pr= ojected > as well. Please consider combining the two paragraphs to make it correct. Great suggestion! Reordering things give: " When forwarding a packet to a destination for which the router determines that routing happens via the Target, the router inserts the source routing header in the packet to reach the Target. In order to add a source-routing header, the router encapsulates the packet with an IP-in-IP header and a non-storing mode source routing header (SRH) [RFC6554]. In the uncompressed form the source of the packet would be self, the destination would be the first Via Address in the SRVIO, and the SRH would contain the list of the remaining Via Addresses and then the Target. In the case of a loose source-routed path, there MUST be either a neighbor that is adjacent to the loose next hop, on which case the packet is forwarded to that neighbor, or a source-routed path to the loose next hop; in the latter case, another encapsulation takes place and the process possibly recurses; otherwise the packet is dropped. " Works? > 4. You've mentioned that the root can be the egress of a path. Does it me= an > that the upward route needs to be projected in some cases, given the fact= that > most of the examples given in the draft are downward or transversal route= s? > Could you give an example on that situation? The P-DAO routes are separate RPL instances. They can be computed based on = an alternate choice of metrics. This means that the "short" path along the DODAG for the main OF may differ= from the preferred one for the objective of the P-DAO route. e.g., if reliability is required for the P-DAO route, the root may enforce = B-A->root through in the main DODAG B is a child of root. All the best, Pascal >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Mon Jan 6 19:39:43 2020 Return-Path: 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 5E7B9120058 for ; Mon, 6 Jan 2020 19:39:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 iejLs7Rlk7yE for ; Mon, 6 Jan 2020 19:39:40 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D03212004A for ; Mon, 6 Jan 2020 19:39:40 -0800 (PST) Received: from LHREML710-CAH.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 4BCD7F1CAEF5A4E056E6 for ; Tue, 7 Jan 2020 03:39:38 +0000 (GMT) Received: from lhreml701-chm.china.huawei.com (10.201.108.50) by LHREML710-CAH.china.huawei.com (10.201.108.33) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 7 Jan 2020 03:39:37 +0000 Received: from lhreml701-chm.china.huawei.com (10.201.108.50) by lhreml701-chm.china.huawei.com (10.201.108.50) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1713.5; Tue, 7 Jan 2020 03:39:37 +0000 Received: from DGGEMM401-HUB.china.huawei.com (10.3.20.209) by lhreml701-chm.china.huawei.com (10.201.108.50) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1713.5 via Frontend Transport; Tue, 7 Jan 2020 03:39:37 +0000 Received: from DGGEMM506-MBS.china.huawei.com ([169.254.4.58]) by DGGEMM401-HUB.china.huawei.com ([10.3.20.209]) with mapi id 14.03.0439.000; Tue, 7 Jan 2020 11:39:31 +0800 From: "Liubing (Remy)" To: Routing Over Low power and Lossy networks Thread-Topic: Comments on draft-ietf-roll-dao-projection-09 Thread-Index: AdW5cQcc12mzHhBPSAydPP/oeu3NqgK9Sp3AACb5xYA= Date: Tue, 7 Jan 2020 03:39:30 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.180.83] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Roll] Comments on draft-ietf-roll-dao-projection-09 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 03:39:42 -0000 Hello Pascal, Thank you for your reply. I think you have answered almost all my questions= . Let's discuss the second question in a separate mail. Best regards, Remy > -----Original Message----- > From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert > (pthubert) > Sent: Monday, January 06, 2020 5:54 PM > To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] Comments on draft-ietf-roll-dao-projection-09 >=20 > Hello Remy >=20 > Many thanks for your review! >=20 > Please see below: >=20 > > I've read the latest version of the draft. Great efforts! Please find > > my comments below for your consideration. > > > > 1. Why do you choose to extend RPL instead of designing a new separate > > protocol to realize the establishment of a path? Technically, > > extending RPL works for sure. But if you look outside the IOT domain, > > the PCE have a separate protocol, i.e. PCEP, to establish the paths on = the > devices. >=20 >=20 > PCEP to the device acting as PCC was considered in the history of 6TiSCH.= So > was RSVP-TE. The Okham razor we used was code footprint. > Most implementations we are aware of do not provide TCP that PCEP needs, > and RSVP-TE would be a whole new protocol to support. > We'd have needed both plus a TE extension to RPL anyway. Extending RPL > for the whole thing was a simpler and smaller update. > Also we wanted to maintain the device<->root relationship that we use in > non-storing mode and that may be secured separately in the future. > It is still possible to use PCEP for the southbound interface root<->PCE = and > have the Root acting as PCC translate in P-DAO terms as opposed to RSVP-T= E. >=20 > > 2. The titles of the subsections in section 6 are misleading. When I > > looked at the title "Non-storing/Storing mode projected route", I > > misunderstood them into "Route projection in non-storing/storing > > mode". Actually, until I reached at the appendix, I realized that they > > means the projected route itself is source-routed or hop-by-hop (no > > matter strict or loose). Do you think it is necessary to add some clar= ification > or to change the titles? >=20 > Yes, that makes sense to me. Would you have a suggestion? Could you make > that a separate thread to attract a better attention from the group? >=20 > > 3. The following specification is not accurate in some cases: " In the > > uncompressed form the source of the packet would be self, the > > destination would be the first Via Address in the SRVIO, and the SRH > > would contain the list of the remaining Via Addresses and then the Targ= et". > > It is true if RPL is running in storing mode, otherwise, another > > encapsulation takes place to indicate the explicit route to the via > > address, just like you have said in the preceding paragraph. And the > > said explicit route should be projected as well. Please consider combin= ing > the two paragraphs to make it correct. >=20 > Great suggestion! Reordering things give: >=20 > " >=20 > When forwarding a packet to a destination for which the router > determines that routing happens via the Target, the router inserts > the source routing header in the packet to reach the Target. In > order to add a source-routing header, the router encapsulates the > packet with an IP-in-IP header and a non-storing mode source routing > header (SRH) [RFC6554]. In the uncompressed form the source of the > packet would be self, the destination would be the first Via Address > in the SRVIO, and the SRH would contain the list of the remaining Via > Addresses and then the Target. >=20 > In the case of a loose source-routed path, there MUST be either a > neighbor that is adjacent to the loose next hop, on which case the > packet is forwarded to that neighbor, or a source-routed path to the > loose next hop; in the latter case, another encapsulation takes place > and the process possibly recurses; otherwise the packet is dropped. >=20 > " >=20 > Works? >=20 > > 4. You've mentioned that the root can be the egress of a path. Does it > > mean that the upward route needs to be projected in some cases, given > > the fact that most of the examples given in the draft are downward or > transversal routes? > > Could you give an example on that situation? >=20 > The P-DAO routes are separate RPL instances. They can be computed based > on an alternate choice of metrics. > This means that the "short" path along the DODAG for the main OF may > differ from the preferred one for the objective of the P-DAO route. > e.g., if reliability is required for the P-DAO route, the root may enforc= e B-A- > >root through in the main DODAG B is a child of root. >=20 > All the best, >=20 > Pascal > > > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Mon Jan 6 19:39:58 2020 Return-Path: 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 8187712086C for ; Mon, 6 Jan 2020 19:39:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 FX1QzENzsGBG for ; Mon, 6 Jan 2020 19:39:47 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68004120827 for ; Mon, 6 Jan 2020 19:39:47 -0800 (PST) Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 137D8DD476EB6D14D69C for ; Tue, 7 Jan 2020 03:39:46 +0000 (GMT) Received: from lhreml744-chm.china.huawei.com (10.201.108.194) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 7 Jan 2020 03:39:45 +0000 Received: from lhreml744-chm.china.huawei.com (10.201.108.194) by lhreml744-chm.china.huawei.com (10.201.108.194) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Tue, 7 Jan 2020 03:39:45 +0000 Received: from DGGEMM421-HUB.china.huawei.com (10.1.198.38) by lhreml744-chm.china.huawei.com (10.201.108.194) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA) id 15.1.1713.5 via Frontend Transport; Tue, 7 Jan 2020 03:39:45 +0000 Received: from DGGEMM506-MBS.china.huawei.com ([169.254.4.58]) by dggemm421-hub.china.huawei.com ([10.1.198.38]) with mapi id 14.03.0439.000; Tue, 7 Jan 2020 11:39:42 +0800 From: "Liubing (Remy)" To: Routing Over Low power and Lossy networks Thread-Topic: Suggestions on the naming of the projected routes Re: Comments on draft-ietf-roll-dao-projection-09 Thread-Index: AdXFB2fUxEgut6qtS8OIEmcUYCIDgw== Date: Tue, 7 Jan 2020 03:39:42 +0000 Message-ID: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.130.180.83] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: [Roll] Suggestions on the naming of the projected routes Re: Comments on draft-ietf-roll-dao-projection-09 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 03:39:57 -0000 Hello Roll, In the previous discussion with Pascal, we have the following question bett= er to discuss separately. > > 2. The titles of the subsections in section 6 are misleading. When I > > looked at the title "Non-storing/Storing mode projected route", I > > misunderstood them into "Route projection in non-storing/storing > > mode". Actually, until I reached at the appendix, I realized that they > > means the projected route itself is source-routed or hop-by-hop (no > > matter strict or loose). Do you think it is necessary to add some clar= ification > or to change the titles? >=20 [Pascal] Yes, that makes sense to me. Would you have a suggestion? Could yo= u make > that a separate thread to attract a better attention from the group? [Remy ]My suggestion would be, change "non-storing" to "source-routed" and = "storing" to "hop-by-hop", to distinguish from the non-storing/storing mode= of RPL. Here "source-routed" means more than one Via addresses in the Route Project= ion Options, and "hop-by-hop" means exactly one Via address.=20 Any suggestion from Pascal and others? Best regards, Remy=20 > -----Original Message----- > From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert > (pthubert) > Sent: Monday, January 06, 2020 5:54 PM > To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] Comments on draft-ietf-roll-dao-projection-09 >=20 > Hello Remy >=20 > Many thanks for your review! >=20 > Please see below: >=20 > > I've read the latest version of the draft. Great efforts! Please find > > my comments below for your consideration. > > > > 1. Why do you choose to extend RPL instead of designing a new separate > > protocol to realize the establishment of a path? Technically, > > extending RPL works for sure. But if you look outside the IOT domain, > > the PCE have a separate protocol, i.e. PCEP, to establish the paths on = the > devices. >=20 >=20 > PCEP to the device acting as PCC was considered in the history of 6TiSCH.= So > was RSVP-TE. The Okham razor we used was code footprint. > Most implementations we are aware of do not provide TCP that PCEP needs, > and RSVP-TE would be a whole new protocol to support. > We'd have needed both plus a TE extension to RPL anyway. Extending RPL > for the whole thing was a simpler and smaller update. > Also we wanted to maintain the device<->root relationship that we use in > non-storing mode and that may be secured separately in the future. > It is still possible to use PCEP for the southbound interface root<->PCE = and > have the Root acting as PCC translate in P-DAO terms as opposed to RSVP-T= E. >=20 > > 2. The titles of the subsections in section 6 are misleading. When I > > looked at the title "Non-storing/Storing mode projected route", I > > misunderstood them into "Route projection in non-storing/storing > > mode". Actually, until I reached at the appendix, I realized that they > > means the projected route itself is source-routed or hop-by-hop (no > > matter strict or loose). Do you think it is necessary to add some clar= ification > or to change the titles? >=20 > Yes, that makes sense to me. Would you have a suggestion? Could you make > that a separate thread to attract a better attention from the group? >=20 > > 3. The following specification is not accurate in some cases: " In the > > uncompressed form the source of the packet would be self, the > > destination would be the first Via Address in the SRVIO, and the SRH > > would contain the list of the remaining Via Addresses and then the Targ= et". > > It is true if RPL is running in storing mode, otherwise, another > > encapsulation takes place to indicate the explicit route to the via > > address, just like you have said in the preceding paragraph. And the > > said explicit route should be projected as well. Please consider combin= ing > the two paragraphs to make it correct. >=20 > Great suggestion! Reordering things give: >=20 > " >=20 > When forwarding a packet to a destination for which the router > determines that routing happens via the Target, the router inserts > the source routing header in the packet to reach the Target. In > order to add a source-routing header, the router encapsulates the > packet with an IP-in-IP header and a non-storing mode source routing > header (SRH) [RFC6554]. In the uncompressed form the source of the > packet would be self, the destination would be the first Via Address > in the SRVIO, and the SRH would contain the list of the remaining Via > Addresses and then the Target. >=20 > In the case of a loose source-routed path, there MUST be either a > neighbor that is adjacent to the loose next hop, on which case the > packet is forwarded to that neighbor, or a source-routed path to the > loose next hop; in the latter case, another encapsulation takes place > and the process possibly recurses; otherwise the packet is dropped. >=20 > " >=20 > Works? >=20 > > 4. You've mentioned that the root can be the egress of a path. Does it > > mean that the upward route needs to be projected in some cases, given > > the fact that most of the examples given in the draft are downward or > transversal routes? > > Could you give an example on that situation? >=20 > The P-DAO routes are separate RPL instances. They can be computed based > on an alternate choice of metrics. > This means that the "short" path along the DODAG for the main OF may > differ from the preferred one for the objective of the P-DAO route. > e.g., if reliability is required for the P-DAO route, the root may enforc= e B-A- > >root through in the main DODAG B is a child of root. >=20 > All the best, >=20 > Pascal > > > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Tue Jan 7 01:10:36 2020 Return-Path: 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 973E112006E for ; Tue, 7 Jan 2020 01:10:33 -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=RJeGefY5; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=SaPqvlwJ 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 T4Y1SDfUgusu for ; Tue, 7 Jan 2020 01:10:31 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2F47120019 for ; Tue, 7 Jan 2020 01:10:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7062; q=dns/txt; s=iport; t=1578388231; x=1579597831; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=lwbl6couPpzHLrUBLy/wUI+6OE/zbT8EpNKS+o92ocY=; b=RJeGefY5AW0BQ5of+Fpjabay/R6wj62NsjsIPnqpsKk1qcEMV1B8Cnv6 lMkQncglDEYYbaaoNaXcIXTDXLiikNjK+MuxnnWQRrDWy/adourhnYqcR MCfLFLhjaK8xFUVdQhnKJLhQvBw3XXVxOijtXUrHEc3i/ethBRJqzrEsY g=; IronPort-PHdr: =?us-ascii?q?9a23=3ABtl7NBZCcqUjIw9kv/aZOWL/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20gabRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8KavycywnFslYSHdu/mqwNg5eH8OtL1A=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AbDwB7ShRe/4oNJK1mHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXyBVFAFbFggBAsqh08DiwJOghGBAZcMglIDVAkBAQEMAQEYCwo?= =?us-ascii?q?CAQGEQAKBaSQ4EwIDDQEBBAEBAQIBBQRthQsHJQyFXgEBAQEDAQEQFRMGAQE?= =?us-ascii?q?sBAgLBAIBCBEEAQEfBQQHJwsUCQgBAQQTCBqDAYJGAy4BAgyhXgKBOIhhgXQ?= =?us-ascii?q?zgn4BAQWFAxiCDAMGgTaFHYZ8GoFBP4EQAUeBTkkHLj6CZAEBgUceJIMcgiy?= =?us-ascii?q?JeKQ8bwqCNoxwhCuFHIJHh32EQ4cWhEKQG5kZAgQCBAUCDgEBBYFpIoFYcBU?= =?us-ascii?q?aIYJsUBgNjAmBCQwXFYM7hRSFP3SBKIxkYAEB?= X-IronPort-AV: E=Sophos;i="5.69,405,1571702400"; d="scan'208";a="398563654" Received: from alln-core-5.cisco.com ([173.36.13.138]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 Jan 2020 09:10:30 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 0079ATe5032253 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 7 Jan 2020 09:10:30 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 7 Jan 2020 03:10:29 -0600 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 7 Jan 2020 03:10:28 -0600 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 7 Jan 2020 03:10:28 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IZbPJWTlZlfeHKWtybgFltC0TkFMzD8v2inWERqIeX3Mta5oPw9VxKpSkmf5gp1haAwGFfpCUEvs4DAvcL93spnXyqiXV+PmkSTY1MjXOmhEYAJQNLWZEbaTgP19px1D413TVjzW9cvQ3uZAiba/0ZKHNF1ycsrB8iSNkGWEz5zcHL8neUnUzV72F/H+w2TtxAUtfJd5AzKD2PvAIFRT+gyUMzGmhs/bHu1POumJm0mZAFDZ4jxJaqo9+2W9Feb9Y6iXgCoDiAJTPopH7zlHSglyOAWc/t4IivCW8fZoCuwumq6lhVQKd14RJwWDorTFoC5aDp33yEWFxdfON2gm3w== 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=yfjJFfX/qG9doVDh7d29Ah4KIAOZcjHRGYM4lr9Uinc=; b=mbu5vDmqPDWluvYDbWIj5HrU1xsADGMp6GOZPubcN/zWvlw5X0aeGJqwdyMTaqb4iuGvm6ulTm0p/sanLRlZMRjs3J3sJToqE2xYFfvFJlO+JWV1P+wxc9FCGe8OWT1lW7gvRmC4Bt1wrY7ChksJFA6unTPpzCcIeefFGxSchYRi0rP1ij2pgqpHIQ+vIhzsmaojW5bi+burJR/wFy7V0/eiPe+fLgaKZyH0vATxH1lbdm5G+1y7QyQ3IhcdcX9TKKnmFRYy23X9yQmUlrD8anoIvUE7c7kcRfN9zPOUyYVfl+qXx8vK0WyC49E6pD5dP8G3sFxkMPfoyQ+CtUFSnA== 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=yfjJFfX/qG9doVDh7d29Ah4KIAOZcjHRGYM4lr9Uinc=; b=SaPqvlwJ1sgjlCp8oT71xU+7UejeSUKkwkKb+IxqCeyy40hnHHKNO+NY0aFJoH5U+Ne47yN0dUFpVySydtcuHU+SBUI4AjB+pjx8wPlqMwCfjn06bI76/zRjCS4p1lFyv22E1C/d18oMCR6yGEaIwAmV5FKo3E0CVud+sRMAorg= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3709.namprd11.prod.outlook.com (20.178.252.214) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.15; Tue, 7 Jan 2020 09:10:27 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::fd76:1534:4f9a:452a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::fd76:1534:4f9a:452a%3]) with mapi id 15.20.2602.015; Tue, 7 Jan 2020 09:10:27 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: Suggestions on the naming of the projected routes Re: Comments on draft-ietf-roll-dao-projection-09 Thread-Index: AdXFB2fUxEgut6qtS8OIEmcUYCIDgwAMh87Q Date: Tue, 7 Jan 2020 09:10:01 +0000 Deferred-Delivery: Tue, 7 Jan 2020 09:09:50 +0000 Message-ID: References: In-Reply-To: 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: [2001:420:44f3:1300:41e7:7725:e525:b2e8] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8ff7407f-fa92-416a-8a92-08d793516fcd x-ms-traffictypediagnostic: MN2PR11MB3709: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 027578BB13 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(346002)(376002)(366004)(396003)(136003)(199004)(189003)(13464003)(37854004)(6666004)(55016002)(8676002)(81166006)(81156014)(2906002)(8936002)(7696005)(9686003)(478600001)(966005)(316002)(33656002)(5660300002)(66556008)(66446008)(66476007)(76116006)(66946007)(64756008)(6506007)(53546011)(52536014)(186003)(6916009)(66574012)(71200400001)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3709; 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: +b1yIBZVvCgcMs/NcZayf4hvdEfS/Vo44HHCqlvaOvNMX6Gj+HBL2Y62xvxJzWnQtUnYXUE9Vk2u9E6jUjgWIT/Hma5E8C38HJtcytZms5aC0wOlhBSfO5x2qhhi7ASkoNK47siiOgXmlo4EkXfcnwTsGLqnkPHHzJowr6HNk8jiNkFaALCh0YgMg98+VKcKnyaDWNQbqvvaQNo8TFuLqioNXli2GOp9wPIZO/P0GF9PxLjrd+sqrKd8kf4oxq7YOh2pksvd2KsRUczJA87FKGtGjDGTaITwGgHkc3VN0sb/fP04fJQGgPny3I4doRH1abOwDTXBKVXHqo7PSXZXZnFTPrslECOPzCe8FkcVbcZmYR7KEjRvwDefXQ346sNTTPb0G1cfUYPcvLChuFhjF1pPJi4pAvWABp7RHUCorwvGMRgDWdTjacMA0z693TnQem1ZEku/ELlVDVEg5Z/Iyma0DNbLifAfo4jdIWHu1HSWRyIQA9OcCxf092MDXCUZBQM6mK5WA+5B21QySHPB6sGaHNM16UyolZITFeerNE/hOLzwR/uF0QC43fvkKgHN x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 8ff7407f-fa92-416a-8a92-08d793516fcd X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jan 2020 09:10:27.2440 (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: dQFOge0y61prdgT4yC7gBjGnrkImBBOnMAcXRTZSzyfzQfRoI4y2j5KQDae31cRQF/7lhMIUfs3h2CR9PBFv2g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3709 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.20, xch-rcd-010.cisco.com X-Outbound-Node: alln-core-5.cisco.com Archived-At: Subject: Re: [Roll] Suggestions on the naming of the projected routes Re: Comments on draft-ietf-roll-dao-projection-09 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 09:10:34 -0000 Hello Remy Source-routed vs. hop-by-hop work for me. Can we do better? Ideally we'd find a qualifier that differentiates from the main DAG where t= hose qualifiers also apply. All the best Pascal > -----Original Message----- > From: Roll On Behalf Of Liubing (Remy) > Sent: mardi 7 janvier 2020 04:40 > To: Routing Over Low power and Lossy networks > Subject: [Roll] Suggestions on the naming of the projected routes Re: > Comments on draft-ietf-roll-dao-projection-09 >=20 > Hello Roll, >=20 > In the previous discussion with Pascal, we have the following question be= tter to > discuss separately. >=20 > > > 2. The titles of the subsections in section 6 are misleading. When I > > > looked at the title "Non-storing/Storing mode projected route", I > > > misunderstood them into "Route projection in non-storing/storing > > > mode". Actually, until I reached at the appendix, I realized that > > > they means the projected route itself is source-routed or hop-by-hop > > > (no matter strict or loose). Do you think it is necessary to add > > > some clarification > > or to change the titles? > > > [Pascal] Yes, that makes sense to me. Would you have a suggestion? Could = you > make > > that a separate thread to attract a better attention from the group? >=20 > [Remy ]My suggestion would be, change "non-storing" to "source-routed" an= d > "storing" to "hop-by-hop", to distinguish from the non-storing/storing mo= de of > RPL. >=20 > Here "source-routed" means more than one Via addresses in the Route > Projection Options, and "hop-by-hop" means exactly one Via address. >=20 > Any suggestion from Pascal and others? >=20 > Best regards, > Remy >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: Roll [mailto:roll-bounces@ietf.org] On Behalf Of Pascal Thubert > > (pthubert) > > Sent: Monday, January 06, 2020 5:54 PM > > To: Routing Over Low power and Lossy networks > > Subject: Re: [Roll] Comments on draft-ietf-roll-dao-projection-09 > > > > Hello Remy > > > > Many thanks for your review! > > > > Please see below: > > > > > I've read the latest version of the draft. Great efforts! Please > > > find my comments below for your consideration. > > > > > > 1. Why do you choose to extend RPL instead of designing a new > > > separate protocol to realize the establishment of a path? > > > Technically, extending RPL works for sure. But if you look outside > > > the IOT domain, the PCE have a separate protocol, i.e. PCEP, to > > > establish the paths on the > > devices. > > > > > > PCEP to the device acting as PCC was considered in the history of > > 6TiSCH. So was RSVP-TE. The Okham razor we used was code footprint. > > Most implementations we are aware of do not provide TCP that PCEP > > needs, and RSVP-TE would be a whole new protocol to support. > > We'd have needed both plus a TE extension to RPL anyway. Extending RPL > > for the whole thing was a simpler and smaller update. > > Also we wanted to maintain the device<->root relationship that we use > > in non-storing mode and that may be secured separately in the future. > > It is still possible to use PCEP for the southbound interface > > root<->PCE and have the Root acting as PCC translate in P-DAO terms as > opposed to RSVP-TE. > > > > > 2. The titles of the subsections in section 6 are misleading. When I > > > looked at the title "Non-storing/Storing mode projected route", I > > > misunderstood them into "Route projection in non-storing/storing > > > mode". Actually, until I reached at the appendix, I realized that > > > they means the projected route itself is source-routed or hop-by-hop > > > (no matter strict or loose). Do you think it is necessary to add > > > some clarification > > or to change the titles? > > > > Yes, that makes sense to me. Would you have a suggestion? Could you > > make that a separate thread to attract a better attention from the grou= p? > > > > > 3. The following specification is not accurate in some cases: " In > > > the uncompressed form the source of the packet would be self, the > > > destination would be the first Via Address in the SRVIO, and the SRH > > > would contain the list of the remaining Via Addresses and then the Ta= rget". > > > It is true if RPL is running in storing mode, otherwise, another > > > encapsulation takes place to indicate the explicit route to the via > > > address, just like you have said in the preceding paragraph. And the > > > said explicit route should be projected as well. Please consider > > > combining > > the two paragraphs to make it correct. > > > > Great suggestion! Reordering things give: > > > > " > > > > When forwarding a packet to a destination for which the router > > determines that routing happens via the Target, the router inserts > > the source routing header in the packet to reach the Target. In > > order to add a source-routing header, the router encapsulates the > > packet with an IP-in-IP header and a non-storing mode source routing > > header (SRH) [RFC6554]. In the uncompressed form the source of the > > packet would be self, the destination would be the first Via Address > > in the SRVIO, and the SRH would contain the list of the remaining Vi= a > > Addresses and then the Target. > > > > In the case of a loose source-routed path, there MUST be either a > > neighbor that is adjacent to the loose next hop, on which case the > > packet is forwarded to that neighbor, or a source-routed path to the > > loose next hop; in the latter case, another encapsulation takes plac= e > > and the process possibly recurses; otherwise the packet is dropped. > > > > " > > > > Works? > > > > > 4. You've mentioned that the root can be the egress of a path. Does > > > it mean that the upward route needs to be projected in some cases, > > > given the fact that most of the examples given in the draft are > > > downward or > > transversal routes? > > > Could you give an example on that situation? > > > > The P-DAO routes are separate RPL instances. They can be computed > > based on an alternate choice of metrics. > > This means that the "short" path along the DODAG for the main OF may > > differ from the preferred one for the objective of the P-DAO route. > > e.g., if reliability is required for the P-DAO route, the root may > > enforce B-A- > > >root through in the main DODAG B is a child of root. > > > > All the best, > > > > 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 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Tue Jan 7 08:11:53 2020 Return-Path: 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 BBFDB120170 for ; Tue, 7 Jan 2020 08:11:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 rj2A0rdVhG_7 for ; Tue, 7 Jan 2020 08:11:49 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BAAC12012E for ; Tue, 7 Jan 2020 08:11:48 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id DFFE73897A for ; Tue, 7 Jan 2020 11:11:27 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id EE41E60A for ; Tue, 7 Jan 2020 11:11:47 -0500 (EST) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: References: X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Roll] Suggestions on the naming of the projected routes Re: Comments on draft-ietf-roll-dao-projection-09 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jan 2020 16:11:52 -0000 --=-=-= Content-Type: text/plain Pascal Thubert (pthubert) wrote: > Source-routed vs. hop-by-hop work for me. Can we do better? > Ideally we'd find a qualifier that differentiates from the main DAG > where those qualifiers also apply. I think that the terms are fine for the document in question. I think that we are overall (as a WG), we going towards various kinds of hybrid forms and the words storing/non-storing need to go away from our lexicon completely. (p2pRPL comes to mind) We may want to distinguish between nodes in a network that have complete or incomplete knowledge of their subtrees. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl4UrcMACgkQgItw+93Q 3WXScAf/exzhcr9k2vwgph6qX30T3d69Fs71dBxV4b3Vb0HkmmR9+cfgvBWlp4T/ xB0eJXVyvX9qn8xn5dxX9W3FU0UAbl+7D3+qbEfKr+A2dK+u+z5wnnU1uUbJdttt w99x/PoeMS4u+ZJL7ETGjLgPOAcFRG8KYH09rnDHhij39QT07eQSgdUG+DpDmsXY lzFe1zj6X5YIO859r7I/Hs+px5dy3tZZgyxkk0y99yYu4CPl7oz+QGgOWZ/i4HYJ hFBz2PQrHOvAKyuLXfDzLxsyKm6twW/biCK3zSAScqw6RhBSZIggKRK6gkqstudK xdnZuwhzoBCiU08KYA/e/Xyxf0jppQ== =KPIe -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jan 17 02:40:15 2020 Return-Path: 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 C8B8A1201DB for ; Fri, 17 Jan 2020 02:40:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com 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 GSLoAx9aA_yH for ; Fri, 17 Jan 2020 02:40:07 -0800 (PST) Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBC86120047 for ; Fri, 17 Jan 2020 02:40:07 -0800 (PST) Received: by mail-io1-xd30.google.com with SMTP id k24so25437164ioc.4 for ; Fri, 17 Jan 2020 02:40:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=Dqbu1Az0Jd/xn6lM2F9/MzRcms1dU60dsr+0kH7BgQk=; b=C4mhunTv29FhaCcaLqIT2T5aoL6Cz4/ShxpvpHwSkE6/1cx8sv17R2Rlu8OOjr+69L WKdAS3TmcYmHvxXItoKRULArY7U0Oi6Nn7eiFdVHiWVe0U3ExYLB+lA2gS346QtplfIv ydk1YupIn5270e6px09mRZwbBBp7q/r3rypJqlglJdrpFZtgHyu4nwbwcrKQTT/OYxnI sDq0Kx2XzDMuEMeoB4thi/85kQCiM8Kb0YiZ7H2TB+OAdEkZQFHA1geka5dp5EOSnqE+ QYBC/iCGBhGjyoRJiqz+XUTB6B5ksnsNSdEgbxg8J63eZfYfXfkoM48ij/hRakewfiOL Gvmg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=Dqbu1Az0Jd/xn6lM2F9/MzRcms1dU60dsr+0kH7BgQk=; b=rCFDFwbREDdcYIagtAM+Tp087N9UiMy3RXeF8b8/K9R7+7N18B8SHq0we69xXBxei8 EcxgYmIn1WlSkmYTq5hPjcJUmBkETQuwGgjPGgyDDE2ffu4deqbTG5lZG7elkNA2GpFc Po2Gt9bm+7n4oIwx3zHXVKAoXOZu+R04mKt5iiwZluA+gyOGkNXuy/rH5OGwym2qFBgT bRE/IWY0zcTiRWFUzNvJyZ6DivJbcwZnwcpPqYkozydaD8MzhV9OhBEDp7LUyPa4g+Jl Lj6m5Jfzo9/gARPia1jovp9ZpEwbDxJqMKeKIY0vdB+xxKjP/R2cv5BboxRbk08Zskug IdLw== X-Gm-Message-State: APjAAAWl5g98xDdST9MWAbEfu2M01GoQDYvQHtzWSE5rl8o935gFnlBV rn9XI1YuXLEO81WtRGAC7Iig0xfAT41bPL4Wf8CTkTvD X-Google-Smtp-Source: APXvYqxBtfeth6q8+Ek1Mh1GudM4qPrrTRBD/8um40HeCzgdJtBSwrzdCAjZw0uhvCPB/mld7iLIsnbiaf+MCG8VkDY= X-Received: by 2002:a5e:8344:: with SMTP id y4mr29158562iom.27.1579257606903; Fri, 17 Jan 2020 02:40:06 -0800 (PST) MIME-Version: 1.0 From: Ines Robles Date: Fri, 17 Jan 2020 12:39:31 +0200 Message-ID: To: roll Content-Type: multipart/alternative; boundary="000000000000ab1bdf059c539010" Archived-At: Subject: [Roll] Request for review draft-ietf-roll-turnon-rfc8138-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jan 2020 10:40:13 -0000 --000000000000ab1bdf059c539010 Content-Type: text/plain; charset="UTF-8" Dear all, We kindly request reviews for the draft draft-ietf-roll-turnon-rfc8138-02 , we understand that it is ready for Last Call. Thank you in advance, Ines and Dominique --000000000000ab1bdf059c539010 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

We kindly request reviews for= the draft=C2=A0draft-ietf-roll-turnon-rfc8138-02=C2=A0, we understand that it is read= y for Last Call.

Thank you in advance,
<= br>
Ines and Dominique
--000000000000ab1bdf059c539010-- From nobody Mon Jan 20 07:33:01 2020 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id EAD7912007A; Mon, 20 Jan 2020 07:32:54 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: roll@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: roll@ietf.org Message-ID: <157953437490.1636.11868814617347348674@ietfa.amsl.com> Date: Mon, 20 Jan 2020 07:32:54 -0800 Archived-At: Subject: [Roll] I-D Action: draft-ietf-roll-useofrplinfo-34.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jan 2020 15:32:55 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks WG of the IETF. Title : Using RPI Option Type, Routing Header for Source Routes and IPv6-in-IPv6 encapsulation in the RPL Data Plane Authors : Maria Ines Robles Michael C. Richardson Pascal Thubert Filename : draft-ietf-roll-useofrplinfo-34.txt Pages : 55 Date : 2020-01-20 Abstract: This document looks at different data flows through LLN (Low-Power and Lossy Networks) where RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) is used to establish routing. The document enumerates the cases where RFC6553 (RPI Option Type), RFC6554 (Routing Header for Source Routes) and IPv6-in-IPv6 encapsulation is required in data plane. This analysis provides the basis on which to design efficient compression of these headers. This document updates RFC6553 adding a change to the RPI Option Type. Additionally, this document updates RFC6550 defining a flag in the DIO Configuration Option to indicate about this change and updates RFC8138 as well to consider the new Option Type when the RPL Option is decompressed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-34 https://datatracker.ietf.org/doc/html/draft-ietf-roll-useofrplinfo-34 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-useofrplinfo-34 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Jan 21 02:52:03 2020 Return-Path: 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 F1C681200FF for ; Tue, 21 Jan 2020 02:52:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.com 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 KWGTE__jnglo for ; Tue, 21 Jan 2020 02:51:56 -0800 (PST) Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-oln040092254031.outbound.protection.outlook.com [40.92.254.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22FC3120091 for ; Tue, 21 Jan 2020 02:51:56 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=VoK7hUEeqRbkjWPPDkK6WTYeg4KQWxLV2DELwU7Knc4x8oSyv0LKDyjRCMc8CJyCcEVhsL4/n5QSM8l3g7Yo6ellNXbwgdNpTZtvhYMA05ia9sdbsbjSbaCtz3LoZo5xUUXbJvTUBWybr5iAhhX4VZXECOWDQ3rMQK4y9dj77xBWRCeQfhKWSBTRYUQhBzg+zVpVIdHSyNUmqxBkLEK/Hpr4TiL6899ptc3g2xT1QlyKTrYzzaEvPELbFRUgFj7OqPPd4REufnha2SDq8wb2qChwbmYL3R+py6VtNvEXiu4QBUAB0Dxo+Z2WM+kPmr/i95rQ+FzcF1UK6rZFjfToLQ== 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=d4t5sVMbPBMxgo/ykn2LRmPGjkNwZxyghneCBoGM4lc=; b=atY1nGVS+6lgd0yHwIgtLle4TqHlRnMaHobtoqF52RpLNah9ovQBBdSz/j56EpP+O5ZrRy2I8UiL0WhZ7YZflADskbM6K52hkgrmAoc3OvPW6cFw1gBL7OTVyCzzwAjHJXteiIMWu8PUoqmtUhNQ81AARI3xqYGpKUhRLdr+6yAiLRlyoDFl4xApp+fF8nTT0Sg9vR+6jzHqKFDZhduOM4pWGyFEBiZTNuDXH6R8pf5yHTpH27bA2GKwR/ArUYz62+xM8A2RPbzGt1tIISnWrU0t1scFSWSLyCKBdtRI34LFyxUWRsRPhpdBkRnfWaB1e6beLmPTqcQQditEXOWYzQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=d4t5sVMbPBMxgo/ykn2LRmPGjkNwZxyghneCBoGM4lc=; b=U+7F1fVVBEd/h7xcLQFGeaVIlLfSwqcRmXs1ChGwXuWkaBtyqhNS5jPax89p+b32Cg5Y5T6tx+O2Ahc1mTdgu1nZEqNui7AYuyk6uWwMmZ01mkiKu76thNDlopj/KZaHBo51huaek9yJxgDHSn3F+tvAcckPrcZ9VmftP5oMJ9SGhaTv/eIf8oF4T0ke91XXfjC2bCN3E0EUfRSlHyQ/Nk55YIj7leRZQjJrlrSyCFBRN9U/NdII58z18oiHcsJJhYcOPB/4Yp2hAJF/0SEBjLFTQzH30DEmb+KJbJs4wjdt8CjK9MQ0E7OIGSq08yiFndJkZPtgkfep4mXeVEhbVQ== Received: from HK2APC01FT027.eop-APC01.prod.protection.outlook.com (10.152.248.54) by HK2APC01HT240.eop-APC01.prod.protection.outlook.com (10.152.249.5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.19; Tue, 21 Jan 2020 10:51:52 +0000 Received: from BM1PR01MB2612.INDPRD01.PROD.OUTLOOK.COM (10.152.248.60) by HK2APC01FT027.mail.protection.outlook.com (10.152.248.179) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.19 via Frontend Transport; Tue, 21 Jan 2020 10:51:52 +0000 Received: from BM1PR01MB2612.INDPRD01.PROD.OUTLOOK.COM ([fe80::b82f:b3:4db6:3004]) by BM1PR01MB2612.INDPRD01.PROD.OUTLOOK.COM ([fe80::b82f:b3:4db6:3004%3]) with mapi id 15.20.2644.024; Tue, 21 Jan 2020 10:51:52 +0000 From: Rahul Jadhav To: roll Thread-Topic: [Roll] Request for review draft-ietf-roll-turnon-rfc8138-02 Thread-Index: AQHVzSKEkzxa5vgOHE60eQMA7CRaaKf09ejr Date: Tue, 21 Jan 2020 10:51:52 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:E66ABFA27C3BFA9676ADD9B1FC417A1B70B8F78D37DF14BB510275AA2D970D3D; UpperCasedChecksum:4C8D7C983F3EEF345E82AF89348EC3FE878A743D83E4B063FC179E6C823BCE78; SizeAsReceived:6868; Count:44 x-tmn: [t7UQdS4NhvQqxoo+kc6Ir7oZ9iGaufp2] x-ms-publictraffictype: Email x-incomingheadercount: 44 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: 7a8c91b2-f18a-4137-b719-08d79e5fecd0 x-ms-traffictypediagnostic: HK2APC01HT240: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 7bLanCRLOaLOTYJAEiLkL/7J5tRtnd0gu+roJZORtldvUHzV3Uqe2v82lFrlJ5h++85mUXG013Vkf3htEUuVUKnT90bmzAxXgs+dblkqnI3tbqUlBpkf264PEooe9FEBu+oYB+iiIIWZO1KzBIuFXpPVYzzejQeyQ+3k2PCHfdLVR2jrW/xaF+cQWWnINKUf0JKghry24CpKOwmUSj0qVjWcZw9mZT5My0/gQdTjKFs= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BM1PR01MB2612725A4CC01B3633EB4AB3A90D0BM1PR01MB2612INDP_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 7a8c91b2-f18a-4137-b719-08d79e5fecd0 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Jan 2020 10:51:52.7228 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: HK2APC01HT240 Archived-At: Subject: Re: [Roll] Request for review draft-ietf-roll-turnon-rfc8138-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jan 2020 10:52:02 -0000 --_000_BM1PR01MB2612725A4CC01B3633EB4AB3A90D0BM1PR01MB2612INDP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear Authors, Overall the document is very much to the point and I do not have any major = comments. Following are my comments for the draft(-02): 1. Section 5 "It results whether a parent supports RFC 8138 is not known by the child wi= th the current level of specifications, and a child cannot favor a parent b= ased on a particular support." I think the purpose of this sentence is to let know that one cannot use T f= lag as a way to know that the parent supports 8138 or not. But I am not sur= e of this. Do you think this can be rephrased? 2. A 6LR may be 8138 + this draft compliant and may want to initiate "a loc= al instance" in which case the 'T' flag needs to be set/unset. I believe th= e 6LR could use the knowledge of Global Instance to handle this. But again,= may be there is no relation here, and it is completely the choice of the I= nstance root (in this case the given 6LR) to decide this. I just wanted to = say it loud, to check if there is anything missing! 3. Section 5 "But the node is also free to refrain from joining an Instance when a param= eter is not suitable." Refrain from joining an instance is not the same as "join as a leaf". A nod= e that joins as a leaf, still is joining the instance. A node may join as a= leaf when a parameter is not suitable. (It is possible that I have complet= ely misunderstood the statement here). 4. Section 5.3 "instances operate as ships-in-the-night" ships-in-the-night? I didn't find any explanation in the given ref. After s= earching online, I think I understand :-), better to put in simple terms. Nits: 1. "network is rebooted with implicitely" implicitely -> implicitly 2. "in an homogeneous network" -> "in a homogeneous .." 3. "but MAY still joins as a leaf" -> "but MAY still join as a leaf" 4. ". when it finally" -> ". When it finally" ... Better would be to rephra= se ... "The root migrates to new OCP when it finally sets the "T" flag." 5. "distribute the uncompresses" uncompresses -> uncompressed 6. Instance 'I' is used capital in some cases, 'i' in other cases for exact= similar context. 7. The term "turn on" is used in a few places... For e.g., in security cons= iderations, "Turning the "T" flag on before..." ... Can we use ON in caps h= ere to specify the meaning appropriately? Thanks, Rahul ________________________________ From: Roll on behalf of Ines Robles Sent: Friday, January 17, 2020 10:39 AM To: roll Subject: [Roll] Request for review draft-ietf-roll-turnon-rfc8138-02 Dear all, We kindly request reviews for the draft draft-ietf-roll-turnon-rfc8138-02 , we under= stand that it is ready for Last Call. Thank you in advance, Ines and Dominique --_000_BM1PR01MB2612725A4CC01B3633EB4AB3A90D0BM1PR01MB2612INDP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Dear Authors,

Overall the document is very much to the point and I do not have any m= ajor comments.
Following are my comments for the draft(-02):

1. Section 5
"It results whether a parent supports RFC 8138 is not known by th= e child with the current level of specifications, and a child cannot favor = a parent based on a particular support."
I think the purpose of this sentence is to let know that one cannot us= e T flag as a way to know that the parent supports 8138 or not. But I am no= t sure of this. Do you think this can be rephrased?

2. A 6LR may be 8138 + this draft compliant and may want to initia= te "a local instance" in which case the 'T' flag needs to be set/= unset. I believe the 6LR could use the knowledge of Global Instance to hand= le this. But again, may be there is no relation here, and it is completely the choice of the Instance root (in this case t= he given 6LR) to decide this. I just wanted to say it loud, to check if the= re is anything missing!

3. Section 5
"But the node is also free to refrain from joining an Instance wh= en a parameter is not suitable."
Refrain from joining an instance is not the same as "join as a le= af". A node that joins as a leaf, still is joining the instance. A nod= e may join as a leaf when a parameter is not suitable. (It is possible that= I have completely misunderstood the statement here).

4. Section 5.3
"instances operate as ships-in-the-night"
ships-in-the-night? I didn't find any explanation in the given ref. Af= ter searching online, I think I understand :-), better to put in simple ter= ms.

Nits:
1. "network is rebooted with implicitely"
implicitely -> implicitly

2. "in an homogeneous network" -> "in a homogeneous = .."

3. "but MAY still joins as a leaf" -> "but MAY still= join as a leaf"

4. ". when it finally" -> ". When it finally" .= .. Better would be to rephrase
... "The root migrates to new OCP when it finally sets the "= T" flag."

5. "distribute the uncompresses"  
uncompresses -> uncompressed

6. Instance 'I' is used capital in some cases, 'i' in other cases for = exact similar context.

7. The term "turn on" is used in a few places... For e.g., i= n security considerations, "Turning the "T" flag on before..= ." ... Can we use ON in caps here to specify the meaning appropriately= ?

Thanks,
Rahul


From: Roll= <roll-bounces@ietf.org> on behalf of Ines Robles <mariainesrobles= =3D40googlemail.com@dmarc.ietf.org>
Sent: Friday, January 17, 2020 10:39 AM
To: roll <roll@ietf.org>
Subject: [Roll] Request for review draft-ietf-roll-turnon-rfc8138-02=
 
Dear all,

We kindly request reviews for the draft draft-ietf-roll-turnon-rfc8138-02 , we understand that it is ready for Last Call.

Thank you in advance,

Ines and Dominique
--_000_BM1PR01MB2612725A4CC01B3633EB4AB3A90D0BM1PR01MB2612INDP_-- From nobody Wed Jan 22 01:25:22 2020 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BAC6120013; Wed, 22 Jan 2020 01:25:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: roll-chairs@ietf.org, roll@ietf.org, dominique.barthel@orange.com, aretana.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157968512040.12295.14784920250107898750.idtracker@ietfa.amsl.com> Date: Wed, 22 Jan 2020 01:25:20 -0800 Archived-At: Subject: [Roll] roll - New Meeting Session Request for IETF 107 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 09:25:21 -0000 A new meeting session request has just been submitted by Dominique Barthel, a Chair of the roll working group. --------------------------------------------------------- Working Group Name: Routing Over Low power and Lossy networks Area Name: Routing Area Session Requester: Dominique Barthel Number of Sessions: 2 Length of Session(s): 2 Hours, 1 Hour Number of Attendees: 50 Conflicts to Avoid: Chair Conflict: anima manet 6tisch core ace lpwan Technology Overlap: rtgarea 6lo 6man lwig cbor t2trg Key Participant Conflict: rtgwg intarea People who must be present: Michael Richardson Dominique Barthel Alvaro Retana Ines Robles Resources Requested: Special Requests: One of the WG chairs will be leaving on Thursday during the day, could we please have both sessions by Wednesday night. --------------------------------------------------------- From nobody Wed Jan 22 02:13:02 2020 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E5241200A3 for ; Wed, 22 Jan 2020 02:13:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157968798112.12270.727897597131977366.idtracker@ietfa.amsl.com> Date: Wed, 22 Jan 2020 02:13:01 -0800 From: IETF Secretariat Archived-At: Subject: [Roll] Milestones changed for roll WG X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 10:13:01 -0000 Changed milestone "Initial submission of a solution to the problems due to the use of No-Path DAO Messages to the IESG", resolved as "Done". Changed milestone "Initial Submission of a proposal with uses cases for RPI, RH3 and IPv6-in-IPv6 encapsulation to the IESG", set due date to March 2020 from December 2019. Changed milestone "Initial submission of routing for RPL Leaves draft to the IESG", set due date to March 2020 from December 2019. Changed milestone "Initial submission of a root initiated routing state in RPL to the IESG", set due date to July 2020 from December 2019. URL: https://datatracker.ietf.org/wg/roll/about/ From nobody Wed Jan 22 02:18:27 2020 Return-Path: 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 CB005120074 for ; Wed, 22 Jan 2020 02:18:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.498 X-Spam-Level: X-Spam-Status: No, score=-14.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=A72hkjZ5; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=QHadGBvr 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 Yx3N2cIP5Azn for ; Wed, 22 Jan 2020 02:18:23 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8E8C7120043 for ; Wed, 22 Jan 2020 02:18:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31319; q=dns/txt; s=iport; t=1579688303; x=1580897903; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=XVbkBhpO0WR+cKI3EZZbJr3t4Aj0tpgYR22c9+H13UE=; b=A72hkjZ5ZKLyuamG0sjlqpGIrDm46Gi4xKNPe2C8q0DV7xw6t8U/1ycV L6WiiPB//FUfq3gqYrLLpKLoyh1vulMWad/B3tHd1ewEGsOwycEkuiquJ myXOqrf2CrfQ0+rlOpwbZNQMzpD+1EixQzC+71poQz82NsK5LgYwGeZ9C k=; IronPort-PHdr: =?us-ascii?q?9a23=3AcRmdNhH68FqhwHTzCqikjJ1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4z1Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0pNV?= =?us-ascii?q?cejNkO2QkpAcqLE0r+eeb2bzEwEd5efFRk5Hq8d0NSHZW2ag=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AqCQD1IChe/4gNJK1lHAEBAQEBBwE?= =?us-ascii?q?BEQEEBAEBgXuBJS9QBWxYIAQLKodYA4sGToIRgQGPHxKHXIFCgRADVAkBAQE?= =?us-ascii?q?MAQEjCgIBAYRAAoIYJDgTAgMNAQEEAQEBAgEFBG2FNwyFXgEBAQEDDAYVBhM?= =?us-ascii?q?BATAIDwIBCBEEAQEhAQYHMhQJCAIEEwgagwWBfU0DLgECDKMFAoE5iGGBdDO?= =?us-ascii?q?CfwEBBYFDQYMAGIIMAwaBOIUbgSyBWoN1GoFBP4EQAUeBTkk1PmsZAYFfAgI?= =?us-ascii?q?BAYEnOgwYBwmDDIIsjVyIVYlzjkJwCoI5hz+HaIcngkeICotihEREjGGKG5I?= =?us-ascii?q?mAgQCBAUCDgEBBYFpIoFYcBWDJ1AYDYJthRSDc4UUhT90AoEnjEgBAQ?= X-IronPort-AV: E=Sophos;i="5.70,349,1574121600"; d="scan'208,217";a="709870793" Received: from alln-core-3.cisco.com ([173.36.13.136]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Jan 2020 10:18:22 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 00MAIMrU004578 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 22 Jan 2020 10:18:22 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 22 Jan 2020 04:18:21 -0600 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 22 Jan 2020 04:18:20 -0600 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 22 Jan 2020 05:18:20 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jjM/aV+Q4fCBx3ROTciDuZQFhmxD+tUluWIJQiocO3vHLMmUYzYJJTeygGfWyeIhJdGisCc97gHxX/lLZkM2j7jXXoVRpH+gBa9a/lmEqO41YgJXvEOBZi/naB58+6QcCZewm9/qEbM65Ddu7m6HEZ4HPRrq8Q+q1n6B/LVor2AkTmLKV7XBFs2i8SQ7O3VF7x9NnONZO0KtQWRM7qpzpGhbyf25RAirk5t4KWmF5/vhoyPUDzumUySoAZ3zPjwf8R7ktMmeyEvFRg7BpbVSdQT4MO27eVyLFT+wm86S9p0rZ9NiqzxGKod5RwDzbNNIfOuMBoWM/aREDRVPxMFKcg== 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=Kc1eWPUPAKE9L6QBn/urS+CCnNt+sJh9ryGUkJThDZ0=; b=ViMekMo+VkXtcPAxeoucdk0izsaUCLaukD15nBHkoYNcCS4guWO9lCernZJXSh/aznV4suUMDt9gtDyNTS7fXwBkxvghAlqgKmuauDCsVrO3mzndWcqqH4X4lFiQtyO3K8Iq87K7nF/oJ/KVrtimMlOW0D/tnZJdtHn404+cezjlDYJMT/fLmRxjxtri23x/z/H9iOwlrszITfevgdfpsQZ6JwrikS1/GE4rl9GBWqfPrmn4Ccx09W429mpWX3zMDUTvz3E8LKsn9JVQOiEuAmmBp4UWN+HsEGSQVaxTJwtCJ54YnqGaiX22FtoOSqjX5Y0OrETzTUTsj1bVEYfgwQ== 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=Kc1eWPUPAKE9L6QBn/urS+CCnNt+sJh9ryGUkJThDZ0=; b=QHadGBvrIoZC6ch31vsydDnLlAMaC+qTw1NB8pJi9fSWHOi5yiatKgDpp1khgVt1FWi78nSy8uolq5EwLUCwX6mIQDYmWAstrlTbCXeYoO3dG9X2A/4RbV6WadBYMeVEkvMzKdUqDTOUyVkVXVY94+HGc1bqM1ZGhn5U6uAs8Tc= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4030.namprd11.prod.outlook.com (10.255.181.224) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.20; Wed, 22 Jan 2020 10:18:18 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::fd76:1534:4f9a:452a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::fd76:1534:4f9a:452a%3]) with mapi id 15.20.2644.027; Wed, 22 Jan 2020 10:18:18 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] Request for review draft-ietf-roll-turnon-rfc8138-02 Thread-Index: AQHVzSKEkzxa5vgOHE60eQMA7CRaaKf09ejrgAFmAxA= Date: Wed, 22 Jan 2020 10:17:52 +0000 Deferred-Delivery: Wed, 22 Jan 2020 10:16:57 +0000 Message-ID: References: In-Reply-To: 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: [2a01:cb1d:4ec:2200:850c:4da1:8ec9:acf4] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b5c0cebf-ae64-474b-0728-08d79f2466cc x-ms-traffictypediagnostic: MN2PR11MB4030: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 029097202E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(39860400002)(136003)(396003)(366004)(346002)(376002)(189003)(199004)(478600001)(71200400001)(9686003)(966005)(33656002)(8936002)(6916009)(52536014)(81166006)(81156014)(8676002)(5660300002)(2906002)(66574012)(6666004)(76116006)(186003)(66946007)(66446008)(66556008)(64756008)(66476007)(316002)(7696005)(55016002)(6506007)(53546011)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4030; H:MN2PR11MB3565.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: h0+beYRT00MTg7BpVpSgiaGelz+F22nKpnxl6Jn1eMjgt3uJ8A7dESESyjkG+oXVPIOwAPGN77m2rp6Ych/8MIeQGOptQ0cL5xoSIbq18qmZ4lv93x1fWo+rOTfYo0pvPNm445P0N3tDOSJGtor6pJhn2BaNbWqf6N8fNIZ2ifMtv1UQy+8+McOC2vudI6GXA5hGKDQS7+4+IinhGWWPivs3pXG8eliwrgLAbzq4T8NS5ZxC0cnFoCUywcE1TRoqU/y8MSgLC4jdXVSFmdPGuQBouB0w1ZcmvBrT8OzakImoMUkR90qyReuZpGAMLM7EurRkt8oxxokC/LTgPaGHhu662Lu8xi7PHNMvXKMPIbLcU/MkRvluAqxVzJ9Sm567tCk3jTGKnY6+hv7IWkdLrR0g9o9u1RuCcdDDwaIVZVvpO6N9TMkoZZXDWsij5S4hKQTjP0mdwatvXhZPTRY7aMN/rLIW/Ygs4nUinKzvQSVa97h8GkQuwBE7QNL9ap49QGhhkG7fuSjYotxoo1isRg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB356510BE84CF94333B09F35ED80C0MN2PR11MB3565namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: b5c0cebf-ae64-474b-0728-08d79f2466cc X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jan 2020 10:18:18.6292 (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: Agvs56P/PS80I1EgnbE8FfP/DpcgEbqCV2FR+Kbr0/e9KH4Oq5e6QmQMQ5R/etzYFLJDS7luM9MSl28uro4x0w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4030 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: alln-core-3.cisco.com Archived-At: Subject: Re: [Roll] Request for review draft-ietf-roll-turnon-rfc8138-02 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 10:18:26 -0000 --_000_MN2PR11MB356510BE84CF94333B09F35ED80C0MN2PR11MB3565namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Rahul Many thanks for your review! Li created a new repo within the ROLL github, you'll find it under https://= github.com/roll-wg Please see below: Overall the document is very much to the point and I do not have any major = comments. Following are my comments for the draft(-02): 1. Section 5 "It results whether a parent supports RFC 8138 is not known by the child wi= th the current level of specifications, and a child cannot favor a parent b= ased on a particular support." I think the purpose of this sentence is to let know that one cannot use T f= lag as a way to know that the parent supports 8138 or not. But I am not sur= e of this. Do you think this can be rephrased? You're correct. What about replacing with: " A parent propagates the "T" flag as set whether it supports RFC 8138 or not. The setting of the "T" flag can thus not be used as an indication of the support by the sender, and a child cannot favor a parent based on it. " 2. A 6LR may be 8138 + this draft compliant and may want to initiate "a loc= al instance" in which case the 'T' flag needs to be set/unset. I believe th= e 6LR could use the knowledge of Global Instance to handle this. But again,= may be there is no relation here, and it is completely the choice of the I= nstance root (in this case the given 6LR) to decide this. I just wanted to = say it loud, to check if there is anything missing! Great question, and yes. Each root is responsible to set the "T" flag based= on its own knowledge and needs, true for local and global RPL Instances. If the OF support mandates RFC 8138 then that will work. If the 6LR/root kn= ows that all participants support RFC 8138 that will work as well. Once we = have the capability draft and the 6LR/root found that all the members of th= e DODAG have the capability, that will work. What if the 6LR knows none of that? This question affects in particular the= DAO projection work. A projected path may cross over multiple DODAGS so it= cannot inherit from one. Also I gave a new look at the transition scenarios. We say that a node that= does not support RFC 8138 can act as a leaf if the 6LR un-compresses the p= ackets before delivery. Same question, how does it know? As it goes, useofr= plinfo says that external targets are not expected to support RFC 8138 sinc= e it is a RPL thing. So acting as a RUL, we know things work. Till the capability work comes in we need a separate source of knowledge (c= onfig, management) for a 6LR to know if 1) it can form a local instance wit= h the "T" flag set and 2) to deliver packets to a RAL in compressed form. I suggest to mod the section on leaf as follows: " A node that does not support can interoperat= e with a node that supports this specification in a network with RFC 8138 compre= ssion turned off. But it cannot forward compressed packets and therefore it c= annot act as a router in a network with RFC 8138 compression turned on. It ma= y remain connected to that network as a leaf and generate uncompressed pa= ckets. The leaf can receive packets if they are delivered by the parent 6LR in= the uncompressed form. This requires a knowledge by the 6LR that the leaf d= oes not support RFC 8138. A RPL-Unaware-Leaf (RUL) is an external target and by default is not expected to support RFC 8= 138. " 3. Section 5 "But the node is also free to refrain from joining an Instance when a param= eter is not suitable." Refrain from joining an instance is not the same as "join as a leaf". A nod= e that joins as a leaf, still is joining the instance. A node may join as a= leaf when a parameter is not suitable. (It is possible that I have complet= ely misunderstood the statement here). Yes that sentence is not that useful. It says that the node may decide not = to join at all. Which is true but not a scientific breakthrough. I'd rather indicate the following " [ietf-roll-useofrplinfo] indicates that the node may also join as a RUL, in which case it refrains from participating to RPL and d= epends on the 6LR to ensure connectivity regardless on the way the RPL network is oper= ated. " 4. Section 5.3 "instances operate as ships-in-the-night" ships-in-the-night? I didn't find any explanation in the given ref. After s= earching online, I think I understand :-), better to put in simple terms. What about " The two RPL Instances operate independently as specified in . " Nits: 1. "network is rebooted with implicitely" implicitely -> implicitly ok 2. "in an homogeneous network" -> "in a homogeneous ..." Ok 3. "but MAY still joins as a leaf" -> "but MAY still join as a leaf" Ok 4. ". when it finally" -> ". When it finally" .... Better would be to rephr= ase ... "The root migrates to new OCP when it finally sets the "T" flag." I'd wish to indicate clearly that they go together. What about: " The root sets the "T" flag at the time it migrates to the new OCP. " 5. "distribute the uncompresses" uncompresses -> uncompressed ok 6. Instance 'I' is used capital in some cases, 'i' in other cases for exact= similar context. Should use "RPL Instance" every time as RFC 6550 does. 7. The term "turn on" is used in a few places... For e.g., in security cons= iderations, "Turning the "T" flag on before...." ... Can we use ON in caps = here to specify the meaning appropriately? Unsure. Do we need to define "turning on"? Thanks, Rahul ________________________________ From: Roll > on behalf = of Ines Robles > Sent: Friday, January 17, 2020 10:39 AM To: roll > Subject: [Roll] Request for review draft-ietf-roll-turnon-rfc8138-02 Dear all, We kindly request reviews for the draft draft-ietf-roll-turnon-rfc8138-02 , we under= stand that it is ready for Last Call. Thank you in advance, Ines and Dominique --_000_MN2PR11MB356510BE84CF94333B09F35ED80C0MN2PR11MB3565namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Rahul

 

Many thanks for your review!

 

Li created a new repo within the ROLL github, you= 217;ll find it under https://github.com/roll-wg =

Please see below:

 

 

Overall the document is very much to the point and I do= not have any major comments.

Following are my comments for the draft(-02):

 

1. Section 5

"It results whether a parent supports RFC 8138 is = not known by the child with the current level of specifications, and a chil= d cannot favor a parent based on a particular support."

I think the purpose of this sentence is to let know tha= t one cannot use T flag as a way to know that the parent supports 8138 or n= ot. But I am not sure of this. Do you think this can be rephrased?

 

<Pascal>

You’re correct. Wha= t about replacing with:

“

A paren= t propagates the "T" flag as set whether it supports

RFC 813= 8 or not. The setting of the "T" flag can thus not be<= /p>

used as= an indication of the support by the sender, and a child

cannot = favor a parent based on it.

 

“

</Pascal>

 

2. A 6LR may be 8138 + this draft compliant and may= want to initiate "a local instance" in which case the 'T' flag n= eeds to be set/unset. I believe the 6LR could use the knowledge of Global Instance to handle this. But again, may be there is no= relation here, and it is completely the choice of the Instance root (in th= is case the given 6LR) to decide this. I just wanted to say it loud, to che= ck if there is anything missing!

 

<Pascal>=

Great question, and yes. = Each root is responsible to set the “T” flag based on its own k= nowledge and needs, true for local and global RPL Instances.

 

If the OF support mandate= s RFC 8138 then that will work. If the 6LR/root knows that all participants= support RFC 8138 that will work as well. Once we have the capability draft= and the 6LR/root found that all the members of the DODAG have the capability, that will work.

What if the 6LR knows non= e of that? This question affects in particular the DAO projection work. A p= rojected path may cross over multiple DODAGS so it cannot inherit from one.=

 

Also I gave a new look at= the transition scenarios. We say that a node that does not support RFC 813= 8 can act as a leaf if the 6LR un-compresses the packets before delivery. S= ame question, how does it know? As it goes, useofrplinfo says that external targets are not expected to support = RFC 8138 since it is a RPL thing. So acting as a RUL, we know things work.

 

Till the capability work = comes in we need a separate source of knowledge (config, management) for a = 6LR to know if 1) it can form a local instance with the “T” fla= g set and 2) to deliver packets to a RAL in compressed form.

 

I suggest to mod the sect= ion on leaf as follows:

“

 &= nbsp;  A node that does not support <xref target=3D'RFC8138'/> c= an interoperate with a

 &= nbsp;  node that supports this specification in a network with RFC 813= 8 compression

 &= nbsp;  turned off. But it cannot forward compressed packets and theref= ore it cannot

 &= nbsp;  act as a router in a network with RFC 8138 compression turned o= n. It may

 &= nbsp;  remain connected to that network as a leaf and generate uncompr= essed packets.

 &= nbsp;  The leaf can receive packets if they are delivered by the paren= t 6LR in the

 &= nbsp;  uncompressed form. This requires a knowledge by the 6LR that th= e leaf does

 &= nbsp;  not support RFC 8138.

 &= nbsp;  A RPL-Unaware-Leaf (RUL) <xref target=3D'I-D.ietf-roll-useof= rplinfo'/>

    &= nbsp; is an external target and by default is not expected to support RFC 8= 138. “

 

</Pascal>

 

3. Section 5

"But the node is also free to refrain from joining= an Instance when a parameter is not suitable."

Refrain from joining an instance is not the same as &qu= ot;join as a leaf". A node that joins as a leaf, still is joining the = instance. A node may join as a leaf when a parameter is not suitable. (It is possible that I have completely misunderstood the = statement here).

 

<Pascal>

Yes that sentence is not that useful. It says that the = node may decide not to join at all. Which is true but not a scientific brea= kthrough.

I’d rather indicate the following

“

   [ietf-roll-useofrplinfo]= indicates that the node may also

   join as a RUL, in which = case it refrains from participating to RPL and depends on the

   6LR to ensure connectivity regardless on t= he way the RPL network is operated.

 

“

</Pascal>

 

4. Section 5.3

"instances operate as ships-in-the-night"

ships-in-the-night? I didn't find any explanation in th= e given ref. After searching online, I think I understand :-), better to pu= t in simple terms.

<Pascal>

What about

“

The two RPL Instances operate indepen= dently as specified

   in <xref target=3D'RFC6550'/>.<= /o:p>

“

</Pascal>

 

 

Nits:

1. "network is rebooted with implicitely"

implicitely -> implicitly

 

ok

 

2. "in an homogeneous network" -> "in= a homogeneous ..."

 

Ok

 

3. "but MAY still joins as a leaf" -> &quo= t;but MAY still join as a leaf"

Ok

 

 

4. ". when it finally" -> ". When it = finally" .... Better would be to rephrase

... "The root migrates to new OCP when it finally = sets the "T" flag."

 

<Pascal>

I’d wish to indicate clearly that they go togethe= r. What about:

“

The root sets the "T" flag = at the time it migrates to the new OCP.

“

</Pascal>

 

5. "distribute the uncompresses"  <= /o:p>

uncompresses -> uncompressed

 

ok

 

6. Instance 'I' is used capital in some cases, 'i' in o= ther cases for exact similar context.

 

<Pascal>

Should use “RPL Instance” every time as RFC= 6550 does.

</Pascal>

 

 

7. The term "turn on" is used in a few places= ... For e.g., in security considerations, "Turning the "T" f= lag on before...." ... Can we use ON in caps here to specify the meaning appropriately?

<Pascal>

Unsure. Do we need to define “turning on”?<= o:p>

</Pascal>

 

 

Thanks,

Rahul

 

&n= bsp;

Dear all,

 

We kindly request reviews for the draft draft-ietf-roll-turnon-rfc8138-02&= nbsp;, we understand that it is ready for Last Call.

 

Thank you in advance,

 

Ines and Dominique

--_000_MN2PR11MB356510BE84CF94333B09F35ED80C0MN2PR11MB3565namp_-- From nobody Wed Jan 22 03:13:40 2020 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3AA7C12004C; Wed, 22 Jan 2020 03:13:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: roll@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: roll@ietf.org Message-ID: <157969161315.12222.13872408662179355132@ietfa.amsl.com> Date: Wed, 22 Jan 2020 03:13:33 -0800 Archived-At: Subject: [Roll] I-D Action: draft-ietf-roll-turnon-rfc8138-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 11:13:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks WG of the IETF. Title : Configuration option for RFC 8138 Authors : Pascal Thubert Li Zhao Filename : draft-ietf-roll-turnon-rfc8138-03.txt Pages : 8 Date : 2020-01-22 Abstract: This document complements RFC 8138 and dedicates a bit in the RPL configuration option defined in RFC 6550 to indicate whether RFC 8138 compression is used within the RPL Instance. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-turnon-rfc8138/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-roll-turnon-rfc8138-03 https://datatracker.ietf.org/doc/html/draft-ietf-roll-turnon-rfc8138-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-turnon-rfc8138-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Jan 22 03:18:01 2020 Return-Path: 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 84DBC120074 for ; Wed, 22 Jan 2020 03:17:59 -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=KMRlhd9B; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=T3GyypG8 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 peC-tVVj4LQu for ; Wed, 22 Jan 2020 03:17:58 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0C0B120048 for ; Wed, 22 Jan 2020 03:17:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1904; q=dns/txt; s=iport; t=1579691878; x=1580901478; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=72KpRrzgkAebLrNs8Y/523l08f0bzpBF9dcy5aFGoxI=; b=KMRlhd9BS+s9UZO73ckV2yuoCnZeoni2rimYm2UJWhbQ2KYYP9pnovpc lNEK3bhJOhmYtvQl4za7AsVww/Oboh226zGXbMhyH5UK1kTRV19VfbluY Gm2Mdo0pRvdQKDGv/YUtbIl+TABYGzliwSumSAi2ozKRKdv1kwoCqZDSj A=; IronPort-PHdr: =?us-ascii?q?9a23=3ALRn6RxDTomMKUOiHIUAcUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qs03kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuNOLqciY3BthqX15+9Hb9Ok9QS47z?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D5DQD8Lihe/5xdJa1lH4IigVRQBWx?= =?us-ascii?q?YIAQLKodYA4sFToIRkCCHboFCgRADVAkBAQEMAQEYCwoCAQGEQAKCGSQ3Bg4?= =?us-ascii?q?CAw0BAQQBAQECAQUEbYU3DIVeAQEBAQMBARAoBgEBLAwLBAIBCBEEAQEfECc?= =?us-ascii?q?LGwEBBQMCBBMIGoMFgkoDLgECDKMUAoE5iGGCJ4J/AQEFgTMCDkGCfhiCDAm?= =?us-ascii?q?BOIwWGoFBP4ERR4JMPoJkAQECAQEYgQ8cHoNAgiyvVgqCOYc/h2iHJ4JHeIc?= =?us-ascii?q?SkCaXQJImAgQCBAUCDgEBBYFoI4FYcBUaIYJsCUcYDYt0hRSFP3SBKYxIAQE?= X-IronPort-AV: E=Sophos;i="5.70,349,1574121600"; d="scan'208";a="410653366" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Jan 2020 11:17:51 +0000 Received: from XCH-ALN-007.cisco.com (xch-aln-007.cisco.com [173.36.7.17]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 00MBHp5H015025 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 22 Jan 2020 11:17:51 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-007.cisco.com (173.36.7.17) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 22 Jan 2020 05:17:50 -0600 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 22 Jan 2020 05:17:49 -0600 Received: from NAM02-BL2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 22 Jan 2020 05:17:49 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EZCPA+fxNslxyls1WzEmx6MuqAcMP/6xxZAFeZoUYURXMhTDH7Gt15qihQC4mkYOC9p6XR8R4Xndd2iMcm/UCkd8Sq7rm2Bizo2OMem+Y9CgvoawV59t+baIyLgBv1AMa/qYBiz2CNc8Ezmo+HapSaA1cNu3/AevS+Shj9Jdjq30XzCdkNIOkFjowYppz5KBYbGGoNBg5dOX2uDeuO9y5s1rEozUykuQTu9ZGSlu+fZcmh6lsdPPvE6janl5FzoYuN/3y3LbLoY8q4HcL3tku0xxF6OolHyeSqIRZNKYXfhaLkvZJ7VfGTfy3vvO0G/BFqihIBHu5SU1mSr3ZZeOdw== 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=kESmdfP7F3NUE0ZoRCVECWqiiCaknTSfy03UU/MPA1Y=; b=Y6pSWHt16U0fynS1esg86SQmOxYwYQPeszNJBAGNjmCn6rwznxgFKPsRzUFhGu/MvYDk9imVLPrfTfWr55Hg3QvyVg+gxOf5KOTlu1HdnabuhVenf2ciA50k1AC+/22GGhDK1oDqe3XhpO9moOyq3cYjfbqUdClZkJkkKQa2+K6b51VYadNrf6AOneMMY2hHI5LtI9zzakzjKrlx/Z5eP1RPtfShzbQA3X/3a2n+bq/jqA/z/i8uXO721UXOeropvW5OyyDNEgY0YMejy/f2LRfcNrIukr20PmOIKQkRaliz/K4ObBOrNBeVyE17iTTjie1QZsT+UnRT2Hqicl5uKA== 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=kESmdfP7F3NUE0ZoRCVECWqiiCaknTSfy03UU/MPA1Y=; b=T3GyypG8Q6vdhvvFrFYV3Qeo2SkPP4XNyWUbW8aBq3VG1ay6GsI6dbGJWSqZtSY5m1KfNqeo0QuWXgODzPbv9fm0xu+ENCzFWcXneReZangwbYtn6mkFjwZilJcFlpYdPvSKOSIBw+9p7yngeAJmFwl8AJy0wgHewOix80Sxglk= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4415.namprd11.prod.outlook.com (52.135.39.95) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.18; Wed, 22 Jan 2020 11:17:48 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::fd76:1534:4f9a:452a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::fd76:1534:4f9a:452a%3]) with mapi id 15.20.2644.027; Wed, 22 Jan 2020 11:17:48 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] I-D Action: draft-ietf-roll-turnon-rfc8138-03.txt Thread-Index: AQHV0RUV7hrNaK6PUE+y1oWKNpIYeqf2iBWQ Date: Wed, 22 Jan 2020 11:17:24 +0000 Deferred-Delivery: Wed, 22 Jan 2020 11:16:48 +0000 Message-ID: References: <157969161315.12222.13872408662179355132@ietfa.amsl.com> In-Reply-To: <157969161315.12222.13872408662179355132@ietfa.amsl.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: [2a01:cb1d:4ec:2200:850c:4da1:8ec9:acf4] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 60c2d426-de38-4b5e-d101-08d79f2cb693 x-ms-traffictypediagnostic: MN2PR11MB4415: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 029097202E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(376002)(39860400002)(366004)(346002)(396003)(199004)(189003)(478600001)(316002)(966005)(186003)(66574012)(6506007)(86362001)(53546011)(7696005)(52536014)(71200400001)(81156014)(81166006)(8936002)(2906002)(55016002)(9686003)(8676002)(6916009)(64756008)(5660300002)(66946007)(33656002)(76116006)(66476007)(66556008)(66446008)(6666004); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4415; 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: 8+aXHSY5BdEFaxlLZEo1C6PcFoonBsyICfrnXps90+8Jipgp+2uENsT5v0O/TcfbwGNiV7/FUxk5XVcW2oWKc8sW/slLfRUsDkdfx/QNc9F4/ARBdWFg/DbsKbxJGPYtO/XFj0/pgvpA1Sd0lJPqus/vHqK3c8V0uSiGb4G/p2AWJ/vjkMWpGDr9mNclVKDWOoz8/C3OHnADI4AMMn6E2BEHjy6F9a3TS8Fdr+HqTYRxRCIRWgyVclWTwgRNG60NkId/R8LqufSMKk25UktuIH1u1HpDSB4WhCpE/DQTsmQtlx+AzbeLfEebIlfWh2FWA35SNzn0nhqYHXKcLjyL4eUz+aV9+nhZ+Te2dP5JyOUzysN/HwQEi/oA+lifJ87NTuot57Zh3jvwfvjywcLGXcoFFcKcCzy8Pn/cmagQWTIyBRaJbVESil/wM2sGXiB1k6lUDBH/wTitTNfQyYeFcDAb/JuLrRekJ7we0mMp/KU= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 60c2d426-de38-4b5e-d101-08d79f2cb693 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jan 2020 11:17:48.6192 (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: 7OQsPqdbCi6jvw6GdMcNDF/IpS60Sj+OFSLYX5zEu6qLqX3dEYwH7hAA8xYdEMmp2aBK4sGI5Aj7zk/ripYbXw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4415 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.17, xch-aln-007.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: [Roll] FW: I-D Action: draft-ietf-roll-turnon-rfc8138-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 11:18:00 -0000 Dear all This publication addresses the first round of review by Rahul (many thanks = Rahul!). If Rahul is OK with the proposals then I believe we can move to WGLC. All the best Pascal -----Original Message----- From: Roll On Behalf Of internet-drafts@ietf.org Sent: mercredi 22 janvier 2020 12:14 To: i-d-announce@ietf.org Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-turnon-rfc8138-03.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Over Low power and Lossy networks = WG of the IETF. Title : Configuration option for RFC 8138 Authors : Pascal Thubert Li Zhao Filename : draft-ietf-roll-turnon-rfc8138-03.txt Pages : 8 Date : 2020-01-22 Abstract: This document complements RFC 8138 and dedicates a bit in the RPL configuration option defined in RFC 6550 to indicate whether RFC 8138 compression is used within the RPL Instance. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-turnon-rfc8138/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-roll-turnon-rfc8138-03 https://datatracker.ietf.org/doc/html/draft-ietf-roll-turnon-rfc8138-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-turnon-rfc8138-03 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From nobody Wed Jan 22 03:48:40 2020 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3167D1200C4 for ; Wed, 22 Jan 2020 03:48:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <157969371819.12299.9918475908454842700.idtracker@ietfa.amsl.com> Date: Wed, 22 Jan 2020 03:48:38 -0800 From: IETF Secretariat Archived-At: Subject: [Roll] Milestones changed for roll WG X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 11:48:38 -0000 Changed milestone "Initial submission to the IESG of mechanism to turn on RFC8138 compression feature within a RPL network", set state to active from review, accepting new milestone. URL: https://datatracker.ietf.org/wg/roll/about/ From nobody Wed Jan 22 07:51:59 2020 Return-Path: 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 86B0412009E for ; Wed, 22 Jan 2020 07:51:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.com 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 VFhlyCkp6Rfz for ; Wed, 22 Jan 2020 07:51:55 -0800 (PST) Received: from APC01-PU1-obe.outbound.protection.outlook.com (mail-oln040092254083.outbound.protection.outlook.com [40.92.254.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6D3D1200BA for ; Wed, 22 Jan 2020 07:51:54 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=DRs2+nZv4wG4GFXejAZ71rQuiAp5vD7nNyna/Xg6/2/oml9SEi2LtbhlSGpTTeghVePWKjGjeKkKMhIRZTnx3fPA+r1qk0DAtIk2JyQ3PI1qCd0FoMHAB8Hkort7xwQ3PO7shGXecfuWePB00nHZoNEEmbXTnysTqIvPKgkiI20+NmrIa7VtNr/8eywVIjpVy1kyc3l+dxOnp5upDXzfQ5Zant+QkA9hWWoxgq9vkhFBHotTaO+sT0FzsUyBhnTxeo2WWSNUe9dLBC9u+wcZCFVOXgfvYVWADR2UJ2fB+MrSy+yr7IjkYETlzTXBM5IgCeEXIImPTUGH8BtsSAgY6A== 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=DUp2j01yVixtLMsdxHwx4vx4UtLvpGSq0kDg5axNc8s=; b=cjdELs9URuDlQGPZrDDU5+wO5aNLCiJoTVC37+scgb/PqRUoNzmKN0j0mtcrM2D6cfBPao6FyaSGXjgM/HpXCevcT1kRMU75Vh6zxFKnPz9rXx98gpCXkxALOEH/L/8cVih/C0JO0ChEys40AqcPw82/aJInHpgTTW6d/5QQIHXg1HhAS1z8Ibrb40cdZu0bDZHgXy0Oe1ksXGfKX2Lkci6iK40WRWZGpzTc2j38S8NFI9JHgZONzJwVrP85UpWDAGbgGRODWPfqgk4hClC+GmRFdRwkUIaaWQ9uchl+HdwxvfGExLDgZmAIXxoZm3lW0l8djv32kJht+aC/FaRWHg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=DUp2j01yVixtLMsdxHwx4vx4UtLvpGSq0kDg5axNc8s=; b=K1WlLterIrgO1O76/Vn4bP0Vz4Rr0TAb1Stvb6OXDZDBgB7DaXefx/ctOIMrCeLfqueCqji9nIW+R0IhwCTdnRR8Lt10FOwu8hIotUTkFiUZWTv7EwbeRizn3fMKIPrAv8DNr29C70Ev3ASr7v1t6uz7/e+PRh7lrDvodw9KMJ/rOqFGcGGLBvXZcpphIx7UCGsu5L/fB+Lqr2c1cjlGdGoQnVTy8z/HmL5UEIyAl6O4qn4QIBj7xuuSbuHbt4JM99UdVLyPU76BVdpY8n5wL+rK0Sxm3yir6ztovLJW3tAcW6iwRV7M7AqLI8g0odQNswhpxAw88pFriX3IYo5nkQ== Received: from SG2APC01FT010.eop-APC01.prod.protection.outlook.com (10.152.250.59) by SG2APC01HT026.eop-APC01.prod.protection.outlook.com (10.152.251.190) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.19; Wed, 22 Jan 2020 15:51:51 +0000 Received: from BM1PR01MB2612.INDPRD01.PROD.OUTLOOK.COM (10.152.250.59) by SG2APC01FT010.mail.protection.outlook.com (10.152.250.134) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.18 via Frontend Transport; Wed, 22 Jan 2020 15:51:51 +0000 Received: from BM1PR01MB2612.INDPRD01.PROD.OUTLOOK.COM ([fe80::b82f:b3:4db6:3004]) by BM1PR01MB2612.INDPRD01.PROD.OUTLOOK.COM ([fe80::b82f:b3:4db6:3004%3]) with mapi id 15.20.2644.027; Wed, 22 Jan 2020 15:51:51 +0000 From: Rahul Jadhav To: "Pascal Thubert (pthubert)" , Routing Over Low power and Lossy networks Thread-Topic: [Roll] FW: I-D Action: draft-ietf-roll-turnon-rfc8138-03.txt Thread-Index: AQHV0RWfmOk8VXLtQ0GZeRxZokIgzaf20fpZ Date: Wed, 22 Jan 2020 15:51:51 +0000 Message-ID: References: <157969161315.12222.13872408662179355132@ietfa.amsl.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:9FED524E52BE04AD0C455DA2593BA033DF5EB4F71037694FF8DA86DE5694E0B9; UpperCasedChecksum:758F33FD8CA2CBAE3EDE529F3D639F8C1E5F29202F7EC4B38457CA2A8F1AB977; SizeAsReceived:7028; Count:44 x-tmn: [A3N8ifUeJ5lSPd3xRqAK9QzVU7isgBNv] x-ms-publictraffictype: Email x-incomingheadercount: 44 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: 9a1c9159-c5fd-4796-5f77-08d79f52ff18 x-ms-traffictypediagnostic: SG2APC01HT026: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Ejzm+RdakEAqchZXkeN2nmQuIdzzsMJYnCfLKEsChNU+MyrWcL1pMdkxTuRmmr2YWMvIXaolIbpJtSiSudEtAbTnxxU2ActPIRtZagt5dkJGKLF2JPeMmb/ho0ZWBcEv7zz3S1JBRU6oEpPh0fDhwgEu159AAQWep4xULQV9XBOA1y4NUfGgThSJpITVPPrMeyixQqLVk2dNWXI0vc1OaRLd1+H1Hrao1jbP7MokSlc= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 9a1c9159-c5fd-4796-5f77-08d79f52ff18 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jan 2020 15:51:51.0967 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2APC01HT026 Archived-At: Subject: Re: [Roll] FW: I-D Action: draft-ietf-roll-turnon-rfc8138-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 15:51:58 -0000 Thank you Pascal, Li for the changes.=0A= =0A= One comment based on the changes:=0A= Section 5:=0A= "A parent propagates the=A0"T" flag as set whether it supports RFC 8138 or = not."=0A= [RJ] I think this is confusing. Consider that the parent does not support R= FC 8138... according to this text a parent may propagate "T" flag =3D 1, bu= t this is not possible.=0A= =0A= Nit:=0A= "...connectivity regardless on the way the RPL..."=0A= on the way -> of the way=0A= =0A= Best,=0A= Rahul=0A= =0A= =0A= =0A= =0A= =0A= =0A= From: Roll on behalf of Pascal Thubert (pthubert) <= pthubert@cisco.com>=0A= =0A= Sent: Wednesday, January 22, 2020 11:17 AM=0A= =0A= To: Routing Over Low power and Lossy networks =0A= =0A= Subject: [Roll] FW: I-D Action: draft-ietf-roll-turnon-rfc8138-03.txt=0A= =0A= =A0=0A= =0A= =0A= Dear all=0A= =0A= =0A= =0A= This publication addresses the first round of review by Rahul (many thanks = Rahul!).=0A= =0A= If Rahul is OK with the proposals then I believe we can move to WGLC.=0A= =0A= =0A= =0A= All the best=0A= =0A= =0A= =0A= Pascal=0A= =0A= =0A= =0A= -----Original Message-----=0A= =0A= From: Roll On Behalf Of internet-drafts@ietf.org=0A= =0A= Sent: mercredi 22 janvier 2020 12:14=0A= =0A= To: i-d-announce@ietf.org=0A= =0A= Cc: roll@ietf.org=0A= =0A= Subject: [Roll] I-D Action: draft-ietf-roll-turnon-rfc8138-03.txt=0A= =0A= =0A= =0A= =0A= =0A= A New Internet-Draft is available from the on-line Internet-Drafts director= ies.=0A= =0A= This draft is a work item of the Routing Over Low power and Lossy networks = WG of the IETF.=0A= =0A= =0A= =0A= =A0=A0=A0=A0=A0=A0=A0 Title=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : Configuration o= ption for RFC 8138=0A= =0A= =A0=A0=A0=A0=A0=A0=A0 Authors=A0=A0=A0=A0=A0=A0=A0=A0 : Pascal Thubert=0A= =0A= =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= Li Zhao=0A= =0A= =A0=A0=A0=A0=A0=A0=A0 Filename=A0=A0=A0=A0=A0=A0=A0 : draft-ietf-roll-turno= n-rfc8138-03.txt=0A= =0A= =A0=A0=A0=A0=A0=A0=A0 Pages=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 8=0A= =0A= =A0=A0=A0=A0=A0=A0=A0 Date=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 2020-01-22=0A= =0A= =0A= =0A= Abstract:=0A= =0A= =A0=A0 This document complements RFC 8138 and dedicates a bit in the RPL=0A= =0A= =A0=A0 configuration option defined in RFC 6550 to indicate whether RFC 813= 8=0A= =0A= =A0=A0 compression is used within the RPL Instance.=0A= =0A= =0A= =0A= =0A= =0A= The IETF datatracker status page for this draft is:=0A= =0A= https://datatracker.ietf.org/doc/draft-ietf-roll-turnon-rfc8138/=0A= =0A= =0A= =0A= There are also htmlized versions available at:=0A= =0A= https://tools.ietf.org/html/draft-ietf-roll-turnon-rfc8138-03=0A= =0A= https://datatracker.ietf.org/doc/html/draft-ietf-roll-turnon-rfc8138-03=0A= =0A= =0A= =0A= A diff from the previous version is available at:=0A= =0A= https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-turnon-rfc8138-03=0A= =0A= =0A= =0A= =0A= =0A= Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org.=0A= =0A= =0A= =0A= Internet-Drafts are also available by anonymous FTP at:=0A= =0A= ftp://ftp.ietf.org/internet-drafts/=0A= =0A= =0A= =0A= _______________________________________________=0A= =0A= Roll mailing list=0A= =0A= Roll@ietf.org=0A= =0A= https://www.ietf.org/mailman/listinfo/roll=0A= =0A= =0A= =0A= _______________________________________________=0A= =0A= Roll mailing list=0A= =0A= Roll@ietf.org=0A= =0A= https://www.ietf.org/mailman/listinfo/roll=0A= =0A= From nobody Wed Jan 22 08:30:56 2020 Return-Path: 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 9AD67120111 for ; Wed, 22 Jan 2020 08:30:54 -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=G7OzWY8P; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=G/lQJ+qC 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 s6WAHK98DZK8 for ; Wed, 22 Jan 2020 08:30:52 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1CA7212010E for ; Wed, 22 Jan 2020 08:30:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4957; q=dns/txt; s=iport; t=1579710652; x=1580920252; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=mKmktjNfZmYpgcWgG+YSRyk8igNCL99kBQHyBE1wrpU=; b=G7OzWY8PYmPk0uJKyW6cks23LAN2+ah/mca5+zKbjtll1elBr9U/DfSN z2fXPFpZp+hYuf1d1xHw7oD9uz0xJtzbDtiGmAchh1PvuepEGaUAiL538 8FN+OJeMVPtQY59QVsfTJRDLVb2dJii3V+e9zQKTD3EzYtyMcyCW7Z+FN I=; IronPort-PHdr: =?us-ascii?q?9a23=3A26JCJx0/SokP2mA0smDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxKGt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQEVH7MfTndTASF8VZX1gj9Ha+YgBY?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CTEgAneChe/5RdJa1lHgELHINPUAV?= =?us-ascii?q?sWCAECyoKh04DiwVOghGYDoFCgRADVAkBAQEMAQEYCwoCAQGEQAKCGiQ4EwI?= =?us-ascii?q?DDQEBBAEBAQIBBQRthTcMhV4BAQEBAwEBEBUZAQEsDAsEAgEIDgMEAQEvJws?= =?us-ascii?q?dCAIEEwgagn8EAoJKAy4BAgELpBkCgTmIYYF0M4J/AQEFgTMCDkGCdxiCDAm?= =?us-ascii?q?BOIUbhnsagUE/gRFHgkw+gmQBAQIBARiBDxwFGYNAgiyXNYhvjzIKgjmHP48?= =?us-ascii?q?Pgkd4hxKQJo5eiGKPG0yCPwIEAgQFAg4BAQWBaSINgUtwFRohgmwJRxgNiAG?= =?us-ascii?q?Dc4UUhT90gSmLMwGBDwEB?= X-IronPort-AV: E=Sophos;i="5.70,350,1574121600"; d="scan'208";a="411020590" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 22 Jan 2020 16:30:51 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 00MGUphu017828 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 22 Jan 2020 16:30:51 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 22 Jan 2020 10:30:50 -0600 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 22 Jan 2020 10:30:49 -0600 Received: from NAM11-CO1-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; Wed, 22 Jan 2020 10:30:49 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hvlKU+sd+ztnoU0aDv9Fq5TEflPCWEemP7VGeeFy6KWrCnLBM/S2syuMsfvckpUquEP9cxC1VCEmtf9CjlqEB7r6dvpq5Ma9dYEQ3KHlmd7uZR1X2Q0CR8FJIe952nDYUlLfOy2CgvSebBqNGKKM87RsPOhCRZHxWwlq1xt1ZapadrBsj3sE9Opsclb57QeCnZp24UoJYf9fcNk0cVbCdUva1tjLIDc5ObTBR4nGoWH8R1J+4tI0xAjkj7h5tYIpFj5K8ctvRTU/4WmiJirgBZsb9FTNb4q3va7dloOsIXOogwI9VdPrsrWfVRDNJEDimCARNQ/9zbK2Icy46jdlKQ== 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=7DUKYLuxoqoK6fzCUchBF/ks2p379UKCCYufqAgRxqo=; b=B26wMLC6WCFerv3+EhZFxj1XYGfLf5NkwURuiTOF/dNnfP+Hle1rlB4BidUX/1bHAP/dS0da82n6tXKts6Pg+Qc4OnxQoMRVgPL67g624bjkNiAXskJG+/LreDIzWHfz3lwjU9/gt/nRoiJO+x3Mk7z3uuopYRja0wik1PFFDCDdTEzCS8dKGrHACk8BnhE948p2vjYncKmQjdxFbF0xmtaKwDuO2MLY5jcoIxMV2urSDnLCmMP8ShlUKqfusN9IB5Q7ZsVY927dWV3fNNXknu173b9+SHAau6hrV79lhSSw7BqzDR09YqPVxhyKxaJrKG1Z8hz42S3etwdq8KVChQ== 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=7DUKYLuxoqoK6fzCUchBF/ks2p379UKCCYufqAgRxqo=; b=G/lQJ+qCCsRZMsnS3pzDPDci5gqNCLYBzmd2wXe03qXbo6DJu7LdwCbRMlbhE3THfjDWJrWeeM5pInoz3Bn6tMtNacIKN5WH/QKCbZGdVe3X0fHESvEWq/PfAoDNx2PayqoKE586L7mglUTe2ZHQ5ndy0fMnqjqvynuN7NGZfP8= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3598.namprd11.prod.outlook.com (20.178.252.28) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.20; Wed, 22 Jan 2020 16:30:48 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::fd76:1534:4f9a:452a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::fd76:1534:4f9a:452a%3]) with mapi id 15.20.2644.027; Wed, 22 Jan 2020 16:30:48 +0000 From: "Pascal Thubert (pthubert)" To: Rahul Jadhav , "Routing Over Low power and Lossy networks" Thread-Topic: [Roll] FW: I-D Action: draft-ietf-roll-turnon-rfc8138-03.txt Thread-Index: AQHV0TvsvIsYf30Beka9tlsCQBUT/6f22UEg Date: Wed, 22 Jan 2020 16:30:48 +0000 Deferred-Delivery: Wed, 22 Jan 2020 16:14:57 +0000 Message-ID: References: <157969161315.12222.13872408662179355132@ietfa.amsl.com>, In-Reply-To: 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: [2.15.172.153] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3f287a73-99ef-4932-7001-08d79f58705d x-ms-traffictypediagnostic: MN2PR11MB3598: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-forefront-prvs: 029097202E x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(376002)(396003)(346002)(366004)(39860400002)(136003)(189003)(199004)(5660300002)(66574012)(66946007)(76116006)(2906002)(52536014)(110136005)(316002)(966005)(8676002)(6506007)(81166006)(81156014)(53546011)(7696005)(26005)(66556008)(9686003)(86362001)(66446008)(66476007)(478600001)(55016002)(33656002)(64756008)(186003)(8936002)(71200400001); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3598; H:MN2PR11MB3565.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: T0Gij4v8Tr/v33mfbkYtAylme7jFPRKsvCzkhXfNYVnKVNSf3PwsiMogJ6aGbYgsne0Z8bPR7OaNutEzdmxkKC6iOBCKPEbfIwmYYw47KhhJf2LtPUHvMSzsvooi65jMyBIIN1XEVSO125qxnu0RdgehU1G9bXZAkhXNIbHx0+wDP/4Pf9r6p4NgE2e/HYs0uwWQuDaFA8D4C0pzqeSjRykbpbtw2xZixfczyxTtRqGTvmM5ZWf0fx6VorBnSMCSqEsOXDXU9cjWp9/gyf7IGR6GDCU+g49ba7MAukWr+Dar+Fz72DCqjRIx51LAx7C44Xbkh+kNfgMAFN4u1/qA4JqCop3wqxgsMaEk4T9I9lKS+s4omzvAK4fTetw52qp123ExGq3HqF+tk7ljFqZIGLbpOkh6eNZ+U0mwllfsiFfiCgCGVF0CdAnR7OijoNbEvNIYzLBVJs1k1JstTNNV9ocqCFACQtLBVGB6KM9eK9IiECC1FTvlodBLqSkyWytKqD2lznT/6drVQ/N9koYy8A== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 3f287a73-99ef-4932-7001-08d79f58705d X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jan 2020 16:30:48.5845 (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: STCH+yTl7ESDdBCrqPOmbYPjJCp/tN+RQrWfwQQKYpgfhOJ2BwTDVYgRWmOJ+gpJpx7rpApBScqNuyxGRrfQnA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3598 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: rcdn-core-12.cisco.com Archived-At: Subject: Re: [Roll] FW: I-D Action: draft-ietf-roll-turnon-rfc8138-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 16:30:55 -0000 Hello Rahul The idea is that the parent copies the configuration bits unchanged as part= of the propagation of the DIO message. >From RFC 6550: " This information is configured at the DO= DAG root and distributed throughout the DODAG with the DODAG Configuration option. Nodes other than the DODAG root MUST NOT modify this information when propagating the DODAG Configuration option. " So the parent propagates the configuration option unchanged in its DIO with= possibly the "T" flag set even if the parent cannot understand what that m= eans. Are we in sync or do I miss something? Should I reword? On the side, I'll be changing the security section to use set and reset for= the "T" flag as opposed to turn on per your comment earlier.Of that works = for you it will be in the next publication, you may already look at it in t= he ROLL github repo. Also applied your new nit. Many thanks again : ) Pascal > -----Original Message----- > From: Rahul Jadhav > Sent: mercredi 22 janvier 2020 16:52 > To: Pascal Thubert (pthubert) ; Routing Over Low > power and Lossy networks > Subject: Re: [Roll] FW: I-D Action: draft-ietf-roll-turnon-rfc8138-03.txt >=20 > Thank you Pascal, Li for the changes. >=20 > One comment based on the changes: > Section 5: > "A parent propagates the=A0"T" flag as set whether it supports RFC 8138 o= r not." > [RJ] I think this is confusing. Consider that the parent does not support= RFC > 8138... according to this text a parent may propagate "T" flag =3D 1, but= this is > not possible. >=20 > Nit: > "...connectivity regardless on the way the RPL..." > on the way -> of the way >=20 > Best, > Rahul >=20 >=20 >=20 >=20 >=20 >=20 > From: Roll on behalf of Pascal Thubert (pthubert) > >=20 > Sent: Wednesday, January 22, 2020 11:17 AM >=20 > To: Routing Over Low power and Lossy networks >=20 > Subject: [Roll] FW: I-D Action: draft-ietf-roll-turnon-rfc8138-03.txt >=20 >=20 >=20 >=20 > Dear all >=20 >=20 >=20 > This publication addresses the first round of review by Rahul (many thank= s > Rahul!). >=20 > If Rahul is OK with the proposals then I believe we can move to WGLC. >=20 >=20 >=20 > All the best >=20 >=20 >=20 > Pascal >=20 >=20 >=20 > -----Original Message----- >=20 > From: Roll On Behalf Of internet-drafts@ietf.org >=20 > Sent: mercredi 22 janvier 2020 12:14 >=20 > To: i-d-announce@ietf.org >=20 > Cc: roll@ietf.org >=20 > Subject: [Roll] I-D Action: draft-ietf-roll-turnon-rfc8138-03.txt >=20 >=20 >=20 >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. >=20 > This draft is a work item of the Routing Over Low power and Lossy network= s > WG of the IETF. >=20 >=20 >=20 > =A0=A0=A0=A0=A0=A0=A0 Title=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : Configuration= option for RFC 8138 >=20 > =A0=A0=A0=A0=A0=A0=A0 Authors=A0=A0=A0=A0=A0=A0=A0=A0 : Pascal Thubert >=20 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0 Li Zhao >=20 > =A0=A0=A0=A0=A0=A0=A0 Filename=A0=A0=A0=A0=A0=A0=A0 : draft-ietf-roll-tur= non-rfc8138-03.txt >=20 > =A0=A0=A0=A0=A0=A0=A0 Pages=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 8 >=20 > =A0=A0=A0=A0=A0=A0=A0 Date=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 : 2020-01-22 >=20 >=20 >=20 > Abstract: >=20 > =A0=A0 This document complements RFC 8138 and dedicates a bit in the RPL >=20 > =A0=A0 configuration option defined in RFC 6550 to indicate whether RFC 8= 138 >=20 > =A0=A0 compression is used within the RPL Instance. >=20 >=20 >=20 >=20 >=20 > The IETF datatracker status page for this draft is: >=20 > https://datatracker.ietf.org/doc/draft-ietf-roll-turnon-rfc8138/ >=20 >=20 >=20 > There are also htmlized versions available at: >=20 > https://tools.ietf.org/html/draft-ietf-roll-turnon-rfc8138-03 >=20 > https://datatracker.ietf.org/doc/html/draft-ietf-roll-turnon-rfc8138-03 >=20 >=20 >=20 > A diff from the previous version is available at: >=20 > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-turnon-rfc8138-03 >=20 >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. >=20 >=20 >=20 > Internet-Drafts are also available by anonymous FTP at: >=20 > ftp://ftp.ietf.org/internet-drafts/ >=20 >=20 >=20 > _______________________________________________ >=20 > Roll mailing list >=20 > Roll@ietf.org >=20 > https://www.ietf.org/mailman/listinfo/roll >=20 >=20 >=20 > _______________________________________________ >=20 > Roll mailing list >=20 > Roll@ietf.org >=20 > https://www.ietf.org/mailman/listinfo/roll From nobody Wed Jan 22 09:13:39 2020 Return-Path: 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 25F8B12010E for ; Wed, 22 Jan 2020 09:13:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outlook.com 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 nzCEdIp_Uqfj for ; Wed, 22 Jan 2020 09:13:34 -0800 (PST) Received: from APC01-HK2-obe.outbound.protection.outlook.com (mail-oln040092255045.outbound.protection.outlook.com [40.92.255.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 053FA12016E for ; Wed, 22 Jan 2020 09:13:33 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ehB8y01XUwzN0G4bjicm3eW38dytDeKmXlS06KBfmPeB0UEsvk5nXvNNXFfrVItYMBBx1PcugaZ7look0o5PpLhKhtYdxNRJP7NajNlQQNFqUbJu3jrfXu7bbJwsHHO+SqU9iUcZjW6A8KVaAUKjIDAAknsrROSLFyugOUf2Fij/uipnf/uSfTrbb25ZoLDwsSHcHu+OrUSY8TBvOqLYuTIXGLMBINuVE3XD3xh/QwjjnQiycssPRnUZUsyk6YO+zA5UU4KzLqLAxbQ+wEB4q9dxiRdayxe3DAd6IAPOHA8mAdi6rIUsy6CuuHT/tKmGNbZ3wKz1MzTV8nP+3GbfGg== 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=qoh14AKpSR1o307KgMYGw17teaczMJvTsjPSZktT4pE=; b=ZzWcQDUe9Vi2DKtxsJCsjZSsgPRtqJWM/7CHx5q8DfjJSwrvWBh0f6Mn5ZHqFccSNekx10OvQ19updEtz6dpHs6+TavgrIEuyPxSGZWvIkzsufE8CNLd8VzuNiHGMfXcHeTNAHuemF5KWAWpKoJa2hVIC/BSOS5NnJKp+yiCTpyFXeTHz1h5b8D4PFsNvkRbHt6H4tBohdkA0VcSJ20NALZ8LGACdTT16ZOBgJn/stK4UDqVOKTxYC9DFxF/urXSctItFPbtEYmF9mDcdOO9ilzLgu0gXFMRRVGq1knJs6G6GbbOmBEEsXpdAcNywXmA5EsNHfOIHlpvifXyRyojOA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qoh14AKpSR1o307KgMYGw17teaczMJvTsjPSZktT4pE=; b=WizOzj00yNRJit7kIRBJG049pQU/uH5yew2sCMFegMUuQy3847aBArlKqHhJT+72CsnegnLXvTJopBfMJSMpEtVUfKkX65sY0vWF2j81NCFM9FKzIiPxcFcnGCCyebNe9S9BzTOY+r+mm2UTkX6/Z+Yvko9UtprK58f4yR16hdCaouYyxZb+VsZNU5q5ljxiDsaS8ihQhQTH76niqjeKmOkJq0UBEX6M4JqqjLOvg8fmPJNafrOa1ijlXFjIAboJTw9795qcNyBpyumi6N8rHHYxmJVT8dKLqhcPjNjB6JDOAr7csMuiN+0W6H93jFQmGc8uRbJhmVPw+cL9hwNNzQ== Received: from SG2APC01FT007.eop-APC01.prod.protection.outlook.com (10.152.250.59) by SG2APC01HT122.eop-APC01.prod.protection.outlook.com (10.152.251.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.19; Wed, 22 Jan 2020 17:13:31 +0000 Received: from BM1PR01MB2612.INDPRD01.PROD.OUTLOOK.COM (10.152.250.52) by SG2APC01FT007.mail.protection.outlook.com (10.152.250.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.18 via Frontend Transport; Wed, 22 Jan 2020 17:13:31 +0000 Received: from BM1PR01MB2612.INDPRD01.PROD.OUTLOOK.COM ([fe80::b82f:b3:4db6:3004]) by BM1PR01MB2612.INDPRD01.PROD.OUTLOOK.COM ([fe80::b82f:b3:4db6:3004%3]) with mapi id 15.20.2644.027; Wed, 22 Jan 2020 17:13:31 +0000 From: Rahul Jadhav To: "Pascal Thubert (pthubert)" , Routing Over Low power and Lossy networks Thread-Topic: [Roll] FW: I-D Action: draft-ietf-roll-turnon-rfc8138-03.txt Thread-Index: AQHV0RWfmOk8VXLtQ0GZeRxZokIgzaf20fpZgAAOdQCAAAJB+w== Date: Wed, 22 Jan 2020 17:13:30 +0000 Message-ID: References: <157969161315.12222.13872408662179355132@ietfa.amsl.com>, , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-incomingtopheadermarker: OriginalChecksum:78C953BE20494C3B3B07928541C22C66B2B3F2751CFE4072260185CEF5AD35F6; UpperCasedChecksum:E4EA1B854E95FAA849CB19E9D39C66C2D446E24A14203523EF5BAEB3ED6392F2; SizeAsReceived:7202; Count:44 x-tmn: [w5JpEWnSxc8EScD6277egGyAulZQz/4v] x-ms-publictraffictype: Email x-incomingheadercount: 44 x-eopattributedmessage: 0 x-ms-office365-filtering-correlation-id: ae9f32f4-df72-4b7c-7cc9-08d79f5e679d x-ms-traffictypediagnostic: SG2APC01HT122: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: kEWRPAcrjhiJFk/MxvuXtVWPTJJMoWP4kia4wtORx1YyqTXFXBxOq/VBJgMZwFBS4Q7bge9y+QoY2FAimD87rk/tqlG8kAjKp/el9aAHpVXSR1mASF+z3v4aN8OrnqoOUM8ObRHiZR0RmD9qhI/cl7zq3du/beEHVPF43MRdlkH8k7+OF5CMnYaPFVBjSLyqKvHHXxo3CyfTcd7WYku24OQPEv+oK1Iwakz80Q6ax/M= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BM1PR01MB2612FFD94F2A1FBB59CA7F9EA90C0BM1PR01MB2612INDP_" MIME-Version: 1.0 X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: ae9f32f4-df72-4b7c-7cc9-08d79f5e679d X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 22 Jan 2020 17:13:31.0011 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Internet X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2APC01HT122 Archived-At: Subject: Re: [Roll] FW: I-D Action: draft-ietf-roll-turnon-rfc8138-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jan 2020 17:13:37 -0000 --_000_BM1PR01MB2612FFD94F2A1FBB59CA7F9EA90C0BM1PR01MB2612INDP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I think I got the point here. But I have one question, Assume a 6LR who does not support 8138 and does not support this draft. If = this happens then that link (in which the 6LR is part) won't work for compr= essed source-routed traffic. Ideally, the root will set the T flag only when it knows that all the nodes= support 8138. But still, it would be better to tell the reader of this sce= nario and let know of the dire consequences. [Pascal] On the side, I'll be changing the security section to use set and = reset for the "T" flag as opposed to turn on per your comment earlier.Of th= at works for you it will be in the next publication, you may already look a= t it in the ROLL github repo. [RJ] Works for me. Thanks, Best, Rahul > -----Original Message----- > From: Rahul Jadhav > Sent: mercredi 22 janvier 2020 16:52 > To: Pascal Thubert (pthubert) ; Routing Over Low > power and Lossy networks > Subject: Re: [Roll] FW: I-D Action: draft-ietf-roll-turnon-rfc8138-03.txt > > Thank you Pascal, Li for the changes. > > One comment based on the changes: > Section 5: > "A parent propagates the "T" flag as set whether it supports RFC 8138 or = not." > [RJ] I think this is confusing. Consider that the parent does not support= RFC > 8138... according to this text a parent may propagate "T" flag =3D 1, but= this is > not possible. > > Nit: > "...connectivity regardless on the way the RPL..." > on the way -> of the way > > Best, > Rahul > > > > > > > From: Roll on behalf of Pascal Thubert (pthubert) > > > Sent: Wednesday, January 22, 2020 11:17 AM > > To: Routing Over Low power and Lossy networks > > Subject: [Roll] FW: I-D Action: draft-ietf-roll-turnon-rfc8138-03.txt > > > > > Dear all > > > > This publication addresses the first round of review by Rahul (many thank= s > Rahul!). > > If Rahul is OK with the proposals then I believe we can move to WGLC. > > > > All the best > > > > Pascal > > > > -----Original Message----- > > From: Roll On Behalf Of internet-drafts@ietf.org > > Sent: mercredi 22 janvier 2020 12:14 > > To: i-d-announce@ietf.org > > Cc: roll@ietf.org > > Subject: [Roll] I-D Action: draft-ietf-roll-turnon-rfc8138-03.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > > This draft is a work item of the Routing Over Low power and Lossy network= s > WG of the IETF. > > > > Title : Configuration option for RFC 8138 > > Authors : Pascal Thubert > > Li Zhao > > Filename : draft-ietf-roll-turnon-rfc8138-03.txt > > Pages : 8 > > Date : 2020-01-22 > > > > Abstract: > > This document complements RFC 8138 and dedicates a bit in the RPL > > configuration option defined in RFC 6550 to indicate whether RFC 8138 > > compression is used within the RPL Instance. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-roll-turnon-rfc8138/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-roll-turnon-rfc8138-03 > > https://datatracker.ietf.org/doc/html/draft-ietf-roll-turnon-rfc8138-03 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-turnon-rfc8138-03 > > > > > > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > 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 --_000_BM1PR01MB2612FFD94F2A1FBB59CA7F9EA90C0BM1PR01MB2612INDP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I think I got the point here. But I have one question,

Assume a 6LR who does not support 8138 and does not support this draft. If = this happens then that link (in which the 6LR is part) won't work for compr= essed source-routed traffic.
Ideally, the root will set the T flag only when it knows that all the nodes= support 8138. But still, it would be better to tell the reader of this sce= nario and let know of the dire consequences.

[Pascal] On the side, I'll be changing the securit= y section to use set and reset for the "T" flag as opposed to tur= n on per your comment earlier.Of that works for you it will be in the next = publication, you may already look at it in the ROLL github repo.

[RJ] Works for me. Thanks,

Best,
Rahul


> -----Original Message-----
> From: Rahul Jadhav <nyrahul@outlook.com>
> Sent: mercredi 22 janvier 2020 16:52
> To: Pascal Thubert (pthubert) <pthubert@cisco.com>; Routing Over= Low
> power and Lossy networks <roll@ietf.org>
> Subject: Re: [Roll] FW: I-D Action: draft-ietf-roll-turnon-rfc8138-03.= txt
>
> Thank you Pascal, Li for the changes.
>
> One comment based on the changes:
> Section 5:
> "A parent propagates the "T" flag as set whether i= t supports RFC 8138 or not."
> [RJ] I think this is confusing. Consider that the parent does not supp= ort RFC
> 8138... according to this text a parent may propagate "T" fl= ag =3D 1, but this is
> not possible.
>
> Nit:
> "...connectivity regardless on the way the RPL..."
> on the way -> of the way
>
> Best,
> Rahul
>
>
>
>
>
>
> From: Roll <roll-bounces@ietf.org> on behalf of Pascal Thubert (= pthubert)
> <pthubert@cisco.com>
>
> Sent: Wednesday, January 22, 2020 11:17 AM
>
> To: Routing Over Low power and Lossy networks <roll@ietf.org> >
> Subject: [Roll] FW: I-D Action: draft-ietf-roll-turnon-rfc8138-03.txt<= br> >
>
>
>
> Dear all
>
>
>
> This publication addresses the first round of review by Rahul (many th= anks
> Rahul!).
>
> If Rahul is OK with the proposals then I believe we can move to WGLC.<= br> >
>
>
> All the best
>
>
>
> Pascal
>
>
>
> -----Original Message-----
>
> From: Roll <roll-bounces@ietf.org> On Behalf Of internet-drafts@= ietf.org
>
> Sent: mercredi 22 janvier 2020 12:14
>
> To: i-d-announce@ietf.org
>
> Cc: roll@ietf.org
>
> Subject: [Roll] I-D Action: draft-ietf-roll-turnon-rfc8138-03.txt
>
>
>
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts dir= ectories.
>
> This draft is a work item of the Routing Over Low power and Lossy netw= orks
> WG of the IETF.
>
>
>
>         Title   &nbs= p;       : Configuration option for RFC 8138<= br> >
>         Authors   &n= bsp;     : Pascal Thubert
>
>            &nbs= p;            &= nbsp; Li Zhao
>
>         Filename   &= nbsp;    : draft-ietf-roll-turnon-rfc8138-03.txt
>
>         Pages   &nbs= p;       : 8
>
>         Date    = ;        : 2020-01-22
>
>
>
> Abstract:
>
>    This document complements RFC 8138 and dedicates a bit in= the RPL
>
>    configuration option defined in RFC 6550 to indicate whet= her RFC 8138
>
>    compression is used within the RPL Instance.
>
>
>
>
>
> The IETF datatracker status page for this draft is:
>
> https://datatracker.ietf.org/doc/draft-ietf-roll-turnon-rfc8138/
>
>
>
> There are also htmlized versions available at:
>
> https://tools.ietf.org/html/draft-ietf-roll-turnon-rfc8138-03
>
> https://datatracker.ietf.org/doc/html/draft-ietf-roll-turnon-rfc8138-03=
>
>
>
> A diff from the previous version is available at:
>
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-turnon-rfc8138-03 >
>
>
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org. >
>
>
> Internet-Drafts are also available by anonymous FTP at:
>
> ftp://ftp.i= etf.org/internet-drafts/
>
>
>
> _______________________________________________
>
> Roll mailing list
>
> Roll@ietf.org
>
> http= s://www.ietf.org/mailman/listinfo/roll
>
>
>
> _______________________________________________
>
> Roll mailing list
>
> Roll@ietf.org
>
> http= s://www.ietf.org/mailman/listinfo/roll

--_000_BM1PR01MB2612FFD94F2A1FBB59CA7F9EA90C0BM1PR01MB2612INDP_-- From nobody Thu Jan 23 08:42:33 2020 Return-Path: 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 D94F7120902 for ; Thu, 23 Jan 2020 08:42:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.497 X-Spam-Level: X-Spam-Status: No, score=-14.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=iAGpw93m; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ATRjsns5 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 lDVkae1YO22q for ; Thu, 23 Jan 2020 08:42:24 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFCBD1208FF for ; Thu, 23 Jan 2020 08:42:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30713; q=dns/txt; s=iport; t=1579797743; x=1581007343; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=BZprrM00YUvN0TYeDX+M8iI7tm/s54CMA5Vc3eg9omM=; b=iAGpw93mK9WmK0T0cpQmySP35+IAo0wVlj0uM1gJMAO3xdvSC0HjUW1d WBAeAMHEQ187KGwKHSYa7sGnf7DkPA+aYeLLJ+kgrFlZp/3DDx6XA4xI/ P86ZdzzbqJtBHo2nofXcWicR7bZHgo5zYWYA7MV8Y5AOdFSlFk7Xng8S2 c=; IronPort-PHdr: =?us-ascii?q?9a23=3Ad1r0ghD5g4fCt02p7MwfUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qs03kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuNOLqciY3BthqX15+9Hb9Ok9QS47z?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BgEwA2zCle/49dJa1lHQEBAQkBEQU?= =?us-ascii?q?FAYF7gSUBLlAFbA9JIAQLKodYA4sNToIRmA+BQoEQA1AECQEBAQwBARgBCgo?= =?us-ascii?q?CAQGEQAKCHiQ4EwIDDQEBBAEBAQIBBQRthTcMhV4BAQEBAwEBEBUGEwEBLAw?= =?us-ascii?q?LBAIBCA4DBAEBIQEGBycLFAkIAgQTCBqCfwQCgX1NAy4BAgyhVgKBOYhhgXQ?= =?us-ascii?q?zgn8BAQWBMwIOQYMDGIIMCYE4hRuBLYFag3UagUE/gRFHUX1+PoJkAQECAQE?= =?us-ascii?q?YgQ8cBAEZKwmDDIIsjVyIV4lzjzIKgjmHQI8Pgkd4hxKQJo5eiGKSJgIEAgQ?= =?us-ascii?q?FAg4BAQWBaSINgUtwFRohgmwJRxgNiAGDc4UUhT90gSmMUwEB?= X-IronPort-AV: E=Sophos;i="5.70,354,1574121600"; d="scan'208,217";a="470187121" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Jan 2020 16:42:20 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 00NGgKR5024922 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 23 Jan 2020 16:42:21 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 23 Jan 2020 10:42:20 -0600 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 23 Jan 2020 10:42:19 -0600 Received: from NAM11-DM6-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, 23 Jan 2020 10:42:19 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kmj586ed5qLH9qo2xon6462JGWFS/HTZwmNttOCWDkMZURMOJ9COe5A/qxTNVfpFlaEfaiWty2igdEqPNC1HctAj/kESdlfMuR/wZuTtUtH0mMigTXd8sClpYbxMRkRNqF8W5wTiZOjc+YZbWtwV8ns/lfFh7Bn9RfRzVjzP3W1wfGrD21VdWCQWDN7EJs679wJA3Wq2wKPQ+ABXm8gYsb5ZYXE+2YDVjslFjFy2sF7E/ozFVyjco4nyHU61IcTiRZzy9dwDwj/XW9YIIIn/xIdWbWR7z5tHF38dBx5H6Ww5Xoa+t6yYV4BoZZpUo6xawdPs9naICpdeo6drEnZItg== 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=wwmHzYh6XUy7+QohMWYtV0Wir0YcycxFTZq9PrnqVjQ=; b=g2woAMcU8ifSm6fq27a18ja9yPXzVs6BKk44Kixtp+7Aa6I4u0yxiGFUIjJVlzfEAWN7YlI6xyHavXTbq7Ekix1cP+EhT3jiW3I+wASgkQtW9R5CCv7d4jtvueisDOBwdfOKUoEPt1RQSnRNFustLtlIvDfufFfCb5xd8eOcp8zEad5GYmsTwAfBhTOvh17s1/JYn4scxkWAavEZlbi4SF62bGXwHQtC8V9TGUkqRQfhtGyW8W+OAKYBnkVjmjET2zzFzWPz9fRiHjVKM6vnybEaBxtSHw3XgKxJNmjnW5RInT/QCbJiBiANTpq3w7E6VX24sZ0iugBLf++hcwNFKw== 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=wwmHzYh6XUy7+QohMWYtV0Wir0YcycxFTZq9PrnqVjQ=; b=ATRjsns5mV7dXQcMo34uCWGdYfCan/ur+fh5K3BBIlBwzZGeoilLCwKsCadP4FhWTrvBxzlp5HaFtXqDsoY1YlI+A0NiD+JNIztemUDOfnfmRK9/KYOrHkzZ1j5L4PrrsUneFtXfMVgMLMTHBP+uWKzXUA1dExnFv1xNqvtdWjI= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4239.namprd11.prod.outlook.com (52.135.39.84) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2644.19; Thu, 23 Jan 2020 16:42:18 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::fd76:1534:4f9a:452a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::fd76:1534:4f9a:452a%3]) with mapi id 15.20.2644.027; Thu, 23 Jan 2020 16:42:18 +0000 From: "Pascal Thubert (pthubert)" To: Rahul Jadhav , "Routing Over Low power and Lossy networks" Thread-Topic: [Roll] FW: I-D Action: draft-ietf-roll-turnon-rfc8138-03.txt Thread-Index: AQHV0TvsvIsYf30Beka9tlsCQBUT/6f22UEggAAS0ACAAW0VUA== Date: Thu, 23 Jan 2020 16:42:15 +0000 Deferred-Delivery: Thu, 23 Jan 2020 16:42:12 +0000 Message-ID: References: <157969161315.12222.13872408662179355132@ietfa.amsl.com>, , In-Reply-To: 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: [2a01:cb1d:4ec:2200:b566:6c8a:dd3c:64bb] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 370057fe-4416-4584-0891-08d7a02335dd x-ms-traffictypediagnostic: MN2PR11MB4239: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 029174C036 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(189003)(199004)(6666004)(45080400002)(110136005)(33656002)(86362001)(2906002)(8676002)(81166006)(55016002)(498600001)(81156014)(186003)(66574012)(9686003)(7696005)(53546011)(6506007)(966005)(8936002)(52536014)(66946007)(5660300002)(76116006)(66556008)(64756008)(66476007)(66446008)(71200400001); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4239; H:MN2PR11MB3565.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: tpnpoLPdoQ0IvC/ycRxHM+DkjzHtcZnKsmcSm5//44cAIg4yUTLhs4iIbh/aE3Ak/yTzSJUelY/P8cuxiTH167+i8+yp23BjTpoN2hbJ/LqyIfQalP1Ae1Yb5J1jVNr9KZyK8C9WOKbM7l0wlxdj02G+Q2AmBzu+m/Wf5QfOv/cW5okDJA+ftM5ydW3sEhdx11xrRlT317td1Yz+/Wspxb/u+VRmDLVofT6RSH3Cfa5zsBJoc98WxLBrEyZ2/4sqQms37sStNsRpZ/LhFbRRvvhWPkTSR9S0q4sJAEI8WBgA4XGoB3tQWq3wzjeJN2AygLfNgHsgml2PAuSjcK0WtPZ4B+//5liXlTTX32OJZBmsKoILB4+Wb7ZGZ1m+wNlSn/JRsYxo2lEsxos4KjbvJeHGH3c1ox9qdk4aU027VlHK8nPjaHG1Sly5Yau85qTZO9zHJvLlgzjtUupI8QTvdxprFR/vZTXWU9w+ApQWnpU= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MN2PR11MB35659ACC79D02B5AB70F8572D80F0MN2PR11MB3565namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 370057fe-4416-4584-0891-08d7a02335dd X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Jan 2020 16:42:18.3842 (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: sb1t2Ux9aQMOT5qun+1PgmV2Ed0++EynryaRN/nPr2t0c0s3Y3E3dRjnWZE5lntmzPPiI3sSN+zLnwTEXAe1/w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4239 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.19, xch-rcd-009.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: Re: [Roll] FW: I-D Action: draft-ietf-roll-turnon-rfc8138-03.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jan 2020 16:42:28 -0000 --_000_MN2PR11MB35659ACC79D02B5AB70F8572D80F0MN2PR11MB3565namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Rahul: Yes, and there's more. The first sentence of the spec is " The transition to [RFC8138] in a network can only be done when all nodes support the specification. In a mixed case with both RFC8138-capable and non-capable nodes, the compression should be turned off. " But since the draft indicates transition scenarios to push non-capable node= s to the edge as leaves, which is somehow inconsistent. To address this and cover your point we could change to: " The transition of a RPL [RFC6550] network to activate the compression defined in [RFC8138] can only be done when all routers in the network support it. A non-capable node acting as a router would drop the compressed packets and black-hole its subDAG. In a mixed case with both RFC8138-capable and non-capable nodes, the compression may be turned on only if all the non-capable nodes act as leaves and their RPL parents handle the compression/decompression on their behalf. " We'll note that the best we can do with a legacy device is turn it into a R= AL whereas a newer implementation could become a RUL. In the case of a RUL, the compressed headers are removed by the parent natu= rally. For a RAL, the parent needs to know it must uncompress, and we do not have = a way to signal that, so it must be configuration. Maybe we should clarify that? The intro then says: " This document complements RFC 8138 and dedicates a bit in the RPL configuration option to indicate whether RFC 8138 compression should be used within the RPL Instance. When the bit is not set, source nodes that support RFC 8138 should refrain from using the compression unless the information is superseded by configuration. " It would be worth adding text in the middle per your earlier comment as fol= lows: " This document complements RFC 8138 and dedicates a bit in the RPL configuration option to indicate whether RFC 8138 compression should be used within the RPL Instance. The setting of new bit is controlled by the Root and propagates as is in the whole network. When the bit is not set, source nodes that support RFC 8138 should refrain from using the compression unless the information is superseded by configuration " Finally a node that supports this spec but not the compression can decide t= o become a leaf without the need of the migration scenarios. Ideally it would become a RUL. We could mandate that so the operation of 6L= R always removes the compressed piece that is the encapsulation, but then t= hat makes the RUL draft a normative ref. Is that OK? From: Rahul Jadhav Sent: mercredi 22 janvier 2020 18:14 To: Pascal Thubert (pthubert) ; Routing Over Low power = and Lossy networks Subject: Re: [Roll] FW: I-D Action: draft-ietf-roll-turnon-rfc8138-03.txt I think I got the point here. But I have one question, Assume a 6LR who does not support 8138 and does not support this draft. If = this happens then that link (in which the 6LR is part) won't work for compr= essed source-routed traffic. Ideally, the root will set the T flag only when it knows that all the nodes= support 8138. But still, it would be better to tell the reader of this sce= nario and let know of the dire consequences. [Pascal] On the side, I'll be changing the security section to use set and = reset for the "T" flag as opposed to turn on per your comment earlier.Of th= at works for you it will be in the next publication, you may already look a= t it in the ROLL github repo. [RJ] Works for me. Thanks, Best, Rahul > -----Original Message----- > From: Rahul Jadhav > > Sent: mercredi 22 janvier 2020 16:52 > To: Pascal Thubert (pthubert) >; Routing Over Low > power and Lossy networks > > Subject: Re: [Roll] FW: I-D Action: draft-ietf-roll-turnon-rfc8138-03.txt > > Thank you Pascal, Li for the changes. > > One comment based on the changes: > Section 5: > "A parent propagates the "T" flag as set whether it supports RFC 8138 or = not." > [RJ] I think this is confusing. Consider that the parent does not support= RFC > 8138... according to this text a parent may propagate "T" flag =3D 1, but= this is > not possible. > > Nit: > "...connectivity regardless on the way the RPL..." > on the way -> of the way > > Best, > Rahul > > > > > > > From: Roll > on behal= f of Pascal Thubert (pthubert) > > > > Sent: Wednesday, January 22, 2020 11:17 AM > > To: Routing Over Low power and Lossy networks > > > Subject: [Roll] FW: I-D Action: draft-ietf-roll-turnon-rfc8138-03.txt > > > > > Dear all > > > > This publication addresses the first round of review by Rahul (many thank= s > Rahul!). > > If Rahul is OK with the proposals then I believe we can move to WGLC. > > > > All the best > > > > Pascal > > > > -----Original Message----- > > From: Roll > On Behal= f Of internet-drafts@ietf.org > > Sent: mercredi 22 janvier 2020 12:14 > > To: i-d-announce@ietf.org > > Cc: roll@ietf.org > > Subject: [Roll] I-D Action: draft-ietf-roll-turnon-rfc8138-03.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > > This draft is a work item of the Routing Over Low power and Lossy network= s > WG of the IETF. > > > > Title : Configuration option for RFC 8138 > > Authors : Pascal Thubert > > Li Zhao > > Filename : draft-ietf-roll-turnon-rfc8138-03.txt > > Pages : 8 > > Date : 2020-01-22 > > > > Abstract: > > This document complements RFC 8138 and dedicates a bit in the RPL > > configuration option defined in RFC 6550 to indicate whether RFC 8138 > > compression is used within the RPL Instance. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-roll-turnon-rfc8138/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-roll-turnon-rfc8138-03 > > https://datatracker.ietf.org/doc/html/draft-ietf-roll-turnon-rfc8138-03 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-turnon-rfc8138-03 > > > > > > Please note that it may take a couple of minutes from the time of submiss= ion > until the htmlized version and diff are available at tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > 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 --_000_MN2PR11MB35659ACC79D02B5AB70F8572D80F0MN2PR11MB3565namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Rahul:

 

Yes, and there’s more.

 

The first sentence of the spec is

“

   The tra= nsition to [RFC8138] in a network can only be done when all

   nodes s= upport the specification.  In a mixed case with both=

   RFC8138= -capable and non-capable nodes, the compression should be=

   turned = off. 

“

But since the draft indicates transition scenarios to push n= on-capable nodes to the edge as leaves, which is somehow inconsistent.=

To address this and cover your point we could change to:

“

 


   The transition of a RPL [RFC6550] network to activate the com=
pression


   defined in [RFC8138] can only be done when all routers in the=
 network


   support it.  A non-capable node acting as a router would=
 drop the


   compressed packets and black-hole its subDAG.  In a mixe=
d case with


   both RFC8138-capable and non-capable nodes, the compression m=
ay be


   turned on only if all the non-capable nodes act as leaves and=
 their


   RPL parents handle the compression/decompression on their beh=
alf.


“


We’ll note that the best we can do with a legacy devic=
e is turn it into a RAL whereas a newer implementation could become a RUL.<=
o:p>


In the case of a RUL, the compressed headers are removed by =
the parent naturally.



For a RAL, the parent needs to know it must uncompress, and =
we do not have a way to signal that, so it must be configuration.


Maybe we should clarify that?



 


The intro then says:


“ 

      =
;  This document complements RFC 8138 and dedicates=
 a bit in the RPL


   configu=
ration option to indicate whether RFC 8138 compression should


   be used=
 within the RPL Instance.  When the bit is not set, source<=
/span>


   nodes t=
hat support RFC 8138 should refrain from using the compression


   unless =
the information is superseded by configuration.

“


It would be worth adding text in the middle per your earlier=
 comment as follows:



“


 


   This do=
cument complements RFC 8138 and dedicates a bit in the RPL


   configu=
ration option to indicate whether RFC 8138 compression should


   be used=
 within the RPL Instance.  The setting of new bit is=



   control=
led by the Root and propagates as is in the whole network.


   When th=
e bit is not set, source nodes that support RFC 8138 should


   refrain=
 from using the compression unless the information is


   superse=
ded by configuration


 


“


 


Finally a node that supports this spec but not the compressi=
on can decide to become a leaf without the need of the  migration scen=
arios.


Ideally it would become a RUL. We could mandate that so the =
operation of 6LR always removes the compressed piece that is the encapsulat=
ion, but then that makes the RUL draft a
 normative ref. Is that OK?


 


 








From: Rahul Jadhav <=
;nyrahul@outlook.com>


Sent: mercredi 22 janvier 20=
20 18:14

To: Pascal Thubert (pthubert=
) <pthubert@cisco.com>; Routing Over Low power and Lossy networks <=
;roll@ietf.org>

Subject: Re: [Roll] FW: I-D =
Action: draft-ietf-roll-turnon-rfc8138-03.txt






 




I thi=
nk I got the point here. But I have one question,<=
/p>





=
 






Assum=
e a 6LR who does not support 8138 and does not support this draft. If this =
happens then that link (in which the 6LR is
 part) won't work for compressed source-routed traffic.






Ideal=
ly, the root will set the T flag only when it knows that all the nodes supp=
ort 8138. But still, it would be better to tell
 the reader of this scenario and let know of the dire consequences.






=
 








[Pascal] On the side, I'll be changing the security section =
to use set and reset for the "T" flag as opposed to turn on per y=
our comment earlier.Of that works for you it will
 be in the next publication, you may already look at it in the ROLL github =
repo.






 






[RJ] Works for me. Thanks,






 






Best,






Rahul






 








> -----Original Message-----

> From: Rahul Jadhav <n=
yrahul@outlook.com>

> Sent: mercredi 22 janvier 2020 16:52

> To: Pascal Thubert (pthubert) <pthubert@cisco.com>; Routing Over Low

> power and Lossy networks <roll@iet=
f.org>

> Subject: Re: [Roll] FW: I-D Action: draft-ietf-roll-turnon-rfc8138-03.=
txt

> 

> Thank you Pascal, Li for the changes.

> 

> One comment based on the changes:

> Section 5:

> "A parent propagates the "T" flag as set whether i=
t supports RFC 8138 or not."

> [RJ] I think this is confusing. Consider that the parent does not supp=
ort RFC

> 8138... according to this text a parent may propagate "T" fl=
ag =3D 1, but this is

> not possible.

> 

> Nit:

> "...connectivity regardless on the way the RPL..."

> on the way -> of the way

> 

> Best,

> Rahul

> 

> 

> 

> 

> 

> 

> From: Roll <roll-bounces@i=
etf.org> on behalf of Pascal Thubert (pthubert)

> <pthubert@cisco.com>
> 

> Sent: Wednesday, January 22, 2020 11:17 AM

> 

> To: Routing Over Low power and Lossy networks <roll@ietf.org>

> 

> Subject: [Roll] FW: I-D Action: draft-ietf-roll-turnon-rfc8138-03.txt<=
br>
> 

> 

> 

> 

> Dear all

> 

> 

> 

> This publication addresses the first round of review by Rahul (many th=
anks

> Rahul!).

> 

> If Rahul is OK with the proposals then I believe we can move to WGLC.<=
br>
> 

> 

> 

> All the best

> 

> 

> 

> Pascal

> 

> 

> 

> -----Original Message-----

> 

> From: Roll <roll-bounces@i=
etf.org> On Behalf Of
internet-drafts@ietf.org
> 

> Sent: mercredi 22 janvier 2020 12:14

> 

> To: i-d-announce@ietf.org=


> 

> Cc: roll@ietf.org

> 

> Subject: [Roll] I-D Action: draft-ietf-roll-turnon-rfc8138-03.txt

> 

> 

> 

> 

> 

> A New Internet-Draft is available from the on-line Internet-Drafts dir=
ectories.

> 

> This draft is a work item of the Routing Over Low power and Lossy netw=
orks

> WG of the IETF.

> 

> 

> 

>         Title   &nbs=
p;       : Configuration option for RFC 8138<=
br>
> 

>         Authors   &n=
bsp;     : Pascal Thubert

> 

>            &nbs=
p;            &=
nbsp; Li Zhao

> 

>         Filename   &=
nbsp;    : draft-ietf-roll-turnon-rfc8138-03.txt

> 

>         Pages   &nbs=
p;       : 8

> 

>         Date    =
;        : 2020-01-22

> 

> 

> 

> Abstract:

> 

>    This document complements RFC 8138 and dedicates a bit in=
 the RPL

> 

>    configuration option defined in RFC 6550 to indicate whet=
her RFC 8138

> 

>    compression is used within the RPL Instance.

> 

> 

> 

> 

> 

> The IETF datatracker status page for this draft is:

> 

> https://datatracker.ietf.org/doc/draft-ietf-roll-turnon-rfc8138/=


> 

> 

> 

> There are also htmlized versions available at:

> 

> https://tools.ietf.org/html/draft-ietf-roll-turnon-rfc8138-03

> 

> 
https://datatracker.ietf.org/doc/html/draft-ietf-roll-turnon-rfc8138-03=


> 

> 

> 

> A diff from the previous version is available at:

> 

> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-turnon-rfc8=
138-03

> 

> 

> 

> 

> 

> Please note that it may take a couple of minutes from the time of subm=
ission

> until the htmlized version and diff are available at tools.ietf.org.
> 

> 

> 

> Internet-Drafts are also available by anonymous FTP at:

> 

> ftp://ftp.ietf.org/int=
ernet-drafts/

> 

> 

> 

> _______________________________________________

> 

> Roll mailing list

> 

> Roll@ietf.org

> 

> https://www.iet=
f.org/mailman/listinfo/roll

> 

> 

> 

> _______________________________________________

> 

> Roll mailing list

> 

> Roll@ietf.org

> 

> https://www.iet=
f.org/mailman/listinfo/roll
--_000_MN2PR11MB35659ACC79D02B5AB70F8572D80F0MN2PR11MB3565namp_-- From nobody Fri Jan 24 08:49:48 2020 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 705AB120929; Fri, 24 Jan 2020 08:49:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: roll@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: roll@ietf.org Message-ID: <157988458739.22155.2332580763866900150@ietfa.amsl.com> Date: Fri, 24 Jan 2020 08:49:47 -0800 Archived-At: Subject: [Roll] I-D Action: draft-ietf-roll-turnon-rfc8138-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 16:49:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks WG of the IETF. Title : Configuration option for RFC 8138 Authors : Pascal Thubert Li Zhao Filename : draft-ietf-roll-turnon-rfc8138-04.txt Pages : 9 Date : 2020-01-24 Abstract: This document complements RFC 8138 and dedicates a bit in the RPL configuration option defined in RFC 6550 to indicate whether RFC 8138 compression is used within the RPL Instance. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-turnon-rfc8138/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-roll-turnon-rfc8138-04 https://datatracker.ietf.org/doc/html/draft-ietf-roll-turnon-rfc8138-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-turnon-rfc8138-04 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jan 24 08:54:29 2020 Return-Path: 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 F1506120976 for ; Fri, 24 Jan 2020 08:54:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.499 X-Spam-Level: X-Spam-Status: No, score=-14.499 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=a9sySN4K; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=NFjFs4U7 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 OhzJSu8Ly4fC for ; Fri, 24 Jan 2020 08:54:25 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3467120969 for ; Fri, 24 Jan 2020 08:54:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1813; q=dns/txt; s=iport; t=1579884865; x=1581094465; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=k/PrqBSFPAwXT6kMuPgUWQ8+LroBYVTkzCX/x67B+jw=; b=a9sySN4K9vpOOhj8s1SIjDLNi5Qp1Wp+Pmm6Qe88Cj35y+caK98Qte9Z k8y5QQo1OkiqcMngMs/3fDcmI5jicoHuapJXuRJnhyUacp1xN3R/fuc4c G0sjTeH80YroZz98YDhiz8zcAbfFZslfTl7q/AaaGvV1o61Qa+v78zUds M=; IronPort-PHdr: =?us-ascii?q?9a23=3Apyx2cxTnMfcAMqFtGqCqkshjbdpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESXBNfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5g640NmhA4RsuMCEn1NvnvOjQmHNlIWUV513q6KkNSXs35Yg6arw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AzEAD7ICte/4cNJK1lHgELHIFwC4F?= =?us-ascii?q?UUAVsWCAECyoKh04DixBOghGQIYdugUKBEANUCQEBAQwBARgLCgIBAYRAAoI?= =?us-ascii?q?iJDcGDgIDDQEBBAEBAQIBBQRthTcMhV4BAQEBAwEBECgGAQEsDAsEAgEIEQQ?= =?us-ascii?q?BAR8QJwsbAQEFAwIEEwgagwWCSgMuAQIMok4CgTmIYYIngn8BAQWBMwIOQYJ?= =?us-ascii?q?8GIIMCYE4jBcagUE/gViCTD6CZAEBAgEBGIEPHB6DQIIsr1wKgjmHQodphye?= =?us-ascii?q?CSHiHEpAql0SSKQIEAgQFAg4BAQWBaCOBWHAVGiGCbAlHGA2IAYNzhRSFP3S?= =?us-ascii?q?BKYsdAYEPAQE?= X-IronPort-AV: E=Sophos;i="5.70,358,1574121600"; d="scan'208";a="619558744" Received: from alln-core-2.cisco.com ([173.36.13.135]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Jan 2020 16:53:52 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by alln-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 00OGropd031136 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 24 Jan 2020 16:53:52 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 24 Jan 2020 10:53:50 -0600 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 24 Jan 2020 11:53:49 -0500 Received: from NAM02-BL2-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, 24 Jan 2020 10:53:49 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MzcVb/Kb6IZxe2RE7sBhepw6KD2Yr+JlprTFOhWc/4APsdmNKWCRt3/u3L5V1uF1Guq5sImpRByIMWQBFaSkwDxgR3SJWPQH41vUMXLW3GhK7eEjVPUicgBJYtLyyfpJ5Gtj39ux3KRMLPunI26fcBirnQ5xW73LGtKDQo/4lguO5rIKLIhKvUyTG2JTZLwLu3SryY+RMgDPwLHR0Dkc9+5V3yoxb1eWj/g7CdZf2G2wMDWR5+lsv6qaVUzNC/LEMSaF9mm8gIm0ZiqgQCQSfaE6cks56nmiJQwC/QD7Y32enQTL3aIKfbyEecOek8oKBhb5YGmlJ8jYVcE2R9LNUQ== 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=Jy3BWnDty8hid9VsL6uZRHf2Y/5mPXdO+LU2DVaxJpU=; b=m762hcBTVQt4iRUGZdC3MVwUPuy+9rccamTHeuAu5bri3N1aJckDiBGp7UYdMpJA/pODjER2CzpnIaz6ZyCkoMmYMVHFkkjGWVVd9dBmSFgkEoTZSSqdg0AQOyno98cL+pnWtbrHRC8c/VYtotFVJ8Yg85Mvd8W2AAthlKIvQovRL2pomx5M14j4NXGkrZTpVCPaqNIkGR9mQvtSrj60NHUcTJIarvOKRto1QFymyQx0H24MaabImeBC86G/aBsjMVQrQwf9sleQrfPHETsF2lY5/Cj3J+zv1XdfWcSvrVxgEpeQ+dI3k1lgTnyOwNZNh4ByUs5jh2qD9LHfREyJrQ== 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=Jy3BWnDty8hid9VsL6uZRHf2Y/5mPXdO+LU2DVaxJpU=; b=NFjFs4U7Hqv2oLfDZwusKbDOKJ34s66m7oDmtJWAMcyOwNjKjJuO+dzjbRoNjsBo39xk+14wfciMFlDra+nkKE4W8t2XboqmrdhQLjHbxTGSODVsfWsf5CEjQbKE0iPX4o80Zoke/azGBqEK05QudVO6MKM0GlKLfZPTfhVDnXA= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB4496.namprd11.prod.outlook.com (52.135.38.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.20; Fri, 24 Jan 2020 16:53:47 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::fd76:1534:4f9a:452a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::fd76:1534:4f9a:452a%3]) with mapi id 15.20.2644.027; Fri, 24 Jan 2020 16:53:48 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] I-D Action: draft-ietf-roll-turnon-rfc8138-04.txt Thread-Index: AQHV0tZUeXOKu1ulN0SdiZ4Qmel+96f6Bzcg Date: Fri, 24 Jan 2020 16:53:40 +0000 Deferred-Delivery: Fri, 24 Jan 2020 16:52:38 +0000 Message-ID: References: <157988458739.22155.2332580763866900150@ietfa.amsl.com> In-Reply-To: <157988458739.22155.2332580763866900150@ietfa.amsl.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: [173.38.220.34] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f54d9195-2142-4d3d-02c7-08d7a0edfb75 x-ms-traffictypediagnostic: MN2PR11MB4496: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7219; x-forefront-prvs: 02929ECF07 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(136003)(39860400002)(376002)(366004)(346002)(396003)(199004)(189003)(966005)(53546011)(2906002)(6506007)(33656002)(8936002)(81166006)(6666004)(8676002)(86362001)(5660300002)(81156014)(52536014)(478600001)(316002)(76116006)(66946007)(64756008)(66446008)(66556008)(66476007)(66574012)(9686003)(186003)(26005)(55016002)(71200400001)(6916009)(7696005); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB4496; 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: xlSy3snrQDEt9v14RKAGFFZvxZ2nzOXS8a8YibE3Ig+cW75c8ykMl7NmjKxrpvljVG2topuBTEWvCYa+0/v5Qy69xy+zdthQcEDcSZudzJN/7sK5GyFW8tLDUf/NjA7x4IfiTGfXwXDzOV6IKva8SWwl772cqxWqPVLV32e/0MEnB+MXMwY76rBcHpVHY6J04xdmmfqqPwWnIeqF39lUfNjZo/zX+hoTAltYhMMpEQ5F7HMJEI8Q3JKKZosCWU1wt0hvAGpFCHqroquTKnNOAb1EZxJ79BqC8ySDUW0tfLE4jFQL14Guq7nGhFBPA8WawROF9bApTP52FqLkIj482Fvt7L4aS7TU/LYUklw+pRNlc1oc5Z+BCk43d/HJ5v1sBv+B5LjmCc7zF1ZuIWzB/5+g6G9g4vcu8z0NOuI7t5G9sqYq+HxPn9LhlSH8D4Gt4qYnpkIXIaq4z0BrDGRDd9c6aj8kWEfnM4XyyRxHilr8y26o8kJOu+O4L+99ERytWhPOc4M7sTi9JlFFmzKdOw== x-ms-exchange-antispam-messagedata: 0MRvf++QesWxqz0YXanZNdrqMrDrJbbRoTdOqqndZssoLNUK29sKrQ87xMW7/xEF6GMMcg2RnhTBftTfJXCTflOgFT39bt+5+rYXqVDIBYax9NQAgq2gAUzzobkIQnThg0774c8SfHVK3RjX/vJj4g== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: f54d9195-2142-4d3d-02c7-08d7a0edfb75 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jan 2020 16:53:48.1218 (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: vMR7jVZU8DkW/DONsE4JhJ0NRxwR2EaxOkXe4Q0DA9r5O1nIYv7HsgONPHE8pPxVkZWjk87MuGnXubb8vVUANQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4496 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.16, xch-rcd-006.cisco.com X-Outbound-Node: alln-core-2.cisco.com Archived-At: Subject: [Roll] FW: I-D Action: draft-ietf-roll-turnon-rfc8138-04.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 16:54:28 -0000 Dear all This includes the result of the discussions with Rahul on this ML so far; Cheers, Pascal -----Original Message----- From: Roll On Behalf Of internet-drafts@ietf.org Sent: vendredi 24 janvier 2020 17:50 To: i-d-announce@ietf.org Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-turnon-rfc8138-04.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Routing Over Low power and Lossy networks = WG of the IETF. Title : Configuration option for RFC 8138 Authors : Pascal Thubert Li Zhao Filename : draft-ietf-roll-turnon-rfc8138-04.txt Pages : 9 Date : 2020-01-24 Abstract: This document complements RFC 8138 and dedicates a bit in the RPL configuration option defined in RFC 6550 to indicate whether RFC 8138 compression is used within the RPL Instance. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-turnon-rfc8138/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-roll-turnon-rfc8138-04 https://datatracker.ietf.org/doc/html/draft-ietf-roll-turnon-rfc8138-04 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-turnon-rfc8138-04 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From nobody Mon Jan 27 01:24:50 2020 Return-Path: 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 F152F12008B for ; Mon, 27 Jan 2020 01:24:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no 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 WO_s9wKLOI_M for ; Mon, 27 Jan 2020 01:24:48 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC73712001B for ; Mon, 27 Jan 2020 01:24:47 -0800 (PST) Received: from opfedar02.francetelecom.fr (unknown [xx.xx.xx.4]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 485kq16mXNz2xw1 for ; Mon, 27 Jan 2020 10:24:45 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.35]) by opfedar02.francetelecom.fr (ESMTP service) with ESMTP id 485kq15z2mzCqkM for ; Mon, 27 Jan 2020 10:24:45 +0100 (CET) Received: from OPEXCAUBM21.corporate.adroot.infra.ftgroup ([fe80::d42b:2e80:86c2:5905]) by OPEXCAUBM6C.corporate.adroot.infra.ftgroup ([fe80::f58e:8e9d:ae18:b9e3%21]) with mapi id 14.03.0468.000; Mon, 27 Jan 2020 10:24:45 +0100 From: To: "roll@ietf.org" Thread-Topic: roll - New Meeting Session Request for IETF 107 Thread-Index: AQHV1POdie5m8PF7DkSEc+tbeKMUGA== Date: Mon, 27 Jan 2020 09:24:45 +0000 Message-ID: <32323_1580117085_5E2EAC5D_32323_160_19_DA5469B0.6F5A1%dominique.barthel@orange.com> References: <157968512040.12295.14784920250107898750.idtracker@ietfa.amsl.com> In-Reply-To: <157968512040.12295.14784920250107898750.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.3.170325 x-originating-ip: [10.114.13.247] Content-Type: text/plain; charset="utf-8" Content-ID: <4F9E8EC09F21E743B591ADE4245F7992@adroot.infra.ftgroup> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Roll] roll - New Meeting Session Request for IETF 107 X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2020 09:24:49 -0000 RGVhciBhbGwsDQoNCkFzIHlvdSBoYXZlIHNlZW4sIHdlIGhhdmUgc3VibWl0dGVkIGEgc2Vzc2lv biByZXF1ZXN0IGZvciBST0xMIGF0IHRoZQ0KSUVURjEwNyBtZWV0aW5nLg0KVGhlIHJlcXVlc3Qg aW5jbHVkZXMgYSBsaXN0IG9mIFdHcyB0aGF0IHdlIGFzayB0byBhdm9pZCBhZ2VuZGEgY29uZmxp Y3RzDQp3aXRoLg0KSWYgeW91IHRoaW5rIHdlIGhhdmUgbWlzc2VkIHNvbWUgV0dzIGluIHRoZSBj b25mbGljdCBsaXN0LCBwbGVhc2UgbGV0IHVzDQprbm93LCB3ZSBjYW4gc3RpbGwgYW1lbmQgdGhl IHJlcXVlc3QuDQpUaGFuayB5b3UgZm9yIHlvdXIgYXR0ZW50aW9uDQoNCkluw6hzICYgRG9taW5p cXVlDQoNCkxlIDIyLzAxLzIwIDEwOjI1LCDCqyBJRVRGIE1lZXRpbmcgU2Vzc2lvbiBSZXF1ZXN0 IFRvb2wgwrsNCjxzZXNzaW9uLXJlcXVlc3RAaWV0Zi5vcmc+IGEgw6ljcml0IDoNCg0KPg0KPg0K PkEgbmV3IG1lZXRpbmcgc2Vzc2lvbiByZXF1ZXN0IGhhcyBqdXN0IGJlZW4gc3VibWl0dGVkIGJ5 IERvbWluaXF1ZQ0KPkJhcnRoZWwsIGEgQ2hhaXIgb2YgdGhlIHJvbGwgd29ya2luZyBncm91cC4N Cj4NCj4NCj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj5Xb3JraW5nIEdyb3VwIE5hbWU6IFJvdXRpbmcgT3ZlciBMb3cgcG93ZXIgYW5k IExvc3N5IG5ldHdvcmtzDQo+QXJlYSBOYW1lOiBSb3V0aW5nIEFyZWENCj5TZXNzaW9uIFJlcXVl c3RlcjogRG9taW5pcXVlIEJhcnRoZWwNCj4NCj5OdW1iZXIgb2YgU2Vzc2lvbnM6IDINCj5MZW5n dGggb2YgU2Vzc2lvbihzKTogIDIgSG91cnMsIDEgSG91cg0KPk51bWJlciBvZiBBdHRlbmRlZXM6 IDUwDQo+Q29uZmxpY3RzIHRvIEF2b2lkOg0KPiBDaGFpciBDb25mbGljdDogYW5pbWEgbWFuZXQg NnRpc2NoIGNvcmUgYWNlIGxwd2FuDQo+IFRlY2hub2xvZ3kgT3ZlcmxhcDogcnRnYXJlYSA2bG8g Nm1hbiBsd2lnIGNib3IgdDJ0cmcNCj4gS2V5IFBhcnRpY2lwYW50IENvbmZsaWN0OiBydGd3ZyBp bnRhcmVhDQo+DQo+DQo+UGVvcGxlIHdobyBtdXN0IGJlIHByZXNlbnQ6DQo+ICBNaWNoYWVsIFJp Y2hhcmRzb24NCj4gIERvbWluaXF1ZSBCYXJ0aGVsDQo+ICBBbHZhcm8gUmV0YW5hDQo+ICBJbmVz IFJvYmxlcw0KPg0KPlJlc291cmNlcyBSZXF1ZXN0ZWQ6DQo+DQoNCgpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNz YWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlv bnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFz IGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNp IHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFs ZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9p bnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0 ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2Fn ZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdl IGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVn ZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQg bm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24u CklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpB cyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdl cyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlv dS4KCg== From nobody Mon Jan 27 06:46:26 2020 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 19F88120058; Mon, 27 Jan 2020 06:46:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: roll@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.116.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: roll@ietf.org Message-ID: <158013638403.26591.5665480098476135366@ietfa.amsl.com> Date: Mon, 27 Jan 2020 06:46:24 -0800 Archived-At: Subject: [Roll] I-D Action: draft-ietf-roll-unaware-leaves-09.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2020 14:46:24 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks WG of the IETF. Title : Routing for RPL Leaves Authors : Pascal Thubert Michael C. Richardson Filename : draft-ietf-roll-unaware-leaves-09.txt Pages : 32 Date : 2020-01-27 Abstract: This specification extends RFC6550 and RFC8505 to provide unicast and multicast routing services in a RPL domain to 6LNs that are plain Hosts and do not participate to RPL, and enables the RPL Root to proxy the EDAR/EDAC flow on behalf of the RULs and RANs in its DODAG. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-unaware-leaves/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-roll-unaware-leaves-09 https://datatracker.ietf.org/doc/html/draft-ietf-roll-unaware-leaves-09 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-unaware-leaves-09 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jan 27 06:52:41 2020 Return-Path: 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 6BBB11200A3 for ; Mon, 27 Jan 2020 06:52:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.498 X-Spam-Level: X-Spam-Status: No, score=-14.498 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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=AZ3FMjcs; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=0mr9oDQF 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 t2TnVI7eylvY for ; Mon, 27 Jan 2020 06:52:37 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81DFE12004F for ; Mon, 27 Jan 2020 06:52:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2374; q=dns/txt; s=iport; t=1580136757; x=1581346357; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=w6vQJUxDAdatcEUlUBaR5y9CkiXO+fNQz9SsG7hUOZo=; b=AZ3FMjcsmjEgdySU2U8Uy9SuAKqlMp2DsXMAFstVdSE2fdr9zLP5Nkvf iKlBZS1Xe7WmBWdUe9BxBi4f1+OJjAnVN7UOuKnmKcCgqETPIBoqC+pqT wi0KF2JvzowkbvR5Ufebk1NM0y6JqYeshKeZWDtB4gdlex+bfMbZrPdHQ 0=; IronPort-PHdr: =?us-ascii?q?9a23=3AdPqZDhzBvSqc8WXXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YhWN/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZudFU3mJvPwcwQxHd9JUxlu+HToeUU=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AyAgB1+C5e/5hdJa1mHQEBAQkBEQU?= =?us-ascii?q?FAYFpBgELAYFTUAVsWCAECyqEFINGA4sTToIRmA+BLoEkA1QJAQEBDAEBJQg?= =?us-ascii?q?CAQGEQAIXgg0kNgcOAgMNAQEEAQEBAgEFBG2FNwyFXgEBAQEDEhERDAEBNQM?= =?us-ascii?q?LBAIBCBEEAQEDAiYCAgIwFQYBAQUDAgQTCBqDBYJKAy4BAgygVAKBOYhhdYE?= =?us-ascii?q?ygn8BAQWBMwIOQYMOGIIMCYEOKgGMHRqBQT+BEUeCTD6CZAEBAgEBGIFJgw4?= =?us-ascii?q?ygiyQVYYCmQUKgjmHQo8Qgkh4hxKQKpAqhxqSKQIEAgQFAg4BAQWBWQgqgVh?= =?us-ascii?q?wFRqDDQlHGA2TbINzhRSFP3QCgSeMYwEB?= X-IronPort-AV: E=Sophos;i="5.70,370,1574121600"; d="scan'208";a="621466157" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Jan 2020 14:52:36 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id 00REqapp030461 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 27 Jan 2020 14:52:36 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 27 Jan 2020 08:52:35 -0600 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 27 Jan 2020 08:52:34 -0600 Received: from NAM11-CO1-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; Mon, 27 Jan 2020 08:52:34 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cYqWBVk8v44My3/VRRqok5kMxfebJbo8Nt6j+6WjoLbgdAtmu11jh78ODYgwC7GhtaXLfb7x9Fh95lT6qOccHjUoefKyG0h9GqIiPemdDWXbTJ0S9j0ciEnYoOkCKpAXBZ89H8QT4VFvQsxev/gnCSNsvsK4YamcoPU9cLn5IwPaKBIbtli62++Wpz0bAeahcHbA8YOnFKy802E/BBFoQa0gG1BKHNFYB2qo4kPwI2S4kx8CuqjAluOJboHNq2WfGklMvFlihjbUsiXfZlcJhjgL69aEqh8M5fx44uhLrCzhFJ9DpTXLcKFXhuTrNDtW/NvY8dcBLHV69E+PivvtQQ== 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=w6vQJUxDAdatcEUlUBaR5y9CkiXO+fNQz9SsG7hUOZo=; b=GQt+EHLgl6R8yrphm+dsTZvh+UPkNi5PUg6zoN5HQpzMekTys5Ksv1bgQOqiDNISug6yukRsWHCuF3d8dD/M/PwV8g0pwBoMxpqeLHyvEAr2kqhw3I7rsf2rClL20wLn+ZP0D/gv4O/IDs/pg5935XlT2D4q4DlbV6hgExvRe6nksEB8ycmvY/BPcV3eTHkAJE3W1zoUvA1k5e6zNGSVxvhMxRvuTPBWG8pfxXC0MkNSi5XNdv2geQCWo2WYpVHXmFYHJJ878ePdTScAlwIzjYdjd1yoCyFvV8LqwvdtdvLfdroWP/hVWsABFN33sHnVVZ+ssy11H7aPFDn5MIz7Gw== 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=w6vQJUxDAdatcEUlUBaR5y9CkiXO+fNQz9SsG7hUOZo=; b=0mr9oDQFgWGynP1N7W5fxzne/o2u8OV0W5HYFcatpw8tdpmI9O21ILK8B4sRR/Gg+0HRrKE0PXX03f1+MtmfXA4UqB5j6fO2jWiF6eCktZ6plQ2Tr6wEFvUc3j57mkIfZc761McBLQiIOCzXHPUwbPJP8J7xvMMkNUZfrZrw5Uw= Received: from MN2PR11MB3565.namprd11.prod.outlook.com (20.178.250.159) by MN2PR11MB3693.namprd11.prod.outlook.com (20.178.252.207) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2665.24; Mon, 27 Jan 2020 14:52:33 +0000 Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::fd76:1534:4f9a:452a]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::fd76:1534:4f9a:452a%3]) with mapi id 15.20.2665.026; Mon, 27 Jan 2020 14:52:33 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: New Version Notification for draft-ietf-roll-unaware-leaves-09.txt Thread-Index: AQHV1SCmFptS8iq3T02hQUB9LqpnEqf+l8UQ Date: Mon, 27 Jan 2020 14:52:09 +0000 Deferred-Delivery: Mon, 27 Jan 2020 14:51:27 +0000 Message-ID: References: <158013638422.26591.6685213749280176035.idtracker@ietfa.amsl.com> In-Reply-To: <158013638422.26591.6685213749280176035.idtracker@ietfa.amsl.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: [2001:420:44f3:1300:41e7:7725:e525:b2e8] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b1b861a9-d2eb-448f-4dc6-08d7a3388a89 x-ms-traffictypediagnostic: MN2PR11MB3693: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-forefront-prvs: 02951C14DC x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(396003)(136003)(346002)(376002)(39860400002)(189003)(199004)(7696005)(6916009)(52536014)(186003)(966005)(66946007)(478600001)(76116006)(66476007)(55016002)(9686003)(66556008)(66446008)(64756008)(6666004)(71200400001)(6506007)(53546011)(316002)(2906002)(5660300002)(33656002)(8936002)(81166006)(81156014)(8676002)(66574012)(15650500001)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3693; H:MN2PR11MB3565.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: qNLlCbToWC+dBZY/bHwbO3xfQKUirvUzjGqvu0E6LW0Iha3OBORAnLSwFa0+KJmTNfvhm0k2iPwrY3fK/4E68B/k/VmEYgmPrd4Q931DRobV/CGYMxG8ngYC/UQtc9MYd+CMF2FROwGi+BYbnsLoA13Ea8RSBUpsi4LeeVHobUvxL0sgdA9we1c4GS/f5CAtJ2wseSCfeZCGHOGKILkd7Ra6O+cQb4wsdXZUQ6dd78wMfFpkWDHMJckF1wkPVfeNNKW+gsucaIT0k5OUpMm8hMvXvVrIMo786gavsi3O2+4zI8CksgpNCOX7vM0cnBwJE+OnHcQ43wTL/A8u0d117idyqRRYTCtWw43XxbwqMdYZqpGYZXdl+3E6fLelkKTLAMjPB2A4fpucRg5OiyR4aYsiUKXcg+oOFs//87iUTz/W/wtBnUI5VIrGHr6DnLT+gxcqBCoy9j97cfXjAVd8oTTx1H457P5QEnbX8rGe2ns= x-ms-exchange-antispam-messagedata: IvyAHrsmghJBzpSPvzfi7yG+gHGMqEoTkxpvUwH9TT5JVHr6cGXQ6BEYaOa0/UWJ6Y1idtMbSlYiAqHtpgaCMTiPjZzymtfHYQV7MaZbGt/bxEiVLZHo7Hjd+FFtQ1BeZMoRJng5tlBysqmBXspkD/IuWzpOUFF644us6pRqESkL3iWTx7UtrY3UUI9r9DqnWIQMXXtAZUYH8V//b7kzYQ== 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: b1b861a9-d2eb-448f-4dc6-08d7a3388a89 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Jan 2020 14:52:33.2705 (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: 9O9V1Xea59mEZMgUHW26lXRv9vSUNwAc1JVlXc8M976x5AA9sRChxl2eg8E56mEUUYIsZrkV7TZnKT2zWlTsYA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB3693 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: [Roll] FW: New Version Notification for draft-ietf-roll-unaware-leaves-09.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jan 2020 14:52:40 -0000 QSBzbWFsbCB1cGRhdGUgdG8gY2xhcmlmeSBob3cgdGhlIFJVTCBrbm93cyB0aGF0IHRoZSA2TFIg Y2FuIGFjdCBhcyByb3V0aW5nIHJlZ2lzdHJhciAocGVyIFJGQyA4NTA1LCByZWFsbHkpLg0KDQot LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3Jn IDxpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+IA0KU2VudDogbHVuZGkgMjcgamFudmllciAyMDIw IDE1OjQ2DQpUbzogUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KSA8cHRodWJlcnRAY2lzY28uY29t PjsgTWljaGFlbCBSaWNoYXJkc29uIDxtY3IraWV0ZkBzYW5kZWxtYW4uY2E+OyBNaWNoYWVsIEMu IFJpY2hhcmRzb24gPG1jcitpZXRmQHNhbmRlbG1hbi5jYT4NClN1YmplY3Q6IE5ldyBWZXJzaW9u IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtaWV0Zi1yb2xsLXVuYXdhcmUtbGVhdmVzLTA5LnR4dA0K DQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1pZXRmLXJvbGwtdW5hd2FyZS1sZWF2ZXMt MDkudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IFBhc2NhbCBUaHViZXJ0 IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LWlldGYt cm9sbC11bmF3YXJlLWxlYXZlcw0KUmV2aXNpb246CTA5DQpUaXRsZToJCVJvdXRpbmcgZm9yIFJQ TCBMZWF2ZXMNCkRvY3VtZW50IGRhdGU6CTIwMjAtMDEtMjcNCkdyb3VwOgkJcm9sbA0KUGFnZXM6 CQkzMg0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0 cy9kcmFmdC1pZXRmLXJvbGwtdW5hd2FyZS1sZWF2ZXMtMDkudHh0DQpTdGF0dXM6ICAgICAgICAg aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1yb2xsLXVuYXdhcmUt bGVhdmVzLw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC1pZXRmLXJvbGwtdW5hd2FyZS1sZWF2ZXMtMDkNCkh0bWxpemVkOiAgICAgICBodHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LWlldGYtcm9sbC11bmF3YXJlLWxlYXZl cw0KRGlmZjogICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFm dC1pZXRmLXJvbGwtdW5hd2FyZS1sZWF2ZXMtMDkNCg0KQWJzdHJhY3Q6DQogICBUaGlzIHNwZWNp ZmljYXRpb24gZXh0ZW5kcyBSRkM2NTUwIGFuZCBSRkM4NTA1IHRvIHByb3ZpZGUgdW5pY2FzdCBh bmQNCiAgIG11bHRpY2FzdCByb3V0aW5nIHNlcnZpY2VzIGluIGEgUlBMIGRvbWFpbiB0byA2TE5z IHRoYXQgYXJlIHBsYWluDQogICBIb3N0cyBhbmQgZG8gbm90IHBhcnRpY2lwYXRlIHRvIFJQTCwg YW5kIGVuYWJsZXMgdGhlIFJQTCBSb290IHRvDQogICBwcm94eSB0aGUgRURBUi9FREFDIGZsb3cg b24gYmVoYWxmIG9mIHRoZSBSVUxzIGFuZCBSQU5zIGluIGl0cyBET0RBRy4NCg0KICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3Vw bGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxp emVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0K VGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K