From nobody Tue Mar 1 02:38:26 2022 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 50A543A1A2E; Tue, 1 Mar 2022 02:38:17 -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: 7.46.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: roll@ietf.org Message-ID: <164613109720.20196.8808589677605098757@ietfa.amsl.com> Date: Tue, 01 Mar 2022 02:38:17 -0800 Archived-At: Subject: [Roll] I-D Action: draft-ietf-roll-rnfd-00.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: Tue, 01 Mar 2022 10:38:18 -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 : RNFD: Fast border router crash detection in RPL Author : Konrad Iwanicki Filename : draft-ietf-roll-rnfd-00.txt Pages : 25 Date : 2022-03-01 Abstract: By and large, a correct operation of a RPL network requires border routers to be up. In many applications, it is beneficial for the nodes to detect a crash of a border router as soon as possible to trigger fallback actions. This document describes RNFD, an extension to RPL that expedites border router failure detection, even by an order of magnitude, by having nodes collaboratively monitor the status of a given border router. The extension introduces an additional state at each node, a new type of RPL Control Message Options for synchronizing this state among different nodes, and the coordination algorithm itself. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-rnfd/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-roll-rnfd-00 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Sun Mar 6 12:55:58 2022 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 157E23A0C0A for ; Sun, 6 Mar 2022 12:55:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.107 X-Spam-Level: X-Spam-Status: No, score=-7.107 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 z6Hl2WnJnipg for ; Sun, 6 Mar 2022 12:55:50 -0800 (PST) Received: from mail-yb1-xb35.google.com (mail-yb1-xb35.google.com [IPv6:2607:f8b0:4864:20::b35]) (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 DA45D3A0C32 for ; Sun, 6 Mar 2022 12:55:49 -0800 (PST) Received: by mail-yb1-xb35.google.com with SMTP id u10so7469295ybd.9 for ; Sun, 06 Mar 2022 12:55:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=DN6IKYUGJmIYwDGN+jYBJPnyuiwxH8L8iR8j2jjYfVc=; b=LT+fd9EJ/dVpnQICrdnCqWC/tl1mEJDcbIhxB74jJ5F3FpmQpYBRV+EE0VJYJTWqrE rapJ2X8IsL9S81Tm2ImogRL0ae9LbkBcYsLNEPXzwEkRCDnyxmKbMMM1DCK/3Tpu/ztz 9pkfcLblIxYwLFXaQkAncoIE9mwefvMlKMW0VSdr5oxk+kp/nBEQ5pa/seqltkvcRT5W fXQpIKeTJBJh6Y9r14WJmvbVrV5+buHbxxmjsCkmRl0pDekq8YCkjml5wVfXKCuBOjyX 3CqM1M/u+5859zczPBI9kRvxYLEUg7vRXHV81fTHbo7vP18bJIqrKPneEczL3LvBnds/ YPpw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=DN6IKYUGJmIYwDGN+jYBJPnyuiwxH8L8iR8j2jjYfVc=; b=J5h5mFwm/zPeZfElmiZn8CqD6cyjaX32nM8Mz84R6ujFMTo3fqvgBOAMAHw8ou7LCQ ZPdZk3hAl/oW4SkuyENw+bx0XjGGKACO9KXRgQQ1rO3clmS4af4zDh8gT2DUkD9dK1zn DJQwVk/KnB970TYv7vHns37V+k9M3brDhIjslqky3wkaAk9L+wSJpYI791K2DX+NbYvX hP/+i4Uqk5m0tuxKX3D9mOl4BmvAMFb7/DiquGz4eu8VPTvuQSA8H/HJYRpNxy+Whxl1 K/QGb/XnvR7KYERNQJ1szCpfnWJEDmnFo4nynl0q03xvnzF/yXa9Tuh/0okGyrqfhgf9 rJkA== X-Gm-Message-State: AOAM532VhiVe87hJay83SIuDq2UfskIl06AxAIjqfMSZyoYUOof/09Ku 83Ys8kiXFCVBVfNl2OGi1tffjK7QKb2vJKFOS0xxKj2Drzg= X-Google-Smtp-Source: ABdhPJy65q1oRRKmKUPZcCUyNKD5LPXiSikz+385ZgGaTVWBFLdzpyXlmoPXbh4ynlZhuEDcBlpu204DP31y7HdXuZ4= X-Received: by 2002:a5b:787:0:b0:624:107a:6c45 with SMTP id b7-20020a5b0787000000b00624107a6c45mr5589761ybq.24.1646600148308; Sun, 06 Mar 2022 12:55:48 -0800 (PST) MIME-Version: 1.0 References: <164356362763.19666.10893663352366955802@ietfa.amsl.com> In-Reply-To: From: Ines Robles Date: Sun, 6 Mar 2022 22:55:12 +0200 Message-ID: To: roll Content-Type: multipart/alternative; boundary="000000000000ed55c405d992f8d6" Archived-At: Subject: Re: [Roll] WGLC draft-ietf-roll-aodv-rpl-12 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: Sun, 06 Mar 2022 20:55:56 -0000 --000000000000ed55c405d992f8d6 Content-Type: text/plain; charset="UTF-8" Dear all, Thank you very much for the comments received on this draft. The authors are working on addressing them. We still would like to receive further feedback, specially in the use of the MOP=4 and its relation with P2P-RPL: "AODV-RPL uses the "P2P Route Discovery Mode of Operation" (MOP == 4) with three new Options for the DIO message, dedicated to discover P2P routes. These P2P routes may differ from routes discoverable by native RPL. Since AODV-RPL uses newly defined Options, there is no conflict with P2P-RPL [RFC6997 ], a previous document using the same MOP. AODV-RPL can be operated whether or not native RPL is running otherwise." Thank you very much in advance, Ines and Dominique. On Mon, Jan 31, 2022 at 8:52 AM Ines Robles wrote: > Dear all, > > Please find below a new version of aodv-rpl draft. This email starts a > WGLC of one week. > > Please review and send your comments by 5th February. > > Note that this draft updates the MOP to 4 [ > https://mailarchive.ietf.org/arch/msg/roll/yNEWYkKGcrDWYfKxCaCCX96lCUY/] > > Thank you, > > Ines and Dominique. > > On Sun, Jan 30, 2022 at 7:27 PM wrote: > >> >> 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 : Supporting Asymmetric Links in Low Power >> Networks: AODV-RPL >> Authors : Charles E. Perkins >> S.V.R Anand >> Satish Anamalamudi >> Bing Liu >> Filename : draft-ietf-roll-aodv-rpl-12.txt >> Pages : 32 >> Date : 2022-01-30 >> >> Abstract: >> Route discovery for symmetric and asymmetric Peer-to-Peer (P2P) >> traffic flows is a desirable feature in Low power and Lossy Networks >> (LLNs). For that purpose, this document specifies a reactive P2P >> route discovery mechanism for both hop-by-hop routing and source >> routing: Ad Hoc On-demand Distance Vector Routing (AODV) based RPL >> protocol (AODV-RPL). Paired Instances are used to construct >> directional paths, for cases where there are asymmetric links between >> source and target nodes. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-roll-aodv-rpl/ >> >> There is also an htmlized version available at: >> https://datatracker.ietf.org/doc/html/draft-ietf-roll-aodv-rpl-12 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-aodv-rpl-12 >> >> >> Internet-Drafts are also available by rsync at rsync.ietf.org: >> :internet-drafts >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> > --000000000000ed55c405d992f8d6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all= ,

Thank you very much for the comments received= on this draft. The authors are working on addressing them.=C2=A0

We still would like to receive further feedback, spe= cially in the use of the MOP=3D4 and its relation with P2P-RPL:=C2=A0

"AODV-RPL use=
s the "P2P Route Discovery Mode of Operation" (MOP =3D=3D 4) with
   three new Options for the DIO message, dedicated to discover P2P
   routes.  These P2P routes may differ from routes discoverable by
   native RPL.  Since AODV-RPL uses newly defined Options, there is no
   conflict with P2P-RPL [RFC6997], a previous document using the=
 same
   MOP.  AODV-RPL can be operated whether or not native RPL is running
   otherwise."

Thank you very much in advance,
= 

Ines and Dominique.

On Mon, Jan 31, 2022 at 8:52= AM Ines Robles <mari= ainesrobles@googlemail.com> wrote:
Dear all,

Please find below a new version of aodv= -rpl draft. This email starts a WGLC of one week.

= Please review and send your comments by 5th February.=C2=A0

<= /div>
Note that this draft updates the MOP to 4=C2=A0 [https://mailarchive.ietf.org/arch/msg/roll/yNEWYkKGcrDWYfKxCaCC= X96lCUY/]=C2=A0

Thank you,

Ines and Dominique.=C2=A0

On Sun, Jan 30, 2022 at 7:27 PM <internet-drafts@ietf= .org> wrote:

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.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= Supporting Asymmetric Links in Low Power Networks: AODV-RPL
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Authors=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Char= les E. Perkins
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 S.V.R Anand
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Satish Anamalamudi
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Bing Liu
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2=A0 =C2=A0 =C2=A0 =C2=A0 : draft-iet= f-roll-aodv-rpl-12.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 32
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2022-01-30

Abstract:
=C2=A0 =C2=A0Route discovery for symmetric and asymmetric Peer-to-Peer (P2P= )
=C2=A0 =C2=A0traffic flows is a desirable feature in Low power and Lossy Ne= tworks
=C2=A0 =C2=A0(LLNs).=C2=A0 For that purpose, this document specifies a reac= tive P2P
=C2=A0 =C2=A0route discovery mechanism for both hop-by-hop routing and sour= ce
=C2=A0 =C2=A0routing: Ad Hoc On-demand Distance Vector Routing (AODV) based= RPL
=C2=A0 =C2=A0protocol (AODV-RPL).=C2=A0 Paired Instances are used to constr= uct
=C2=A0 =C2=A0directional paths, for cases where there are asymmetric links = between
=C2=A0 =C2=A0source and target nodes.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ie= tf-roll-aodv-rpl/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/ht= ml/draft-ietf-roll-aodv-rpl-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=3Dd= raft-ietf-roll-aodv-rpl-12


Internet-Drafts are also available by rsync at rsync.ietf.org::internet-dra= fts


_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--000000000000ed55c405d992f8d6-- From nobody Mon Mar 7 14:27:00 2022 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 4BC2F3A1018; Mon, 7 Mar 2022 14:26:53 -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: 7.46.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: roll@ietf.org Message-ID: <164669201324.9148.2727309154158644463@ietfa.amsl.com> Date: Mon, 07 Mar 2022 14:26:53 -0800 Archived-At: Subject: [Roll] I-D Action: draft-ietf-roll-aodv-rpl-13.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, 07 Mar 2022 22:26:53 -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 : Supporting Asymmetric Links in Low Power Networks: AODV-RPL Authors : Charles E. Perkins S.V.R Anand Satish Anamalamudi Bing Liu Filename : draft-ietf-roll-aodv-rpl-13.txt Pages : 33 Date : 2022-03-07 Abstract: Route discovery for symmetric and asymmetric Peer-to-Peer (P2P) traffic flows is a desirable feature in Low power and Lossy Networks (LLNs). For that purpose, this document specifies a reactive P2P route discovery mechanism for both hop-by-hop routing and source routing: Ad Hoc On-demand Distance Vector Routing (AODV) based RPL protocol (AODV-RPL). Paired Instances are used to construct directional paths, for cases where there are asymmetric links between source and target nodes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-aodv-rpl/ There is also an htmlized version available at: https://datatracker.ietf.org/doc/html/draft-ietf-roll-aodv-rpl-13 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-aodv-rpl-13 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Wed Mar 9 07:52:25 2022 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 A21643A0BB3; Wed, 9 Mar 2022 07:52:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 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, NICE_REPLY_A=-0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=lupinlodge.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 fPV8wMIBEFP9; Wed, 9 Mar 2022 07:52:17 -0800 (PST) Received: from delivery.mailspamprotection.com (delivery.mailspamprotection.com [185.56.84.8]) (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 1A5413A0122; Wed, 9 Mar 2022 07:52:16 -0800 (PST) Received: from 246.206.208.35.bc.googleusercontent.com ([35.208.206.246] helo=giowm1055.siteground.biz) by se18.mailspamprotection.com with esmtps (TLSv1.2:AES128-GCM-SHA256:128) (Exim 4.92) (envelope-from ) id 1nRybk-000Ir1-Oo; Wed, 09 Mar 2022 09:52:16 -0600 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lupinlodge.com; s=default; h=In-Reply-To:From:Cc:References:To:Subject: MIME-Version:Date:Message-ID:Content-Type:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=pOhD5fW6VqPkBwivaFXQS/is+K9Yj4p+meQoNF/Mzas=; b=Q9y4CCIPzEcLEsVdjMhAS/a86G XZYSZWhZ0nHQ55Eh+CCtJFH9K2SkHcfhAd2PGiDlIHuQ+9u7cEKg0hj1TknTRAc0v8uGYOgt21kkW mSwRskfCXA3ffnR08FnRSG1Xolswzb3TGBN3kDo7KQ0B8oQ4mBoRB9NSQUUPVuIwWLt4=; Received: from [99.51.72.196] (port=61036 helo=[192.168.1.72]) by giowm1055.siteground.biz with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.90-.1) (envelope-from ) id 1nRybj-000PdM-Rc; Wed, 09 Mar 2022 15:52:12 +0000 Content-Type: multipart/alternative; boundary="------------ulYUG5I1t4GO1mXqQH0LNgb5" Message-ID: Date: Wed, 9 Mar 2022 07:52:10 -0800 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.6.1 Content-Language: en-US To: "Pascal Thubert (pthubert)" References: <164356362763.19666.10893663352366955802@ietfa.amsl.com> Cc: Routing Over Low power and Lossy networks , "S.V.R Anand" From: Charles Perkins In-Reply-To: X-Originating-IP: 35.208.206.246 X-SpamExperts-Domain: giowm1055.siteground.biz X-SpamExperts-Username: 35.208.206.246 Authentication-Results: mailspamprotection.com; auth=pass smtp.auth=35.208.206.246@giowm1055.siteground.biz X-SpamExperts-Outgoing-Class: ham X-SpamExperts-Outgoing-Evidence: Combined (0.09) X-Recommended-Action: accept X-Filter-ID: Pt3MvcO5N4iKaDQ5O6lkdGlMVN6RH8bjRMzItlySaT9P2pH8F8B0TkJ3cRV6AlxcPUtbdvnXkggZ 3YnVId/Y5jcf0yeVQAvfjHznO7+bT5wCZIDtDtG6u4+mtG65Ad5NGXpXDZ9q9SfFuTjzTYcXWMuf YNrAYlXlS+8CgcYchaTorXjKZ8hJHfsMYCHTL63+23mBbZZ3UItFDK+3wbwiItwfqviEA/vTl/F/ EzXFCnqndGqwUO1HyreDVA27IAhcJODXbtOodkPED+RkHjVGHwjCb0vqkI3EMl8GO9R0zySxG15V srLJzy107IRH8AbaTxDXk5cqvgj8dcQpa+E3++OlTK5FqrxiqfkGNjPNZs/ne3LK8ihzmsY4JQcn vFn7tVNgYSjxFBAX9nmP18UkLI0P9+T7Qp7zpNqTfBw38n6wIbovQQmgPQewLpKnjva0BkjG1dbQ zPgHtIwXtZT0cHgVNAFqthsqHsMas60ctbI8F/IJRA8ZF8C5AnJBxSFDLnQKyOOdNV2reR3vzxDX NzDt3skp6X1z4vnXAvsYlMaMuKFo2/LhRTCj6V1DqZJATOfAMOm/HJU4B9MUbVvRiuclOr+zdCAF 883MRYOAt+TBXGgZNtSVg8KO9+U23r3YEDZwTFWhChNgmER8tESSYipCkjtDDwc1Gq8wGw3Hlp/J 0IdteI/zTbpcDI9MsmV317NirEYyqwqMBGrw8ELiqJ2Lnubrt6xFfUVlzWE+fUwE/Xy9bqh2t87x wDNJ1ZQnkG4rgMcOadSlmA4Mg6UQtNxCHahZfsjvoDKdqQReE7opol7/zxbDwFIVzeFgpWdBcxw3 qqhc+N6cuEg4XWh5FtyOJ22t24VloPyX9BGeStAmYmzRI832YO+xrG5Cb5w5Cn249IiGubUTLA7G bwOg30XwrrYViEuGagSIN7/O33R5gp+c5sKchOteOmUKeQfDj3Ltlm5R44ab7iqTWcdHVhEVniih uDwEGDcmr6e3OPSxEN5QEet+r0zJa01AeQWqa3ey8Ttknde1hbQF2hNBLaCL8Doo2inzBkL8lBss qwADOaYShsJqCtCu/O2pU0N1S6O/n5DbqB7JqR5W38xVr2bjO41FyBEqIaDudcVplPGo8O3fyoE/ EIkj7suaqO/fRxTLjYfcEBFky7CHK1b09CCFodXXRkJa5kttv+iL83U6k3ZQW2oP6jmYyyqnCGjk q4+/nSIiLoVyj+6JgVp2ls3SLvmmH08hpnUWu8Jz3L6MyGnDIpSchlco6RIDoNg/DowYF5X92G1X xuvnCFAIOL4E8mR+f5GXncX0bx4kQWOIIp8cwMiDN0G2V9om2+V6MS+4ayUpOtEhdxekWDmK9g== X-Report-Abuse-To: spam@quarantine1.mailspamprotection.com Archived-At: Subject: Re: [Roll] WGLC draft-ietf-roll-aodv-rpl-12 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, 09 Mar 2022 15:52:23 -0000 This is a multi-part message in MIME format. --------------ulYUG5I1t4GO1mXqQH0LNgb5 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hello Pascal, Did you mean that AODV-RPL is the replacement protocol for P2P-RPL? Or that it could be viewed as a replacement protocol for RPL? I hope you will excuse my long delay in seeking this clarification. Your email below got overwhelmed in my inbox, but thank goodness not lost. We just issued revision ...-13 for AODV-RPL and tried to respond to your suggestion.  Please take a look! Naturally Yours, Charlie P. On 1/31/2022 8:02 AM, Pascal Thubert (pthubert) wrote: > > About “ > > AODV-RPL can be operated whether or not native RPL is running otherwise. > > “ > > I agree that the advertisements can be differentiated; still it’s > simpler to discourage using both protocols in the same network. Why do > so since this is essentially the replacement protocol? > > Keep safe; > > Pascal > > *From:* Roll *On Behalf Of *Ines Robles > *Sent:* lundi 31 janvier 2022 7:52 > *To:* roll > *Subject:* [Roll] WGLC draft-ietf-roll-aodv-rpl-12 > > Dear all, > > Please find below a new version of aodv-rpl draft. This email starts a > WGLC of one week. > > Please review and send your comments by 5th February. > > Note that this draft updates the MOP to 4  > [https://mailarchive.ietf.org/arch/msg/roll/yNEWYkKGcrDWYfKxCaCCX96lCUY/] > > Thank you, > > Ines and Dominique. > > On Sun, Jan 30, 2022 at 7:27 PM wrote: > > > 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           : Supporting Asymmetric Links in Low Power > Networks: AODV-RPL >         Authors         : Charles E. Perkins >                           S.V.R Anand >                           Satish Anamalamudi >                           Bing Liu >         Filename        : draft-ietf-roll-aodv-rpl-12.txt >         Pages           : 32 >         Date            : 2022-01-30 > > Abstract: >    Route discovery for symmetric and asymmetric Peer-to-Peer (P2P) >    traffic flows is a desirable feature in Low power and Lossy > Networks >    (LLNs).  For that purpose, this document specifies a reactive P2P >    route discovery mechanism for both hop-by-hop routing and source >    routing: Ad Hoc On-demand Distance Vector Routing (AODV) based RPL >    protocol (AODV-RPL).  Paired Instances are used to construct >    directional paths, for cases where there are asymmetric links > between >    source and target nodes. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-roll-aodv-rpl/ > > There is also an htmlized version available at: > https://datatracker.ietf.org/doc/html/draft-ietf-roll-aodv-rpl-12 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-aodv-rpl-12 > > > Internet-Drafts are also available by rsync at > rsync.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 --------------ulYUG5I1t4GO1mXqQH0LNgb5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit Hello Pascal,

Did you mean that AODV-RPL is the replacement protocol for P2P-RPL?  Or that it could be viewed as a replacement protocol for RPL?

I hope you will excuse my long delay in seeking this clarification.  Your email below got overwhelmed in my inbox, but thank goodness not lost.

We just issued revision ...-13 for AODV-RPL and tried to respond to your suggestion.  Please take a look!

Naturally Yours,
Charlie P.



On 1/31/2022 8:02 AM, Pascal Thubert (pthubert) wrote:

About “

AODV-RPL can be operated whether or not native RPL is running otherwise.

“

I agree that the advertisements can be differentiated; still it’s simpler to discourage using both protocols in the same network. Why do so since this is essentially the replacement protocol?

 

Keep safe;

 

Pascal

 

From: Roll <roll-bounces@ietf.org> On Behalf Of Ines Robles
Sent: lundi 31 janvier 2022 7:52
To: roll <roll@ietf.org>
Subject: [Roll] WGLC draft-ietf-roll-aodv-rpl-12

 

Dear all,

 

Please find below a new version of aodv-rpl draft. This email starts a WGLC of one week.

 

Please review and send your comments by 5th February. 

 

Note that this draft updates the MOP to 4  [https://mailarchive.ietf.org/arch/msg/roll/yNEWYkKGcrDWYfKxCaCCX96lCUY/] 

 

Thank you,

 

Ines and Dominique. 

 

On Sun, Jan 30, 2022 at 7:27 PM <internet-drafts@ietf.org> wrote:


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           : Supporting Asymmetric Links in Low Power Networks: AODV-RPL
        Authors         : Charles E. Perkins
                          S.V.R Anand
                          Satish Anamalamudi
                          Bing Liu
        Filename        : draft-ietf-roll-aodv-rpl-12.txt
        Pages           : 32
        Date            : 2022-01-30

Abstract:
   Route discovery for symmetric and asymmetric Peer-to-Peer (P2P)
   traffic flows is a desirable feature in Low power and Lossy Networks
   (LLNs).  For that purpose, this document specifies a reactive P2P
   route discovery mechanism for both hop-by-hop routing and source
   routing: Ad Hoc On-demand Distance Vector Routing (AODV) based RPL
   protocol (AODV-RPL).  Paired Instances are used to construct
   directional paths, for cases where there are asymmetric links between
   source and target nodes.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-roll-aodv-rpl/

There is also an htmlized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-roll-aodv-rpl-12

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-aodv-rpl-12


Internet-Drafts are also available by rsync at rsync.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

--------------ulYUG5I1t4GO1mXqQH0LNgb5-- From nobody Wed Mar 9 07:58:25 2022 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 5ED4E3A0771 for ; Wed, 9 Mar 2022 07:58:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.605 X-Spam-Level: X-Spam-Status: No, score=-9.605 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_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=R4EsMjE4; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=0QhaL4IZ 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 hCAoPxP7O7sk for ; Wed, 9 Mar 2022 07:58:18 -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 8E7973A0C66 for ; Wed, 9 Mar 2022 07:58:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20609; q=dns/txt; s=iport; t=1646841498; x=1648051098; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=T6BMD+a+jW5+Tb7ywjr5lXW6ibekAjY0qLJVQSG+TU8=; b=R4EsMjE4OFK1l/hRyvkQQ+rHfjeKfYqA8qaPc5pqtZgaO/X8dWf6MgVO 8RfDGzCoMcVOXFG7ZWNG+cdNDpd4eA1x3l9pVprzSINeGW1+xP27Bj0TI WcQsCkxb0SOJ7uKZ0deyeY0WDvacT4TPz5TzKnZdNRXFRSMpN4MdZDPUT s=; X-IPAS-Result: =?us-ascii?q?A0ALAABNzShimJldJa1aHAEBAQEBAQcBARIBAQQEAQGCB?= =?us-ascii?q?gcBAQsBgSAxVn5aN0SEVINKA4RZYIUQgwIDgROVCIUWgS4UgREDVAsBAQENA?= =?us-ascii?q?QEqAQoMBAEBhQcCF4QKAiU0CQ4BAgQBAQEBAwIDAQEBAQEBAwEBBQEBAQIBB?= =?us-ascii?q?gQUAQEBAQEBAQEUCQcGDAUOEAUihWgNhkIBAQEBAwEBEBEKEwEBLAsBDwIBC?= =?us-ascii?q?A4DBAEBKAMCAgIlCxQJCAIEDgUigmIBgg5XAy4BDqFIAYE6AoofeoExgQGCC?= =?us-ascii?q?AEBBgQEgTcBAwIOQYJ/GII3AwaBPAGDEIMDVkoBAYcSJxyBSUSBFSccgjA3P?= =?us-ascii?q?oJjAQECAReBDAUBCggBAzUWCYJkN4IulgFdaARRAhQNOj1CLwofRZVdiV2Nf?= =?us-ascii?q?JJrCoNJiwqLH4lCBS6Dc4wslQ6DBZZVjROUKAYIhQcCBAIEBQIOAQEGgWE6O?= =?us-ascii?q?jFwcBUaISoBggoBATJRGQ+OIAwNCYNQhRSFSnU4AgYBCgEBAwmPOII3AQE?= IronPort-PHdr: A9a23:U5otfRxlYHK4sRPXCzPZngc9DxPP8534PQ8Qv5wgjb8GMqGu5I/rM 0GX4/JxxETIUoPW57Mh6aLWvqnsVHZG7cOHt3YPI5BJXgUO3MMRmQFoCcWZCEr9efjtaSFyH MlLWFJ/uX+hNk0AE8flbFqUqXq3vlYv IronPort-Data: A9a23:tDkqK6LMx92W6owDFE+R65UlxSXFcZb7ZxGr2PjKsXjdYENS0TcOm moWXD/Va/zbYGL1fI11b4i1o0NS7JDRn4dmSwod+CA2RRqmiyZq6fd1j6vUF3nPRiEWZBs/t 63yUvGZcIZsCCW0Si6FatANl1EkvU2zbue6Wbas1hxZH1c+En960UM7wYbVv6Yx6TSHK1LV0 T/Ni5W31G+Ng1aY5UpNtspvADs21BjDkGtwUm4WPJinj3eC/5UhN6/zEInqR5fOria4KcbhL wrL5OnREmo0ZH7BAPv9+lrwWhVirrI/oWFih1IOM5VOjCSuqQQe+4sXLNVEdntShhuPgsFey o9JvLqvHFJB0q3kwIzxUjFCGC14eKZB4rKCez60sNeYyAvNdH6EL/dGVR5te9ZHvLcsRzgTr pT0KxhVBvyHr/qqwK+xR/Nwrs8iN8LseogYvxmMyBmJV698Gc2aHvqiCdlw+xIfwcVuDNHiW Ns/bRFqbT/lcxlrEwJCYH45tL742iagG9FCk3qepaMt52ne1CR1zaDsNt7SdtOHA85Smy6wr 2TP+WjRDxoXct2e0jHD/2iqi/OJnCWTcJgVELmQ9/N2jhuU3GN7NfENfUGwrf/8gUmkVpcFb UcV4SEp66M18SRHU+URQTWUiVOopjFEROZVHsM89RCiyPDQ6iCGUz1soiF6VPQqs8o/RDoP3 1CPns/0CTEHjFFzYS/BnltzhW7pURX5PVPudgdfF1pZvIOLTJUby0OREY45T8ZZm/WsQWmoq w1muhTSkFn6YSQj7aSw/VndjymroPAlpSZqu12HBwpJAu6FDbNJiqSy4lTdqP1HNovcFB+Kv WMPnI6V6+Vm4XCxeM6lHbtl8FKBvqvt3NjgbbhHRMVJG9OFoCLLQGyoyGsiTHqFy+5dEdMTX GfduBlK+LhYN2awYKl8buqZUpp2k/e+SY69BqqINbKih6SdkifarEmCgmbNgAjQfLQEysnTx L/CK5/3VCZGYUiZ5GPrHLt1PUAXKtAWnDOPGs+TI+WP2ruFb3ndUqYeLFaLdYgEAFCs/m3oH yJkH5LSkX13CbSmCgGOqNJ7BQ1UcRATWM6nw+QKJ7XrClc3RwkJVaSLqZt/INMNokigvrqSl p1LchUEkgCXaLyuAVjiV02Pn5u0BMch9y1nZXJwVbtqslB6CbuSAG4kX8NfVdEaGCZLlJaYk 9Ftlx28P8ly IronPort-HdrOrdr: A9a23:W5u7Ia1uiPgjNSijXjJ7EgqjBQRyeYIsimQD101hICG9Lfb4qy n+ppomPEHP5wr5AEtQ5uxpOMG7MBThHO1OkPcs1NaZLUbbUQ6TTL2KgrGSuAEIdxeOk9K1kJ 0QD5SWa+eAQ2SS7/yKmjVQeuxIqLLsnczY5pa9854ud3AWV0gK1XYeNu/vKDwPeOAwP+tBKH Pz3LsimxOQPVAsKuirDHgMWObO4/fRkoj9XBIADxk7rCGTkDKB8tfBYlml9yZbdwkK7aYp8G DDnQC8zL6kqeuHxhjV0HKWx4hKmeHm1sBICKW3+4gow3TX+0WVjbZaKvi/VQMO0aWSAZER4Z 7xSiIbToZOArXqDyeISFXWqlDdOX0Vmg7fIBej8AveSIrCNWoH4w4rv/MCTvMfgHBQ5+2UmZ g7rF6xpt5ZCwjNkz/64MWNXxZ2llCsqX5niuILiWdDOLFuIoO5gLZvtH+9Kq1wVx4SKbpXZ9 VGHYXZ/rJbYFmaZ3fWsi1mx8GtRG06GlODTlIZssKY3jBKlDQhpnFoiPA3jzMF7tYwWpNE7+ PLPuBhk6xPVNYfaeZ4CP0aScW6B2TRSVbHMX6UI17gCKYbUki95qLf8fEw/qWnaZYIxJw9lN DIV05Zr3c7fwb0BciHzPRwg1nwqaWGLELQI+1llu1EU+fHNcjW2AW4OSQTr/c= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.90,167,1643673600"; d="scan'208,217";a="821205157" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Mar 2022 15:58:17 +0000 Received: from mail.cisco.com (xbe-aln-003.cisco.com [173.36.7.18]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 229FwH5m015613 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Wed, 9 Mar 2022 15:58:17 GMT Received: from xfe-rtp-005.cisco.com (64.101.210.235) by xbe-aln-003.cisco.com (173.36.7.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Wed, 9 Mar 2022 09:58:17 -0600 Received: from xfe-rtp-005.cisco.com (64.101.210.235) by xfe-rtp-005.cisco.com (64.101.210.235) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Wed, 9 Mar 2022 10:58:16 -0500 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xfe-rtp-005.cisco.com (64.101.210.235) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14 via Frontend Transport; Wed, 9 Mar 2022 10:58:16 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Mrg9v4aJfvm7ffPN1ja4cg1n73pUPFPGF+NRPwMeWRPhV0VVRodHpizZjNiC9AcJ8xTb7hWPCeDpZKUxE/Vd6kqb3U4CiDc+6nxSTvP3srRN0ERoGVDxr/MfbDFZMAc1hhZlosOtoM7zD8X3mmilhvcUCmfmjny6v5EggXkv8WOOdn/xsoj14KwQ4uyVmW5B96x2LyEuBvrvDP//kiaBjgIYHJbQFDIGPyYw+Ubiko/0I73tNtmbTe8gxxlBxx0jU8deVikBg09GLMW9BOWrJanNmZzqVjtMLu1WM+FeKZvzjfcQ3pMB+3IdKaN4BwyhqFTDvM6Wkd98bxFJG3kUAg== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=T6BMD+a+jW5+Tb7ywjr5lXW6ibekAjY0qLJVQSG+TU8=; b=DL3U18LNNwKx6dGAZiF2OTi/KcKkICBLu6NbQjAMiJpZByyFhwFYHB5pCKjbGr7cLJGl4E7Bg+bGMYTSSvq3T2NW2oI12zRf9C0isdwyt9LtNquzVlF4sw9r1Uks6wUZ1sA/xl924fDzBRiynvQRad54kd/5VaaQbr1PesXl1Fzt4FMpnOX2vgBEIhFT/tzrlRxdBBu6/YzGcYwHyNEH2+YCfZ4c/bfvpeUkiN3FCCuCzGWMhPB0HfW0Fbz6+kLXEkytoiUPH/c5mFtnQIz8FPo8fqEsr/43L0s1zr/WZx8G25pVkxzpp+oSaZE22r02SN+Q1kOuluPdJembKLqWWg== 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=T6BMD+a+jW5+Tb7ywjr5lXW6ibekAjY0qLJVQSG+TU8=; b=0QhaL4IZ6VKWnLJQw+14w9xyon2GfU7TVApx/T0nDou/Ka+wv4+TvYJJnYXEP5oslfTV3kI350byamO/rdH8o4+66nU9Kn/iAT6kvRgm5XIOColvYBm6ND/Fx7nNTjelP+00Onghv2vQDRIk0hYYPLO66ifJg5SsWhGWT/hN1rM= Received: from SJ0PR11MB4896.namprd11.prod.outlook.com (2603:10b6:a03:2dd::20) by DM8PR11MB5718.namprd11.prod.outlook.com (2603:10b6:8:31::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5038.16; Wed, 9 Mar 2022 15:58:13 +0000 Received: from SJ0PR11MB4896.namprd11.prod.outlook.com ([fe80::5d33:9c3c:f79a:2a4b]) by SJ0PR11MB4896.namprd11.prod.outlook.com ([fe80::5d33:9c3c:f79a:2a4b%5]) with mapi id 15.20.5038.027; Wed, 9 Mar 2022 15:58:13 +0000 From: "Pascal Thubert (pthubert)" To: Charles Perkins CC: Routing Over Low power and Lossy networks , "S.V.R Anand" Thread-Topic: [Roll] WGLC draft-ietf-roll-aodv-rpl-12 Thread-Index: AQHYFm87VS3/BJqAm0GAoUNE+YHq+Kx9Sc8wgDokmACAAAGw+g== Date: Wed, 9 Mar 2022 15:58:13 +0000 Message-ID: References: <164356362763.19666.10893663352366955802@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 90875dc0-d05c-4d51-7617-08da01e59df1 x-ms-traffictypediagnostic: DM8PR11MB5718:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 4Cubn6LACTI7eqjLwg70ArrkBBxeXivNskCaHf7H7eDy47bYYnIT4dmN961iHqU5Kp+YTVDbtgLOsJv7O74fr6LlTJZ9fySHCf92KFphHQaFrK5swmLgfkNZVgQA9lR+v6eYIwCG7dTQKAIz5Rz3Vwu8HWLeVgiXvymQEUt73sFwHq9t1ekZLhDSzDTYWjB4tIGAnVnRPvXoq3LgZAYWD33N4hswrURkheaICTV6SkIs7eqfqCHuGkuVqryyOYpG57X+Fz9zc5zD3ZdP70fZNuMvy9f9xtfRZF5KQMlzBsSNqxotJM3C0Gs8S6NwD2XJNhavRLO3ZWe27Fm3+xZ0wZ8vel0NeKIXZS7qRcqpXfnvdYBvgitYV5Zpmbcv+6tPQMdgZfS8Xs7rriCbrfHY2lXMamTZ2EtfmVEsdSGLZ4yYI3paoD2cHeG6AYSbocJHVjYFH/1SPsP011Z40x0N69C6xnDJRRUTL9iHlE11o/BiLWOJgc22I9Svj2YCAkGJvDhhWcUvNiPKvH6BSdeIKMOgywn4N9dHg6cqYfo2zmog6jj9vc6MS530TI8L5yUi4ttNIg/tDpKZDg9KJYFlv/tLXYo0cmZaFIfdk91Jtqm9xhQESPF58w9fYmlpVK9gGYhMxRpiIy0xMKrp1ZNekC89q2iQGnC7doYbr8/YO9rcidRMdW6iWXMic5AHNYYh+H9FMof5bfGGpHcY8EQ/jSerWt7dvB3BEkyeDhYs5uy21ENv+8DD+4pbmtuUL6mCjEKHwL4X6jRkxzodg+3owBZ++ZM9AMSXuLFNQpkYqbgalPeY71EaiszGCOuPDiGSGAJUnrVaDsAGaocMkmd1iLdmOjqA+oo6urbsollJb1ZezKNldLcLkZqneW3KCKo8 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SJ0PR11MB4896.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(66446008)(5660300002)(91956017)(8676002)(64756008)(66556008)(66946007)(66476007)(76116006)(33656002)(4326008)(2906002)(316002)(166002)(6916009)(8936002)(36756003)(54906003)(38100700002)(122000001)(508600001)(38070700005)(6486002)(86362001)(71200400001)(6512007)(6506007)(55236004)(53546011)(66574015)(2616005)(966005)(26005)(83380400001)(186003)(45980500001)(244885003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?utf-8?B?T0R4L3ZWd3R4RnlDUWpQYSs0MTNpZmRVOGJoNjIxNzJPWWhoUmVHb1BXdGhu?= =?utf-8?B?Y2I5NEpRWFJUT0RIWEZOdjBpSFpQNlZwc1Nnbkh2L01oR05YQTZMZUFnYnBh?= =?utf-8?B?QnBvK2M1c2RnWUpQWlpTYzhaNjExWkQ1TXh1bmgzTXF2a3dRT0NwNERhb1hN?= =?utf-8?B?QTJ4SUJKRnA5cWFtTmNTdnYvcVQ1dE9oUVBwUVpGMnJ2N0NJWktpNHdhbzZ3?= =?utf-8?B?TUlKRTRaTEp5dk9KWmJOaFdTUTJIdXlBaWp3NFlMeDVpMkR4ZVM4WmVLY1Bs?= =?utf-8?B?dzkxNi9GeHMwdW1Fb2xFbmNIcEhLYVlvaGxqZzE3ejlhdHlFYUZsUkhGY29Y?= =?utf-8?B?QlZhdVdTcUNoV1J4bDZiaFNrczc3R1RqMmR4dlFmNzFUdUo2aFFBN2hkOCth?= =?utf-8?B?WjJvTi8vUnFkSjVuWDYzZE04azFaTkYybksxQm5kRHFUKzkxZ3hsREcxMFhj?= =?utf-8?B?Q3dSYjB2RmxTK21GNDgrOEMzNlc5cFFaTDBoT0FvaWkrOHdoQkNveUxRcjlF?= =?utf-8?B?VEpiVkowc1VBbkFLbUhpNUcrTTdRSHVIZytkSFN1U05DR2YvT1JaNW9IUWVl?= =?utf-8?B?TDZXenl0azdHZXE3TlZEZHNiLzZsY2VFMW1YN1RVb2tXeHRuTUlldlJIdWRG?= =?utf-8?B?ek9Xd2pVVVdPK2gySW5RL0tNTWlHRCtDVHlhYU1XRWVhNllkTTRtTTNCT3RK?= =?utf-8?B?dWFjSklNZkJlMlZ6SndYN20vc2RGWVgzZjJaVXg2d2lENSs5Wm9NVk82QTAx?= =?utf-8?B?Zm1ScnEyTS9xQlUyb3c3L2k3TjdzYVJRRGJURGM0Szl2NXNjOGZMbUFyQndY?= =?utf-8?B?WisxUHkxUnd4NHpJekVoSzQ2QkNzOUlhbksyT0NQZ051SXN6UkdtWlZFUkJi?= =?utf-8?B?NE1wd3NYeEU2YStrenZOTE9oR2hxaXZyV1dUS2pyQk1kR0x4dXVwT3NsTzVU?= =?utf-8?B?Ky8xRVlNTkFCTjVvMHoxalR4Zy96UnFNTzhNRFBXQ0Q1ZHRrSWc5eHM5UDJB?= =?utf-8?B?ejVtMjA1NTFDcDExMyt3TVVCb3E0REU5eVlHdk51ZUUxbWp3T01kbnNNdnNx?= =?utf-8?B?clJhRzRjVjhNVWdUano1eDl3YytLcm1jZXJxNXU3dVl5dlhFKzROTDlBUnVS?= =?utf-8?B?VGJFNmlJNWgrd3NqQ2Znd1VzUWxKOGJvSUhSMEg0ejdZVlJ2N2J1bFc0cTdr?= =?utf-8?B?RjFub3NJaDI1Nk5yVnl2cms2VmpuY0xjaERYWitKTnBVNExLcFZGSGNSd3dT?= =?utf-8?B?dTM4VWdlZzVKeUlUVzVzbDFjQnZ1a3M5U1BsR2FDK3lBc2t1Z1ZWS1lsZWZS?= =?utf-8?B?SkNtSnFmV2xNY0Q4NlpuNDh6dlRnWXRkejVpUS90ejVoQnVjRXg4dUpRUmhI?= =?utf-8?B?ZWhYS3VsZW9KUUhWWXBPWVhQVGRHekNWSGE2VDFoZ05UdjVSM1dQMy9lQyt3?= =?utf-8?B?N1FjbnU3ejYzZkloV284a2s2OGFYUG41MWxsMjUrWVdzbFB5R2VrUXMxcy9E?= =?utf-8?B?N3YyOHBHSDZaWFdob2xudDV2V1ZNK1BPQUN0TzBhVmlJRm5iZ2wrbTZGQkYy?= =?utf-8?B?M0d3UTRad3FOZjVuMGlvb2VKRjBOV2JiUVNIeEE0UVlKSllpaHptZlZ2Wi9h?= =?utf-8?B?c1NuUllsUTBxZVZtUklOQ25NUllkcFRYcUJERFVUaEdHYTNjWkRVSW96K3NT?= =?utf-8?B?V3V3RXRMWWl3bTJhY3hXQkE3bHlXK1hTN2o4aSt3QzZRNTluZ0llclVQN3dO?= =?utf-8?B?dlVodUJCaFRhZUx6VFJyS01lOEJ0Z0ZqcFJPa3ZhNVp0L0haSXZRamdxUzdz?= =?utf-8?B?WkpJTTZsbVBHaVdieW9LK3RYVi91UHJsSmpXK3RwYXJsOXNqLzVNbURXNUVK?= =?utf-8?B?Sm9rUEpyVWM0eDdHamJFcjhiRWZ0ZFM1bmZPeERza3RnTnpVQXNZZFVraFFr?= =?utf-8?B?RmcvVFBYT0dqT1p1VlRTSnM4U0doVk15dDJ6ekFBd0FnbGVhTzB2UVZzdXhX?= =?utf-8?B?OHRiaEtHUkQ5MGVOSkZBaUJ6NHJJUVZIeFEwdEFhNWxMQ2FCNm4wWkVLTW5p?= =?utf-8?B?VlRETzM1dzFUWmZjK1NwZW5nTG5iNC9odFM4ZXdxbk55eWVkVzBYWitLWHUw?= =?utf-8?B?eDNjOG1XMTQ2SUFDYi8va2Q1a1BCSXAwVlZBT092TzBQYTRsK1ZvVGpNTmN3?= =?utf-8?Q?ecg1h5xFIjXVrpvOPAyxJOs=3D?= Content-Type: multipart/alternative; boundary="_000_FE7C761CA30849BCB7678A44557D5116ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SJ0PR11MB4896.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 90875dc0-d05c-4d51-7617-08da01e59df1 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Mar 2022 15:58:13.3912 (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: IJft1HTbB5hj5veYy8duk0KaMqSFGp+w14rtOYtIjRn3j1XKJwDF6WnoCKm7anvMQk+GO//kzdrRJyhzFDj2yg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM8PR11MB5718 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.18, xbe-aln-003.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: Re: [Roll] WGLC draft-ietf-roll-aodv-rpl-12 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, 09 Mar 2022 15:58:24 -0000 --_000_FE7C761CA30849BCB7678A44557D5116ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gQ2hhcmxpZQ0KDQpUaGUgQU9EViBmbGF2b3IgY29tcGxldGVzIHRoZSBSUEwgZmFtaWx5 LiBJdCByZXBsYWNlcyBQMlAgKHdoaWNoIHdhcyBleHBlcmltZW50YWwpIGFzIHRoZSByZWZlcmVu Y2UgcmVhY3RpdmUgdmFyaWF0aW9uIG9mIFJQTC4NCg0KVGhlIG9yaWdpbmFsIFJQTCBpcyBwcm9h Y3RpdmUgYW5kIGRpc3RyaWJ1dGVkOyBpdCByZW1haW5zIGFzIHRoZSBjZW50cmFsIG9wdGlvbi4N Cg0KQXQgdGhlIG90aGVyIGV4dHJlbWUgZnJvbSByZWFjdGl2ZSwgd2UgZmluZCByb3V0ZSBwcm9q ZWN0aW9uIHRoYXQgaXMgdGhlIFNETiAoY2VudHJhbGl6ZWQpIHZhcmlhdGlvbi4NCg0KVG9nZXRo ZXIgdGhvc2UgMyBwcm92aWRlIGEgY29tcHJlaGVuc2l2ZSB0b29sIHNldCBmb3IgTExOc+KApg0K DQoNClJlZ2FyZHMsDQoNClBhc2NhbA0KDQpMZSA5IG1hcnMgMjAyMiDDoCAxNjo1MiwgQ2hhcmxl cyBQZXJraW5zIDxjaGFybGllcEBsdXBpbmxvZGdlLmNvbT4gYSDDqWNyaXQgOg0KDQrvu78gSGVs bG8gUGFzY2FsLA0KDQpEaWQgeW91IG1lYW4gdGhhdCBBT0RWLVJQTCBpcyB0aGUgcmVwbGFjZW1l bnQgcHJvdG9jb2wgZm9yIFAyUC1SUEw/ICBPciB0aGF0IGl0IGNvdWxkIGJlIHZpZXdlZCBhcyBh IHJlcGxhY2VtZW50IHByb3RvY29sIGZvciBSUEw/DQoNCkkgaG9wZSB5b3Ugd2lsbCBleGN1c2Ug bXkgbG9uZyBkZWxheSBpbiBzZWVraW5nIHRoaXMgY2xhcmlmaWNhdGlvbi4gIFlvdXIgZW1haWwg YmVsb3cgZ290IG92ZXJ3aGVsbWVkIGluIG15IGluYm94LCBidXQgdGhhbmsgZ29vZG5lc3Mgbm90 IGxvc3QuDQoNCldlIGp1c3QgaXNzdWVkIHJldmlzaW9uIC4uLi0xMyBmb3IgQU9EVi1SUEwgYW5k IHRyaWVkIHRvIHJlc3BvbmQgdG8geW91ciBzdWdnZXN0aW9uLiAgUGxlYXNlIHRha2UgYSBsb29r IQ0KDQpOYXR1cmFsbHkgWW91cnMsDQpDaGFybGllIFAuDQoNCg0KDQpPbiAxLzMxLzIwMjIgODow MiBBTSwgUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KSB3cm90ZToNCkFib3V0IOKAnA0KQU9EVi1S UEwgY2FuIGJlIG9wZXJhdGVkIHdoZXRoZXIgb3Igbm90IG5hdGl2ZSBSUEwgaXMgcnVubmluZyBv dGhlcndpc2UuDQrigJwNCkkgYWdyZWUgdGhhdCB0aGUgYWR2ZXJ0aXNlbWVudHMgY2FuIGJlIGRp ZmZlcmVudGlhdGVkOyBzdGlsbCBpdOKAmXMgc2ltcGxlciB0byBkaXNjb3VyYWdlIHVzaW5nIGJv dGggcHJvdG9jb2xzIGluIHRoZSBzYW1lIG5ldHdvcmsuIFdoeSBkbyBzbyBzaW5jZSB0aGlzIGlz IGVzc2VudGlhbGx5IHRoZSByZXBsYWNlbWVudCBwcm90b2NvbD8NCg0KS2VlcCBzYWZlOw0KDQpQ YXNjYWwNCg0KRnJvbTogUm9sbCA8cm9sbC1ib3VuY2VzQGlldGYub3JnPjxtYWlsdG86cm9sbC1i b3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgSW5lcyBSb2JsZXMNClNlbnQ6IGx1bmRpIDMx IGphbnZpZXIgMjAyMiA3OjUyDQpUbzogcm9sbCA8cm9sbEBpZXRmLm9yZz48bWFpbHRvOnJvbGxA aWV0Zi5vcmc+DQpTdWJqZWN0OiBbUm9sbF0gV0dMQyBkcmFmdC1pZXRmLXJvbGwtYW9kdi1ycGwt MTINCg0KRGVhciBhbGwsDQoNClBsZWFzZSBmaW5kIGJlbG93IGEgbmV3IHZlcnNpb24gb2YgYW9k di1ycGwgZHJhZnQuIFRoaXMgZW1haWwgc3RhcnRzIGEgV0dMQyBvZiBvbmUgd2Vlay4NCg0KUGxl YXNlIHJldmlldyBhbmQgc2VuZCB5b3VyIGNvbW1lbnRzIGJ5IDV0aCBGZWJydWFyeS4NCg0KTm90 ZSB0aGF0IHRoaXMgZHJhZnQgdXBkYXRlcyB0aGUgTU9QIHRvIDQgIFtodHRwczovL21haWxhcmNo aXZlLmlldGYub3JnL2FyY2gvbXNnL3JvbGwveU5FV1lrS0djckRXWWZLeENhQ0NYOTZsQ1VZL10N Cg0KVGhhbmsgeW91LA0KDQpJbmVzIGFuZCBEb21pbmlxdWUuDQoNCk9uIFN1biwgSmFuIDMwLCAy MDIyIGF0IDc6MjcgUE0gPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50ZXJuZXQt ZHJhZnRzQGlldGYub3JnPj4gd3JvdGU6DQoNCkEgTmV3IEludGVybmV0LURyYWZ0IGlzIGF2YWls YWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cyBkaXJlY3Rvcmllcy4NClRoaXMg ZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIFJvdXRpbmcgT3ZlciBMb3cgcG93ZXIgYW5kIExv c3N5IG5ldHdvcmtzIFdHIG9mIHRoZSBJRVRGLg0KDQogICAgICAgIFRpdGxlICAgICAgICAgICA6 IFN1cHBvcnRpbmcgQXN5bW1ldHJpYyBMaW5rcyBpbiBMb3cgUG93ZXIgTmV0d29ya3M6IEFPRFYt UlBMDQogICAgICAgIEF1dGhvcnMgICAgICAgICA6IENoYXJsZXMgRS4gUGVya2lucw0KICAgICAg ICAgICAgICAgICAgICAgICAgICBTLlYuUiBBbmFuZA0KICAgICAgICAgICAgICAgICAgICAgICAg ICBTYXRpc2ggQW5hbWFsYW11ZGkNCiAgICAgICAgICAgICAgICAgICAgICAgICAgQmluZyBMaXUN CiAgICAgICAgRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0Zi1yb2xsLWFvZHYtcnBsLTEyLnR4 dA0KICAgICAgICBQYWdlcyAgICAgICAgICAgOiAzMg0KICAgICAgICBEYXRlICAgICAgICAgICAg OiAyMDIyLTAxLTMwDQoNCkFic3RyYWN0Og0KICAgUm91dGUgZGlzY292ZXJ5IGZvciBzeW1tZXRy aWMgYW5kIGFzeW1tZXRyaWMgUGVlci10by1QZWVyIChQMlApDQogICB0cmFmZmljIGZsb3dzIGlz IGEgZGVzaXJhYmxlIGZlYXR1cmUgaW4gTG93IHBvd2VyIGFuZCBMb3NzeSBOZXR3b3Jrcw0KICAg KExMTnMpLiAgRm9yIHRoYXQgcHVycG9zZSwgdGhpcyBkb2N1bWVudCBzcGVjaWZpZXMgYSByZWFj dGl2ZSBQMlANCiAgIHJvdXRlIGRpc2NvdmVyeSBtZWNoYW5pc20gZm9yIGJvdGggaG9wLWJ5LWhv cCByb3V0aW5nIGFuZCBzb3VyY2UNCiAgIHJvdXRpbmc6IEFkIEhvYyBPbi1kZW1hbmQgRGlzdGFu Y2UgVmVjdG9yIFJvdXRpbmcgKEFPRFYpIGJhc2VkIFJQTA0KICAgcHJvdG9jb2wgKEFPRFYtUlBM KS4gIFBhaXJlZCBJbnN0YW5jZXMgYXJlIHVzZWQgdG8gY29uc3RydWN0DQogICBkaXJlY3Rpb25h bCBwYXRocywgZm9yIGNhc2VzIHdoZXJlIHRoZXJlIGFyZSBhc3ltbWV0cmljIGxpbmtzIGJldHdl ZW4NCiAgIHNvdXJjZSBhbmQgdGFyZ2V0IG5vZGVzLg0KDQoNClRoZSBJRVRGIGRhdGF0cmFja2Vy IHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRm Lm9yZy9kb2MvZHJhZnQtaWV0Zi1yb2xsLWFvZHYtcnBsLw0KDQpUaGVyZSBpcyBhbHNvIGFuIGh0 bWxpemVkIHZlcnNpb24gYXZhaWxhYmxlIGF0Og0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvaHRtbC9kcmFmdC1pZXRmLXJvbGwtYW9kdi1ycGwtMTINCg0KQSBkaWZmIGZyb20gdGhl IHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv cmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtcm9sbC1hb2R2LXJwbC0xMg0KDQoNCkludGVybmV0LURy YWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgcnN5bmMgYXQgcnN5bmMuaWV0Zi5vcmc6OmludGVy bmV0LWRyYWZ0cw0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpSb2xsIG1haWxpbmcgbGlzdA0KUm9sbEBpZXRmLm9yZzxtYWlsdG86Um9sbEBpZXRm Lm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbA0KDQoNCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClJvbGwgbWFp bGluZyBsaXN0DQpSb2xsQGlldGYub3JnPG1haWx0bzpSb2xsQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsDQoNCg0K --_000_FE7C761CA30849BCB7678A44557D5116ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQpI ZWxsbyBDaGFybGllJm5ic3A7DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGUgQU9EViBmbGF2 b3IgY29tcGxldGVzIHRoZSBSUEwgZmFtaWx5LiBJdCByZXBsYWNlcyBQMlAgKHdoaWNoIHdhcyBl eHBlcmltZW50YWwpIGFzIHRoZSByZWZlcmVuY2UgcmVhY3RpdmUgdmFyaWF0aW9uIG9mIFJQTC4m bmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoZSBvcmlnaW5hbCBSUEwgaXMg cHJvYWN0aXZlIGFuZCBkaXN0cmlidXRlZDsgaXQgcmVtYWlucyBhcyB0aGUgY2VudHJhbCBvcHRp b24uPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5BdCB0aGUgb3RoZXIgZXh0cmVtZSBm cm9tIHJlYWN0aXZlLCB3ZSBmaW5kIHJvdXRlIHByb2plY3Rpb24gdGhhdCBpcyB0aGUgU0ROIChj ZW50cmFsaXplZCkgdmFyaWF0aW9uLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VG9n ZXRoZXIgdGhvc2UgMyBwcm92aWRlIGEgY29tcHJlaGVuc2l2ZSB0b29sIHNldCBmb3IgTExOc+KA pjxicj4NCjxicj4NCjxkaXYgZGlyPSJsdHIiPg0KPGRpdj48YnI+DQo8L2Rpdj4NClJlZ2FyZHMs DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5QYXNjYWw8L2Rpdj4NCjwvZGl2Pg0KPGRpdiBkaXI9 Imx0ciI+PGJyPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+TGUgOSBtYXJzIDIwMjIgw6AgMTY6 NTIsIENoYXJsZXMgUGVya2lucyAmbHQ7Y2hhcmxpZXBAbHVwaW5sb2RnZS5jb20mZ3Q7IGEgw6lj cml0Jm5ic3A7Ojxicj4NCjxicj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg dHlwZT0iY2l0ZSI+DQo8ZGl2IGRpcj0ibHRyIj7vu78gSGVsbG8gUGFzY2FsLDxicj4NCjxicj4N CkRpZCB5b3UgbWVhbiB0aGF0IEFPRFYtUlBMIGlzIHRoZSByZXBsYWNlbWVudCBwcm90b2NvbCBm b3IgUDJQLVJQTD8mbmJzcDsgT3IgdGhhdCBpdCBjb3VsZCBiZSB2aWV3ZWQgYXMgYSByZXBsYWNl bWVudCBwcm90b2NvbCBmb3IgUlBMPzxicj4NCjxicj4NCkkgaG9wZSB5b3Ugd2lsbCBleGN1c2Ug bXkgbG9uZyBkZWxheSBpbiBzZWVraW5nIHRoaXMgY2xhcmlmaWNhdGlvbi4mbmJzcDsgWW91ciBl bWFpbCBiZWxvdyBnb3Qgb3ZlcndoZWxtZWQgaW4gbXkgaW5ib3gsIGJ1dCB0aGFuayBnb29kbmVz cyBub3QgbG9zdC48YnI+DQo8YnI+DQpXZSBqdXN0IGlzc3VlZCByZXZpc2lvbiAuLi4tMTMgZm9y IEFPRFYtUlBMIGFuZCB0cmllZCB0byByZXNwb25kIHRvIHlvdXIgc3VnZ2VzdGlvbi4mbmJzcDsg UGxlYXNlIHRha2UgYSBsb29rITxicj4NCjxicj4NCk5hdHVyYWxseSBZb3Vycyw8YnI+DQpDaGFy bGllIFAuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGRpdiBjbGFzcz0ibW96LWNpdGUtcHJlZml4 Ij5PbiAxLzMxLzIwMjIgODowMiBBTSwgUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KSB3cm90ZTo8 YnI+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiIGNpdGU9Im1pZDpDTzFQUjExTUI0 ODgxRkExQTI4MjdDRDhFNUQ4MjU3OTZEODI1OUBDTzFQUjExTUI0ODgxLm5hbXByZDExLnByb2Qu b3V0bG9vay5jb20iPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQg V29yZCAxNSAoZmlsdGVyZWQNCiAgICAgICAgbWVkaXVtKSI+DQo8c3R5bGU+QGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O31AZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1 IDIgMiAyIDQgMyAyIDQ7fXAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwN Cgl7bWFyZ2luOjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO31hOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fXNwYW4u RW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFt aWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fS5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO31kaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO308L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0i MiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkFib3V0IOKA nDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9u dCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+ QU9EVi1SUEwgY2FuIGJlIG9wZXJhdGVkIHdoZXRoZXIgb3Igbm90IG5hdGl2ZSBSUEwgaXMgcnVu bmluZyBvdGhlcndpc2UuPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij7igJw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPkkgYWdyZWUgdGhhdCB0aGUgYWR2ZXJ0aXNlbWVudHMgY2FuIGJlIGRp ZmZlcmVudGlhdGVkOyBzdGlsbCBpdOKAmXMgc2ltcGxlciB0byBkaXNjb3VyYWdlIHVzaW5nIGJv dGggcHJvdG9jb2xzIGluIHRoZSBzYW1lIG5ldHdvcmsuIFdoeSBkbyBzbyBzaW5jZSB0aGlzIGlz IGVzc2VudGlhbGx5IHRoZSByZXBsYWNlbWVudA0KIHByb3RvY29sPzxvOnA+PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJD YWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZh Y2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5LZWVwIHNhZmU7PG86 cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNp emU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZv bnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PlBhc2NhbDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxkaXYgc3R5bGU9ImJv cmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20NCiAgICAg ICAgICAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNFMUUxRTENCiAgICAgICAgICAgICAgMS4wcHQ7cGFkZGluZzozLjBwdCAw Y20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48Zm9udCBzaXplPSIyIiBmYWNl PSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LXdlaWdodDpib2xk Ij5Gcm9tOjwvc3Bhbj48L2ZvbnQ+PC9iPiBSb2xsDQo8YSBjbGFzcz0ibW96LXR4dC1saW5rLXJm YzIzOTZFIiBocmVmPSJtYWlsdG86cm9sbC1ib3VuY2VzQGlldGYub3JnIj4mbHQ7cm9sbC1ib3Vu Y2VzQGlldGYub3JnJmd0OzwvYT4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5P biBCZWhhbGYgT2YgPC9zcGFuPjwvYj5JbmVzIFJvYmxlczxicj4NCjxiPjxzcGFuIHN0eWxlPSJm b250LXdlaWdodDpib2xkIj5TZW50Ojwvc3Bhbj48L2I+IGx1bmRpIDMxIGphbnZpZXIgMjAyMiA3 OjUyPGJyPg0KPGI+PHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlRvOjwvc3Bhbj48L2I+ IHJvbGwgPGEgY2xhc3M9Im1vei10eHQtbGluay1yZmMyMzk2RSIgaHJlZj0ibWFpbHRvOnJvbGxA aWV0Zi5vcmciPg0KJmx0O3JvbGxAaWV0Zi5vcmcmZ3Q7PC9hPjxicj4NCjxiPjxzcGFuIHN0eWxl PSJmb250LXdlaWdodDpib2xkIj5TdWJqZWN0Ojwvc3Bhbj48L2I+IFtSb2xsXSBXR0xDIGRyYWZ0 LWlldGYtcm9sbC1hb2R2LXJwbC0xMjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNl PSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+RGVhciBhbGwsPG86cD48 L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlBsZWFzZSBmaW5kIGJlbG93IGEgbmV3IHZlcnNp b24gb2YgYW9kdi1ycGwgZHJhZnQuIFRoaXMgZW1haWwgc3RhcnRzIGEgV0dMQyBvZiBvbmUgd2Vl ay48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxp YnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+UGxlYXNlIHJldmlldyBhbmQgc2Vu ZCB5b3VyIGNvbW1lbnRzIGJ5IDV0aCBGZWJydWFyeS4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6 ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+Tm90ZSB0aGF0IHRoaXMgZHJhZnQgdXBkYXRlcyB0aGUgTU9QIHRvIDQm bmJzcDsgWzxhIGhyZWY9Imh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5vcmcvYXJjaC9tc2cvcm9s bC95TkVXWWtLR2NyRFdZZkt4Q2FDQ1g5NmxDVVkvIiB0YXJnZXQ9Il9ibGFuayIgbW96LWRvLW5v dC1zZW5kPSJ0cnVlIiBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0Ij5odHRwczovL21haWxh cmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL3JvbGwveU5FV1lrS0djckRXWWZLeENhQ0NYOTZsQ1VZ LzwvYT5dJm5ic3A7PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIg ZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoYW5rIHlvdSw8 bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJp Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SW5lcyBhbmQgRG9taW5pcXVlLiZuYnNw OzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPGRpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+T24gU3VuLCBKYW4gMzAsIDIwMjIgYXQgNzoyNyBQ TSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgbW96LWRvLW5v dC1zZW5kPSJ0cnVlIiBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0Ij5pbnRlcm5ldC1kcmFm dHNAaWV0Zi5vcmc8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0K PC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQg I0NDQ0NDQw0KICAgICAgICAgICAgICAgIDEuMHB0O3BhZGRpbmc6MGNtIDBjbSAwY20NCiAgICAg ICAgICAgICAgICA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGNtIj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij48YnI+DQpBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFp bGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMgZGlyZWN0b3JpZXMuPGJyPg0K VGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgUm91dGluZyBPdmVyIExvdyBwb3dlciBh bmQgTG9zc3kgbmV0d29ya3MgV0cgb2YgdGhlIElFVEYuPGJyPg0KPGJyPg0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IFRpdGxlJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDs6IFN1cHBvcnRpbmcgQXN5bW1ldHJpYyBMaW5rcyBpbiBMb3cgUG93ZXIgTmV0d29ya3M6 IEFPRFYtUlBMPGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEF1dGhvcnMmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiBDaGFybGVzIEUuIFBlcmtpbnM8YnI+DQombmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgUy5WLlIgQW5hbmQ8YnI+DQombmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgU2F0aXNoIEFuYW1hbGFtdWRpPGJyPg0KJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IEJpbmcgTGl1PGJyPg0KJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IEZpbGVuYW1lJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDogZHJhZnQtaWV0 Zi1yb2xsLWFvZHYtcnBsLTEyLnR4dDxicj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBQ YWdlcyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7OiAzMjxicj4NCiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBEYXRlJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgOiAyMDIyLTAxLTMwPGJyPg0KPGJyPg0KQWJzdHJhY3Q6PGJyPg0KJm5i c3A7ICZuYnNwO1JvdXRlIGRpc2NvdmVyeSBmb3Igc3ltbWV0cmljIGFuZCBhc3ltbWV0cmljIFBl ZXItdG8tUGVlciAoUDJQKTxicj4NCiZuYnNwOyAmbmJzcDt0cmFmZmljIGZsb3dzIGlzIGEgZGVz aXJhYmxlIGZlYXR1cmUgaW4gTG93IHBvd2VyIGFuZCBMb3NzeSBOZXR3b3Jrczxicj4NCiZuYnNw OyAmbmJzcDsoTExOcykuJm5ic3A7IEZvciB0aGF0IHB1cnBvc2UsIHRoaXMgZG9jdW1lbnQgc3Bl Y2lmaWVzIGEgcmVhY3RpdmUgUDJQPGJyPg0KJm5ic3A7ICZuYnNwO3JvdXRlIGRpc2NvdmVyeSBt ZWNoYW5pc20gZm9yIGJvdGggaG9wLWJ5LWhvcCByb3V0aW5nIGFuZCBzb3VyY2U8YnI+DQombmJz cDsgJm5ic3A7cm91dGluZzogQWQgSG9jIE9uLWRlbWFuZCBEaXN0YW5jZSBWZWN0b3IgUm91dGlu ZyAoQU9EVikgYmFzZWQgUlBMPGJyPg0KJm5ic3A7ICZuYnNwO3Byb3RvY29sIChBT0RWLVJQTCku Jm5ic3A7IFBhaXJlZCBJbnN0YW5jZXMgYXJlIHVzZWQgdG8gY29uc3RydWN0PGJyPg0KJm5ic3A7 ICZuYnNwO2RpcmVjdGlvbmFsIHBhdGhzLCBmb3IgY2FzZXMgd2hlcmUgdGhlcmUgYXJlIGFzeW1t ZXRyaWMgbGlua3MgYmV0d2Vlbjxicj4NCiZuYnNwOyAmbmJzcDtzb3VyY2UgYW5kIHRhcmdldCBu b2Rlcy48YnI+DQo8YnI+DQo8YnI+DQpUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBm b3IgdGhpcyBkcmFmdCBpczo8YnI+DQo8YSBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2RvYy9kcmFmdC1pZXRmLXJvbGwtYW9kdi1ycGwvIiB0YXJnZXQ9Il9ibGFuayIgbW96LWRv LW5vdC1zZW5kPSJ0cnVlIiBjbGFzcz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0Ij5odHRwczovL2Rh dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXJvbGwtYW9kdi1ycGwvPC9hPjxicj4N Cjxicj4NClRoZXJlIGlzIGFsc28gYW4gaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6PGJy Pg0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1p ZXRmLXJvbGwtYW9kdi1ycGwtMTIiIHRhcmdldD0iX2JsYW5rIiBtb3otZG8tbm90LXNlbmQ9InRy dWUiIGNsYXNzPSJtb3otdHh0LWxpbmstZnJlZXRleHQiPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2h0bWwvZHJhZnQtaWV0Zi1yb2xsLWFvZHYtcnBsLTEyPC9hPjxicj4NCjxicj4N CkEgZGlmZiBmcm9tIHRoZSBwcmV2aW91cyB2ZXJzaW9uIGlzIGF2YWlsYWJsZSBhdDo8YnI+DQo8 YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1yb2xs LWFvZHYtcnBsLTEyIiB0YXJnZXQ9Il9ibGFuayIgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIiBjbGFz cz0ibW96LXR4dC1saW5rLWZyZWV0ZXh0Ij5odHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3Vy bDI9ZHJhZnQtaWV0Zi1yb2xsLWFvZHYtcnBsLTEyPC9hPjxicj4NCjxicj4NCjxicj4NCkludGVy bmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgcnN5bmMgYXQgcnN5bmMuaWV0Zi5vcmc6 OmludGVybmV0LWRyYWZ0czxicj4NCjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KUm9sbCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBo cmVmPSJtYWlsdG86Um9sbEBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiIG1vei1kby1ub3Qtc2Vu ZD0idHJ1ZSIgY2xhc3M9Im1vei10eHQtbGluay1mcmVldGV4dCI+Um9sbEBpZXRmLm9yZzwvYT48 YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwi IHRhcmdldD0iX2JsYW5rIiBtb3otZG8tbm90LXNlbmQ9InRydWUiIGNsYXNzPSJtb3otdHh0LWxp bmstZnJlZXRleHQiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbDwv YT48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8YnI+DQo8ZmllbGRzZXQgY2xhc3M9Im1vei1taW1lLWF0 dGFjaG1lbnQtaGVhZGVyIj48L2ZpZWxkc2V0Pg0KPHByZSBjbGFzcz0ibW96LXF1b3RlLXByZSIg d3JhcD0iIj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Um9sbCBtYWlsaW5nIGxpc3QNCjxhIGNsYXNzPSJtb3otdHh0LWxpbmstYWJicmV2aWF0ZWQiIGhy ZWY9Im1haWx0bzpSb2xsQGlldGYub3JnIj5Sb2xsQGlldGYub3JnPC9hPg0KPGEgY2xhc3M9Im1v ei10eHQtbGluay1mcmVldGV4dCIgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9yb2xsIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGw8 L2E+DQo8L3ByZT4NCjwvYmxvY2txdW90ZT4NCjxicj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_FE7C761CA30849BCB7678A44557D5116ciscocom_-- From nobody Thu Mar 17 06:35:13 2022 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 B70603A00E0 for ; Thu, 17 Mar 2022 06:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] 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 1a3CZgChS2ED for ; Thu, 17 Mar 2022 06:35:08 -0700 (PDT) Received: from mail.mimuw.edu.pl (mail.mimuw.edu.pl [193.0.96.6]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A37E3A00C4 for ; Thu, 17 Mar 2022 06:35:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by duch.mimuw.edu.pl (Postfix) with ESMTP id 34BE0600FF060 for ; Thu, 17 Mar 2022 14:35:05 +0100 (CET) X-Virus-Scanned: amavisd-new at mimuw.edu.pl Received: from duch.mimuw.edu.pl ([127.0.0.1]) by localhost (mail.mimuw.edu.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Z_738HKjcJ-o for ; Thu, 17 Mar 2022 14:35:03 +0100 (CET) Received: from [10.12.6.132] (unknown [10.12.6.132]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by duch.mimuw.edu.pl (Postfix) with ESMTPSA for ; Thu, 17 Mar 2022 14:35:02 +0100 (CET) Message-ID: <21a67951-92c7-5cfa-7bda-a11ac004492c@mimuw.edu.pl> Date: Thu, 17 Mar 2022 14:35:01 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 Content-Language: en-US From: Konrad Iwanicki To: Routing Over Low power and Lossy networks Reply-To: Routing Over Low power and Lossy networks References: <49ac5fc3-4a3c-fb87-d366-eb7e7cfd60df@mimuw.edu.pl> <18233.1583176305@localhost> <10272666-28c7-ab3e-9ceb-1b8f2bb6e5e5@mimuw.edu.pl> <02c7a894-b7a8-8fcb-9119-172a91a3871b@mimuw.edu.pl> <8421.1620834368@localhost> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Roll] Border router failure detection 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, 17 Mar 2022 13:35:11 -0000 Dear all, Since the RNFD draft has been adopted by the group, I am expected to propose a set of work items on which we could iterate to progress on the draft. To this end, I went through our e-mails and meeting recordings and decided to just briefly summarize the status so far and propose some starting point. # Status RNFD is an addition to RPL that improves detecting crashes of DODAG roots by all DODAG members. The algorithm essentially boils down to nodes voting and achieving consensus on whether the root has crashed. The improvement regards only the performance and not the ability to detect root crashes: RPL alone can do this but the process is slow and generates heavy traffic. From our discussions, it seems that the problem seems important but the current RNFD algorithm is not necessarily the final one. # Starting point I am an author of the draft and it is hard for me to come up with a way to improve the algorithm. However, Pascal had an interesting idea, which may be worth exploring. More specifically, achieving consensus in RNFD is done in such a way that the root node need not be involved. As long as the network remains connected, the nodes are able to conclude that the root has crashed, irrespective of how degenerated the DODAG may be because of the crash. What Pascal suggested (or at least what I understood) is that involving the root and using perhaps a different consensus algorithm may be worth considering. I think we could try to organize the initial work items around this idea to see if we can improve the RNFD algorithm or replace it with something else. What do you think about this starting point? Or perhaps do you have suggestions of other work items? (Also, I believe that discussing the work items should first be done asynchronously/offline. However, if you prefer allocating a slot at IETF 113, please do let me know.) Best, -- - Konrad Iwanicki. From nobody Thu Mar 17 07:57:42 2022 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 4FEE73A0BB0; Thu, 17 Mar 2022 07:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.606 X-Spam-Level: X-Spam-Status: No, score=-9.606 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=EE2WUlcJ; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=xeDkfmfP 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 0JlS3IpbPg8R; Thu, 17 Mar 2022 07:57:35 -0700 (PDT) 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 6C9053A0BA9; Thu, 17 Mar 2022 07:57:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10284; q=dns/txt; s=iport; t=1647529055; x=1648738655; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=5jZ7/+zSldSFWJd5nz/t53KVCpARzM+2RFBBNynaCpQ=; b=EE2WUlcJv52cWW8U9GwVGudGrJJHaCsSzLBTRENBSh6eE9o0ZhXoaB6d IQOMIvHipeM3axLNwkSKi5wosMprpKCmsH48v7D2bGjk41K+FpjZz9wi0 vJ8cbIgP9+OWiB2O6wXWJiWJX7iC2BF0GRkBlKPh0cbpd4Of5mc2cZpnM 4=; IronPort-PHdr: =?us-ascii?q?A9a23=3AFpiG5REzPAF2PkCyU7neTZ1GfiYY04WdBeZdw?= =?us-ascii?q?pYkircbdKOl8tyiOUHE/vxigRfPWpmT8PNLjefa8sWCEWwN6JqMqjYOJZpLU?= =?us-ascii?q?RJWhcAfhQd1BsmDBAXyJ+LraCpvGsNEWRdl8ni3PFITFtz5YgjZo2a56ngZH?= =?us-ascii?q?RCsXTc=3D?= IronPort-Data: =?us-ascii?q?A9a23=3AWcz3eaO65QJZSfXvrR2dlcFynXyQoLVcMsEvi?= =?us-ascii?q?/4bfWQNrUol3mYPxmQaC2/SPvqPN2D1LdAlYITg8UsDsZTRmII3HXM5pCpnJ?= =?us-ascii?q?55oRWUpJjg4wn8dtEp+F+WbJK5cx5hYO4GowPwcFCeG/E/2a+e59xGQ6InRL?= =?us-ascii?q?lbCIL+cUsxObVcMpBcJ0XqPqsZh6mJaqYHR7zCl4bsel/bi1GqNgFaYBI67B?= =?us-ascii?q?5Wr83uDtNyq0N8RU8dXifpj5DcynFFNZH4TyD3YEpf2fmVUNrbSq+fr1rq1+?= =?us-ascii?q?CbS+A0gT4zjmbfgeUpMSbnXVeSMoiMJAO753V4T/Wprjv1T2Pk0MS+7jx2Rg?= =?us-ascii?q?9BswthXqbS7SBwiOevHn+F1vxxwTHovYfMXpuabSZS4mYnJp6HcSFP2xPFqJ?= =?us-ascii?q?EA7IYNe/fx4aUlC7/UWNHUMYwyNwvixxLb+Q+5gmIE5NM2tNYcbknBt0T+fC?= =?us-ascii?q?uwpKa0v6Y2iCcRwxjw8gIVFGuzTIpVfYjt0ZxOGaBpKUmr7wakWxI+A7kQTu?= =?us-ascii?q?RUBwL5NmZcK3g=3D=3D?= IronPort-HdrOrdr: =?us-ascii?q?A9a23=3AZYJzX66e9WvKUGPTkwPXwX2BI+orL9Y04l?= =?us-ascii?q?Q7vn2ZFiY6TiXIra+TdaoguSMc0AxhJU3Jmbi7Sc29qADnhOJICO4qTPuftW?= =?us-ascii?q?jdySaVxeRZjLcKrAeQYxEXeIRmpNxdmsRFeb/N5DtB/InHCWuDYqwdKbC8mc?= =?us-ascii?q?jC74q/vhRQpGpRGsZdBnJCe3+m+zpNNW977PQCZf+hz/sCgwDlVWUcb8y9CH?= =?us-ascii?q?VAdfPEvcf3mJXvZgNDLwI76SGV5AnYpoLSIly95FMzQjlPybAt/SzuiAri/J?= =?us-ascii?q?iutPm911v1y3LT1ZJLg9Hso+EzRfBky/JlagkEuDzYJriJaIfy+QzdZ9vfrG?= =?us-ascii?q?rCpeO84CvI+f4DrE85MFvF5ycFkDOQrwrGo0WSt2Nwx0GT+PAQgFkBepF8bU?= =?us-ascii?q?UzSGqA16NohqAM7Itbm22erJZZFhXGgWD04MXJTQhjkg6urWMlivN7tQ0WbW?= =?us-ascii?q?IyUs4mkWUkxjIdLH7AJlOO1Kk3VO11SM3M7vdfdl2XK3jfo2l02dSpGnA+BA?= =?us-ascii?q?2PTEQOstGcl2E+pgEy82IIgMgE2nsQ/pM0TJdJo+zCL6RzjblLCssbd7h0Cu?= =?us-ascii?q?sNSda+TmbNXRXPOmSPJkmPLtBNB1vd75rspLkl7uCjf5IFiJM0hZTaSVtd8X?= =?us-ascii?q?U/fkr/YPf+q6GjMiq9NFlVcQ6duf22vaIJyoEUbICbQxG+dA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BtBgCSSzNi/49dJa1agQmBWoFSKC4?= =?us-ascii?q?Hd1o3RIgeA4U5hRCDAoEWjy2KdIEuFIERA1QLAQEBDQEBNQwEAQGBT4M4AoQ?= =?us-ascii?q?sAiU0CQ4BAgQBAQESAQEFAQEBAgEHBIEJE4VoAQyGRRYoBgEBNwERAT5CJgE?= =?us-ascii?q?EDg0NDYJjgmUDLgEOogQBgToCgQ6JEXiBM4EBgggBAQYEBIULGII3AwaBPIM?= =?us-ascii?q?Ri18cgUlEgRVDgWZKN4MKFwSBJDyDT4IulnYKax1RDgYbIgJQNUgbARQWHgE?= =?us-ascii?q?LOpFhKq4ZCoNJBaAIFYNzjC6YGZZZIIIpnwmFBwIEAgQFAg4BAQaBYTyBWXA?= =?us-ascii?q?VO4JpURkPjiwWg1CFFIVKdQIBATQCBgsBAQMJi3UHgkEBAQ?= X-IronPort-AV: E=Sophos;i="5.90,188,1643673600"; d="scan'208";a="739469614" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 17 Mar 2022 14:57:34 +0000 Received: from mail.cisco.com (xfe-aln-002.cisco.com [173.37.135.122]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 22HEvY5a017051 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK); Thu, 17 Mar 2022 14:57:34 GMT Received: from xfe-rcd-001.cisco.com (173.37.227.249) by xfe-aln-002.cisco.com (173.37.135.122) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Thu, 17 Mar 2022 09:57:33 -0500 Received: from NAM02-DM3-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-001.cisco.com (173.37.227.249) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14 via Frontend Transport; Thu, 17 Mar 2022 09:57:33 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=foAYpdKjDOPxH8CzBjzZRf1okANDQgPSlkcyrjsgfFFG9N+q0PhKa6Oyh39p2tHKTbVVyPh51HVVpVoLU9rhsRvfSfVEia3A09vXRN+cg6hbEc560YXVcizZaH7bbKMejDpIyyq/g/DeiiwKXrcv8DTQLngwmxppNEOapoJydua0XtJh10rFUUSf/TdlhaJ5VKMLVNXJaUa0VkfreljzpKLfwz5YDyYLBVgOsisV1Liby/wd9LriO6m6ALNVQn+dWWbBONKWMmbBlLJrSXxKvs63IVgyS9zNsz2ZTEdYLA69XLdQJ2Q0ljGfUUzpTf2dA2r7cU932jniXV3GmWGA5Q== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=rCDq3EB0IEWK5esQxCYNXINxxPnbTCTTB8+ZMHy2qz0=; b=IxrdRuuq8Y84u6JVpeDIqP/4RNn5epOBgui5DvPGHXF6AvT6tTkjrmaDsG5sjp/QW/hkifENKiHZX4Sjc00KmUa/Qs+wv6D/M4fppPCUYmwbNJ7mFhCfZ2XfK8cw/tu4LNss3p634Ony9WsvXA73O6jcuIa9KZdstGmq8nXrUNMjDBcMDByw37gol36zDhPQv0KVzUZXbDDPWDjjYEXU3HDe4TAZO9AJyE0/PoOXn5xahMQwFIiokyDfLT1OXwmoHNK0Nb5aVU7pBlcc7n4AXJNW+JbN5tdxOfcOuiFQtVdghWRpjm/09o3MRzyA9knQCeDorJQGG9QxseXyp1DAAw== 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=rCDq3EB0IEWK5esQxCYNXINxxPnbTCTTB8+ZMHy2qz0=; b=xeDkfmfPaFN7gAMm5UbMm2b/olFRUqQ/ZCvf2yzqs1zYfOFB4SBDXwNSs0hUAFIhN9CdUjMAYynhuOMBpdP3Ehj3vWD+0t4brzTG6h3JMcgCMLZ2tkkiBeVLqGj/eJ6uI5Ig/iipC1wisIPhrgGZlMkdbxsPjdG36w/0lqRzc/U= Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by DM6PR11MB3690.namprd11.prod.outlook.com (2603:10b6:5:13d::32) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5081.16; Thu, 17 Mar 2022 14:57:32 +0000 Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::d4d0:b43e:40e8:d888]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::d4d0:b43e:40e8:d888%5]) with mapi id 15.20.5081.018; Thu, 17 Mar 2022 14:57:32 +0000 From: "Pascal Thubert (pthubert)" To: "draft-ietf-roll-aodv-rpl.all@ietf.org" CC: "ROLL WG (roll@ietf.org)" Thread-Topic: Review of draft-ietf-roll-aodv-rpl-13 Thread-Index: Adg5xEPvuK6UskvFQ4qfe6KNSs4VbQ== Date: Thu, 17 Mar 2022 14:56:28 +0000 Deferred-Delivery: Thu, 17 Mar 2022 14:39:50 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 711e1a1b-4e0c-4b70-de80-08da082676ed x-ms-traffictypediagnostic: DM6PR11MB3690:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: cugelQFvkJmGq/65GTs/9gctaCYoARqAEOcyIDC3EQpSMd9wonl8SBg3x4fUwIqAbxmvE11BuZmVct0fzWzWm6KlK341/ENkvhCTqOib2VNq2HiKY1PgnRDtkd/TGBXcz35nbVtdEUBtMvyi+geM6899p8f5p44jTpwCj+gmqffZSWjd+iLhmPnmrTGkv5jWKMPLa/akQtCxV1iG1+TbFfSe2DNneC0iFKcAB6cY1ndyIOU7I4UgJWabqg/GR9xoANXcP9YzpZcC8MkjkauEm/V+HzWdZE9MyIlmQE0N06STYnnxp+m1kJCS0h8+gEnObHN4ZvSlo8qgn7ro6KqdW0J1jvgMiSPcqIzzow982pN426MIVrGA8D4aEHSRGlAdPPfyxqHx+0j/vp9FIageQ+HOLjgFgEsqZwc1jVmnHk3LS/xaL9Ev6OmS5qeHs+wjRB7/k0B9OFz6NmUw+X1BF1uYFxPeVfZ2hZDoRGSF1Kjye2MNL0kUusfkJ4IW9/sxOtlv8cOf7IYn611gWn4LFy3avQUSdq1oRVPnNd7cWfyWz/zO2SvCI5HnGqSrj540S6IdzGo1UHxvVGdKjqEsGIUkiqEytc4oJjQt7OtgBgkISCVDaa6aQ+oRifktGjc2d4hPkunkf9FI+EA81/D/o9VUepTuiQo0UlnLmJdyeTr2YCcWbSv6IngMEYh+92lf0KXkYF6eZCyJ91y+9kSi1n54WmtMzsL4wj+A8qnFU4cpfJFHheV6+Qhw6YqDtvquPESAH2n63n7oQTT2k01+9SWq/JHI3cMglf/QV63ooeQ= x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR11MB4881.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(7696005)(6506007)(6916009)(508600001)(6666004)(9686003)(33656002)(52536014)(55016003)(316002)(966005)(26005)(83380400001)(186003)(66574015)(71200400001)(66946007)(64756008)(66446008)(4326008)(76116006)(66476007)(38070700005)(86362001)(66556008)(8676002)(450100002)(8936002)(38100700002)(5660300002)(2906002)(122000001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?ClRoAOBhD+7Ati2O918v1wCALYcV8Tbu2tVLOxYI9bOxWDtOE/gFzJx+/n5O?= =?us-ascii?Q?lfEUWamJR61Bmn4G3QnwM2wuQdff2O4NQaNgq8P3RR/Nlmh635sF7ANNA2pg?= =?us-ascii?Q?IXwZM0OD4sSsyT589XVtegQraRC2R+l7yJlWlMIjvgN7Utbk1/E2sGkiYOWr?= =?us-ascii?Q?9dYGlZPX+Q4lU43k5wHiw7GFk7zX+31a3ZAuuC5Pp3BqTzZZEKXZANBZyrd7?= =?us-ascii?Q?OxiJwQN7AWau+ozAndv+4xXvKWCyWCbhJj/he1c/JaxTdjmuUp3oipLqGvIR?= =?us-ascii?Q?4HfxVBP67sP2zV1SBB+7g+mqSLNM4eO2XLRD9UFnZKsRd7BSLAgFNU2o5dND?= =?us-ascii?Q?aBDB2MBYnOXdIX6XnbshZ0SRO0Ib6RoSdl6CDSZ+pCfcRc0E2Ss+L/3kEEQ0?= =?us-ascii?Q?RivApSKjoWhMXvS/AIF7lMd8JQbHgCnEChDecT5uByzkuI+jpAZKbuf0iMue?= =?us-ascii?Q?O3liNdXMu6WtMtn9fkWLpnT1McaniHxrY8EemkdJ0WAQmVTtxEbpAQCbQcwl?= =?us-ascii?Q?oggkCSvZsWTjTLvrdyxiy4L6OX+yHHpV43pu3hD66P7oWglofhMGBzCybWAZ?= =?us-ascii?Q?NmBuczVT6UTvag1x3R0tSYySPiOCpw1cZmxfzAfaWruyu6M8cNkJCDE5eHU3?= =?us-ascii?Q?wrn6C/OU1GYIqFPOifnDvyo+6snJAab87uloLJMVZqLUh7rzcyJ34xZPBpqd?= =?us-ascii?Q?paGHBh4IN493ICZzsCauhm659Rhv2F0RR8sbqzuS3yEnN6f0rjTuYWfi3V/F?= =?us-ascii?Q?KKp6lbfnKwkR/jtUwmfXD5OJsuSlnrVzVKdao0pjrXmTF30sbo9E1nGxLxPY?= =?us-ascii?Q?dYqBB1TL/k9XrF7HX1VSrBTeocDizpJrMA76k5lEhwdFcqsr64qAolN8EaWk?= =?us-ascii?Q?mPdxPV3seFx4WiuzEYxkLxz1LLAWfmzg+k62JzgoMyR8QEPK18oGhKGTgYVf?= =?us-ascii?Q?9Dq7u33LFl+KatU2dXlyDIkJdPhcI7QCOQpBEE4hjTNrN/lu1Pc6pp9Wf9LT?= =?us-ascii?Q?s/nSMM0Zzkunn4Jp4gIS8JZzOvm7yb3fIUxgbM4087keuKEGcwsMmIn/Y0pT?= =?us-ascii?Q?Kjib/uSLfWfE0+NWMMQkxPQGx4MFnzIA5TVDyklB7xTNqf0rV0Bc419/0bvc?= =?us-ascii?Q?anXqWQ4jQ8lk0KqgTGn7quVeo0FJ8iH/iR+YVc10aQwdaxuJgTFV0PNyvPAu?= =?us-ascii?Q?FFVseFNQ8F7OCf+VynM80H5IMlbm19dPO2Aw8MCiQvscL7KycDUNFILk3Ayu?= =?us-ascii?Q?BzZPyajc7Mj+pfv+U11RszWjc10qQULdYj9NhEZu0YJPUlEIndzUXKh6f7kM?= =?us-ascii?Q?zCSrHXpULbGOBP/sHLOBMHM+MntPT7v63E6xKt3zURiMkZH/nyN5X4onYW5m?= =?us-ascii?Q?zWmId/bw5TcGL1DrL9ET1DlbtdYNFQN0g5MEtMBE/3cKDc7cNGwAjzJy25Ve?= =?us-ascii?Q?zPq+gO538kiVt3dhcYzt1bOcBT3Wsbgu?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB4881.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 711e1a1b-4e0c-4b70-de80-08da082676ed X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Mar 2022 14:57:32.2020 (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: zeQNzqtj7jm9N9b6aK1lG7ysJ5xlNtyZQNLfD9hBWdw4rNBpFpOmOwpi+Ndss+RVr4CtU2IvvchNpTU09+IoXw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3690 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.135.122, xfe-aln-002.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: [Roll] Review of draft-ietf-roll-aodv-rpl-13 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, 17 Mar 2022 14:57:41 -0000 Dear authors and all; Please find my comments on draft-ietf-roll-aodv-rpl-13 below: Bottom line is that we're not there yet. I believe a number of mechanism ar= e either underspecified or broken as described, e.g., the way a source rout= e is constructed does not seem to work for nodes with different interfaces = up and down. ---------------------------------------------------------------------------= --------------------- " Consequently, for traffic between routers within the DODAG (i.e., Peer-to-Peer (P2P) traffic) data packets either have to traverse the root in non-storing mode, or traverse a common ancestor in storing mode." =3D> Suggest to add references to RFC 6687 for the route stretch and to RFC= 9010 for the detailed impacts. ---------------------------------------------------------------------------= --------------------- The on-demand nature of AODV route discovery is natural for the needs of peer-to-peer routing in RPL-based LLNs. =20 =3D> because ? "natural" lacks substanciation. One could argue the exact sa= me for projected DAO, and all the DetNet / RAW work would support it. I'd r= emove that sentence. Instead, it would be nice to qualify the properties of= on demand that fits which needs so we can derive applicability. I'd say that all RPL variations have in common that they avoid building = optimized routes between every all pairs of nodes, to save constrained reso= urces and control protocol exchanges. On-demand enables an optimization for= specific pairs where a larger main RPL DODAG will allow stretched but any-= to-any connectivity. ---------------------------------------------------------------------------= --------------------- " AODV-RPL can be operated whether or not P2P-RPL or native RPL is runni= ng otherwise." I do not believe that is generally true, please remove the text. MOP 4 i= n DIOs could create a confusion between the reactive methods and a P2P RPL= implementation will not recognize the RREQ option and may process the DIO = or enter an error state. But it does not matter. I'd indicate that if ever = RPL, P2P RPL, and/or AODV RPL run between the same nodes (so unlikely!) the= n they operate as different RPL instances anyway (since " the OrigNode buil= ds a local RPLInstance and a DODAG rooted at itself."). Instances do not mi= x, by definition. =09 ---------------------------------------------------------------------------= --------------------- " For many networks AODV-RPL could be a replacement for RPL, since it can find better routes at very moderate extra cost. Consequently, it is unlikely that RPL would be needed in a network that is running AODV-RPL, even though it would be possible to run both protocols at the same time." =3D> "better" is unsubstanciated.=20 I suggest to remove that text altogether. I believe that it suffices to say= what I pointed above, that RPL and AODV RPL must be operated in different = instances, which is unavoidablme since they are running with different MOPs= , so they just cannot interfere. Which one is used is a policy decision, ou= t of scope. ---------------------------------------------------------------------------= --------------------- " DIO DODAG Information Object " =3D> Remove, this is already defined in RFC 6550 ---------------------------------------------------------------------------= --------------------- " Source routing A mechanism by which the source supplies the complete route towards the target node along with each data packet [RFC6550] " =3D> if it is "complete" then this is *strict* source routing.=20 ---------------------------------------------------------------------------= --------------------- " OrigNode selects one of its IPv6 addresses and sets it in the DODAGID field of the RREQ-DIO message. " =3D>The address scope must encompass the domain where the route is built. E= .G, not link-local.=20 ---------------------------------------------------------------------------= --------------------- " H Set to one for a hop-by-hop route " =3D> In the RPL culture we call that Storing Mode (I did not choose that te= rm!!!). Source route is Non-Storing Mode. Ideally we'd align terminology. Alse, it should at least be indicated in = the terminology and the introduction. ---------------------------------------------------------------------------= --------------------- " L 2-bit unsigned integer determining the length of time that a node is able to belong to the RREQ-Instance " length of time =3D> duration?=20 Also, 256 s might be very short for energy scavenging devices.=20 Could that be based on the " Lifetime Unit " in https://www.rfc-editor.org= /rfc/rfc6550.html#section-6.7.6 so deployments could use very different ra= nges? ---------------------------------------------------------------------------= --------------------- "In Figure 4 and Figure 5, BR is the Border Router, O is the OrigNode, " =3D> This seems to indicate that there's a need for a main RPL instance. Bu= t the text clearly said it is not the case.=20 So maybe indicate that this is an example where you have connectivity to th= e outside (which is not needed) and a main RPL Instance rooted at the BR (w= hich is not needed either). ---------------------------------------------------------------------------= --------------------- " criteria used when determining whether or not each link is symmetric. " =3D> maybe mention DLEP ? No pressure ---------------------------------------------------------------------------= --------------------- " Figure 5: " =3D> The propagation of both DIOs appears to be along a sequence of nodes t= hough it is really flooded in a Rank Diameter around O. I believe it is wor= th explaining. Also, what happens when the S flag arrives at T with both fl= avors? ---------------------------------------------------------------------------= --------------------- "to multicast group all-RPL-nodes". =3D> could we have a all-AODV-RPL-nodes group? The all-RPL-nodes is for nor= mal DIOs. ---------------------------------------------------------------------------= --------------------- "The address in the ART Option can be a unicast IPv6 address or a" =3D> The Target Prefix / Address in the ART option ... ---------------------------------------------------------------------------= --------------------- Section 6.2.1 is pseudo code with no indentation. This results in ambiguity= . For instance,=20 " The upstream neighbor router that transmitted the received RREQ-DIO is selected as the preferred parent. " This is true only in the case where the received DIO is the best.=20 ---------------------------------------------------------------------------= --------------------- Section 6.2.2 :=20 " After determining that a received RREQ provides a usable route " Does that determination impact the operation of this section? What if S=3D0= ? ---------------------------------------------------------------------------= --------------------- Section 6.2.3 : " then the router MUST build or update its upward route entry towards OrigNode, " Even if S=3D0 ? Even if not the newest sequence? Even if RREQ not from pref= erred parent to orig? Suggest to list all the checks first and then if OK the action. Here the la= st sentence is only one of the checks and appears too late to follow the lo= gic. ---------------------------------------------------------------------------= --------------------- Section 6.2.5 :=20 What is the interface up is not the interface down, and the addresses are d= ifferent? The result is that the address list is not reversible. In particular, in th= e case where S =3D 1?=20 ---------------------------------------------------------------------------= --------------------- Section 6.2.5 : " If the router is a TargNode and was already associated with the RREQ- Instance, it takes no further action and does not send an RREP-DIO " In 6.3.1 it says=20 " For a symmetric route, the RREP-DIO message is unicast to the next hop according to the Address Vector (H=3D0) or the route entry (H=3D1); " This means that if an RREP-DIO was sent on a bad path received fast, it wil= l not be updated when a better path shows? ---------------------------------------------------------------------------= --------------------- Section 6.3.3 : This all idea of delta is complicated. Why not just place in that field the= RPL instance ID of the RREQ instance? It's also 6 bits since it is a local= RPL Instance ID. ---------------------------------------------------------------------------= --------------------- Section 6.4.1 : " The router that transmitted the received RREP-DIO is selected as the preferred parent. Afterwards, other RREP-DIO messages can be received. " What if more than one RREP-DIO are received? ---------------------------------------------------------------------------= --------------------- Section 6.4.4 : " If H=3D0, the intermediate router MUST include the address of the interface receiving the RREP-DIO into the address vector. " Same as the other direction. The address on the receive interface of the RR= EQ-DIO may not be visible on the interface from which traffic to target is = received. It would make sense to place the address of the previous hop from= which the RREP-DIO is received. ---------------------------------------------------------------------------= --------------------- Section 7 " an Intermediate router that receives a RREQ-DIO message MAY transmit a "Gratuitous" RREP-DIO message " How does it select the RPL Instance ID? I believe only the target can do th= at so only the target should send the RREP-DIO ---------------------------------------------------------------------------= --------------------- Keep safe, Pascal=20 From nobody Thu Mar 17 09:55:13 2022 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 B78633A128E for ; Thu, 17 Mar 2022 09:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.897 X-Spam-Level: X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, T_SPF_TEMPERROR=0.01, 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 j-UxpCORklCt for ; Thu, 17 Mar 2022 09:55:03 -0700 (PDT) Received: from relay.sandelman.ca (relay.cooperix.net [IPv6:2a01:7e00:e000:2bb::1]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C851E3A1278 for ; Thu, 17 Mar 2022 09:55:02 -0700 (PDT) Received: from dooku.sandelman.ca (unknown [62.218.44.74]) by relay.sandelman.ca (Postfix) with ESMTPS id 35A531F4BA for ; Thu, 17 Mar 2022 16:49:08 +0000 (UTC) Received: by dooku.sandelman.ca (Postfix, from userid 179) id E80961A046F; Thu, 17 Mar 2022 11:32:40 -0400 (EDT) From: Michael Richardson To: Routing Over Low power and Lossy networks In-reply-to: <21a67951-92c7-5cfa-7bda-a11ac004492c@mimuw.edu.pl> References: <49ac5fc3-4a3c-fb87-d366-eb7e7cfd60df@mimuw.edu.pl> <18233.1583176305@localhost> <10272666-28c7-ab3e-9ceb-1b8f2bb6e5e5@mimuw.edu.pl> <02c7a894-b7a8-8fcb-9119-172a91a3871b@mimuw.edu.pl> <8421.1620834368@localhost> <21a67951-92c7-5cfa-7bda-a11ac004492c@mimuw.edu.pl> Comments: In-reply-to Konrad Iwanicki message dated "Thu, 17 Mar 2022 14:35:01 +0100." X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 26.3 MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Date: Thu, 17 Mar 2022 11:32:40 -0400 Message-ID: <260038.1647531160@dooku> Archived-At: Subject: Re: [Roll] Border router failure detection 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, 17 Mar 2022 16:55:09 -0000 --=-=-= Content-Type: text/plain Konrad Iwanicki wrote: > Since the RNFD draft has been adopted by the group, I am expected to > propose a set of work items on which we could iterate to progress on > the draft. Please note that it is an anti-pattern (a pathology) of the IETF that we think that we have to improve/change the document after adoption. It might be that there is little work to do, but we won't really know until more people have read it. > More specifically, achieving consensus in RNFD is done in such a way > that the root node need not be involved. As long as the network remains > connected, the nodes are able to conclude that the root has crashed, > irrespective of how degenerated the DODAG may be because of the > crash. What Pascal suggested (or at least what I understood) is that > involving the root and using perhaps a different consensus algorithm > may be worth considering. The idea being, I think, if the root hasn't crashed, it ought to be able to quickly prove that to all parties involved. The hidden node problem means that that some nodes might think that the root has gone, when it is just not very reachable to that node. A node that can speak to many other rank=2 ("root-children"?) nodes, but can't see the root ought to just become a child of those other nodes. > (Also, I believe that discussing the work items should first be done > asynchronously/offline. However, if you prefer allocating a slot at > IETF 113, please do let me know.) Discussion on the ML is always good and appropriate. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAEBCgAdFiEEow/1qDVgAbWL2zxYcAKuwszYgEMFAmIzVJgACgkQcAKuwszY gENNtwwAqc8NFYeVvfQ9tfQKUgA3YJFHZAyw9bxniUfofxbLXMmYYYRCYop2K7+i 7tuf6wYFkmfAQ8h7Fc0VuXuTxNfhwmGA4E78XyxHTgP19IWykLAT1fZrfYQ5GH2L +Qj/HBNNrSG8ZRRyHC2xareIRb2g2Cy9jq/fcVWkLI3YvyDZFoc3parMr0q6M3IH yhea9x5kpHxGYhqB3DMhaS9S7mGfuOCSNgK+l5wMPkcgDV/6ttmxFl9aZ5Z7wL8Z 5Hu25O3j05FGyq5nyqSqWDHIAusFDBmM9Oqt7pcRi5V+yL3EAuQDn1MKsHraHCiM xc0JEQGyew0mWTRgEUIpBp/6wHgXjoMArpDMxCaw6LF2mQMzKCBmBSkSbOZJx+EY VbxDkHBx4yk7dOpkM83YN96IYk+cqb62alEDzv7cZWvmzdmwbtCAzv8zEdbMB5Om EiW3FoYdFGUE79lAfFr9Rz00NupMJqa6h4tSGuRRragjEFkq9JVwuI9o0UdD6gjI /iJX/XmC =TNrb -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Mar 17 10:33:16 2022 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 B685E3A1445; Thu, 17 Mar 2022 10:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.106 X-Spam-Level: X-Spam-Status: No, score=-2.106 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=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=gmail.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 nUW6fZ5odMEP; Thu, 17 Mar 2022 10:33:09 -0700 (PDT) Received: from mail-ej1-x635.google.com (mail-ej1-x635.google.com [IPv6:2a00:1450:4864:20::635]) (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 C0AF93A143D; Thu, 17 Mar 2022 10:33:08 -0700 (PDT) Received: by mail-ej1-x635.google.com with SMTP id hw13so12010024ejc.9; Thu, 17 Mar 2022 10:33:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:mime-version:date:message-id:subject:to:cc :content-transfer-encoding; bh=DyDF5qy2L6mTP562EvHUROyx85OidysiIR8gEs0+6is=; b=JKJHTAQdN1u4enyTGFMfLSRL3i5ArJDd4xxA2NTHq5NpCFVQMqIv9yu1aNKsqxdkz+ /GDdovFiw/7z+gWqJPVFU1OvgYqIdHoZSvV2/xoUc27ag0Uy01c2iVhySP1QT+F1FI4d Az4bs45SFClFxAUZX2QypSIpEYxQm6za7U5wkJQ1WTcEJavqvp5B38hUizAY68NrycIJ vhq3+L3SGyVmSPJ/nxkGB2ALvz2otVCRzRztvaqlvW/rDJ1495t0Fo6i9uQN41p0P2je SLRa5X9vLCIz0Lc6zar4u5w9orxu/0U5m/0g/V5UsRi32AtY39v/jWuXXJkkZy/pVQ0w cB4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:mime-version:date:message-id:subject:to:cc :content-transfer-encoding; bh=DyDF5qy2L6mTP562EvHUROyx85OidysiIR8gEs0+6is=; b=LK5hbQaP6ohzgZaMZtouqcOO5Vbx4/FMcEYqwG5BobS7LACG/LsgtV1Qa9uUox15Bd hzpkfTJOZ8VHN5NC9GFzs01SSWGSj4NPe/nxVLPMUvS4hgkuhl5Yq569ZPZz1FAy2MyK Rl9iJL6IxCuig+B5B2gFpK+o0lkQON7qF70K8lXJiJ/e99DdvNVn/SnqirRkJg1gIkDR xMf69irRwdG0cPKz6xq/+FAYz5Os9QkVCqL0aPrWa5N0ul0HqNM1h2nsTWoomM2Yuiy9 3dW9G8eg/u+25uibbfCCBE2+gwpRsk+ywn2NuPNHjwXYIc0WrxxkoJ8vwwGZaxN0ZMS9 Czxg== X-Gm-Message-State: AOAM533AiH0XiEk+LBTu/DlMjoFH0jYSpF8WNAYR4FnIv5Xa9UYEyjIx Pv+cDD/gGfJQqt5UsC8zLYfZIeMlxfgBBHNwVzBy3QbF X-Google-Smtp-Source: ABdhPJw5oN4NwpfVcoFXnwvZUY/fWbgqkSMZ0FZ2N1KVzIzy5CPe/KZyQaRg5WIm7sHDpr8qAU61yzzLBTi62vh1Nzo= X-Received: by 2002:a17:907:5009:b0:6db:385a:2b93 with SMTP id fw9-20020a170907500900b006db385a2b93mr5356331ejc.653.1647538385928; Thu, 17 Mar 2022 10:33:05 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 17 Mar 2022 10:33:05 -0700 From: Alvaro Retana MIME-Version: 1.0 Date: Thu, 17 Mar 2022 10:33:04 -0700 Message-ID: To: draft-ietf-roll-nsa-extension@ietf.org Cc: Dominique Barthel , roll-chairs , roll@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Roll] AD Review of draft-ietf-roll-nsa-extension-10 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, 17 Mar 2022 17:33:14 -0000 Dear authors: Thank you for this work! =C2=A0The draft is clear and to the point. =C2=A0I= am sorry it took me so long to get to it due to too many other documents in the queue. I have a general comment that I will mention up-front and several in-line comments/questions (below). =C2=A0I will wait for at least a revision to start the IETF Last Call. (1) Motivation -- are there other applications? The document starts by prominently using PRE to justify the work. =C2=A0The Abstract even promises that it "details how to apply Packet Replication and Elimination in RPL" =C2=A0However, PRE is barely mentioned beyond the Introduction. =C2=A0The only significant mention comes in =C2=A7= 6, where implementation control is recommended -- but no guidance is given on when or how to use it (see specific comments below). This document aims to specify the CA OF and the PS NSA extension (as the title mentions). =C2=A0PRE may have been the original inspiration, just that. =C2=A0But, IMHO, the document shouldn't be centered around it -- we could even eliminate =C2=A76. Are there other potential users of these extensions? =C2=A0Thinking out loud... =C2=A0The AP can be used as a load-sharing path (at least until the traffic reaches a CA). =C2=A0The AP could also be used as a pre-calculated backup path. This comment is not a show stopper, but I think the document would benefit from less focus on PRE: using it as an example of potentially many other applications. Thanks! Alvaro. [Line numbers from idnits.] ... 141 2. =C2=A0Terminology 143 =C2=A0 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL N= OT", 144 =C2=A0 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in= this 145 =C2=A0 document are to be interpreted as described in [RFC2119]. [major] Use the text in rfc8174. 147 =C2=A0 The draft uses the following Terminology: ... 156 =C2=A0 Parent Set (PS): =C2=A0Given a RPL node, the set of its neighbo= r nodes 157 =C2=A0 =C2=A0 =C2=A0which participate in the same RPL DODAG and which = can potentially 158 =C2=A0 =C2=A0 =C2=A0take the role of the node's preferred parent. [minor] This term already exists in rfc6550. =C2=A0It looks like the definition is the same, but to avoid confusion or divergence please point there instead. =C2=A0For example: "The following terms from rfc6550 are used in this document: PS, ...". ... 169 3. =C2=A0Common Ancestor AP Selection Policies 171 =C2=A0 In the RPL protocol, each node maintains a list of potential pa= rents. 172 =C2=A0 For PRE, the Preferred Parent (PP) node is defined to be the sa= me as 173 =C2=A0 the RPL DODAG Preferred Parent node. =C2=A0Furthermore, to cons= truct an 174 =C2=A0 alternative path toward the root, in addition to the PP node, e= ach 175 =C2=A0 node in the network selects additional parent(s), called altern= ative 176 =C2=A0 parent(s), from its Parent Set (PS). [minor] "For PRE, the Preferred Parent (PP) node is defined to be the same as the RPL DODAG Preferred Parent node." IOW, there isn't really a PRE PP, just a PP, as defined in rfc6550, right? Suggestion> =C2=A0 =C2=A0PRE uses the RPL DODAG Preferred Parent node. [** See related comment below in =C2=A74. **] [nit] "additional parent(s)" =C2=A0=C2=A72 uses "Additional Parents" capitalized. =C2=A0Please be consistent when using defined terms. ... 181 =C2=A0 All three policies defined perform AP selection based on common 182 =C2=A0 ancestors, named Common Ancestor Strict, Common Ancestor Medium= , and 183 =C2=A0 Common Ancestor Relaxed, depending on how restrictive the selec= tion 184 =C2=A0 process is. =C2=A0A more restrictive policy will limit flooding= but might 185 =C2=A0 fail to select an appropriate AP, while a less restrictive one = will 186 =C2=A0 more often find an appropriate AP but might increase flooding. [major] Besides the consideration of more or less flooding, what other things should an operator keep in mind when selecting a policy? [** I revisit this question in =C2=A74.1. **] ... 192 3.1. =C2=A0Common Ancestor Strict ... 233 =C2=A0 node S can decide to use node B as its AP node, since PP(PP(S))= =3D Y =3D 234 =C2=A0 PP(B). [nit] s/node S/Node S [major] "node S can decide to use node B as its AP node" What do you mean by "can decide"? =C2=A0If Node S is using the CA Strict OF then B *is* its AP node. =C2=A0There's no room for other decisions. =C2=A0A= m I missing something? I can see the case where multiple nodes meet the condition -- for example if a new node E also has PP(E) =3D Y -- then I can see how node S "can decide" to use one or the other. =C2=A0Are you implying that the result of the policy is somehow optional? [major] BTW, if there was more than one option, how would node S make that tie-breaking decision? 236 3.2. =C2=A0Common Ancestor Medium ... 251 =C2=A0 node S can decide to use node B or D as its AP node. [nit] s/node S/Node S [] Same questions about "can decide" and multiple nodes that satisfy the condition. 253 3.3. =C2=A0Common Ancestor Relaxed ... 269 =C2=A0 node S can decide to use node A, B or D as its AP node. [nit] s/node S/Node S [] Same questions about "can decide". [major] How would node S select between A, B, and D? 271 4. =C2=A0Common Ancestor Objective Function 273 =C2=A0 An OF which allows the multiple paths to remain correlated is 274 =C2=A0 detailed here. =C2=A0More specifically, when using this OF a no= de will 275 =C2=A0 select an AP node close to its PP node to allow the operation o= f 276 =C2=A0 overhearing between parents. =C2=A0For more details about overh= earing and 277 =C2=A0 its use in this context see the "Complex Track with Replication= and 278 =C2=A0 Elimination" in Section 4.5.3 of [I-D.ietf-6tisch-architecture]= . =C2=A0If 279 =C2=A0 multiple potential APs match this condition, the AP with the lo= west 280 =C2=A0 rank will be registered. [minor] "a node will select an AP node close to its PP node to allow the operation of overhearing between parents" How is this used in the policies defined in =C2=A73? =C2=A0Are you referrin= g to physical distance or inferring proximity based on the selection policy? [] "the AP with the lowest rank will be registered." Is this the tie-breaker for the policies in =C2=A73? 282 =C2=A0 The OF described here is an extension of The Minimum Rank with 283 =C2=A0 Hysteresis Objective Function [MRHOF]. =C2=A0In general, this O= F extends 284 =C2=A0 MRHOF by specifying how an AP is selected. =C2=A0Importantly, t= he 285 =C2=A0 calculation of the rank of the node through each candidate neig= hbor 286 =C2=A0 and the selection of the PP is kept the same as in MRHOF. [minor] "Importantly, the...selection of the PP is kept the same as in MRHO= F." =C2=A73 says that "For PRE, the Preferred Parent (PP) node is defined to be the same as the RPL DODAG Preferred Parent node." =C2=A0I made a comment there about clarifying that the PP was selected according to rfc6550 -- but the text here talks about using rfc6719 instead. =C2=A0Please clarify. [major style nit] Personally, I prefer using references in the form of "[RFCxxx]" instead of a name, for example "[MRHOF]". =C2=A0In this case, the reference to "MRHOF" is used both as a reference to rfc6719 and as an abbreviation. =C2=A0The result is that the rest of the text is not clear as to whether you're extending the objective function defined in rfc6719, or rfc6719 itself (as in a formal Update). The RFC Style Guide (rfc7322) says this: =C2=A0 =C2=A03.6. =C2=A0Abbreviation Rules =C2=A0 =C2=A0Abbreviations should be expanded in document titles and upon f= irst =C2=A0 =C2=A0use in the document. =C2=A0The full expansion of the text shou= ld be =C2=A0 =C2=A0followed by the abbreviation itself in parentheses. s/The Minimum Rank with Hysteresis Objective Function [MRHOF]/the Minimum Rank with Hysteresis Objective Function (MRHOF) [RFC6719] Please use "[RFC6719]" as the reference throughout. [major] I am assuming that this document doesn't intend to formally Update rfc6719. =C2=A0Instead, it defines a new OF (with a different OCP) based on MRHOF. =C2=A0Is that correct? 288 =C2=A0 The ways in which the CA OF modifies MRHOF in a section-by-sect= ion 289 =C2=A0 manner follows in detail: [minor] s/CA OF modifies MRHOF/CA OF differs from MRHOF ... 298 =C2=A0 [MRHOF], Section 3 "The Minimum Rank with Hysteresis Objective 299 =C2=A0 Function": 300 =C2=A0 =C2=A0 =C2=A0Same as MRHOF extended to AP selection. =C2=A0Mini= mum Rank path 301 =C2=A0 =C2=A0 =C2=A0selection and switching applies correspondingly to= the AP with the 302 =C2=A0 =C2=A0 =C2=A0extra CA requirement of having some match between = ancestors. [] "extra CA requirement of having some match between ancestors" You're referring to the policies defined =C2=A73, right? =C2=A0If so, pleas= e say so. 304 =C2=A0 [MRHOF], Section 3.1 "Computing the Path Cost": 305 =C2=A0 =C2=A0 =C2=A0Same as MRHOF extended to AP selection. =C2=A0If a= candidate neighbor 306 =C2=A0 =C2=A0 =C2=A0does not fulfill the CA requirement then the path = through that 307 =C2=A0 =C2=A0 =C2=A0neighbor SHOULD be set to MAX_PATH_COST, the same = value used by 308 =C2=A0 =C2=A0 =C2=A0MRHOF. =C2=A0As a result, the node MUST NOT select= the candidate 309 =C2=A0 =C2=A0 =C2=A0neighbor as its AP. [minor] s/the path...set to MAX_PATH_COST/the path cost...set to MAX_PATH_C= OST [major] "SHOULD be set to MAX_PATH_COST...MUST NOT select" When is it ok to not set the path cost to MAX_PATH_COST? =C2=A0Why is this action recommended and not required? I realize that rfc6719 also only recommends the setting. =C2=A0This is the text from =C2=A73.1: =C2=A0 =C2=A0If the selected metric is a link metric and the metric of the = link to =C2=A0 =C2=A0a neighbor is not available, the path cost for the path throug= h that =C2=A0 =C2=A0neighbor SHOULD be set to MAX_PATH_COST. =C2=A0This cost value= will =C2=A0 =C2=A0prevent this path from being considered for path selection. The difference is that the text in rfc6719 goes on to say what the expected result of setting the cost to MAX_PATH_COST is -- in a non-normative way. OTOH, this document follows up by saying that "As a result, the node MUST NOT select the candidate neighbor as its AP." =C2=A0So -- the required action to not select is contingent on the recommended action of setting the cost. =C2=A0What are the cases when it is ok to not use MAX_PATH_COST? [Even if you use the wording from rfc6719 I will still want to know when it is ok to not use MAX_PATH_COST.] ... 319 =C2=A0 [MRHOF], Section 3.2.2 "Parent Selection Algorithm": 320 =C2=A0 =C2=A0 =C2=A0Same as MRHOF extended to AP selection. =C2=A0If t= he smallest path cost 321 =C2=A0 =C2=A0 =C2=A0for paths through the candidate neighbors is small= er than 322 =C2=A0 =C2=A0 =C2=A0cur_ap_min_path_cost by less than PARENT_SWITCH_TH= RESHOLD (the 323 =C2=A0 =C2=A0 =C2=A0same variable as MRHOF uses), the node MAY continu= e to use the 324 =C2=A0 =C2=A0 =C2=A0current AP. =C2=A0Additionally, if there is no PP = selected, there MUST 325 =C2=A0 =C2=A0 =C2=A0NOT be any AP selected as well. =C2=A0Finally, as = with MRHOF, a node 326 =C2=A0 =C2=A0 =C2=A0MAY include up to PARENT_SET_SIZE-1 additional can= didate neighbors 327 =C2=A0 =C2=A0 =C2=A0in its alternative parent set. =C2=A0The value of = PARENT_SET_SIZE is 328 =C2=A0 =C2=A0 =C2=A0the same as in MRHOF. [minor] s/MUST NOT be any AP selected as well/MUST NOT be any AP selected e= ither ... 336 =C2=A0 [MRHOF], Section 3.5 "Working without Metric Containers": 337 =C2=A0 =C2=A0 =C2=A0It is not possible to work without metric containe= rs, since CA AP 338 =C2=A0 =C2=A0 =C2=A0selection requires information from parents regard= ing their parent 339 =C2=A0 =C2=A0 =C2=A0sets, which is transmitted via the NSA object in t= he DIO Mectric 340 =C2=A0 =C2=A0 =C2=A0Container. [major] "It is not possible to work without metric containers..." What if the metric container is not present? =C2=A0Is this one of the risks that should also be mentioned in the Security section? ... 353 =C2=A0 =C2=A0 =C2=A0Alternative parent set: =C2=A0Corresponding to the= MRHOF parent set. 354 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The size is defined by the same PARENT_SET= _SIZE parameter as in 355 =C2=A0 =C2=A0 =C2=A0 =C2=A0 MRHOF. =C2=A0The Alternative parent set MU= ST be a non-strict subset 356 =C2=A0 =C2=A0 =C2=A0 =C2=A0 of the parent set. [major] "MUST be a non-strict subset of the parent set" Maybe I don't understand the full meaning of non-strict, but the AP set should at least not include the PP, right? =C2=A0That means that the AP set has to be a strict subset of the parent set. =C2=A0What am I missing? 358 =C2=A0 =C2=A0 =C2=A0cur_ap_min_path_cost: =C2=A0Corresponding to the M= RHOF 359 =C2=A0 =C2=A0 =C2=A0 =C2=A0 cur_min_path_cost variable. =C2=A0To suppo= rt the operation of the 360 =C2=A0 =C2=A0 =C2=A0 =C2=A0 hysteresis function for AP selection. [major] "Corresponding to the MRHOF cur_min_path_cost variable." This is an additional variable which is similar to cur_min_path_cost, right? =C2=A0IOW, you're not replacing one with the other. ... 371 4.1. =C2=A0Usage 373 =C2=A0 All OF policies apply their corresponding criterion to filter t= he 374 =C2=A0 list of candidate neighbours in the alternative parent set. =C2= =A0The AP 375 =C2=A0 is then selected from the alternative parent set based on Rank = and 376 =C2=A0 using hysteresis as is done for the PP in MRHOF. =C2=A0It is no= teworthy 377 =C2=A0 that the OF uses the same Objective Code Point (OCP): TBD1 for = all 378 =C2=A0 policies used. [minor] s/All OF policies/All Common Ancestor AP Selection Policies (Sectio= n 3) [minor] s/Objective Code Point (OCP): TBD1/Objective Code Point (OCP) (TBD1= ) 380 =C2=A0 The PS information can be used by any of the described AP selec= tion 381 =C2=A0 policies or other ones not described here, depending on require= ments. 382 =C2=A0 It is optional for all nodes to use the same AP selection polic= ies. 383 =C2=A0 Different nodes may use different AP selection policies, since = the 384 =C2=A0 selection policy is local to each node. =C2=A0For example, usin= g different 385 =C2=A0 policies can be used to vary the transmission reliability in ea= ch 386 =C2=A0 hop. [] It is ok to not require the same policy for on all nodes, but it opens questions about policy selection and configuration (below). [major] Operational Considerations: How should an operator choose which policy to apply where? =C2=A0I understand the difference with respect to the strictness, but what makes a policy appropriate for a specific situation. =C2=A0For example, (just making this up) should more strict policies be applies closer to the edge (leaves) of the network where there's a greater probability of common GP? I later found Appendix B... =C2=A0Please reference it from here. [major] How are the different policies provisioned at different nodes? =C2=A0In many instances the root decides about the behavior of the DODAG and propagates that information (all do the same). =C2=A0But in this case all nodes won't have the same configuration. =C2=A0How is that provisioned? 388 5. =C2=A0Node State and Attribute (NSA) object type extension ... 455 =C2=A0 The structure of the DAG Metric Container data in the form of a= Node 456 =C2=A0 State and Attribute (NSA) object with a TLV in the NSA Optional= TLVs 457 =C2=A0 field is shown in Figure 3. =C2=A0The first 32 bits comprise th= e DAG 458 =C2=A0 Metric Container header and all the following bits are part of = the 459 =C2=A0 Node State and Attribute object body, as defined in [RFC6551]. = =C2=A0This 460 =C2=A0 document defines a new TLV, which MAY be carried in the Node St= ate 461 =C2=A0 and Attribute (NSA) object Optional TLVs field. =C2=A0The TLV i= s named 462 =C2=A0 Parent Set and is abbreviated as PS in Figure 3. [major] "MAY be carried" It is an optional TLV. =C2=A0However, in the context of this document it is required to convey the PS. =C2=A0I would prefer it if the text mentioned that: "MUST be carried to indicate the PS...". [related] If the network is using the CA OF, what does it mean for the TLV to not be present? =C2=A0Everyone has a parent...well, except for the root... ... 466 =C2=A0 PS Length: =C2=A0The total length of the TLV value field (PS IP= v6 467 =C2=A0 =C2=A0 =C2=A0 =C2=A0 address(es)) in bytes. =C2=A0The length is= an integral multiple of 468 =C2=A0 =C2=A0 =C2=A0 =C2=A0 16, the number of bytes in an IPv6 address= . [major] If my math is correct, the length cannot be larger than 240. What should the receiver do if the length is not a multiple of 16 or more than 240? [minor] Is 0 a valid length? =C2=A0What does it mean to not have parents? 470 =C2=A0 PS IPv6 address(es) =C2=A0One or more 128-bit IPv6 address(es) = without any 471 =C2=A0 =C2=A0 =C2=A0 =C2=A0 separator between them. =C2=A0The field co= nsists of one IPv6 address 472 =C2=A0 =C2=A0 =C2=A0 =C2=A0 per parent in the parent set. =C2=A0The pa= rent addresses are listed 473 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in decreasing order of preference and not = all parents in the 474 =C2=A0 =C2=A0 =C2=A0 =C2=A0 parent set need to be included. =C2=A0The = selection of how many 475 =C2=A0 =C2=A0 =C2=A0 =C2=A0 parents from the parent set are to be incl= uded is left to the 476 =C2=A0 =C2=A0 =C2=A0 =C2=A0 implementation. =C2=A0The number of parent= addresses in the PS IPv6 477 =C2=A0 =C2=A0 =C2=A0 =C2=A0 address(es) field can be deduced by dividi= ng the length of the 478 =C2=A0 =C2=A0 =C2=A0 =C2=A0 PS IPv6 address(es) field in bytes by 16, = the number of bytes 479 =C2=A0 =C2=A0 =C2=A0 =C2=A0 in an IPv6 address. [] I am surprised that these addresses were not compressed. 481 5.1. =C2=A0Usage 483 =C2=A0 The PS SHOULD be used in the process of parent selection, and 484 =C2=A0 especially in AP selection, since it can help the alternative p= ath to 485 =C2=A0 not significantly deviate from the preferred path. =C2=A0The Pa= rent Set is 486 =C2=A0 information local to the node that broadcasts it. [major] "PS SHOULD be used" What are the cases where it should not be used, or when it is ok to not use it? =C2=A0In the context of this document, why is the use recommended and not required? The CA policy is defined per-node...and also (from above) the propagation of the PS is not required. =C2=A0Not propagating the PS may undermine any efforts the downstream has to figure out their GP... 488 =C2=A0 The PS is used only within NSA objects configured as a metric, 489 =C2=A0 therefore the DAG Metric Container field "C" MUST be 0. 490 =C2=A0 Additionally, since the information in the PS needs to be propa= gated 491 =C2=A0 downstream but it cannot be aggregated, the DAG Metric Containe= r 492 =C2=A0 field "R" MUST be 1. =C2=A0Finally, since the information conta= ined is by 493 =C2=A0 definition partial, more specifically just the parent set of th= e DIO- 494 =C2=A0 sending node, the DAG Metric Container field "P" MUST be 1. [major] What should a receiver do if the PS is included but the flags are not set correctly? 496 =C2=A0 It is important that the PS does not affect the calculation of = the 497 =C2=A0 rank through candidate neighbors. =C2=A0It is only used with th= e CA OF to 498 =C2=A0 remove nodes which do not fulfill the CA OF criteria from the 499 =C2=A0 candidate neighbor list. [] I'm not sure what you're trying to get to with the first sentence. Are you saying that the PS shouldn't be used for anything else? =C2=A0How can you prevent that? =C2=A0What if in the future there's a new use? 501 6. =C2=A0Controlling PRE 503 =C2=A0 PRE is very helpful when the aim is to increase reliability for= a 504 =C2=A0 certain path, however its use creates additional traffic as par= t of 505 =C2=A0 the replication process. =C2=A0It is conceivable that not all p= aths have 506 =C2=A0 stringent reliability requirements. =C2=A0Therefore, a way to c= ontrol 507 =C2=A0 whether PRE is applied to a path's packets SHOULD be implemente= d. 508 =C2=A0 For example, a traffic class label can be used to determine thi= s 509 =C2=A0 behavior per flow type as described in Deterministic Networking 510 =C2=A0 Architecture [RFC8655]. [major] "a way to control whether PRE is applied to a path's packets SHOULD be implemented." Why is this a recommendation and not a requirement? =C2=A0Is it expected that if PRE is available on the node that it should apply to all traffic? =C2=A0Even if the configuration knob existed, what criteria should the network operator use to decide whether to activate PRE or not? 512 7. =C2=A0Security Considerations [major] Please indicate that the security considerations from rfc6550, rfc6551, and rfc6719 apply. 514 =C2=A0 The structure of the DIO control message is extended, within th= e pre- 515 =C2=A0 defined DIO options. =C2=A0The additional information are the I= Pv6 516 =C2=A0 addresses of the parent set of the node transmitting the DIO. = =C2=A0This 517 =C2=A0 use of this additional information can have the following poten= tial 518 =C2=A0 consequences: 520 =C2=A0 * =C2=A0A malicious node that can receive and read the DIO can = "see" 521 =C2=A0 =C2=A0 =C2=A0further than it's own neighbourhood by one hop, le= arning the 522 =C2=A0 =C2=A0 =C2=A0addresses of it's two hop neighbors. =C2=A0This is= a privacy / network 523 =C2=A0 =C2=A0 =C2=A0discovery issue. [] I would stay away from "privacy". =C2=A0In general, similar information can be gleaned by looking at the traffic and (in storing mode) holding routes. =C2=A0Topology discovery inside a domain is usually not an issue. OTOH, if you have real privacy concerns, please take a look at rfc6973 and include a section on it. ... 532 8. =C2=A0IANA Considerations 534 =C2=A0 This proposal requests the allocation of a new value TBD1 from = the 535 =C2=A0 "Objective Code Point (OCP)" sub-registry of the "Routing Proto= col 536 =C2=A0 for Low Power and Lossy Networks (RPL)" registry. 538 =C2=A0 This proposal also requests the allocation of a new value TBD2 = for 539 =C2=A0 the "Parent Set" TLV from the "Routing Metric/Constraint TLVs" = sub- 540 =C2=A0 registry of the "Routing Protocol for Low Power and Lossy Netwo= rks 541 =C2=A0 (RPL) Routing Metric/Constraint" registry. [nit] s/This proposal/This document/g ... 569 10.2. =C2=A0Informative references 571 =C2=A0 [I-D.ietf-6tisch-architecture] 572 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thubert, P., "An Archi= tecture for IPv6 over the TSCH mode 573 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0of IEEE 802.15.4", Wor= k in Progress, Internet-Draft, 574 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-ietf-6tisch-arch= itecture-29, 27 August 2020, 575 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0. =3D=3D Outdated reference: draft-ietf-6tisch-architecture has been publishe= d as =C2=A0 =C2=A0RFC 9030 ... 586 =C2=A0 [MRHOF] =C2=A0 =C2=A0Gnawali, O. and P. Levis, "The Minimum Ran= k with 587 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hysteresis Objective F= unction", RFC 6719, 588 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DOI 10.17487/RFC6719, = September 2012, 589 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0. [major] This reference has to be Normative. ... 596 =C2=A0 [RFC2119] =C2=A0Bradner, S., "Key words for use in RFCs to Indi= cate 597 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Requirement Levels", B= CP 14, RFC 2119, 598 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DOI 10.17487/RFC2119, = March 1997, 599 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0. [major] This reference, and the required one to rfc8174, have to be Normati= ve. [EoR -10] From nobody Fri Mar 18 12:23:58 2022 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 E2AFB3A0E8E for ; Fri, 18 Mar 2022 12:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.106 X-Spam-Level: X-Spam-Status: No, score=-2.106 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 AAOcjdLotE-f for ; Fri, 18 Mar 2022 12:23:55 -0700 (PDT) Received: from mail-yb1-xb2a.google.com (mail-yb1-xb2a.google.com [IPv6:2607:f8b0:4864:20::b2a]) (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 870CF3A0ED4 for ; Fri, 18 Mar 2022 12:23:55 -0700 (PDT) Received: by mail-yb1-xb2a.google.com with SMTP id y142so17473186ybe.11 for ; Fri, 18 Mar 2022 12:23:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=yMhSHbr747GOAlnN0G1gd5FtecjR0UYJJ7s4z8h41nw=; b=Nz+hEhJkYnwz4O1xvvn8+U/lkM0OIN5R5yAkwyKu5gU4gMeFd3FVk1TkKQvvS/e3Fv BD+5cVsdRx+gfB/NJIBiLJCZVoG3OHKBQIwDmxz+Tn9o07tBqV6e7EgCuH2u7MpIDPsD BJmEGvogkBdU0QvhdHNmZRyx8gzlfv8QkFBloDecxUWokr4bZ8gGzsEd7OWzLIeSRZSc QiMIhIv20627QJD4E/ab6w5puWDmivZFyz8I12CNKfJs1gTWt5bGHmdg7qzp2WKs/xJv UQ8wsuw0WC4P3gwoYavLfo2hmAEp8gQVHS0WVh/wqSoIlbFGKTQ6eAuLTJcNGSAv3cXc cFxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=yMhSHbr747GOAlnN0G1gd5FtecjR0UYJJ7s4z8h41nw=; b=SGrKiyq/Y/Pnhhgp2m9KJHv/3j5JQkSuQuDlWSzoY5mz+Tt2ObK3w35h/mOAW3gBYP KBYARQWU6xynCwoa/28ljq/xY8QJoJAALd7tD1gPix9gXyfAOGIdf28ZQMey+krL126n gOYEQ5DRLTENNaNw+Fvc7jRBKrwmh28ZSL2sIVUJ6fhPcKpB5q+oNwYp2Sl6I5yNWWJd vc7wGlx+TtXALaBjcEvzydVYkMODjr7R4+qRWm8LewIMDhhI87esHFaR1z9PW9V0jPtX yVFKXU+Y+i0VfDMKay4KFHVUbgu7gPd/8OogigjFnZNTEgfloiE8MI1zQy/8nqBT/IGX 9EvQ== X-Gm-Message-State: AOAM530cr1DrBZGvE/umL6QhCvJk9s3uULArc07bcv5MDAXHtVdRh/+2 tUryKnqnduNxWzLbSyhzcGQCzgXW8iehslGHiICsq55H X-Google-Smtp-Source: ABdhPJzVo2IoXlQ0TSbITc5NiBvgPufFnck83wb8zONBc2Gs0+toP8Sfa0Ety3aCWnSu2cUSYhvKoaqZGIpSenRfT00= X-Received: by 2002:a05:6902:311:b0:625:22a0:a5ec with SMTP id b17-20020a056902031100b0062522a0a5ecmr11691832ybs.573.1647631434083; Fri, 18 Mar 2022 12:23:54 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ines Robles Date: Fri, 18 Mar 2022 21:23:18 +0200 Message-ID: To: roll Content-Type: multipart/alternative; boundary="00000000000059727f05da831677" Archived-At: Subject: [Roll] IETF 113 - Agenda 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, 18 Mar 2022 19:23:57 -0000 --00000000000059727f05da831677 Content-Type: text/plain; charset="UTF-8" Dear all, Please find below the link to the agenda for the IETF 113. https://datatracker.ietf.org/meeting/113/materials/agenda-113-roll-02 Comments welcome, Thank you, Ines and Dominique. On Tue, Feb 22, 2022 at 10:46 AM Ines Robles wrote: > Dear all, > > Please let us know by 4th March if you desire to present a topic at the > IETF 113. We will have a one hour time-slot. Please indicate in your > request: > *Topic, > *Presenter, > *Required time. > * If you will be Onsite or Remote > > Thank you in advance, > > Ines and Dominique > --00000000000059727f05da831677 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

Please f= ind below the link to the agenda for the IETF 113.=C2=A0


Comments welcome,
<= br>
Thank you,=C2=A0

Ines and Dominique.= =C2=A0

On Tue, Feb 22, 2022 at 10:46 AM Ines Robles <mariainesrobles@googlemail.com>= wrote:
Dear all,

Please let us know by 4th March i= f you desire to present a topic at the IETF 113. We will have a one hour ti= me-slot. Please indicate in your request:=C2=A0
*Topic,=C2=A0
*Presenter,=C2=A0
*Required time.
* If you will = be Onsite or Remote

Thank you in advance,

Ines and Dominique
--00000000000059727f05da831677-- From nobody Fri Mar 18 14:10:45 2022 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 22E4D3A119D for ; Fri, 18 Mar 2022 14:10:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 vpK8K42YmSoc for ; Fri, 18 Mar 2022 14:10:39 -0700 (PDT) Received: from mail.mimuw.edu.pl (mail.mimuw.edu.pl [193.0.96.6]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 69D833A1196 for ; Fri, 18 Mar 2022 14:10:38 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by duch.mimuw.edu.pl (Postfix) with ESMTP id 6AEE861FE2C37 for ; Fri, 18 Mar 2022 22:10:35 +0100 (CET) X-Virus-Scanned: amavisd-new at mimuw.edu.pl Received: from duch.mimuw.edu.pl ([127.0.0.1]) by localhost (mail.mimuw.edu.pl [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id FaxULw1Q-_ye for ; Fri, 18 Mar 2022 22:10:33 +0100 (CET) Received: from [192.168.0.31] (unknown [213.134.178.208]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by duch.mimuw.edu.pl (Postfix) with ESMTPSA for ; Fri, 18 Mar 2022 22:10:32 +0100 (CET) Message-ID: <5fad2f45-02a5-7241-f797-43165b0fc9a2@mimuw.edu.pl> Date: Fri, 18 Mar 2022 22:10:25 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:91.0) Gecko/20100101 Thunderbird/91.7.0 From: Konrad Iwanicki To: Routing Over Low power and Lossy networks References: <49ac5fc3-4a3c-fb87-d366-eb7e7cfd60df@mimuw.edu.pl> <18233.1583176305@localhost> <10272666-28c7-ab3e-9ceb-1b8f2bb6e5e5@mimuw.edu.pl> <02c7a894-b7a8-8fcb-9119-172a91a3871b@mimuw.edu.pl> <8421.1620834368@localhost> <21a67951-92c7-5cfa-7bda-a11ac004492c@mimuw.edu.pl> <260038.1647531160@dooku> Content-Language: en-US In-Reply-To: <260038.1647531160@dooku> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Roll] Border router failure detection 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, 18 Mar 2022 21:10:44 -0000 Thanks Michael for your comments. Please, find my replies inline. On 17.03.2022 16:32, Michael Richardson wrote: > Konrad Iwanicki wrote: > > Since the RNFD draft has been adopted by the group, I am expected to > > propose a set of work items on which we could iterate to progress on > > the draft. > > Please note that it is an anti-pattern (a pathology) of the IETF that we > think that we have to improve/change the document after adoption. > It might be that there is little work to do, but we won't really know until > more people have read it. I think I am starting to see your point of view. > > More specifically, achieving consensus in RNFD is done in such a way > > that the root node need not be involved. As long as the network remains > > connected, the nodes are able to conclude that the root has crashed, > > irrespective of how degenerated the DODAG may be because of the > > crash. What Pascal suggested (or at least what I understood) is that > > involving the root and using perhaps a different consensus algorithm > > may be worth considering. > > The idea being, I think, if the root hasn't crashed, it ought to be able to > quickly prove that to all parties involved. This is already present in the algorithm: the second paragraph of Section 5.4. Essentially, if the root observes that something wrong may be going on, it increases the DODAG Version (and resets its Trickle timer). In this way, the nodes (falsely) suspecting that the root may be down get a proof of its activity. > The hidden node problem means that that some nodes might think that the root has > gone, when it is just not very reachable to that node. > > A node that can speak to many other rank=2 ("root-children"?) nodes, but > can't see the root ought to just become a child of those other nodes. This is also what is already happening. Unless there is consensus that the root is considered down by all nodes, RNFD does not influence RPL's decision as to what parent a node is allowed to choose. Therefore, if a root's child's link to the root goes bad, the child will select another parent instead of the root, possibly another child or even a node deeper in the DODAG. I may be wrong, but what I understood from Pascal's idea is that we could try to get the root more involved in the process of coordinating the children acting as sentinels, at least in the periods when it is up. Best, -- - Konrad Iwanicki. > > (Also, I believe that discussing the work items should first be done > > asynchronously/offline. However, if you prefer allocating a slot at > > IETF 113, please do let me know.) > > Discussion on the ML is always good and appropriate. > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > From nobody Mon Mar 21 12:38:38 2022 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 3A00A3A14F3 for ; Mon, 21 Mar 2022 12:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.107 X-Spam-Level: X-Spam-Status: No, score=-2.107 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 wXsuIZ50ZQpZ for ; Mon, 21 Mar 2022 12:38:31 -0700 (PDT) Received: from mail-yb1-xb36.google.com (mail-yb1-xb36.google.com [IPv6:2607:f8b0:4864:20::b36]) (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 618963A14EC for ; Mon, 21 Mar 2022 12:38:31 -0700 (PDT) Received: by mail-yb1-xb36.google.com with SMTP id m67so29975303ybm.4 for ; Mon, 21 Mar 2022 12:38:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vHHaIvHWwiUwPuueEssuQa5I6wgPbrM1aK/b7EHatfE=; b=A8LzKAyxL1I8Va5+QsGieJdg2B+EuXhi5xaoU5eCb2Qyg/QIN+fnOhVy+Eme6UNhrk rv3AeVQH0k0iIJ0jiBpKl468gKJEy/Mj8g+OkrGrIb/2yvlMa5f9YpKv7lh/vPYtfLST qrrbGEA2+Yay4i5KpuPsb3nMTS0LEuimQW1w+Xj+IO1YghIk0ds10g12/ywOVHJg+SGb ZKN38t6jVeFFl4xHMssu2xp7Ue2s0ImadHIwIFGWo1ldT1IrN0vMERFi0SJrOOuF+vBY c+QAFpALvuiNkx/oDEgk5kDsLbNZVoSWq9fmrGFqIO7d6bVC2uyEJjHXH/tQFa2nT+Py 5VdQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vHHaIvHWwiUwPuueEssuQa5I6wgPbrM1aK/b7EHatfE=; b=GkoOHIQR9W5HPjnvu2BUHU/Cd256vezUTOwkxUD8c4NosPZDp/DuoHu5Gp2x/jNeJG z9G1+mqNdi6EAURUGGgiDlDwcjD5fOZDk8u4MNahpl+ixb6W7iodCfiPMfHddXl0trgk nA1isdiEJ64LmdtIgW9T9FWFEqV/OiTDXL7rufKK8RoxaL6ZSvd5rLswR3BYB5tXKak5 RsdE8of3eC4Lx+arzf0BUNhQnqYULQN6LUteHF1POIg0UKk51kDW2PPrJe62jQQb6z8f SFc0/9B2KrCTU9dEJObEzGWc6T2NmRGsq6eAz+AnlTnnd+t06eefuJZfYh4kJ7E8Vbhf AXBQ== X-Gm-Message-State: AOAM530QVqQkrEa2ZLTL69dVbr4Go/prga8VA4fsrTRqo4d9uDkOD7jR lHPqZdtjByxH/MUrmRo2viDyf7ZBeLRf8QCpokkToeW/S2o= X-Google-Smtp-Source: ABdhPJxJSOX1p/hBm8lY9Supr8fRgt5waoycFQ/j5AXAy3VFovY8evQciSs2REvSCRP8PZFuWsaBjg11LNASflZtPso= X-Received: by 2002:a5b:787:0:b0:624:107a:6c45 with SMTP id b7-20020a5b0787000000b00624107a6c45mr22798480ybq.24.1647891510089; Mon, 21 Mar 2022 12:38:30 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ines Robles Date: Mon, 21 Mar 2022 21:37:54 +0200 Message-ID: To: roll Content-Type: multipart/alternative; boundary="000000000000165ca705dabfa48e" Archived-At: Subject: [Roll] IETF 113 - Consolidated Slides 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, 21 Mar 2022 19:38:36 -0000 --000000000000165ca705dabfa48e Content-Type: text/plain; charset="UTF-8" Dear all, Please find below the consolidated slide set for IETF 113 https://datatracker.ietf.org/meeting/113/materials/slides-113-roll-roll-ietf113-consolidated-00.pdf Comments welcome, Thank you, Ines and Dominique On Fri, Mar 18, 2022 at 9:23 PM Ines Robles wrote: > Dear all, > > Please find below the link to the agenda for the IETF 113. > > https://datatracker.ietf.org/meeting/113/materials/agenda-113-roll-02 > > Comments welcome, > > Thank you, > > Ines and Dominique. > >> >> --000000000000165ca705dabfa48e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

<= /div>
Please find below the consolidated slide set for IETF 113


Comments welcome,

Thank you,

Ines and Dominique

On Fri, Mar 18,= 2022 at 9:23 PM Ines Robles <mariainesrobles@googlemail.com> wrote:
De= ar all,

Please find below the link to the agenda for= the IETF 113.=C2=A0

http= s://datatracker.ietf.org/meeting/113/materials/agenda-113-roll-02

Comments welcome,

Than= k you,=C2=A0

Ines and Dominique.=C2=A0
=
> S=0" instead of just 1 or 0, and holding on to the (symmetric) address > > vector from OrigNode to B. Then B could perform translation from the > > asymmetric to symmetric regime for the RREP and all routers on the path > > would be able to install useful route entries. But there's not anything > > in the current text to suggest that B should be doing that.) > > As described above, I agree about the usefulness of allowing an > intermediate node to store a symmetric address vector.  This will be > specified as an optional behavior in the revised document. > > > > > (2) I'm putting this in the Discuss section because I think it's > > important for the authors/WG to produce an answer. Since I've been > > wrong about it at least once, I do not claim to know the correct answer, > > and thus the Discuss point ought to be easy to resolve. > > > > Section 6.3.3 says: > > > > Instead, the RPLInstanceID MUST be replaced by > > another value so that the two RREP-instances can be distinguished. > > In RREP-DIO option, the Shift field of the RREP-DIO message(Figure 2) > > indicates the shift to be applied to original RPLInstanceID to obtain > > the replacement RPLInstanceID. When the new RPLInstanceID after > > shifting exceeds 255, it rolls over starting at 0. For example, if > > the original RPLInstanceID is 252, and shifted by 6, the new > > RPLInstanceID will be 2. [...] > > > > I know that the use of 255 as the largest value here comes as a result > > of my earlier review, but wanted to note that the resulting discussion > > thread may not have fully concluded. > > In particular, I now see > > https://datatracker.ietf.org/doc/html/rfc6550#section-5.1 that does > > indicate that only 6 bits of "usable" ID are present for local > > RPLInstanceIDs, which seem to be the ones in use here. Sorry to have > > missed that in my initial review; I hope that we can figure out what the > > actual correct boundary value is. > > All 8 bits of the ID are usable.  The design allows for 64 possible > alternative choices in the case of a collision.  Collisions are rare, so > that should be plenty.  Providing a "shift" operation does not place any > restriction on use of all 8 bits for choice of ID.  It just enables the > elimination of ID collisions for all foreseeable cases. Okay, thank you for double-checking. > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- Trimming... > > Section 4.3 > > > > Target Prefix / Address > > (variable-length field) An IPv6 destination address or prefix. > > The Prefix Length field contains the number of valid leading bits > > in the prefix. The Target Prefix / Address field contains the > > least number of octets that can represent all of the bits of the > > Prefix, in other words Ceil(Prefix Length/8) octets. The initial > > bits in the Target Prefix / Address field preceding the prefix > > length (if any) MUST be set to zero on transmission and MUST be > > ignored on receipt. If Prefix Length is zero, the Address field > > is 128 bits for IPv6 addresses. > > > > This is a change from the -10 about where the target prefix is aligned > > for prefix lengths that are not a multiple of 8. > > I have no stance on which formulation is best, but it seems very > > surprising to change the wire encoding in this manner at such a late > > stage in the document lifecycle, without specific compelling reasoning. > > It is still allowable to have Prefixes that are not multiples of 8. It's > just that representing those prefixes still takes an integral number of > bytes in the message field.  For prefixes that are not multiples of 8, > some of the bits in the message field are ignored. Sorry, I was unclear here. In my reading what changed was whether the padding bits were "on the left" or "on the right" (when there are padding bits at all). That is, in the -10, I thought that even for non-multiple-of-8 prefix length, the non-padding bits were aligned to start at the beginning (left) of the field, whereas in the -11 and later these initial bits are the padding bits. [LOTS of very informative detailed explanations trimmed -- thank you!] > > > > It seems that if Compr is set too large, there is some risk of a node > > failing to check that it shares that many bits of address prefix with > > the address in the DODAGID and thus decompression would produce an > > incorrect route. > > We could provide additional specification, but I am not sure it is needed. > > Old: > >    Compr >       4-bit unsigned integer.  Number of prefix octets that are elided >       from the Address Vector.  The octets elided are shared with the >       IPv6 address in the DODAGID.  This field is only used in source >       routing mode (H=0).  In hop-by-hop mode (H=1), this field MUST be >       set to zero and ignored upon reception. > > New: > >    Compr >       4-bit unsigned integer.    When Compr is nonzero, exactly that >       number of prefix octets MUST be elided from each address in >       the Address Vector.  The octets elided are shared with the >       IPv6 address in the DODAGID.  This field is only used in source >       routing mode (H=0).  In hop-by-hop mode (H=1), this field MUST be >       set to zero and ignored upon reception. > > Does this resolve the problem? That seems like an okay change to make, but I was mostly asking about putting a sentence in the security considerations to the effect of "use of address/prefix compression can introduce errors in the recovered address/prefix, if the router applying compression does not properly check that the bits being elided are compressible". Thanks, Ben From nobody Mon Mar 21 13:42:40 2022 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 622913A0A74; Mon, 21 Mar 2022 13:42:31 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Benjamin Kaduk via Datatracker To: "The IESG" Cc: draft-ietf-roll-aodv-rpl@ietf.org, roll-chairs@ietf.org, roll@ietf.org, Ines Robles , aretana.ietf@gmail.com, mariainesrobles@googlemail.com X-Test-IDTracker: no X-IETF-IDTracker: 7.46.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Benjamin Kaduk Message-ID: <164789535137.30683.1147416800310471061@ietfa.amsl.com> Date: Mon, 21 Mar 2022 13:42:31 -0700 Archived-At: Subject: [Roll] Benjamin Kaduk's Abstain on draft-ietf-roll-aodv-rpl-13: (with COMMENT) 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, 21 Mar 2022 20:42:32 -0000 Benjamin Kaduk has entered the following ballot position for draft-ietf-roll-aodv-rpl-13: Abstain When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-roll-aodv-rpl/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for the updates in -12 and -13, they're a big help for clarity and readability. I'm abstaining because I don't think this document should be published in its current form, but cannot supply a concrete path to changes that would make it suitable. (I believe that such a path exists, but I cannot provide a proof by construction.) I'm also concerned about the level of review this document has received, with multiple errors having gone uncaught until the IESG Evaluation stage. That said, I do have some additional comments to offer in the hope that they improve the document. Section 6.4.1 (RREP handling) directs the router's processing to proceed to §6.2.2 (RREQ handling), which seems like an unfortunate copy/paste error. I continue to believe that it would be very helpful to depict the 'S bit' information associated with an RREQ-Instance as a tristate rather than a single bit. In essence, this state reflects the contract between adjacent nodes about how to process the corresponding RREP-DIO, but a given (intermediate) router needs to know what contract to use both when processing an incoming RREP-DIO and when emitting an RREP-DIOO (indeed, even to know whether to emit unicast or multicast), and it's hard to see how a single bit could cover both incoming and outgoing RREP-DIOs at the point of transition. A few other section-by-section notes follow. Section 4.1 L 2-bit unsigned integer determining the length of time that a node is able to belong to the RREQ-Instance (a temporary DAG including the OrigNode and the TargNode). Once the time is reached, a node MUST leave the RREQ-Instance and stop sending or receiving any more DIOs for the RREQ-Instance. This naturally depends on the node's ability to keep track of time. Once a node leaves an RREQ- Instance, it MUST NOT rejoin the same RREQ-Instance. L is independent from the route lifetime, which is defined in the DODAG configuration option. I assume that this "MUST NOT rejoin" would have some timeframe associated with it (at least for L != 0x00), since the instance-id could eventually be reused for a different logical instance. Section 4.2 L 2-bit unsigned integer defined as in RREQ option. The lifetime of the RREP-Instance MUST be shorter than the lifetime of the RREQ- Instance to which it is paired. Strictly shorter, or "less than or equal to"? I think, given the limited options, strictly shorter would be pretty disruptive. Section 6.2.4 Suppose a router has joined the RREQ-Instance, and H=0, and the S-bit of the RREQ-Instance is set to 1. In this case, the router MAY optionally associate to the RREQ-Instance, the Address Vector of the symmetric route back to OrigNode. This is useful if the router later receives an RREP-DIO that is paired with the RREQ. I think we should say what happens if I don't do what the MAY says. Do we just fail to find a route entirely, or only with degraded performance, or ...? Section 6.4.2 The router updates its stored value of the TargNode's sequence number according to the value provided in the ART option. The router next checks if one of its addresses is included in the ART Option. If so, this router is the OrigNode of the route discovery. [...] This seems to set up a scenario where TargNode learns about its own sequence number updates by processing the ART Option, which is rather amusing to think about :) NITS Section 6.1 RPLInstance and a DODAG rooted at itself. Then it transmits a DIO message containing exactly one RREQ option (see Section 4.1) to multicast group all-RPL-nodes. The DIO MUST contain at least one ART "the multicast group". From nobody Tue Mar 22 09:08:14 2022 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 922FF3A0123 for ; Tue, 22 Mar 2022 09:08:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.107 X-Spam-Level: X-Spam-Status: No, score=-7.107 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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 Wo0OgYjwB3Ku for ; Tue, 22 Mar 2022 09:08:08 -0700 (PDT) Received: from mail-yb1-xb2e.google.com (mail-yb1-xb2e.google.com [IPv6:2607:f8b0:4864:20::b2e]) (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 E050E3A0121 for ; Tue, 22 Mar 2022 09:08:07 -0700 (PDT) Received: by mail-yb1-xb2e.google.com with SMTP id o5so34526414ybe.2 for ; Tue, 22 Mar 2022 09:08:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=EiaANdgFC8l3M8bP2wa/an/Ialw8gT69vcDisJZbfhA=; b=d3IocbexWQwDyZArN0Oq/kh9OUS/gB0+mdBhCST3xPxc05D3lay5wUnjDF38Y0yb3S W8GbTd5VvX221VAPmLYHDtI4duzH/v/itYpOxcxo7gl99UpoRh+/K0Zh2MCJyaM20cIS iE8EH+cTq3JTjyA4tKDuYG3p2ksdJ9cpd2jZRgXD3cX8zgXtuE66MyInfMoyp21NNqK6 jO4S9uEtdL1lDCdTUM/HCFjymfI9fm2Y1ExRXNFOA2FUHuo0Kw4HSyBovJkTfs7CxNhj BRJMp52PYMR5jJh1b0NmvymscorjVsXIW8rDtY2vSyA1qIXtZOVy2PK9TD+I8j54jAbw Hbjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=EiaANdgFC8l3M8bP2wa/an/Ialw8gT69vcDisJZbfhA=; b=3HU2S9fMvcdoGyM4x/3L6UxSXYRrRXlhIrkNoF+4O5lUVOXdX9QR0qs22r/dL8DVdP QTFiniQsNeB4iZmPxf6QK2oUmQaH94YXmVpNeMj6TPsLuHO+YjX+ua11IXd3NA/Q1Y5Y CEOhBOg0Vhirurf/gMPJADqndZqCyyL2QTg5vkM4NCx2gKhI56MxS+WeWdFc0zzGlBUn k8KoCjUVqUUABPXclEZR2fePQBwyfQVQqKoiJEHyUaKW8wHNiiHbhSFxuZkMEtUc8prg sEXycgRGdKP3vXtTkdxWbj2Uz4+maMhCsLE7R/LI6rOMweCceonVtC3kRVZQ6rWr3XcU RpXQ== X-Gm-Message-State: AOAM530yBuKZ/7+AUjH6ILECyXmoTaY2fP5G74Ug2ZJ03S2daJSlHbeW iSxZ507dCm+TDcCF++kfq1la+uMbWw39rzA7Y4S1uE5K9Js= X-Google-Smtp-Source: ABdhPJwVSe9dcGdks2Umvf1Aab93H11jtVDzxYRUTT6xWeXY4jczPo+Jdq9iENc+j/F4Eb1O2od/rh8eLLJTy+LW0DI= X-Received: by 2002:a5b:787:0:b0:624:107a:6c45 with SMTP id b7-20020a5b0787000000b00624107a6c45mr26530763ybq.24.1647965286754; Tue, 22 Mar 2022 09:08:06 -0700 (PDT) MIME-Version: 1.0 From: Ines Robles Date: Tue, 22 Mar 2022 18:07:31 +0200 Message-ID: To: roll Content-Type: multipart/alternative; boundary="00000000000084ec7705dad0d130" Archived-At: Subject: [Roll] IETF 113 - Request for Minute Taker 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, 22 Mar 2022 16:08:13 -0000 --00000000000084ec7705dad0d130 Content-Type: text/plain; charset="UTF-8" Dear all, We kindly request your help as a minute taker during the ROLL meeting tomorrow. Please let us know if you are willing to volunteer. Notes: https://notes.ietf.org/notes-ietf-113-roll?both Thank you very much, Ines and Dominique --00000000000084ec7705dad0d130 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

We kindly request your=C2= =A0help as a minute taker during the ROLL meeting tomorrow. Please let us k= now if you are willing to volunteer.


Thank you very = much,

Ines and Dominique
--00000000000084ec7705dad0d130-- From nobody Wed Mar 23 08:21:48 2022 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 917413A150C; Wed, 23 Mar 2022 08:21:44 -0700 (PDT) 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: 7.46.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: roll@ietf.org Message-ID: <164804890421.30480.14303817453027088953@ietfa.amsl.com> Date: Wed, 23 Mar 2022 08:21:44 -0700 Archived-At: Subject: [Roll] I-D Action: draft-ietf-roll-dao-projection-25.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, 23 Mar 2022 15:21:45 -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 : Root initiated routing state in RPL Authors : Pascal Thubert Rahul Arvind Jadhav Michael C. Richardson Filename : draft-ietf-roll-dao-projection-25.txt Pages : 84 Date : 2022-03-23 Abstract: THIS RFC extends RFC 6550, RFC 6553, and RFC 8138 to enable a RPL Root to install and maintain Projected Routes within its DODAG, along a selected set of nodes that may or may not include self, for a chosen duration. This potentially enables routes that are more optimized or resilient than those obtained with the classical distributed operation of RPL, either in terms of the size of a Routing Header or in terms of path length, which impacts both the latency and the packet delivery ratio. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-dao-projection/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-roll-dao-projection-25.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-dao-projection-25 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-drafts From nobody Wed Mar 23 08:27:50 2022 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 54C9F3A08CE for ; Wed, 23 Mar 2022 08:27:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.605 X-Spam-Level: X-Spam-Status: No, score=-9.605 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, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=nFgvTOlm; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ehdwAfgs 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 xhN0LsVGuw_m for ; Wed, 23 Mar 2022 08:27:43 -0700 (PDT) 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 F15503A0863 for ; Wed, 23 Mar 2022 08:27:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2146; q=dns/txt; s=iport; t=1648049263; x=1649258863; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=3utZiWgITjTpLWHQtTTJNC1H74QvwOLtlDmZ3NsmMkA=; b=nFgvTOlmisXazQQfVw818ytXiLrlO/3Lp8+umzzJwPEQHUk59A/FeDn4 zZQybKv1ixhjGSVRUPfZHJvGRXRgV0/RoXZ6c/8/1kk/oWNc0iZlUgj8F hSXkWdKrTt69772foAGgqXZontEloRFKvNbLV60xQ9aAglhtCwRrWChT0 s=; X-IPAS-Result: =?us-ascii?q?A0D4AAD5OztimJRdJa1aHgEBCxIMQIFPC4FSVn5aN0SIH?= =?us-ascii?q?gOFOYUQgwIDknKIQ4EuFIERA1QLAQEBDQEBLAsMBAEBgU+DOAKERQIlNAkOA?= =?us-ascii?q?QIEAQEBAQMCAwEBAQEBAQMBAQUBAQECAQcEFAEBAQEBAQEBCRQHBgwFDhAnh?= =?us-ascii?q?WgNhkIBAQEBAwEBECgGAQEsDAsEAgEIEQQBAR8QJwsbAQEFAwIEEwgagmIBg?= =?us-ascii?q?mUDLgEOoFUBgToCgQ6JEXiBM4EBgggBAQYEBIE7Ag5Bgn8YgjcDBoE8gxGLO?= =?us-ascii?q?SccgUlEgRVDgmc+gmMBAQEBAReBDBELIINPgi6XJy9TYVECFDsMAgkygRlGw?= =?us-ascii?q?CwKg0mLD4shiWEVqECWWyCMdZQhHIUHAgQCBAUCDgEBBoFhghVwFRohgmlRG?= =?us-ascii?q?Q+OIBmDWYUUhUp1AjYCBgsBAQMJjgqCSAEB?= IronPort-PHdr: A9a23:Fz66GRKrl7yvVk247tmcuWEyDhhOgF28FgIW659yjbVIf+zj+pn5J 0XQ6L1ri0OBRoTU7f9Iyo+0+6DtUGAN+9CN5XYFdpEfWxoMk85DmQsmDYaMAlH6K/i/aSs8E YxCWVZp8mv9P1JSHZP1ZkbZpTu56jtBcig= IronPort-Data: A9a23:fhAoeaBmkOs99hVW/yfjw5YqxClBgxIJ4kV8jS/XYbTApDxw1DAAm mEdUW2Daa2KMWWhc9F/bI6zpk9XusXRndFnOVdlrnsFo1CmBibm6XV1Cm+qYkt+++WaFBoPA /02M4WGdIZuJpPljk/F3oLJ9RGQ7onVAOukYAL4EnopH1U8E3160UsLd9MR2+aEv/DoW2thh vuqyyHvEAfNN+lcaz98Bwqr8XuDjdyq0N8qlgVWicNj4Dcyo0Io4Kc3fsldGZdXrr58RYZWT 86bpF2wE/iwEx0FUrtJmZ6jGqEGryK70QWm0hJrt6aebhdq5XBiib9jOaYgSGQImS6budMpz JJInMnlIespFvWkdOU1SRJUFWR1OrdLveadZ3O+qseUiUbBdhMAwd03UxpwZtJeq70xWD0en RAbAGhlghSrn/623bi2UPVEjcU4J86tN4Qa0p1l5WGCVat+EMCaHs0m4/dTxDMw3s8NNsrhW PonVxVrURKHezZmbwJ/5JUWxbf02SaXnydjgEiSoa4f4mXPwkp2yreFDTbOUsaBScMQlUGCq yefpSLyAwoRM5qUzj/tHm+QavHn3n+rA5tKGeGE1901kkaB4G9LDFoTfA7uyRWmsXKWV9VaI k0S3yMhq6ku6UCmJuURuTXl/BZoWTZBALJt//0GBBKlkfCFv1nDboQQZnsQNoN+7pBeqSkCj wfRx7vU6SpTXKp5oJ533o2VpjO7IyQOKmlqicQsElZds4CLTG3ecnvyojtLCqW5iJj+Hiv9h mnQ6iM/nL4Uy8UM0s1XHGwrYRrx+fAlrSZsu207u15JCCsiPuZJgKTzsjDmAQ5odtrxc7V4l CFsdzKixO4PF4qRsyeGXf8AGrqkj97cbmGD0AE0T8B4rGjzk5JGQWy2yGwhTKuOGptaEQIFn GeP0e+szMYJZSDzPfMfj3yZUph7lsAM6ugJptiNPoYRPfCdhSeM/TplYgaLznvxnU03+ZzTy r/FGftA+U0yUPw9pBLvHr91+eZymkgWmDOCLbimnk/P+efPOxa9F+xfWHPQNb9R0U9xiFiPm zqpH5HUm0w3vSyXSnS/zLP/2nhRdCllX8+q85ILHgNBSyI/cFwc5zbq6etJU+RYc259zY8kI lnVtpdk9WfC IronPort-HdrOrdr: A9a23:S7bkN62MCUgWitpVd/A+kAqjBRhyeYIsimQD101hICG9Lfb3qy n+ppsmPEHP5Ar5AEtQ5exoS5PwPk80kqQFrrX5XI3SEDUO3VHIEGgM1/qa/9VvcReOjtK1uZ 0QEZSWTeeAcGSS7vyKrjVQcexQu+VvmZrA7Yy1ohcdLj2CKZsQlTuRYTzrdnGeMTM2Y6bRY6 DsgfavyQDQHEg/X4CePD0oTuLDr9rEmNbNehgdHSMq7wGIkHeB9KP6OwLw5GZebxp/hZMZtU TVmQ3w4auu99uhzAXH6mPV55NK3PP819p4AtCWgMR9EESttu/oXvUjZ1SxhkFxnAid0idvrD AKmWZmAy1H0QKSQohym2qq5+Cv6kd215ao8y7nvZKqm72JeNt9MbsYuWqcGSGpsXbJe7pHof l2NiuixupqJAKFkyLn69fSURZ20kKyvHo5iOYWy2dSSI0EddZq3MciFW5uYd499RjBmcga+S hVfbXhzecTdUnfY2HSv2FpztDpVnMvHg2eSkxHvsCOyTBZkH1w0kNdnaUk7zo93YN4T4MB6/ XPM6xumr0LRsgKbbhlDONERcesEGTCTR/FLWrXK1X6E6MMPW7LtvfMkf8IzfDvfIZNwIo5mZ zHXl8dvWkue1j2AcnLx5FP+gClehTKYd0s8LAo23FUgMyPeFOwC1zxdLkHqbrUn8ki X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.90,204,1643673600"; d="scan'208";a="830509815" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Mar 2022 15:27:41 +0000 Received: from mail.cisco.com (xfe-rcd-005.cisco.com [173.37.227.253]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 22NFRfXV010770 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK) for ; Wed, 23 Mar 2022 15:27:41 GMT Received: from xfe-aln-004.cisco.com (173.37.135.124) by xfe-rcd-005.cisco.com (173.37.227.253) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Wed, 23 Mar 2022 10:27:40 -0500 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xfe-aln-004.cisco.com (173.37.135.124) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14 via Frontend Transport; Wed, 23 Mar 2022 10:27:40 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=G4+quDknF0DSFcMJyKoKeqEd2R+vTZZ4m+4Q4SmOHy6T8zsFe0SsgqnOFfuFU0X2jvFu8sPs4Vcd78cHC9AqdzCupFkz7ENb0JJIFIZ9+NhvVFQpJgVGxHUmSfM9zxIgHyeAWKCjCdJkQUteGOrgCX1sRuuBpOk3l83l53u0+KWu4SuxHKrDNli6U9LTVMHrWqWX1IZEwjWsKbNnYwq+6q24q21glW+0bq23O+OhT6FQlqfgwDM2t28QKASM19hElYZVdvIg5ZlTom6xJCOdTtrWa1jUNwcLKBbI4tb60DBgxjyS2uMH/FohvaW+XJ6e4/AA3tj0qnA8d2jowDnH0g== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=/Wb8eossi5pTZSJqyYEbPR+yriaXf4oSkBSyFh3kqTE=; b=J605149XFUdJa4t9xgc7Nsdjop4EjmfJ5RJzM7UX9JMOQsY8xLiFcMAZYhagSLZo7iiznlhO8iU46+Ioo2o/5TxM2LiRzI+EPtweD7+0GDLNgtRJq6e66SDUsFHIWQo3J2+Ebq0HGh5bPVVFYOb/scuC19O+HPOAXfjwOTYnoizGlOefPcyStri8bqYA4zwOP7G3C6f0Xqoi8k53JPVtBVHr0fd4sVUBb693LHIoDZLnHOWn3j+HGS3RLWWypw69vG0A3rfbLkVIc5TQjgr3LQsURWaSg10lB0jlIYbc4DEDQhSk997snM1iQPLHWjILmuWmUgMf+suAjaWv37umcw== 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=/Wb8eossi5pTZSJqyYEbPR+yriaXf4oSkBSyFh3kqTE=; b=ehdwAfgsssJxHjmOE8ig3yrgVth7pcVLwt2qjNLpwQ6v+7fS1SYEqYH2dH71F+5+5Ix+CXUTCV3mpnxcP9X5hu2w+Ju9z7qhN4qegbtfDIT/i98zxfNxeg15rZi1GemAOiSTpUpzyPmwL9WPnuCi90pTZJUubSQXWVf81Q/bosE= Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by BYAPR11MB3781.namprd11.prod.outlook.com (2603:10b6:a03:b1::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5081.18; Wed, 23 Mar 2022 15:27:38 +0000 Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::d4d0:b43e:40e8:d888]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::d4d0:b43e:40e8:d888%4]) with mapi id 15.20.5102.016; Wed, 23 Mar 2022 15:27:38 +0000 From: "Pascal Thubert (pthubert)" To: "ROLL WG (roll@ietf.org)" Thread-Topic: [Roll] I-D Action: draft-ietf-roll-dao-projection-25.txt Thread-Index: AQHYPsm9A5fBJVcewkiHkbNcgRJ0jazNFpXw Date: Wed, 23 Mar 2022 15:26:42 +0000 Deferred-Delivery: Wed, 23 Mar 2022 15:26:35 +0000 Message-ID: References: <164804890421.30480.14303817453027088953@ietfa.amsl.com> In-Reply-To: <164804890421.30480.14303817453027088953@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4ef52dd3-dbff-489f-eb92-08da0ce1aa09 x-ms-traffictypediagnostic: BYAPR11MB3781:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: tRWPIXup7kYWtaA9uFlBjkV2FuGRCIgyEYTOWvriFysDq0XAJHWFVHM++DY33f7UKLPVGNeLSoE/Lqcxdo3d3BnqKyO4ld8bnIHAMJ6owlgZ72LEesEicVsGNgZmPHjWs6Ntv3N4yJXkw2ImdHJ8X8F472yf0Z+Ko7uFIoYbB6Yt5Mv0ZJqKxu/CaY6lPXaYYJHJ5Bo9BwH7T/5AN1c8b4Sgvy0WEOjgiXyt3TmrJRQyT+2Y2+mCOnv0SnYAEcoMnC65xQk85sC3JJ+Ux8A0XP70YEiLp9Zbv6rD87YPIYfPCzT7lIuimGJf8Uvsa8M0pWfMZQsg87yiJFxf1QDlUmP4GiN9T8xs+8PTqW1NMTw9kVsR0bNuxanRdSo9/tR/P07Te6uEk1tT6VYPp5i3AWcM0B3e9sVpwyiARvNtIzvUXyxE3NcFDmbZar1EwssNYfWsfEzNVZlOXqLNuBZsisBT8qaaau+ncETPVXCqAMtCSZ6ogHZDhVrPdr2rDhpVimDSHoz1FioUX/bN3CM7SuEjeMAxd+w60itPobS5ADLd086+p7D32c1EQ77m+Do1K/knIJFqu7diONhl5aMbXbCEm0pGdh3GInWAUpC23bLcQkE4sMBD9ifmwfpiv8Rq9lHZxsI+zExNznjvzFWTBQw8w0uvIoq4YhTM2OdnDnQi7tveo0gk+HITFZhNpUULScwUO74PeH7TNfFjSjv4L33fzFM1MNti0GqOGINKpqvHQkcj75kKf5WKWDU7umQCTl6y74LVBpu57fVpdDOQBThH8DFAZVjjflxSz6HYVfo0i7PyCcnkCmOtriF/6qRmyoI4kEcFvvrc1i+nyisdQw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR11MB4881.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(66476007)(66446008)(76116006)(6916009)(86362001)(64756008)(66556008)(71200400001)(66574015)(8676002)(8936002)(83380400001)(186003)(52536014)(66946007)(5660300002)(6666004)(53546011)(38100700002)(55016003)(38070700005)(9686003)(7696005)(6506007)(33656002)(2906002)(508600001)(316002)(122000001)(966005)(26005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?GR7SudrJM0Z1Cw27fN/gml6j3RWDDkG33Xpj3NSt25ACOx4q4aRyIYXWK8C5?= =?us-ascii?Q?3vIIn9GYtx+kniK8gHrSFTlHtI1MNHQkp9bxCyYCW2aT5wxV+rrLp5EetyP4?= =?us-ascii?Q?KuJyJTLi+OKE4ENQwkwfYQ0xHTE7mSOJYHLmYfx/x7/i+ZlRnzYUenL2kqTz?= =?us-ascii?Q?dbFwaD+c5ft653UDMyDcJT2CA67UdSbBmfoqSXnO1Q2CIWuiFluFdhrn5XAU?= =?us-ascii?Q?DpmFytwQAm3NDdBPbcl7UGAJZ8qji2Ul1ra0eQRiC9XrxLYcM3yM+Tjcj9q0?= =?us-ascii?Q?zofkEsNafLdFI3nNUW11oym3kN79DSDVNW58OVAvy5NDK405ElU/huFizTuo?= =?us-ascii?Q?8EGU/rtdDdRz0EPUv7BS4QKAoOVmFMjqtzAXloR7ZVi9cdP5xH00SfTFyTNc?= =?us-ascii?Q?aZO2k0GV4eSRmCGcwJpojl3ToKzOE0pL/FzZLpQHKXiqTtLaWxWqBcRHCFbV?= =?us-ascii?Q?9nNDFKvPmMX8JNY3AbrwFeaBwLNOlo/IhzdwT3kbfor51+0upBJ/B8/VyzkA?= =?us-ascii?Q?AfXpAgt4kBx+ZmJOblHB2XygOKe/E6KXWmAdsxz1z0cK+CPt1ufua5GCH5uM?= =?us-ascii?Q?Rn0yhrlhXVpm6dG/g3uwzSsH0/nYgxSWjtbb7G7M197wQ7S420weqZX9bmEm?= =?us-ascii?Q?93xXdOlWmLalXWPqA87kRNqEvasNc1eaGzWvQ8ZVNlrQNdSen34cPLgHHKMs?= =?us-ascii?Q?abMdCcfGzCt6h1YTg3Xr8EZvBid46eSpBptUGqnIjb/NCr9qMvdBizwUzu0N?= =?us-ascii?Q?JoEShRJxdugOoxmsQVO7qEI6RYtmAm/pX3gqP3yOXHmqAKMknyJwDW4LKPWe?= =?us-ascii?Q?kgkFSwIOsQquPjCKxq103dXU/qRetU/U5+N99xaxAhsdCmSsObWJyzr0mh0m?= =?us-ascii?Q?eZlB43Ef0DhvkyoAHPUAZu4UsCeiVB/2w/4SGEJXwc+nxd5vvTAJxIywNo1E?= =?us-ascii?Q?WZioSP6+ZD29MNbzMF3UoT2J6KpPko+bGCj8pvqH2AZrWuvX3U8ujebfEZbv?= =?us-ascii?Q?LxtDt1z7xMNYPbeX+pa1yEqUmN9xOtJ2p/cdzBOzp4ia/ZZ09lEG89BfNH71?= =?us-ascii?Q?abqMn8X1BbewgSysDjKWShM5A5co4plWXp7mkWYRSYGALfFrPc1Eyuc4rykL?= =?us-ascii?Q?7vucCBEtyLF9bUIHFpZ2J4f8If++d1WJ01bd1A+L8hc3R6AcXD3eJdW1ZTj4?= =?us-ascii?Q?y7w0Nm+oOJcCtO+4FWQQYEDGKsaJUkKqOB05gBJoei14k4fqgo974W2hsZ89?= =?us-ascii?Q?tzu4OjW4o90TO1FHUd+VSeLO85ugxEvPAREqpIdVlbXJtRTm4KWVzj2N7B1V?= =?us-ascii?Q?F5hDNoJTMndgT8YccsCuQK+2yVD1tubqdKj7KKTz0RWG9EdTXRGDpePuVz8T?= =?us-ascii?Q?0Q2EIQsUUkfIjzMM1s+bnhkg630a7npt/T6zCmwZZQNEcJpGcle1HhkaM5Zj?= =?us-ascii?Q?FLKi6hCIpseQ/sFqV0VxM9XTYnCBFNWx?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB4881.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4ef52dd3-dbff-489f-eb92-08da0ce1aa09 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2022 15:27:38.5517 (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: KTvym5XeOxCtC82/avjJzuB9EKrIKDGEFXkPMovN2MncXhlxZ9a7+Kmu/wSDL1nLb/zHDp1PGNiwL0Wv0XnXjQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR11MB3781 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.227.253, xfe-rcd-005.cisco.com X-Outbound-Node: rcdn-core-12.cisco.com Archived-At: Subject: [Roll] FW: I-D Action: draft-ietf-roll-dao-projection-25.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, 23 Mar 2022 15:27:49 -0000 Dear all: Rev 25 contains the limited changes that I discussed this morning at the WG= meeting.=20 Basically, the clarification of the terminology, more in the diffs. Dear chairs: I believe this version is appropriate for starting a WGLC. Keep safe; Pascal -----Original Message----- From: Roll On Behalf Of internet-drafts@ietf.org Sent: mercredi 23 mars 2022 16:22 To: i-d-announce@ietf.org Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-dao-projection-25.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 : Root initiated routing state in RPL Authors : Pascal Thubert Rahul Arvind Jadhav Michael C. Richardson Filename : draft-ietf-roll-dao-projection-25.txt Pages : 84 Date : 2022-03-23 Abstract: THIS RFC extends RFC 6550, RFC 6553, and RFC 8138 to enable a RPL Root to install and maintain Projected Routes within its DODAG, along a selected set of nodes that may or may not include self, for a chosen duration. This potentially enables routes that are more optimized or resilient than those obtained with the classical distributed operation of RPL, either in terms of the size of a Routing Header or in terms of path length, which impacts both the latency and the packet delivery ratio. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-dao-projection/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-roll-dao-projection-25.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-dao-projection-25 Internet-Drafts are also available by rsync at rsync.ietf.org::internet-dra= fts _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From nobody Wed Mar 23 08:41:21 2022 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 F1F5B3A174B for ; Wed, 23 Mar 2022 08:41:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.606 X-Spam-Level: X-Spam-Status: No, score=-14.606 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, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=UOmHe511; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=WfMRSjME 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 tSQcUpt2ssQQ for ; Wed, 23 Mar 2022 08:41:15 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB6113A1749 for ; Wed, 23 Mar 2022 08:41:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2939; q=dns/txt; s=iport; t=1648050074; x=1649259674; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=yBQsf+f+/y3mjwMvEClHXTfQStqY/P4ftsRWedlulZU=; b=UOmHe5115eU30+QSQqTLXkCbgJse8Qi+hk5HodlJvqvQEBOt7wJxZz1G Dar+O0TD7wWq59QFzcY5+1c1EC5Dt1O7CIKLg7AKzbSVtGsa2hVkpuf1n 1AatHm6vvNL3Zpx2avLbiUk6Hc766vyAO6BUztB6FIFkZILTimg/sZIaD g=; X-IPAS-Result: =?us-ascii?q?A0D3AAADPztimIQNJK1aH2qBWoFSVn5aN0SIHgOFOYUQg?= =?us-ascii?q?wIDmzWBLhSBEQNUCwEBAQ0BASwLDAQBAYFPgzgChEUCJTQJDgECBAEBAQEDA?= =?us-ascii?q?gMBAQEBAQEDAQEFAQEBAgEHBBQBAQEBAQEBAQkUBwYMBQ4QJ4VoDYZCAQEBA?= =?us-ascii?q?QMBARAVEwYBASwMCwQCAQgRBAEBHxAnCx0IAgQTCBqCYgGCZQMuAQ6gfQGBO?= =?us-ascii?q?gKBDokReIEBMoEBgggBAQYEBIE7Ag5Bgn8YgjcDBoE8gxGLOSccgUlEgRVDg?= =?us-ascii?q?mc+gmMBAQEBAReBDBELIINPgi6XJy9MB2FRAhQ7DAIJMoEZRsAsCoNJiw+VA?= =?us-ascii?q?hWoQJZbjRWUIRyFBwIEAgQFAg4BAQaBYYIVcBUaIYJpURkPjjmDWYUUhUp1A?= =?us-ascii?q?jYCBgsBAQMJjgqCSAEB?= IronPort-PHdr: A9a23:xjQpaRDGlkkBN17s1ZGeUyQVaBdPi9zP1kY95pkmjudIdaKut9TnM VfE7PpgxFnOQc3A6v1ChuaX1sKoWWEJ7Zub9nxXdptKWkwJjMwMlFkmB8iIQUTwMP/taXk8G 8JPHF9o9n22Kw5bAsH7MlbTuXa1qzUVH0aXCA== IronPort-Data: A9a23:ReLV1aNQtaiALmbvrR2ll8FynXyQoLVcMsEvi/4bfWQNrUol1zUPn zAbCj3Qa6yLNjb3fYgjPo/koRxTsZfTmNQxGXM5pCpnJ55oRWUpJjg4wmPYZX76whjrFRo/h ykmQoCcaphyFBcwnz/1WlTbhSEUOZqgG/ytUIYoBggrHVU+EHx70ko68wIEqtcAbeaRUlvlV eza+6UzCHf9s9KjGjtJg04rgEoHUMXa4Fv0jHRnDRx4lAO2e00uMX4qDfrZw00U7WVjNrXSq +7rlNlV945ClvsnIovNfr3TKiXmTlNOVOSDoiI+ZkSsvvRNjnUbyoQHCKITUBZesT7WxdNIl OxX64PlHG/FPoWU8AgcexBcFyc7Nqpc9fqeeT60sNeYyAvNdH6EL/dGVR5te9ZGvL8sRzgVr 5T0KxhVBvyHr/qqwK+xR/Nwrs8iN8LseogYvxmMyBmJUK94GMuSH/iiCdlw7g8uoMN3P+rnY Mc2TRwzRznsYCxVJQJCYH45tL742iagG9FCk3qPoq4zy2ne0AI316LiWOc5YfSDQcFT202fv G+Dpjy/CRABP9vZwj2Amp6xugPRtXrSQKAuKOW3z69julbMnG8qVCQMC0Tu9JFVlXWCc95YL kUV/A8noq4z6FGnQ7HBs/uQ/SLsUvk0BoE4LgEq1O2e4vGPul/GWADoWhYEOYJ4655vLdA// gbRx7vU6SpTXKp5oJ533p6QqT60UcT+BTBfPXZfJefpDiWKnW3ephvLStAmG6mvg5isQXf7w iuBq241gLB7YS83O0eToA2vb9GE/8WhousJCuP/BTnNAuRRP9fNWmBQwQKHhcus1a7AJrV7g FAKmtKF8McFBoyXmSqGTY0lRe/1uKfaa22F2AUzQfHNEghBHVb+Iui8Bxkjei9U3josJVcFn WeK41oKvc8PVJdURfYrMtnZ5zsWIVjITIS5Ca+8gitmaZlqfwjP5zB1eUOVxAjQfLsEz8kC1 WOgWZ/0Vx4yUP0/pBLvHrt1+eJ7l0gWmDKILbimnkvP+eTFPha9F+xaWGZim8hktstoVi2Pr YYGXyZLoj0CONDDjt7/qtdCcwpVcSBlWfgbaaV/L4a+H+avI0l5Y9e5/F/rU9UNc3h9/gsQw kyAZw== IronPort-HdrOrdr: A9a23:et8Mp6Mc8FSxFMBcT2v155DYdb4zR+YMi2TDiHoedfUFSKOlfp 6V8MjzjSWE9Ar5K0tQ5uxoX5PwDk80lKQFrbX5WI3CYOCIghrQEGnth7GSuwEIdxeOlNK1kJ 0QDpSWa+eAQ2SS7/yKmzVQeuxIqLLsncDY5ts2jU0dNz2CAJsQizuRfzzrdHGeMzM2YqbReq Dsg/Zvln6FQzA6f867Dn4KU6zovNvQjq/rZhYAGloO9BSOpSnA0s+6LzGomjMlFx9fy7Yr9m bI1ybj4L+4jv29whjAk0fO8pVtnsf7wNcrPr3NtiFVEESutu+bXvUlZ1SwhkFwnAhp0idsrD D4mWZjAy200QKWQoj6m2q15+Cq6kdR15ar8y7ovZKkm72geNr/YPAx376wtXDimhEdVZhHod J29nPcuJxNARzamiPho9DOShFxj0Kx5WEviOgJkhVkIMAjgZJq3MUiFXluYd899ePBmfQaOf grCNuZ6OddcFucYXyctm5zwMa0VnB2GhudWEANtsGczjATxRlCvgYl7d1amm1F+IM2SpFC6e iBOqN0lKtWRstTaa5mHu8OTca+F2SISxPRN2CZJ0jhCcg8Sjjwgo+y5K9w6PCheZQOwpd3kJ PdUElAvWp3YE7qAd3m5uw8zvkMehTLYd3A8LAt23EigMyOeFPCC1z3dGwT X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.90,204,1643673600"; d="scan'208";a="851613945" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 23 Mar 2022 15:41:13 +0000 Received: from mail.cisco.com (xfe-rtp-005.cisco.com [64.101.210.235]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 22NFfDg9003869 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=OK) for ; Wed, 23 Mar 2022 15:41:13 GMT Received: from xfe-rcd-003.cisco.com (173.37.227.251) by xfe-rtp-005.cisco.com (64.101.210.235) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14; Wed, 23 Mar 2022 11:41:12 -0400 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xfe-rcd-003.cisco.com (173.37.227.251) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.986.14 via Frontend Transport; Wed, 23 Mar 2022 10:41:12 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=CEe1ei4GutguLTZ7uCez4RmyTFfXaKwEYPre3L5l4VUqfB0gsXrSnVFI88VLwi8UV+tud7vNYBWQ5EaOa3LOELGDO1aqxRrk6QjWyDOW9HGXdQfIR4lLy3tS2X0fh3pIk137gSVfpycx2SRKO3zjxyBMdFl+tff72rXwF0CrpWxqanKe4bm3TnYas/AoflvfwnEKpP4vB/cqvY879ABTF20toRYL67p0CrSXjF5tfnldBiQISr/WloowHxGsZvADBXXO+Q2Kt1hw1XK1LiyL1BN20iLGR92ySnlxEi8Vi63ivFmiyxpSMVBQcDR3O7E7iSpjz54tfRYIleLYserO+w== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=gxRsw1KCgy9C6ZoIrIJj/t+YlYXnGoWgoU7UzYq2UxQ=; b=dtRTisF6yTFK4u2UxcBnxdR9kL5AMStVwrMQwPzSwdSAlPnmgxlieUt3ETQwJtfGwiaFTyovvotmKj+ZkbrFsPoNAISZgOi6EVMjA+ZHjGDJuxnFy+ZAVV+m5EevsHyZOtp9d87XsPaEvvfxujP6+Ol2sAiItBu4Gm+qKxAXaHGd/aWAHped/9SZg4yAQULaM3oSXJNdxXMwiBsq1joZEnc0OVN6+gaS4LsXVOX+1umrG6Itf2VJzIWVnlIhvLIDvLIFXPTGPWlxFQY9HpckHohw5xK7wroazZ8FFTP6T2ayY9Cjl4zOjo/Gzp7Q6WZi5M/Wxn7qOC6Fz6rK8h7jDw== 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=gxRsw1KCgy9C6ZoIrIJj/t+YlYXnGoWgoU7UzYq2UxQ=; b=WfMRSjMEqaj1iwv6HZSImDgS8IesxJnY7ATo1URpbc+3AQZkZQWbJRZHECiUPHurbB+ylHh0gAZ5WUJB9Knj8j3EpRMX5031qP7jUhFwL1D7UvhTpujNJaUU3ddS6kqEW2EPxBIvEZUI5YHj5sDg62uNcpS/mjRCHjQ4om+akrc= Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by DM6PR11MB3355.namprd11.prod.outlook.com (2603:10b6:5:5d::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5081.21; Wed, 23 Mar 2022 15:41:09 +0000 Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::d4d0:b43e:40e8:d888]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::d4d0:b43e:40e8:d888%4]) with mapi id 15.20.5102.016; Wed, 23 Mar 2022 15:41:08 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] FW: I-D Action: draft-ietf-roll-dao-projection-25.txt Thread-Index: AQHYPsxdWX5bK7Ee+0yCftHwDPO/VA== Date: Wed, 23 Mar 2022 15:40:47 +0000 Deferred-Delivery: Wed, 23 Mar 2022 15:40:03 +0000 Message-ID: References: <164804890421.30480.14303817453027088953@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: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cisco.com; x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8b9e288c-f61a-48fc-a438-08da0ce38ce1 x-ms-traffictypediagnostic: DM6PR11MB3355:EE_ x-microsoft-antispam-prvs: x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Fa93udBXNiLiYSLb4cuKxAz9ilYfaskGLACD4O3gsYR8PjF6u50nn12tPjm32OQh3NzR6CDF7dZKhW0jT2yEtmN8iDQmMn5GbV7pSDa+BFVZs5SdjjthX5EYhY6+cENi+sM/r/Wszk4DNeDUGzQyk48Zmfys2bL7z+qolB5x0vr8qDNe/pnzDdVeklTc08R8rUiHcjEmB9SkmHKmqbvFk5yLc+Fd6Qgf1a4uphQpllpmmUT2Fe4u2K7CkbgwqYpYQ5UKqQuWSGoWHNN1ElmKkInSVo2rjXsTit3WH5ewSk6fR2W0o/xYfyPTsWr8W2D7qFiMYbsiwd+4XmTajQS2FL6yq9L1g9mki+Wa5KRXqLAqS6PMvmrnt9TB48jUkqfF/lwvGoEyK8atjwyK5xLRpCpfu0B+b9UQ/9en3tu2IrMB/B7ayfew501VESJE/dkMY5mfs/rO+TBj0NaysA77cxxCGjjhYjmljbu9RZYVIq25DGc5kUdjeiwMwRhBcQ/2xK4geQtqAMaWcvN5fIl3BUGZYs7BMtYGICqF0Qt4TDlRZR+ADILHhXrW7vjqDy+/NyBpoHdmvWFdebqbbnGzpy4i0TJypydKw1Fofbx+EXK0qWgaYfM9tLRn6Eumse3oSpK2A9YnIc0i7KGeTV4YMUmtE39eFfcDPpaoFQP7pu7d+adjaNYxLLRjKwxhJv5gf6jp0X/ip3AZnTOcYbwYIJfF1acO4uhuQZBcS3RJUKRVbx/YNsrMwyS++Ft0XHiHdcJs2IUEaqrhkb//fqjFoRjXwQDSBq14/HbDeHSm0+njBJ7TE05tSjOdkvJNXQSUyq7Ddk1UdHISTDny7E9ISQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CO1PR11MB4881.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(66476007)(508600001)(66556008)(2906002)(66574015)(76116006)(6916009)(6506007)(33656002)(966005)(71200400001)(66446008)(52536014)(7696005)(9686003)(86362001)(5660300002)(66946007)(2940100002)(26005)(64756008)(186003)(8676002)(38100700002)(83380400001)(122000001)(8936002)(6666004)(53546011)(316002)(55016003)(38070700005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?XjG6Kc67o7rcz5fFAlGTFxDsJrE5Tj82z1YPCOzUEjDKXpAnAq4EIDU8qjWj?= =?us-ascii?Q?175MXApZfKkG3S8hEi+rMyEEQpeRZcb3Y+UC/kYmU118YHBq98jUk/h9EFeP?= =?us-ascii?Q?MfWkzBpXqwTvXkohR2+DXCDr5ssLhDHtGKCpWzYgq+aIYVf88MJ5o/Z/34jb?= =?us-ascii?Q?5+G/yA13I/+zbBMbfh2AuzOS4b4cBqw1QPwiHlSvHPQXdQrIC5cKW80mPj22?= =?us-ascii?Q?4k+4bExtXFEjpycsVHETl3K7SkMMzAQULyI3uGDGDIcEeDL2JU7AMolUkY/b?= =?us-ascii?Q?4YcdjaN631VFmTemF/J7Hc3r1g4S4O/1aT8ebtoeTa+4EHEB1uxA7lrQboY0?= =?us-ascii?Q?IiH/JyurWlv1hh6a4wwiT6Ep/AqAdkh4/t3V+Y0y60h8cMb444I8yiXT/Ls9?= =?us-ascii?Q?wNYDmR4aX8o6ijSSCMF4rKYApPS8nGBnIHflJBVBZ90XkL3MocBVEddxB/+n?= =?us-ascii?Q?2cBnTRwvnFFC385lwNHV8tybLgflywThIEQJkB4XVsQKrG4viYMgIWDqOu4X?= =?us-ascii?Q?oduAh3yrmLPh3zvw8cUUu4OmJ4MFppe/XKEIZGb3pZyk0Wqfv3Mzo73aDK+J?= =?us-ascii?Q?YkI+tysf+i1fAiYuiWx5EaKolw9w4SjZqnpav84lL0iR0UF9QXL+MnAU8L1H?= =?us-ascii?Q?oWUg32CUtA2sH9VD4CI+DxHFblHc2plIbjjPUHp6B6msOU4rYjSYSZxKalIl?= =?us-ascii?Q?D338ZxrfeXiSB8oM3VAZF+T2OzVbclGRgYPR1uaDXbidjadbX2GwFJnS5MO7?= =?us-ascii?Q?rRbVw+4Mop7kfsjbqNtG8cEpSM/TfOWwOMvVQDAXu6z4/oE05uxpeXqb/wMk?= =?us-ascii?Q?KT5KrSe52XUFelEoEcImosiQsHwxk/1zeEcnsVisq1X16qD4UUURDBcI+ih9?= =?us-ascii?Q?syoQb53kTriY3ODaFu4xM7r3r7Jl0UXtXeEgP+ELqAC8o07YSDxUvuY2E1x7?= =?us-ascii?Q?1Qzc3I6sHWs2eooWZ5dGr/pGPaflXTuf4kyPYKTVK/BHahGSxYt/LhYKrx/w?= =?us-ascii?Q?dOfaI3DtU4scm96D4bo1k9NNmwBut2rcfXsQzgaItZpd0NRwzkNwyRg4SpDK?= =?us-ascii?Q?JTaXrN53qNnfezGqHT9vC2KStBIkb0RaI4frJ2Jgm40XoLJtjkm14WBF2A5X?= =?us-ascii?Q?FwrDxu9f3kcMg6Y9wtzsdxnM8aqwzX72QyrODM5G1CLC5VCCLswKTSapZuIV?= =?us-ascii?Q?lyQlAYG5gx3vMJFI59Gk+cpd0QITKHKTxSe2Iv6tLiIx0khBKXSWNOd3EPaY?= =?us-ascii?Q?tkrAScxnnzpVSCmI6fr5Q0H0IktVRr3Q3hAN7+MHbVfz7ZULq509Tr9XIYm4?= =?us-ascii?Q?dFiJ9v0HgjcJpsgwOFDPBKtZIdMdMOdNbPVdDnxULDCox8fOnhbpkrmEhEIW?= =?us-ascii?Q?aBIGLOrAc/at3WeWA1OANRzNgrE0JlAdQWZUwi7gExwA2xf7zDrrwYrrsJpw?= =?us-ascii?Q?Du1euTRZS0Muzmk/U+d/1NETPyRZFvyr?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB4881.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8b9e288c-f61a-48fc-a438-08da0ce38ce1 X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Mar 2022 15:41:08.5804 (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: WjCxmgnt5Ud3OVrnCRBmK7HTPeAZFpLdrlFe0iNfHQCpT/Fio8xAACX1lZEURxh+htLTDWOgslgi6zOFhCpb7w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB3355 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 64.101.210.235, xfe-rtp-005.cisco.com X-Outbound-Node: alln-core-10.cisco.com Archived-At: Subject: Re: [Roll] FW: I-D Action: draft-ietf-roll-dao-projection-25.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, 23 Mar 2022 15:41:19 -0000 BTW looking at the diffs after publication I found a oups:=20 a change this doc-> THIS RFC intended for the IANA section has gone wild. I fixed that in the git repo... no need to mention it again : ) Keep safe Pascal > -----Original Message----- > From: Roll On Behalf Of Pascal Thubert (pthubert) > Sent: mercredi 23 mars 2022 16:27 > To: ROLL WG (roll@ietf.org) > Subject: [Roll] FW: I-D Action: draft-ietf-roll-dao-projection-25.txt >=20 > Dear all: >=20 > Rev 25 contains the limited changes that I discussed this morning at the = WG > meeting. > Basically, the clarification of the terminology, more in the diffs. >=20 > Dear chairs: I believe this version is appropriate for starting a WGLC. >=20 > Keep safe; >=20 > Pascal >=20 > -----Original Message----- > From: Roll On Behalf Of internet-drafts@ietf.org > Sent: mercredi 23 mars 2022 16:22 > To: i-d-announce@ietf.org > Cc: roll@ietf.org > Subject: [Roll] I-D Action: draft-ietf-roll-dao-projection-25.txt >=20 >=20 > 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 network= s WG > of the IETF. >=20 > Title : Root initiated routing state in RPL > Authors : Pascal Thubert > Rahul Arvind Jadhav > Michael C. Richardson > Filename : draft-ietf-roll-dao-projection-25.txt > Pages : 84 > Date : 2022-03-23 >=20 > Abstract: > THIS RFC extends RFC 6550, RFC 6553, and RFC 8138 to enable a RPL > Root to install and maintain Projected Routes within its DODAG, along > a selected set of nodes that may or may not include self, for a > chosen duration. This potentially enables routes that are more > optimized or resilient than those obtained with the classical > distributed operation of RPL, either in terms of the size of a > Routing Header or in terms of path length, which impacts both the > latency and the packet delivery ratio. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-roll-dao-projection/ >=20 > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-roll-dao-projection-25.html >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-dao-projection-25 >=20 >=20 > Internet-Drafts are also available by rsync at rsync.ietf.org::internet- > drafts >=20 >=20 > _______________________________________________ > 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