[Roll] FW: Published draft-ietf-roll-unaware-leaves-17.txt
"Pascal Thubert (pthubert)" <pthubert@cisco.com> Fri, 12 June 2020 15:30 UTC
Return-Path: <pthubert@cisco.com>
X-Original-To: roll@ietfa.amsl.com
Delivered-To: roll@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A467C3A0B8A; Fri, 12 Jun 2020 08:30:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.597
X-Spam-Level:
X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, 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=a9BdSwzb; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Oes0P5SB
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 C2uLVOB6nY_f; Fri, 12 Jun 2020 08:30:32 -0700 (PDT)
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 98CDD3A091A; Fri, 12 Jun 2020 08:30:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=57056; q=dns/txt; s=iport; t=1591975831; x=1593185431; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=ZuygOoMBkpD1yo31Asn/dGt7/wV4/zXycoYLOK57RAs=; b=a9BdSwzbf1gvPL1xpLEXDKqRjQS93FBbB3oxcuCImZN6+6H/T+4sih2i /EuGDB6PpDncY8wV9Ke87Mh8hkKY3SifZ0LDw0HL4lT99ebxKnQ3WtL8V U1V72NBtmanQ36njElU/Cc25exxCrIKncIa8I0bJrZMu5o/UyjaqUMcdf E=;
IronPort-PHdr: 9a23:1jePFxSMNivfl3JmbwTTWXH1Gtpsv++ubAcI9poqja5Pea2//pPkeVbS/uhpkESQBN+J6v9YhazRqa+zEWAD4JPUtncEfdQMUhIekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsutZlDOrDu19zFBUhn6PBB+c+LyHIOahs+r1ue0rpvUZQgAhDe0bb5oahusqgCEvcgNiowkIaE0mRY=
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CyAAA2n+Ne/4ENJK1mGgEBAQEBAQEBAQEDAQEBARIBAQEBAgIBAQEBggqBIy9SB29YLyyDZECDRgONO4EBl1GBQoEQA1AFAwgBAQEMAQEYAQoKAgQBAYMOgTYCF4IUAiQ4EwIDAQELAQEFAQEBAgEGBG2FWwyFcgEBAQECAQEBCgYRBAYTAQElBwsBBAcEAgEGAhEEAQEhAQYDAgICJQsUBwEBBQMCBA4FCBqDBYF+TQMOIAEOl0SQaAKBOYhhdn8zgwEBAQWBNgIOQYMaGIIOCYE4gmSCS4EFhhcagUE/gRFDgU9JNT6CZwEBAgEBGIEPHCArCQiCVjOCLZIjhjcmm0EKglmIPIYhil6CcIEWiASOOYQkknmIKJAIhBsCBAIEBQIOAQEFgUAqIoFADwdwFRohgmkJRxcCDY16JAwXg06FFIVCdAI1AgMDAQcBAQMJfI8yAQE
X-IronPort-AV: E=Sophos;i="5.73,503,1583193600"; d="scan'208,217";a="692111482"
Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Jun 2020 15:30:28 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 05CFUSxC014422 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 12 Jun 2020 15:30:28 GMT
Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 12 Jun 2020 10:30:28 -0500
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 12 Jun 2020 10:30:26 -0500
Received: from NAM12-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.1497.2 via Frontend Transport; Fri, 12 Jun 2020 10:30:28 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SwSSDAP/ZmWwcEFi5DrtekQuGKh8pK+dP5ZjYpOfwB7oudX3Zs1EAAYSD7CLJEw+exL597vTAyN07If+NvdUGrQyEPjJ2YlvDv1nrZLNn0DGKJm63LcZswYBBKtlu7mN8qCXIRFmP/Z7XloYb3eRKLcRvoTgVUCV+SN5VP5yJok08SVeiOOknHRf0xmSkfZ40/fQTpWzxi0kggMx/ZE8ZDbNZJhP7lX7kVOudp+IfsqrqO0JWKvx5zUIkXPKYzAXTgxdyvBoUFhkwsLX9b7yCIqbk5yI85ipbN4dXfUm/qDUj33N3UrGh1fsOFn+rwN8TTKu4ggMqYrXHa7IpFhBGg==
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=ZuygOoMBkpD1yo31Asn/dGt7/wV4/zXycoYLOK57RAs=; b=nGgVWUer6RgttsrLEkaK8qgIt9/ZIZ3eJ97c6rlMdZpxPqzM5M7dYP6+Pw8LVhXjqe5g+ZExn+Te+bsOu4wm3oZklqVRl8itA5W4+wwEWQPbyvrz7XJePv7hRL63ClT1VwQ1bPSQBabxTYf1WhoavmAucN65KDaoS4mGRPP/PO8UilT3XXA5PR5GhSJIQEpr5BihQfESokRuqluiSxD+5AkmyZfKwbAwtAcXIEASxZueozOnjU0Ltm2vw4UoCGKPArPb/Xy10SibuceLY101qpF/BTg+tvYwqGF30Nqx/Xr0uGLyCL3oQrvLijYOvH9hHzx2PusEVG+FQkyw2WH48w==
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=ZuygOoMBkpD1yo31Asn/dGt7/wV4/zXycoYLOK57RAs=; b=Oes0P5SBzzVxEPzfm4Ba2UTXPn40nacy9HpRmb3SP/gEKEmuvP7lKdxQR5+99fn1tyY1BTf7z0fGCxLXeRwx9CcdBRNqDN9r3jphs3IgEVqCWC7pv7t2zJ3zaF4cBLMmX2bcM/3RPyt/WDgwVV9ScDkJGypIQesWdqy+Els1FkI=
Received: from MN2PR11MB3565.namprd11.prod.outlook.com (2603:10b6:208:ea::31) by MN2PR11MB4518.namprd11.prod.outlook.com (2603:10b6:208:24f::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.19; Fri, 12 Jun 2020 15:30:25 +0000
Received: from MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::55bb:b065:86c1:1108]) by MN2PR11MB3565.namprd11.prod.outlook.com ([fe80::55bb:b065:86c1:1108%6]) with mapi id 15.20.3088.019; Fri, 12 Jun 2020 15:30:25 +0000
From: "Pascal Thubert (pthubert)" <pthubert@cisco.com>
To: Routing Over Low power and Lossy networks <roll@ietf.org>
CC: "roll-chairs@ietf.org" <roll-chairs@ietf.org>
Thread-Topic: [Roll] Published draft-ietf-roll-unaware-leaves-17.txt
Thread-Index: AQHWQJYkF8cIMqAmH0C7arDxY5eeFKjU4/QQgAA2wZA=
Date: Fri, 12 Jun 2020 15:30:05 +0000
Deferred-Delivery: Fri, 12 Jun 2020 15:29:17 +0000
Message-ID: <MN2PR11MB3565063E1888E31009B8FAB8D8810@MN2PR11MB3565.namprd11.prod.outlook.com>
References: <MN2PR11MB3565F185BC584EBA1680766BD8830@MN2PR11MB3565.namprd11.prod.outlook.com> <CAO0Djp2PVYaEC4HQV4-ZiN7DsOi0qqWfg5DAgO7xCJ46qtihow@mail.gmail.com> <MN2PR11MB356531BE6CDD6C49AD35F3B3D8810@MN2PR11MB3565.namprd11.prod.outlook.com>
In-Reply-To: <MN2PR11MB356531BE6CDD6C49AD35F3B3D8810@MN2PR11MB3565.namprd11.prod.outlook.com>
Accept-Language: fr-FR, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com;
x-originating-ip: [2001:420:c0c0:1001::1fa]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: cb3ac347-470e-4511-1cb1-08d80ee5879a
x-ms-traffictypediagnostic: MN2PR11MB4518:
x-microsoft-antispam-prvs: <MN2PR11MB451885FF25B900EE355DC1C5D8810@MN2PR11MB4518.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0432A04947
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: VghnPlyJg+nFsdYvoxoPtR/uSeYoQqnpRqclkQd8eItWQVsRKYNQo9qZaSvLlyegdbPXO8HuJ3hnSB+LlhSkxXpU6ePFik6dEyM0frmGZ32TOqpJr8kxKpUIiLdY0SsmGGHzns3ae1NKyRUeHncIIXI1nj0IhVMLepSkNhVkuArxlPehvKCIO8fk7QqtewdhFEGl9cyjElkTJsoN+tKlSQHEdc2T7DAcdI4/YlOeXRYZnyheHkovQE+Wr6LvIRl//FCQ4SrLi3Thw0b/We8nh2HKa9haHIXYRGmnZa+E4nCCG8RwWMuaM+Q6OVLDQ1OYUPqpRIGn+kMRQGALmwMufMFFR+9DZ4mT1vrvKb6GzLHK4pDZ20xxlM/7Am3I06oVh4o20thwVAQke5mGQ1HQ7w==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MN2PR11MB3565.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(366004)(346002)(376002)(39860400002)(396003)(136003)(8936002)(4326008)(53546011)(316002)(6916009)(55016002)(186003)(66574014)(166002)(6506007)(450100002)(5660300002)(7696005)(9686003)(71200400001)(64756008)(66446008)(966005)(2940100002)(8676002)(33656002)(76116006)(52536014)(66556008)(83380400001)(66476007)(2906002)(86362001)(66946007)(6666004)(478600001); DIR:OUT; SFP:1101;
x-ms-exchange-antispam-messagedata: GSTH9/SKjWXZ+Dqh/0JWGzvvyy+PZKEnDyyI2QrXD0jM0BLOHDFHEswuDJoDW7gsVvGcqWu97NCvfe4Fb9CKYxwl1NWyfYxXbrXtmrOcW9hYhE0kSvAob/0p3r1ME5prX/cdBxmei3yAbesISd2jSeBUxlxjPQOmENlz624/qVYhvb+5J6D5PKaBt52vbHTcZk9U1cE6rWKqy0N6y3xOyKKWD9bizJifIH4WWNUZ+seg1Is60BLf3JG2gUZj+QBP7qOZHi40wmtD3Wurd5WvdyqfOtr1ee45IwJ3zcHBVtnj/9/IDlZBbCs6+8FVRUF9JjdbPxWa5tPw85VwHqiRdnsvxCgefQzEoT8f8+A7FMcJT05KdF+Ehg92fySHvgSlBD/JbvMVEoQxO82dTds/ngLkdDwLtyGUBl8uWI0nh+Svo/wUZ1RiLmA+HIgiMPQxP2sIMlGk1yAS7Fp5pfGb/K9FNI/qH2bLLZkMZ5VHbw/WnUeMGR6uuwe/PLtYHMUkw98outDNGo4ljLOoFUxtDg==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_MN2PR11MB3565063E1888E31009B8FAB8D8810MN2PR11MB3565namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: cb3ac347-470e-4511-1cb1-08d80ee5879a
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Jun 2020 15:30:25.7119 (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: noGzZ96gaNjQzMq64e+3oBCCOH5LKhuJupwI7Ccg0lViT6+xaINICYHtgKm+ouuL1EsPqYyTyvmVoNfdTbRX/Q==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: MN2PR11MB4518
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com
X-Outbound-Node: alln-core-9.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/roll/JXBWUJ01rRL-YpE8-k5wiWQOOeo>
Subject: [Roll] FW: Published draft-ietf-roll-unaware-leaves-17.txt
X-BeenThere: roll@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Over Low power and Lossy networks <roll.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/roll>, <mailto:roll-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/roll/>
List-Post: <mailto:roll@ietf.org>
List-Help: <mailto:roll-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/roll>, <mailto:roll-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Jun 2020 15:30:35 -0000
Hello Rahul: Excellent comments! Many thanks 😊 > As per our discussion and your summary for the published -17 draft, we should be mandating the use of Updated Target Option. However, I don't see any clear text suggesting so in the draft. Am I missing something? The draft mentions the use of Updated Target Option only in response to the "P" flag. There are sections (for e.g., Section 10.2.2) which still refer to RPL Target Option and not the updated one. There is text (section 6) which still suggests that keep-alive EDAR/EDAC can be sent from 6LR. The MUST I was discussing was to ensure that we do not need to define the anonymous flow (the EDAR from Root to 6LBR without a ROVR). So the updated DAO is a MUST when the ‘P’ flag is set. Else the EDAR is from the 6LR so it is not anonymous anyway. For the general case it is better to use the updated target option because it brings the capability to do more zerotrust protection; but you also mentioned at some point that there’s a cost in memory for the DAO state, in particular in storing mode, that all nodes may not be able to pay. So I made it a SHOULD page 14: “ The modified format is illustrated in Figure 4. It is backward compatible with the Target Option in [RFC6550<https://tools.ietf.org/html/rfc6550>] and SHOULD be used as a replacement in new implementations even for Storing Mode operations in preparation for upcoming security mechanisms based in the ROVR. “ Does that match your expectation? 1. Section 1: "either as a collection tree or with routing back." -> I don't understand what "routing back" means here. That’s the DAO thingy. Collection Tree is a generic name for a tree structure built for AMR-type operations, like our MOP 0. See in the art the CTP https://en.wikipedia.org/wiki/Collection_Tree_Protocol from which our MOP 0 takes inspiration. The other MOPs enable routing back to the device, e.g., for AMI-type operations, and for the sake of history it is inspired by https://tools.ietf.org/html/draft-thubert-roll-fundamentals . What about “ [RFC6550] provides unicast and multicast routing services to RPL- Aware nodes (RANs), either as a collection tree for outwards traffic only, or with routing back to the devices as well. “ > 2. Section 10.2.2 > a. Refers to RPL Target Option and not the Updated Target Option Yes… “ If the "R" flag is set in the NS(EARO), the 6LR MUST inject the Host route in RPL, unless this is barred for other reasons, such as the saturation of the RPL parent. The 6LR MUST use a RPL Non-Storing Mode signaling and the updated Target Option (see Section 9). “ > b. ROVR field addition to the Updated Target Option must be specified in this section Clearly missing, I’ll add it as well “ The DAO message advertising the Registered Address MUST be constructed as follows: 1. The Registered Address is signaled as Target Prefix in the updated Target Option in the DAO message; the Prefix Length is set to 128. The ROVR field is copied unchanged from the EARO. “ > c. As per 8505 TID is optional. However the draft assumes that TID is always copied from the EARO to the Path Sequence of DAO Also correct, I need to MUST it, in 7.1. “ 7.1. Support of 6LoWPAN ND In order to obtain routing services from a 6LR, a RUL MUST implement [RFC8505] and set the "R" and "T" flags in the EARO. “ In 10.2.1 “ 2. Once it has formed an address, the 6LN (re)registers its address periodically, within the Lifetime of the previous Address Registration, as prescribed by [RFC6775], to refresh the NCE before the lifetime indicated in the EARO expires. It MUST set the "T" flag and the TID is incremented each time and wraps in a lollipop fashion (see section 5.2.1 of [RFC8505] which is fully compatible with section 7.2 of [RFC6550]). “ > 3. Section 9. Should we mention that the Option Length MUST be >= 18 if the "F" flag is set? Does that really help? He definition in RFC 6550 is still exactly correct… > Nits: Applied I posted 18 so you can see the diffs; please let me know if that works for you. Also: I’ll need you to update the shepherd report indicating that you carried a sequence of reviews and that the new version concludes that series. Take care, Pascal From: Roll <roll-bounces@ietf.org<mailto:roll-bounces@ietf.org>> On Behalf Of Rahul Jadhav Sent: vendredi 12 juin 2020 10:47 To: Routing Over Low power and Lossy networks <roll@ietf.org<mailto:roll@ietf.org>> Cc: roll-chairs@ietf.org<mailto:roll-chairs@ietf.org> Subject: Re: [Roll] Published draft-ietf-roll-unaware-leaves-17.txt Thanks Pascal for the updates, As per our discussion and your summary for the published -17 draft, we should be mandating the use of Updated Target Option. However, I don't see any clear text suggesting so in the draft. Am I missing something? The draft mentions the use of Updated Target Option only in response to the "P" flag. There are sections (for e.g., Section 10.2.2) which still refer to RPL Target Option and not the updated one. There is text (section 6) which still suggests that keep-alive EDAR/EDAC can be sent from 6LR. Other comments: 1. Section 1: "either as a collection tree or with routing back." -> I don't understand what "routing back" means here. 2. Section 10.2.2 a. Refers to RPL Target Option and not the Updated Target Option b. ROVR field addition to the Updated Target Option must be specified in this section c. As per 8505 TID is optional. However the draft assumes that TID is always copied from the EARO to the Path Sequence of DAO. 3. Section 9. Should we mention that the Option Length MUST be >= 18 if the "F" flag is set? Nits: * "Direction-Oriented Directed Acyclic Graphs" -> It should be Destination-Oriented * an RAN injects -> a RAN injects * "even when the DODAG is operated in Storing Mode DODAGs" -> remove DODAGs. * "such a Ethernet" -> "such as Ethernet" * "Sollicitation" -> "Solicitation" ... multiple places * "set to 0 a prescribed by" -> "set to 0 as prescribed by" * "For the refreshes of the registration, .." -> "For registration refresh, .." * "if the "I" field" -> "If the "I" field" * "A RPL Root SHOULD set the "P" flag in the RPL configuration option" -> "A RPL Root SHOULD set the "P" flag in the RPL DODAG Configuration Option" Best, Rahul On Wed, 10 Jun 2020 at 23:53, Pascal Thubert (pthubert) <pthubert=40cisco.com@dmarc.ietf.org<mailto:40cisco.com@dmarc.ietf.org>> wrote: Dear chairs: This publication attempts to resolve the issues recently raised in the threads with Rahul. The major changes are that : - the support of the updated target option is now a MUST; this simplifies considerably the spec and removes the "anonymous" EDAR. - setting the 'K' flag in the DAO asking for DAO-ACK is now a MUST as well; this avoids weird error paths and ensures that the route is installed. Minors: - require padding the prefix to the next byte in the Target Option - a new bit to place the full address of the advertiser in the prefix in the Target Option Then, editorials, suppression of duplicate text. Please let me know how to proceed from there (WGLC? Update Shepherd statement?) Take care, Pascal > -----Original Message----- > From: Roll <roll-bounces@ietf.org<mailto:roll-bounces@ietf.org>> On Behalf Of internet-drafts@ietf.org<mailto:internet-drafts@ietf.org> > Sent: mercredi 10 juin 2020 17:43 > To: i-d-announce@ietf.org<mailto:i-d-announce@ietf.org> > Cc: roll@ietf.org<mailto:roll@ietf.org> > Subject: [Roll] I-D Action: draft-ietf-roll-unaware-leaves-17.txt > > > 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-17.txt > Pages : 32 > Date : 2020-06-10 > > Abstract: > This specification extends RFC6550 and RFC8505 to provide routing > services to Hosts called RPL Unaware Leaves that implement 6LoWPAN ND > but do not participate to RPL. This specification also enables the > RPL Root to proxy the 6LoWPAN keep-alive flows 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-17 > https://datatracker.ietf..org/doc/html/draft-ietf-roll-unaware-leaves-17<https://datatracker.ietf.org/doc/html/draft-ietf-roll-unaware-leaves-17> > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-unaware-leaves-17 > > > 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<http://tools.ietf.org>. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > > _______________________________________________ > Roll mailing list > Roll@ietf.org<mailto:Roll@ietf.org> > https://www.ietf.org/mailman/listinfo/roll _______________________________________________ Roll mailing list Roll@ietf.org<mailto:Roll@ietf.org> https://www.ietf.org/mailman/listinfo/roll
- [Roll] Published draft-ietf-roll-unaware-leaves-1… Pascal Thubert (pthubert)
- Re: [Roll] Published draft-ietf-roll-unaware-leav… Rahul Jadhav
- [Roll] FW: Published draft-ietf-roll-unaware-leav… Pascal Thubert (pthubert)