From nobody Mon Nov 2 06:25:11 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 592383A105A for ; Mon, 2 Nov 2020 06:25:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, 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 yoD4dOwoux9Q for ; Mon, 2 Nov 2020 06:25:09 -0800 (PST) Received: from mail-ua1-x92d.google.com (mail-ua1-x92d.google.com [IPv6:2607:f8b0:4864:20::92d]) (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 538A43A1072 for ; Mon, 2 Nov 2020 06:24:39 -0800 (PST) Received: by mail-ua1-x92d.google.com with SMTP id k12so3972003uad.11 for ; Mon, 02 Nov 2020 06:24:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=9pxYlwQn2ma90G2Ll1mydQyfGtKUMDy8RkmDxnDDl5Q=; b=JqRKNcpENEnIIlHgyDQkfWmSzkduwdYVIr0uIZYcGPijuZzSTumCZ3yVAA2q1MlwdK TSaY25Fwe+P3+CtxQ1gNKfZcJNnvu9kjRkdjp5oi1Hh4Pg8SueDcOroXdKTXOMj9Z4qt ZZWx5m7Kq3C2iTzAxEjV0A9Xh3eG8ZuQXk9/6AE5CCWh9G3LeVBIW4GPgxBp5rbiqkMa ni4MJaNmDrQ22CWk4qiage+BPtxPWzUn7fNzw4z+GdB9oZJGREp38xDBebMaZVgObnbG 5p7790Zm4oQdrbVJkkrurydTVBqkvIFitYBjmIEHNl2TdWzOSyOInmIiVcxcDqIC8q5x m07Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=9pxYlwQn2ma90G2Ll1mydQyfGtKUMDy8RkmDxnDDl5Q=; b=oUmvPnHdtZckxaUILxxuIHx0UggMTNVWouXKItnMVwL/EGjsYZ9MEkOQ6r5q1pci9r VGWZeEiuYEnnxi5gU0hw2WBty3fdPa/oIG3nw67A6BmJaL00Qc/bLWXOwoVcvmed4hTc n8W6s7478Opp/2mPVxvy+aHk3hNaFZykwS3OdxNspER8xQNGGxbmfWx3RFAPOfN+8rkJ CgUT9zrnFLM1Q2+KhbZ9Z9TBCWVUJBElxy38meLpaSlihNBR3GWcEg8/MgHsgkh2dZ5k 6OBRLdltA1PkYq45x4DX40okuMl+CW74r6eYbOR4fRYp3TP3wze5HR6CvxtwbWPD61aC jvHw== X-Gm-Message-State: AOAM531G7VSn+Z6wXSrs69Y0pdMeSQygieFB9eywCZwDaUJgjP5+chwK VqBoPgdLlIOHjXadWRWxxjFIRk3ZnJZGly/6WzbyYS1xS5c= X-Google-Smtp-Source: ABdhPJwXAS+CWWY+ZUvDzRlMfT986Sga55pRij3D5DdNt6QIp1A/fj9EuRFFUdzTh1rtAnsTbHueJJdfFK+qNmBXooY= X-Received: by 2002:ab0:2903:: with SMTP id v3mr5137533uap.51.1604327077843; Mon, 02 Nov 2020 06:24:37 -0800 (PST) MIME-Version: 1.0 From: Ines Robles Date: Mon, 2 Nov 2020 16:24:02 +0200 Message-ID: To: roll Content-Type: multipart/alternative; boundary="00000000000094175805b3208191" Archived-At: Subject: [Roll] IETF 109 - Agenda Requests 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, 02 Nov 2020 14:25:10 -0000 --00000000000094175805b3208191 Content-Type: text/plain; charset="UTF-8" Dear all, Please let us know if you desire to present a topic and how much time you need at IETF 109 - 2hs session -, so far we have: Topics: - Introduction: WG Status (10 min) - P-DAO Projection (20 min) - Unaware-leaves status (10 min) - Turnon-draft status (10 min) - RPLv2 status (10 min) Thank you, Ines and Dominique --00000000000094175805b3208191 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

Please let us know if you= desire to present a topic and how much time you need at IETF 109 - 2hs ses= sion -, so far we have:

Topics:
- Introd= uction: WG Status (10 min)
- P-DAO Projection (20 min)
= - Unaware-leaves status (10 min)
- Turnon-draft status (10 min)
- RPLv2 status (10 min)

Thank you,
<= div>
Ines and Dominique


--00000000000094175805b3208191-- From nobody Mon Nov 2 06:46:01 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E89C3A10AA for ; Mon, 2 Nov 2020 06:45:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, 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 N0CgDp3tX_ZW for ; Mon, 2 Nov 2020 06:45:57 -0800 (PST) Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (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 24D4B3A1065 for ; Mon, 2 Nov 2020 06:45:57 -0800 (PST) Received: by mail-ej1-x630.google.com with SMTP id 7so19273985ejm.0 for ; Mon, 02 Nov 2020 06:45:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=V2AShhCLa4ognF3A9nmI+l8IYbGdX7mgGleeajLkDzo=; b=qgSxYYHBTu6Q4aWE9HXXsKzmED01kTjkYpN1soDq97v8DxPlB4CKXpEnxUECcl7lo3 yfDrmk/5QQsh+ZYawTcxjbmpNlIo26NFqy71jzx8KeZ/ePnsl9HOY2X4Y1mJxDa9uGyk k1+33uVF2ZUsND7EHLvG4OX8nJ+/9foqkwfzkv6II5OZ4XI4PhVgv39Jc0ViqVQ6Ul5K TThjcfG51KKQDTV7dbA0zqk3qhPnaWSjH9nDKAF3Lla7o7l7HNZyiw1eyFVzNzaBmMln WSXk75WnEQqnblaykobTPVGL1cleBjKDoJbZav93s8+f6z333bMAAS2rqtejTKl5+OPr mnZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=V2AShhCLa4ognF3A9nmI+l8IYbGdX7mgGleeajLkDzo=; b=MT9paOtLUHSPpAHF8wmgXIpMR0ll6b318heuGeHu7pIJiVmn2f08z2pLhqt0XMBDQ/ z7iA2nL1cnJQ4Jsyyl/413gdozaahl3SvDvtc75O0d4DrhEBmvLnAAtzR49ayR0WSxqk IrZedWTYMCwASdkGcAL3xGWxKW2Hv6Hd1oCRGIm4bJ909ZQn3XJGjBMP23VQvDr7z/dw AZfPpOairyhRtx12UIQeSKZp5MkeGQXbBqoMo1KNteUutqaCiUAvmKPV5CpWvDDieOdM EvtCfyGpEwBumvbUsT4pj8HZ3zw0wxRqyk0BSgBXxFeFHsxUeqMDnFvLfEZNUyddf26m rmPg== X-Gm-Message-State: AOAM5320DYtgZttbkq5fqoyhCms+Ka63n4o09FbQjlalU/Zq1pwI5jgY w6ql+2xGIymxXr5z5yc9LJMffm9a0dSe4d895Fp32yVZAc8= X-Google-Smtp-Source: ABdhPJxefmjkMn8eRnz9uSm/vYA/w3pJ8mVj9G/Rm1x8EvPo7pcM+I/+SNoC5brNxjzuNIFq7O7+8FIwiJsLxoWGHmI= X-Received: by 2002:a17:906:3782:: with SMTP id n2mr11550773ejc.493.1604328355147; Mon, 02 Nov 2020 06:45:55 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Rahul Jadhav Date: Mon, 2 Nov 2020 20:15:44 +0530 Message-ID: To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="000000000000b63a5605b320cd3e" Archived-At: Subject: Re: [Roll] IETF 109 - Agenda Requests 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, 02 Nov 2020 14:45:59 -0000 --000000000000b63a5605b320cd3e Content-Type: text/plain; charset="UTF-8" Hello All, I would like an opportunity to present draft-jadhav-roll-storing-rootack-01 Time: 15 mins Presenter: Rahul Jadhav Thanks, Rahul On Mon, 2 Nov 2020 at 19:55, Ines Robles wrote: > Dear all, > > Please let us know if you desire to present a topic and how much time you > need at IETF 109 - 2hs session -, so far we have: > > Topics: > - Introduction: WG Status (10 min) > - P-DAO Projection (20 min) > - Unaware-leaves status (10 min) > - Turnon-draft status (10 min) > - RPLv2 status (10 min) > > Thank you, > > Ines and Dominique > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --000000000000b63a5605b320cd3e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello All,

I would like an opportunity to present <= a href=3D"https://tools.ietf.org/html/draft-jadhav-roll-storing-rootack-01"= >draft-jadhav-roll-storing-rootack-01
Time: 15 mins
Prese= nter: Rahul Jadhav

Thanks,
Rahul


On Mon, 2 Nov 2020 at 19:55, Ines Robles <mariainesrobles=3D40googlemail.com@dmarc.ietf.org> wrote:
Dear all,

Please let us know if you de= sire to present a topic and how much time you need at IETF 109 - 2hs sessio= n -, so far we have:

Topics:
- Introduct= ion: WG Status (10 min)
- P-DAO Projection (20 min)
- U= naware-leaves status (10 min)
- Turnon-draft status (10 min)
- RPLv2 status (10 min)

Thank you,

Ines and Dominique


_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--000000000000b63a5605b320cd3e-- From nobody Mon Nov 2 07:06:22 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D62E63A116A for ; Mon, 2 Nov 2020 07:06:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, 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 BV-qfwivJArd for ; Mon, 2 Nov 2020 07:06:17 -0800 (PST) Received: from mail-ua1-x930.google.com (mail-ua1-x930.google.com [IPv6:2607:f8b0:4864:20::930]) (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 DCF8A3A1095 for ; Mon, 2 Nov 2020 07:06:16 -0800 (PST) Received: by mail-ua1-x930.google.com with SMTP id 52so4018651uaj.4 for ; Mon, 02 Nov 2020 07:06:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=LJdbVLNtPhzM83RflUvphKc57h6m0oOpmXgYw6EK9l0=; b=sEo9f756DBzN+fXVKwgAfUC9ZQPU14bYNcwxZwhfrrVc7UXcvHRTFlgcjMpElAiQLy uAnMZ/y1LwLMj17SVWkibDYnuRP98V768DepQZyxPgrGk/tNoyClZKZkfQuWxvzPenVg Yeb5eWwd9At69wgEG30oVQcq7nD3ghN5R+Tq7/LdvlWdmjzuCZExQ4aLTpDfFte7yNGU BYl8mjl1hmSlTiEE5F1rpQ++qauAlamW12QrfW0CNGgi9GoaLrhSP0fB81irpV9y51Nx KyQGpfDOee8BzjJEv5gLw48PkjqOCcgN5LsyQR1KMsu2rBNzUOwRGlLgpofTvELEvZx1 cn6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=LJdbVLNtPhzM83RflUvphKc57h6m0oOpmXgYw6EK9l0=; b=M8PvLju7yccvZtNlUBb904xJ6XEtSIy04FFOXsUbTAufkiEsAD8sGCnQaMOFhlB6FW g4neHDWSWHZ8/6rfSQdro7vJdK2G12SKFQxsWQO0dkFk8XQRpgXDDzG4HOtRMBWk7uWa HEJPUyYzjn3I9ST8kPkl8JnAsNHfwkDedsXGD2cbl2i2lpMS7TjGspquv7JsKZG+8zz2 xwgGas0JsKK5bOZyAUWzJ6m9vmFqRg8THpoHLhwzQmePoOSVQ/uMjtussqwUYqzNFnpm oZobd/Q9WLTKudBaIaDK4VPuhnjJq+hZxbsXK4bPU+vG3oEOI+wF4SgEaw0Bzm3sBcY1 S7Xg== X-Gm-Message-State: AOAM532M9DF2Y0UJDdAoihK0v89evsLTKcqcB6JlOvrOF6WW2r9LZ7M+ a83cSax60IWmswv2eTflesJueyTRLg+Qf4z/+n1cPv/VIR175Q== X-Google-Smtp-Source: ABdhPJxO6o/FTZnp+F//ZidG6CDuA21VSD9LhGZwJ4t42VDgchGRsBlRqEOoP3XBCIl8KdY/rq29JLTfJArU5XnC6ig= X-Received: by 2002:a9f:35cb:: with SMTP id u11mr8366196uad.46.1604329574735; Mon, 02 Nov 2020 07:06:14 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ines Robles Date: Mon, 2 Nov 2020 17:05:38 +0200 Message-ID: To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="00000000000067b0e505b32116a8" Archived-At: Subject: Re: [Roll] IETF 109 - Agenda Requests 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, 02 Nov 2020 15:06:20 -0000 --00000000000067b0e505b32116a8 Content-Type: text/plain; charset="UTF-8" Thank you very much! Roll is going to meet on Thursday 19th November, from 9:00 to 11:00 UTC Time. Please find the place where you can upload your presentation: https://datatracker.ietf.org/meeting/109/session/roll Agenda in UTC: https://www.ietf.org/proceedings/109/agenda/agenda-109-roll-02 Codimd: https://codimd.ietf.org/notes-ietf-109-roll Thank you, Ines. On Mon, Nov 2, 2020 at 4:46 PM Rahul Jadhav wrote: > Hello All, > > I would like an opportunity to present > draft-jadhav-roll-storing-rootack-01 > > Time: 15 mins > Presenter: Rahul Jadhav > > Thanks, > Rahul > > > On Mon, 2 Nov 2020 at 19:55, Ines Robles 40googlemail.com@dmarc.ietf.org> wrote: > >> Dear all, >> >> Please let us know if you desire to present a topic and how much time you >> need at IETF 109 - 2hs session -, so far we have: >> >> Topics: >> - Introduction: WG Status (10 min) >> - P-DAO Projection (20 min) >> - Unaware-leaves status (10 min) >> - Turnon-draft status (10 min) >> - RPLv2 status (10 min) >> >> Thank you, >> >> Ines and Dominique >> >> >> _______________________________________________ >> 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 > --00000000000067b0e505b32116a8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you very much!

Roll is going to m= eet on Thursday 19th November, from 9:00 to 11:00 UTC Time.

Please find the place where you can upload your presentation:=C2=A0= https://d= atatracker.ietf.org/meeting/109/session/roll

=


Thank you,

Ines.=

On Mon, Nov 2, 2020 at 4:46 PM Rahul Jadhav <rahul.ietf@gmail.com> wrote:
Hello All,

I= would like an opportunity to present draft-jadhav-roll= -storing-rootack-01
Time: 15 mins
Presenter: Rahul Jadhav=

Thanks,
Rahul


_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--00000000000067b0e505b32116a8-- From nobody Mon Nov 2 11:16:49 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03EC23A0B3E for ; Mon, 2 Nov 2020 11:16:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJWUjakUfyDC for ; Mon, 2 Nov 2020 11:16:46 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 72C7E3A0B21 for ; Mon, 2 Nov 2020 11:16:45 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 854883899B for ; Mon, 2 Nov 2020 14:23:46 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id sjbNqJ78UN_k for ; Mon, 2 Nov 2020 14:23:46 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 2243838998 for ; Mon, 2 Nov 2020 14:23:46 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 478D11F9 for ; Mon, 2 Nov 2020 14:16:44 -0500 (EST) From: Michael Richardson To: Routing Over Low power and Lossy networks In-Reply-To: References: X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Roll] IETF 109 - Agenda Requests 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, 02 Nov 2020 19:16:48 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ines Robles wrote: > - RPLv2 status (10 min) Who is doing this? [was it me?] I don't think that 10 minutes is enough. Rather than talk about RPLv2, let's talk about planning for RFC6550bis. I think that needs a bunch of planning. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl+gWxsACgkQgItw+93Q 3WXhBgf+MMUKYZl875PPn+HuHOL4sY/Jfw4Dh3XVoAKboUs3R9qGba14XMdy1yNh DdvO1Jd/y9vrxNwaYk91eNjCPxfbU1y+tSbdTmaqMv1szqxsCKGFXKRvSinHINNC DBnW19Kl3BWmt+IO4to7GNq9uCPfdLrxlOYJasv24jGZBb7ptSuLEyAUuHSl4BIP F9zyyEI6WV9Sb72zdGyT2GuThxSD1LT6J3N9hEpQtANCokrOvb3L2d9fOoqKO2e0 IIg34fwweiHYmDctu3/T7RXD76rQmttLC5Ct1vXBnpfyd211t+tvrxbcklW4Lrgx RvlpDGjW01Z5HvOVio+6RYdpx/Wzdg== =dXNo -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Nov 2 11:40:31 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3561C3A0D7D for ; Mon, 2 Nov 2020 11:40:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, 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 PKUsS_sq4yeA for ; Mon, 2 Nov 2020 11:40:27 -0800 (PST) Received: from mail-ua1-x92a.google.com (mail-ua1-x92a.google.com [IPv6:2607:f8b0:4864:20::92a]) (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 1781E3A0D78 for ; Mon, 2 Nov 2020 11:40:27 -0800 (PST) Received: by mail-ua1-x92a.google.com with SMTP id t15so4281869ual.6 for ; Mon, 02 Nov 2020 11:40:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=AT0FmWaKmyCdVGeHk1F3AQazuw/ni2BLRq6YKaMWrJQ=; b=QNoiuCDfurY7vHDKQxSQHjfEQ5TqKqzdnRLOseovNZbg5uvGXk9QIKHLzzABhlUWHp 9KljQZDyVF5zmpBBPG99961r5s0XqUbDFMJNQYXAf1eEcA7ZgiXAxFOvvA9ldUVpZs5j VHAFLxqRfyCLu5VhwfLsyPmS+lU80J6WnYNwo/wijnR73Y9pmjPsLRpE9uKfxEo8HQ6/ lUjSPnXYD7mtIHDtUx4OggJqJJm8qxflfbuZ8ZDeQNXWrdwh3A8tDHW0CGk3v0Z6JLkz FIz4BqoHXaKnZDFlcfrzQfmf1xjxAyiE4EIcze3MpNI8LOBAh4G3H5XCxljmWk45BhQl 6UCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=AT0FmWaKmyCdVGeHk1F3AQazuw/ni2BLRq6YKaMWrJQ=; b=bQA/5KO10/wW6T+IOXG846XLfKCUgP7EKOpZCLBAUmq8isXIcs5sNz0WOVnK/YL66i 8cr/D3+0YglHxO4q+7fDjZMv83+u7Z1pT/8OJD31C0U2OiYuUvIGRWu9OBUIM/2W29kY vMToHwcA4Mq20f5gOOS8RlayJ8sKzMXtvzGqdDqudNCtOw/jElsn4fWUuqwfSbDHFFPC YtT1bICu88Zr6TPo1p0BH+ndaxXtDfJinv94BmnVPEh4qLxIGGla/863IFPJlZqOGYhv fUYR2b4rSu9+Fw8dbEKoM5/4WewG8Sko3aeoj1ZJxpF2q0QX+gJ2pnLPIuuk5CX0NCZq tqXQ== X-Gm-Message-State: AOAM532TCFtvLTyIUTKtvdWmM/cyVvvgIMtv/C2pJWZY+/eLwH199Du6 RHYZXVmEnWva8ZuxCGhMkT90FPONSZwE+1JCLrgRTRniW+Npdg== X-Google-Smtp-Source: ABdhPJwU5/y+Y+XSN86InVXW2CAb8I/NNKQ4X0ipy9OcEu4QQYOSlQ9y661owLat/kJQA0sUz4H6MvchKyJd7poIRZY= X-Received: by 2002:ab0:7042:: with SMTP id v2mr8549431ual.107.1604346025784; Mon, 02 Nov 2020 11:40:25 -0800 (PST) MIME-Version: 1.0 References: <23007.1604344604@localhost> In-Reply-To: <23007.1604344604@localhost> From: Ines Robles Date: Mon, 2 Nov 2020 21:39:49 +0200 Message-ID: To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="000000000000f6bb9805b324eade" Archived-At: Subject: Re: [Roll] IETF 109 - Agenda Requests 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, 02 Nov 2020 19:40:29 -0000 --000000000000f6bb9805b324eade Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi, Great!, we have 30 min slot-free, thus RFC6550bis would have 40 min if there are no further meeting requests. Thank you, Ines. On Mon, Nov 2, 2020 at 9:16 PM Michael Richardson wrote: > > Ines Robles wrote: > > - RPLv2 status (10 min) > > Who is doing this? [was it me?] > I don't think that 10 minutes is enough. > > Rather than talk about RPLv2, let's talk about planning for RFC6550bis. > I think that needs a bunch of planning. > > -- > Michael Richardson . o O ( IPv6 I=C3=B8T consul= ting ) > Sandelman Software Works Inc, Ottawa and Worldwide > > > > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --000000000000f6bb9805b324eade Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

Great!, we have 30 min slot-f= ree, thus=C2=A0 RFC6550bis=C2=A0 would have 40 min if there are no further meeting requests= .=C2=A0

Thank you,=C2=A0

= Ines.

On Mon, Nov 2, 2020 at 9:16 PM Michael Richardson <mcr+ietf@sandelman.ca> wrote:

Ines Robles <mariainesrobles=3D40googlemail.com@dmarc.ietf.org> wrote:<= br> =C2=A0 =C2=A0 > - RPLv2 status (10 min)

Who is doing this? [was it me?]
I don't think that 10 minutes is enough.

Rather than talk about RPLv2, let's talk about planning for RFC6550bis.=
I think that needs a bunch of planning.

--
Michael Richardson <mcr+IETF@sandelman.ca>=C2=A0 =C2=A0. o O ( IPv6 I=C3=B8T co= nsulting )
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sandelman Software Works Inc, Otta= wa and Worldwide




_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--000000000000f6bb9805b324eade-- From nobody Fri Nov 6 14:10:24 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA1813A0DBF; Fri, 6 Nov 2020 14:10:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 gBVpo_k9mOJ0; Fri, 6 Nov 2020 14:10:22 -0800 (PST) Received: from mail-ed1-x534.google.com (mail-ed1-x534.google.com [IPv6:2a00:1450:4864:20::534]) (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 C22F33A0DAD; Fri, 6 Nov 2020 14:10:21 -0800 (PST) Received: by mail-ed1-x534.google.com with SMTP id o20so2801138eds.3; Fri, 06 Nov 2020 14:10:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=4AjVJVb7tQphaupwH+5pvOtrrZeuzVJaMP1wcm6RE90=; b=PKUxmN1DDlk8Ho8mFIFc0Y+9gwp0Xh3Xlzgi3JvAV6Ho11xGMLkBRjzTvgqo6ynIKk noIPQbiyQ680y1kwTzV2vCznCKMhwp8fGuaCV7b7uDjectzbORHN1wX6N6qkshE9QGrT Mu6D+dKz/DAlsFQqtfuDOZ8Np9Sk8g8b40TrZPGRAK6Y8tAtg8nJaLL2bp7U0yQq7OX+ ZyJF2mhzShYWTRoXicge7aPpnpjsCSrMBFggnAxSpVFHATj2YxhBpkQA0/kHCF1+kYTK 3mpJ8jM8np2MENma0TDxSQKJtSFSgl5xlWycAHofasdQOmsA1+/Katne5qVlJRhFjsGR gzbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=4AjVJVb7tQphaupwH+5pvOtrrZeuzVJaMP1wcm6RE90=; b=iz3KV4QLAhklhoYtsrVodzTZ67JRew5/nofWanqp87xtOta49gm103bxwJRMpso2zP 14UlEcsCQP/iZKRSz1pBfc7mREYtTku5A1vZ7HVS4M7PaLVzBLsWcsw2EbJ5bC3eOyKE jv3yEhl10cbbbgWwYl72Ru5dP3JjqTuWGUi5ssYbbka3S3ccjv/Rw7oPkL0HvmstDMJE m1FWNlnINKBFxGpSTmSFyZPSquL2xnjAXyljArOY09n3b+S8YzJdxbgfdhNqXY5i5KhO WZ03+Q+2u4C30fT7k6fhSYlnKZT5/yEspD7zgM+ZV/+DqE67Mwuns3wPAOA8+X+qOeY1 eqQw== X-Gm-Message-State: AOAM530gtg8RFr2/PTcbOgIeXsmorVxYNSVZHeOg7TswkB6M/EF9djxX AlgiQfDuJ24AymQkEXDcGujt0x39Qpr2ss9sA7o= X-Google-Smtp-Source: ABdhPJzjBrs4kdxveTcO4rAyKt9+kMbZdYHx3JRF8TnPb3izg8QYi06C1iR+DZav5hFX7O5lEf3jCE4RoeiEkF9L0CE= X-Received: by 2002:a05:6402:b8e:: with SMTP id cf14mr4172302edb.86.1604700619940; Fri, 06 Nov 2020 14:10:19 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Fri, 6 Nov 2020 17:10:18 -0500 From: Alvaro Retana In-Reply-To: References: MIME-Version: 1.0 Date: Fri, 6 Nov 2020 17:10:18 -0500 Message-ID: To: "Pascal Thubert (pthubert)" , "draft-ietf-roll-unaware-leaves@ietf.org" Cc: "roll-chairs@ietf.org" , Routing Over Low power and Lossy networks , Rahul Jadhav Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Roll] AddRE: AD Review of draft-ietf-roll-unaware-leaves-18 (cont) 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, 06 Nov 2020 22:10:24 -0000 On October 28, 2020 at 5:29:25 PM, Pascal Thubert wrote: Hi Pascal! There are just a couple of remaining comments...nothing major. =C2=A0I will start the IETF LC when you upload an update. :-) Thanks!! Alvaro. ... > > > But we're also merging the statis with the DCO-ACK Status In that we > > > deprecate > > > https://www.iana.org/assignments/rpl/rpl.xhtml#rpl-dco-ack-status > > > > That is new!! I don't even see DCO-ACK mentioned in the document at all= . > > > > Does this mean that =C2=A712.5 should also be changed to include the DC= O-ACK > > message in it? > > Not sure I understand. =C2=A712.5 Has the only DCO status, status 1. =C2=A712.5 says this: =C2=A0 =C2=A0This specification creates a new Subregistry for the RPL Non- =C2=A0 =C2=A0Rejection Status values for use in the RPL DAO-ACK and DCO mes= sages =C2=A0 =C2=A0with the 'A' flag reset, under the RPL registry. s/DAO-ACK and DCO/DAO-ACK, DCO, and DCO-ACK ... > > [major] What should the receiver do if a different value is used? > > > Added > " > ROVRsz (ROVR Size): Indicates the Size of the ROVR. It SHOULD be 1, > 2, 3, or 4, indicating a ROVR size of 64, 128, 192, or 256 bits, > respectively. If a legacy Target Option is used, then the value > must remain 0, as specified in [RFC6550]; In case of a value above > 4, the size of the ROVR is undetermined and this node cannot > validate the ROVR; an implementation SHOULD propagate the whole > Target Option upwards as received to enable the verification by an > ancestor that would support the upgraded ROVR. > " [nit] s/[RFC6550]; In/[RFC6550]. In [major] "value above 4, the size of the ROVR is undetermined and this node cannot validate the ROVR; an implementation SHOULD propagate the whole Target Option upwards as received to enable the verification by an ancestor that would support the upgraded ROVR." Several points: 1- Maybe I missed it, but I didn't see anywhere that a RPL node would validate the ROVR. =C2=A0Is that implicit somehow? =C2=A0Note that I'm refe= rring to RPL functionality since we're talking about the Target Option (not from rfc8505's point of view). 2- It seems to me that both the 6LR and then the Root simply copy the ROVR from/to the EDAR. =C2=A0IOW, there doesn't seem to be another RPL ancestor who would do anything with it. 3- Assuming that the 6LR somehow originated a bad Target Option (with a ROVRsz > 4), then it looks like the Root wouldn't be able to send an EDAR. =C2=A0What should it do? =C2=A0I'm guessing it should send a failure signal back to the 6LR. 4- We're making assumptions about an "upgraded ROVR". To solve all this maybe just delete starting with "In case of a value above 4..." =C2=A0 If RPL is just carrying the information then that seems more an rfc8505 issue... ... > Nothing prevents a packet coming in a RPL domain to carry an RPI. E.g., > that packet escaped another RPL domain, which is now valid. The border > router (typically the root) must rewrite it. the question is whether we > assume that the RUL placed a meaningful one. I'd say that cannot be > assumed in all cases, e.g., if instead of a leaf we have another RPKL > network. > But when it is useful, the 6LR should have a policy to know so it knows > how to use it. ... > I added > " > If the packet from the RUL has an RPI, the 6LR as a RPL border router > MUST rewrite the RPI to indicate the selected Instance and set the flags, > but it does not need to encapsulate the packet. > " > > Also added > > " > It is up to the 6LR (e.g., by policy) to use the > RPLInstanceID information provided by the RUL or rewrite it to the select= ed > RPLInstanceID for forwarding inside the RPL domain. > " Good...except that I think there's a Normative conflict: "the 6LR...MUST rewrite the RPI" vs "up to the 6LR...to use...or rewrite". s/MUST/SHOULD Should any of this be also in UseofRPLInfo? =C2=A0Or maybe it should be explained there and referenced form here. =C2=A0UseofRPLInfo talks about always inserting the RPI at the 6LR, no exceptions. ... > I'm wondering if there again the end of your message was lost? Nope, that was it. :-) From nobody Mon Nov 9 00:58:49 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE8393A0D29; Mon, 9 Nov 2020 00:58:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 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_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=fZ+juFPd; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=iPgaqnFF 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 hOVqdEB2ohDN; Mon, 9 Nov 2020 00:58:45 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DE8433A0D20; Mon, 9 Nov 2020 00:58:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9348; q=dns/txt; s=iport; t=1604912325; x=1606121925; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=QQpzLPpEe57eQYViX6jzKnAnVy65G4ngqvlZLMG9O6s=; b=fZ+juFPdThYCejvuI1lxXlMVN9bm6/bNa9ViLuquQkOhCOtqy6685N7K gmdobTbppRTfRuJzUbVSxq2F4oK1nb13tl3wK0XDvWLmvHgXmKvp3WIIt lVgfTIMSBnAXX2kwAemXRH/SYwBL4v8KQfKdWS2RC/W7RRN6/kxKRb/SF E=; X-IPAS-Result: =?us-ascii?q?A0DpCAC4A6lffYsNJK1aCB4BPAwCCxWDIVF7WS8uhD2DS?= =?us-ascii?q?QONVYEFl3yBQoERA1QLAQEBDQEBJQgCBAEBhEoCF4F7AiU4EwIDAQEBAwIDA?= =?us-ascii?q?QEBAQUBAQECAQYEFAEBhjwMhXIBAQEBAgESEREMAQE3AQQLAgEIDgwCJgICA?= =?us-ascii?q?jAVEAEBBAENDRqDBYJVAw4gAQ6iIQKBO4hodoEygwQBAQWBMwGDWxiCEAMGg?= =?us-ascii?q?Q4qgnODdYZXG4FBP4ERQ4IaNT6CRhcCAQGBNg4KEYMVM4Iskyc+kymRHAqCb?= =?us-ascii?q?YkNhg6MFIMYihKURpNOgX6Ie5VNAgQCBAUCDgEBBYFrIYFZcBWDJFAXAg2SE?= =?us-ascii?q?IUUhUR0AgktAgYBCQEBAwl8iwYCBSEHghcBAQ?= IronPort-PHdr: =?us-ascii?q?9a23=3An4QXIxd0WFNpMHpuHTE43HvslGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwaQAdfU7vtFj6zdtKWzEWAD4JPUtncEfdQMUh?= =?us-ascii?q?IekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsutaFjbo3n05jkXSV?= =?us-ascii?q?3zMANvLbHzHYjfx828y+G1/cjVZANFzDqwaL9/NlO4twLU48IXmoBlbK02z0?= =?us-ascii?q?jE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.77,463,1596499200"; d="scan'208";a="621075327" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 09 Nov 2020 08:58:43 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 0A98whnl001629 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 9 Nov 2020 08:58:43 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 9 Nov 2020 02:58:43 -0600 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 9 Nov 2020 03:58:42 -0500 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 9 Nov 2020 02:58:42 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=eJGF8Y7xl5S+ooQCvM7RnR1kwOB5UkXRUETilq9BpSUhW3zMl+cMEqXm+xMHg7EMHzgh99NxF7PIwD6ZorYWmP/QRsmRDrQxEA2m6plRjC46LsHg8nVEzfB5ewQzvXH8bJ4BryJqRtnC9LKdoUzWOn/9T+tXJOJK13ifI0eBzzvT9D78o7dkg7aDF41cjzT8/Tl59D7JuaoSHs+iSSij2a4AHN3B8VUUdsFU4JdxHwTwR5GTj7aRJh37Gvd7fpxQrA2MRTTCjS3uCMRxWr8+DVHDC5ousCxobAVsj3LWUDIk+Prl5+YxJu/BiWsy0NjcVqBWwX5ZxsVttkKCvnbFig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QQpzLPpEe57eQYViX6jzKnAnVy65G4ngqvlZLMG9O6s=; b=iQ0hnJvGqdjhoSOgd2vfA2qNSa3RtYQswYUIL7Q71vNvXnG9CNpwmLBU1WVKD9HY1UjOmL4MtLogScqz+/fuw1aLq+cf4G0IN62YZ0kF+DWYiSCcHRCahNOebNgZyt1CgAQbYKmcVIEB4qDd5fW8nsWr+Tlya6rIOMCzht28eLyAT1x1Vm/z+ym55N3PisRUvi5xN7qb4WPVlw0XBhY3EwoVa96StjR6XAQt6gpSKOwaVvY1Z62O1UH/BlCNRUNCRVXYzOfiU+ICRYWAumeUpio3YvhNOpT1vjvdA9pkhr+Temj7wVWxsLJcBgqyXVGglCbBocUOzHXmou18qv6vIg== 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=QQpzLPpEe57eQYViX6jzKnAnVy65G4ngqvlZLMG9O6s=; b=iPgaqnFFqW+nf2g/ctpzL1WHhMGYe1x79gQCEgdvbI7j7mfIdasXTB4WcmHtWVtdCp8p6lsnDphbPwgcMFQw5JqPHPY8xvKcP9ijyRS8GS4jEq+3Vb5KcJX63QvVjngPwxZEKHG42ITPjhwfzGkNXLYjwzgFkRUv5KTbBhD6F4s= Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by MW3PR11MB4747.namprd11.prod.outlook.com (2603:10b6:303:2f::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.23; Mon, 9 Nov 2020 08:58:40 +0000 Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::ad88:1b7e:c9f2:b30d]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::ad88:1b7e:c9f2:b30d%6]) with mapi id 15.20.3541.024; Mon, 9 Nov 2020 08:58:40 +0000 From: "Pascal Thubert (pthubert)" To: Alvaro Retana , "draft-ietf-roll-unaware-leaves@ietf.org" CC: "roll-chairs@ietf.org" , "Routing Over Low power and Lossy networks" , Rahul Jadhav Thread-Topic: AddRE: AD Review of draft-ietf-roll-unaware-leaves-18 (cont) Thread-Index: AdatWy2mXTdzAsDFTqmHK9bpaMWnsgHLm6oAACjXjZA= Date: Mon, 9 Nov 2020 08:58:26 +0000 Deferred-Delivery: Mon, 9 Nov 2020 08:58:14 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2a01:cb1d:4ec:2200:8cd9:8d24:c5d2:c846] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 45791ab8-56a8-4ed0-f346-08d8848da784 x-ms-traffictypediagnostic: MW3PR11MB4747: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8273; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Yvr+VP8sYOH/rg6nyDlcizmhxFbzeGdGWoimCAkcPW9ssEdT+CNB98Ew2vyOaVgmypTuLsYR8JFgpfk2xreqUvRK03H5wnKLr5O9wi8pf92pHEctGMDt2DwP8DS8Zc5LsW6kRaKOZx/7n1+CqZBW6ofOsHyDyIgBl7Iz2UwO3kaAWKyqsuQTBrIyCDNzsCHqPCWl29pOvdYlCEhxmx9H23C5fJhGPhcTA58VlC4lpd2BKz+L0IB43lSPZ44EaIV6DFgxw3xefwczPEcIOO5FB0O9/vdUP5/NPFJ+77aQLlwNQ4tBaNck9LPZnUxp+SmPqgFD25RL+IYGW81OLsmuIYBksUOmBSRKlXPAwHMhSRGrcA9o640JjJDFzTH3oSGec6O5eHpvN0cWTRtqJd/ddg== 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:(346002)(376002)(396003)(366004)(39860400002)(136003)(7696005)(33656002)(86362001)(83380400001)(186003)(2906002)(55016002)(66476007)(9686003)(64756008)(66556008)(4326008)(52536014)(6666004)(71200400001)(6506007)(8936002)(66946007)(110136005)(54906003)(316002)(66446008)(8676002)(76116006)(5660300002)(478600001)(966005)(66574015); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: H4XGaeqWL6Rj+55ivCAxskjTqcT2sDLvpW6lxEg9TqcrPM7zoo0dI8Ye5LSv8fiKQB8cqmHdfRK4boO155fqqIiA/zGoTa/TC6lz0Dlg8svIaHBTznJtj4x7TMJwqftIPDLNQ3+NbXk2+FTF46k/+EqVoV+2obfSq8kNDxxhlRxoYrtClyDYaiyHhcCoGVh+J5ERicwkssAV4EasxdtJs5Wh3Dm4lR2G68W2wxmnnVBJJiu8n9gh4pXiVGt/h/e/gu3rXIUJGZX544EzYD/frOQRHxVz9ZftqlpgqenzaqAqrjTJIxESxGLC3az0N69BTzmOTJdmD0vfccgC40XQHsj9/JGOZ8nSp6suSLQi+LwdngVMyFodR5xwQYMKCwbJvKQcmmnRASm51TFpxvxLGgq5UPWJdw+vS/+aHCw8Ci1xhU4l7/qG81GJ8d5TM/9WUrvFyL6R+c/cZIJe5NnmUpVtaaAyh2XpTD7K+7jctlBddKU+LaOGcc0hGVyaaqqeGQC9gBjm0QaXGCDx3A1POE5hnLgQPLBwMMtQcEqoMU0b0ysfszSyTWaCZAJe2Zxm61Avz+4NEvLRdDaPaFsygft6m5gFxzp62SlG8K5B9wDYKI150MJIHUtQxrW/qNEy7j+/DeeyWawYW2SrMD9vonv1jSJjZA0UbDti8cndGd6dmQY3NKSKiEuHRdCqn1wF/O5kplvgIEhpM0S6tdHGNA== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB4881.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 45791ab8-56a8-4ed0-f346-08d8848da784 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Nov 2020 08:58:40.7643 (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: XojKFh5z3UownY0gCG+loTVVbd6cN9KaGN4kIeTkLWxWhgYTGDiu8GfcmLl8EoUg9azlvxfxLXjv7eT11m+Saw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR11MB4747 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: alln-core-6.cisco.com Archived-At: Subject: Re: [Roll] AddRE: AD Review of draft-ietf-roll-unaware-leaves-18 (cont) 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, 09 Nov 2020 08:58:48 -0000 TWFueSB0aGFua3MgQWx2YXJvIQ0KDQpJIGNvbW1pdHRlZCB0byBnaXQgYnV0IHRoZSBJRVRGIGRh dGF0cmFja2VyIGlzIGxvY2tlZCB0aWxsIG5leHQgd2Vlay4NClBsZWFzZSBmaW5kIHRoZSBkZWx0 YSBoZXJlOg0KDQpodHRwczovL2dpdGh1Yi5jb20vcm9sbC13Zy9yb2xsLXVuYXdhcmUtbGVhdmVz L2NvbW1pdC82MDY4ZTQwZDY0NTBiMzNlNjY0NDYwZDYwNmU4NjA0MDFjYzlhNWMzDQoNCm1vcmUg YmVsb3cgOiApDQoNCj4gDQo+IEhpIFBhc2NhbCENCj4gDQo+IA0KPiBUaGVyZSBhcmUganVzdCBh IGNvdXBsZSBvZiByZW1haW5pbmcgY29tbWVudHMuLi5ub3RoaW5nIG1ham9yLiDCoEkgd2lsbCBz dGFydA0KPiB0aGUgSUVURiBMQyB3aGVuIHlvdSB1cGxvYWQgYW4gdXBkYXRlLiA6LSkNCj4gDQo+ IFRoYW5rcyEhDQo+IA0KPiBBbHZhcm8uDQo+IA0KPiANCj4gDQo+IC4uLg0KPiA+ID4gPiBCdXQg d2UncmUgYWxzbyBtZXJnaW5nIHRoZSBzdGF0aXMgd2l0aCB0aGUgRENPLUFDSyBTdGF0dXMgSW4g dGhhdA0KPiA+ID4gPiB3ZSBkZXByZWNhdGUNCj4gPiA+ID4gaHR0cHM6Ly93d3cuaWFuYS5vcmcv YXNzaWdubWVudHMvcnBsL3JwbC54aHRtbCNycGwtZGNvLWFjay1zdGF0dXMNCj4gPiA+DQo+ID4g PiBUaGF0IGlzIG5ldyEhIEkgZG9uJ3QgZXZlbiBzZWUgRENPLUFDSyBtZW50aW9uZWQgaW4gdGhl IGRvY3VtZW50IGF0IGFsbC4NCj4gPiA+DQo+ID4gPiBEb2VzIHRoaXMgbWVhbiB0aGF0IMKnMTIu NSBzaG91bGQgYWxzbyBiZSBjaGFuZ2VkIHRvIGluY2x1ZGUgdGhlDQo+ID4gPiBEQ08tQUNLIG1l c3NhZ2UgaW4gaXQ/DQo+ID4NCj4gPiBOb3Qgc3VyZSBJIHVuZGVyc3RhbmQuIMKnMTIuNSBIYXMg dGhlIG9ubHkgRENPIHN0YXR1cywgc3RhdHVzIDEuDQo+IA0KPiDCpzEyLjUgc2F5cyB0aGlzOg0K PiANCj4gwqAgwqBUaGlzIHNwZWNpZmljYXRpb24gY3JlYXRlcyBhIG5ldyBTdWJyZWdpc3RyeSBm b3IgdGhlIFJQTCBOb24tDQo+IMKgIMKgUmVqZWN0aW9uIFN0YXR1cyB2YWx1ZXMgZm9yIHVzZSBp biB0aGUgUlBMIERBTy1BQ0sgYW5kIERDTyBtZXNzYWdlcw0KPiDCoCDCoHdpdGggdGhlICdBJyBm bGFnIHJlc2V0LCB1bmRlciB0aGUgUlBMIHJlZ2lzdHJ5Lg0KPiANCj4gcy9EQU8tQUNLIGFuZCBE Q08vREFPLUFDSywgRENPLCBhbmQgRENPLUFDSw0KPiANCj4gDQoNCk9oIEkgc2VlLCBkb25lLg0K DQo+IA0KPiAuLi4NCj4gPiA+IFttYWpvcl0gV2hhdCBzaG91bGQgdGhlIHJlY2VpdmVyIGRvIGlm IGEgZGlmZmVyZW50IHZhbHVlIGlzIHVzZWQ/DQo+ID4gPg0KPiA+IEFkZGVkDQo+ID4gIg0KPiA+ IFJPVlJzeiAoUk9WUiBTaXplKTogSW5kaWNhdGVzIHRoZSBTaXplIG9mIHRoZSBST1ZSLiBJdCBT SE9VTEQgYmUgMSwgMiwNCj4gPiAzLCBvciA0LCBpbmRpY2F0aW5nIGEgUk9WUiBzaXplIG9mIDY0 LCAxMjgsIDE5Miwgb3IgMjU2IGJpdHMsDQo+ID4gcmVzcGVjdGl2ZWx5LiBJZiBhIGxlZ2FjeSBU YXJnZXQgT3B0aW9uIGlzIHVzZWQsIHRoZW4gdGhlIHZhbHVlIG11c3QNCj4gPiByZW1haW4gMCwg YXMgc3BlY2lmaWVkIGluIFtSRkM2NTUwXTsgSW4gY2FzZSBvZiBhIHZhbHVlIGFib3ZlIDQsIHRo ZQ0KPiA+IHNpemUgb2YgdGhlIFJPVlIgaXMgdW5kZXRlcm1pbmVkIGFuZCB0aGlzIG5vZGUgY2Fu bm90IHZhbGlkYXRlIHRoZQ0KPiA+IFJPVlI7IGFuIGltcGxlbWVudGF0aW9uIFNIT1VMRCBwcm9w YWdhdGUgdGhlIHdob2xlIFRhcmdldCBPcHRpb24NCj4gPiB1cHdhcmRzIGFzIHJlY2VpdmVkIHRv IGVuYWJsZSB0aGUgdmVyaWZpY2F0aW9uIGJ5IGFuIGFuY2VzdG9yIHRoYXQNCj4gPiB3b3VsZCBz dXBwb3J0IHRoZSB1cGdyYWRlZCBST1ZSLg0KPiA+ICINCj4gDQo+IFtuaXRdIHMvW1JGQzY1NTBd OyBJbi9bUkZDNjU1MF0uIEluDQoNCkRvbmUNCg0KPiANCj4gDQo+IFttYWpvcl0gInZhbHVlIGFi b3ZlIDQsIHRoZSBzaXplIG9mIHRoZSBST1ZSIGlzIHVuZGV0ZXJtaW5lZCBhbmQgdGhpcyBub2Rl DQo+IGNhbm5vdCB2YWxpZGF0ZSB0aGUgUk9WUjsgYW4gaW1wbGVtZW50YXRpb24gU0hPVUxEIHBy b3BhZ2F0ZSB0aGUgd2hvbGUNCj4gVGFyZ2V0IE9wdGlvbiB1cHdhcmRzIGFzIHJlY2VpdmVkIHRv IGVuYWJsZSB0aGUgdmVyaWZpY2F0aW9uIGJ5IGFuIGFuY2VzdG9yDQo+IHRoYXQgd291bGQgc3Vw cG9ydCB0aGUgdXBncmFkZWQgUk9WUi4iDQo+IA0KPiBTZXZlcmFsIHBvaW50czoNCj4gDQo+IDEt IE1heWJlIEkgbWlzc2VkIGl0LCBidXQgSSBkaWRuJ3Qgc2VlIGFueXdoZXJlIHRoYXQgYSBSUEwg bm9kZSB3b3VsZCB2YWxpZGF0ZQ0KPiB0aGUgUk9WUi4gwqBJcyB0aGF0IGltcGxpY2l0IHNvbWVo b3c/IMKgTm90ZSB0aGF0IEknbSByZWZlcnJpbmcgdG8gUlBMDQo+IGZ1bmN0aW9uYWxpdHkgc2lu Y2Ugd2UncmUgdGFsa2luZyBhYm91dCB0aGUgVGFyZ2V0IE9wdGlvbiAobm90IGZyb20gcmZjODUw NSdzDQo+IHBvaW50IG9mIHZpZXcpLg0KIA0KQXMgb2Ygbm93LCB0aGUgb25seSB2ZXJpZmljYXRp b24gaXMgYnkgdGhlIDZMQlIsIHdoZW4gdGhlIFJvb3QgcHJveGllcyB0aGUgRURBUi4gSXQgaXMg aW1wb3J0YW50IHRoYXQgdGhlIGludGVybWVkaWF0ZSByb3V0ZXJzIHRyYW5zcG9ydCB0aGUgUk9W UiBldmVuIGlmIHRoZXkgZG8gbm90IHVuZGVyc3RhbmQgaXQsIHNvIHRoZSBSb290IGNhbiBkbyBh cHByb3ByaWF0ZSBwcm94eWluZy4gVGhlIDZMQlIgdmVyaWZpZXMgdGhhdCB0aGUgUk9WUiBpcyB0 aGUgc2FtZSwgZWxzZSBpdCB0cmlnZ2VycyBhIHZhbGlkYXRpb24gYnkgdGhlIDZMUi4NCg0KVGhp cyBtYXkgaGFwcGVuIGluIHRoZSBjYXNlIHdoZXJlIHRoZSA2TE4gZG9lcyBub3QgY2xhaW0gdGhl IFJPVlIgaXMgY3J5cHRvZ3JhcGhpYyBhbmQgdGh1cyB0aGUgNkxSIGRvZXMgbm90IGRvIHRoZSB2 YWxpZGF0aW9uLCBidXQgdGhlIFJPVlIgYWxyZWFkeSBleGlzdGVkIGF0IHRoZSA2TEJSIGFuZCB3 YXMgc2VlbiBhcyBjcnlwdG9ncmFwaGljLCBzbyB0aGUgNkxCUiB0cmlnZ2VycyB0aGUgY2hlY2su DQoNClNlZSBodHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9hdXRob3JzL3JmYzg5MjguaHRtbA0K Ig0KVGhlIDZMUiBNVVNUIGluZGljYXRlIHRvIHRoZSA2TEJSIHRoYXQgaXQgcGVyZm9ybWVkIGEg c3VjY2Vzc2Z1bCB2YWxpZGF0aW9uIGJ5IHNldHRpbmcgYSBzdGF0dXMgY29kZSBvZiA1ICgiVmFs aWRhdGlvbiBSZXF1ZXN0ZWQiKSBpbiB0aGUgRURBUi4gVXBvbiBhIHN1YnNlcXVlbnQgRURBUiBm cm9tIGEgbmV3IDZMUiB3aXRoIGEgc3RhdHVzIGNvZGUgdGhhdCBpcyBub3QgNSBmb3IgYSB2YWxp ZGF0ZWQgQmluZGluZywgdGhlIDZMQlIgTVVTVCBpbmRpY2F0ZSB0byB0aGUgbmV3IDZMUiB0aGF0 IGl0IG5lZWRzIHRvIGNoYWxsZW5nZSB0aGUgNkxOIHVzaW5nIGEgc3RhdHVzIGNvZGUgb2YgNSBp biB0aGUgRURBQy4NCiINCg0KTm93LCBpdCBpcyBteSBob3BlIHRoYXQgaW4gdGhlIGZ1dHVyZSB3 ZSBhZGQgYW4gUk9WIChyb3V0ZSBvd25lcnNoaXAgdmFsaWRhdGlvbikgbWV0aG9kIHRvIFJQTCwg YmFzZWQgb24gdGhlIFJPVlIuDQoNCj4gMi0gSXQgc2VlbXMgdG8gbWUgdGhhdCBib3RoIHRoZSA2 TFIgYW5kIHRoZW4gdGhlIFJvb3Qgc2ltcGx5IGNvcHkgdGhlIFJPVlINCj4gZnJvbS90byB0aGUg RURBUi4gwqBJT1csIHRoZXJlIGRvZXNuJ3Qgc2VlbSB0byBiZSBhbm90aGVyIFJQTCBhbmNlc3Rv ciB3aG8NCj4gd291bGQgZG8gYW55dGhpbmcgd2l0aCBpdC4NCiANClRydWUsIHRoaXMgc3BlYyBk b2VzIG5vdCBoYXZlIGEgYmFja3dhcmQgY29tcGF0aWJpbGl0eSBpc3N1ZS4gDQpCdXQgd2UgYXJl IHN0aWxsIGNoYW5naW5nIHRoZSBEQU8gZm9yIGFsbCBtb2Rlcy4gU28gSSB0aG91Z2h0IHdlIG5l ZWQgdG8gaW5kaWNhdGUgd2hhdCB0aGUgYmVoYXZpb3IgaXMgaW4gb3RoZXIgbW9kZXMgYXMgd2Vs bC4NCg0KDQo+IDMtIEFzc3VtaW5nIHRoYXQgdGhlIDZMUiBzb21laG93IG9yaWdpbmF0ZWQgYSBi YWQgVGFyZ2V0IE9wdGlvbiAod2l0aCBhDQo+IFJPVlJzeiA+IDQpLCB0aGVuIGl0IGxvb2tzIGxp a2UgdGhlIFJvb3Qgd291bGRuJ3QgYmUgYWJsZSB0byBzZW5kIGFuDQo+IEVEQVIuIMKgV2hhdCBz aG91bGQgaXQgZG8/IMKgSSdtIGd1ZXNzaW5nIGl0IHNob3VsZCBzZW5kIGEgZmFpbHVyZSBzaWdu YWwgYmFjayB0bw0KPiB0aGUgNkxSLg0KDQpUcnVlLiBJIGd1ZXNzIHRoYXQgY291bGQgYmUgYSBi YWQgUlBMIHN0YXR1cyBvbiB0aGUgREFPLUFDSzsgaWYgdGhlcmUgaXMgbm8gQUNLIHJlcXVlc3Rl ZCBpdCBjb3VsZCBiZSBhIERDTy4gDQpJJ20gd29uZGVyaW5nIGlmIHdlIHNob3VsZCBzdGFydCBk ZWZpbmluZyBSUEwgc3RhdHVzZXMuIE5vdGUgdGhhdCB0aGUgY2FzZSBpcyBlaXRoZXIgYSBidWcg b3IgYSBiYWNrbGV2ZWwgUm9vdCwgSU9XIGEgZGVwbG95bWVudCBpc3N1ZS4gDQpXZSBzaG91bGQg bm90IGNvbXBsZXhpZnkgdGhlIGNvZGUgb3ZlcnRseSBmb3IgYW55IGlmIHRob3NlIGNhc2UuDQoN Cj4gDQo+IDQtIFdlJ3JlIG1ha2luZyBhc3N1bXB0aW9ucyBhYm91dCBhbiAidXBncmFkZWQgUk9W UiIuDQo+IA0KPiANCj4gVG8gc29sdmUgYWxsIHRoaXMgbWF5YmUganVzdCBkZWxldGUgc3RhcnRp bmcgd2l0aCAiSW4gY2FzZSBvZiBhIHZhbHVlIGFib3ZlDQo+IDQuLi4iIMKgIElmIFJQTCBpcyBq dXN0IGNhcnJ5aW5nIHRoZSBpbmZvcm1hdGlvbiB0aGVuIHRoYXQgc2VlbXMgbW9yZSBhbiByZmM4 NTA1DQo+IGlzc3VlLi4uDQo+IA0KDQpXZWxsLCB0aGUgNkxSIGlzIGNhcGFibGUgb2YgcGxhY2lu ZyBhIGxhcmdlciBST1ZSIGFuZCB0aGUgUm9vdCBkb2VzIG5vdCB1bmRlcnN0YW5kIGl0LiBUaGlz IG5lZWRzIHRvIGJlIHJlcG9ydGVkIHRvIHRoZSBuZXR3b3JrIGFkbWluLiANCkknbSBub3QgdG9v IGhhcHB5IHJlbW92aW5nIHRoZSBzZW50ZW5jZSBmb3IgdGhlIHJlYXNvbnMgYWJvdmUuIEknbGwg ZG8gdGhpcyBnaXQgY29tbWl0IHdpdGggaXQgYnV0IGtlZXAgdGhlIHBvaW50IG9wZW4uDQoNCg0K PiA+IE5vdGhpbmcgcHJldmVudHMgYSBwYWNrZXQgY29taW5nIGluIGEgUlBMIGRvbWFpbiB0byBj YXJyeSBhbiBSUEkuDQo+ID4gRS5nLiwgdGhhdCBwYWNrZXQgZXNjYXBlZCBhbm90aGVyIFJQTCBk b21haW4sIHdoaWNoIGlzIG5vdyB2YWxpZC4gVGhlDQo+ID4gYm9yZGVyIHJvdXRlciAodHlwaWNh bGx5IHRoZSByb290KSBtdXN0IHJld3JpdGUgaXQuIHRoZSBxdWVzdGlvbiBpcw0KPiA+IHdoZXRo ZXIgd2UgYXNzdW1lIHRoYXQgdGhlIFJVTCBwbGFjZWQgYSBtZWFuaW5nZnVsIG9uZS4gSSdkIHNh eSB0aGF0DQo+ID4gY2Fubm90IGJlIGFzc3VtZWQgaW4gYWxsIGNhc2VzLCBlLmcuLCBpZiBpbnN0 ZWFkIG9mIGEgbGVhZiB3ZSBoYXZlDQo+ID4gYW5vdGhlciBSUEtMIG5ldHdvcmsuDQo+ID4gQnV0 IHdoZW4gaXQgaXMgdXNlZnVsLCB0aGUgNkxSIHNob3VsZCBoYXZlIGEgcG9saWN5IHRvIGtub3cg c28gaXQNCj4gPiBrbm93cyBob3cgdG8gdXNlIGl0Lg0KPiAuLi4NCj4gPiBJIGFkZGVkDQo+ID4g Ig0KPiA+IElmIHRoZSBwYWNrZXQgZnJvbSB0aGUgUlVMIGhhcyBhbiBSUEksIHRoZSA2TFIgYXMg YSBSUEwgYm9yZGVyIHJvdXRlcg0KPiA+IE1VU1QgcmV3cml0ZSB0aGUgUlBJIHRvIGluZGljYXRl IHRoZSBzZWxlY3RlZCBJbnN0YW5jZSBhbmQgc2V0IHRoZQ0KPiA+IGZsYWdzLCBidXQgaXQgZG9l cyBub3QgbmVlZCB0byBlbmNhcHN1bGF0ZSB0aGUgcGFja2V0Lg0KPiA+ICINCj4gPg0KPiA+IEFs c28gYWRkZWQNCj4gPg0KPiA+ICINCj4gPiBJdCBpcyB1cCB0byB0aGUgNkxSIChlLmcuLCBieSBw b2xpY3kpIHRvIHVzZSB0aGUgUlBMSW5zdGFuY2VJRA0KPiA+IGluZm9ybWF0aW9uIHByb3ZpZGVk IGJ5IHRoZSBSVUwgb3IgcmV3cml0ZSBpdCB0byB0aGUgc2VsZWN0ZWQNCj4gPiBSUExJbnN0YW5j ZUlEIGZvciBmb3J3YXJkaW5nIGluc2lkZSB0aGUgUlBMIGRvbWFpbi4NCj4gPiAiDQo+IA0KPiBH b29kLi4uZXhjZXB0IHRoYXQgSSB0aGluayB0aGVyZSdzIGEgTm9ybWF0aXZlIGNvbmZsaWN0OiAi dGhlIDZMUi4uLk1VU1QNCj4gcmV3cml0ZSB0aGUgUlBJIiB2cyAidXAgdG8gdGhlIDZMUi4uLnRv IHVzZS4uLm9yIHJld3JpdGUiLg0KPiAgcy9NVVNUL1NIT1VMRA0KDQpEb25lLCB0aG91Z2ggdW5j b252aW5jZWQuICJ1cCB0byB0aGUgNkxSLi4uIiBoYXMgbm8gbm9ybWF0aXZlIHRleHQgb24gdGhl IDZMUiBiZWhhdmlvciwganVzdCBvbiB0aGUgNkxOLiANCg0KPiANCj4gU2hvdWxkIGFueSBvZiB0 aGlzIGJlIGFsc28gaW4gVXNlb2ZSUExJbmZvPyDCoE9yIG1heWJlIGl0IHNob3VsZCBiZSBleHBs YWluZWQNCj4gdGhlcmUgYW5kIHJlZmVyZW5jZWQgZm9ybSBoZXJlLiDCoFVzZW9mUlBMSW5mbyB0 YWxrcyBhYm91dCBhbHdheXMgaW5zZXJ0aW5nDQo+IHRoZSBSUEkgYXQgdGhlIDZMUiwgbm8gZXhj ZXB0aW9ucy4NCj4gDQoNCkknbGwgb3BlbiBhIHRocmVhZDsgeW91ciBwb2ludCBvbiB0aGUgc2Vj dXJpdHkgc2VjdGlvbiBjb3VsZCBiZSByZWZsZWN0ZWQgdGhlcmUsIHRoYXQgaWYgdGhlIGV4dGVy bmFsIGRlc3RpbmF0aW9uIHBhc3NlcyBhIHBhY2tldCB3aXRoIGEgUlBJIHRoZW4gdGhlIFJQSSBz aG91bGQgYmUgcmV2aXNpdGVkIG9yIGVuY2Fwc3VsYXRlZC4NCg0KDQo+IA0KPiANCj4gLi4uDQo+ ID4gSSdtIHdvbmRlcmluZyBpZiB0aGVyZSBhZ2FpbiB0aGUgZW5kIG9mIHlvdXIgbWVzc2FnZSB3 YXMgbG9zdD8NCj4gDQoNCkdyZWF0LCByZWFkeSB0byBwdWJsaXNoIHdoZW4geW91IChhbmQgdGhl IGRhdGF0cmFja2VyKSBhcmUhDQoNClRha2UgY2FyZSwNCg0KUGFzY2FsDQoNCg0K From nobody Mon Nov 9 10:57:14 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 650D83A0C1F; Mon, 9 Nov 2020 10:57:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 vvVow1ES4ihS; Mon, 9 Nov 2020 10:57:12 -0800 (PST) Received: from mail-ej1-x629.google.com (mail-ej1-x629.google.com [IPv6:2a00:1450:4864:20::629]) (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 9A4393A0846; Mon, 9 Nov 2020 10:57:11 -0800 (PST) Received: by mail-ej1-x629.google.com with SMTP id me8so4376552ejb.10; Mon, 09 Nov 2020 10:57:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:date:message-id:subject:to:cc :content-transfer-encoding; bh=QbzGuvefxIVdI1bQOgBTaV/PwGjbm7skIRPJPre4BZ0=; b=TBl/yQzWCQtHexTrx1hxizwZolweLK+iRcmt8W2lWyltWUQKFbzoLTKx/xbAt7kj9q YTxaDP6yv4RzWhDPCdtZxACNxhHEg8faPCzroAdRCSxGEM+CCKV2HJRmj5lp20cwdbJe NwqRdgCqtloLCh0dO7h+y2dk761SIIP4gsWeoVxz8ytKzbDUrywuelFg644rA28pdzaR PxrO6cIFoSHnlXitbIoJgy40usJWSKh7jcp6ICVoRfzW2b23LhzOwMOLmYuIzQYlvJfG lfbXShClgkdzQ4j/hxV6T6XE8ULRe1NtKEhCwxe4V5L496QeMSNMJrlq850byBIYcHDi k8Zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:date:message-id:subject:to:cc :content-transfer-encoding; bh=QbzGuvefxIVdI1bQOgBTaV/PwGjbm7skIRPJPre4BZ0=; b=mGhH8qoOPNDxM0blv/zOXPm10ZmieSW0vwgqYjmH+m+Np0Aqn2Zyp9VMbg/CQ9Idko 3xRI4g9CWkhIsIBCfBQHMcPV2ph5rZDLyVSSYkF0hwBEEaYiw71rixWxJPiZt8RA5jPW TDq1FolWBZUmCyaDwRX1RWHFTfD1V7EJFeUWcppGR9CXpvQT2TvVrysjya7DlWuE6/VF NiAFnyCWh+SgJWOZD0WV44MipP81ByDBbh3FjdocGTHYP8xL0ARQvZXEe7B/GD+9AaJx cXtRjqY4qyf4aMkQ1Ih2QSKVgEsmalWe8SddnAKhwNN2yM8Xg7Zqa06Rf4myin9KPOR5 UCZw== X-Gm-Message-State: AOAM5319AphClgyZV+B1ehX1y8GQ40jeP+csM/Vk54AhzFOKZcNbIcCm uHHd4sHh/aiAhx97ZB/QRVDgIrnGnhaV/VDrvJc8Y3LyPuj3mQ== X-Google-Smtp-Source: ABdhPJyoDZSTJZs+lzF5ODhGbG+xWsA2T5ds4ZpXPmfSLnirq38EihhJMHf/MIIebVyPVpVzjLqa/bL2ZIeem2XFK5A= X-Received: by 2002:a17:906:f744:: with SMTP id jp4mr16202354ejb.122.1604948229442; Mon, 09 Nov 2020 10:57:09 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 9 Nov 2020 10:57:08 -0800 From: Alvaro Retana MIME-Version: 1.0 Date: Mon, 9 Nov 2020 10:57:08 -0800 Message-ID: To: "draft-ietf-roll-useofrplinfo@ietf.org" Cc: Peter van der Stok , "roll-chairs@ietf.org" , Routing Over Low power and Lossy networks Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [Roll] AD Review of draft-ietf-roll-useofrplinfo-41 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, 09 Nov 2020 18:57:13 -0000 Dear authors: Thank you for all the work on this draft. I have a couple of comments in-line -- nothing hard to address. =C2=A0I mostly looked at the diffs (wrt -31) and so my comments are just on new text. I want to progress this draft with unaware-leaves -- to make it easier on the IESG. =C2=A0I'll start the IETF LC when both are ready. Thanks! Alvaro. >From idnits: =C2=A0 ** The abstract seems to contain references ([RFC8138]), which it =C2=A0 =C2=A0 =C2=A0shouldn't. =C2=A0Please replace those with straight tex= tual mentions of the =C2=A0 =C2=A0 =C2=A0documents in question. [Line numbers from idnits.] ... 66 =C2=A0 4. =C2=A0Updates to RFC6553, RFC6550 and RFC8138 . . . . . . . .= . . . =C2=A0 7 67 =C2=A0 =C2=A0 4.1. =C2=A0Updates to RFC6550: Advertising External Route= s with Non- 68 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Storing Mode Signaling. . . . . . . = . . . . . . . . . . . =C2=A0 7 69 =C2=A0 =C2=A0 4.2. =C2=A0Updates to RFC6553: Indicating the new RPI Opt= ion Type. . =C2=A0 8 70 =C2=A0 =C2=A0 4.3. =C2=A0Updates to RFC6550: 71 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Configuration Options and Mode 72 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 of Operation =C2=A0. . . . . . . . .= . . . . . . . . . . . . . =C2=A011 73 =C2=A0 =C2=A0 4.4. =C2=A0Updates to RFC6550: Indicating the new RPI in = the 74 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 DODAG Configuration option Flag. =C2= =A0. . . . . . . . . . . . =C2=A012 75 =C2=A0 =C2=A0 4.5. =C2=A0Updates to RFC8138: Indicating the way to deco= mpress with 76 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the new RPI Option Type. =C2=A0. . .= . . . . . . . . . . . . . =C2=A013 [nit - no action needed, just a suggestion] Group all the updates to rfc6550: either in one sub-section or in consecutive ones. ... 493 4.3. =C2=A0Updates to RFC6550: Configuration Options and Mode of Operat= ion 495 =C2=A0 RFC6550 section 6.7.6 describes the DODAG Configuration Option.= =C2=A0In 496 =C2=A0 this option are a series of Flags in the first octet of the pay= load. 497 =C2=A0 These flags are described by the DODAG Configuration Option Fla= gs 498 =C2=A0 registry [dodagcfg], in section 20.14 of RFC6550. 500 =C2=A0 Anticipating future work to revise RPL relating to how the LLN = and 501 =C2=A0 DODAG is configured, this document changes the interpretation o= f the 502 =C2=A0 [dodagcfg] Registry to be limited to Mode-of-Operation (MOP) 503 =C2=A0 specific. =C2=A0The MOP is described in [RFC6550] section 6.3.1= . =C2=A0The 504 =C2=A0 Options Flags Registry is renamed, and applies to MOP values ze= ro (0) 505 =C2=A0 to six (6) only, leaving the flags reserved for MOP value seven= (7). 507 =C2=A0 In addition, this document reserves MOP value 7 for future expa= nsion. [] NEW> =C2=A0 =C2=A0Section 6.7.6 of RFC6550 describes the DODAG Configuration Opt= ion as =C2=A0 =C2=A0containing a series of Flags in the first octet of the payload= . =C2=A0 =C2=A0Anticipating future work to revise RPL relating to how the LLN= and DODAG =C2=A0 =C2=A0are configured, this document renames the DODAG Configuration = Option =C2=A0 =C2=A0Flags registry so that it applies to Mode of Operation (MOP) v= alues zero =C2=A0 =C2=A0(0) to six (6) only, leaving the flags unassigned for MOP valu= e seven =C2=A0 =C2=A0(7). =C2=A0The MOP is described in [RFC6550] section 6.3.1. =C2=A0 =C2=A0In addition, this document reserves MOP value 7 for future exp= ansion. =C2=A0 =C2=A0See Sections 11.2 and 11.3. 509 4.4. =C2=A0Updates to RFC6550: Indicating the new RPI in the DODAG 510 =C2=A0 =C2=A0 =C2=A0Configuration option Flag. ... 529 =C2=A0 For a MOP value of 7 or above, the flag MAY indicate something 530 =C2=A0 different and MUST NOT be interpreted as "RPI 0x23 enable" unle= ss the 531 =C2=A0 specification of the MOP indicates to do so. =C2=A0For a MOP va= lue of 7, a 532 =C2=A0 node SHOULD assume that the RPI 0x23 option is enabled. [major] The text in =C2=A74.3 says that the flags for MOP 7 are reserved (I'm suggesting unassigned -- but that makes no difference in the context of this comment), but this text seems to want to pre-define what to do with the reserved/unassigned flags. =C2=A0Please take the first sentence out; then MOP 7 is defined it can figure out what to do with the flags. [major] How do you normatively enforce "SHOULD assume"? =C2=A0When is it ok to not do so? =C2=A0IOW, why use SHOULD and not MUST? Suggestion> =C2=A0 =C2=A0For a MOP value of 7, a node MUST use the RPI 0x23 option is. ... 691 6. =C2=A0Use cases ... 821 =C2=A0 =C2=A0 =C2=A0- In the uses cases, we dont assume that the RUL s= upports IP-in-IP 822 =C2=A0 =C2=A0 =C2=A0encapsulation. [nit] s/dont/don't ... 993 7.1.3. =C2=A0SM: Example of Flow from Root to RUL ... 1033 =C2=A0 IP-in-IP encapsulation MAY be avoided for Root to RUL communic= ation. 1034 =C2=A0 In SM, it can be replaced by a loose RH3 header that indicates= the 1035 =C2=A0 RUL, in which case the packet is routed to the 6LR as a normal= SM 1036 =C2=A0 operation, then the 6LR forwards to the RUL based on the RH3, = and the 1037 =C2=A0 RUL ignores both the consumed RH3 and the RPI, as in Non-Stori= ng 1038 =C2=A0 Mode. [major] s/encapsulation MAY be avoided/encapsulation may be avoided Not a Normative statement, just a fact. ... 2378 11.2. =C2=A0Changes to DODAG Configuration Options Flags [nit] s/.../Change to the DODAG Configuration Options Flags registry 2380 =C2=A0 This document changes the name of the "DODAG Configuration Opt= ion 2381 =C2=A0 Flags" [dodagcfg] to "DODAG Configuration Option Flags for MOP= 0..6". [] NEW> =C2=A0 =C2=A0This document requests IANA to change the name of the "DODAG =C2=A0 =C2=A0Configuration Option Flags" registry to "DODAG Configuration O= ption Flags =C2=A0 =C2=A0for MOP 0..6". 2383 11.3. =C2=A0Change MOP value 7 to Reserved 2385 =C2=A0 This document changes the allocation status of the Mode of Ope= ration 2386 =C2=A0 (MOP) [ianamop] from Unassigned to Reserved. =C2=A0This change= is in 2387 =C2=A0 support of future work related to capabilities. [] NEW> =C2=A0 =C2=A0This document requests the changing the registration status of= value 7 in =C2=A0 =C2=A0the Mode of Operation registry from Unassigned to Reserved. = =C2=A0This change =C2=A0 =C2=A0is in support of future work. ... 2564 14.1. =C2=A0Normative References ... 2571 =C2=A0 [dodagcfg] 2572 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0IANA, "DODAG Configur= ation Option Flags", Sept 2020, 2573 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0. 2576 =C2=A0 [ianamop] =C2=A0IANA, "Mode Of Operation", Sept 2020, 2577 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0. [minor] These references are not needed. ... 2636 =C2=A0 [RFC8504] =C2=A0Chown, T., Loughney, J., and T. Winters, "IPv6= Node 2637 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Requirements", BCP 22= 0, RFC 8504, DOI 10.17487/RFC8504, 2638 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0January 2019, . [minor] This reference can be Informative. From nobody Mon Nov 9 11:13:59 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C2603A1273; Mon, 9 Nov 2020 11:13:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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 cyDUrBIvUrBI; Mon, 9 Nov 2020 11:13:57 -0800 (PST) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (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 9AAF13A11D4; Mon, 9 Nov 2020 11:13:57 -0800 (PST) Received: by mail-ed1-x530.google.com with SMTP id v4so9982772edi.0; Mon, 09 Nov 2020 11:13:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc:content-transfer-encoding; bh=lTqoroyooKJIwn2sJbvqZrKeK8/a4NUNkBtSOl4ioAY=; b=oZWdy9gpFJlG5SNDpzZ+TlQOOQL24w0h4Zh824j5PGPgmNpdgnD/4Jn2q9aBYZ5eHQ jed7/DBEfUvNCjaBc/W7qq3iUq8IFBWGVQEC1yspXCPoDc3fl7bvVY3GYP5XqIhije1m wwL1SjhX8ylkhnf10WyePOirbgQ0ogvlnKCTSJwVI8ajtChj8O/aD6EY1cruNpf+zjqs tC6qvXjNCCDVg4mZaapmx/Quh4vertmfICapc2j1rE7iXRXmwHj5JzRaXoD/FvJncaRQ eWH9rpmrqwbpXob0St5INgu5VBtygyHgfFkDsd9RDBTKsjXDRfgQp/Siv3yAI03zCAW4 9Bdw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc:content-transfer-encoding; bh=lTqoroyooKJIwn2sJbvqZrKeK8/a4NUNkBtSOl4ioAY=; b=YElUaKl7IH4KijnlV5ZF5I4Jwn8Ry5dtTUdGwRkkL3zgaNXtS0AWBBdggyD6rzSaU6 I/JY4RT0C8OD6cZHNW2zU+hjzReUJE/qd/hLvXjiFlTvJQw71CxTlJJT05rpzA0SMZQF /+bj8DWTHioSgDUDTjpWuG4i9Xfd3NNtUmVDW6OYQqCsDBdDdwh55M/XZt8OqwkJyhhM U1b8aetBQQy5XiPsFaJJZkQ+ygBVXeo8yVzapMcOaNYPCe4PELRt1peGx/dLLLsqTt+z LIBLDzJ0pAEG6y5/cQEuY0rpg0UcwxilyGonTgJVcm4/M3Bq6yzD9YAl/d1qmWbPWXfa l/nQ== X-Gm-Message-State: AOAM531+zeVJ326B1MkAfMTm3x4RQGa3PtKH3y4qNHsYhyHEyjICzYzD K9JbD0cxunTPHzIZ8H//YV24QSKngL/yco6c4Wc= X-Google-Smtp-Source: ABdhPJxi5bUVj2QxdSexDhe6TXN/j9xQ3shzd3ITbkkBfN/oD4oMaXVF3dJohzv5oj+8ST8ZaAdu3jLVnSKnmkY1hkE= X-Received: by 2002:aa7:ce8d:: with SMTP id y13mr17651950edv.65.1604949236023; Mon, 09 Nov 2020 11:13:56 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Mon, 9 Nov 2020 11:13:55 -0800 From: Alvaro Retana In-Reply-To: References: MIME-Version: 1.0 Date: Mon, 9 Nov 2020 11:13:55 -0800 Message-ID: To: "Pascal Thubert (pthubert)" , "draft-ietf-roll-unaware-leaves@ietf.org" Cc: "roll-chairs@ietf.org" , Routing Over Low power and Lossy networks , Rahul Jadhav Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Roll] AddRE: AD Review of draft-ietf-roll-unaware-leaves-18 (cont) 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, 09 Nov 2020 19:13:59 -0000 On November 9, 2020 at 3:58:44 AM, Pascal Thubert wrote: Pascal: Hi! I'm ok with the document as is...just one comment remaining. =C2=A0You can take it as a Last Call comment. I'll start the IETF LC when I get updated versions of both this and UseofRPLInfo. =C2=A0If you're ready to submit before the window opens again, feel free to ask the Secretariat (ietf-secretariat@ietf.org) for manual posting -- I'll approve. Thanks! Alvaro. ... > > > Nothing prevents a packet coming in a RPL domain to carry an RPI. . > > Should any of this be also in UseofRPLInfo? Or maybe it should be > > explained there and referenced form here. UseofRPLInfo talks about > > always inserting the RPI at the 6LR, no exceptions. > > > > I'll open a thread; your point on the security section could be reflected > there, that if the external destination passes a packet with a RPI then t= he > RPI should be revisited or encapsulated. As I was reading UseofRPLInfo-41... =C2=A0=C2=A76 (Use Cases) now says this= (one of the assumptions in the use cases): =C2=A0"For traffic leaving a RUL, if the RUL adds an opaque RPI then the description of the RAL applies." This is what I was looking for (in UseofRPLInfo) in terms of how to handle an RPI from the RUL. =C2=A0There is however a difference between what is now written in unaware-leaves and what UseofRPLInfo says (in the "RAL to..." cases). =C2=A0In general, UseofRPLInfo says that the 6LR modifies the RPI, but provide no details except for mentioning the rank... =C2=A0The difference is that unaware-leaves says that if the sender was a RUL then the 6LR "SHOULD rewrite the RPI". I think that we could simply add the Normative text from above to the sentence in =C2=A76/UseofRPLInfo to bring them all in sync: NEW> =C2=A0 =C2=A0- For traffic leaving a RUL, if the RUL adds an opaque RPI the= n the =C2=A0 =C2=A0 =C2=A0description of the RAL applies. =C2=A0The 6LR as a RPL = border router SHOULD =C2=A0 =C2=A0 =C2=A0rewrite the RPI to indicate the selected Instance and s= et the flags. From nobody Mon Nov 9 19:35:00 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC2E3A045E; Mon, 9 Nov 2020 19:34:54 -0800 (PST) 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_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s20nRllhONhW; Mon, 9 Nov 2020 19:34:52 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 616FC3A03FC; Mon, 9 Nov 2020 19:34:51 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0AA3YdD1022475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 9 Nov 2020 22:34:44 -0500 Date: Mon, 9 Nov 2020 19:34:38 -0800 From: Benjamin Kaduk To: "Pascal Thubert (pthubert)" Cc: Alvaro Retana , The IESG , "draft-ietf-roll-turnon-rfc8138@ietf.org" , Martin Duke , Routing Over Low power and Lossy networks , "roll-chairs@ietf.org" , Michael Richardson Message-ID: <20201110033438.GE39170@kduck.mit.edu> References: <20200911162617.GQ89563@kduck.mit.edu> <8F19C753-DCA0-4A32-BA3B-A124B2F7F745@cisco.com> <117497.1600481093@dooku> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: Subject: Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf-roll-turnon-rfc8138-14: (with DISCUSS and COMMENT) 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, 10 Nov 2020 03:34:55 -0000 Hi Pascal, all, Thanks for the updated drafts; I'm happy to see that useofrplinfo is marking MOP 7 as "special" with respect to the flags registry. That said, and my apologies for a hazy memory coming back to this after a couple months, in a year or N from now when mopex is finalized, how will someone looking at mopex know to use RFC8138 on links where 6LoWPAN Header Compression applies (and not use it otherwise)? We are claiming in the -14 of this document that: For a MOP value of 7, [RFC8138] MUST be used on Links where 6LoWPAN Header Compression [RFC6282] applies and MUST NOT be used otherwise. but I am not sure (or have forgotten) what the chain of references is supposed to lead someone who is implementing RPL plus MOP=7 to the requirement to use RFC 8138. I don't think we should just rely on the mopex text to do so, since we are trying to impose the requirement with this document (which predates mopex by some time), and there's not anything (other than our collective memories, of course) requiring mopex to remain consistent with that requirement. Thanks, Ben On Wed, Sep 30, 2020 at 04:25:10PM +0000, Pascal Thubert (pthubert) wrote: > Hello Alvaro > > I uploaded both draft with the suggested update, please see > > https://tools.ietf.org/rfcdiff?url2=draft-ietf-roll-turnon-rfc8138-17.txt > https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-unaware-leaves-21.txt > > Keep safe > > Pascal > > > -----Original Message----- > > From: Alvaro Retana > > Sent: jeudi 24 septembre 2020 17:49 > > To: Pascal Thubert (pthubert) > > Cc: Benjamin Kaduk ; The IESG ; draft-ietf- > > roll-turnon-rfc8138@ietf.org; Martin Duke ; > > Routing Over Low power and Lossy networks ; roll- > > chairs@ietf.org; Michael Richardson > > Subject: Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf-roll-turnon-rfc8138- > > 14: (with DISCUSS and COMMENT) > > > > On September 24, 2020 at 8:13:09 AM, Pascal Thubert wrote: > > > > > > Pascal: > > > > Hi! > > > > > Following the meeting last Monday and subsequent the update of > > > useofrplinfo by Michael (thanks Michael!) I published a new version of > > > the turnon RFC > > > 8138 draft. > > > > > > The major changes are > > > - removed the formal update to RFC 6550 > > > - refer to useofrplinfo as the justification why the flag is not > > > defined for MOP 7 > > > - defined the operation in MOP 7 as compression on iff the Link uses > > > 6LoPWAN HC. > > > > Thanks for these changes. > > > > Because we have to cycle useofrplinfo back through (when the WG is done > > with it), I asked Ben/Martin to wait for that before coming back to this > > document.  It'll make it easier than tracking multiple changes. :-) > > > > > > OTOH, I do have comments on the recent change: > > > > OLD> > >    Section 4.3 of [USEofRPLinfo] updates [RFC6550] to indicate that the > >    definition of the Flags applies to Mode of Operation (MOP) values > >    zero (0) to six (6) only, leaving the flags reserved for MOP value > >    seven (7).  For a MOP value of 7, the bit in position 2 is considered > >    unallocated and [RFC8138] MUST be used on Links where 6LoWPAN Header > >    Compression [RFC6282] applies and MUST NOT be used otherwise. > > > > NEW> > > > >    Section 4.3 of [USEofRPLinfo] updates [RFC6550] to indicate that the > >    definition of the Flags applies to Mode of Operation (MOP) values zero (0) > >    to six (6) only.  For a MOP value of 7, [RFC8138] MUST be used on Links > >    where 6LoWPAN Header Compression [RFC6282] applies and MUST NOT be > > used > >    otherwise. > > > > > > Thanks! > > > > Alvaro. From nobody Tue Nov 10 00:15:52 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 969763A0D86; Tue, 10 Nov 2020 00:15:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 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_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=aUlvePR9; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=iZI/hDWQ 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 S5w_9xz9lWFF; Tue, 10 Nov 2020 00:15:49 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C4F03A0D82; Tue, 10 Nov 2020 00:15:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6481; q=dns/txt; s=iport; t=1604996149; x=1606205749; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=vnyv8/UJOxuFJ4fv4ljiuwMYw/oUN+DdMPtetAXpkg8=; b=aUlvePR95W1y4delKozEz1WmcKV5PABBV4uKTPF+WZzswXtmZRfOK+kU sbV5THfdrMO9TQZ1qMYDTa8E51du40tWoQ8D4BMxMpCl3E3LvXL7cWDaH e9GDpyrXf+ZZ/NKc5tcGEFFAltgIM8roaCMCcikNyXRRxKXKgWu9vhcaX o=; X-IPAS-Result: =?us-ascii?q?A0AdBQC4S6pffZxdJa1iDg4BAQEBAQEHAQESAQEEBAEBQ?= =?us-ascii?q?IFPgVJRe1kvLogGA41TihWObIFCgREDVAsBAQENAQEjCgIEAQGESgKCEgIlO?= =?us-ascii?q?BMCAwEBAQMCAwEBAQEFAQEBAgEGBBQBAYY8DIVyAQEBAQIBEi4BATcBBAcEA?= =?us-ascii?q?gEIEQQBAQEjCyERHQgCBA4FCBqDBYJVAw4gAQ6iWwKBO4hodIE0gwQBAQWBN?= =?us-ascii?q?wIOQYMFDQuCEAMGgTiCc4JlTocZG4FBP4ERQ4JPPoIbQgICAQEVgR0LBByDS?= =?us-ascii?q?IIskycBiRmKTZBIVAqCbYkNjG2FNYMYihKURpVMiHuCbo4thDICBAIEBQIOA?= =?us-ascii?q?QEFgWshgUMPB3AVgyRQFwINjh8MFxSDOoUUhQRAdAI2AgYKAQEDCXyLBoJGA?= =?us-ascii?q?QE?= IronPort-PHdr: =?us-ascii?q?9a23=3AAsxF6RK9NViZsmaWsNmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeGvK0/iV7VG4jX9qEMh+nXtvXmXmoNqdaEvWsZeZNBHx?= =?us-ascii?q?kClY0NngMmDcLEbC+zLPPjYyEgWsgXUlhj8iK+MFQTFcrjNBXep3So5msUHR?= =?us-ascii?q?PyfQN+OuXyHNvUiMK6n+C/8pHeeUNGnj24NLhzNx6x6w7Ws5ob?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.77,465,1596499200"; d="scan'208";a="585447161" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 Nov 2020 08:15:48 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AA8FmnG003750 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 10 Nov 2020 08:15:48 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 10 Nov 2020 02:15:47 -0600 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 10 Nov 2020 03:15:46 -0500 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 10 Nov 2020 03:15:46 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=P98hAffOzUKFSmLm6k7DISKYkCmFaYDbNfv3aqN851bFUNEEnGL090/MkgB6o1M+7ZPVeNfX696hcxK7PCwxRGY4maow/8jpRVU1XZYzNH0g/d1YwjRWzoTmi+dY2IlgVQc4/gISL7As6C7a+7W1pOgE35wNFWp8LjsvidXxdd2c1Dr/K4I8jgHwlFxBIBE0g4T7HLfb68e19E7S3OQk25NyHhqUcORQ49yI+5xRXcGrR3i6Q1Us2uPXsClJchdkfWgyZ/hwXD15b6ScFdp0DpXfTcg00FNd/V7D17IslNE77gAAPjLnkFhNoCdb8Kt63u4xTYcoJtypEnsjOFYdFQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=vUYsY4yNidTO61sYSHAmK7nfNmUi+0HIwF2dqT3ymxE=; b=ASeEs8csgq6Ks06Jrl1bDcDaDXOEfnN+nf9HLQIY8D8H/U7IV+0m0vV1YniqaaF1U1jgp5hCAPgupdBMM5yxya2DT7w48mhJ2l3XrNS1w/8A3UGUdJ6PGbzd1QIFrHjzYh6Pxp1ZOMXip8u9Uhcct+kZD7ZGmj15LY0rGX9w2FOxpoEWWbLqs/Jqu6z38q0lbYldJDBjtlgyYJOzAJT4kT6A9zo9eMjTugPkenysjj98ohzL5Uppfoy9lTCwanndmZpRsxl7PRM2xHeEX+4vwrVaFy8S0Kb296aFa5SBhOxjdgQDBl6jahN7GcvHS+uafq9L8NUFOSOVFd1Hn8VPzQ== 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=vUYsY4yNidTO61sYSHAmK7nfNmUi+0HIwF2dqT3ymxE=; b=iZI/hDWQjryh4icSyxiLczx+yAMzebBraOkKtmQ4XwO8tUSVhlqkGuZj+Ah4GGLz0bb1iHethnliHBs/RRXR3oDU2yjyWG+/fYnsJek/H4k1FQ2VE9DyVSCsbVlP+tJinKUCFhN8mfq56KZMb8LJm8A8uCOAoxQ2pZFACm6JaqU= Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by CO1PR11MB4833.namprd11.prod.outlook.com (2603:10b6:303:99::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.21; Tue, 10 Nov 2020 08:15:43 +0000 Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::ad88:1b7e:c9f2:b30d]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::ad88:1b7e:c9f2:b30d%6]) with mapi id 15.20.3541.025; Tue, 10 Nov 2020 08:15:43 +0000 From: "Pascal Thubert (pthubert)" To: Benjamin Kaduk CC: Alvaro Retana , The IESG , "draft-ietf-roll-turnon-rfc8138@ietf.org" , Martin Duke , Routing Over Low power and Lossy networks , "roll-chairs@ietf.org" , "Michael Richardson" Thread-Topic: [Roll] Benjamin Kaduk's Discuss on draft-ietf-roll-turnon-rfc8138-14: (with DISCUSS and COMMENT) Thread-Index: AQHWhvbDFnz+ZxCN2kqfSLm4/QQEM6lhafFggADkOACAAVPGAIAAAK+AgAAvlRyACqqkkIAAO8YAgAAzb6aAAAQpAIAAVGSAgAiD2ECAAD3vgIAJd1hAgD+ZLwCAAEVDsA== Date: Tue, 10 Nov 2020 08:15:33 +0000 Deferred-Delivery: Tue, 10 Nov 2020 08:15:24 +0000 Message-ID: References: <20200911162617.GQ89563@kduck.mit.edu> <8F19C753-DCA0-4A32-BA3B-A124B2F7F745@cisco.com> <117497.1600481093@dooku> <20201110033438.GE39170@kduck.mit.edu> In-Reply-To: <20201110033438.GE39170@kduck.mit.edu> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2a01:cb1d:4ec:2200:dc4f:b025:348a:d66a] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 41bb7bee-35c7-44fa-c945-08d88550d16b x-ms-traffictypediagnostic: CO1PR11MB4833: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 8devRXFRkPQTZm6gVAqFHG/PJEeti1opVm3NLhzVs0mvBXCvHYN85lNsqixkWESjudKOTtejFibm3/nqb2fo6T6t8mH4DluDLRuYoTFxsZHtZmPMfaC/9g8QNWUwqVh6ML7Ku6vhZssbLMbyPrvrmcPyEFFASvOkJzOGGTuDz9k4gtB/WYtLEhzs1imTWnfzThiDypML1PMm0vIHHxMGrTavn9w4qFpHm4FqepweMFGmbOc9sWEt/VJfZuxMjSj+hvOkN5My1PBN32VHvjYqe7gXnI4JZUbPxkCFfr227vC7zAawBLz4e9x5QUFjybn8YUkz9a+w2CkhDVHbCxomUgXQOlh/BrHSxTiS6aWYhF8F2LU+TQWQvt3DlO1+DYgQkNpAt/TScd61qHepvTW5Zg== 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:(39860400002)(346002)(396003)(376002)(366004)(136003)(66446008)(6506007)(4326008)(53546011)(83380400001)(9686003)(66476007)(86362001)(66946007)(33656002)(66556008)(64756008)(7696005)(76116006)(2906002)(55016002)(5660300002)(6666004)(966005)(186003)(316002)(478600001)(52536014)(8936002)(71200400001)(54906003)(6916009)(8676002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?gAHcN9o9JCu8RCj7QKrvE+3YTanmDE60sFPFaandm1mEVhyrmqRf/UH/NV?= =?iso-8859-1?Q?21FCV4oSwBZVQHvmmL0HZokgC8LEnwnVZDhTeJlWqCYUAElw5Da+H+w0ti?= =?iso-8859-1?Q?idCh2fyT4+moDPC6FKpsvJfObenM9Oo/efwBAJhW74hWpznN8nIVN8o18i?= =?iso-8859-1?Q?CmUsD4N7chsMsbXVT1j2ssQDNLAy+LyJqm/xdw4Tg9ccjcQLg/pz3ZqPFd?= =?iso-8859-1?Q?hl61ngHNG1gnI2PkrQEtsblXdxl0zSqXPgbvtLhHFAx97KCrf/vdxHXvKH?= =?iso-8859-1?Q?WzTojPHgtGjCwDEh4HxmJK0POcph0t1jdji7iPE2y8yapgCVjyBTiYdvz1?= =?iso-8859-1?Q?zzB/xRsN+ca1vNw9ZWg4gL3jPb4uq5IomapvaerI50mnBgYTYOpdGXnWMY?= =?iso-8859-1?Q?1Aa2pOmitvB997J72+gNMdj8fLRG6Ug6MYAgcTqgUoH8TGAWIHxzsUBIN0?= =?iso-8859-1?Q?GBGkf1eY4CHcYOoCDezVQM9bNH1Rf46JtMWoHsWdQpWkezKqizeQ8ze674?= =?iso-8859-1?Q?ySW0sukJpVbyEXI41wmWCJZfE8oUxqPe4Df0B9bZ+r4BGZhpSY8xkA9LlD?= =?iso-8859-1?Q?QHx4HbC+986YfmC3vKM2ieUU2tJ6iu4TjotkTHLsT3xn3oix9QpS0RN35v?= =?iso-8859-1?Q?TiKcir2RSItuedodq/CbYfs2jbZXYKEdRrWcuw+Dx/NKDB5RajC1f+BDyu?= =?iso-8859-1?Q?Dkb4PPvXmGNY4gEd+jzo1JIagQY0X4464YXKC/PIALNgpshg17NLGzIoca?= =?iso-8859-1?Q?MshRoQRx1gh15uR2J1pHxggHKGW+UOJmLlSRWGdY9JZ00suYqnncWN9rk3?= =?iso-8859-1?Q?c3VEuC+yK/AOYRUP/xjkczXPi8eBF6cLVFN6x+BjE5wKWzpVdN5txELYQx?= =?iso-8859-1?Q?YVFDz2jUaYW2fT05rJNT4OHcyrvxFDRuPmCeswHo8Ez3wO7lnGEymaApok?= =?iso-8859-1?Q?Jnh6VW84x4gElSC15WLonysyArUFaSmxgUN5mn+wtiPEbhC9q8VFLQ=3D?= =?iso-8859-1?Q?=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB4881.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 41bb7bee-35c7-44fa-c945-08d88550d16b X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Nov 2020 08:15:42.9160 (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: T0Q7eVJjs0MoKn/RbOqiRYH578E3FVhlD8r/sH5oqKXK+RCROXY9YY/E9lwjhTKNR6RGna0nkcqNFto3MuipXQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR11MB4833 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf-roll-turnon-rfc8138-14: (with DISCUSS and COMMENT) 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, 10 Nov 2020 08:15:52 -0000 Hello Benjamin: =20 > That said, and my apologies for a hazy memory coming back to this after a > couple months, in a year or N from now when mopex is finalized, how will > someone looking at mopex know to use RFC8138 on links where 6LoWPAN > Header Compression applies (and not use it otherwise)? We are claiming i= n > the -14 of this document that: >=20 > For a MOP value of 7, [RFC8138] MUST be > used on Links where 6LoWPAN Header Compression [RFC6282] applies and > MUST NOT be used otherwise. >=20 > but I am not sure (or have forgotten) what the chain of references is sup= posed > to lead someone who is implementing RPL plus MOP=3D7 to the requirement t= o > use RFC 8138. I don't think we should just rely on the mopex text to do = so, > since we are trying to impose the requirement with this document (which > predates mopex by some time), and there's not anything (other than our > collective memories, of course) requiring mopex to remain consistent with > that requirement. Just to be clear for the other readers: MOPext does not exist as a normativ= e reference for this work. The only field that exists is the MOP field in the DIO and that field is 3 = bits long, values 0..7. The normative reference that you are after is https://datatracker.ietf.org/= doc/draft-ietf-roll-useofrplinfo/ This is the spec that updates RPL and changes the IANA registry to indicate= that 7 is not a MOP. There we have: " ... Anticipating future work to revise RPL relating to how the LLN and DODAG is configured, this document changes the interpretation of the [dodagcfg] Registry to be limited to Mode-of-Operation (MOP) specific. The MOP is described in [RFC6550] section 6.3.1. The Options Flags Registry is renamed, and applies to MOP values zero (0) to six (6) only, leaving the flags reserved for MOP value seven (7). In addition, this document reserves MOP value 7 for future expansion. ... 11.3. Change MOP value 7 to Reserved This document changes the allocation status of the Mode of Operation (MOP) [ianamop] from Unassigned to Reserved. This change is in support of future work related to capabilities. " So basically we tell the implementations from now on to test if MOP is 7, a= nd in that case, the Options Flags are undefined. In other words, if MOP is= 7, the stack must not use the option flags as if the MOP was <7. In fact, = 7 is no more a MOP value but a reserved thingy that can be overloaded in th= e future. And yes, we intend to do just that in MOPExt. Until that happens, implementations are at a loss if they encounter when a = MOP field that is all ones. So we need to give them instructions to cope wi= th the situation. This draft derives whether to use RFC 8138 from whether t= he 6LoWPAN compression applies to the link or not. This will stay true forever, unless another RFC amends it. When/if that hap= pens, the new RFC will have to consider backward compatibility with a legac= y implementation that implements the above.=20 Note that this line of thought applies to 3 flags, defined respectively in: - https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/ - https://datatracker.ietf.org/doc/draft-ietf-roll-turnon-rfc8138/ - https://datatracker.ietf.org/doc/draft-ietf-roll-unaware-leaves/ Keep safe! Pascal >=20 > Thanks, >=20 > Ben >=20 > On Wed, Sep 30, 2020 at 04:25:10PM +0000, Pascal Thubert (pthubert) wrote= : > > Hello Alvaro > > > > I uploaded both draft with the suggested update, please see > > > > https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-turnon-rfc8138-17= . > > txt > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-unaware-leaves-21.t= x > > t > > > > Keep safe > > > > Pascal > > > > > -----Original Message----- > > > From: Alvaro Retana > > > Sent: jeudi 24 septembre 2020 17:49 > > > To: Pascal Thubert (pthubert) > > > Cc: Benjamin Kaduk ; The IESG ; > > > draft-ietf- roll-turnon-rfc8138@ietf.org; Martin Duke > > > ; Routing Over Low power and Lossy networks > > > ; roll- chairs@ietf.org; Michael Richardson > > > > > > Subject: Re: [Roll] Benjamin Kaduk's Discuss on > > > draft-ietf-roll-turnon-rfc8138- > > > 14: (with DISCUSS and COMMENT) > > > > > > On September 24, 2020 at 8:13:09 AM, Pascal Thubert wrote: > > > > > > > > > Pascal: > > > > > > Hi! > > > > > > > Following the meeting last Monday and subsequent the update of > > > > useofrplinfo by Michael (thanks Michael!) I published a new > > > > version of the turnon RFC > > > > 8138 draft. > > > > > > > > The major changes are > > > > - removed the formal update to RFC 6550 > > > > - refer to useofrplinfo as the justification why the flag is not > > > > defined for MOP 7 > > > > - defined the operation in MOP 7 as compression on iff the Link > > > > uses 6LoPWAN HC. > > > > > > Thanks for these changes. > > > > > > Because we have to cycle useofrplinfo back through (when the WG is > > > done with it), I asked Ben/Martin to wait for that before coming > > > back to this document. =A0It'll make it easier than tracking multiple > > > changes. :-) > > > > > > > > > OTOH, I do have comments on the recent change: > > > > > > OLD> > > > =A0 =A0Section 4.3 of [USEofRPLinfo] updates [RFC6550] to indicate th= at > > > the > > > =A0 =A0definition of the Flags applies to Mode of Operation (MOP) val= ues > > > =A0 =A0zero (0) to six (6) only, leaving the flags reserved for MOP > > > value > > > =A0 =A0seven (7). =A0For a MOP value of 7, the bit in position 2 is > > > considered > > > =A0 =A0unallocated and [RFC8138] MUST be used on Links where 6LoWPAN > > > Header > > > =A0 =A0Compression [RFC6282] applies and MUST NOT be used otherwise. > > > > > > NEW> > > > > > > =A0 =A0Section 4.3 of [USEofRPLinfo] updates [RFC6550] to indicate th= at > > > the > > > =A0 =A0definition of the Flags applies to Mode of Operation (MOP) val= ues > > > zero (0) > > > =A0 =A0to six (6) only. =A0For a MOP value of 7, [RFC8138] MUST be us= ed on > > > Links > > > =A0 =A0where 6LoWPAN Header Compression [RFC6282] applies and MUST NO= T > > > be used > > > =A0 =A0otherwise. > > > > > > > > > Thanks! > > > > > > Alvaro. From nobody Tue Nov 10 04:51:49 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F41A3A0D51; Tue, 10 Nov 2020 04:51:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 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_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=JMLXUVj4; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=T8o9jzr0 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 uYtNalx_OQ-E; Tue, 10 Nov 2020 04:51:46 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C9403A0D52; Tue, 10 Nov 2020 04:51:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5276; q=dns/txt; s=iport; t=1605012706; x=1606222306; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=falsak9I7DC4C5iup2ehC0htcvj9hZsqryKQ13DEEnQ=; b=JMLXUVj4BqSC3jDEELKDUz88jiNGZQUCH3nXt1wqORtStPlYM2UTDF3c BhzM24xoHZeAGvnCP1JF1pzsJkVkvvYk7zJ5DPnKhiGI7X3ibeTgAS/Rx WGVu9xwELMbmbetC9x5WtKhMjez7CXUZHtuV4vvK3T9CAAOPJ/l0MOZHC M=; X-IPAS-Result: =?us-ascii?q?A0C6HgCxi6pffYYNJK1iHAECPQEEBAEEAQcBFoFRgTwCE?= =?us-ascii?q?lGBVC8uhD2DSQONVYoVjm2BQoERA1QLAQEBDQEBLQIEAQGESgIXgXsCJTgTA?= =?us-ascii?q?gMBAQEDAgMBAQEBBQEBAQIBBgQUAQGGPAyFcgEBAQQSEREMAQElEgELBAIBB?= =?us-ascii?q?gIOAwQBAQMCJgICAh8RFQgIAgQBDQUIGoVaAy4BkimQagKBO4hodoEygwQBA?= =?us-ascii?q?QWFEQ0LghAJgQ4oAgEBgnGCZU5ChlcbgUE/gRFDgk8+ghuBaRELIIMVM4Isk?= =?us-ascii?q?2ajc1QKgm2VfYU1gxiKFZRHk1GNaI4vhDICBAIEBQIOAQEFgWshgVlwFYMkU?= =?us-ascii?q?BcCDY4rF4NOilh0OAIGAQkBAQMJfIsGgkYBAQ?= IronPort-PHdr: =?us-ascii?q?9a23=3A8kEChRfLFTB2DApWPqNDJdljlGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwaQAdfU7vtFj6zdtKWzEWAD4JPUtncEfdQMUh?= =?us-ascii?q?IekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsutaFjbo3n05jkXSV?= =?us-ascii?q?3zMANvLbHzHYjfx828y+G1/cjVZANFzDqwaL9/NlO4twLU48IXmoBlbK02z0?= =?us-ascii?q?jE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.77,466,1596499200"; d="scan'208";a="622399985" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 Nov 2020 12:51:45 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AACpjAF031258 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 10 Nov 2020 12:51:45 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 10 Nov 2020 06:51:45 -0600 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 10 Nov 2020 07:51:44 -0500 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 10 Nov 2020 07:51:44 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=MoL38luCP89zUXQfo+QIaJsL0UGQG4IOWknxgft2fYXr4AKa1MSf66Gf5Qy76/Q4+ToHVoAacR1JeO+GOVSHIVVJw98LerMmDaB53RXMHaL5KEaRwU6VNYyYvO4WLxtInPuNp2kGfpHDyUSqisfJwGZo8yAnZFwtV1guE3TRggS/fDqoHEXhmeZNUN1Ofh2FGNe4hZnhnS7ngVxcWquAX08PUfV0OwA4IGE+xKQzYWUPbMKU/9ozHlW9i18uNQd/jgfTaQQOXhIK15xwBKiAtL6ZPa+WgkvMQhOTdZR0to3Qxjwe9isyvNSVBkPVihakzyPcQmUP/yzNLftZBposAw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=falsak9I7DC4C5iup2ehC0htcvj9hZsqryKQ13DEEnQ=; b=GvSFK5Ll3VEzFv2Ew9Fq/HP6wqaIaYO64GH2LQJtukNe0mkvtmV3GTxbB3k5cDJa/BMXwbHWAiIA/Wx6zhEkGoBZsml2/XpR9lY27iIOuWUxKOC17rclXPWgSEc71hX9N9QlmsD6UT/U23exNiIy87AqkVtpI6/SpBkx6IETl/M/bn5R/0wXDRe8l6J6r5/BthfaSSYc4cr2qvtBx5EVOXdPqfnPyU1L7BuVIGWl97UZg00aglcuyvdONSRlJUHdYuyfGgdZa17e1KeiSxsefihq6j8gUjKgMp3EnYRLGaPrhSnS1bkEK6Ay6id3ZS4JHoAb39eIZwsIqOl3bYbTZA== 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=falsak9I7DC4C5iup2ehC0htcvj9hZsqryKQ13DEEnQ=; b=T8o9jzr0pxUVisVYGqpw4Ik9/X8CICd1/pxs7tiBbV4dYAVGNqVc142H3bsq5zfmUr2vmNnVUqIwbal3akDT4y/UKq970FLD1vQ86yMn2PqenUp/NmYASxy9VPum/MWYlDdWGbFpXFpx715W9Uq05fFZpwARYBXXRcCsQ/y6ZiI= Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by MWHPR11MB0029.namprd11.prod.outlook.com (2603:10b6:301:67::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.24; Tue, 10 Nov 2020 12:51:43 +0000 Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::ad88:1b7e:c9f2:b30d]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::ad88:1b7e:c9f2:b30d%6]) with mapi id 15.20.3541.025; Tue, 10 Nov 2020 12:51:43 +0000 From: "Pascal Thubert (pthubert)" To: Alvaro Retana , "draft-ietf-roll-useofrplinfo@ietf.org" CC: Peter van der Stok , "roll-chairs@ietf.org" , Routing Over Low power and Lossy networks Thread-Topic: AD Review of draft-ietf-roll-useofrplinfo-41 Thread-Index: AQHWtsopWPGpKPyXqka248pIzpGi46nBUOXw Date: Tue, 10 Nov 2020 12:51:29 +0000 Deferred-Delivery: Tue, 10 Nov 2020 12:51:25 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2a01:cb1d:4ec:2200:e06f:f44a:8c4f:831d] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 53e7bcfa-6af3-4dd3-a324-08d88577600e x-ms-traffictypediagnostic: MWHPR11MB0029: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: GR8kgkud3lE8GkiiTNNP7CGLWQFEQsSad+XxZNLO2bHu92xE8yzwmzowziRKXfDdFBPWcS6fCbWW1l7r+yC68/G4mJ0W7mE3A5JHis62TJr9drIBUrCYTXx+I3WiZUZwdcO/cujMk3fyMcRDShcS13AoS+o2zzqyhIpiZirozQMppKWjeKrepU/zj9gf6D/UrwiEZwyRPy10BW/Q18LCWPw3+ZQWdcJfWv6FDe9JWJ72AhL7LbvIp+ZkBpYPjzvAn4mecN5HGgYDi2HyZLcn3EKW++UEe84X6JKArJ2hvoPVN00jZzKO9FDIwY/BsTTTEecE7wYoQ9Wx1xNZq+Qycw== 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:(346002)(376002)(396003)(136003)(39860400002)(366004)(5660300002)(7696005)(2906002)(8936002)(71200400001)(4326008)(66946007)(76116006)(66476007)(83380400001)(9686003)(6506007)(66556008)(64756008)(110136005)(54906003)(33656002)(316002)(8676002)(186003)(6666004)(52536014)(53546011)(478600001)(66446008)(86362001)(55016002)(66574015); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?WGhVLzF1Z2tPQWlPRVd5QXV3dVA4ODlsc1pXREVjVm1mZHRadHNIRUxtc1Ur?= =?utf-8?B?ZTI1SmwxZitRNURZVlR6Y3BYeHJ3NXJkQmJYRzFIR29HRWlDb2t0WjRsS0Ra?= =?utf-8?B?TmdVWFo3ZStlSmJOQ2ljQ2trdWZLRjVuaXRROEh3dzBMa0s2VUREa0s5RkxL?= =?utf-8?B?aGZnbWVQdmp3akJVcVR5WkhNUFVzblU5WWM5cW5sWUU3YVpCS2JpUzVHQ0tK?= =?utf-8?B?cU82eDFFZ0JjRW9yS1Vydi9jWFhIQzV6eXBVMlgrOXpkWW1zd1IyaUJaTUZP?= =?utf-8?B?OGJ1RGNSL01EQSt4RHNSVUUwNzNndlc5aFVCQVNjcUtyejVNcWFSQ1dsNmhV?= =?utf-8?B?cjVMVGQrc0t6SzB6THdydEpZdW9UK0pVcFVnUGFMRVI3V2xWYmhBc2gvTFR3?= =?utf-8?B?eTQyVHpZV1RERGFIZXpxVFhVQzNhOUYvNjg3bkVOL2dRLzJyVnBYWnp2QVlP?= =?utf-8?B?alhXc0FrYW9pd2huZjlTd3BjdWlYRGFiRTh3L2tPWnBNK3VwYUF4Q2ZKNGFI?= =?utf-8?B?R1dESE5RME1FTUZjdG44UWhmSjFwVWluZVNFT21Iam1mTTVvYzd0MFg1emFC?= =?utf-8?B?L0NsN1VWMTd4TlNBanlQZGF2QzhWQlQ0Ny9UZ2F3VWJYWjJGMFVjZUh5ZHlw?= =?utf-8?B?MzdaaUFZeUxaYi9pdElvbjBaRDc4dDM5cFVMdDZzSWJpdWZISVNqVWRzeFVN?= =?utf-8?B?bGJqeDY3N2dYLzhObURiYVNyZVV0NmpVWW5XN2FSRkJ3KzUxTG9wUVFrY1Zu?= =?utf-8?B?UE93VHZzQVYwS2JROEZjVmZCWXJjK0Q0L2FNRmxqYURkUDdwUXh2MGdPVDF1?= =?utf-8?B?NFBQUmIrZFRiOUxkd1RFaVE3V0tqbzVUNmlNUW5kVllOeGZkbThSYlNEZlNy?= =?utf-8?B?R2NJNkoxdDVOK1FLbTZ2LzgrRjFybm9oeUExck4rVUt3UktrRWlsUTN0NEdj?= =?utf-8?B?VTBVOWkzVis1WXB5c1lQWGovcVRTU1h5dzlvNDRlbS9tNzVEQ2VYS3B5VjFW?= =?utf-8?B?c0JnMTBHZnU1WEtsaHM5cm1DajgxaEtMWXpCNWFKMUp0NHU0WDRVWXhNWEk3?= =?utf-8?B?Rnc2Q2JrRWc5N25raHp0bDBCZ1lZUTk0R252RFNRYUZpeGRqSmVLZEsweXRy?= =?utf-8?B?SXV5N1hJNkRNMjRFMnBUUDV1bXVIRmhhMGc0Q3dRck9FUGJQZlhzK2dnaytN?= =?utf-8?B?SlgyQk5vK0ZjaEhDTjN5Z0EyNnhMb0xYS2czVVR6S1RvNmIrSHRmbTYxWWZX?= =?utf-8?B?eXFPY0lJNnVKa1VjcGJIVWF0Nm5JVlZ4d2tVazZJVXo2KzBKQT09?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB4881.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 53e7bcfa-6af3-4dd3-a324-08d88577600e X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Nov 2020 12:51:43.1840 (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: Fok8k2qj4VRP+Y9IJBL2AA6nukSz7olxcuJvzOchTp7p2UkMwVyn75/AHEOCjEmn1CupNH8luTbc4XknBxRTiQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB0029 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: Re: [Roll] AD Review of draft-ietf-roll-useofrplinfo-41 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, 10 Nov 2020 12:51:49 -0000 SGVsbG8gQWx2YXJvIGFuZCBhbGwNCg0KSnVzdCB0byBwb2ludCBvdXQgdGhhdCBkdXJpbmcgQWx2 YXJvJ3MgcmV2aWV3IG9mIHVuYXdhcmUgbGVhdmVzLCB3ZSBhbHNvIG1lbnRpb25lZCB0aGUgc2Vj dXJpdHkgYXNwZWN0IG9mIGluamVjdGluZyBhbiBSUEkuDQoNClRoZXJlIGFyZSAzIGNhc2VzOg0K LSB0aGUgbGVhZiBpcyBhbiBleHRlcm5hbCByb3V0ZXIgdGhhdCBwYXNzZXMgYSBwYWNrZXQgdGhh dCBpdCBkaWQgbm90IGdlbmVyYXRlIGFuZCB0aGF0IGNhcnJpZXMgYW4gdW5yZWxhdGVkIFJQSSAt IHdlIG5lZWQgdG8gcmV3cml0ZSBpdA0KLSB0aGUgbGVhZiBpcyBhbiBhdHRhY2tlciB0aGF0IHRy aWVzIHRvIGluamVjdCB0cmFmZmljIGluIGEgcHJvdGVjdGVkIGluc3RhbmNlIC0gd2UgbmVlZCB0 byByZXdyaXRlIG91dCBvciBkcm9wDQotIHRoZSBsZWFmIGlzIGF3YXJlIG9mIHRoZSBSUEwgaW5z dGFuY2UgYW5kIHBhc3NlcyBhIGNvcnJlY3QgUlBJIC0gdG8gbWFrZSB0aGUgZGlmZmVyZW5jZSwg dGhlIDZMUiBuZWVkcyBhIGNvbmZpZ3VyYXRpb24gdGhhdCBhbGxvd3MgdGhhdCBsZWFmIHRvIGlu amVjdCBpbiB0aGF0IGluc3RhbmNlLg0KDQpUaGlzIGlzIHdoeSB3ZSBlbmRlZCB1cCBTSE9VTERp bmcgdGhlIHJld3JpdGUuIERvIHdlIG5lZWQgbW9yZSB0ZXh0IGxpa2UgdGhlIGFib2NlIGluIHRo ZSBzZWN1cml0eSBzZWN0aW9uPw0KDQpLZWVwIHNhZmU7DQoNClBhc2NhbA0KDQo+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEFsdmFybyBSZXRhbmEgPGFyZXRhbmEuaWV0ZkBn bWFpbC5jb20+DQo+IFNlbnQ6IGx1bmRpIDkgbm92ZW1icmUgMjAyMCAxOTo1Nw0KPiBUbzogZHJh ZnQtaWV0Zi1yb2xsLXVzZW9mcnBsaW5mb0BpZXRmLm9yZw0KPiBDYzogUGV0ZXIgdmFuIGRlciBT dG9rIDxjb25zdWx0YW5jeUB2YW5kZXJzdG9rLm9yZz47IHJvbGwtY2hhaXJzQGlldGYub3JnOw0K PiBSb3V0aW5nIE92ZXIgTG93IHBvd2VyIGFuZCBMb3NzeSBuZXR3b3JrcyA8cm9sbEBpZXRmLm9y Zz4NCj4gU3ViamVjdDogQUQgUmV2aWV3IG9mIGRyYWZ0LWlldGYtcm9sbC11c2VvZnJwbGluZm8t NDENCj4gDQo+IERlYXIgYXV0aG9yczoNCj4gDQo+IFRoYW5rIHlvdSBmb3IgYWxsIHRoZSB3b3Jr IG9uIHRoaXMgZHJhZnQuDQo+IA0KPiBJIGhhdmUgYSBjb3VwbGUgb2YgY29tbWVudHMgaW4tbGlu ZSAtLSBub3RoaW5nIGhhcmQgdG8gYWRkcmVzcy4gwqBJIG1vc3RseQ0KPiBsb29rZWQgYXQgdGhl IGRpZmZzICh3cnQgLTMxKSBhbmQgc28gbXkgY29tbWVudHMgYXJlIGp1c3Qgb24gbmV3IHRleHQu DQo+IA0KPiBJIHdhbnQgdG8gcHJvZ3Jlc3MgdGhpcyBkcmFmdCB3aXRoIHVuYXdhcmUtbGVhdmVz IC0tIHRvIG1ha2UgaXQgZWFzaWVyIG9uIHRoZQ0KPiBJRVNHLiDCoEknbGwgc3RhcnQgdGhlIElF VEYgTEMgd2hlbiBib3RoIGFyZSByZWFkeS4NCj4gDQo+IFRoYW5rcyENCj4gDQo+IEFsdmFyby4N Cj4gDQo+IA0KPiA+RnJvbSBpZG5pdHM6DQo+IA0KPiDCoCAqKiBUaGUgYWJzdHJhY3Qgc2VlbXMg dG8gY29udGFpbiByZWZlcmVuY2VzIChbUkZDODEzOF0pLCB3aGljaCBpdA0KPiDCoCDCoCDCoHNo b3VsZG4ndC4gwqBQbGVhc2UgcmVwbGFjZSB0aG9zZSB3aXRoIHN0cmFpZ2h0IHRleHR1YWwgbWVu dGlvbnMgb2YgdGhlDQo+IMKgIMKgIMKgZG9jdW1lbnRzIGluIHF1ZXN0aW9uLg0KPiANCj4gDQo+ IA0KPiBbTGluZSBudW1iZXJzIGZyb20gaWRuaXRzLl0NCj4gDQo+IA0KPiAuLi4NCj4gNjYJIMKg IDQuIMKgVXBkYXRlcyB0byBSRkM2NTUzLCBSRkM2NTUwIGFuZCBSRkM4MTM4IC4gLiAuIC4gLiAu IC4gLiAuIC4gLiDCoCA3DQo+IDY3CSDCoCDCoCA0LjEuIMKgVXBkYXRlcyB0byBSRkM2NTUwOiBB ZHZlcnRpc2luZyBFeHRlcm5hbCBSb3V0ZXMgd2l0aCBOb24tDQo+IDY4CSDCoCDCoCDCoCDCoCDC oCBTdG9yaW5nIE1vZGUgU2lnbmFsaW5nLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAu IC4gwqAgNw0KPiA2OQkgwqAgwqAgNC4yLiDCoFVwZGF0ZXMgdG8gUkZDNjU1MzogSW5kaWNhdGlu ZyB0aGUgbmV3IFJQSSBPcHRpb24gVHlwZS4gLiDCoCA4DQo+IDcwCSDCoCDCoCA0LjMuIMKgVXBk YXRlcyB0byBSRkM2NTUwOg0KPiA3MQkgwqAgwqAgwqAgwqAgwqAgQ29uZmlndXJhdGlvbiBPcHRp b25zIGFuZCBNb2RlDQo+IDcyCSDCoCDCoCDCoCDCoCDCoCBvZiBPcGVyYXRpb24gwqAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIC4gLiAuIMKgMTENCj4gNzMJIMKgIMKgIDQu NC4gwqBVcGRhdGVzIHRvIFJGQzY1NTA6IEluZGljYXRpbmcgdGhlIG5ldyBSUEkgaW4gdGhlDQo+ IDc0CSDCoCDCoCDCoCDCoCDCoCBET0RBRyBDb25maWd1cmF0aW9uIG9wdGlvbiBGbGFnLiDCoC4g LiAuIC4gLiAuIC4gLiAuIC4gLiAuIMKgMTINCj4gNzUJIMKgIMKgIDQuNS4gwqBVcGRhdGVzIHRv IFJGQzgxMzg6IEluZGljYXRpbmcgdGhlIHdheSB0byBkZWNvbXByZXNzIHdpdGgNCj4gNzYJIMKg IMKgIMKgIMKgIMKgIHRoZSBuZXcgUlBJIE9wdGlvbiBUeXBlLiDCoC4gLiAuIC4gLiAuIC4gLiAu IC4gLiAuIC4gLiAuIC4gwqAxMw0KPiANCj4gW25pdCAtIG5vIGFjdGlvbiBuZWVkZWQsIGp1c3Qg YSBzdWdnZXN0aW9uXSBHcm91cCBhbGwgdGhlIHVwZGF0ZXMgdG8NCj4gcmZjNjU1MDogZWl0aGVy IGluIG9uZSBzdWItc2VjdGlvbiBvciBpbiBjb25zZWN1dGl2ZSBvbmVzLg0KPiANCj4gDQo+IC4u Lg0KPiA0OTMJNC4zLiDCoFVwZGF0ZXMgdG8gUkZDNjU1MDogQ29uZmlndXJhdGlvbiBPcHRpb25z IGFuZCBNb2RlIG9mDQo+IE9wZXJhdGlvbg0KPiANCj4gNDk1CSDCoCBSRkM2NTUwIHNlY3Rpb24g Ni43LjYgZGVzY3JpYmVzIHRoZSBET0RBRyBDb25maWd1cmF0aW9uDQo+IE9wdGlvbi4gwqBJbg0K PiA0OTYJIMKgIHRoaXMgb3B0aW9uIGFyZSBhIHNlcmllcyBvZiBGbGFncyBpbiB0aGUgZmlyc3Qg b2N0ZXQgb2YgdGhlIHBheWxvYWQuDQo+IDQ5NwkgwqAgVGhlc2UgZmxhZ3MgYXJlIGRlc2NyaWJl ZCBieSB0aGUgRE9EQUcgQ29uZmlndXJhdGlvbiBPcHRpb24gRmxhZ3MNCj4gNDk4CSDCoCByZWdp c3RyeSBbZG9kYWdjZmddLCBpbiBzZWN0aW9uIDIwLjE0IG9mIFJGQzY1NTAuDQo+IA0KPiA1MDAJ IMKgIEFudGljaXBhdGluZyBmdXR1cmUgd29yayB0byByZXZpc2UgUlBMIHJlbGF0aW5nIHRvIGhv dyB0aGUgTExOIGFuZA0KPiA1MDEJIMKgIERPREFHIGlzIGNvbmZpZ3VyZWQsIHRoaXMgZG9jdW1l bnQgY2hhbmdlcyB0aGUgaW50ZXJwcmV0YXRpb24gb2YNCj4gdGhlDQo+IDUwMgkgwqAgW2RvZGFn Y2ZnXSBSZWdpc3RyeSB0byBiZSBsaW1pdGVkIHRvIE1vZGUtb2YtT3BlcmF0aW9uIChNT1ApDQo+ IDUwMwkgwqAgc3BlY2lmaWMuIMKgVGhlIE1PUCBpcyBkZXNjcmliZWQgaW4gW1JGQzY1NTBdIHNl Y3Rpb24gNi4zLjEuIMKgVGhlDQo+IDUwNAkgwqAgT3B0aW9ucyBGbGFncyBSZWdpc3RyeSBpcyBy ZW5hbWVkLCBhbmQgYXBwbGllcyB0byBNT1AgdmFsdWVzIHplcm8NCj4gKDApDQo+IDUwNQkgwqAg dG8gc2l4ICg2KSBvbmx5LCBsZWF2aW5nIHRoZSBmbGFncyByZXNlcnZlZCBmb3IgTU9QIHZhbHVl IHNldmVuICg3KS4NCj4gDQo+IDUwNwkgwqAgSW4gYWRkaXRpb24sIHRoaXMgZG9jdW1lbnQgcmVz ZXJ2ZXMgTU9QIHZhbHVlIDcgZm9yIGZ1dHVyZQ0KPiBleHBhbnNpb24uDQo+IA0KPiBbXSBORVc+ DQo+IMKgIMKgU2VjdGlvbiA2LjcuNiBvZiBSRkM2NTUwIGRlc2NyaWJlcyB0aGUgRE9EQUcgQ29u ZmlndXJhdGlvbiBPcHRpb24gYXMNCj4gwqAgwqBjb250YWluaW5nIGEgc2VyaWVzIG9mIEZsYWdz IGluIHRoZSBmaXJzdCBvY3RldCBvZiB0aGUgcGF5bG9hZA0K From nobody Tue Nov 10 08:39:04 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D3FE3A0A42; Tue, 10 Nov 2020 08:39:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, 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 OL7bCo0TjOGr; Tue, 10 Nov 2020 08:39:00 -0800 (PST) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (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 BB10E3A0A2B; Tue, 10 Nov 2020 08:38:59 -0800 (PST) Received: by mail-ed1-x531.google.com with SMTP id b9so13426416edu.10; Tue, 10 Nov 2020 08:38:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=QLXm3rwACW+POKeKPFNtMFPWH8PaPmx7rGe2DOTYG8M=; b=RtoTSFtj2z/zCd7z4uK8ryqsoHoiwM9u2ofNpHEp5FRSFptfCs4Cq/74rwbgNA1ONz 4a1kqvou0Bq3ai+1ccrpyBK1kJ29yRsokMMDMHHC56K9T5XfXkrYkseXkfok1gf2OODL 9QuG3unfLmu0+aB/ZjFkIrC7esa3+mVMFlqTMMqgg/2ODybLTtzHSbjyENl/Ob2Rc+LZ iKaSuO97xU6QJweMgrlBbPHyytY0WB9UzwSyr5Z9RezmI/QUqK+0z+wRbYEFNLD0Pnbf lo0tuH4udpjhcWzWBifqY/gmsAHY8ZZ7JoaqxNV5r01qYh1Dpry717ixAEGG8EDJuOAt ecbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=QLXm3rwACW+POKeKPFNtMFPWH8PaPmx7rGe2DOTYG8M=; b=YVUYZmPitoGt0bduhJWpDCoJgl5UInc5SGw7picqTS+ckTrbcpMh7Wmo8IhYNEltSe Y1x1ko3mRB3L8jrm/bNc/P3Dk3CRawtuiJ0aUPxb057sThVp56U8q7bRkwbZaIz6shDg Qapzi9NTLtXjiUmN1/TCKRQSeditQKXq/ZLh0nNXxV5my6G/A8y3+uoTEGKk5UjJNmO/ 2Km2pXoq43tGR28yCyRg3XpzzRWL61c7IKhdD20m4ZoXzBaubiWEA972y6p0Q5muVUF3 ynOstSKC0H7pKHc5J95ognq8BD8Fpe3IUgcv4D/E/QLX3PpYPwC2JAyJRJKEj8Hd7JWY h6lA== X-Gm-Message-State: AOAM530xgUtdGY05piFx6nKXqf9kRzRYgZjEau8VTes91gwaxchFB7XY FicYHu99q7DNhB6b3L11en9moTDmfvYNdgiLrGIL8cZhNg2sFw== X-Google-Smtp-Source: ABdhPJweKepc0PmxVWojgWY7/Ub+AYJZp2zLieR21HcroYbVm/fc7Uss7ntVnsxTVk3+8CPodmDEAG/RfvlxqGUHOoE= X-Received: by 2002:a05:6402:b8e:: with SMTP id cf14mr20992645edb.86.1605026338143; Tue, 10 Nov 2020 08:38:58 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Tue, 10 Nov 2020 08:38:57 -0800 From: Alvaro Retana In-Reply-To: References: MIME-Version: 1.0 Date: Tue, 10 Nov 2020 08:38:57 -0800 Message-ID: To: "Pascal Thubert (pthubert)" , "draft-ietf-roll-useofrplinfo@ietf.org" Cc: "roll-chairs@ietf.org" , Routing Over Low power and Lossy networks , Peter van der Stok Content-Type: multipart/alternative; boundary="000000000000bd9c7b05b3c35083" Archived-At: Subject: Re: [Roll] AD Review of draft-ietf-roll-useofrplinfo-41 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, 10 Nov 2020 16:39:02 -0000 --000000000000bd9c7b05b3c35083 Content-Type: text/plain; charset="UTF-8" Just a quick note: the second case can also be due to a misconfiguration, or maybe even old Instance ID at the RUL. IOW, the general case of the instant not existing is not always due to an attack. Thanks! Alvaro. On November 10, 2020 at 7:51:46 AM, Pascal Thubert (pthubert) ( pthubert@cisco.com) wrote: Hello Alvaro and all Just to point out that during Alvaro's review of unaware leaves, we also mentioned the security aspect of injecting an RPI. There are 3 cases: - the leaf is an external router that passes a packet that it did not generate and that carries an unrelated RPI - we need to rewrite it - the leaf is an attacker that tries to inject traffic in a protected instance - we need to rewrite out or drop - the leaf is aware of the RPL instance and passes a correct RPI - to make the difference, the 6LR needs a configuration that allows that leaf to inject in that instance. This is why we ended up SHOULDing the rewrite. Do we need more text like the aboce in the security section? Keep safe; Pascal > -----Original Message----- > From: Alvaro Retana > Sent: lundi 9 novembre 2020 19:57 > To: draft-ietf-roll-useofrplinfo@ietf.org > Cc: Peter van der Stok ; roll-chairs@ietf.org; > Routing Over Low power and Lossy networks > Subject: AD Review of draft-ietf-roll-useofrplinfo-41 > > Dear authors: > > Thank you for all the work on this draft. > > I have a couple of comments in-line -- nothing hard to address. I mostly > looked at the diffs (wrt -31) and so my comments are just on new text. > > I want to progress this draft with unaware-leaves -- to make it easier on the > IESG. I'll start the IETF LC when both are ready. > > Thanks! > > Alvaro. > > > >From idnits: > > ** The abstract seems to contain references ([RFC8138]), which it > shouldn't. Please replace those with straight textual mentions of the > documents in question. > > > > [Line numbers from idnits.] > > > ... > 66 4. Updates to RFC6553, RFC6550 and RFC8138 . . . . . . . . . . . 7 > 67 4.1. Updates to RFC6550: Advertising External Routes with Non- > 68 Storing Mode Signaling. . . . . . . . . . . . . . . . . . 7 > 69 4.2. Updates to RFC6553: Indicating the new RPI Option Type. . 8 > 70 4.3. Updates to RFC6550: > 71 Configuration Options and Mode > 72 of Operation . . . . . . . . . . . . . . . . . . . . . . 11 > 73 4.4. Updates to RFC6550: Indicating the new RPI in the > 74 DODAG Configuration option Flag. . . . . . . . . . . . . 12 > 75 4.5. Updates to RFC8138: Indicating the way to decompress with > 76 the new RPI Option Type. . . . . . . . . . . . . . . . . 13 > > [nit - no action needed, just a suggestion] Group all the updates to > rfc6550: either in one sub-section or in consecutive ones. > > > ... > 493 4.3. Updates to RFC6550: Configuration Options and Mode of > Operation > > 495 RFC6550 section 6.7.6 describes the DODAG Configuration > Option. In > 496 this option are a series of Flags in the first octet of the payload. > 497 These flags are described by the DODAG Configuration Option Flags > 498 registry [dodagcfg], in section 20.14 of RFC6550. > > 500 Anticipating future work to revise RPL relating to how the LLN and > 501 DODAG is configured, this document changes the interpretation of > the > 502 [dodagcfg] Registry to be limited to Mode-of-Operation (MOP) > 503 specific. The MOP is described in [RFC6550] section 6.3.1. The > 504 Options Flags Registry is renamed, and applies to MOP values zero > (0) > 505 to six (6) only, leaving the flags reserved for MOP value seven (7). > > 507 In addition, this document reserves MOP value 7 for future > expansion. > > [] NEW> > Section 6.7.6 of RFC6550 describes the DODAG Configuration Option as > containing a series of Flags in the first octet of the payload --000000000000bd9c7b05b3c35083 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Just a quick note: =C2=A0the second case can als= o be due to a misconfiguration, or maybe even old Instance ID at the RUL.= =C2=A0 IOW, the general case of the instant not existing is not always due = to an attack.

Thank= s!

Alvaro.

On November 10, 2020 at 7:51:46 AM, Pascal Thuber= t (pthubert) (pthubert@cisco.com)= wrote:

Hello Alvaro and all

Just to point out that during Alvaro's review of unaware leaves, we= also mentioned the security aspect of injecting an RPI.

There are 3 cases:
- the leaf is an external router that passes a packet that it did not g= enerate and that carries an unrelated RPI - we need to rewrite it
- the leaf is an attacker that tries to inject traffic in a protected i= nstance - we need to rewrite out or drop
- the leaf is aware of the RPL instance and passes a correct RPI - to m= ake the difference, the 6LR needs a configuration that allows that leaf to = inject in that instance.

This is why we ended up SHOULDing the rewrite. Do we need more text lik= e the aboce in the security section?

Keep safe;

Pascal

> -----Original Message-----
> From: Alvaro Retana <= aretana.ietf@gmail.com>
> Sent: lundi 9 novembre 2020 19:57
> To: draft= -ietf-roll-useofrplinfo@ietf.org
> Cc: Peter van der Stok <consultancy@vanderstok.org>; roll-chairs@ietf.org;
> Routing Over Low power and Lossy networks <roll@ietf.org>
> Subject: AD Review of draft-ietf-roll-useofrplinfo-41
> =20
> Dear authors:
> =20
> Thank you for all the work on this draft.
> =20
> I have a couple of comments in-line -- nothing hard to address.=C2= =A0 I mostly
> looked at the diffs (wrt -31) and so my comments are just on new t= ext.
> =20
> I want to progress this draft with unaware-leaves -- to make it ea= sier on the
> IESG.=C2=A0 I'll start the IETF LC when both are ready.
> =20
> Thanks!
> =20
> Alvaro.
> =20
> =20
> >From idnits:
> =20
> =C2=A0 ** The abstract seems to contain references ([RFC8138]), wh= ich it
> =C2=A0 =C2=A0 =C2=A0shouldn't.=C2=A0 Please replace those with= straight textual mentions of the
> =C2=A0 =C2=A0 =C2=A0documents in question.
> =20
> =20
> =20
> [Line numbers from idnits.]
> =20
> =20
> ...
> 66 =C2=A0 4.=C2=A0 Updates to RFC6553, RFC6550 and RFC8138 . . . = . . . . . . . . =C2=A0 7
> 67 =C2=A0 =C2=A0 4.1.=C2=A0 Updates to RFC6550: Advertising Exter= nal Routes with Non-
> 68 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Storing Mode Signaling. . .= . . . . . . . . . . . . . . . =C2=A0 7
> 69 =C2=A0 =C2=A0 4.2.=C2=A0 Updates to RFC6553: Indicating the ne= w RPI Option Type. . =C2=A0 8
> 70 =C2=A0 =C2=A0 4.3.=C2=A0 Updates to RFC6550:
> 71 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Configuration Options and M= ode
> 72 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 of Operation =C2=A0. . . . = . . . . . . . . . . . . . . . . . . =C2=A011
> 73 =C2=A0 =C2=A0 4.4.=C2=A0 Updates to RFC6550: Indicating the ne= w RPI in the
> 74 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 DODAG Configuration option = Flag. =C2=A0. . . . . . . . . . . . =C2=A012
> 75 =C2=A0 =C2=A0 4.5.=C2=A0 Updates to RFC8138: Indicating the wa= y to decompress with
> 76 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the new RPI Option Type. = =C2=A0. . . . . . . . . . . . . . . . =C2=A013
> =20
> [nit - no action needed, just a suggestion] Group all the updates = to
> rfc6550: either in one sub-section or in consecutive ones.
> =20
> =20
> ...
> 493 4.3.=C2=A0 Updates to RFC6550: Configuration Options and Mode = of
> Operation
> =20
> 495 =C2=A0 RFC6550 section 6.7.6 describes the DODAG Configuratio= n
> Option.=C2=A0 In
> 496 =C2=A0 this option are a series of Flags in the first octet o= f the payload.
> 497 =C2=A0 These flags are described by the DODAG Configuration O= ption Flags
> 498 =C2=A0 registry [dodagcfg], in section 20.14 of RFC6550.
> =20
> 500 =C2=A0 Anticipating future work to revise RPL relating to how= the LLN and
> 501 =C2=A0 DODAG is configured, this document changes the interpr= etation of
> the
> 502 =C2=A0 [dodagcfg] Registry to be limited to Mode-of-Operation= (MOP)
> 503 =C2=A0 specific.=C2=A0 The MOP is described in [RFC6550] sect= ion 6.3.1.=C2=A0 The
> 504 =C2=A0 Options Flags Registry is renamed, and applies to MOP = values zero
> (0)
> 505 =C2=A0 to six (6) only, leaving the flags reserved for MOP va= lue seven (7).
> =20
> 507 =C2=A0 In addition, this document reserves MOP value 7 for fu= ture
> expansion.
> =20
> [] NEW>
> =C2=A0 =C2=A0Section 6.7.6 of RFC6550 describes the DODAG Configur= ation Option as
> =C2=A0 =C2=A0containing a series of Flags in the first octet of th= e payload
<= /body> --000000000000bd9c7b05b3c35083-- From nobody Tue Nov 10 08:45:39 2020 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 495A83A0D67; Tue, 10 Nov 2020 08:45:33 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: roll@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.22.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: roll@ietf.org Message-ID: <160502673320.1061.3204176144630975423@ietfa.amsl.com> Date: Tue, 10 Nov 2020 08:45:33 -0800 Archived-At: Subject: [Roll] I-D Action: draft-ietf-roll-unaware-leaves-23.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, 10 Nov 2020 16:45:33 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks WG of the IETF. Title : Routing for RPL Leaves Authors : Pascal Thubert Michael C. Richardson Filename : draft-ietf-roll-unaware-leaves-23.txt Pages : 39 Date : 2020-11-10 Abstract: This specification updates RFC6550, RFC6775, and RFC8505, to provide routing services to RPL Unaware Leaves that implement 6LoWPAN ND and the extensions therein. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-unaware-leaves/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-roll-unaware-leaves-23.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-unaware-leaves-23 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Nov 10 13:52:31 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21A2C3A107F for ; Tue, 10 Nov 2020 13:52:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, 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 Rvcr5rB-rCE4 for ; Tue, 10 Nov 2020 13:52:26 -0800 (PST) Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com [IPv6:2607:f8b0:4864:20::e2a]) (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 B559A3A107D for ; Tue, 10 Nov 2020 13:52:26 -0800 (PST) Received: by mail-vs1-xe2a.google.com with SMTP id b129so7728vsb.1 for ; Tue, 10 Nov 2020 13:52:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=QziO0sKBdlgM/fA+AlPyaOGmB+ZgZqny0FJJk+2r7p8=; b=MrWUqnqrcxf5UVl1bsuvGcFtvlRRbf2ig0SDYbIZT4Yt6CXZuEORuhw+tC26AVJQ60 CFwm5rKX6Ndtk2HnBFQMFKehy7e4dObhwPcktFmeukvoGKy0uRQvFopr/D2hfVfmnlR7 I1xIsm29GewuHgiyEuArIHzNVv/LsuR9oBXFM2vL4UoSd2FIq0VLq6wMlZMXzQDLn0aN YM07tG8Q4Bq9/5pMAQUpVY7V2qvELp+ZHqVfA8lvw90Ke1c+AUjqrY172IhB+czaTa3n bdYl+vcZhWx5lf+5Q/lJUGisPRJazxugNuJlmqyZBY5a8fux+4N64O69ENiGjkrUZ0TE sf6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=QziO0sKBdlgM/fA+AlPyaOGmB+ZgZqny0FJJk+2r7p8=; b=CiVSpR+lC+i7ed81Ig3E9WljX0LxUeCkdSQb8bOvfzqbQsrauCkGmhQIKxs5lo5FuA Peamf8f51nRKj3WDKOJejTLD1exWyCbk05Dr2DTer0Jp5CNOiJ+IaSRrSKZvSgtVXaHZ hWONQpR8Xf3sjCLoZYOn1Wxr0gLx27Wr01Emw+vdqYTJDttTLRXSMWyo+ZvmXP4wTbTJ /pUwTBykwvGMd35wD54Qm/A2wsmoMpHTzAFIEw13XAsyvJ1Il0ZZE3r/7DYc9HEgtTSo k4K+pHX9Qg0+ojJBqZeC6n1UYhjRyc8Go7y6yGfzcKGKS65y7+lbI+nfSTmi3VfSxllE qpxQ== X-Gm-Message-State: AOAM532UZdNQR1iKoq/k/OrGzpF9ro21yBYwSY9kK/Q99tUY2Xwu6ze2 Oi1q4+U+B3GW7VKXB0bir7LmZjvo7Z0JfJzrwi7XRoIM47c= X-Google-Smtp-Source: ABdhPJwdbFR84GIe0BmmrYFpM5Djjh2q+JvawEaDA6GB7PH/Gspu95EOodlHNbeT2vDf3aEgd0HgJg9gDwRWmlfcSdo= X-Received: by 2002:a67:ee0a:: with SMTP id f10mr6541555vsp.39.1605045145571; Tue, 10 Nov 2020 13:52:25 -0800 (PST) MIME-Version: 1.0 References: <160071395471.20401.6949662287254386726@ietfa.amsl.com> <195789.1600714786@dooku> <924_1603345522_5F911C72_924_396_1_DBB6E52D.7B25E%dominique.barthel@orange.com> In-Reply-To: <924_1603345522_5F911C72_924_396_1_DBB6E52D.7B25E%dominique.barthel@orange.com> From: Ines Robles Date: Tue, 10 Nov 2020 23:51:49 +0200 Message-ID: To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="000000000000c0162a05b3c7b1ac" Archived-At: Subject: Re: [Roll] I-D Action: draft-ietf-roll-useofrplinfo-41.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: Tue, 10 Nov 2020 21:52:29 -0000 --000000000000c0162a05b3c7b1ac Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Dominique, Many thanks for your review. Updates were done in github. Please find comments in line. On Thu, Oct 22, 2020 at 8:45 AM wrote: > Hello all, > > I just looked at draft-ietf-roll-useofrplinfo-41.txt and specifically the > diff. > > I have the following comments: > - Section 4.3: "leaving the flags reserved for MOP value seven (7)". > Actually, there is no normative text later in the document (e.g., Section > 11) that implements this. MOP 7 is indeed reserved (see following comment= , > though), but not the flags for the MOP 7. I think this would not be a goo= d > idea anyway, since it would be starting designing the protocol that uses > MOP 7. > [ines] We deleted: "leaving the flags reserved for MOP value seven (7)" to avoid confusion. The goal is to rename the registry not to affect the flags for MOP 7. > - Section 11.3: "this document changes the allocation status of the Mode > of Operation > (MOP) [ianamop] from Unassigned to Reserved.". I guess you mean "his > document changes the allocation status of the Mode of Operation (MOP) > [ianamop] value 7 from Unassigned to Reserved.", correct? > [ines] thank you, yes we fixed as you suggested. > - Section 4.3 "to be limited to Mode-of-Operation (MOP) specific.". I > can't quite parse this sentence. Do you mean "to be limited to > Mode-of-Operation (MOP) specific values."? Or "to be Mode-of-Operation > (MOP) specific."? > [ines] we fixed added specific values. > - Section 8.2.1: "Having the RAL information about the RPL domain, it may > encapsulate". "It" does not refer to anything identifiable. Grammatically= , > it would refer to "the flow", which does not quite make sense. > [ines] we fixed to "Having the RAL information about the RPL domain, the packet may be encapsulated to the root when the destination is not in the RPL domain of the RAL." Many thanks again, Ines. > > Best regards > > Dominique > > > Le 21/09/20 21:58, =C2=AB Roll on behalf of Pascal Thubert (pthubert) =C2= =BB > a > =C3=A9crit : > > >Hello Michael > > > >Many thanks for this; I agree with those diffs and will change the other > >2 drafts to refer to this. > > > > > >Take care, > > > >Pascal > > > >> Le 21 sept. 2020 =C3=A0 21:01, Michael Richardson a= =C3=A9crit > >>: > >> > >> > >> internet-drafts@ietf.org wrote: > >>> A diff from the previous version is available at: > >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-useofrplinfo-41 > >> > >> Hi, based upon a conversation this morning among the authors and > >>useofrplinfo > >> and turnon-rfc8138, we arrived at the diffs above. > >> > >> The point is that the changes to MOP and the rename of the > >> DODAG Configuration Options Flags registry would get done in the first > >> document that uses them, which is useofrplinfo. > >> > >> I agreed to make the diffs required, and I hope that I got it right. > >> > >> Some bits of the diff: > >> > >> 4.3. Updates to RFC6550: Configuration Options and Mode of Operation > >> > >> RFC6550 section 6.7.6 describes the DODAG Configuration Option. I= n > >> this option are a series of Flags in the first octet of the > >>payload. > >> These flags are described by the DODAG Configuration Option Flags > >> registry [dodagcfg], in section 20.14 of RFC6550. > >> > >> Anticipating future work to revise RPL relating to how the LLN and > >> DODAG is configured, this document changes the interpretation of > >>the > >> [dodagcfg] Registry to be limited to Mode-of-Operation (MOP) > >> specific. The MOP is described in [RFC6550] section 6.3.1. The > >> Options Flags Registry is renamed, and applies to MOP values zero > >>(0) > >> to six (6) only, leaving the flags reserved for MOP value seven > >>(7). > >> > >> In addition, this document reserves MOP value 7 for future > >>expansion. > >> > >> ... > >> > >> 11.2. Changes to DODAG Configuration Options Flags > >> > >> This document changes the name of the "DODAG Configuration Option > >> Flags" [dodagcfg] to "DODAG Configuration Option Flags for MOP > >>0..6". > >> > >> 11.3. Change MOP value 7 to Reserved > >> > >> This document changes the allocation status of the Mode of > >>Operation > >> (MOP) [ianamop] from Unassigned to Reserved. This change is in > >> support of future work related to capabilities. > >> > >> > >> The MOPEX document would then allocate the value, but nobody else can > >>use it > >> before then. > >> > >> > >> -- > >> ] Never tell me the odds! | ipv6 mesh > >>networks [ > >> ] Michael Richardson, Sandelman Software Works | network > >>architect [ > >> ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on > >>rails [ > >> > >> _______________________________________________ > >> 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 > > > > _________________________________________________________________________= ________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations > confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez > recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages > electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme o= u > falsifie. Merci. > > This message and its attachments may contain confidential or privileged > information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and > delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have bee= n > modified, changed or falsified. > Thank you. > > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll > --000000000000c0162a05b3c7b1ac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Dominique,

Many tha= nks for your review. Updates were done in github. Please find comments in l= ine.

On Thu, Oct 22, 2020 at 8:45 AM <dominique.barthel@orange.com> wrote:
Hello all,

I just looked at draft-ietf-roll-useofrplinfo-41.txt and specifically the diff.

I have the following comments:
- Section 4.3: "leaving the flags reserved for MOP value seven (7)&quo= t;.
Actually, there is no normative text later in the document (e.g., Section 11) that implements this. MOP 7 is indeed reserved (see following comment,<= br> though), but not the flags for the MOP 7. I think this would not be a good<= br> idea anyway, since it would be starting designing the protocol that uses MOP 7.
=C2=A0
[ines] We deleted: "leavi= ng the flags reserved for MOP value seven (7)" to avoid confusion.
The goal is to rename the registry not to affect the flags for MOP 7= .=C2=A0
=C2=A0
- Section 11.3: "this document changes the allocation status of the Mo= de
of Operation
=C2=A0 =C2=A0 =C2=A0(MOP) [ianamop] from Unassigned to Reserved.". I g= uess you mean "his
document changes the allocation status of the Mode of Operation (MOP)
[ianamop] value 7 from Unassigned to Reserved.", correct?

[ines] thank you, yes=C2=A0 we fixed as you suggest= ed.

=C2=A0
- Section 4.3 "to be limited to Mode-of-Operation (MOP) specific."= ;. I
can't quite parse this sentence. Do you mean "to be limited to
Mode-of-Operation (MOP) specific values."? Or "to be Mode-of-Oper= ation
(MOP) specific."?
[ines]=C2=A0 we fixed added spe= cific values.
=C2=A0
- Section 8.2.1: "Having the RAL information about the RPL domain, it = may
encapsulate". "It" does not refer to anything identifiable. = Grammatically,
it would refer to "the flow", which does not quite make sense.
[ines]=C2=A0 we fixed to "Having the RAL information a= bout the RPL domain, the packet may be encapsulated to the root when the de= stination is not in the RPL domain of the RAL."

<= /div>
Many thanks again,

Ines.

Best regards

Dominique


Le 21/09/20 21:58, =C2=AB Roll on behalf of Pascal Thubert (pthubert) =C2= =BB
<roll-bounces= @ietf.org on behalf of pthubert=3D40cisco.com@dmarc.ietf.org> a
=C3=A9crit :

>Hello Michael
>
>Many thanks for this; I agree with those diffs and will change the othe= r
>2 drafts to refer to this.
>
>
>Take care,
>
>Pascal
>
>> Le 21 sept. 2020 =C3=A0 21:01, Michael Richardson <mcr@sandelman.ca> a =C3=A9= crit
>>:
>>
>>
>> inte= rnet-drafts@ietf.org wrote:
>>> A diff from the previous version is available at:
>>> https://www.ietf.org= /rfcdiff?url2=3Ddraft-ietf-roll-useofrplinfo-41
>>
>> Hi, based upon a conversation this morning among the authors and >>useofrplinfo
>> and turnon-rfc8138, we arrived at the diffs above.
>>
>> The point is that the changes to MOP and the rename of the
>> DODAG Configuration Options Flags registry would get done in the f= irst
>> document that uses them, which is useofrplinfo.
>>
>> I agreed to make the diffs required, and I hope that I got it righ= t.
>>
>> Some bits of the diff:
>>
>> 4.3.=C2=A0 Updates to RFC6550: Configuration Options and Mode of O= peration
>>
>>=C2=A0 =C2=A0 =C2=A0RFC6550 section 6.7.6 describes the DODAG Confi= guration Option.=C2=A0 In
>>=C2=A0 =C2=A0 =C2=A0this option are a series of Flags in the first = octet of the
>>payload.
>>=C2=A0 =C2=A0 =C2=A0These flags are described by the DODAG Configur= ation Option Flags
>>=C2=A0 =C2=A0 =C2=A0registry [dodagcfg], in section 20.14 of RFC655= 0.
>>
>>=C2=A0 =C2=A0 =C2=A0Anticipating future work to revise RPL relating= to how the LLN and
>>=C2=A0 =C2=A0 =C2=A0DODAG is configured, this document changes the = interpretation of
>>the
>>=C2=A0 =C2=A0 =C2=A0[dodagcfg] Registry to be limited to Mode-of-Op= eration (MOP)
>>=C2=A0 =C2=A0 =C2=A0specific.=C2=A0 The MOP is described in [RFC655= 0] section 6.3.1.=C2=A0 The
>>=C2=A0 =C2=A0 =C2=A0Options Flags Registry is renamed, and applies = to MOP values zero
>>(0)
>>=C2=A0 =C2=A0 =C2=A0to six (6) only, leaving the flags reserved for= MOP value seven
>>(7).
>>
>>=C2=A0 =C2=A0 =C2=A0In addition, this document reserves MOP value 7= for future
>>expansion.
>>
>> ...
>>
>> 11.2.=C2=A0 Changes to DODAG Configuration Options Flags
>>
>>=C2=A0 =C2=A0 =C2=A0This document changes the name of the "DOD= AG Configuration Option
>>=C2=A0 =C2=A0 =C2=A0Flags" [dodagcfg] to "DODAG Configura= tion Option Flags for MOP
>>0..6".
>>
>> 11.3.=C2=A0 Change MOP value 7 to Reserved
>>
>>=C2=A0 =C2=A0 =C2=A0This document changes the allocation status of = the Mode of
>>Operation
>>=C2=A0 =C2=A0 =C2=A0(MOP) [ianamop] from Unassigned to Reserved.=C2= =A0 This change is in
>>=C2=A0 =C2=A0 =C2=A0support of future work related to capabilities.=
>>
>>
>> The MOPEX document would then allocate the value, but nobody else = can
>>use it
>> before then.
>>
>>
>> --
>> ]=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Never tell= me the odds!=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= | ipv6 mesh
>>networks [
>> ]=C2=A0 =C2=A0Michael Richardson, Sandelman Software Works=C2=A0 = =C2=A0 =C2=A0 =C2=A0 | network
>>architect=C2=A0 [
>> ]=C2=A0 =C2=A0 =C2=A0mcr@sandelman.ca=C2=A0 http://www.sandelman.ca/=C2=A0 =C2= =A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0ruby on
>>rails=C2=A0 =C2=A0 [
>>=C2=A0 =C2=A0
>> _______________________________________________
>> 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


___________________________________________________________________________= ______________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les message= s electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci.

This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele= te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified.
Thank you.

_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--000000000000c0162a05b3c7b1ac-- From nobody Tue Nov 10 15:16:29 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7972B3A11DA; Tue, 10 Nov 2020 15:16:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, 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 Urq1lmGyg3ta; Tue, 10 Nov 2020 15:16:20 -0800 (PST) Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (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 85A043A11DB; Tue, 10 Nov 2020 15:16:19 -0800 (PST) Received: by mail-io1-xd31.google.com with SMTP id u19so260004ion.3; Tue, 10 Nov 2020 15:16:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4UV4Yz8d7u6yoTVE7Y+99slrM8YgQH5x8nnHsoTyzHY=; b=PPFCOSQDuzJ5pepN+Ano2UcIClml4JnKfvaI9Kdg/pGVK4H1yqaVmi3/tLwCXerN8C 2oFghImN42ejCHMJolJdx/JE5gP8c9vZgJOzGjudP+PofgLI+olTfjxkMYmDRPenJDxJ UvmliDeV9AKlNsp1D1Y6li+m8j2mLVhibDJ+kT5lrmp5B9Q/5YVP6YGEFJhiBTSTJFKp q66dLsbTlJ9Tt4uJPcLNcF4OIDB707nJ8MbVfwPeSfOCSaJYZQxuoLRXs3pgBcOGJLxV Tq0/5zFpIQ0zgfvUNLbzjrR2Vy0Y5U48GeGIEcxR3S+MU/8Ku1lUNfEVdgcZQC0zemxf ydPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4UV4Yz8d7u6yoTVE7Y+99slrM8YgQH5x8nnHsoTyzHY=; b=DQnTDOfAcCmMrVCxQAdiN3ol/vKrdgPflOaFBQlxfAWRcplN2FKXZ981791L7/uXTY XWIxmS9dVjG4CmH9G40UcvxFbyhvL069HyBOAsNtFY42jHsiC+jQAHZnTocLr2i2T5Mj 2DaiyxSpQ6H1p+X/RDRTXbkGUON5PAB4LoXtZSe2AgjozNEUwoBQAIy2g6JuqdpUAWbm OqfGLNGzarx5xcFoeTCH/W51m3PZjn3OkBZbSdJU5AUUrxfgMHgXTy7joY7hSS+va6eL ix1i9w6Eza+l7io8hoGnfbHNmtUfY5Vfe1RU9dGgLXlOanh6dO2e/Zpmdi+bnSJ8vfJ1 AuJw== X-Gm-Message-State: AOAM5334MpJadl4dDyj7kteJ1cLuJIUm0Y9vJB6IvWakoKcxznvoyBC1 N/A7uFFAPFjIGCGijpbCUArVqDLHX1e/BybhCKA= X-Google-Smtp-Source: ABdhPJzDpZBz7AamSz2jWysH1D59VMtti26AEjK3/1ZBTipPpHXQqMAYdb1ReQwy5nIw95hF4DOWCXRXSKztuJ80dqA= X-Received: by 2002:a05:6602:2d93:: with SMTP id k19mr15818801iow.51.1605050178505; Tue, 10 Nov 2020 15:16:18 -0800 (PST) MIME-Version: 1.0 References: <20200911162617.GQ89563@kduck.mit.edu> <8F19C753-DCA0-4A32-BA3B-A124B2F7F745@cisco.com> <117497.1600481093@dooku> <20201110033438.GE39170@kduck.mit.edu> In-Reply-To: From: Martin Duke Date: Tue, 10 Nov 2020 15:16:08 -0800 Message-ID: To: "Pascal Thubert (pthubert)" Cc: Benjamin Kaduk , Alvaro Retana , The IESG , "draft-ietf-roll-turnon-rfc8138@ietf.org" , Routing Over Low power and Lossy networks , "roll-chairs@ietf.org" , Michael Richardson Content-Type: multipart/alternative; boundary="000000000000bc909405b3c8dd41" Archived-At: Subject: Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf-roll-turnon-rfc8138-14: (with DISCUSS and COMMENT) 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, 10 Nov 2020 23:16:23 -0000 --000000000000bc909405b3c8dd41 Content-Type: text/plain; charset="UTF-8" OK, We will eventually get there, but this will never stop being weird to me. :-) Imagine 5 types of DODAG nodes: Type 8138? this draft? MOP5? MOP 7? ------- ------- ------------ -------- ---------- A N N N N B Y N N N C Y Y N N D Y Y Y N E Y Y Y Y So if IIUC, the current state of play is that B can't gracefully deploy into a network with A, because they have to be statically configured to not-compress. As long as B is upgraded to this draft (C), it can gracefully deploy in a network with A, because compression will remain off until all the A is gone. C and B can function together without this draft, but they won't be able to dynamically change compression state, FWIW. Similarly, a hypothetical D can gracefully deploy with A, as it will have use of these flags, but doesn't really need the flags to work with B or C unless you want to dynamically change state for some reason. Meanwhile, E will *not *be able to gracefully deploy with A, because it does not have a means to change its compression state using the DODAG configuration. But because of the sentence we've discussing in this thread, networks with C and D will have no problem because they have this text to help them decide whether or not to compress. They will not have the ability to dynamically change compression state. So I guess the value of the MOP 7 behavior is... to recover the bit of the flags? Fine, I suppose, but this would appear to have two costs: 1) If A is still out there when E deploys, this bit would have been useful, but isn't. 2) I have no idea if the "dynamic change in compression state" use case is valuable it all, but it would certainly foreclose the possilbilty. Do I have this right? Martin On Tue, Nov 10, 2020 at 12:15 AM Pascal Thubert (pthubert) < pthubert@cisco.com> wrote: > Hello Benjamin: > > > That said, and my apologies for a hazy memory coming back to this after a > > couple months, in a year or N from now when mopex is finalized, how will > > someone looking at mopex know to use RFC8138 on links where 6LoWPAN > > Header Compression applies (and not use it otherwise)? We are claiming > in > > the -14 of this document that: > > > > For a MOP value of 7, [RFC8138] MUST be > > used on Links where 6LoWPAN Header Compression [RFC6282] applies and > > MUST NOT be used otherwise. > > > > but I am not sure (or have forgotten) what the chain of references is > supposed > > to lead someone who is implementing RPL plus MOP=7 to the requirement to > > use RFC 8138. I don't think we should just rely on the mopex text to do > so, > > since we are trying to impose the requirement with this document (which > > predates mopex by some time), and there's not anything (other than our > > collective memories, of course) requiring mopex to remain consistent with > > that requirement. > > Just to be clear for the other readers: MOPext does not exist as a > normative reference for this work. > The only field that exists is the MOP field in the DIO and that field is 3 > bits long, values 0..7. > > The normative reference that you are after is > https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/ > This is the spec that updates RPL and changes the IANA registry to > indicate that 7 is not a MOP. > > There we have: > > " > > ... > > Anticipating future work to revise RPL relating to how the LLN and > DODAG is configured, this document changes the interpretation of the > [dodagcfg] Registry to be limited to Mode-of-Operation (MOP) > specific. The MOP is described in [RFC6550] section 6.3.1. The > Options Flags Registry is renamed, and applies to MOP values zero (0) > to six (6) only, leaving the flags reserved for MOP value seven (7). > > In addition, this document reserves MOP value 7 for future expansion. > > ... > > 11.3. Change MOP value 7 to Reserved > > This document changes the allocation status of the Mode of Operation > (MOP) [ianamop] from Unassigned to Reserved. This change is in > support of future work related to capabilities. > " > > So basically we tell the implementations from now on to test if MOP is 7, > and in that case, the Options Flags are undefined. In other words, if MOP > is 7, the stack must not use the option flags as if the MOP was <7. In > fact, 7 is no more a MOP value but a reserved thingy that can be overloaded > in the future. And yes, we intend to do just that in MOPExt. > > Until that happens, implementations are at a loss if they encounter when a > MOP field that is all ones. So we need to give them instructions to cope > with the situation. This draft derives whether to use RFC 8138 from whether > the 6LoWPAN compression applies to the link or not. > > This will stay true forever, unless another RFC amends it. When/if that > happens, the new RFC will have to consider backward compatibility with a > legacy implementation that implements the above. > > Note that this line of thought applies to 3 flags, defined respectively in: > - https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/ > - https://datatracker.ietf.org/doc/draft-ietf-roll-turnon-rfc8138/ > - https://datatracker.ietf.org/doc/draft-ietf-roll-unaware-leaves/ > > Keep safe! > > Pascal > > > > > Thanks, > > > > Ben > > > > On Wed, Sep 30, 2020 at 04:25:10PM +0000, Pascal Thubert (pthubert) > wrote: > > > Hello Alvaro > > > > > > I uploaded both draft with the suggested update, please see > > > > > > https://tools.ietf.org/rfcdiff?url2=draft-ietf-roll-turnon-rfc8138-17. > > > txt > > > https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-unaware-leaves-21.tx > > > t > > > > > > Keep safe > > > > > > Pascal > > > > > > > -----Original Message----- > > > > From: Alvaro Retana > > > > Sent: jeudi 24 septembre 2020 17:49 > > > > To: Pascal Thubert (pthubert) > > > > Cc: Benjamin Kaduk ; The IESG ; > > > > draft-ietf- roll-turnon-rfc8138@ietf.org; Martin Duke > > > > ; Routing Over Low power and Lossy networks > > > > ; roll- chairs@ietf.org; Michael Richardson > > > > > > > > Subject: Re: [Roll] Benjamin Kaduk's Discuss on > > > > draft-ietf-roll-turnon-rfc8138- > > > > 14: (with DISCUSS and COMMENT) > > > > > > > > On September 24, 2020 at 8:13:09 AM, Pascal Thubert wrote: > > > > > > > > > > > > Pascal: > > > > > > > > Hi! > > > > > > > > > Following the meeting last Monday and subsequent the update of > > > > > useofrplinfo by Michael (thanks Michael!) I published a new > > > > > version of the turnon RFC > > > > > 8138 draft. > > > > > > > > > > The major changes are > > > > > - removed the formal update to RFC 6550 > > > > > - refer to useofrplinfo as the justification why the flag is not > > > > > defined for MOP 7 > > > > > - defined the operation in MOP 7 as compression on iff the Link > > > > > uses 6LoPWAN HC. > > > > > > > > Thanks for these changes. > > > > > > > > Because we have to cycle useofrplinfo back through (when the WG is > > > > done with it), I asked Ben/Martin to wait for that before coming > > > > back to this document. It'll make it easier than tracking multiple > > > > changes. :-) > > > > > > > > > > > > OTOH, I do have comments on the recent change: > > > > > > > > OLD> > > > > Section 4.3 of [USEofRPLinfo] updates [RFC6550] to indicate that > > > > the > > > > definition of the Flags applies to Mode of Operation (MOP) values > > > > zero (0) to six (6) only, leaving the flags reserved for MOP > > > > value > > > > seven (7). For a MOP value of 7, the bit in position 2 is > > > > considered > > > > unallocated and [RFC8138] MUST be used on Links where 6LoWPAN > > > > Header > > > > Compression [RFC6282] applies and MUST NOT be used otherwise. > > > > > > > > NEW> > > > > > > > > Section 4.3 of [USEofRPLinfo] updates [RFC6550] to indicate that > > > > the > > > > definition of the Flags applies to Mode of Operation (MOP) values > > > > zero (0) > > > > to six (6) only. For a MOP value of 7, [RFC8138] MUST be used on > > > > Links > > > > where 6LoWPAN Header Compression [RFC6282] applies and MUST NOT > > > > be used > > > > otherwise. > > > > > > > > > > > > Thanks! > > > > > > > > Alvaro. > --000000000000bc909405b3c8dd41 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
OK,

We will= eventually get there, but this will never stop being weird to me. :-)

Imagine 5 types of DODAG nodes:

Type=C2=A0 =C2=A0 =C2=A08138? this draft? MOP5?=C2=A0 MOP 7?=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=A0A=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0N=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 N=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0N=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0N=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0
<= div>B=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Y=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 N=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0N=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0N
C=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Y=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 Y=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0N=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0N
D=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 Y=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Y=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Y=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 N
E=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Y= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Y=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Y=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Y
<= div>
So if IIUC, the current state of play is that B can'= t gracefully deploy into a network with A, because they have to be statical= ly configured to not-compress.

As long as B is upg= raded to this draft (C), it can gracefully deploy in a network with A, beca= use=C2=A0compression will remain off until all the A is gone. C and B can f= unction together without this draft, but they won't be able to dynamica= lly change compression state, FWIW.

Similarly, a h= ypothetical D can gracefully deploy with A, as it will have use of these fl= ags, but doesn't really need the flags to work with B or C unless you w= ant to dynamically change state for some reason.

M= eanwhile, E will not be able to gracefully deploy with A, because it= does not have a means to change its compression state using the DODAG conf= iguration. But because of the sentence we've discussing in this thread,= networks with C and D will have no problem because they have this text to = help them decide whether or not to compress. They will not have the ability= to dynamically change compression state.

So I gue= ss the value of the MOP 7 behavior is... to recover the bit of the flags? F= ine, I suppose, but this would appear to have two costs:
1) If A = is still out there when E deploys, this bit would have been useful, but isn= 't.
2) I have no idea if the "dynamic change in compress= ion state" use case is valuable it all, but it would certainly foreclo= se the possilbilty.

Do I have this right?

Martin


On Tue, Nov 10, 2020 at 1= 2:15 AM Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
Hello Benjamin:

> That said, and my apologies for a hazy memory coming back to this afte= r a
> couple months, in a year or N from now when mopex is finalized, how wi= ll
> someone looking at mopex know to use RFC8138 on links where 6LoWPAN > Header Compression applies (and not use it otherwise)?=C2=A0 We are cl= aiming in
> the -14 of this document that:
>
>=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 =C2=A0 =C2=A0 =C2=A0For a MOP value of 7, [RFC8138] MU= ST be
>=C2=A0 =C2=A0 used on Links where 6LoWPAN Header Compression [RFC6282] = applies and
>=C2=A0 =C2=A0 MUST NOT be used otherwise.
>
> but I am not sure (or have forgotten) what the chain of references is = supposed
> to lead someone who is implementing RPL plus MOP=3D7 to the requiremen= t to
> use RFC 8138.=C2=A0 I don't think we should just rely on the mopex= text to do so,
> since we are trying to impose the requirement with this document (whic= h
> predates mopex by some time), and there's not anything (other than= our
> collective memories, of course) requiring mopex to remain consistent w= ith
> that requirement.

Just to be clear for the other readers: MOPext does not exist as a normativ= e reference for this work.
The only field that exists is the MOP field in the DIO and that field is 3 = bits long, values 0..7.

The normative reference that you are after is https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/<= br> This is the spec that updates RPL and changes the IANA registry to indicate= that 7 is not a MOP.

There we have:

"

...

=C2=A0 Anticipating future work to revise RPL relating to how the LLN and =C2=A0 =C2=A0DODAG is configured, this document changes the interpretation = of the
=C2=A0 =C2=A0[dodagcfg] Registry to be limited to Mode-of-Operation (MOP) =C2=A0 =C2=A0specific.=C2=A0 The MOP is described in [RFC6550] section 6.3.= 1.=C2=A0 The
=C2=A0 =C2=A0Options Flags Registry is renamed, and applies to MOP values z= ero (0)
=C2=A0 =C2=A0to six (6) only, leaving the flags reserved for MOP value seve= n (7).

=C2=A0 =C2=A0In addition, this document reserves MOP value 7 for future exp= ansion.

...

11.3.=C2=A0 Change MOP value 7 to Reserved

=C2=A0 =C2=A0This document changes the allocation status of the Mode of Ope= ration
=C2=A0 =C2=A0(MOP) [ianamop] from Unassigned to Reserved.=C2=A0 This change= is in
=C2=A0 =C2=A0support of future work related to capabilities.
"

So basically we tell the implementations from now on to test if MOP is 7, a= nd in that case, the Options Flags are undefined. In other words, if MOP is= 7, the stack must not use the option flags as if the MOP was <7. In fac= t, 7 is no more a MOP value but a reserved thingy that can be overloaded in= the future. And yes, we intend to do just that in MOPExt.

Until that happens, implementations are at a loss if they encounter when a = MOP field that is all ones. So we need to give them instructions to cope wi= th the situation. This draft derives whether to use RFC 8138 from whether t= he 6LoWPAN compression applies to the link or not.

This will stay true forever, unless another RFC amends it. When/if that hap= pens, the new RFC will have to consider backward compatibility with a legac= y implementation that implements the above.

Note that this line of thought applies to 3 flags, defined respectively in:=
- https://datatracker.ietf.org/doc/dra= ft-ietf-roll-useofrplinfo/
- https://datatracker.ietf.org/doc/d= raft-ietf-roll-turnon-rfc8138/
- https://datatracker.ietf.org/doc/d= raft-ietf-roll-unaware-leaves/

Keep safe!

Pascal

>
> Thanks,
>
> Ben
>
> On Wed, Sep 30, 2020 at 04:25:10PM +0000, Pascal Thubert (pthubert) wr= ote:
> > Hello Alvaro
> >
> > I uploaded both draft with the suggested update, please see
> >
> > https://tools.ietf.= org/rfcdiff?url2=3Ddraft-ietf-roll-turnon-rfc8138-17.
> > txt
> > https://www.ietf.o= rg/rfcdiff?url2=3Ddraft-ietf-roll-unaware-leaves-21.tx
> > t
> >
> > Keep safe
> >
> > Pascal
> >
> > > -----Original Message-----
> > > From: Alvaro Retana <aretana.ietf@gmail.com>
> > > Sent: jeudi 24 septembre 2020 17:49
> > > To: Pascal Thubert (pthubert) <pthubert@cisco.com>
> > > Cc: Benjamin Kaduk <kaduk@mit.edu>; The IESG <iesg@ietf.org>;
> > > draft-ietf- roll-turnon-rfc8138@ietf.org; Martin Duke
> > > <martin.h.duke@gmail.com>; Routing Over Low power and Lossy netw= orks
> > > <roll@= ietf.org>; roll- chairs@ietf.org; Michael Richardson
> > > <mcr+ietf@sandelman.ca>
> > > Subject: Re: [Roll] Benjamin Kaduk's Discuss on
> > > draft-ietf-roll-turnon-rfc8138-
> > > 14: (with DISCUSS and COMMENT)
> > >
> > > On September 24, 2020 at 8:13:09 AM, Pascal Thubert wrote: > > >
> > >
> > > Pascal:
> > >
> > > Hi!
> > >
> > > > Following the meeting last Monday and subsequent the up= date of
> > > > useofrplinfo by Michael (thanks Michael!) I published a= new
> > > > version of the turnon RFC
> > > > 8138 draft.
> > > >
> > > > The major changes are
> > > > - removed the formal update to RFC 6550
> > > > - refer to useofrplinfo as the justification why the fl= ag is not
> > > > defined for MOP 7
> > > > - defined the operation in MOP 7 as compression on iff = the Link
> > > > uses 6LoPWAN HC.
> > >
> > > Thanks for these changes.
> > >
> > > Because we have to cycle useofrplinfo back through (when the= WG is
> > > done with it), I asked Ben/Martin to wait for that before co= ming
> > > back to this document.=C2=A0 It'll make it easier than t= racking multiple
> > > changes. :-)
> > >
> > >
> > > OTOH, I do have comments on the recent change:
> > >
> > > OLD>
> > > =C2=A0 =C2=A0Section 4.3 of [USEofRPLinfo] updates [RFC6550]= to indicate that
> > > the
> > > =C2=A0 =C2=A0definition of the Flags applies to Mode of Oper= ation (MOP) values
> > > =C2=A0 =C2=A0zero (0) to six (6) only, leaving the flags res= erved for MOP
> > > value
> > > =C2=A0 =C2=A0seven (7).=C2=A0 For a MOP value of 7, the bit = in position 2 is
> > > considered
> > > =C2=A0 =C2=A0unallocated and [RFC8138] MUST be used on Links= where 6LoWPAN
> > > Header
> > > =C2=A0 =C2=A0Compression [RFC6282] applies and MUST NOT be u= sed otherwise.
> > >
> > > NEW>
> > >
> > > =C2=A0 =C2=A0Section 4.3 of [USEofRPLinfo] updates [RFC6550]= to indicate that
> > > the
> > > =C2=A0 =C2=A0definition of the Flags applies to Mode of Oper= ation (MOP) values
> > > zero (0)
> > > =C2=A0 =C2=A0to six (6) only.=C2=A0 For a MOP value of 7, [R= FC8138] MUST be used on
> > > Links
> > > =C2=A0 =C2=A0where 6LoWPAN Header Compression [RFC6282] appl= ies and MUST NOT
> > > be used
> > > =C2=A0 =C2=A0otherwise.
> > >
> > >
> > > Thanks!
> > >
> > > Alvaro.
--000000000000bc909405b3c8dd41-- From nobody Tue Nov 10 23:00:40 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5A1F3A0991; Tue, 10 Nov 2020 23:00:32 -0800 (PST) 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_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ZAdJ6CktF_z; Tue, 10 Nov 2020 23:00:30 -0800 (PST) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 99EFA3A0985; Tue, 10 Nov 2020 23:00:29 -0800 (PST) Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 0AB70B9l026881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 11 Nov 2020 02:00:22 -0500 Date: Tue, 10 Nov 2020 23:00:10 -0800 From: Benjamin Kaduk To: "Pascal Thubert (pthubert)" Cc: Alvaro Retana , The IESG , "draft-ietf-roll-turnon-rfc8138@ietf.org" , Martin Duke , Routing Over Low power and Lossy networks , "roll-chairs@ietf.org" , Michael Richardson Message-ID: <20201111070010.GU39170@kduck.mit.edu> References: <117497.1600481093@dooku> <20201110033438.GE39170@kduck.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Archived-At: Subject: Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf-roll-turnon-rfc8138-14: (with DISCUSS and COMMENT) 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, 11 Nov 2020 07:00:33 -0000 Hi Pascal, I will say a bit more inline, but want to note upfront that my primary unease here is that we seem to be assigning some (partial) semantics to MOP value 7 here (even though we do not specify full semantics for MOP value 7): For a MOP value of 7, [RFC8138] MUST be used on Links where 6LoWPAN Header Compression [RFC6282] applies and MUST NOT be used otherwise. yet there is no "trail of breadcrumbs" for someone to follow from "I want to implement MOP 7" and end up at the sentence I quoted above. A formal Update to 6550 would provide such a trail, as would being listed as a reference in the IANA registry for MOP value 7. My current understanding is that the only thing we have right now is "repeat this requirement in whatever document ends up providing a full specification for MOP value 7", and I don't think that relying on the IETF's collective memory is a great way to enforce such a requirement -- we can and have in the past slipped up and published RFCs that are inconsistent with requirements imposed by previous ones. On Tue, Nov 10, 2020 at 08:15:33AM +0000, Pascal Thubert (pthubert) wrote: > Hello Benjamin: > > > That said, and my apologies for a hazy memory coming back to this after a > > couple months, in a year or N from now when mopex is finalized, how will > > someone looking at mopex know to use RFC8138 on links where 6LoWPAN > > Header Compression applies (and not use it otherwise)? We are claiming in > > the -14 of this document that: > > > > For a MOP value of 7, [RFC8138] MUST be > > used on Links where 6LoWPAN Header Compression [RFC6282] applies and > > MUST NOT be used otherwise. > > > > but I am not sure (or have forgotten) what the chain of references is supposed > > to lead someone who is implementing RPL plus MOP=7 to the requirement to > > use RFC 8138. I don't think we should just rely on the mopex text to do so, > > since we are trying to impose the requirement with this document (which > > predates mopex by some time), and there's not anything (other than our > > collective memories, of course) requiring mopex to remain consistent with > > that requirement. > > Just to be clear for the other readers: MOPext does not exist as a normative reference for this work. > The only field that exists is the MOP field in the DIO and that field is 3 bits long, values 0..7. Yes. > The normative reference that you are after is https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/ > This is the spec that updates RPL and changes the IANA registry to indicate that 7 is not a MOP. Not a MOP at all, or not a "normal" MOP that behaves like 0..6? > There we have: > > " > > ... > > Anticipating future work to revise RPL relating to how the LLN and > DODAG is configured, this document changes the interpretation of the > [dodagcfg] Registry to be limited to Mode-of-Operation (MOP) > specific. The MOP is described in [RFC6550] section 6.3.1. The > Options Flags Registry is renamed, and applies to MOP values zero (0) > to six (6) only, leaving the flags reserved for MOP value seven (7). > > In addition, this document reserves MOP value 7 for future expansion. > > ... > > 11.3. Change MOP value 7 to Reserved > > This document changes the allocation status of the Mode of Operation > (MOP) [ianamop] from Unassigned to Reserved. This change is in > support of future work related to capabilities. > " > > So basically we tell the implementations from now on to test if MOP is 7, and in that case, the Options Flags are undefined. In other words, if MOP is 7, the stack must not use the option flags as if the MOP was <7. In fact, 7 is no more a MOP value but a reserved thingy that can be overloaded in the future. And yes, we intend to do just that in MOPExt. > > Until that happens, implementations are at a loss if they encounter when a MOP field that is all ones. So we need to give them instructions to cope with the situation. This draft derives whether to use RFC 8138 from whether the 6LoWPAN compression applies to the link or not. Yes, we are saying "if you see a MOP field that is all ones, do this". To me, that seems like we want to be listed as an additional reference for MOP value 7 in the IANA registry. > This will stay true forever, unless another RFC amends it. When/if that happens, the new RFC will have to consider backward compatibility with a legacy implementation that implements the above. It will stay true forever (until amended), but how does a new person making an implementation know to find this document and do so? [useofrplinfo] says that MOP value 7 is special and needs dedicated handling, but it doesn't say anything about using 8138 [on links where 6LoWPAN Header Compression applies]. I'm missing the trail of breadcrumbs. Thanks, Ben > Note that this line of thought applies to 3 flags, defined respectively in: > - https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/ > - https://datatracker.ietf.org/doc/draft-ietf-roll-turnon-rfc8138/ > - https://datatracker.ietf.org/doc/draft-ietf-roll-unaware-leaves/ > > Keep safe! > > Pascal > > > > > Thanks, > > > > Ben > > > > On Wed, Sep 30, 2020 at 04:25:10PM +0000, Pascal Thubert (pthubert) wrote: > > > Hello Alvaro > > > > > > I uploaded both draft with the suggested update, please see > > > > > > https://tools.ietf.org/rfcdiff?url2=draft-ietf-roll-turnon-rfc8138-17. > > > txt > > > https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-unaware-leaves-21.tx > > > t > > > > > > Keep safe > > > > > > Pascal > > > > > > > -----Original Message----- > > > > From: Alvaro Retana > > > > Sent: jeudi 24 septembre 2020 17:49 > > > > To: Pascal Thubert (pthubert) > > > > Cc: Benjamin Kaduk ; The IESG ; > > > > draft-ietf- roll-turnon-rfc8138@ietf.org; Martin Duke > > > > ; Routing Over Low power and Lossy networks > > > > ; roll- chairs@ietf.org; Michael Richardson > > > > > > > > Subject: Re: [Roll] Benjamin Kaduk's Discuss on > > > > draft-ietf-roll-turnon-rfc8138- > > > > 14: (with DISCUSS and COMMENT) > > > > > > > > On September 24, 2020 at 8:13:09 AM, Pascal Thubert wrote: > > > > > > > > > > > > Pascal: > > > > > > > > Hi! > > > > > > > > > Following the meeting last Monday and subsequent the update of > > > > > useofrplinfo by Michael (thanks Michael!) I published a new > > > > > version of the turnon RFC > > > > > 8138 draft. > > > > > > > > > > The major changes are > > > > > - removed the formal update to RFC 6550 > > > > > - refer to useofrplinfo as the justification why the flag is not > > > > > defined for MOP 7 > > > > > - defined the operation in MOP 7 as compression on iff the Link > > > > > uses 6LoPWAN HC. > > > > > > > > Thanks for these changes. > > > > > > > > Because we have to cycle useofrplinfo back through (when the WG is > > > > done with it), I asked Ben/Martin to wait for that before coming > > > > back to this document.  It'll make it easier than tracking multiple > > > > changes. :-) > > > > > > > > > > > > OTOH, I do have comments on the recent change: > > > > > > > > OLD> > > > >    Section 4.3 of [USEofRPLinfo] updates [RFC6550] to indicate that > > > > the > > > >    definition of the Flags applies to Mode of Operation (MOP) values > > > >    zero (0) to six (6) only, leaving the flags reserved for MOP > > > > value > > > >    seven (7).  For a MOP value of 7, the bit in position 2 is > > > > considered > > > >    unallocated and [RFC8138] MUST be used on Links where 6LoWPAN > > > > Header > > > >    Compression [RFC6282] applies and MUST NOT be used otherwise. > > > > > > > > NEW> > > > > > > > >    Section 4.3 of [USEofRPLinfo] updates [RFC6550] to indicate that > > > > the > > > >    definition of the Flags applies to Mode of Operation (MOP) values > > > > zero (0) > > > >    to six (6) only.  For a MOP value of 7, [RFC8138] MUST be used on > > > > Links > > > >    where 6LoWPAN Header Compression [RFC6282] applies and MUST NOT > > > > be used > > > >    otherwise. > > > > > > > > > > > > Thanks! > > > > > > > > Alvaro. From nobody Wed Nov 11 01:47:45 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF6693A1020 for ; Wed, 11 Nov 2020 01:47:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=L7ZA3DhE; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=o8ltfU9l 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 A7IXCRIevljg for ; Wed, 11 Nov 2020 01:47:42 -0800 (PST) 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 104A33A1012 for ; Wed, 11 Nov 2020 01:47:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16389; q=dns/txt; s=iport; t=1605088062; x=1606297662; h=from:to:subject:date:message-id:mime-version; bh=XYp2mXNw1tz+mYsEC3WG+Ze0uPK6kGzJlexutwh5Z0Y=; b=L7ZA3DhEEcNQPdcDGgDA01in3mnskOxE8pvsKcac4vT0Gj51pkDNV6KZ wewj58HXBHV2aEaGMXxya+aEi9ZOx/hXw/y4G3HHLEb00z8BwjUyf5Ur/ vwhfnhmTKkKGxZyPDL5OeqJChc99m/5P51RP0C3cib8172OzaN/jwnxDx 8=; X-IPAS-Result: =?us-ascii?q?A0AYHgD8sqtffZNdJa1iHAEBATwBAQQEAQECAQEHAQGBZ?= =?us-ascii?q?AKBIS9Re1kvLgqEM4NJA40xlDqEb4JTA1QLAQEBDQEBLQIEAQGEY4F+AiU3B?= =?us-ascii?q?g4CAwEBAQMCAwEBAQEFAQEBAgEGBBQBAYY8AQuGCxEdAQE4EQFKAgQwJwQ1g?= =?us-ascii?q?wQBgX5XAy4BpDUCgTuIaHaBMoMEAQEFgkyCTRiCEAmBOAGCcoN1hlcbgUE/g?= =?us-ascii?q?RAoDBCKYjOCLJAsgzmHHYwNkBKBDAqCbZsRAx+hdpNRoE0CBAIEBQIOAQEFg?= =?us-ascii?q?WoigVlwFWUBgj5QFwINkhCKWHQ4AgYBCQEBAwl8jDsBgRABAQ?= IronPort-PHdr: =?us-ascii?q?9a23=3A8xkmCRbbKrac507+jvAo8W7/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el21QaTD4TW9/wCjPDZ4OjsWm0FtJCGtn1KMJlBTA?= =?us-ascii?q?QMhshemQs8SNWEBkv2IL+PDWQ6Ec1OWUUj8yS9Nk5YS8fze1OUpWe9vnYeHx?= =?us-ascii?q?zlPl9zIeL4UofZk8Ww0bW0/JveKwVFjTawe/V8NhKz+A7QrcIRx4BlL/U8?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.77,469,1596499200"; d="scan'208,217";a="601549030" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Nov 2020 09:47:15 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AB9lFEa020289 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 11 Nov 2020 09:47:15 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 11 Nov 2020 03:47:14 -0600 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 11 Nov 2020 03:47:14 -0600 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 11 Nov 2020 03:47:14 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=NMpGvDLIHFh1AqX3KNXOJjK7J6ZPOuSFxO3q9/7UGgZaGOX/cLBTqDHIHg1uZ9o8k16X0zhoR20/8lSL7uYPlT43++J2Cvjt99AKxm1eJwjNQE2tFxXwmbXm/4rDBMODj+z65aOv27pU9O+mObzyo+RFndyXjSgMz3pyVjE/YAsqA5bLl9lAyrjzdTEDBeKVRmfRF/3Pf+04Lix+6soX3y61/M4V1sKlymvwyo20a2Oj6+t+t+HXv2omdRApfNBPs9AGAXmpkyqr34tGppQMUPwtmhrLrX/LoXVwEaykGlhhuubWOaptjDQMyg22lYcnCqya1MPv0tJ/XClqu9BlLg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XYp2mXNw1tz+mYsEC3WG+Ze0uPK6kGzJlexutwh5Z0Y=; b=BqQ+GcRM3jJPV7giRSUGoXBToIveQE+Ed5O4n1Peku1sm2ghPEjKTqB4DAWpdvGej1ygf2jwWR2biL0JZzaEiISS1gO/40JYX6+4l70y4S87F7O4XQ46hfREnDaQfJ4BI05Pw4wkmH5mTLWYOYRhWf5pPJnFkjrkmWMHG14Q8OMjwme5WbKO56e+SOKEWJOK8+WpaP6fPJptSPtFcSHecOOYaO2xl2um5fXYPYdSNupNMOH0ZpgIUhcrlTjoqAgUnEOxzdmI00mf5IR9I9qeE3gCSTzIpmuh4a8tnclPERan4jYlsB23L6AhwD4GdCQKcDKwll8IJ4Z+8AAqBgUnkQ== 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=XYp2mXNw1tz+mYsEC3WG+Ze0uPK6kGzJlexutwh5Z0Y=; b=o8ltfU9leb8KWq7XXV4YfCSd3BRFhEKMpWdHm4Dn9sh14TX6Ism048ta/x5PMKhu5iOCflnOjYS/plMU1hNNtnKkkYwJtD91h6DmbX3YMT1D2RCAi0Mkxx/7UKg+/bcj72SVUn2clBN4PMIvVvIEPyVMjc8vmS/tCBLWdcxYYEc= Received: from DM6PR11MB3803.namprd11.prod.outlook.com (2603:10b6:5:141::30) by DM6PR11MB4329.namprd11.prod.outlook.com (2603:10b6:5:201::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3499.18; Wed, 11 Nov 2020 09:47:11 +0000 Received: from DM6PR11MB3803.namprd11.prod.outlook.com ([fe80::35e6:3f07:484f:c1bb]) by DM6PR11MB3803.namprd11.prod.outlook.com ([fe80::35e6:3f07:484f:c1bb%6]) with mapi id 15.20.3541.025; Wed, 11 Nov 2020 09:47:11 +0000 From: "Huimin She (hushe)" To: "roll@ietf.org" Thread-Topic: Comments/Questions for draft-ietf-roll-dao-projection Thread-Index: AQHWuA+gHxYXc9lzakOVsRXi0iJz+Q== Date: Wed, 11 Nov 2020 09:47:11 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [64.104.125.236] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d87fe00b-d04f-4a6a-9a0d-08d88626c37d x-ms-traffictypediagnostic: DM6PR11MB4329: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: yVoepY2Wus+VA7TNqcG+QIUhMCUKMGuUWFgFgklpGE1KOMZOpEdUn4dWnkyU3beQZwTXRoc0IVXqHd1gGGUJinkTzy03hyan5Hs0F0X4A0MLRAqaxUjMQe3aos28B5DmgCC392RI6SlYmGuktMDJmg7JamU4vgAu0vpQG03wxMWmKD2mg4LJDsKJCiN+v5rwDVGlKFIFJnZCMxC26BYxPzbndhb+JiovibYBgG0PSxF0qBT8mT732Q2cU7BX2PJcosFbiqupTVySrfvhzVsU/6YjNj4WhytCmpkRP2RW8j62o5+vdoE7H6oDuFC3v52jTNXFrZKJjatbAj1+Agae9A== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB3803.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(376002)(136003)(396003)(346002)(39860400002)(71200400001)(186003)(5660300002)(26005)(2906002)(478600001)(316002)(2616005)(91956017)(6916009)(6506007)(64756008)(66476007)(8936002)(83380400001)(76116006)(66446008)(66946007)(66556008)(8676002)(6512007)(86362001)(36756003)(33656002)(6486002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: GB1M/Axo/oS+8vSKXqf0tYx+oAnIXBxAWINghe5ut6pDFzXBa8h2r6qQ0tCG4YG/5L4YyBeSjrx3e6WfggIqBBljqQSGP4cFN7I4zt33QC/qPt9bHgl184TX3p1bqg1D9KOR9qiBLHC9sKU2oCaSJYothz5Gy7yDdDIHYMnL+gHhcuShrTkdgv7itLGJXVCX3x0Mt/SAe7U7hczExEZzb9MxS+lgatqWwiOQqg/AzP9rXpbCjVCJrzjorqhmcCNSEBFC1jFF65qudpwHfon537H+aMURmcPlCG/FP2vSHT/RI0SFrILAmgDC4Lg1zKXIrOrC6LVLOH5DOjX7HQ7yBgbF5c0qONrqWDx107K0cotM4N7tZBtA8FxsAvgfo8UIfDybyLu3p3B+L1eqnML4CFJfxTsyXRuAGQvr5Sgj9XcnRg88GNpTrUZcU8566uzHAyeggMhNAXbeCJeisoF3vlXIwRifmoXg0z2RAlVNcDruH2B8zYqgLtxln4xQx8mUtWMwLykR5HEATJ4wNNqlur8oZZirgATvWWMcpbv3vO8v0A8//6oL91g2bPPYceK24iyGYsVtfqli893jurjA8IJ09BbJRU6sPrXDgUfyYT73vl+N4W+55g+aof7rTo49zyA2QAwzRaBDQQsj55pKfg== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_F7190FB73F2C43119CA0C8A34923F472ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB3803.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d87fe00b-d04f-4a6a-9a0d-08d88626c37d X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Nov 2020 09:47:11.7983 (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: iQq5De5CFSPvQ5Ypmir6FuMGennw23EVNj7LVEYGp/FJBZ0dCBc28bpBOrVpdlEc X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB4329 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: [Roll] Comments/Questions for draft-ietf-roll-dao-projection 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, 11 Nov 2020 09:47:44 -0000 --_000_F7190FB73F2C43119CA0C8A34923F472ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQpJIHdvdWxkIGxpa2UgdG8gcHJvcG9zZSBhIGZldyBjb21tZW50cy9xdWVzdGlv bnMgZm9yIHRoZSBQLURBTyBkcmFmdC4NCg0KDQogIDEuICBMaWZldGltZSB1bml0OiBSZXFMaWZl dGltZSwgVHJhY2sgbGlmZXRpbWUsIGFuZCBTZWdtZW50IExpZmV0aW1lIGFyZSBkZWZpbmVkIGFz IDggYml0cy4gQW5kIHRoZWlyIGxpZmV0aW1lIFVuaXQgaXMgb2J0YWluZWQgZnJvbSB0aGUgRE9E QUcgY29uZmlndXJhdGlvbiBvcHRpb24uDQpJdCB3aWxsIGxlYWQgdG8gaW5mbGV4aWJpbGl0eSBh cyBhbGwgdHJhY2tzIGluIHRoZSBQQU4gdXNlIHRoZSBzYW1lIGxpZmV0aW1lIHVuaXQuIFdlIHBy b3Bvc2UgdG8gZGVmaW5lIGxpZmV0aW1lIHVuaXQgc2VwYXJhdGVseSBmb3IgZWFjaCB0cmFjayAo IGZvciBleGFtcGxlIGFkZGluZyBhIDItYml0IGZsYWcgdG8gaW5kaWNhdGUgc2Vjb25kLCBtaW51 dGUsIGhvdXIsIGRheSkuIERldGFpbHMgY2FuIGJlIGRpc2N1c3NlZCBsYXRlci4NCg0KDQogIDEu ICBOb3cgdGhlIFRyYWNrSUQgaGFzIHRoZSBzYW1lIG1lYW5pbmcgYXMgTG9jYWwgUnBsSW5zdGFu Y2VJRC4gSG93IGRvZXMgYSBub2RlIGp1ZGdlIHdoZXRoZXIgdGhlIHJlY2VpdmVkIG1lc3NhZ2Ug aXMgYSBQLURBTyBtZXNzYWdlIG9yIExvY2FsIFJQTCBpbnN0YW5jZSBEQU8gbWVzc2FnZT8NCg0K SXMgaXQgcG9zc2libGUgdG8gZGVmaW5lIGEgZmxhZyBpbiB0aGUgUC1EQU8gbWVzc2FnZT8NCg0K DQoNCiAgMS4gIFRoZSBQLURBTyB0cmFjay9zZWdtZW50IGlzIHNpbmdsZS1kaXJlY3Rpb25hbC4g SSBzdWdnZXN0IHRvIGFkZCB0aGUgcG9zc2liaWxpdHkgZm9yIGNyZWF0aW5nIGJpLWRpcmVjdGlv bmFsIHNlZ21lbnRzL3RyYWNrcy4gV2UgY2FuIGFkZCBhIGZsYWcgaW4gdGhlIFBEUiBtZXNzYWdl IHRvIGluZGljYXRlIHRoZSByZXF1ZXN0ZWQgdHJhY2sgaXMgc2luZ2xlLWRpcmVjdGlvbmFsIG9y IGJpLWRpcmVjdGlvbmFsLg0KDQoNCg0KICAxLiAgSSBzdWdnZXN0IHRvIGFkZCBhIGZsb3cgb2Yg bWVzc2FnZSBleGNoYW5nZXMgZm9yIOKAnFBEUiwgUERSLUFDSywgUC1EQU8sIFAtREFPIEFDS+KA nSBpbiB0aGUgZHJhZnQuDQoNClRoYW5rIHlvdS4NCg0KQmVzdCByZWdhcmRzLA0KSHVpbWluDQo= --_000_F7190FB73F2C43119CA0C8A34923F472ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <509AF17379F5D24B9B7EF67345543EB5@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6RGVuZ1hpYW47DQoJcGFub3NlLTE6 MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseToiSGVsdmV0aWNhIE5ldWUiOw0KCXBhbm9zZS0xOjIgMCA1IDMgMCAwIDAgMiAwIDQ7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiXEBEZW5nWGlhbiI7DQoJcGFub3NlLTE6MiAxIDYg MCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxp Lk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCWZvbnQtc2l6ZToxMi4w cHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5Nc29MaXN0UGFyYWdy YXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5 bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRvcDowY207DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCglt YXJnaW4tYm90dG9tOjBjbTsNCgltYXJnaW4tbGVmdDozNi4wcHQ7DQoJZm9udC1zaXplOjEyLjBw dDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUx Nw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxp YnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7 bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2 MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpk aXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlv bnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjU2MzY3NzUzOw0KCW1zby1saXN0LXR5cGU6 aHlicmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxNzQwODI1MDU4IDY1Mjc5Mzk5NCA2NzY5 ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcx MyA2NzY5ODcxNTt9DQpAbGlzdCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRleHQ6IiUxXCkiOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0Ow0KCW1zby1hc2NpaS1mb250LWZhbWlseTpDYWxpYnJp Ow0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCW1zby1oYW5zaS1mb250LWZh bWlseTpDYWxpYnJpOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30N CkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0K QGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxl dmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2 ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93 ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6 OTA4NjE5NjA7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0xNzU0ODg0Mjg4O30NCkBsaXN0IGwy DQoJe21zby1saXN0LWlkOjE4ODU2NjQ1NTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MjY0NDg4 ODt9DQpAbGlzdCBsMw0KCXttc28tbGlzdC1pZDo3NjM1MjY4MjQ7DQoJbXNvLWxpc3QtdHlwZTpo eWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE1OTY1OTg0NjAgMTEwMDM3NDgxMCA2NzY5 ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcx MyA2NzY5ODcxNTt9DQpAbGlzdCBsMzpsZXZlbDENCgl7bXNvLWxldmVsLXRleHQ6JTE7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0KQGxpc3QgbDM6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0 IGwzOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0K CXRleHQtaW5kZW50Oi05LjBwdDt9DQpAbGlzdCBsMzpsZXZlbDQNCgl7bXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0xOC4wcHQ7fQ0KQGxpc3QgbDM6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFs cGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwzOmxldmVsNg0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50 Oi05LjBwdDt9DQpAbGlzdCBsMzpsZXZlbDcNCgl7bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0xOC4wcHQ7fQ0K QGxpc3QgbDM6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwzOmxldmVsOQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50Oi05LjBwdDt9DQpA bGlzdCBsNA0KCXttc28tbGlzdC1pZDo5OTAxODM3MzU7DQoJbXNvLWxpc3QtdHlwZTpoeWJyaWQ7 DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi03NTUxOTM3ODggNjc2OTg3MDMgNjc2OTg3MTMgNjc2 OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3 MTU7fQ0KQGxpc3QgbDQ6bGV2ZWwxDQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0 IGw0OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28t bGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsNDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3Qg bDQ6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGw0OmxldmVsNQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LTE4LjBwdDt9DQpAbGlzdCBsNDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9t YW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDQ6bGV2ZWw3DQoJ e21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGw0OmxldmVsOA0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpA bGlzdCBsNDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdo dDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDUNCgl7bXNvLWxpc3QtaWQ6MTUwOTI5 NTAzODsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTkx MTE1MzcxNiAzNDc1MjQ5NjQgNjc2OTg3MTMgNjc2OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2 OTg3MTUgNjc2OTg3MDMgNjc2OTg3MTMgNjc2OTg3MTU7fQ0KQGxpc3QgbDU6bGV2ZWwxDQoJe21z by1sZXZlbC10ZXh0OiUxOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGw1Omxl dmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsNTpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDU6bGV2 ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGw1OmxldmVsNQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9u ZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBw dDt9DQpAbGlzdCBsNTpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93 ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDU6bGV2ZWw3DQoJe21zby1s ZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGw1OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBs NTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0 ZXh0LWluZGVudDotOS4wcHQ7fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFy Z2luLWJvdHRvbTowY207fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9ImVuLUNO IiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv bjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij5IaSBhbGwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkkgd291bGQgbGlrZSB0byBwcm9wb3Nl IGEgZmV3IGNvbW1lbnRzL3F1ZXN0aW9ucyBmb3IgdGhlIFAtREFPIGRyYWZ0LjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPG9sIHN0 eWxlPSJtYXJnaW4tdG9wOjBjbSIgc3RhcnQ9IjEiIHR5cGU9IjEiPg0KPGxpIGNsYXNzPSJNc29M aXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGNtO21zby1saXN0Omw0IGxldmVsMSBs Zm82Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkxpZmV0aW1l IHVuaXQ6IFJlcUxpZmV0aW1lLCBUcmFjayBsaWZldGltZSwgYW5kIFNlZ21lbnQgTGlmZXRpbWUg YXJlIGRlZmluZWQgYXMgOCBiaXRzLiBBbmQgdGhlaXIgbGlmZXRpbWUgVW5pdCBpcyBvYnRhaW5l ZCBmcm9tIHRoZSBET0RBRw0KIGNvbmZpZ3VyYXRpb24gb3B0aW9uLjxvOnA+PC9vOnA+PC9zcGFu PjwvbGk+PC9vbD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+SXQgd2lsbCBsZWFkIHRvIGluZmxleGliaWxpdHkgYXMgYWxs IHRyYWNrcyBpbiB0aGUgUEFOIHVzZSB0aGUgc2FtZSBsaWZldGltZSB1bml0LiBXZSBwcm9wb3Nl IHRvIGRlZmluZSBsaWZldGltZSB1bml0IHNlcGFyYXRlbHkgZm9yIGVhY2ggdHJhY2sgKCBmb3Ig ZXhhbXBsZSBhZGRpbmcgYSAyLWJpdCBmbGFnIHRvIGluZGljYXRlIHNlY29uZCwNCiBtaW51dGUs IGhvdXIsIGRheSkuIERldGFpbHMgY2FuIGJlIGRpc2N1c3NlZCBsYXRlci48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxvbCBzdHls ZT0ibWFyZ2luLXRvcDowY20iIHN0YXJ0PSIyIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNvTGlz dFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBjbTttc28tbGlzdDpsNCBsZXZlbDEgbGZv NiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5Ob3cgdGhlIFRy YWNrSUQgaGFzIHRoZSBzYW1lIG1lYW5pbmcgYXMgTG9jYWwgUnBsSW5zdGFuY2VJRC4gSG93IGRv ZXMgYSBub2RlIGp1ZGdlIHdoZXRoZXIgdGhlIHJlY2VpdmVkIG1lc3NhZ2UgaXMgYSBQLURBTyBt ZXNzYWdlIG9yIExvY2FsDQogUlBMIGluc3RhbmNlIERBTyBtZXNzYWdlPyA8bzpwPjwvbzpwPjwv c3Bhbj48L2xpPjwvb2w+DQo8cCBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCI+PHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JcyBpdCBwb3NzaWJsZSB0byBkZWZpbmUg YSBmbGFnIGluIHRoZSBQLURBTyBtZXNzYWdlPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29MaXN0UGFyYWdyYXBoIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxvbCBzdHlsZT0ibWFyZ2lu LXRvcDowY20iIHN0YXJ0PSIzIiB0eXBlPSIxIj4NCjxsaSBjbGFzcz0iTXNvTGlzdFBhcmFncmFw aCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBjbTttc28tbGlzdDpsNCBsZXZlbDEgbGZvNiI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaGUgUC1EQU8gdHJhY2svc2Vn bWVudCBpcyBzaW5nbGUtZGlyZWN0aW9uYWwuIEkgc3VnZ2VzdCB0byBhZGQgdGhlIHBvc3NpYmls aXR5IGZvciBjcmVhdGluZyBiaS1kaXJlY3Rpb25hbCBzZWdtZW50cy90cmFja3MuIFdlIGNhbiBh ZGQNCiBhIGZsYWcgaW4gdGhlIFBEUiBtZXNzYWdlIHRvIGluZGljYXRlIHRoZSByZXF1ZXN0ZWQg dHJhY2sgaXMgc2luZ2xlLWRpcmVjdGlvbmFsIG9yIGJpLWRpcmVjdGlvbmFsLjxvOnA+PC9vOnA+ PC9zcGFuPjwvbGk+PC9vbD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxvbCBzdHlsZT0ibWFyZ2luLXRvcDowY20iIHN0YXJ0PSI0IiB0eXBlPSIxIj4NCjxs aSBjbGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9Im1hcmdpbi1sZWZ0OjBjbTttc28tbGlz dDpsNCBsZXZlbDEgbGZvNiI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij5JIHN1Z2dlc3QgdG8gYWRkIGEgZmxvdyBvZiBtZXNzYWdlIGV4Y2hhbmdlcyBmb3Ig4oCc UERSLCBQRFItQUNLLCBQLURBTywgUC1EQU8gQUNL4oCdIGluIHRoZSBkcmFmdC48bzpwPjwvbzpw Pjwvc3Bhbj48L2xpPjwvb2w+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaGFu ayB5b3UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g bGFuZz0iRU4tVVMiIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPkh1aW1pbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_F7190FB73F2C43119CA0C8A34923F472ciscocom_-- From nobody Wed Nov 11 01:59:22 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37BF73A0DDC; Wed, 11 Nov 2020 01:59:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 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_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=arEUV6wC; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=kt6B06fX 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 QnBd5BpMIH4g; Wed, 11 Nov 2020 01:59:18 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 961C23A00E3; Wed, 11 Nov 2020 01:59:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14468; q=dns/txt; s=iport; t=1605088758; x=1606298358; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=m1p9OBhRi+e7TaTuTnINpMSCrCvPGMaD0lbWwFpKa18=; b=arEUV6wCITk+7Vo71jNlI5bz2P+SGEBjVdO7E9xaHo6JQcMIBzfKTPB+ XBmrTBqPOBDU+VlmL1Fqhzesk1ROaXjS3DDx0W3xMDLew7iJ+WJA3DJ8J bBrZKYtYDDZ2cIRcIKC5YVghTrfDCYnRmqp7dP5O3B6+0+eSn/NNzfeLH 0=; X-IPAS-Result: =?us-ascii?q?A0DvAQA1tKtf/5BdJa1iGwEBAQEBAQEBBQEBARIBAQEDA?= =?us-ascii?q?wEBAUCBT4FSUQd0WS8uhD2DSQONVooWjm2BQoERA1QLAQEBDQEBIwoCBAEBg?= =?us-ascii?q?VWCdQIXgX4CJTgTAgMBAQEDAgMBAQEBBQEBAQIBBgRxhWEMhXIBAQEBAgESE?= =?us-ascii?q?REMAQE3AQQHBAIBBgIRBAEBAQICHwQDAgICHxEUAQgIAgQOBQgagwWCVQMOI?= =?us-ascii?q?AEOkz+QagKBO4hodoEygwQBAQWBNwIOQYMRDQuCEAMGgQ4qgnOCZU5CgQaFU?= =?us-ascii?q?RuBQT+BEUOCTz6CG0ICAgEBFYEdCwQLEYMVM4Isi3eEHimCaQE9kyqQSlQKg?= =?us-ascii?q?m2JDYwBcIU1gxmKFYVMiSCFXJVQiH2Cbo4whDMCBAIEBQIOAQEFgWsjgUEPB?= =?us-ascii?q?3AVgyRQFwINjh8MFxSDOoUUhUR0AjYCBgEJAQEDCXyLBgImgT5gAQE?= IronPort-PHdr: =?us-ascii?q?9a23=3AhdLZBhNUHX0Br0b0q60l6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEvKwx3lDMVITfrflDjrmev6PhXDkG5pCM+DAHfYdXXh?= =?us-ascii?q?AIwcMRg0Q7AcGDBEG6SZyibyEzEMlYElMw+Xa9PBtaHc//YxvZpXjhpTIXEw?= =?us-ascii?q?/0YAxyIOm9E4XOjsOxgua1/ZCbYwhBiDenJ71oKxDjpgTKvc5Qioxneas=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.77,469,1596499200"; d="scan'208";a="578514874" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Nov 2020 09:59:17 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AB9xH3K000730 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 11 Nov 2020 09:59:17 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 11 Nov 2020 03:59:16 -0600 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 11 Nov 2020 03:59:15 -0600 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 11 Nov 2020 03:59:15 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=F8Yr570JQNvYNw+UCuZaO+6NtdOWGOEyt96qmF+XTY+FdVVspQljGxa/ZdimTcvshDVvwbJ2JmWx7+QNZdLuCic7uwq7q4cdYC3f0ybZ30aZuYWTwFs325p+gj27ahvRH6g2HYScg1lPmKvsHwpU/gTYDQXkxXIkhrNNEFvLm89nBr13hYWEMy0DsjnrU0mbtBSkoqJDkny1VpHbHDP9uzsorACaciISXOl4D1jR22cH3u0WZgG37cSh5raEhmOYywTGyNbuZextqZ0bMNHYPwtuoIbI06PRLMuI64Tr2/2ylr/oAB9HrlCAKyFXXP3J/LJoisDTxfyT3ip942dylg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=m1p9OBhRi+e7TaTuTnINpMSCrCvPGMaD0lbWwFpKa18=; b=CZR35xAt94IaP/4nfoD7k4CLMvomRjVyc7Z4sueiBS9194yo0LOEAxqD4yveVHAvtxn2WctDaPEzdxOiC93bTnkxXD6nJaidyKb31uu7hCHs1AHz5l1O9uYvdWtBhr86bVKuPlN80h6ihBGl9jZ+pRCWKzPh8+gclI4hfCcQEGrrTY3DqZVFpKImOoXKkZtXZX4R+AAWnc+Cn7LZ0ukHnlYfyxC8zyrhl5NafPofN/r0dsPzxdLTkxPvjzOiR5ONg6oGu66qbiaorOykAKFnMBYhIEBzH1w1kV4OU0MZIZ/mvZoBz/drMkjfOg/jidmThWs1071rfm4a6kqm1upcKw== 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=m1p9OBhRi+e7TaTuTnINpMSCrCvPGMaD0lbWwFpKa18=; b=kt6B06fXNJcwVQQwx2MdiSDNPIuSGxHEdIrH1RdfVIszeSLQNchcibQeIz/yoxCh6k4iTnizo4ORgs9y399PA0drr+RS+Gb/rJlGnoqP8c2BWYv+CkEN4ZtGuVy4hJk3QaY2Fz7L5HywwRQhTUkVQBvUVfE0VpkjmZw1jqs/EmQ= Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by MWHPR11MB0030.namprd11.prod.outlook.com (2603:10b6:301:65::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.21; Wed, 11 Nov 2020 09:59:14 +0000 Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::ad88:1b7e:c9f2:b30d]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::ad88:1b7e:c9f2:b30d%6]) with mapi id 15.20.3541.025; Wed, 11 Nov 2020 09:59:14 +0000 From: "Pascal Thubert (pthubert)" To: Martin Duke CC: Benjamin Kaduk , Alvaro Retana , The IESG , "draft-ietf-roll-turnon-rfc8138@ietf.org" , "Routing Over Low power and Lossy networks" , "roll-chairs@ietf.org" , Michael Richardson Thread-Topic: [Roll] Benjamin Kaduk's Discuss on draft-ietf-roll-turnon-rfc8138-14: (with DISCUSS and COMMENT) Thread-Index: AQHWhvbDFnz+ZxCN2kqfSLm4/QQEM6lhafFggADkOACAAVPGAIAAAK+AgAAvlRyACqqkkIAAO8YAgAAzb6aAAAQpAIAAVGSAgAiD2ECAAD3vgIAJd1hAgD+ZLwCAAEVDsIABBNkAgACsepA= Date: Wed, 11 Nov 2020 09:59:03 +0000 Deferred-Delivery: Wed, 11 Nov 2020 09:58:46 +0000 Message-ID: References: <20200911162617.GQ89563@kduck.mit.edu> <8F19C753-DCA0-4A32-BA3B-A124B2F7F745@cisco.com> <117497.1600481093@dooku> <20201110033438.GE39170@kduck.mit.edu> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2a01:cb1d:4ec:2200:a4ce:26bc:deb6:b0f1] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: cdc9f46c-206e-445c-b097-08d88628721a x-ms-traffictypediagnostic: MWHPR11MB0030: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: On/F92HQev663VuArM43HbtaKwa0Q5porye8ASzFOxYZpUyuybRA71jNd/pfHWdJgPz1XAmi2c32fLaMsDDj4w4ER4Ya5rS29BYHOBRD+REiPXYEBCf5UTCvaeUvteUkqJTOSfO0NGQqFXsU/MnYq/fP0sSqbKIdbIg52zcaWhe8zwKtkHT5cnkgppSaqH8ngV6/iEINNTqw/XIkLSuYyJ/OZJNkzA9JegdgNwSQzeTztzQTMBkD4NY4DMR9f1nuOURQGo2PU7GErmRZRHq5jI5avdnQm/sp+j+49N5yLZrDT4HXDHY6hdOzjanNUh6TuXEUohaW25A/HiEAkr4TFFTFHYZkNzxeTqrqFu6UfpMZLX1haD6sPF9Rmr0lsRdC4BBBotKYtLuz1Zn7eUVQfw== 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:(396003)(136003)(366004)(376002)(39860400002)(346002)(7696005)(4326008)(53546011)(6666004)(316002)(9686003)(66446008)(8676002)(64756008)(66556008)(478600001)(966005)(33656002)(66946007)(54906003)(55016002)(186003)(83380400001)(52536014)(86362001)(76116006)(6916009)(66476007)(2906002)(71200400001)(5660300002)(6506007)(8936002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?bkFia1R2YUhHd29CdGwwOWVpcStxaEsyTWRvcDJtWWMyTFRWR2FXM1ZVV0I2?= =?utf-8?B?OUFWZ3lJLzVPSVdxVk1jZ1kySVVoODk3ZExMSmM3c0dQbGJ3UFJobC9RcVBv?= =?utf-8?B?MkZzU2pTSnFtcnZqZks5amkzbGpZSm1WZEVrTmxlczRGNGVNSmNZZGQ1NWJs?= =?utf-8?B?cERRbEx6TGlCREF6c0wyU0JQcDVadTB5QlVUdlE0eEVMMzU0MXZCNlRWaHVr?= =?utf-8?B?Q1BQQTczTW9WaHpiLzA1UnVuWmNySWtNM0VXYk82M2wvT00zbnNYY1BKU09a?= =?utf-8?B?VGhBSUE2dHQ1U2tyZDdRcWRISXpnYUpjRmJ1YkltenVuVXdIZkxucGMyNWFP?= =?utf-8?B?R2tsN1d1bGlhYSs0SlhIWmpyZzBlLy9qTmZUTjIydFdxME5PNEY4OC9qSkJI?= =?utf-8?B?TkxBdXJFdXN3UnByMVVwVEVVQ3ZLNGhTMEx5STYwKzdlbWVYTmRPZ1BqUkhG?= =?utf-8?B?UnhIcHZaSThEWVlER1FaLzJ5dUtxNUJVR0tvVmZWY1JsQWxSWWFwbDVwMldt?= =?utf-8?B?bVVaOHdLRnh2ODRENVlXdHZMKzlBTkpGc040SllmMjdFL3JNcGk4bjBPYWpF?= =?utf-8?B?azVGSGo5Q05UZElrMkVRWnRmNkM2MkZ5SUdtTDRTbWdXZFJWL2Yva3lxTElr?= =?utf-8?B?Q20vV3NieVlZQXZWWXo3YnNGV2dqZXVzQlJoUWFsM3NYdGkwNGdEMWNkL3Rp?= =?utf-8?B?YmN1eFArRFo4NURMTnpjcFNFeFNJeUlFZVg5cFhaZDJXUzlRcGE4TVIyS3FF?= =?utf-8?B?d1RWeEw0N0Q0b1Y5ZGVpOGNRT0F4M2swN1h1dGU4aC9lajJnUHRWVVRSWStB?= =?utf-8?B?c1dkZUtrQXl1TEZYbHNWMWpBWUpVRmcvd1N0Yk5VSkU0N25xbmN4RUp5MCsw?= =?utf-8?B?SnMvSklSSWowR1FUZXQxeXFzM0daREdTNlRmei92Z1gxeWxlNVNDZzBNSTd5?= =?utf-8?B?ZXlCT0Jzb25tU3pCQXhFM2lpbkxmSnBqR09aYTd4UGJMUTMxS1ZzdEwxbTY1?= =?utf-8?B?M0ZycG5zSHFZT2RoUThjTU95Y0krZFlKbXpPclo1clpLOGoycDRZV1NMTzJo?= =?utf-8?B?MHNDOGtOUjY0SEZWWUcyRWlOVVlNcnZUSUFzeUZNU3piSXkwSGU1eFZEWm5T?= =?utf-8?B?aFBYU0dUL21oRzZ4ZTVVUjZONEVIQTR6L3dHd2xTR0hJUG02L1pIZ3ZFcFlZ?= =?utf-8?B?TXhZWVk4UTQ5VHE5aUt6QUJURDRrMmc2dmdrVW4zVnBRYUFsVi9MOGhnbENv?= =?utf-8?B?VjBpbnVSelBNZG9jbDV6RkltV0V6ZHl0M3JoWUdjNGtnZ1BnZz09?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB4881.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: cdc9f46c-206e-445c-b097-08d88628721a X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Nov 2020 09:59:14.2985 (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: qQr3m2lgASaEs46tfBhhVI54TQaPxk1iqtENnhQ661r/3cGG6/0jEIeWpFmT5YLVOdO+6YFO+8A7Rrk6JtmMUg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB0030 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: rcdn-core-8.cisco.com Archived-At: Subject: Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf-roll-turnon-rfc8138-14: (with DISCUSS and COMMENT) 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, 11 Nov 2020 09:59:21 -0000 SGVsbG8gTWFydGluDQoNCkZpcnN0IG9mIGFsbCB5b3UgYXJlIGNvcnJlY3QgdGhhdCB0aGUgd2hv bGUgZ2FtZSBpcyB0byByZWNvdmVyIHRoZSBiaXRzIGZvciBSUEx2Miwgd2l0aCB0aGUgaWRlYSB0 aGF0IHRoZSBmZWF0dXJlcyB0aGF0IHRoZXkgc2lnbmFsZWQgd2lsbCBiZSBpbnN0YWxsZWQgYW5k IHRoYXQgc2lnbmFsaW5nIHRoZSB0cmFuc2l0aW9uIHdpbGwgYmUgYSB3YXN0ZS4gQWxzbyBSUEwg aGFzIHZlcnkgZmV3IG9mIHRoZXNlIGZsYWdzIGF2YWlsYWJsZSBpbiB0aGUgY29uZmlndXJhdGlv biBvcHRpb24gYW5kIHRoZSBncm91cCBpbnNpc3RlZCBvbiBnZXR0aW5nIHRoZW0gYmFjayBhZnRl ciB0aGUgdHJhbnNpdGlvbi4gDQoNClNlY29uZCBpcyB0byB0aGFuayB5b3UgZm9yIHlvdXIgY2Fy ZSAvIHRoZSBkZXB0aCBvZiB5b3VyIGF0dGVudGlvbiBvbiB0aGF0IGlzc3VlLiBJdCBpcyBpbmRl ZWQg4oCcdG91Y2h54oCdLiBBbmQgaXQgc3BhbnMgMyBkcmFmdHMgdGhhdCBhcmUgZ29pbmcgdGhy b3VnaCBJRVNHIGluIHRoZSBzYW1lIHdpbmRvdyBvZiB0aW1lLg0KDQpMZXTigJlzIHNlZSBiZWxv dw0KDQo+IFdlIHdpbGwgZXZlbnR1YWxseSBnZXQgdGhlcmUsIGJ1dCB0aGlzIHdpbGwgbmV2ZXIg c3RvcCBiZWluZyB3ZWlyZCB0byBtZS4gOi0pDQoNCj4gSW1hZ2luZSA1IHR5cGVzIG9mIERPREFH IG5vZGVzOg0KDQpJIHJlYWQgdGhleSBzdXBwb3J0IHRoZSBiZWxvdyBhcyBvcHBvc2VkIHRvIHRo ZSBET0RBRyBpcyBkZXBsb3llZCB3aXRoIHRoZSBiZWxvdy4NCg0KVHlwZSAgICAgODEzOD8gdGhp cyBkcmFmdD8gTU9QNT8gIE1PUCA3PyANCi0tLS0tLS0gICAgICAtLS0tLS0tICAgLS0tLS0tLS0t LS0tICAgIC0tLS0tLS0tICAgLS0tLS0tLS0tLSAgDQogQSAgICAgICAgICAgICBOICAgICAgICAg ICAgICBOICAgICAgICAgICAgIE4gICAgICAgICAgIE4gICAgICAgIA0KQiAgICAgICAgICAgICAg WSAgICAgICAgICAgICAgTiAgICAgICAgICAgICBOICAgICAgICAgICBODQpDICAgICAgICAgICAg ICBZICAgICAgICAgICAgICBZICAgICAgICAgICAgIE4gICAgICAgICAgIE4NCkQgICAgICAgICAg ICAgIFkgICAgICAgICAgICAgIFkgICAgICAgICAgICAgWSAgICAgICAgICAgIE4NCkUgICAgICAg ICAgICAgIFkgICAgICAgICAgICAgIFkgICAgICAgICAgICAgIFkgICAgICAgICAgIFkNCg0KPiBT byBpZiBJSVVDLCB0aGUgY3VycmVudCBzdGF0ZSBvZiBwbGF5IGlzIHRoYXQgQiBjYW4ndCBncmFj ZWZ1bGx5IGRlcGxveSBpbnRvIGEgbmV0d29yayB3aXRoIEEsIGJlY2F1c2UgdGhleSBoYXZlIHRv IGJlIHN0YXRpY2FsbHkgY29uZmlndXJlZCB0byBub3QtY29tcHJlc3MuDQoNCk9yIHlvdSBuZWVk IHNvbWUgbWFuYWdlbWVudCBvdXRzaWRlIG9mIFJQTCB3aGljaCBpcyBhZ2FpbnN0IHRoZSBjb3Jl IGRlc2lnbiBwb2ludCB0aGF0IFJQTCBzaG91bGQgYmUgYXV0b25vbWljL3NlbGYtY29uZmlndXJp bmcNCg0KPiBBcyBsb25nIGFzIEIgaXMgdXBncmFkZWQgdG8gdGhpcyBkcmFmdCAoQyksIGl0IGNh biBncmFjZWZ1bGx5IGRlcGxveSBpbiBhIG5ldHdvcmsgd2l0aCBBLCBiZWNhdXNlwqBjb21wcmVz c2lvbiB3aWxsIHJlbWFpbiBvZmYgdW50aWwgYWxsIHRoZSBBIGlzIGdvbmUuIEMgYW5kIEIgY2Fu IGZ1bmN0aW9uIHRvZ2V0aGVyIHdpdGhvdXQgdGhpcyBkcmFmdCwgYnV0IHRoZXkgd29uJ3QgYmUg YWJsZSB0byBkeW5hbWljYWxseSBjaGFuZ2UgY29tcHJlc3Npb24gc3RhdGUsIEZXSVcNCg0KWWVz LCB0aGF0IGlzIHRoZSB0cmFuc2l0aW9uIHBoYXNlDQoNCj4gIFNpbWlsYXJseSwgYSBoeXBvdGhl dGljYWwgRCBjYW4gZ3JhY2VmdWxseSBkZXBsb3kgd2l0aCBBLCBhcyBpdCB3aWxsIGhhdmUgdXNl IG9mIHRoZXNlIGZsYWdzLCBidXQgZG9lc24ndCByZWFsbHkgbmVlZCB0aGUgZmxhZ3MgdG8gd29y ayB3aXRoIEIgb3IgQyB1bmxlc3MgeW91IHdhbnQgdG8gZHluYW1pY2FsbHkgY2hhbmdlIHN0YXRl IGZvciBzb21lIHJlYXNvbi4NCg0KVW5jbGVhciB3aGF0IHlvdSBtZWFuLiBJZiB0aGUgRE9EQUcg aXMgZGVwbG95ZWQgd2l0aCBhIE1PUCA8IDUgRCBpcyBhIEMuIElmIHRoZSBNT1AgaXMgNSwgbm9k ZXMgQSwgQiwgYW5kIEMgd2lsbCBoYXZlIHRvIGJlIGxlYXZlcywgYW5kIHRoZSBmbGFnIHdpbGwg c3RpbGwgYmUgb2ZmIGFzIGxvbmcgYXMgdGhlcmUncyBhbiBBIGluIHRoZSBuZXR3b3JrLCBlbHNl IHRoYXQgQSB3aWxsIGJlIGlzb2xhdGVkLg0KDQo+IE1lYW53aGlsZSwgRSB3aWxsIG5vdCBiZSBh YmxlIHRvIGdyYWNlZnVsbHkgZGVwbG95IHdpdGggQSwgYmVjYXVzZSBpdCBkb2VzIG5vdCBoYXZl IGEgbWVhbnMgdG8gY2hhbmdlIGl0cyBjb21wcmVzc2lvbiBzdGF0ZSB1c2luZyB0aGUgRE9EQUcg Y29uZmlndXJhdGlvbi4gQnV0IGJlY2F1c2Ugb2YgdGhlIHNlbnRlbmNlIHdlJ3ZlIGRpc2N1c3Np bmcgaW4gdGhpcyB0aHJlYWQsIG5ldHdvcmtzIHdpdGggQyBhbmQgRCB3aWxsIGhhdmUgbm8gcHJv YmxlbSBiZWNhdXNlIHRoZXkgaGF2ZSB0aGlzIHRleHQgdG8gaGVscCB0aGVtIGRlY2lkZSB3aGV0 aGVyIG9yIG5vdCB0byBjb21wcmVzcy4gVGhleSB3aWxsIG5vdCBoYXZlIHRoZSBhYmlsaXR5IHRv IGR5bmFtaWNhbGx5IGNoYW5nZSBjb21wcmVzc2lvbiBzdGF0ZS4NCg0KU2FtZSBhcyBhYm92ZSwg aWYgdGhlIE1PUCBpcyA8NywgdGhlIGZsYWcgc3RpbGwgd29ya3MsIGV2ZW4gaWYgRSBpcyBjYXBh YmxlIG9mIHNvbWUgbmV3IE1PUEV4dCBNT1BzLiBJZiB3ZSB1c2UgYSBNT1BleHQgKHNpZ25hbGVk IGJ5IE1PUD03KSwgYW5kIGlmIHRoZXJlIGFyZSBub2RlcyBvZiB0eXBlIEEgaW4gdGhlIG5ldHdv cmssIHRvc2Ugbm9kZXMgb2YgdHlwZSBBIHdpbGwgYmUgbGVhdmVzIGFuZCB0aGV5J2xsIGJlIGlz b2xhdGVkLCB1bmxlc3MgdGhleSB0dXJuIGludG8gUlBMLXVuYXdhcmUtbGVhdmVzLCBmcm9tIHdo aWNoIGNvbXByZXNzaW9uIGlzIG5vdCBleHBlY3RlZC4NCg0KPiBTbyBJIGd1ZXNzIHRoZSB2YWx1 ZSBvZiB0aGUgTU9QIDcgYmVoYXZpb3IgaXMuLi4gdG8gcmVjb3ZlciB0aGUgYml0IG9mIHRoZSBm bGFncz8gRmluZSwgSSBzdXBwb3NlLCBidXQgdGhpcyB3b3VsZCBhcHBlYXIgdG8gaGF2ZSB0d28g Y29zdHM6DQpZZXMNCg0KPiAxKSBJZiBBIGlzIHN0aWxsIG91dCB0aGVyZSB3aGVuIEUgZGVwbG95 cywgdGhpcyBiaXQgd291bGQgaGF2ZSBiZWVuIHVzZWZ1bCwgYnV0IGlzbid0Lg0KSXQncyBub3Qg d2hlbiBFIGRlcGxveXMsIGl0IGlzIHdoZW4gdGhlIERPREFHIGlzIGRlcGxveWVkIG9yIHVwZ3Jh ZGVkIHdpdGggYSBNT1AgNy4gDQoNCj4gMikgSSBoYXZlIG5vIGlkZWEgaWYgdGhlICJkeW5hbWlj IGNoYW5nZSBpbiBjb21wcmVzc2lvbiBzdGF0ZSIgdXNlIGNhc2UgaXMgdmFsdWFibGUgaXQgYWxs LCBidXQgaXQgd291bGQgY2VydGFpbmx5IGZvcmVjbG9zZSB0aGUgcG9zc2lsYmlsdHkuDQpXZSBk ZWZpbmVkIHRoaXMgZmxhZyB0byBlbmFibGUgdGhlIGFjdGl2YXRpb24gb2YgdGhlIGNvbXByZXNz aW9uIGluIGEgYnJvd24gZmllbGQuIFJpZ2h0IG5vdyB3ZSBoYXZlIG1pbGxpb25zIG9mIG5vZGVz IGRlcGxveWVkLCBhbGwgb2YgdHlwZSBBLiB0eXBpY2FsbHkgdXRpbGl0eSBBTUkgbWV0ZXJzLiBI YXZpbmcgdG8gaW1wb3NlIGEgZmxhZyBkYXkgdG8gbWlncmF0ZSB0byB0aGUgY29tcHJlc3Npb24g aXMgbm90IGFjY2VwdGFibGUgdG8gb3VyIHVzZXJzLiBTbyB3ZSBkbyBub3QgZXZlbiBwcm9wb3Nl IGl0LiBhbmQgdGhlIHNpdHVhdGlvbiBpcyBzdHVjay4gSWYgd2UgaGF2ZSBhIG1pZ3JhdGlvbiBz Y2VuYXJpbyB3aXRob3V0IGEgZmxhZyBkYXksIHdlIGNhbiBzaGlwIHRoZSBjb21wcmVzc2lvbiBp biBzb2Z0d2FyZSByZWZyZXNoZXMsIGFuZCBsZXQgdGhlIGN1c3RvbWVyIGRlY2lkZSBpZiBhbmQg d2hlbiB0byB0dXJuIG9uLiANCg0KPiBEbyBJIGhhdmUgdGhpcyByaWdodD8NCg0KWW91IGRvIPCf mIoNCg0KUGFzY2FsDQoNCg0KT24gVHVlLCBOb3YgMTAsIDIwMjAgYXQgMTI6MTUgQU0gUGFzY2Fs IFRodWJlcnQgKHB0aHViZXJ0KSA8bWFpbHRvOnB0aHViZXJ0QGNpc2NvLmNvbT4gd3JvdGU6DQpI ZWxsbyBCZW5qYW1pbjoNCg0KPiBUaGF0IHNhaWQsIGFuZCBteSBhcG9sb2dpZXMgZm9yIGEgaGF6 eSBtZW1vcnkgY29taW5nIGJhY2sgdG8gdGhpcyBhZnRlciBhDQo+IGNvdXBsZSBtb250aHMsIGlu IGEgeWVhciBvciBOIGZyb20gbm93IHdoZW4gbW9wZXggaXMgZmluYWxpemVkLCBob3cgd2lsbA0K PiBzb21lb25lIGxvb2tpbmcgYXQgbW9wZXgga25vdyB0byB1c2UgUkZDODEzOCBvbiBsaW5rcyB3 aGVyZSA2TG9XUEFODQo+IEhlYWRlciBDb21wcmVzc2lvbiBhcHBsaWVzIChhbmQgbm90IHVzZSBp dCBvdGhlcndpc2UpP8KgIFdlIGFyZSBjbGFpbWluZyBpbg0KPiB0aGUgLTE0IG9mIHRoaXMgZG9j dW1lbnQgdGhhdDoNCj4gDQo+wqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAgwqAg wqAgwqAgwqBGb3IgYSBNT1AgdmFsdWUgb2YgNywgW1JGQzgxMzhdIE1VU1QgYmUNCj7CoCDCoCB1 c2VkIG9uIExpbmtzIHdoZXJlIDZMb1dQQU4gSGVhZGVyIENvbXByZXNzaW9uIFtSRkM2MjgyXSBh cHBsaWVzIGFuZA0KPsKgIMKgIE1VU1QgTk9UIGJlIHVzZWQgb3RoZXJ3aXNlLg0KPiANCj4gYnV0 IEkgYW0gbm90IHN1cmUgKG9yIGhhdmUgZm9yZ290dGVuKSB3aGF0IHRoZSBjaGFpbiBvZiByZWZl cmVuY2VzIGlzIHN1cHBvc2VkDQo+IHRvIGxlYWQgc29tZW9uZSB3aG8gaXMgaW1wbGVtZW50aW5n IFJQTCBwbHVzIE1PUD03IHRvIHRoZSByZXF1aXJlbWVudCB0bw0KPiB1c2UgUkZDIDgxMzguwqAg SSBkb24ndCB0aGluayB3ZSBzaG91bGQganVzdCByZWx5IG9uIHRoZSBtb3BleCB0ZXh0IHRvIGRv IHNvLA0KPiBzaW5jZSB3ZSBhcmUgdHJ5aW5nIHRvIGltcG9zZSB0aGUgcmVxdWlyZW1lbnQgd2l0 aCB0aGlzIGRvY3VtZW50ICh3aGljaA0KPiBwcmVkYXRlcyBtb3BleCBieSBzb21lIHRpbWUpLCBh bmQgdGhlcmUncyBub3QgYW55dGhpbmcgKG90aGVyIHRoYW4gb3VyDQo+IGNvbGxlY3RpdmUgbWVt b3JpZXMsIG9mIGNvdXJzZSkgcmVxdWlyaW5nIG1vcGV4IHRvIHJlbWFpbiBjb25zaXN0ZW50IHdp dGgNCj4gdGhhdCByZXF1aXJlbWVudC4NCg0KSnVzdCB0byBiZSBjbGVhciBmb3IgdGhlIG90aGVy IHJlYWRlcnM6IE1PUGV4dCBkb2VzIG5vdCBleGlzdCBhcyBhIG5vcm1hdGl2ZSByZWZlcmVuY2Ug Zm9yIHRoaXMgd29yay4NClRoZSBvbmx5IGZpZWxkIHRoYXQgZXhpc3RzIGlzIHRoZSBNT1AgZmll bGQgaW4gdGhlIERJTyBhbmQgdGhhdCBmaWVsZCBpcyAzIGJpdHMgbG9uZywgdmFsdWVzIDAuLjcu DQoNClRoZSBub3JtYXRpdmUgcmVmZXJlbmNlIHRoYXQgeW91IGFyZSBhZnRlciBpcyBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLXJvbGwtdXNlb2ZycGxpbmZvLw0K VGhpcyBpcyB0aGUgc3BlYyB0aGF0IHVwZGF0ZXMgUlBMIGFuZCBjaGFuZ2VzIHRoZSBJQU5BIHJl Z2lzdHJ5IHRvIGluZGljYXRlIHRoYXQgNyBpcyBub3QgYSBNT1AuDQoNClRoZXJlIHdlIGhhdmU6 DQoNCiINCg0KLi4uDQoNCsKgIEFudGljaXBhdGluZyBmdXR1cmUgd29yayB0byByZXZpc2UgUlBM IHJlbGF0aW5nIHRvIGhvdyB0aGUgTExOIGFuZA0KwqAgwqBET0RBRyBpcyBjb25maWd1cmVkLCB0 aGlzIGRvY3VtZW50IGNoYW5nZXMgdGhlIGludGVycHJldGF0aW9uIG9mIHRoZQ0KwqAgwqBbZG9k YWdjZmddIFJlZ2lzdHJ5IHRvIGJlIGxpbWl0ZWQgdG8gTW9kZS1vZi1PcGVyYXRpb24gKE1PUCkN CsKgIMKgc3BlY2lmaWMuwqAgVGhlIE1PUCBpcyBkZXNjcmliZWQgaW4gW1JGQzY1NTBdIHNlY3Rp b24gNi4zLjEuwqAgVGhlDQrCoCDCoE9wdGlvbnMgRmxhZ3MgUmVnaXN0cnkgaXMgcmVuYW1lZCwg YW5kIGFwcGxpZXMgdG8gTU9QIHZhbHVlcyB6ZXJvICgwKQ0KwqAgwqB0byBzaXggKDYpIG9ubHks IGxlYXZpbmcgdGhlIGZsYWdzIHJlc2VydmVkIGZvciBNT1AgdmFsdWUgc2V2ZW4gKDcpLg0KDQrC oCDCoEluIGFkZGl0aW9uLCB0aGlzIGRvY3VtZW50IHJlc2VydmVzIE1PUCB2YWx1ZSA3IGZvciBm dXR1cmUgZXhwYW5zaW9uLg0KDQouLi4NCg0KMTEuMy7CoCBDaGFuZ2UgTU9QIHZhbHVlIDcgdG8g UmVzZXJ2ZWQNCg0KwqAgwqBUaGlzIGRvY3VtZW50IGNoYW5nZXMgdGhlIGFsbG9jYXRpb24gc3Rh dHVzIG9mIHRoZSBNb2RlIG9mIE9wZXJhdGlvbg0KwqAgwqAoTU9QKSBbaWFuYW1vcF0gZnJvbSBV bmFzc2lnbmVkIHRvIFJlc2VydmVkLsKgIFRoaXMgY2hhbmdlIGlzIGluDQrCoCDCoHN1cHBvcnQg b2YgZnV0dXJlIHdvcmsgcmVsYXRlZCB0byBjYXBhYmlsaXRpZXMuDQoiDQoNClNvIGJhc2ljYWxs eSB3ZSB0ZWxsIHRoZSBpbXBsZW1lbnRhdGlvbnMgZnJvbSBub3cgb24gdG8gdGVzdCBpZiBNT1Ag aXMgNywgYW5kIGluIHRoYXQgY2FzZSwgdGhlIE9wdGlvbnMgRmxhZ3MgYXJlIHVuZGVmaW5lZC4g SW4gb3RoZXIgd29yZHMsIGlmIE1PUCBpcyA3LCB0aGUgc3RhY2sgbXVzdCBub3QgdXNlIHRoZSBv cHRpb24gZmxhZ3MgYXMgaWYgdGhlIE1PUCB3YXMgPDcuIEluIGZhY3QsIDcgaXMgbm8gbW9yZSBh IE1PUCB2YWx1ZSBidXQgYSByZXNlcnZlZCB0aGluZ3kgdGhhdCBjYW4gYmUgb3ZlcmxvYWRlZCBp biB0aGUgZnV0dXJlLiBBbmQgeWVzLCB3ZSBpbnRlbmQgdG8gZG8ganVzdCB0aGF0IGluIE1PUEV4 dC4NCg0KVW50aWwgdGhhdCBoYXBwZW5zLCBpbXBsZW1lbnRhdGlvbnMgYXJlIGF0IGEgbG9zcyBp ZiB0aGV5IGVuY291bnRlciB3aGVuIGEgTU9QIGZpZWxkIHRoYXQgaXMgYWxsIG9uZXMuIFNvIHdl IG5lZWQgdG8gZ2l2ZSB0aGVtIGluc3RydWN0aW9ucyB0byBjb3BlIHdpdGggdGhlIHNpdHVhdGlv bi4gVGhpcyBkcmFmdCBkZXJpdmVzIHdoZXRoZXIgdG8gdXNlIFJGQyA4MTM4IGZyb20gd2hldGhl ciB0aGUgNkxvV1BBTiBjb21wcmVzc2lvbiBhcHBsaWVzIHRvIHRoZSBsaW5rIG9yIG5vdC4NCg0K VGhpcyB3aWxsIHN0YXkgdHJ1ZSBmb3JldmVyLCB1bmxlc3MgYW5vdGhlciBSRkMgYW1lbmRzIGl0 LiBXaGVuL2lmIHRoYXQgaGFwcGVucywgdGhlIG5ldyBSRkMgd2lsbCBoYXZlIHRvIGNvbnNpZGVy IGJhY2t3YXJkIGNvbXBhdGliaWxpdHkgd2l0aCBhIGxlZ2FjeSBpbXBsZW1lbnRhdGlvbiB0aGF0 IGltcGxlbWVudHMgdGhlIGFib3ZlLiANCg0KTm90ZSB0aGF0IHRoaXMgbGluZSBvZiB0aG91Z2h0 IGFwcGxpZXMgdG8gMyBmbGFncywgZGVmaW5lZCByZXNwZWN0aXZlbHkgaW46DQotIGh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcm9sbC11c2VvZnJwbGluZm8vDQot IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcm9sbC10dXJub24t cmZjODEzOC8NCi0gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1y b2xsLXVuYXdhcmUtbGVhdmVzLw0KDQpLZWVwIHNhZmUhDQoNClBhc2NhbA0KDQo+IA0KPiBUaGFu a3MsDQo+IA0KPiBCZW4NCj4gDQo+IE9uIFdlZCwgU2VwIDMwLCAyMDIwIGF0IDA0OjI1OjEwUE0g KzAwMDAsIFBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkgd3JvdGU6DQo+ID4gSGVsbG8gQWx2YXJv DQo+ID4NCj4gPiBJIHVwbG9hZGVkIGJvdGggZHJhZnQgd2l0aCB0aGUgc3VnZ2VzdGVkIHVwZGF0 ZSwgcGxlYXNlIHNlZQ0KPiA+DQo+ID4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy9yZmNkaWZmP3Vy bDI9ZHJhZnQtaWV0Zi1yb2xsLXR1cm5vbi1yZmM4MTM4LTE3Lg0KPiA+IHR4dA0KPiA+IGh0dHBz Oi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1pZXRmLXJvbGwtdW5hd2FyZS1sZWF2 ZXMtMjEudHgNCj4gPiB0DQo+ID4NCj4gPiBLZWVwIHNhZmUNCj4gPg0KPiA+IFBhc2NhbA0KPiA+ DQo+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogQWx2YXJvIFJl dGFuYSA8bWFpbHRvOmFyZXRhbmEuaWV0ZkBnbWFpbC5jb20+DQo+ID4gPiBTZW50OiBqZXVkaSAy NCBzZXB0ZW1icmUgMjAyMCAxNzo0OQ0KPiA+ID4gVG86IFBhc2NhbCBUaHViZXJ0IChwdGh1YmVy dCkgPG1haWx0bzpwdGh1YmVydEBjaXNjby5jb20+DQo+ID4gPiBDYzogQmVuamFtaW4gS2FkdWsg PG1haWx0bzprYWR1a0BtaXQuZWR1PjsgVGhlIElFU0cgPG1haWx0bzppZXNnQGlldGYub3JnPjsN Cj4gPiA+IGRyYWZ0LWlldGYtIG1haWx0bzpyb2xsLXR1cm5vbi1yZmM4MTM4QGlldGYub3JnOyBN YXJ0aW4gRHVrZQ0KPiA+ID4gPG1haWx0bzptYXJ0aW4uaC5kdWtlQGdtYWlsLmNvbT47IFJvdXRp bmcgT3ZlciBMb3cgcG93ZXIgYW5kIExvc3N5IG5ldHdvcmtzDQo+ID4gPiA8bWFpbHRvOnJvbGxA aWV0Zi5vcmc+OyByb2xsLSBtYWlsdG86Y2hhaXJzQGlldGYub3JnOyBNaWNoYWVsIFJpY2hhcmRz b24NCj4gPiA+IDxtYWlsdG86bWNyJTJCaWV0ZkBzYW5kZWxtYW4uY2E+DQo+ID4gPiBTdWJqZWN0 OiBSZTogW1JvbGxdIEJlbmphbWluIEthZHVrJ3MgRGlzY3VzcyBvbg0KPiA+ID4gZHJhZnQtaWV0 Zi1yb2xsLXR1cm5vbi1yZmM4MTM4LQ0KPiA+ID4gMTQ6ICh3aXRoIERJU0NVU1MgYW5kIENPTU1F TlQpDQo+ID4gPg0KPiA+ID4gT24gU2VwdGVtYmVyIDI0LCAyMDIwIGF0IDg6MTM6MDkgQU0sIFBh c2NhbCBUaHViZXJ0IHdyb3RlOg0KPiA+ID4NCj4gPiA+DQo+ID4gPiBQYXNjYWw6DQo+ID4gPg0K PiA+ID4gSGkhDQo+ID4gPg0KPiA+ID4gPiBGb2xsb3dpbmcgdGhlIG1lZXRpbmcgbGFzdCBNb25k YXkgYW5kIHN1YnNlcXVlbnQgdGhlIHVwZGF0ZSBvZg0KPiA+ID4gPiB1c2VvZnJwbGluZm8gYnkg TWljaGFlbCAodGhhbmtzIE1pY2hhZWwhKSBJIHB1Ymxpc2hlZCBhIG5ldw0KPiA+ID4gPiB2ZXJz aW9uIG9mIHRoZSB0dXJub24gUkZDDQo+ID4gPiA+IDgxMzggZHJhZnQuDQo+ID4gPiA+DQo+ID4g PiA+IFRoZSBtYWpvciBjaGFuZ2VzIGFyZQ0KPiA+ID4gPiAtIHJlbW92ZWQgdGhlIGZvcm1hbCB1 cGRhdGUgdG8gUkZDIDY1NTANCj4gPiA+ID4gLSByZWZlciB0byB1c2VvZnJwbGluZm8gYXMgdGhl IGp1c3RpZmljYXRpb24gd2h5IHRoZSBmbGFnIGlzIG5vdA0KPiA+ID4gPiBkZWZpbmVkIGZvciBN T1AgNw0KPiA+ID4gPiAtIGRlZmluZWQgdGhlIG9wZXJhdGlvbiBpbiBNT1AgNyBhcyBjb21wcmVz c2lvbiBvbiBpZmYgdGhlIExpbmsNCj4gPiA+ID4gdXNlcyA2TG9QV0FOIEhDLg0KPiA+ID4NCj4g PiA+IFRoYW5rcyBmb3IgdGhlc2UgY2hhbmdlcy4NCj4gPiA+DQo+ID4gPiBCZWNhdXNlIHdlIGhh dmUgdG8gY3ljbGUgdXNlb2ZycGxpbmZvIGJhY2sgdGhyb3VnaCAod2hlbiB0aGUgV0cgaXMNCj4g PiA+IGRvbmUgd2l0aCBpdCksIEkgYXNrZWQgQmVuL01hcnRpbiB0byB3YWl0IGZvciB0aGF0IGJl Zm9yZSBjb21pbmcNCj4gPiA+IGJhY2sgdG8gdGhpcyBkb2N1bWVudC7CoCBJdCdsbCBtYWtlIGl0 IGVhc2llciB0aGFuIHRyYWNraW5nIG11bHRpcGxlDQo+ID4gPiBjaGFuZ2VzLiA6LSkNCj4gPiA+ DQo+ID4gPg0KPiA+ID4gT1RPSCwgSSBkbyBoYXZlIGNvbW1lbnRzIG9uIHRoZSByZWNlbnQgY2hh bmdlOg0KPiA+ID4NCj4gPiA+IE9MRD4NCj4gPiA+IMKgIMKgU2VjdGlvbiA0LjMgb2YgW1VTRW9m UlBMaW5mb10gdXBkYXRlcyBbUkZDNjU1MF0gdG8gaW5kaWNhdGUgdGhhdA0KPiA+ID4gdGhlDQo+ ID4gPiDCoCDCoGRlZmluaXRpb24gb2YgdGhlIEZsYWdzIGFwcGxpZXMgdG8gTW9kZSBvZiBPcGVy YXRpb24gKE1PUCkgdmFsdWVzDQo+ID4gPiDCoCDCoHplcm8gKDApIHRvIHNpeCAoNikgb25seSwg bGVhdmluZyB0aGUgZmxhZ3MgcmVzZXJ2ZWQgZm9yIE1PUA0KPiA+ID4gdmFsdWUNCj4gPiA+IMKg IMKgc2V2ZW4gKDcpLsKgIEZvciBhIE1PUCB2YWx1ZSBvZiA3LCB0aGUgYml0IGluIHBvc2l0aW9u IDIgaXMNCj4gPiA+IGNvbnNpZGVyZWQNCj4gPiA+IMKgIMKgdW5hbGxvY2F0ZWQgYW5kIFtSRkM4 MTM4XSBNVVNUIGJlIHVzZWQgb24gTGlua3Mgd2hlcmUgNkxvV1BBTg0KPiA+ID4gSGVhZGVyDQo+ ID4gPiDCoCDCoENvbXByZXNzaW9uIFtSRkM2MjgyXSBhcHBsaWVzIGFuZCBNVVNUIE5PVCBiZSB1 c2VkIG90aGVyd2lzZS4NCj4gPiA+DQo+ID4gPiBORVc+DQo+ID4gPg0KPiA+ID4gwqAgwqBTZWN0 aW9uIDQuMyBvZiBbVVNFb2ZSUExpbmZvXSB1cGRhdGVzIFtSRkM2NTUwXSB0byBpbmRpY2F0ZSB0 aGF0DQo+ID4gPiB0aGUNCj4gPiA+IMKgIMKgZGVmaW5pdGlvbiBvZiB0aGUgRmxhZ3MgYXBwbGll cyB0byBNb2RlIG9mIE9wZXJhdGlvbiAoTU9QKSB2YWx1ZXMNCj4gPiA+IHplcm8gKDApDQo+ID4g PiDCoCDCoHRvIHNpeCAoNikgb25seS7CoCBGb3IgYSBNT1AgdmFsdWUgb2YgNywgW1JGQzgxMzhd IE1VU1QgYmUgdXNlZCBvbg0KPiA+ID4gTGlua3MNCj4gPiA+IMKgIMKgd2hlcmUgNkxvV1BBTiBI ZWFkZXIgQ29tcHJlc3Npb24gW1JGQzYyODJdIGFwcGxpZXMgYW5kIE1VU1QgTk9UDQo+ID4gPiBi ZSB1c2VkDQo+ID4gPiDCoCDCoG90aGVyd2lzZS4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gVGhhbmtz IQ0KPiA+ID4NCj4gPiA+IEFsdmFyby4NCg== From nobody Wed Nov 11 08:27:04 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC1B93A0E96; Wed, 11 Nov 2020 08:27:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, 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 xxLYXDCe0whA; Wed, 11 Nov 2020 08:26:59 -0800 (PST) Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 C4A663A0DFB; Wed, 11 Nov 2020 08:26:58 -0800 (PST) Received: by mail-il1-x134.google.com with SMTP id x20so2482473ilj.8; Wed, 11 Nov 2020 08:26:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=OrOGTnIy849IfvLbJ+z6SnN3yfIPAhJB1K2AwHyykU4=; b=KyosjpO62oNmoQDTU4ZAlPfnSoRQDzcjk0u1RqNpDB2ZxbY1ObpEYTEA6YOp8g7eU9 nU4sXQRAP8CfieHTP2gOAaBsfbFl7h2M6OGpoh3FSni8/o9WTxcXxUAQD8G+xtD37Myq lBUOf6qCNAkE5bPzueFNz5lGh0QCz7YtPGpFjG2AyKv5yEyY4o58RNfMGUb30p2kL8lu 4qXh14St/rsJZnt0Tv51tTzu6hcwMVLzgTZZ1SuAdynoy2Yr4SOuIOmQnzEQriBWSjPf n6fvMmO1blN1GCzUhM8KB1fS7T1w888NKC8hFlKXin+dOv9c9JMEqftx94K6zqkSSkKj QvMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=OrOGTnIy849IfvLbJ+z6SnN3yfIPAhJB1K2AwHyykU4=; b=OdLjGufxv9dMCHIZDeDpSUuxq/InTMzgouyui5RkFd8WzbPWrOjjKLuAZtp7DDMBQ0 UuiTFOm6ynCRaH3iMRdJcv6lz6LCEMbrX5Lm/sHfN4qBAmQzrrEsdmkz42nWfu8ILSOY MdGUX3LjMuo4p83Oq7zOw4r06cmXNfTb2IXhZip2PZUt6wmaSzWx7QVG2dGFbawbJ/kJ ytCi5/XxpVUO2IxNMxRhQO2eDcNTCIaIAYoJffVW8UsaVDRzksyVVmRNLXh234AX157s d5LJWa5VzkwOQatr/ZIyCQ9/0hjLPsuTqpp6EEKzX6Q61uHsZG1WYQgVkrR3Js+pE26O M/hw== X-Gm-Message-State: AOAM532igwJOR0+kvM6fQsxGPage+qVKVvrVs5giDokE5m4mWtRtCUfX ytLNOtGqEkyC6nW/9JyACpmpSvNyrLFYQHayO9A= X-Google-Smtp-Source: ABdhPJzZSFt2G21Adn4aVnY/RqYVffMaXQMhVIRI9fUkXPGWEMN/HS1AaO6VOsMBwXENOHKCuo6rXvMfOiucnLTd4Pg= X-Received: by 2002:a05:6e02:1388:: with SMTP id d8mr19259967ilo.272.1605112017931; Wed, 11 Nov 2020 08:26:57 -0800 (PST) MIME-Version: 1.0 References: <20200911162617.GQ89563@kduck.mit.edu> <8F19C753-DCA0-4A32-BA3B-A124B2F7F745@cisco.com> <117497.1600481093@dooku> <20201110033438.GE39170@kduck.mit.edu> In-Reply-To: From: Martin Duke Date: Wed, 11 Nov 2020 08:26:48 -0800 Message-ID: To: "Pascal Thubert (pthubert)" Cc: Benjamin Kaduk , Alvaro Retana , The IESG , "draft-ietf-roll-turnon-rfc8138@ietf.org" , Routing Over Low power and Lossy networks , "roll-chairs@ietf.org" , Michael Richardson Content-Type: multipart/alternative; boundary="000000000000a7535205b3d743d2" Archived-At: Subject: Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf-roll-turnon-rfc8138-14: (with DISCUSS and COMMENT) 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, 11 Nov 2020 16:27:02 -0000 --000000000000a7535205b3d743d2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ah, OK, I see now that MOP7 in itself substitutes for the flag. I'm satisfied. On Wed, Nov 11, 2020 at 1:59 AM Pascal Thubert (pthubert) < pthubert@cisco.com> wrote: > Hello Martin > > First of all you are correct that the whole game is to recover the bits > for RPLv2, with the idea that the features that they signaled will be > installed and that signaling the transition will be a waste. Also RPL has > very few of these flags available in the configuration option and the gro= up > insisted on getting them back after the transition. > > Second is to thank you for your care / the depth of your attention on tha= t > issue. It is indeed =E2=80=9Ctouchy=E2=80=9D. And it spans 3 drafts that = are going through > IESG in the same window of time. > > Let=E2=80=99s see below > > > We will eventually get there, but this will never stop being weird to > me. :-) > > > Imagine 5 types of DODAG nodes: > > I read they support the below as opposed to the DODAG is deployed with th= e > below. > > Type 8138? this draft? MOP5? MOP 7? > ------- ------- ------------ -------- ---------- > A N N N N > B Y N N N > C Y Y N N > D Y Y Y N > E Y Y Y Y > > > So if IIUC, the current state of play is that B can't gracefully deploy > into a network with A, because they have to be statically configured to > not-compress. > > Or you need some management outside of RPL which is against the core > design point that RPL should be autonomic/self-configuring > > > As long as B is upgraded to this draft (C), it can gracefully deploy in > a network with A, because compression will remain off until all the A is > gone. C and B can function together without this draft, but they won't be > able to dynamically change compression state, FWIW > > Yes, that is the transition phase > > > Similarly, a hypothetical D can gracefully deploy with A, as it will > have use of these flags, but doesn't really need the flags to work with B > or C unless you want to dynamically change state for some reason. > > Unclear what you mean. If the DODAG is deployed with a MOP < 5 D is a C. > If the MOP is 5, nodes A, B, and C will have to be leaves, and the flag > will still be off as long as there's an A in the network, else that A wil= l > be isolated. > > > Meanwhile, E will not be able to gracefully deploy with A, because it > does not have a means to change its compression state using the DODAG > configuration. But because of the sentence we've discussing in this threa= d, > networks with C and D will have no problem because they have this text to > help them decide whether or not to compress. They will not have the abili= ty > to dynamically change compression state. > > Same as above, if the MOP is <7, the flag still works, even if E is > capable of some new MOPExt MOPs. If we use a MOPext (signaled by MOP=3D7)= , > and if there are nodes of type A in the network, tose nodes of type A wil= l > be leaves and they'll be isolated, unless they turn into > RPL-unaware-leaves, from which compression is not expected. > > > So I guess the value of the MOP 7 behavior is... to recover the bit of > the flags? Fine, I suppose, but this would appear to have two costs: > Yes > > > 1) If A is still out there when E deploys, this bit would have been > useful, but isn't. > It's not when E deploys, it is when the DODAG is deployed or upgraded wit= h > a MOP 7. > > > 2) I have no idea if the "dynamic change in compression state" use case > is valuable it all, but it would certainly foreclose the possilbilty. > We defined this flag to enable the activation of the compression in a > brown field. Right now we have millions of nodes deployed, all of type A. > typically utility AMI meters. Having to impose a flag day to migrate to t= he > compression is not acceptable to our users. So we do not even propose it. > and the situation is stuck. If we have a migration scenario without a fla= g > day, we can ship the compression in software refreshes, and let the > customer decide if and when to turn on. > > > Do I have this right? > > You do =F0=9F=98=8A > > Pascal > > > On Tue, Nov 10, 2020 at 12:15 AM Pascal Thubert (pthubert) pthubert@cisco.com> wrote: > Hello Benjamin: > > > That said, and my apologies for a hazy memory coming back to this after= a > > couple months, in a year or N from now when mopex is finalized, how wil= l > > someone looking at mopex know to use RFC8138 on links where 6LoWPAN > > Header Compression applies (and not use it otherwise)? We are claiming > in > > the -14 of this document that: > > > > For a MOP value of 7, [RFC8138] MUST be > > used on Links where 6LoWPAN Header Compression [RFC6282] applies and > > MUST NOT be used otherwise. > > > > but I am not sure (or have forgotten) what the chain of references is > supposed > > to lead someone who is implementing RPL plus MOP=3D7 to the requirement= to > > use RFC 8138. I don't think we should just rely on the mopex text to d= o > so, > > since we are trying to impose the requirement with this document (which > > predates mopex by some time), and there's not anything (other than our > > collective memories, of course) requiring mopex to remain consistent wi= th > > that requirement. > > Just to be clear for the other readers: MOPext does not exist as a > normative reference for this work. > The only field that exists is the MOP field in the DIO and that field is = 3 > bits long, values 0..7. > > The normative reference that you are after is > https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/ > This is the spec that updates RPL and changes the IANA registry to > indicate that 7 is not a MOP. > > There we have: > > " > > ... > > Anticipating future work to revise RPL relating to how the LLN and > DODAG is configured, this document changes the interpretation of the > [dodagcfg] Registry to be limited to Mode-of-Operation (MOP) > specific. The MOP is described in [RFC6550] section 6.3.1. The > Options Flags Registry is renamed, and applies to MOP values zero (0) > to six (6) only, leaving the flags reserved for MOP value seven (7). > > In addition, this document reserves MOP value 7 for future expansion. > > ... > > 11.3. Change MOP value 7 to Reserved > > This document changes the allocation status of the Mode of Operation > (MOP) [ianamop] from Unassigned to Reserved. This change is in > support of future work related to capabilities. > " > > So basically we tell the implementations from now on to test if MOP is 7, > and in that case, the Options Flags are undefined. In other words, if MOP > is 7, the stack must not use the option flags as if the MOP was <7. In > fact, 7 is no more a MOP value but a reserved thingy that can be overload= ed > in the future. And yes, we intend to do just that in MOPExt. > > Until that happens, implementations are at a loss if they encounter when = a > MOP field that is all ones. So we need to give them instructions to cope > with the situation. This draft derives whether to use RFC 8138 from wheth= er > the 6LoWPAN compression applies to the link or not. > > This will stay true forever, unless another RFC amends it. When/if that > happens, the new RFC will have to consider backward compatibility with a > legacy implementation that implements the above. > > Note that this line of thought applies to 3 flags, defined respectively i= n: > - https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/ > - https://datatracker.ietf.org/doc/draft-ietf-roll-turnon-rfc8138/ > - https://datatracker.ietf.org/doc/draft-ietf-roll-unaware-leaves/ > > Keep safe! > > Pascal > > > > > Thanks, > > > > Ben > > > > On Wed, Sep 30, 2020 at 04:25:10PM +0000, Pascal Thubert (pthubert) > wrote: > > > Hello Alvaro > > > > > > I uploaded both draft with the suggested update, please see > > > > > > https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-turnon-rfc8138-= 17. > > > txt > > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-unaware-leaves-21= .tx > > > t > > > > > > Keep safe > > > > > > Pascal > > > > > > > -----Original Message----- > > > > From: Alvaro Retana > > > > Sent: jeudi 24 septembre 2020 17:49 > > > > To: Pascal Thubert (pthubert) > > > > Cc: Benjamin Kaduk ; The IESG iesg@ietf.org>; > > > > draft-ietf- mailto:roll-turnon-rfc8138@ietf.org; Martin Duke > > > > ; Routing Over Low power and Lossy > networks > > > > ; roll- mailto:chairs@ietf.org; Michael > Richardson > > > > > > > > Subject: Re: [Roll] Benjamin Kaduk's Discuss on > > > > draft-ietf-roll-turnon-rfc8138- > > > > 14: (with DISCUSS and COMMENT) > > > > > > > > On September 24, 2020 at 8:13:09 AM, Pascal Thubert wrote: > > > > > > > > > > > > Pascal: > > > > > > > > Hi! > > > > > > > > > Following the meeting last Monday and subsequent the update of > > > > > useofrplinfo by Michael (thanks Michael!) I published a new > > > > > version of the turnon RFC > > > > > 8138 draft. > > > > > > > > > > The major changes are > > > > > - removed the formal update to RFC 6550 > > > > > - refer to useofrplinfo as the justification why the flag is not > > > > > defined for MOP 7 > > > > > - defined the operation in MOP 7 as compression on iff the Link > > > > > uses 6LoPWAN HC. > > > > > > > > Thanks for these changes. > > > > > > > > Because we have to cycle useofrplinfo back through (when the WG is > > > > done with it), I asked Ben/Martin to wait for that before coming > > > > back to this document. It'll make it easier than tracking multiple > > > > changes. :-) > > > > > > > > > > > > OTOH, I do have comments on the recent change: > > > > > > > > OLD> > > > > Section 4.3 of [USEofRPLinfo] updates [RFC6550] to indicate that > > > > the > > > > definition of the Flags applies to Mode of Operation (MOP) value= s > > > > zero (0) to six (6) only, leaving the flags reserved for MOP > > > > value > > > > seven (7). For a MOP value of 7, the bit in position 2 is > > > > considered > > > > unallocated and [RFC8138] MUST be used on Links where 6LoWPAN > > > > Header > > > > Compression [RFC6282] applies and MUST NOT be used otherwise. > > > > > > > > NEW> > > > > > > > > Section 4.3 of [USEofRPLinfo] updates [RFC6550] to indicate that > > > > the > > > > definition of the Flags applies to Mode of Operation (MOP) value= s > > > > zero (0) > > > > to six (6) only. For a MOP value of 7, [RFC8138] MUST be used o= n > > > > Links > > > > where 6LoWPAN Header Compression [RFC6282] applies and MUST NOT > > > > be used > > > > otherwise. > > > > > > > > > > > > Thanks! > > > > > > > > Alvaro. > --000000000000a7535205b3d743d2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Ah, OK, I see now that MOP7 in itself substitutes for the = flag. I'm satisfied.

On Wed, Nov 11, 2020 at 1:59 AM Pascal Thubert (pth= ubert) <pthubert@cisco.com>= wrote:
Hello Ma= rtin

First of all you are correct that the whole game is to recover the bits for= RPLv2, with the idea that the features that they signaled will be installe= d and that signaling the transition will be a waste. Also RPL has very few = of these flags available in the configuration option and the group insisted= on getting them back after the transition.

Second is to thank you for your care / the depth of your attention on that = issue. It is indeed =E2=80=9Ctouchy=E2=80=9D. And it spans 3 drafts that ar= e going through IESG in the same window of time.

Let=E2=80=99s see below

> We will eventually get there, but this will never stop being weird to = me. :-)

> Imagine 5 types of DODAG nodes:

I read they support the below as opposed to the DODAG is deployed with the = below.

Type=C2=A0 =C2=A0 =C2=A08138? this draft? MOP5?=C2=A0 MOP 7?
-------=C2=A0 =C2=A0 =C2=A0 -------=C2=A0 =C2=A0------------=C2=A0 =C2=A0 -= -------=C2=A0 =C2=A0----------=C2=A0
=C2=A0A=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0N=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 N=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0N=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0N=C2=A0 =C2=A0 =C2=A0 =C2= =A0
B=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Y=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 N=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0N= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0N
C=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Y=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Y=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0N= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0N
D=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Y=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Y=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Y= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 N
E=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Y=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Y=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = Y=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Y

> So if IIUC, the current state of play is that B can't gracefully d= eploy into a network with A, because they have to be statically configured = to not-compress.

Or you need some management outside of RPL which is against the core design= point that RPL should be autonomic/self-configuring

> As long as B is upgraded to this draft (C), it can gracefully deploy i= n a network with A, because=C2=A0compression will remain off until all the = A is gone. C and B can function together without this draft, but they won&#= 39;t be able to dynamically change compression state, FWIW

Yes, that is the transition phase

>=C2=A0 Similarly, a hypothetical D can gracefully deploy with A, as it = will have use of these flags, but doesn't really need the flags to work= with B or C unless you want to dynamically change state for some reason.
Unclear what you mean. If the DODAG is deployed with a MOP < 5 D is a C.= If the MOP is 5, nodes A, B, and C will have to be leaves, and the flag wi= ll still be off as long as there's an A in the network, else that A wil= l be isolated.

> Meanwhile, E will not be able to gracefully deploy with A, because it = does not have a means to change its compression state using the DODAG confi= guration. But because of the sentence we've discussing in this thread, = networks with C and D will have no problem because they have this text to h= elp them decide whether or not to compress. They will not have the ability = to dynamically change compression state.

Same as above, if the MOP is <7, the flag still works, even if E is capa= ble of some new MOPExt MOPs. If we use a MOPext (signaled by MOP=3D7), and = if there are nodes of type A in the network, tose nodes of type A will be l= eaves and they'll be isolated, unless they turn into RPL-unaware-leaves= , from which compression is not expected.

> So I guess the value of the MOP 7 behavior is... to recover the bit of= the flags? Fine, I suppose, but this would appear to have two costs:
Yes

> 1) If A is still out there when E deploys, this bit would have been us= eful, but isn't.
It's not when E deploys, it is when the DODAG is deployed or upgraded w= ith a MOP 7.

> 2) I have no idea if the "dynamic change in compression state&quo= t; use case is valuable it all, but it would certainly foreclose the possil= bilty.
We defined this flag to enable the activation of the compression in a brown= field. Right now we have millions of nodes deployed, all of type A. typica= lly utility AMI meters. Having to impose a flag day to migrate to the compr= ession is not acceptable to our users. So we do not even propose it. and th= e situation is stuck. If we have a migration scenario without a flag day, w= e can ship the compression in software refreshes, and let the customer deci= de if and when to turn on.

> Do I have this right?

You do =F0=9F=98=8A

Pascal


On Tue, Nov 10, 2020 at 12:15 AM Pascal Thubert (pthubert) <mailto:pthubert@cisco.com&g= t; wrote:
Hello Benjamin:

> That said, and my apologies for a hazy memory coming back to this afte= r a
> couple months, in a year or N from now when mopex is finalized, how wi= ll
> someone looking at mopex know to use RFC8138 on links where 6LoWPAN > Header Compression applies (and not use it otherwise)?=C2=A0 We are cl= aiming in
> the -14 of this document that:
>
>=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 =C2=A0 =C2=A0 =C2=A0For a MOP value of 7, [RFC8138] MU= ST be
>=C2=A0 =C2=A0 used on Links where 6LoWPAN Header Compression [RFC6282] = applies and
>=C2=A0 =C2=A0 MUST NOT be used otherwise.
>
> but I am not sure (or have forgotten) what the chain of references is = supposed
> to lead someone who is implementing RPL plus MOP=3D7 to the requiremen= t to
> use RFC 8138.=C2=A0 I don't think we should just rely on the mopex= text to do so,
> since we are trying to impose the requirement with this document (whic= h
> predates mopex by some time), and there's not anything (other than= our
> collective memories, of course) requiring mopex to remain consistent w= ith
> that requirement.

Just to be clear for the other readers: MOPext does not exist as a normativ= e reference for this work.
The only field that exists is the MOP field in the DIO and that field is 3 = bits long, values 0..7.

The normative reference that you are after is https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/<= br> This is the spec that updates RPL and changes the IANA registry to indicate= that 7 is not a MOP.

There we have:

"

...

=C2=A0 Anticipating future work to revise RPL relating to how the LLN and =C2=A0 =C2=A0DODAG is configured, this document changes the interpretation = of the
=C2=A0 =C2=A0[dodagcfg] Registry to be limited to Mode-of-Operation (MOP) =C2=A0 =C2=A0specific.=C2=A0 The MOP is described in [RFC6550] section 6.3.= 1.=C2=A0 The
=C2=A0 =C2=A0Options Flags Registry is renamed, and applies to MOP values z= ero (0)
=C2=A0 =C2=A0to six (6) only, leaving the flags reserved for MOP value seve= n (7).

=C2=A0 =C2=A0In addition, this document reserves MOP value 7 for future exp= ansion.

...

11.3.=C2=A0 Change MOP value 7 to Reserved

=C2=A0 =C2=A0This document changes the allocation status of the Mode of Ope= ration
=C2=A0 =C2=A0(MOP) [ianamop] from Unassigned to Reserved.=C2=A0 This change= is in
=C2=A0 =C2=A0support of future work related to capabilities.
"

So basically we tell the implementations from now on to test if MOP is 7, a= nd in that case, the Options Flags are undefined. In other words, if MOP is= 7, the stack must not use the option flags as if the MOP was <7. In fac= t, 7 is no more a MOP value but a reserved thingy that can be overloaded in= the future. And yes, we intend to do just that in MOPExt.

Until that happens, implementations are at a loss if they encounter when a = MOP field that is all ones. So we need to give them instructions to cope wi= th the situation. This draft derives whether to use RFC 8138 from whether t= he 6LoWPAN compression applies to the link or not.

This will stay true forever, unless another RFC amends it. When/if that hap= pens, the new RFC will have to consider backward compatibility with a legac= y implementation that implements the above.

Note that this line of thought applies to 3 flags, defined respectively in:=
- https://datatracker.ietf.org/doc/dra= ft-ietf-roll-useofrplinfo/
- https://datatracker.ietf.org/doc/d= raft-ietf-roll-turnon-rfc8138/
- https://datatracker.ietf.org/doc/d= raft-ietf-roll-unaware-leaves/

Keep safe!

Pascal

>
> Thanks,
>
> Ben
>
> On Wed, Sep 30, 2020 at 04:25:10PM +0000, Pascal Thubert (pthubert) wr= ote:
> > Hello Alvaro
> >
> > I uploaded both draft with the suggested update, please see
> >
> > https://tools.ietf.= org/rfcdiff?url2=3Ddraft-ietf-roll-turnon-rfc8138-17.
> > txt
> > https://www.ietf.o= rg/rfcdiff?url2=3Ddraft-ietf-roll-unaware-leaves-21.tx
> > t
> >
> > Keep safe
> >
> > Pascal
> >
> > > -----Original Message-----
> > > From: Alvaro Retana <mailto:aretana.ietf@gmail.com>
> > > Sent: jeudi 24 septembre 2020 17:49
> > > To: Pascal Thubert (pthubert) <mailto:pthubert@cisco.com>
> > > Cc: Benjamin Kaduk <mailto:kaduk@mit.edu>; The IESG <mailto:iesg@ietf.org>;
> > > draft-ietf- mailto:roll-turnon-rfc8138@ietf.org; Martin Duke
> > > <mailto:martin.h.duke@gmail.com>; Routing Over Low power and Los= sy networks
> > > <mailto:roll@ietf.org>; roll- mailto:chairs@ietf.org; Michael Richardson
> > > <mailto:mcr%2Bietf@sandelman.ca>
> > > Subject: Re: [Roll] Benjamin Kaduk's Discuss on
> > > draft-ietf-roll-turnon-rfc8138-
> > > 14: (with DISCUSS and COMMENT)
> > >
> > > On September 24, 2020 at 8:13:09 AM, Pascal Thubert wrote: > > >
> > >
> > > Pascal:
> > >
> > > Hi!
> > >
> > > > Following the meeting last Monday and subsequent the up= date of
> > > > useofrplinfo by Michael (thanks Michael!) I published a= new
> > > > version of the turnon RFC
> > > > 8138 draft.
> > > >
> > > > The major changes are
> > > > - removed the formal update to RFC 6550
> > > > - refer to useofrplinfo as the justification why the fl= ag is not
> > > > defined for MOP 7
> > > > - defined the operation in MOP 7 as compression on iff = the Link
> > > > uses 6LoPWAN HC.
> > >
> > > Thanks for these changes.
> > >
> > > Because we have to cycle useofrplinfo back through (when the= WG is
> > > done with it), I asked Ben/Martin to wait for that before co= ming
> > > back to this document.=C2=A0 It'll make it easier than t= racking multiple
> > > changes. :-)
> > >
> > >
> > > OTOH, I do have comments on the recent change:
> > >
> > > OLD>
> > > =C2=A0 =C2=A0Section 4.3 of [USEofRPLinfo] updates [RFC6550]= to indicate that
> > > the
> > > =C2=A0 =C2=A0definition of the Flags applies to Mode of Oper= ation (MOP) values
> > > =C2=A0 =C2=A0zero (0) to six (6) only, leaving the flags res= erved for MOP
> > > value
> > > =C2=A0 =C2=A0seven (7).=C2=A0 For a MOP value of 7, the bit = in position 2 is
> > > considered
> > > =C2=A0 =C2=A0unallocated and [RFC8138] MUST be used on Links= where 6LoWPAN
> > > Header
> > > =C2=A0 =C2=A0Compression [RFC6282] applies and MUST NOT be u= sed otherwise.
> > >
> > > NEW>
> > >
> > > =C2=A0 =C2=A0Section 4.3 of [USEofRPLinfo] updates [RFC6550]= to indicate that
> > > the
> > > =C2=A0 =C2=A0definition of the Flags applies to Mode of Oper= ation (MOP) values
> > > zero (0)
> > > =C2=A0 =C2=A0to six (6) only.=C2=A0 For a MOP value of 7, [R= FC8138] MUST be used on
> > > Links
> > > =C2=A0 =C2=A0where 6LoWPAN Header Compression [RFC6282] appl= ies and MUST NOT
> > > be used
> > > =C2=A0 =C2=A0otherwise.
> > >
> > >
> > > Thanks!
> > >
> > > Alvaro.
--000000000000a7535205b3d743d2-- From nobody Wed Nov 11 08:40:45 2020 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C585E3A0EEE; Wed, 11 Nov 2020 08:40:40 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: Martin Duke via Datatracker To: "The IESG" Cc: draft-ietf-roll-turnon-rfc8138@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.22.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: Martin Duke Message-ID: <160511284071.11537.6395585148979048057@ietfa.amsl.com> Date: Wed, 11 Nov 2020 08:40:40 -0800 Archived-At: Subject: [Roll] Martin Duke's No Objection on draft-ietf-roll-turnon-rfc8138-17: (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: Wed, 11 Nov 2020 16:40:41 -0000 Martin Duke has entered the following ballot position for draft-ietf-roll-turnon-rfc8138-17: No Objection 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/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-roll-turnon-rfc8138/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for addressing my DISCUSS. I found last paragraph of Section 3 confusing. I suggest the following change: OLD: Section 6.3.1 of [RFC6550] defines a 3-bit Mode of Operation (MOP) in the DIO Base Object. This specification applies to MOP values 0 to 6. For a MOP value of 7, the compression MUST be used by default regardless of the setting of the "T" flag. NEW: "Section 6.3.1 of [RFC6550] defines a 3-bit Mode of Operation (MOP) in the DIO Base Object. This specification adds codepoint 7 to the registry for this field. For a MOP value of 7, the compression MUST be used by default regardless of the setting of the "T" flag.“ From nobody Wed Nov 11 09:40:27 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A96E3A46B2; Wed, 11 Nov 2020 09:40:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xeauz8f4EIT7; Wed, 11 Nov 2020 09:40:18 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C73DA3A13F7; Wed, 11 Nov 2020 09:28:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 825DB389B4; Wed, 11 Nov 2020 12:29:08 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id i2-nhulXLoOM; Wed, 11 Nov 2020 12:29:07 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 7995B389AB; Wed, 11 Nov 2020 12:29:07 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 7A6591AD; Wed, 11 Nov 2020 12:28:37 -0500 (EST) From: Michael Richardson To: Martin Duke , "Pascal Thubert (pthubert)" , Benjamin Kaduk , Alvaro Retana , The IESG , "draft-ietf-roll-turnon-rfc8138@ietf.org" , Routing Over Low power and Lossy networks , "roll-chairs@ietf.org" In-Reply-To: X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Content-Transfer-Encoding: quoted-printable Date: Wed, 11 Nov 2020 12:28:37 -0500 Message-ID: <6978.1605115717@localhost> Archived-At: Subject: Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf-roll-turnon-rfc8138-14: (with DISCUSS and COMMENT) 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, 11 Nov 2020 17:40:26 -0000 Martin Duke wrote: > So I guess the value of the MOP 7 behavior is... to recover the bit = of the > flags? Fine, I suppose, but this would appear to have two costs: > 1) If A is still out there when E deploys, this bit would have been = useful, > but isn't. The whole point is that A and E can't co-exist, BY CONSTRUCTION. The same way that IPv6 nodes can't talk to IPv4 directly. And we're okay with that, because it's the A/B -> C transition that worrie= s us. > Do I have this right? I think so. Finally, at present, there aren't many networks where there is much in the way of multi-vendor nodes present. That's sad. But, the owners of the networks want/need (often by NAFTA Article 10/etc. other treaty) to be abl= e to source from other vendors. -- ] Never tell me the odds! | ipv6 mesh networ= ks [ ] Michael Richardson, Sandelman Software Works | IoT architect= [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails = [ From nobody Wed Nov 11 09:46:29 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77FCC3A51F5; Wed, 11 Nov 2020 09:46:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 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_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=TM5+VUzl; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=PM5uzlfB 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 LD_gbfDe3WLd; Wed, 11 Nov 2020 09:46:17 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34BFC3A1DBC; Wed, 11 Nov 2020 09:31:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10050; q=dns/txt; s=iport; t=1605115908; x=1606325508; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=g7X1MjC6EbISEpln7I8P0O/OR35AL07WAmK56NWNjBY=; b=TM5+VUzl980HBaEezQGpckHgSwDwjO3lRxKq/4yCJ8mjcynMQ7MTqfeC SjjctNUPIrRoEUMOm7/lwjM3YUZgIxNPsqPXVHq5DzTq1u6OK6V7uxQ6g lK5aguLcWfBY3MaUsbfk6MITWY4Tt99J8a/rM8z0OC4wU/tkXE3f5GM1Z Q=; X-IPAS-Result: =?us-ascii?q?A0AcBQDWHqxffYgNJK1iDg4BAQEBAQEHAQESAQEEBAEBQ?= =?us-ascii?q?IFPgVJRe1kvLogGA41UihaObYFCgREDVAsBAQENAQEjCgIEAQGESgKCFgIlO?= =?us-ascii?q?BMCAwEBAQMCAwEBAQEFAQEBAgEGBBQBAYY8DIVyAQEBAwESLgEBNwEEBwQCA?= =?us-ascii?q?QgRBAEBASMLIREdCAIEDgUIGoMFglUDDiABDqUbAoE8iGh0gTSDBAEBBYE3A?= =?us-ascii?q?g5Bgw8NC4IQAwaBOIJzgmVOhxkbgUE/gRFDgVF+PoIbQgEBAgEBFYEdCwQcg?= =?us-ascii?q?0iCLJMoAYkaik6QSlQKgm2JD4xyhTWDGYoVlEmVUIh9gm6OMYQ0AgQCBAUCD?= =?us-ascii?q?gEBBYFrIYFDDwdwFYMkUBcCDY4fDBcUgzqFFIUEQHQCNgIGCgEBAwl8iwaCR?= =?us-ascii?q?gEB?= IronPort-PHdr: =?us-ascii?q?9a23=3AvvRlGBN77QompOiv+HAl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEvKw13lrIQcPW5+8Xw+bVsqW1X2sG7N7BtX0Za5VDWl?= =?us-ascii?q?cDjtlehA0vBsOJSCiZZP7nZiA3BoJOAVli+XzoNElJXsvyeg6arni79zVHHB?= =?us-ascii?q?L5OEJ8Lfj0HYiHicOx2qiy9pTfbh8OiiC6ZOZ5LQ69qkPascxFjA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.77,470,1596499200"; d="scan'208";a="605671022" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Nov 2020 17:31:47 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 0ABHVlxJ010711 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 11 Nov 2020 17:31:47 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 11 Nov 2020 11:31:46 -0600 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 11 Nov 2020 11:31:46 -0600 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 11 Nov 2020 12:31:45 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZE8NTCBO2AEYK8RbDryE/Em1C0yHrXDIEquxPCKYv23E3satnlPukuaaRM2+XQp8gIPRC2StRC6T5dfddXOq/WKBrk4WZ7KCrf/FnQeArh5uHAsaVBwb6F0EMH2TSkFYl5a1MWjN2WgFPMgbPLMzh5t8YoPU/T/0eImMUEDUTGAnwG+3jFIWOv9QDh6pAIO/7MlaPJbd/2MgCh7STyz4rRW3LUST1qxGuoX7JO7IUHc+wJnvprRaesBJgCEqRnl4WGzJK0Uk56vq7BK7cn8QBLwqI/GBVziTLOQp8o/DFGxzfrJ93SvHx7Xt5XmOs/gSjEiBVYh0LursbLaH1oe3qg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SEsiBu0VPE1VE7nU/pgc74xZCojUzEGll0Aa8fPzCS4=; b=Ha/5v70nabnSIM6msObDLZFTUZ6D7A3KwaVCxr34HJSDvthbq9mwehTM4le/1vnJLlX1bqv8cX49TQlIQpUR3VgWHDjR7LFHueK/9AMsclltndjsVlv2/7gcsZdpEmHxE8s6vSnd32AbfPjpKBCoHykcMqNHYoIYmnbyNpnrEQS1Oev6U2yd7+3gZiCsAXZylei8j4FRjkyjlUc72hMnHNv50n+nretRDOrDCMhLmwx95NtLs9ibfh2Tpu2RyhVayYP/EnPxvno6cWhpr7aLoE+YXLC9hGpwTeNWGVOoS58ekkCRpBffEABrXc1bpqqGVLZz+7Cu5RcEUJN2SkDpsQ== 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=SEsiBu0VPE1VE7nU/pgc74xZCojUzEGll0Aa8fPzCS4=; b=PM5uzlfB2LzSfaLb+PrTLYMw7IHawjQlZNuh1XmnE/lhDET4HJyAv2p8ckd1iyieTEtXH8ba1OiVdAaQ+vidSGaICYikPzsyJDdaZRo+pUckKm6fRsnCry/1uVVGcS3FEcLTqqOxhoj164xXGEf46ShGOx3++Qcsz/uZT+IVNWw= Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by MWHPR11MB1824.namprd11.prod.outlook.com (2603:10b6:300:110::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.24; Wed, 11 Nov 2020 17:31:44 +0000 Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::ad88:1b7e:c9f2:b30d]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::ad88:1b7e:c9f2:b30d%6]) with mapi id 15.20.3541.025; Wed, 11 Nov 2020 17:31:44 +0000 From: "Pascal Thubert (pthubert)" To: Benjamin Kaduk CC: Alvaro Retana , The IESG , "draft-ietf-roll-turnon-rfc8138@ietf.org" , Martin Duke , Routing Over Low power and Lossy networks , "roll-chairs@ietf.org" , "Michael Richardson" Thread-Topic: [Roll] Benjamin Kaduk's Discuss on draft-ietf-roll-turnon-rfc8138-14: (with DISCUSS and COMMENT) Thread-Index: AQHWhvbDFnz+ZxCN2kqfSLm4/QQEM6lhafFggADkOACAAVPGAIAAAK+AgAAvlRyACqqkkIAAO8YAgAAzb6aAAAQpAIAAVGSAgAiD2ECAAD3vgIAJd1hAgD+ZLwCAAEVDsIABhn8AgACo+UA= Date: Wed, 11 Nov 2020 17:31:28 +0000 Deferred-Delivery: Wed, 11 Nov 2020 17:30:32 +0000 Message-ID: References: <117497.1600481093@dooku> <20201110033438.GE39170@kduck.mit.edu> <20201111070010.GU39170@kduck.mit.edu> In-Reply-To: <20201111070010.GU39170@kduck.mit.edu> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: mit.edu; dkim=none (message not signed) header.d=none;mit.edu; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2a01:cb1d:4ec:2200:90d6:2c75:2304:2eda] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b0219558-8ee1-4985-ecbe-08d88667a8f6 x-ms-traffictypediagnostic: MWHPR11MB1824: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Qq8RaeiGkbECNGHeEpXGF9p5HbR54edV9TG4W9tJvbNxEi6zirGqy4v9EtOB4OEZai5xnvPNDzDbIzsTyzhTio6fyK6pH+PB5IY6/O+OQmelv9t2WWdR5gMVq/jJmq44vaQnTSakI6Gqt6+PhoQObGb88EPlMZtAhA4G5qq1AAHbKzqx7zR4HZ9RHOmIoMZjr4/BsV/+zfnAYBM9rg4lOOzBmzQqS90jx77RErzK1RV3K0vgpge94k2dB6/UFCZ9E7gT7j+crXAbF/kh0+RPJWiG+d4YtEuEOBR4O9fMBzv9dLEVRetgSgAd+HOjA82GgAaOzjifsa9VNx3/ly0/838DCPSLbcf6/Sr6i6yaThW2IE+lBe2N+ZbGXTMb526HiPOvbx0D50o730/FbFR+bw== 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:(376002)(366004)(346002)(136003)(39860400002)(396003)(55016002)(5660300002)(8676002)(7696005)(8936002)(6506007)(53546011)(33656002)(86362001)(6916009)(76116006)(478600001)(186003)(71200400001)(316002)(52536014)(2906002)(4326008)(66556008)(83380400001)(66476007)(64756008)(66446008)(966005)(6666004)(66946007)(54906003)(9686003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?iso-8859-1?Q?8XpoMLIg8Oma4ENhG1N/YQv9brBXA9iHEr1GjZYAyTgDFA6IpvAF0M58yl?= =?iso-8859-1?Q?KwDLpr5JBldmIwcRvBFnNLsyAlA8enByUa392SZ0b/U0Dj57k4GSGbCVaM?= =?iso-8859-1?Q?BDPljcOaLI0CUUwmdT8GC6EEXr20cPqo0EKHmDHVaI5a1Q3w4vS+TSXVuU?= =?iso-8859-1?Q?sU1D7IACLVilFoul8n5JIIspaYVVlSrpHrivHHpRujW58943LXmtLYqj1Q?= =?iso-8859-1?Q?o8FycQ9cxCqu6/mof5Qjk2QyxfGJ4GBA/pI97rc1PhYE8mJWbyll9dEeK0?= =?iso-8859-1?Q?mxs0bFIYcZ81mSpjWpauVWc0LhJnqLS7josBdC5CKDYJneWTjhdhsxNfSk?= =?iso-8859-1?Q?RTURtFk7Msmm7F1fXhJT517Azc+EEHNH1jZmWJW2ufd1Uo96kl4CRZG6Yg?= =?iso-8859-1?Q?6+2ZFz9Qh8KxBf6QX0ga0r6lnYbrsrKwmdO7nCGoyl4m75nS/GXGCkpD/B?= =?iso-8859-1?Q?PZsVQzTk17xWeueOulSDOqDJuV/QKwaXEnmcC9Jx+84c5P/eeUuiUDW3zA?= =?iso-8859-1?Q?BMM1M7IaoeExnTrBo4f/pYtoLLCn0YcOTtYmOVS6w/+lRmAGikTYm+brA1?= =?iso-8859-1?Q?wyWhbVlSKed39Fz/ZZpuoz+dCfF0zgeesXNTWKdTGPKA5utLImnAMd1kST?= =?iso-8859-1?Q?tBShsx4JPeD2BZAOaGq00FyxH7PbUYn5zj//ZrsMX1pL9RL0CZCBaROZ9p?= =?iso-8859-1?Q?G6jaWU4hJTGoMbjjbmrat7IYb6zb3uxpUPi0pQBITGu+zAZ0fncet6G9gs?= =?iso-8859-1?Q?E60aqL1ti4L1vJ6DkNAuCKs9pbxlJ4tCng+91g+2DhHBBbUiQXaX2P/Xis?= =?iso-8859-1?Q?iGxznijlpoP2tBt12Ztyb43uMC7lyWkhpgkijTLQz8n65fBSRzovf28XBC?= =?iso-8859-1?Q?tgqxvVLwYEiepN0YOEYbwmkFTVbiArujM63xAEU8UpcHJS7vK8qR1Os2pM?= =?iso-8859-1?Q?WxnUf5fiBtasXAjunij08CQgfDkVkiXPEUCc1O7JdehulDWZiA77VA=3D?= =?iso-8859-1?Q?=3D?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB4881.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b0219558-8ee1-4985-ecbe-08d88667a8f6 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Nov 2020 17:31:44.6756 (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: yT6wHUdBt8fNl5breE/ttS3fQRwSfSTtSGOVJNFpPjE3b6yBmm1LMB3clqRwCeBttNe+VYFXozQccomgzNEA6g== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1824 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: alln-core-3.cisco.com Archived-At: Subject: Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf-roll-turnon-rfc8138-14: (with DISCUSS and COMMENT) 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, 11 Nov 2020 17:46:24 -0000 Hello Benjamin =20 > I will say a bit more inline, but want to note upfront that my primary un= ease > here is that we seem to be assigning some (partial) semantics to MOP valu= e 7 > here (even though we do not specify full semantics for MOP value 7): >=20 > For a MOP value of 7, [RFC8138] MUST be > used on Links where 6LoWPAN Header Compression [RFC6282] applies and > MUST NOT be used otherwise. True; we considered the position of an implementer testing for MOP < 7 to d= ecide if the flag was meaningful. That implementer would have to populate the else statement and we preferred= to give him instructions rather than have different implementations do dif= ferent things. >=20 > yet there is no "trail of breadcrumbs" for someone to follow from "I want= to > implement MOP 7" and end up at the sentence I quoted above. A formal > Update to 6550 would provide such a trail, as would being listed as a > reference in the IANA registry for MOP value 7. My current understanding= is There was this traceability statement in https://tools.ietf.org/html/draft-= ietf-roll-turnon-rfc8138-15#section-3 which is gone now. I followed Alvaro's lead there; we removed it based on an interpretation of= the "updates" that denotes a change in RFC 6550 implementations, which is = not the case here. Using a reserved flag is not an "update" per this interp= retation. But yes, I see your point.=20 > that the only thing we have right now is "repeat this requirement in what= ever > document ends up providing a full specification for MOP value 7", and I d= on't > think that relying on the IETF's collective memory is a great way to enfo= rce > such a requirement -- we can and have in the past slipped up and publishe= d > RFCs that are inconsistent with requirements imposed by previous ones. True. We have created a file to store this kind of memory. I added your qu= ote there, please see: https://github.com/roll-wg/RPLv2/blob/main/README.md I've been thinking about it so more but cannot find a better answer... Many thanks! Pascal >=20 > On Tue, Nov 10, 2020 at 08:15:33AM +0000, Pascal Thubert (pthubert) wrote= : > > Hello Benjamin: > > > > > That said, and my apologies for a hazy memory coming back to this > > > after a couple months, in a year or N from now when mopex is > > > finalized, how will someone looking at mopex know to use RFC8138 on > > > links where 6LoWPAN Header Compression applies (and not use it > > > otherwise)? We are claiming in the -14 of this document that: > > > > > > For a MOP value of 7, [RFC8138] MUST be > > > used on Links where 6LoWPAN Header Compression [RFC6282] applies > and > > > MUST NOT be used otherwise. > > > > > > but I am not sure (or have forgotten) what the chain of references > > > is supposed to lead someone who is implementing RPL plus MOP=3D7 to > > > the requirement to use RFC 8138. I don't think we should just rely > > > on the mopex text to do so, since we are trying to impose the > > > requirement with this document (which predates mopex by some time), > > > and there's not anything (other than our collective memories, of > > > course) requiring mopex to remain consistent with that requirement. > > > > Just to be clear for the other readers: MOPext does not exist as a norm= ative > reference for this work. > > The only field that exists is the MOP field in the DIO and that field i= s 3 bits > long, values 0..7. >=20 > Yes. >=20 > > The normative reference that you are after is > > https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/ > > This is the spec that updates RPL and changes the IANA registry to indi= cate > that 7 is not a MOP. >=20 > Not a MOP at all, or not a "normal" MOP that behaves like 0..6? >=20 > > There we have: > > > > " > > > > ... > > > > Anticipating future work to revise RPL relating to how the LLN and > > DODAG is configured, this document changes the interpretation of the > > [dodagcfg] Registry to be limited to Mode-of-Operation (MOP) > > specific. The MOP is described in [RFC6550] section 6.3.1. The > > Options Flags Registry is renamed, and applies to MOP values zero (0= ) > > to six (6) only, leaving the flags reserved for MOP value seven (7). > > > > In addition, this document reserves MOP value 7 for future expansion= . > > > > ... > > > > 11.3. Change MOP value 7 to Reserved > > > > This document changes the allocation status of the Mode of Operation > > (MOP) [ianamop] from Unassigned to Reserved. This change is in > > support of future work related to capabilities. > > " > > > > So basically we tell the implementations from now on to test if MOP is = 7, > and in that case, the Options Flags are undefined. In other words, if MOP= is 7, > the stack must not use the option flags as if the MOP was <7. In fact, 7 = is no > more a MOP value but a reserved thingy that can be overloaded in the futu= re. > And yes, we intend to do just that in MOPExt. > > > > Until that happens, implementations are at a loss if they encounter whe= n a > MOP field that is all ones. So we need to give them instructions to cope = with > the situation. This draft derives whether to use RFC 8138 from whether th= e > 6LoWPAN compression applies to the link or not. >=20 > Yes, we are saying "if you see a MOP field that is all ones, do this". T= o me, > that seems like we want to be listed as an additional reference for MOP v= alue > 7 in the IANA registry. >=20 > > This will stay true forever, unless another RFC amends it. When/if that > happens, the new RFC will have to consider backward compatibility with a > legacy implementation that implements the above. >=20 > It will stay true forever (until amended), but how does a new person maki= ng > an implementation know to find this document and do so? [useofrplinfo] s= ays > that MOP value 7 is special and needs dedicated handling, but it doesn't = say > anything about using 8138 [on links where 6LoWPAN Header Compression > applies]. I'm missing the trail of breadcrumbs. >=20 > Thanks, >=20 > Ben >=20 > > Note that this line of thought applies to 3 flags, defined respectively= in: > > - https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/ > > - https://datatracker.ietf.org/doc/draft-ietf-roll-turnon-rfc8138/ > > - https://datatracker.ietf.org/doc/draft-ietf-roll-unaware-leaves/ > > > > Keep safe! > > > > Pascal > > > > > > > > Thanks, > > > > > > Ben > > > > > > On Wed, Sep 30, 2020 at 04:25:10PM +0000, Pascal Thubert (pthubert) > wrote: > > > > Hello Alvaro > > > > > > > > I uploaded both draft with the suggested update, please see > > > > > > > > https://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-turnon-rfc813= 8-17. > > > > txt > > > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-unaware-leaves-= 2 > > > > 1.tx > > > > t > > > > > > > > Keep safe > > > > > > > > Pascal > > > > > > > > > -----Original Message----- > > > > > From: Alvaro Retana > > > > > Sent: jeudi 24 septembre 2020 17:49 > > > > > To: Pascal Thubert (pthubert) > > > > > Cc: Benjamin Kaduk ; The IESG ; > > > > > draft-ietf- roll-turnon-rfc8138@ietf.org; Martin Duke > > > > > ; Routing Over Low power and Lossy > > > > > networks ; roll- chairs@ietf.org; Michael > > > > > Richardson > > > > > Subject: Re: [Roll] Benjamin Kaduk's Discuss on > > > > > draft-ietf-roll-turnon-rfc8138- > > > > > 14: (with DISCUSS and COMMENT) > > > > > > > > > > On September 24, 2020 at 8:13:09 AM, Pascal Thubert wrote: > > > > > > > > > > > > > > > Pascal: > > > > > > > > > > Hi! > > > > > > > > > > > Following the meeting last Monday and subsequent the update of > > > > > > useofrplinfo by Michael (thanks Michael!) I published a new > > > > > > version of the turnon RFC > > > > > > 8138 draft. > > > > > > > > > > > > The major changes are > > > > > > - removed the formal update to RFC 6550 > > > > > > - refer to useofrplinfo as the justification why the flag is > > > > > > not defined for MOP 7 > > > > > > - defined the operation in MOP 7 as compression on iff the > > > > > > Link uses 6LoPWAN HC. > > > > > > > > > > Thanks for these changes. > > > > > > > > > > Because we have to cycle useofrplinfo back through (when the WG > > > > > is done with it), I asked Ben/Martin to wait for that before > > > > > coming back to this document. =A0It'll make it easier than > > > > > tracking multiple changes. :-) > > > > > > > > > > > > > > > OTOH, I do have comments on the recent change: > > > > > > > > > > OLD> > > > > > =A0 =A0Section 4.3 of [USEofRPLinfo] updates [RFC6550] to indicat= e > > > > > that the > > > > > =A0 =A0definition of the Flags applies to Mode of Operation (MOP) > > > > > values > > > > > =A0 =A0zero (0) to six (6) only, leaving the flags reserved for M= OP > > > > > value > > > > > =A0 =A0seven (7). =A0For a MOP value of 7, the bit in position 2 = is > > > > > considered > > > > > =A0 =A0unallocated and [RFC8138] MUST be used on Links where 6LoW= PAN > > > > > Header > > > > > =A0 =A0Compression [RFC6282] applies and MUST NOT be used otherwi= se. > > > > > > > > > > NEW> > > > > > > > > > > =A0 =A0Section 4.3 of [USEofRPLinfo] updates [RFC6550] to indicat= e > > > > > that the > > > > > =A0 =A0definition of the Flags applies to Mode of Operation (MOP) > > > > > values zero (0) > > > > > =A0 =A0to six (6) only. =A0For a MOP value of 7, [RFC8138] MUST b= e > > > > > used on Links > > > > > =A0 =A0where 6LoWPAN Header Compression [RFC6282] applies and MUS= T > > > > > NOT be used > > > > > =A0 =A0otherwise. > > > > > > > > > > > > > > > Thanks! > > > > > > > > > > Alvaro. From nobody Wed Nov 11 10:02:51 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 154CE3A3FBE; Wed, 11 Nov 2020 09:50:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.598 X-Spam-Level: X-Spam-Status: No, score=-9.598 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_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=cIqZ/0n4; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=HPRacb7m 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 5mufucH4nFQa; Wed, 11 Nov 2020 09:50:23 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B97323A3FB7; Wed, 11 Nov 2020 09:34:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3404; q=dns/txt; s=iport; t=1605116087; x=1606325687; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=I7IhnV0WzgQXJhJYhwWB08Un2zYLhBTA2bZ33ZQ+jT0=; b=cIqZ/0n4XzTb7e2X9pKqH9NZYvXxIR2KAxKRytiw4hRwkP/J/Ux6D2UR EBpToRZ2ctZYLkRB09TCg8gc9D87XkCEivMViaLC95DjnAsguRN5bm6TT WL4Ek8FFn04qGbTqTyROZcetcIM+TCIUI28efanEDhXQaoHJynlGh5jT9 w=; X-IPAS-Result: =?us-ascii?q?A0DrCADrH6xffYQNJK1igQmDIVF7WS8uhD2DSQONVZkDg?= =?us-ascii?q?UKBEQNUCwEBAQ0BARgLCgIEAQGESgIXgX8CJTgTAgMBAQEDAgMBAQEBBQEBA?= =?us-ascii?q?QIBBgQUAQGGPAyFcgEBAQQBARAREQwBASwLAQsEAgEIEQQBAQMCJgICAiULF?= =?us-ascii?q?QgIAgQBDQUIGoMFglUDLgEOpRkCgTyIaHaBMoMEAQEFgUdBgwkNC4IQAwaBD?= =?us-ascii?q?iqCc4JlTkKGVxuBQT+BEUOCTz6CG0IBAQEBAQGBJgESASODFTOCLJA/gyekS?= =?us-ascii?q?QqCbYkPkieDGYoVlEmTUYF/iH2RH4Q0AgQCBAUCDgEBBYFrIWlYEQdwFTuCa?= =?us-ascii?q?VAXAg2OVoM6hRSFRHQCNgIGAQkBAQMJfI1MAQE?= IronPort-PHdr: =?us-ascii?q?9a23=3AqqztBhMIZWlhKxjGsFAl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEvKwx3lDMVITfrflDjrmev6PhXDkG5pCM+DAHfYdXXh?= =?us-ascii?q?AIwcMRg0Q7AcGDBEG6SZyibyEzEMlYElMw+Xa9PBtaHc//YxvZpXjhpTIXEw?= =?us-ascii?q?/0YAxyIOm9E4XOjsOxgua1/ZCbYwhBiDenJ71oKxDjpgTKvc5Qioxneas=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.77,470,1596499200"; d="scan'208";a="587188069" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Nov 2020 17:34:46 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 0ABHYkbO020613 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 11 Nov 2020 17:34:46 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 11 Nov 2020 11:34:46 -0600 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 11 Nov 2020 11:34:46 -0600 Received: from NAM10-BN7-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 11 Nov 2020 11:34:46 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=K246/ODarnn8XCcR8UoT6PFxrvjHjKSTCq6MS6RvM6tPpg6OiPC7HQmDhU/pUfo1RfQifUjYhwGTJAA7iX15JUFse0XDRVjfpYEkXHUxDE181T6MJqG/PdJpj5wOMOXBcf1EkJtHIx6Kvnkn1wmOK4oPkR2F3ebKMLtGC5P4clwFVcfu9d+yWTJaTOrorMtpzH/b0TYETHQZ7Q8p8Frt3JEJy+6+wYPvryoSHjS1f6FaS8XhEeevkv4L0RpTcFB6GAlLty3jvnopPn0kpWewGkgyu1YcymdQbASN2Xr9wZi0RO8MwNGgXEQaqSStbc20CJ+PqhxyorpxP95lR1Tx8w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=I7IhnV0WzgQXJhJYhwWB08Un2zYLhBTA2bZ33ZQ+jT0=; b=YWEM2XyhQ0APZ6gQ8BDDoYqUlcOSeZ1/2dtXRvO1AxocUpTySzhKfkUUEx/HGEVgaxQrLVW4gojsOOR+xn/7H+zKsH5w/7r5ieMmqQXf77ymZdQJgXnGKU7K1IaeVUXv1CyqXa4tt4SVB988XdoErqOfPllW26tQktxS5k3cQ0SNxNL2bkJmtKymDIEUJlK4dY3D5Ft0GVUTw0UcjnwBL8pIFRDRDKT9RkpVlmQ3b9xzilhXKsQ8lz4rojvgaXBuvRarXOCR9dhlCv1XRw2CZ1IBjFJ/7zwR/RMjqVcgGyhWQM28l4x3KLfAHqDdzVI/HC+wE6+hqe0YBUwe93sqWg== 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=I7IhnV0WzgQXJhJYhwWB08Un2zYLhBTA2bZ33ZQ+jT0=; b=HPRacb7m/6eKSbeSHUPbysI2D2cGGMHCnTvKAg2yc7cb5OfoFYZPB616pTrtMx6zj+Hds5PdJUNONq7KOusRu2+MegNXWu5fL85TL81IyIYHW2vy1S++eEicLE2lEpzS155xvuy/NV1jACnJmEtRJyU3s6uqLrMQ9LMygSRV+Zk= Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by MWHPR11MB1824.namprd11.prod.outlook.com (2603:10b6:300:110::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.24; Wed, 11 Nov 2020 17:34:44 +0000 Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::ad88:1b7e:c9f2:b30d]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::ad88:1b7e:c9f2:b30d%6]) with mapi id 15.20.3541.025; Wed, 11 Nov 2020 17:34:44 +0000 From: "Pascal Thubert (pthubert)" To: Martin Duke , "Routing Over Low power and Lossy networks" , The IESG CC: "roll-chairs@ietf.org" , "mariainesrobles@googlemail.com" , "draft-ietf-roll-turnon-rfc8138@ietf.org" Thread-Topic: [Roll] Martin Duke's No Objection on draft-ietf-roll-turnon-rfc8138-17: (with COMMENT) Thread-Index: AQHWuEl0zYpZXUgJ+k6GiDeXsf8wZqnDLhNw Date: Wed, 11 Nov 2020 17:34:27 +0000 Deferred-Delivery: Wed, 11 Nov 2020 17:34:12 +0000 Message-ID: References: <160511284071.11537.6395585148979048057@ietfa.amsl.com> In-Reply-To: <160511284071.11537.6395585148979048057@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2a01:cb1d:4ec:2200:90d6:2c75:2304:2eda] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 13f1cbdf-123d-4443-94c7-08d88668144b x-ms-traffictypediagnostic: MWHPR11MB1824: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 2tty+EfUpvmANeh5VfbXme1i/ageapWZc5uL+TPphT/diJol294RqlMP7QzpY1dwGV+Ifzd/0NldXJx1RyGV0Az1lOVchgBkL+TGBGEtj2KaUrVsUZgTfssjltVzTSv+1eB5DIVAmXInRia7/0xX6mp+0m6wONLuBtmCnGdCA2kRt+MLe3aujXv8usmKgMttXvA46aT7RPheEQw6SAiWG8PSHfsZQOomtXRylH1vzeXTjxXjzI+K02cWdq+CpqMcMdY97ewY9wZKcMGb9jigOVqjiTIXI3bei87BVBIwehUXkOATlk19XARPTvkHBCmZTTn4LDPJGoUK+Ydc1ydfUNfWaIfF3WvQho7XnyS1BEjyWhNW7YaQcc/FhOwR4k2wtkjY08+fff3bBxbzVhzOMA== 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:(376002)(366004)(346002)(136003)(39860400002)(396003)(55016002)(5660300002)(8676002)(7696005)(8936002)(6506007)(53546011)(33656002)(86362001)(76116006)(478600001)(186003)(71200400001)(316002)(52536014)(2906002)(4326008)(66556008)(83380400001)(66476007)(64756008)(66446008)(966005)(6666004)(66946007)(110136005)(54906003)(9686003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?SkVrL2QvN3F3aG9KUVhtWnJzYXBWbkFoS3IyVVBDQ0I0Nk9uYVlKVzU4MklP?= =?utf-8?B?Tk8xQld5NlpsSjJUQy9idGMyRklwVmJrL2gxclBDSG1FTGRaOGZnQkRJUEZH?= =?utf-8?B?amRrb3NxU0d3Q1IwaGh3ZXBBR1MyKzdjQTFURUQ0bG9BOXllMk1IcG5ic0hx?= =?utf-8?B?VWs2YUlCa28zMkM1bENPQWg5SUFIY1ZsRUtHQVNNTEp0WDVtVVk0T0VLeElS?= =?utf-8?B?RnkwL2VRRERyMFJOZzcvRzZxdXFYWkhLbmpDMEFoMmFBSDBpMGVCR0t1Wjdi?= =?utf-8?B?ZFpTcm1HRWtMdnBmRkZES1RDckxveXVDbHVrVDBiRktWQXhINExlS0FuMnFz?= =?utf-8?B?bWVnanNwUjFDcW05ZjJKSEp6MkFJMnNvOU50b05KMnFzUW5mNHVRMFFFSmFM?= =?utf-8?B?SXdRb0VHVzhSWGdLdHYrRXhyTDRYTjNuaHNPREowYVRpc1Q1cElIYVc1Vm5X?= =?utf-8?B?THY1emRLV1lXSEFqaHM1L01jNGE4NHBtYUYrbmwxTmdneUw0NlAzOTRIZTdL?= =?utf-8?B?VHljSy9lSmZnd0VocFpZTmpXNlZKc1dzckp6ZEVsUzRxRW1LL0JLM0hpeDJn?= =?utf-8?B?TEFxdncrejdadzFpY21PY1M1bnNxQXJUVlNOdmFadXZsSkRaWGQ5Z1FKalRZ?= =?utf-8?B?cWNUekFBellqelNIWTNNcWxpVUg3VmRGSTZvcTRPRUFJb3c4STA3amE0d2Y5?= =?utf-8?B?cDl1azIvWlZ4Tko2YXB0bktzMG1ycFZobEJQb3ZDWHErV1FIL01Ud21UQzdr?= =?utf-8?B?Z29YKzBsWHJlSjJ1NzlCdXlYc1gzc3pxLzNpSjZXejRXV1dPeStzY204aDUr?= =?utf-8?B?bXNnS0k3UjZVcjBDRWFCTnBweWJFekZXbkg3U3NjSHVvcXRodU53engvOVZT?= =?utf-8?B?dlIxU3NIYTUxV0YxYjduQUJHUUxSUkI3YUR5aWY0UGgxOWM2djU5WmRxbE1Y?= =?utf-8?B?UktTOGIvUXM5VGZtcGpHM2tjVGpoek0wVndtaXFUV2IyYVdZQUp4WGNVakpE?= =?utf-8?B?aVlrOHVielBKUFBGcGFsdnQyaS80Zk9UQjhUNlA0SmFEMExjT3dMUHdxOVVh?= =?utf-8?B?NVhIRmhqQ2JxTlgwMS9pRHdkMmhYbzlLLzJJMjRyY0JKQ29LY0ZqaVdBM3c1?= =?utf-8?B?alhTK25NVlpiOHNBNEI0SnlYQUVUYWNvQXppdmdNTEkxdGI3RmQvU1Z2Sm90?= =?utf-8?B?bXQrbGhZWWlIdHd2Q2FmcXhFR0g1S3UyWXdCR3N3NUxKZ0JWN0RNejlqUllk?= =?utf-8?B?dUlWKzBuTklHYUx2bHlGRFRWcUNvN1pMUmpINWpVWU5FdUs1dz09?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB4881.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 13f1cbdf-123d-4443-94c7-08d88668144b X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Nov 2020 17:34:44.6918 (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: X0qvXASOdDTCoatitDq3ruSRHmXfDR8IFK8TywP76FWIlhevjzJ/uv/DxQRcr5YTpSoizjxBdK4hfgXsXsbcfA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1824 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com X-Outbound-Node: alln-core-10.cisco.com Archived-At: Subject: Re: [Roll] Martin Duke's No Objection on draft-ietf-roll-turnon-rfc8138-17: (with COMMENT) 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, 11 Nov 2020 17:50:30 -0000 SGVsbG8gTWFydGluOg0KDQpNT1AgNyBpcyBub3QgYWRkZWQgYnkgdGhpcyBkb2N1bWVudCBidXQg YnkgdXNlb2ZycGxpbmZvLiBUaGlzIGlzIHdoeSB3ZSBkbyBub3QgdXBkYXRlIGl0IGhlcmUuDQpQ bGVhc2Ugc2VlIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJvbGwtdXNl b2ZycGxpbmZvLTQxI3NlY3Rpb24tNC4zDQoNCkknbSByZWx1Y3RhbnQgYXBwbHlpbmcgdGhlIGNo YW5nZSB5b3UgcHJvcG9zZS4gQ29uc2lkZXJpbmcgdGhlIGFib3ZlIGl0IHNlZW1zIG1pc2xlYWRp bmcuDQpBbHNvIGl0IHRvb2sgYSBhIGxvdCBvZiBlZmZvcnQgZnJvbSBtdWx0aXBsZSBwZXJzb25z IChBbHZhcm8gbGVhZGluZykgdG8gY3JhZnQgdGhhdCBwYXJ0aWN1bGFyIHNlbnRlbmNlLg0KV2Ug c2VlbSB0byBoYXZlIHJlYWNoZWQgYSBkaWZmaWN1bHQgY29uc2Vuc3VzLg0KDQpUYWtlIGNhcmUN Cg0KUGFzY2FsDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogUm9sbCA8 cm9sbC1ib3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgTWFydGluIER1a2UgdmlhIERhdGF0 cmFja2VyDQo+IFNlbnQ6IG1lcmNyZWRpIDExIG5vdmVtYnJlIDIwMjAgMTc6NDENCj4gVG86IFRo ZSBJRVNHIDxpZXNnQGlldGYub3JnPg0KPiBDYzogcm9sbC1jaGFpcnNAaWV0Zi5vcmc7IHJvbGxA aWV0Zi5vcmc7IG1hcmlhaW5lc3JvYmxlc0Bnb29nbGVtYWlsLmNvbTsNCj4gZHJhZnQtaWV0Zi1y b2xsLXR1cm5vbi1yZmM4MTM4QGlldGYub3JnDQo+IFN1YmplY3Q6IFtSb2xsXSBNYXJ0aW4gRHVr ZSdzIE5vIE9iamVjdGlvbiBvbiBkcmFmdC1pZXRmLXJvbGwtdHVybm9uLXJmYzgxMzgtDQo+IDE3 OiAod2l0aCBDT01NRU5UKQ0KPiANCj4gTWFydGluIER1a2UgaGFzIGVudGVyZWQgdGhlIGZvbGxv d2luZyBiYWxsb3QgcG9zaXRpb24gZm9yDQo+IGRyYWZ0LWlldGYtcm9sbC10dXJub24tcmZjODEz OC0xNzogTm8gT2JqZWN0aW9uDQo+IA0KPiBXaGVuIHJlc3BvbmRpbmcsIHBsZWFzZSBrZWVwIHRo ZSBzdWJqZWN0IGxpbmUgaW50YWN0IGFuZCByZXBseSB0byBhbGwgZW1haWwNCj4gYWRkcmVzc2Vz IGluY2x1ZGVkIGluIHRoZSBUbyBhbmQgQ0MgbGluZXMuIChGZWVsIGZyZWUgdG8gY3V0IHRoaXMg aW50cm9kdWN0b3J5DQo+IHBhcmFncmFwaCwgaG93ZXZlci4pDQo+IA0KPiANCj4gUGxlYXNlIHJl ZmVyIHRvIGh0dHBzOi8vd3d3LmlldGYub3JnL2llc2cvc3RhdGVtZW50L2Rpc2N1c3MtY3JpdGVy aWEuaHRtbA0KPiBmb3IgbW9yZSBpbmZvcm1hdGlvbiBhYm91dCBJRVNHIERJU0NVU1MgYW5kIENP TU1FTlQgcG9zaXRpb25zLg0KPiANCj4gDQo+IFRoZSBkb2N1bWVudCwgYWxvbmcgd2l0aCBvdGhl ciBiYWxsb3QgcG9zaXRpb25zLCBjYW4gYmUgZm91bmQgaGVyZToNCj4gaHR0cHM6Ly9kYXRhdHJh Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1yb2xsLXR1cm5vbi1yZmM4MTM4Lw0KPiANCj4g DQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IENPTU1FTlQ6DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gDQo+ IFRoYW5rcyBmb3IgYWRkcmVzc2luZyBteSBESVNDVVNTLg0KPiANCj4gSSBmb3VuZCBsYXN0IHBh cmFncmFwaCBvZiBTZWN0aW9uIDMgY29uZnVzaW5nLiBJIHN1Z2dlc3QgdGhlIGZvbGxvd2luZyBj aGFuZ2U6DQo+IA0KPiBPTEQ6DQo+IFNlY3Rpb24gNi4zLjEgb2YgW1JGQzY1NTBdIGRlZmluZXMg YSAzLWJpdCBNb2RlIG9mIE9wZXJhdGlvbiAoTU9QKSBpbiB0aGUNCj4gRElPIEJhc2UgT2JqZWN0 LiBUaGlzIHNwZWNpZmljYXRpb24gYXBwbGllcyB0byBNT1AgdmFsdWVzIDAgdG8gNi4gRm9yIGEg TU9QDQo+IHZhbHVlIG9mIDcsIHRoZSBjb21wcmVzc2lvbiBNVVNUIGJlIHVzZWQgYnkgZGVmYXVs dCByZWdhcmRsZXNzIG9mIHRoZSBzZXR0aW5nDQo+IG9mIHRoZSAiVCIgZmxhZy4NCj4gDQo+IE5F VzoNCj4gIlNlY3Rpb24gNi4zLjEgb2YgW1JGQzY1NTBdIGRlZmluZXMgYSAzLWJpdCBNb2RlIG9m IE9wZXJhdGlvbiAoTU9QKSBpbiB0aGUNCj4gRElPIEJhc2UgT2JqZWN0LiBUaGlzIHNwZWNpZmlj YXRpb24gYWRkcyBjb2RlcG9pbnQgNyB0byB0aGUgcmVnaXN0cnkgZm9yIHRoaXMNCj4gZmllbGQu ICAgRm9yIGEgTU9QIHZhbHVlIG9mIDcsIHRoZSBjb21wcmVzc2lvbiBNVVNUIGJlIHVzZWQgYnkg ZGVmYXVsdA0KPiByZWdhcmRsZXNzIG9mIHRoZSBzZXR0aW5nIG9mIHRoZSAiVCIgZmxhZy7igJwN Cj4gDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gUm9sbCBtYWlsaW5nIGxpc3QNCj4gUm9sbEBpZXRmLm9yZw0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwNCg== From nobody Wed Nov 11 14:10:36 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E8D23A1174; Wed, 11 Nov 2020 14:10:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, 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 xfBnHBiVNfDC; Wed, 11 Nov 2020 14:10:33 -0800 (PST) Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (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 71E653A116F; Wed, 11 Nov 2020 14:10:33 -0800 (PST) Received: by mail-ua1-x934.google.com with SMTP id q68so1219608uaq.3; Wed, 11 Nov 2020 14:10:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=+RwgCmUKvNzC+k1pfB7JdhwfpXu6TgKsLIQhAeRUQoU=; b=mIzbCuoq7HW6q0QJnXIjJvv6pOaSPk7XP+11N0iUu4RlcyXHdnYVH5gxwWY6dihVH+ dQXE5bEZHw/QNTKAEpOS3Nmf0LlrySmx8ZJ66nxoon57RTzZfl+REM2X69vRV4gjvrPl 7530mMO9APImbGw2GIYUQoQ6qjbsc3JdlCfyUCeakcIl2gHk32hVLDz9BAA4jWKjlIbZ vptCGwo6Bce3x0JCoKDfgP3885d4knZyGHA24AOoc35bhAkKa9i2bXks69BjSWE2vA3W 2vOiLxBqp1llronUeWTxbze5Ae3/InWG/llOS7ZnFicDh0ouAg39BMcmPaCOXy25qcDG MyBw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=+RwgCmUKvNzC+k1pfB7JdhwfpXu6TgKsLIQhAeRUQoU=; b=SjU6Z8/4hrWBRpyew7yShGUTbGt5yARw/XrFmOj3EmxGvGsFKC4HjX+QtlfiZOH952 7rzxUCPCAzLUX8VIqncxv5Ik6324AZmwfDklHtFISeTgWfjLRVh/eJn/lmOWiEOq5Uw6 aVynng2+hwQD7ehC1mL7UfaoMK8xq/PX+BvbCrhBW5OxNOyrW9LTjuL6BDM7sK4LlPYA kAPtmvHoRWTUq5Fa93U9QakozY+HFHFCccI4jPbZL9sDnJ5v0pLiwCQOSZ54oFz8v1Sy f7A02+7ea1nYTllbCHwqZkcD0Lcz6yeg99o7laEY7G2iqGlCnC84Bf0k1pyHjGvLBCy9 mlfQ== X-Gm-Message-State: AOAM533tFcgK5dyxi5K6mTAqi05R/drfpjI9CsWQUHy059ti1gNHT02m upmc3z47yW27CAzzcZA51u89IEBWEWnjLqz4Vik= X-Google-Smtp-Source: ABdhPJzMFVA8MOw9pnzcPlHaC+/APjl9UyyUvGl216yrCXeFq6Jxa7A5AMxxBjXuvQS2ww45izAI/dwwKfBkmEwrdBI= X-Received: by 2002:ab0:1c08:: with SMTP id a8mr3385961uaj.17.1605132632397; Wed, 11 Nov 2020 14:10:32 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Ines Robles Date: Thu, 12 Nov 2020 00:09:56 +0200 Message-ID: To: Alvaro Retana Cc: "draft-ietf-roll-useofrplinfo@ietf.org" , Peter van der Stok , "roll-chairs@ietf.org" , Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="0000000000005f1a3005b3dc10ab" Archived-At: Subject: Re: [Roll] AD Review of draft-ietf-roll-useofrplinfo-41 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, 11 Nov 2020 22:10:35 -0000 --0000000000005f1a3005b3dc10ab Content-Type: text/plain; charset="UTF-8" Hi Alvaro, Many thanks for your review. We addressed your comments on version 42 ( https://github.com/roll-wg/useofrplinfo/blob/master/draft-ietf-roll-useofrplinfo-42.txt ) Should be do a manual post request or wait until 14th Nov? Thank you again, Ines. On Mon, Nov 9, 2020 at 8:57 PM Alvaro Retana wrote: > Dear authors: > > Thank you for all the work on this draft. > > I have a couple of comments in-line -- nothing hard to address. I > mostly looked at the diffs (wrt -31) and so my comments are just on > new text. > > I want to progress this draft with unaware-leaves -- to make it easier > on the IESG. I'll start the IETF LC when both are ready. > > Thanks! > > Alvaro. > > > >From idnits: > > ** The abstract seems to contain references ([RFC8138]), which it > shouldn't. Please replace those with straight textual mentions of the > documents in question. > > > > [Line numbers from idnits.] > > > ... > 66 4. Updates to RFC6553, RFC6550 and RFC8138 . . . . . . . . . . > . 7 > 67 4.1. Updates to RFC6550: Advertising External Routes with > Non- > 68 Storing Mode Signaling. . . . . . . . . . . . . . . . . > . 7 > 69 4.2. Updates to RFC6553: Indicating the new RPI Option Type. > . 8 > 70 4.3. Updates to RFC6550: > 71 Configuration Options and Mode > 72 of Operation . . . . . . . . . . . . . . . . . . . . . > . 11 > 73 4.4. Updates to RFC6550: Indicating the new RPI in the > 74 DODAG Configuration option Flag. . . . . . . . . . . . > . 12 > 75 4.5. Updates to RFC8138: Indicating the way to decompress > with > 76 the new RPI Option Type. . . . . . . . . . . . . . . . > . 13 > > [nit - no action needed, just a suggestion] Group all the updates to > rfc6550: either in one sub-section or in consecutive ones. > > > ... > 493 4.3. Updates to RFC6550: Configuration Options and Mode of > Operation > > 495 RFC6550 section 6.7.6 describes the DODAG Configuration > Option. In > 496 this option are a series of Flags in the first octet of the > payload. > 497 These flags are described by the DODAG Configuration Option > Flags > 498 registry [dodagcfg], in section 20.14 of RFC6550. > > 500 Anticipating future work to revise RPL relating to how the LLN > and > 501 DODAG is configured, this document changes the interpretation > of the > 502 [dodagcfg] Registry to be limited to Mode-of-Operation (MOP) > 503 specific. The MOP is described in [RFC6550] section 6.3.1. The > 504 Options Flags Registry is renamed, and applies to MOP values > zero (0) > 505 to six (6) only, leaving the flags reserved for MOP value seven > (7). > > 507 In addition, this document reserves MOP value 7 for future > expansion. > > [] NEW> > Section 6.7.6 of RFC6550 describes the DODAG Configuration Option as > containing a series of Flags in the first octet of the payload --0000000000005f1a3005b3dc10ab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi=C2=A0Alvaro,

Many thanks for your re= view. We addressed your comments on version 42 (ht= tps://github.com/roll-wg/useofrplinfo/blob/master/draft-ietf-roll-useofrpli= nfo-42.txt)
Should be do a manual post request or wait until = 14th Nov?

Thank you again,

Ines.



On Mon, Nov 9, 2020 at 8:57 PM A= lvaro Retana <aretana.ietf@gma= il.com> wrote:
Dear authors:

Thank you for all the work on this draft.

I have a couple of comments in-line -- nothing hard to address. =C2=A0I
mostly looked at the diffs (wrt -31) and so my comments are just on
new text.

I want to progress this draft with unaware-leaves -- to make it easier
on the IESG.=C2=A0 I'll start the IETF LC when both are ready.

Thanks!

Alvaro.


>From idnits:

=C2=A0 ** The abstract seems to contain references ([RFC8138]), which it =C2=A0 =C2=A0 =C2=A0shouldn't.=C2=A0 Please replace those with straight= textual mentions of the
=C2=A0 =C2=A0 =C2=A0documents in question.



[Line numbers from idnits.]


...
66=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 4.=C2=A0 Updates to RFC6553, RFC6550 an= d RFC8138 . . . . . . . . . . . =C2=A0 7
67=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 4.1.=C2=A0 Updates to RFC6550: A= dvertising External Routes with Non-
68=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Storing Mod= e Signaling. . . . . . . . . . . . . . . . . . =C2=A0 7
69=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 4.2.=C2=A0 Updates to RFC6553: I= ndicating the new RPI Option Type. . =C2=A0 8
70=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 4.3.=C2=A0 Updates to RFC6550: 71=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Configurati= on Options and Mode
72=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 of Operatio= n =C2=A0. . . . . . . . . . . . . . . . . . . . . . =C2=A011
73=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 4.4.=C2=A0 Updates to RFC6550: I= ndicating the new RPI in the
74=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 DODAG Confi= guration option Flag. =C2=A0. . . . . . . . . . . . =C2=A012
75=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 4.5.=C2=A0 Updates to RFC8138: I= ndicating the way to decompress with
76=C2=A0 =C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the new RPI= Option Type. =C2=A0. . . . . . . . . . . . . . . . =C2=A013

[nit - no action needed, just a suggestion] Group all the updates to
rfc6550: either in one sub-section or in consecutive ones.


...
493=C2=A0 =C2=A0 =C2=A04.3.=C2=A0 Updates to RFC6550: Configuration Options= and Mode of Operation

495=C2=A0 =C2=A0 =C2=A0 =C2=A0 RFC6550 section 6.7.6 describes the DODAG Co= nfiguration Option.=C2=A0 In
496=C2=A0 =C2=A0 =C2=A0 =C2=A0 this option are a series of Flags in the fir= st octet of the payload.
497=C2=A0 =C2=A0 =C2=A0 =C2=A0 These flags are described by the DODAG Confi= guration Option Flags
498=C2=A0 =C2=A0 =C2=A0 =C2=A0 registry [dodagcfg], in section 20.14 of RFC= 6550.

500=C2=A0 =C2=A0 =C2=A0 =C2=A0 Anticipating future work to revise RPL relat= ing to how the LLN and
501=C2=A0 =C2=A0 =C2=A0 =C2=A0 DODAG is configured, this document changes t= he interpretation of the
502=C2=A0 =C2=A0 =C2=A0 =C2=A0 [dodagcfg] Registry to be limited to Mode-of= -Operation (MOP)
503=C2=A0 =C2=A0 =C2=A0 =C2=A0 specific.=C2=A0 The MOP is described in [RFC= 6550] section 6.3.1.=C2=A0 The
504=C2=A0 =C2=A0 =C2=A0 =C2=A0 Options Flags Registry is renamed, and appli= es to MOP values zero (0)
505=C2=A0 =C2=A0 =C2=A0 =C2=A0 to six (6) only, leaving the flags reserved = for MOP value seven (7).

507=C2=A0 =C2=A0 =C2=A0 =C2=A0 In addition, this document reserves MOP valu= e 7 for future expansion.

[] NEW>
=C2=A0 =C2=A0Section 6.7.6 of RFC6550 describes the DODAG Configuration Opt= ion as
=C2=A0 =C2=A0containing a series of Flags in the first octet of the payload=
--0000000000005f1a3005b3dc10ab-- From nobody Wed Nov 11 14:23:20 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD553A11BE; Wed, 11 Nov 2020 14:23:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 g3zbNz6PUlFV; Wed, 11 Nov 2020 14:23:10 -0800 (PST) Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (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 D95EB3A11C9; Wed, 11 Nov 2020 14:23:09 -0800 (PST) Received: by mail-il1-x12f.google.com with SMTP id g7so3414189ilr.12; Wed, 11 Nov 2020 14:23:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=l3qLvxQYr3wghA31GkRhRukhCiJzqS/EyL/csYBV3C0=; b=W/ZLrRYP4whYFsy4Ei/TcGmKkTA2AH1Levx0eLecModIfzrXlttX+1mBS4V/X17sGV kSYz81jHFYqA4BpoQzdRBpXeGqqOR1G5aSSWbYTfq93xJ4tij8bpS78ug4zEXGQDyuaa TB3TNeeO7L1pzLARC15RSlJTFMB0QZ4jA9serEqq4XKN8Ut/dwcMSgjpyBQhqXw1Rhaz ukaNjtdxknzdh0AM9cXrDQkuYZvcaH86PXF2x3PtyqnYNBZtX0oUFGxWQEbKIdKtcVG1 IXoXiclyvhYTqNkGr/UCa8XossZdrazLo1F+/+MxSK5JFoJz/FQbX2LG2YRVg+01RjyH ehJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=l3qLvxQYr3wghA31GkRhRukhCiJzqS/EyL/csYBV3C0=; b=kld4HD98TCjITTP0nNJaeJNQY7f2XyF20Gmhsi/8EAzLv/pNvdLF7srZFBlGJx5G9H K3CVWWs6pXX8XmNmed1O1xayen7GuoFUYC5qvuXCjwe49xw0gbvutvJ23yL214Yj4s1c XWJJAb1JSzC4yE/oUbi4EyGLLFgtA8kIP6ryNy6nLHOGgAjBFNeFdGhBvxfTx5aC7P2Y tXxOoFiN6BIJuupv5G7LL7tzFKPj93DMdMGbw5W2mjwPgG9ft4DnZbnUcnwrFkwJBhiL 95+++CbqWtREbE5dcwDKiAVeFO0lpxMQALs0NtAY/NwzbQAEr+Wgymsnn8YY/ISn8ZRl ZgfA== X-Gm-Message-State: AOAM533uTGr1u4v1rU0sE9airMFBJgL/PTVxSRKdSwy/wxJPw5A5kiIf WBcnwJTo23gbZWbNkf62ZFE3sW3CWXNK468lXTU= X-Google-Smtp-Source: ABdhPJy341DrQVJ5pfXxRymWrUPkCEiDanCsE3XZWnKppLfnLm8LQmxnMNFkU6Y7TRGESFcAXRVCFITghKSm0PrQVUs= X-Received: by 2002:a05:6e02:926:: with SMTP id o6mr20970233ilt.287.1605133389035; Wed, 11 Nov 2020 14:23:09 -0800 (PST) MIME-Version: 1.0 References: <160511284071.11537.6395585148979048057@ietfa.amsl.com> In-Reply-To: From: Martin Duke Date: Wed, 11 Nov 2020 14:22:58 -0800 Message-ID: To: "Pascal Thubert (pthubert)" Cc: Routing Over Low power and Lossy networks , The IESG , "roll-chairs@ietf.org" , "mariainesrobles@googlemail.com" , "draft-ietf-roll-turnon-rfc8138@ietf.org" Content-Type: multipart/alternative; boundary="000000000000787f7105b3dc3d7a" Archived-At: Subject: Re: [Roll] Martin Duke's No Objection on draft-ietf-roll-turnon-rfc8138-17: (with COMMENT) 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, 11 Nov 2020 22:23:16 -0000 --000000000000787f7105b3dc3d7a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable sorry, that comment is left over from the original ballot. On Wed, Nov 11, 2020 at 9:34 AM Pascal Thubert (pthubert) < pthubert@cisco.com> wrote: > Hello Martin: > > MOP 7 is not added by this document but by useofrplinfo. This is why we d= o > not update it here. > Please see > https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-41#section-4.3 > > I'm reluctant applying the change you propose. Considering the above it > seems misleading. > Also it took a a lot of effort from multiple persons (Alvaro leading) to > craft that particular sentence. > We seem to have reached a difficult consensus. > > Take care > > Pascal > > > -----Original Message----- > > From: Roll On Behalf Of Martin Duke via > Datatracker > > Sent: mercredi 11 novembre 2020 17:41 > > To: The IESG > > Cc: roll-chairs@ietf.org; roll@ietf.org; mariainesrobles@googlemail.com= ; > > draft-ietf-roll-turnon-rfc8138@ietf.org > > Subject: [Roll] Martin Duke's No Objection on > draft-ietf-roll-turnon-rfc8138- > > 17: (with COMMENT) > > > > Martin Duke has entered the following ballot position for > > draft-ietf-roll-turnon-rfc8138-17: No Objection > > > > 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/iesg/statement/discuss-criteria.html > > for more information about IESG DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-roll-turnon-rfc8138/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Thanks for addressing my DISCUSS. > > > > I found last paragraph of Section 3 confusing. I suggest the following > change: > > > > OLD: > > Section 6.3.1 of [RFC6550] defines a 3-bit Mode of Operation (MOP) in t= he > > DIO Base Object. This specification applies to MOP values 0 to 6. For a > MOP > > value of 7, the compression MUST be used by default regardless of the > setting > > of the "T" flag. > > > > NEW: > > "Section 6.3.1 of [RFC6550] defines a 3-bit Mode of Operation (MOP) in > the > > DIO Base Object. This specification adds codepoint 7 to the registry fo= r > this > > field. For a MOP value of 7, the compression MUST be used by default > > regardless of the setting of the "T" flag.=E2=80=9C > > > > > > > > _______________________________________________ > > Roll mailing list > > Roll@ietf.org > > https://www.ietf.org/mailman/listinfo/roll > --000000000000787f7105b3dc3d7a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
sorry, that comment is left over from the original ballot.=

= On Wed, Nov 11, 2020 at 9:34 AM Pascal Thubert (pthubert) <pthubert@cisco.com> wrote:
Hello Martin:

MOP 7 is not added by this document but by useofrplinfo. This is why we do = not update it here.
Please see https://tools.ietf= .org/html/draft-ietf-roll-useofrplinfo-41#section-4.3

I'm reluctant applying the change you propose. Considering the above it= seems misleading.
Also it took a a lot of effort from multiple persons (Alvaro leading) to cr= aft that particular sentence.
We seem to have reached a difficult consensus.

Take care

Pascal

> -----Original Message-----
> From: Roll <roll-bounces@ietf.org> On Behalf Of Martin Duke via Datatracker<= br> > Sent: mercredi 11 novembre 2020 17:41
> To: The IESG <ie= sg@ietf.org>
> Cc: roll-cha= irs@ietf.org; roll@i= etf.org; mariainesrobles@googlemail.com;
> draft-ietf-roll-turnon-rfc8138@ietf.org
> Subject: [Roll] Martin Duke's No Objection on draft-ietf-roll-turn= on-rfc8138-
> 17: (with COMMENT)
>
> Martin Duke has entered the following ballot position for
> draft-ietf-roll-turnon-rfc8138-17: No Objection
>
> 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 intr= oductory
> paragraph, however.)
>
>
> Please refer to https://www.ietf.org/i= esg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/do= c/draft-ietf-roll-turnon-rfc8138/
>
>
>
> ----------------------------------------------------------------------=
> COMMENT:
> ----------------------------------------------------------------------=
>
> Thanks for addressing my DISCUSS.
>
> I found last paragraph of Section 3 confusing. I suggest the following= change:
>
> OLD:
> Section 6.3.1 of [RFC6550] defines a 3-bit Mode of Operation (MOP) in = the
> DIO Base Object. This specification applies to MOP values 0 to 6. For = a MOP
> value of 7, the compression MUST be used by default regardless of the = setting
> of the "T" flag.
>
> NEW:
> "Section 6.3.1 of [RFC6550] defines a 3-bit Mode of Operation (MO= P) in the
> DIO Base Object. This specification adds codepoint 7 to the registry f= or this
> field.=C2=A0 =C2=A0For a MOP value of 7, the compression MUST be used = by default
> regardless of the setting of the "T" flag.=E2=80=9C
>
>
>
> _______________________________________________
> Roll mailing list
> Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll
--000000000000787f7105b3dc3d7a-- From nobody Wed Nov 11 14:49:27 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 174C23A11BB; Wed, 11 Nov 2020 14:49:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, 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 wVBQJ9VvD-RQ; Wed, 11 Nov 2020 14:49:21 -0800 (PST) Received: from mail-io1-xd2b.google.com (mail-io1-xd2b.google.com [IPv6:2607:f8b0:4864:20::d2b]) (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 C76793A11BA; Wed, 11 Nov 2020 14:49:21 -0800 (PST) Received: by mail-io1-xd2b.google.com with SMTP id m13so3995327ioq.9; Wed, 11 Nov 2020 14:49:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kNY4PNmfP3bKhz/KCVFlhts67iVDwK+dSpf0Yr9GCYc=; b=SDIGXQFnfDpv88Wne2ihdsou02dSPzesVAK36dSUkFwqeA4rcsGcBJ56fPdBgh199G k9OO0ZBuZYwSimzvU1WOrNYMalX95LK7CyhXt0TLM/vUhz/p+FnrTRAJA3uqSgnjv4Yi r4+/8DXPNKb0jvjcu8BJPCecU4svFrejjc438MX4f1FDzVoDUA2j+ssOUPM+DB41nr64 /JGw0uYN6110Gxz4feCdnHIFjc2oi3mkgQBiyj7Y0mai/0Vf6UCiA3+JMpOgI89xYV5a mkoLmea6sXNTCd4wPIFknFnmT6Dgqzx5xyVTFjdob6HErZxL3kLgaCLTklpvojN+cJ/S SBmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kNY4PNmfP3bKhz/KCVFlhts67iVDwK+dSpf0Yr9GCYc=; b=LqZxaYoequHGBgneI6Gw838bzCvyKQZjyI1o2fJULx+flEjAIRkeyV1LgLyjOCMj1Q Y/E23QZSR9wrzpm5COF1RxJsQEWWvj8DGWd8AqxRiheAqGA7Dxaix42SZGE/sGwgjrCz /iD3OODjjObllJFbCpqdJRZXXrSOYbT4qyT3R3aPhDC1OqoHV7pnm/P1UJAYlx9Ix/Ux QuZr6f19GdEcvyS59oVpZ1e2eJjQ6iPtT9jsd0R978KfLdbGjFtGWU+Eiwp2JRBaC7zm Ltxv/OInMFbdQoDQIC84owo4i2Z4Io6p2zdZFPOzXixUB6mNSaVc4nH0i1m4SzVAakSY Nmpg== X-Gm-Message-State: AOAM5319eEJyigR83oesHjuYjJ8YXpLgkpT9hBls0u20RBiK4O2gZHS9 siBQQPddDbjtsgbw+dcALJ35vtG/QxMLZwK88LY= X-Google-Smtp-Source: ABdhPJzOXRrwruq+xmj1sgbz21IHixaHQsZs5fdlysvtqFG+fAXhx/n8FN8HSBLLh4bOwHwVkR0+SILu/L+NQdxWiZ4= X-Received: by 2002:a6b:630b:: with SMTP id p11mr19719077iog.97.1605134961046; Wed, 11 Nov 2020 14:49:21 -0800 (PST) MIME-Version: 1.0 References: <6978.1605115717@localhost> In-Reply-To: <6978.1605115717@localhost> From: Martin Duke Date: Wed, 11 Nov 2020 14:49:10 -0800 Message-ID: To: Michael Richardson Cc: "Pascal Thubert (pthubert)" , Benjamin Kaduk , Alvaro Retana , The IESG , "draft-ietf-roll-turnon-rfc8138@ietf.org" , Routing Over Low power and Lossy networks , "roll-chairs@ietf.org" Content-Type: multipart/alternative; boundary="0000000000002b792a05b3dc9bac" Archived-At: Subject: Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf-roll-turnon-rfc8138-14: (with DISCUSS and COMMENT) 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, 11 Nov 2020 22:49:23 -0000 --0000000000002b792a05b3dc9bac Content-Type: text/plain; charset="UTF-8" On Wed, Nov 11, 2020 at 9:28 AM Michael Richardson wrote: > Martin Duke wrote: > > So I guess the value of the MOP 7 behavior is... to recover the bit > of the > > flags? Fine, I suppose, but this would appear to have two costs: > > 1) If A is still out there when E deploys, this bit would have been > useful, > > but isn't. > > The whole point is that A and E can't co-exist, BY CONSTRUCTION. > The same way that IPv6 nodes can't talk to IPv4 directly. > And we're okay with that, because it's the A/B -> C transition that > worries us. > I've already lifted the DISCUSS, but I am confused by this response. Yes, in a perfect world all nodes are upgraded to implement this draft before anyone ships anything with MOP7. Is it not accurate that node C could interop with a MOP7-capable node, because C could be a leaf node? If so, then if A is still lying around then it can't even be a leaf node because there's no way for E to run MOP7 without compression. Maybe it's true that A and B will all be gone, in which case my example is true but irrelevant. --0000000000002b792a05b3dc9bac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

On Wed, Nov 11, 2020 at 9:28 AM Michael R= ichardson <mcr@sandelman.ca> = wrote:
Martin Du= ke <martin.= h.duke@gmail.com> wrote:
=C2=A0 =C2=A0 > So I guess the value of the MOP 7 behavior is... to reco= ver the bit of the
=C2=A0 =C2=A0 > flags? Fine, I suppose, but this would appear to have tw= o costs:
=C2=A0 =C2=A0 > 1) If A is still out there when E deploys, this bit woul= d have been useful,
=C2=A0 =C2=A0 > but isn't.

The whole point is that A and E can't co-exist, BY CONSTRUCTION.
The same way that IPv6 nodes can't talk to IPv4 directly.
And we're okay with that, because it's the A/B -> C transition t= hat worries us.

I've already lifted= the DISCUSS, but I am confused by this response. Yes, in a perfect world a= ll nodes are upgraded to implement this draft before anyone ships anything = with MOP7.=C2=A0 Is it not accurate that node C could interop with a MOP7-c= apable node, because C could be a leaf node? If so, then if A is still lyin= g around then it can't even be a leaf node because there's no way f= or E to run MOP7 without compression.

Maybe it'= ;s true that A and B will all be gone, in which case my example is true but= irrelevant.
--0000000000002b792a05b3dc9bac-- From nobody Wed Nov 11 15:18:44 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C97283A11E5; Wed, 11 Nov 2020 15:18:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U6EF06BuL7ir; Wed, 11 Nov 2020 15:18:40 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F230F3A11E2; Wed, 11 Nov 2020 15:18:39 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id CCA80389BA; Wed, 11 Nov 2020 18:19:09 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ptHpq85UoK7B; Wed, 11 Nov 2020 18:19:08 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A8E24389B5; Wed, 11 Nov 2020 18:19:08 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id BD8D9EF4; Wed, 11 Nov 2020 18:18:37 -0500 (EST) From: Michael Richardson To: Routing Over Low power and Lossy networks cc: "draft-ietf-roll-useofrplinfo\@ietf.org" , "roll-chairs\@ietf.org" In-Reply-To: References: X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Roll] AD Review of draft-ietf-roll-useofrplinfo-41 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, 11 Nov 2020 23:18:43 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Alvaro Retana wrote: > [major] The text in =C2=A74.3 says that the flags for MOP 7 are reser= ved > (I'm suggesting unassigned -- but that makes no difference in the > context of this comment), but this text seems to want to pre-define I believe that we got advice from IANA that RESERVED was the right state. It could be changed by an IESG action, such as publishing an IETF Consensus= RFC. Unassigned, in theory, leaves IANA free to allocate it to the next document that asks for a MOP value. Of course, in practice, it would come back to the WG, Expert Review, etc. but... =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl+scU0ACgkQgItw+93Q 3WU9CwgAhJ3Thcge32b5VzeLnGuBhRBgNtF8B0zko+58iakYHQPHTX8irM2ALz1q rQrDrfDiPrsuzNmNc1QEhVek3XbQMgRW+sSUtuQzLzbb3YMUhhcoOrdZiR+z0UBY ZDNKrEYFEm1sm5f+Is3EHReRI1svNYAECnwzAWk7ICEmpwYm8GhTRsQnBT4/F5wF K9boFPIQseT3nUt3fKnkFR/iwWTB79e33JTdBfteUbtoTHX9SsJjN3grkxxGSzBf NmZpva7olOOlVVumW46c3LHrZTZdFdUz9g+cbHiDDlufNbZjhhU2YSxWjdQM6Lur QROSCxsX+eiogxNQQnSOdmUSNTSxWQ== =F2bO -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Nov 11 15:27:39 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19CE63A11ED; Wed, 11 Nov 2020 15:27:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 36d3cZ86tRao; Wed, 11 Nov 2020 15:27:31 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A1BA3A11EC; Wed, 11 Nov 2020 15:27:30 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 2DF03389BA; Wed, 11 Nov 2020 18:28:00 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 97_wQd1k7j89; Wed, 11 Nov 2020 18:27:59 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 8C6BA389B5; Wed, 11 Nov 2020 18:27:59 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 9D464EF4; Wed, 11 Nov 2020 18:27:28 -0500 (EST) From: Michael Richardson To: Martin Duke cc: "Pascal Thubert \(pthubert\)" , Benjamin Kaduk , Alvaro Retana , The IESG , "draft-ietf-roll-turnon-rfc8138\@ietf.org" , Routing Over Low power and Lossy networks , "roll-chairs\@ietf.org" In-Reply-To: References: <6978.1605115717@localhost> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf-roll-turnon-rfc8138-14: (with DISCUSS and COMMENT) 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, 11 Nov 2020 23:27:33 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Martin Duke wrote: >> Martin Duke wrote: >> > So I guess the value of the MOP 7 behavior is... to recover the bit >> of the >> > flags? Fine, I suppose, but this would appear to have two costs: >> > 1) If A is still out there when E deploys, this bit would have been >> useful, >> > but isn't. >> >> The whole point is that A and E can't co-exist, BY CONSTRUCTION. >> The same way that IPv6 nodes can't talk to IPv4 directly. >> And we're okay with that, because it's the A/B -> C transition that >> worries us. I'm sorry, the table was hard to read/remember, so maybe I should have said "A/B can't co-exist with E" > I've already lifted the DISCUSS, but I am confused by this response. = Yes, > in a perfect world all nodes are upgraded to implement this draft bef= ore > anyone ships anything with MOP7. We are saying that, not just in a perfect world. By construction, we saying that was are intentionally making this decision. We have MOP 5 and MOP 6 still to allocate and possibly a bunch of other stu= ff before we get to that place. Again, IPv6 analogy: state "E" is when we turn off IPv4. Any node not upgraded is landfill. Sorry. > Is it not accurate that node C could > interop with a MOP7-capable node, because C could be a leaf node? I think, yes. > If so, > then if A is still lying around then it can't even be a leaf node bec= ause > there's no way for E to run MOP7 without compression. correct. But... this is on 802.15.4 and other links where we use optionally use 8138= compression. It wouldn't be true at all on 802.11 or ethernet links. (Such as draft-ietf-anima-autonomic-control-plane's RPL instance) Some new IP-over-FOO document where FOO !=3D 802.15.4 [or lookalikes], coul= d say that 8138 was always on, or compression was unnecessary, or ... Of course, device "A" probably won't have this new fangled as-yet-to-be-inv= ented interface, so it can't connect at layer-1 anyway. If A if modular and can grow such an interface, then I guess it better get a software update too. > Maybe it's true that A and B will all be gone, in which case my examp= le is > true but irrelevant. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAl+sc2AACgkQgItw+93Q 3WVzigf+JNebnKJZI1tXuxTJYI2LRlXE4gl9MDHRKLzhLuDZmPyVO9s3IymH/xUy Y3dnGU7saKDzzcCyfFWQ7kkIUBXvOD+9mQGIid/lfIJcPBJM3Qyb+IR0AFFNPCB7 HFLhNfNqLbpePW/S/SJlG8vFeJ6oFA7LO1AwrBrNmSiY3/vVQm7aQ4utKp01WR+4 Ar+luP7VYb9xVIgjtSqbHDlowTMC8BcbmNrVE8kqGMhsw3HDsMsPkJPnNoauE1mQ 9e/uRJDYHkBIdrkeiTtMR08ZdVcCamygZ5JdxRYHBOUYtELGeHjMT34bM7WHmcW3 ogXI+v+OXWG+XCy/VlEpYZVc20qx9Q== =UeWL -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Nov 11 15:29:15 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CBC03A11ED; Wed, 11 Nov 2020 15:29:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, 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 eHP-fQ_n4-HY; Wed, 11 Nov 2020 15:29:09 -0800 (PST) Received: from mail-il1-x134.google.com (mail-il1-x134.google.com [IPv6:2607:f8b0:4864:20::134]) (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 EB8513A11EC; Wed, 11 Nov 2020 15:29:08 -0800 (PST) Received: by mail-il1-x134.google.com with SMTP id g15so3570915ilc.9; Wed, 11 Nov 2020 15:29:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KP+V1djdx21mKzbKdSKEASwXbOO8Wa9DvfamkqgQC3I=; b=aGirh+T0vZOgiF/j8k1LdP6K49SoRvITxr5jbMwG9hPHTXBMttnC+uuTQN2KsBJ9C5 /zRpSDeQ6Itk/UrCMe58xbaJ9MFfvrpYkqkd8hPN5A1uF067DEqQYsrzNP1ij4Z9cuR3 Uq6LtAuHaXolXIIEpbW82vEk0TrzFkDDVxm4f19lZ9ke42ddhk9XtavPLEz4JbcAnNa5 SMOhMf8OBRScwrPHA+BTQobvZQ7Frua0+JLKn5luh/UTjTxbC03MXeQ04T13qAw0it4Y v1bHSwaOyn0oCJCclGcR3kQs+lHzDYpDlwhLROzAucDgp0b9eubPUpuNx6WSXhSGTHn6 4YmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KP+V1djdx21mKzbKdSKEASwXbOO8Wa9DvfamkqgQC3I=; b=SxbPv7De1Mj1d6RiXljT6grGlV0DzimitN8SED2BFAqnAyLD9JqMDIXs6Du9IntDgB bhByOvosU9549g9ey1P5I0BAgUOzvcVPnAQ0ExPT8+x5XTY6hp2SIz8UP/J5HVZs9JJD jzpEGAbMP8+Bi+0+/9eMieFAVrPerPAyVJ7ZUykCxOzLrPYUos0tIr34o2a3IaZmuyqB Jkf1vztvUTYZUHK8oF34FHB7XvS+RPwpygXz/ftK8QcMT1WvQEuMb+LtKrusDI3RR4S7 Q4HX8x5jkkP19pF3H7twWITKEDoNAaL73WafUVySq3TMyCEZAeVRnhc1y23VGOj7fUJH LrEQ== X-Gm-Message-State: AOAM532DJy9l4EYMZZ9KXQjMyG/PAtsirwIKWkROXMp2Gq4roXXO28Uc 7phVb93ftDSzLY0Vnki5dnJsey6ektiaZyuow8E= X-Google-Smtp-Source: ABdhPJxfxWPDFdvX7a9mkdfwl7irVBMGHNDiVaHi84OS4OIc7srwrHOmH6MDQGbmVMxSB4ADtosX+p5vNHlEsUImX3w= X-Received: by 2002:a05:6e02:1305:: with SMTP id g5mr21412434ilr.237.1605137348229; Wed, 11 Nov 2020 15:29:08 -0800 (PST) MIME-Version: 1.0 References: <6978.1605115717@localhost> <4890.1605137248@localhost> In-Reply-To: <4890.1605137248@localhost> From: Martin Duke Date: Wed, 11 Nov 2020 15:28:57 -0800 Message-ID: To: Michael Richardson Cc: "Pascal Thubert (pthubert)" , Benjamin Kaduk , Alvaro Retana , The IESG , "draft-ietf-roll-turnon-rfc8138@ietf.org" , Routing Over Low power and Lossy networks , "roll-chairs@ietf.org" Content-Type: multipart/alternative; boundary="0000000000007506a205b3dd29a0" Archived-At: Subject: Re: [Roll] Benjamin Kaduk's Discuss on draft-ietf-roll-turnon-rfc8138-14: (with DISCUSS and COMMENT) 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, 11 Nov 2020 23:29:11 -0000 --0000000000007506a205b3dd29a0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Very well. On Wed, Nov 11, 2020 at 3:27 PM Michael Richardson wrote: > > Martin Duke wrote: > >> Martin Duke wrote: > >> > So I guess the value of the MOP 7 behavior is... to recover the > bit > >> of the > >> > flags? Fine, I suppose, but this would appear to have two costs: > >> > 1) If A is still out there when E deploys, this bit would have > been > >> useful, > >> > but isn't. > >> > >> The whole point is that A and E can't co-exist, BY CONSTRUCTION. > >> The same way that IPv6 nodes can't talk to IPv4 directly. > >> And we're okay with that, because it's the A/B -> C transition tha= t > >> worries us. > > I'm sorry, the table was hard to read/remember, so maybe I should have sa= id > "A/B can't co-exist with E" > > > I've already lifted the DISCUSS, but I am confused by this response= . > Yes, > > in a perfect world all nodes are upgraded to implement this draft > before > > anyone ships anything with MOP7. > > We are saying that, not just in a perfect world. > By construction, we saying that was are intentionally making this decisio= n. > We have MOP 5 and MOP 6 still to allocate and possibly a bunch of other > stuff > before we get to that place. > > Again, IPv6 analogy: state "E" is when we turn off IPv4. > Any node not upgraded is landfill. Sorry. > > > Is it not accurate that node C could > > interop with a MOP7-capable node, because C could be a leaf node? > > I think, yes. > > > If so, > > then if A is still lying around then it can't even be a leaf node > because > > there's no way for E to run MOP7 without compression. > > correct. > But... this is on 802.15.4 and other links where we use optionally use > 8138 compression. > It wouldn't be true at all on 802.11 or ethernet links. > (Such as draft-ietf-anima-autonomic-control-plane's RPL instance) > Some new IP-over-FOO document where FOO !=3D 802.15.4 [or lookalikes], co= uld > say > that 8138 was always on, or compression was unnecessary, or ... > Of course, device "A" probably won't have this new fangled > as-yet-to-be-invented > interface, so it can't connect at layer-1 anyway. If A if modular and ca= n > grow such an interface, then I guess it better get a software update too. > > > Maybe it's true that A and B will all be gone, in which case my > example is > > true but irrelevant. > > > -- > Michael Richardson . o O ( IPv6 I=C3=B8T consul= ting ) > Sandelman Software Works Inc, Ottawa and Worldwide > --0000000000007506a205b3dd29a0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Very well.

On Wed, Nov 11, 2020 at 3:27 PM Michael Richards= on <mcr+ietf@sandelman.ca= > wrote:

Martin Duke <martin.h.duke@gmail.com> wrote:
=C2=A0 =C2=A0 >> Martin Duke <martin.h.duke@gmail.com> wrote:
=C2=A0 =C2=A0 >> > So I guess the value of the MOP 7 behavior is..= . to recover the bit
=C2=A0 =C2=A0 >> of the
=C2=A0 =C2=A0 >> > flags? Fine, I suppose, but this would appear t= o have two costs:
=C2=A0 =C2=A0 >> > 1) If A is still out there when E deploys, this= bit would have been
=C2=A0 =C2=A0 >> useful,
=C2=A0 =C2=A0 >> > but isn't.
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> The whole point is that A and E can't co-exist, = BY CONSTRUCTION.
=C2=A0 =C2=A0 >> The same way that IPv6 nodes can't talk to IPv4 = directly.
=C2=A0 =C2=A0 >> And we're okay with that, because it's the A= /B -> C transition that
=C2=A0 =C2=A0 >> worries us.

I'm sorry, the table was hard to read/remember, so maybe I should have = said
"A/B can't co-exist with E"

=C2=A0 =C2=A0 > I've already lifted the DISCUSS, but I am confused b= y this response. Yes,
=C2=A0 =C2=A0 > in a perfect world all nodes are upgraded to implement t= his draft before
=C2=A0 =C2=A0 > anyone ships anything with MOP7.

We are saying that, not just in a perfect world.
By construction, we saying that was are intentionally making this decision.=
We have MOP 5 and MOP 6 still to allocate and possibly a bunch of other stu= ff
before we get to that place.

Again, IPv6 analogy: state "E" is when we turn off IPv4.
Any node not upgraded is landfill.=C2=A0 Sorry.

=C2=A0 =C2=A0 > Is it not accurate that node C could
=C2=A0 =C2=A0 > interop with a MOP7-capable node, because C could be a l= eaf node?

I think, yes.

=C2=A0 =C2=A0 > If so,
=C2=A0 =C2=A0 > then if A is still lying around then it can't even b= e a leaf node because
=C2=A0 =C2=A0 > there's no way for E to run MOP7 without compression= .

correct.
But... this is on 802.15.4 and other links where we use optionally use 8138= compression.
It wouldn't be true at all on 802.11 or ethernet links.
(Such as draft-ietf-anima-autonomic-control-plane's RPL instance)
Some new IP-over-FOO document where FOO !=3D 802.15.4 [or lookalikes], coul= d say
that 8138 was always on, or compression was unnecessary, or ...
Of course, device "A" probably won't have this new fangled as= -yet-to-be-invented
interface, so it can't connect at layer-1 anyway.=C2=A0 If A if modular= and can
grow such an interface, then I guess it better get a software update too.
=C2=A0 =C2=A0 > Maybe it's true that A and B will all be gone, in wh= ich case my example is
=C2=A0 =C2=A0 > true but irrelevant.


--
Michael Richardson <mcr+IETF@sandelman.ca>=C2=A0 =C2=A0. o O ( IPv6 I=C3=B8T co= nsulting )
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sandelman Software Works Inc, Otta= wa and Worldwide
--0000000000007506a205b3dd29a0-- From nobody Wed Nov 11 17:34:37 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6C0F3A12C6; Wed, 11 Nov 2020 17:34:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.096 X-Spam-Level: X-Spam-Status: No, score=-1.096 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, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 hHi5wxT1HeK7; Wed, 11 Nov 2020 17:34:34 -0800 (PST) Received: from mail-ej1-x634.google.com (mail-ej1-x634.google.com [IPv6:2a00:1450:4864:20::634]) (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 0AD0B3A12C0; Wed, 11 Nov 2020 17:34:34 -0800 (PST) Received: by mail-ej1-x634.google.com with SMTP id f23so5446445ejk.2; Wed, 11 Nov 2020 17:34:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=VRVbBRGBC5tTgzP7p4ctWmhOd5mKPUPxTCvHoYYyWks=; b=PfulVN9FY7PYnJiEv40gAlsb+LI2SV1yLi4kgGXLGJyJ3HMlLU8TMcjDqafr/gd1KY yTzmcAfLlkCx/RshDRhwEEka9DRSmoXXUThYqSmvuSpftUzsoe36G5djHdlSZJ3Ks7Wj 4M93LJjfyNqTvcbpgcrafgaqsjIIbLXGsWxSEzG6k8/aqcYhCrkJpIoaDCrLq7q16fVj 5dD+anjlFM4NU10k+d+wmYj4zoU19ARxRHg567Ii0MYHqGtUpNalFysSkoybl6Vua+NR DqcPMl5jKLtAnhwRE2lrU79uLuyflZtmCej3eBhHaEY0rihDTRxv3rv234Rx0xhQImLU T1+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=VRVbBRGBC5tTgzP7p4ctWmhOd5mKPUPxTCvHoYYyWks=; b=XIsRZS7/yZ3xbfBksWi9ujL4H2mBkE+rrHVQ51TaXjpDwaVsZhuio7tu2qTmqLQEbC UHLeQ7WTuDjXcVvlB+NsNd/aukdjc/2K67waB9GRvLwiULmNEw633/ZD5lee9BqybFgX t5ZVLb28rP8AmP0gQmww3IklPpfIBUSO3xzytptuI9tpSYtn7yuwejtjfeeSQTFIdUtm 2bn2gIHING1oDWMp+DVtD5Fxi0n4p/qRQYxyIxf/WREYggR8LEYsae3Kl2Iyh6672eLS ExDw68F2Z1J+C4yaySYeThVv/VPoPX7HWW/dfqZZf7PcJiCWiBQC91dTTs7TtlDJ3iFC OYxg== X-Gm-Message-State: AOAM533Zmo0QUYl04LEDW/hpGVSwYixX+Kyzu1b3Emd97Ysf0li/4cKj DIHziONijoGB3/dfinbT2QzeNGzolA2mHAEQKIs= X-Google-Smtp-Source: ABdhPJw7C6tbJ8lQB1MF1QlpClEWEHKMCa7W30CWAdidZpupvxpAqukjIElVZKK8Um+zn6EGsgtgnOTom5irg5mZkSA= X-Received: by 2002:a17:906:3a49:: with SMTP id a9mr28130758ejf.300.1605144872435; Wed, 11 Nov 2020 17:34:32 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 11 Nov 2020 17:34:31 -0800 From: Alvaro Retana In-Reply-To: References: MIME-Version: 1.0 Date: Wed, 11 Nov 2020 17:34:31 -0800 Message-ID: To: Ines Robles Cc: Routing Over Low power and Lossy networks , Peter van der Stok , "roll-chairs@ietf.org" , "draft-ietf-roll-useofrplinfo@ietf.org" Content-Type: multipart/alternative; boundary="000000000000ef46a505b3dee957" Archived-At: Subject: Re: [Roll] AD Review of draft-ietf-roll-useofrplinfo-41 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, 12 Nov 2020 01:34:36 -0000 --000000000000ef46a505b3dee957 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Ines: Hi! Let=E2=80=99s request the manual post so I can start the IETF LC. Thanks! Alvaro. On November 11, 2020 at 5:10:33 PM, Ines Robles ( mariainesrobles@googlemail.com) wrote: Should be do a manual post request or wait until 14th Nov? --000000000000ef46a505b3dee957 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Ines:

Hi!

L= et=E2=80=99s request the manual post so I can start the IETF LC.

Thanks!

Alvaro.

On November 11, 2020 at 5:10:33 PM, Ines Robles (mariainesrobles@googlemail.com) wrote:

=
Should be do a manu= al post request or wait until 14th Nov?
--000000000000ef46a505b3dee957-- From nobody Wed Nov 11 17:35:19 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB03E3A12C2; Wed, 11 Nov 2020 17:35:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, 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 qUxLA0EKUBRE; Wed, 11 Nov 2020 17:35:15 -0800 (PST) Received: from mail-ej1-x630.google.com (mail-ej1-x630.google.com [IPv6:2a00:1450:4864:20::630]) (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 3FB3C3A12C0; Wed, 11 Nov 2020 17:35:15 -0800 (PST) Received: by mail-ej1-x630.google.com with SMTP id oq3so5393649ejb.7; Wed, 11 Nov 2020 17:35:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to :cc; bh=OJrJ+V2r+EArwvFW3iMRTLQqz8+PElJkTLq1Yu42i8k=; b=ixk95cioy95Ru3mRfHg0SrkZ9bDf5ZJgJR02yxkmyyfmF7OAhfi5mcOYWVYl0dhlxE 1hmgf4HJjN/H2jsoo1DhL4Ov/LPBrGzNmMWKz8u/pCq/+MnQKGK8NDAD6baT+hF+KBbI MgU0+SIEY8DG5Y2uO/27BV8Ad9rDGmDvQAYvdwqHD/rHln+1rJZ9y4Hl47IBQDiZdlyr 8V3SJ5fg8HvlPeInhvhu48CeS8FlSWoqy+EU1fkJsil5Dv1LMsygA156mO7xweqpkrXz hehDxhPOuQgEuN7vRpjoygDckRkeu2HZAt4ZMJosomCoS4kxb6aYTsGStkbUMMmc/UXT pPRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to:cc; bh=OJrJ+V2r+EArwvFW3iMRTLQqz8+PElJkTLq1Yu42i8k=; b=SLzfW1MFwKNDaBMOgqBAN9WI6STXwNZP9oUrQePsCncF8svGy8O4AzYwJ19qRf1bly iWg/0QR/wRvqeSt1bi3iFCWhjQO3+gKPRq5ivNqkFyb2NKzVS+U1eyQEV0anon0sgb4t qy0mP++jg8D7/sSFmvIuD4nCCZDNqEOb8NB+aEarozWawood4uw+roNErMsFOH4Ry4ye suxl1d2CWmGK0UddTACGqqUir0EkM6XzPVUrYCva1op+vsC78Y+IC6Jzzfd/De4EniqC OOFS/HXt3gx71kZ9OpYTD7YBXnoVf7TGycgu2jJEUFcVBjh/BJG2tkHCu6a3tZCeHTvE bs3A== X-Gm-Message-State: AOAM533W+aHLVHtE3FreeIKxUS0HN5o/0ydHp4HfYw+ZQfmQId+uZRuE cCsV5AywyfhtMWDfLBAr2HsBtQaeHLzc1LgZ3qiIEUsuEa8= X-Google-Smtp-Source: ABdhPJwgDQ3hnwFRnF/C/Z7ggA2LNQHjKsslEeoLR5p6f1R3ap6YjDLEt0XFwHX37U8nO31SP6QXrzBZkvq28TQNyQs= X-Received: by 2002:a17:907:2805:: with SMTP id eb5mr27753114ejc.27.1605144913664; Wed, 11 Nov 2020 17:35:13 -0800 (PST) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 11 Nov 2020 17:35:12 -0800 From: Alvaro Retana In-Reply-To: <2502.1605136717@localhost> References: <2502.1605136717@localhost> <2502.1605136717@localhost> MIME-Version: 1.0 Date: Wed, 11 Nov 2020 17:35:12 -0800 Message-ID: To: Routing Over Low power and Lossy networks , Michael Richardson Cc: "roll-chairs@ietf.org" , "draft-ietf-roll-useofrplinfo@ietf.org" Content-Type: multipart/alternative; boundary="00000000000064636705b3deece2" Archived-At: Subject: Re: [Roll] AD Review of draft-ietf-roll-useofrplinfo-41 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, 12 Nov 2020 01:35:17 -0000 --00000000000064636705b3deece2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Either way works... On November 11, 2020 at 6:19:11 PM, Michael Richardson ( mcr+ietf@sandelman.ca) wrote: Alvaro Retana wrote: > [major] The text in =C2=A74.3 says that the flags for MOP 7 are reserved > (I'm suggesting unassigned -- but that makes no difference in the > context of this comment), but this text seems to want to pre-define I believe that we got advice from IANA that RESERVED was the right state. It could be changed by an IESG action, such as publishing an IETF Consensus RFC. Unassigned, in theory, leaves IANA free to allocate it to the next document that asks for a MOP value. Of course, in practice, it would come back to the WG, Expert Review, etc. but... --=20 Michael Richardson . o O ( IPv6 I=C3=B8T consulting= ) Sandelman Software Works Inc, Ottawa and Worldwide _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll --00000000000064636705b3deece2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Either way works...

On November 11, 2020 at 6:19:11 PM, Michael Richardson (mcr+ietf@sandelman.ca) wrote:


Alvaro Retana <aretana.iet= f@gmail.com> wrote:
> [major] The text in =C2=A74.3 says that the flags for MOP 7 ar= e reserved
> (I'm suggesting unassigned -- but that makes no difference= in the
> context of this comment), but this text seems to want to pre-d= efine

I believe that we got advice from IANA that RESERVED was the right stat= e.
It could be changed by an IESG action, such as publishing an IETF Conse= nsus RFC.

Unassigned, in theory, leaves IANA free to allocate it to the next docu= ment
that asks for a MOP value. Of course, in practice, it would come back t= o the
WG, Expert Review, etc. but...

--
Michael Richardson <mcr+I= ETF@sandelman.ca> . o O ( IPv6 I=C3=B8T consulting )
Sandelman Software Works Inc, Ottawa and Worldwide




_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf= .org/mailman/listinfo/roll
<= /body> --00000000000064636705b3deece2-- From nobody Thu Nov 12 10:25:49 2020 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 21DA83A1481; Thu, 12 Nov 2020 10:25:47 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: roll@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.22.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: roll@ietf.org Message-ID: <160520554705.21185.11097800792268556150@ietfa.amsl.com> Date: Thu, 12 Nov 2020 10:25:47 -0800 Archived-At: Subject: [Roll] I-D Action: draft-ietf-roll-useofrplinfo-42.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: Thu, 12 Nov 2020 18:25:47 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Routing Over Low power and Lossy networks WG of the IETF. Title : Using RPI Option Type, Routing Header for Source Routes and IPv6-in-IPv6 encapsulation in the RPL Data Plane Authors : Maria Ines Robles Michael C. Richardson Pascal Thubert Filename : draft-ietf-roll-useofrplinfo-42.txt Pages : 63 Date : 2020-11-12 Abstract: This document looks at different data flows through LLN (Low-Power and Lossy Networks) where RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) is used to establish routing. The document enumerates the cases where RFC6553 (RPI Option Type), RFC6554 (Routing Header for Source Routes) and IPv6-in-IPv6 encapsulation is required in data plane. This analysis provides the basis on which to design efficient compression of these headers. This document updates RFC6553 adding a change to the RPI Option Type. Additionally, this document updates RFC6550 defining a flag in the DIO Configuration option to indicate about this change and updates RFC8138 as well to consider the new Option Type when the RPL Option is decompressed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-roll-useofrplinfo-42 https://datatracker.ietf.org/doc/html/draft-ietf-roll-useofrplinfo-42 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-useofrplinfo-42 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Nov 13 00:26:00 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26BAC3A1636 for ; Fri, 13 Nov 2020 00:25:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, 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 kydGIpqOspN3 for ; Fri, 13 Nov 2020 00:25:56 -0800 (PST) Received: from mail-vs1-xe29.google.com (mail-vs1-xe29.google.com [IPv6:2607:f8b0:4864:20::e29]) (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 52B313A1635 for ; Fri, 13 Nov 2020 00:25:56 -0800 (PST) Received: by mail-vs1-xe29.google.com with SMTP id m16so4793197vsl.8 for ; Fri, 13 Nov 2020 00:25:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Xa3/JzyPSObx2ntZ8/lYVPPtoovB+9vqxUn2sfV64NY=; b=P4YM1/o2KOSF/thu6qgiJX+xqk1vnxrcAovVihiUzo3CdVPQwnFVNHhdqNohMHinNB ImB2OcUswen//2SJRSwVD+8hX6dsW3j1qVzRdK9umFp+5tZ/oiK/Ux/cMRf3lKOqsxsM GIdHsx3wBJSao5HTunX20cQk9eloMsRivPzxBA55ZEMr1rrobxLhIfzMdkWevjfWi0rP NHj5KxnpU9BQeWhy9FF4xoevUvhG3L421krvnqeFAx8HB9hFGe3eb5BBh7p6Xc6rhENV eeJG4ye0wHGXVBUyi2+iq/NozkQGQVfln4ag6bd6TVVC/IfLvWf3WC00G3p3qBxkgRh8 k1Xw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Xa3/JzyPSObx2ntZ8/lYVPPtoovB+9vqxUn2sfV64NY=; b=VjQkFO+juRFJj7ntuXSqTAjDUP4CFh97eL2yLtbcePQVizIwWQihpp72FF9UOY7BXQ tcX/H3yF6ODP54vTlptJHmbZiM+jg8jAvm4uRv8ZYDReGkbiHKtQQguDc7F+AfBHXLW9 x70MWXE/ORfm7sW7aAz8Wq+p13sK4qPc3wmd9M/08ZrAuCj5A7Y057lD9d6k5QPUcfLC cDsMY2MgHR6Zcf3fBmavN50Rv+TO6PMptmKjIn56Yi/X+G/ydEhi0t/OccUgvvRoLqxG tVGiRi3j34PfoDYSLX2LW0MV7aCT5R7SPLrATWJbmapw57LgjEmWErtxOV4ISBooo7i7 jN4Q== X-Gm-Message-State: AOAM530GUzhQh1X6Vuy3EBnMmGyQSRPwzbj4pNDkkjgWrDUHdeQQrgjO w0HUnk99cOrBBhtQV7Bj7EatJ9AWblyZczDg4mRGixaoMcE= X-Google-Smtp-Source: ABdhPJwpHBL4gkeb1QZBe6q2dnig+QUD64y5eBVbGpk9+Dn6zKAol0QPL1Z5SOrY4LNDyfDbAGGY2LFULaInzWVJr2M= X-Received: by 2002:a67:ec9a:: with SMTP id h26mr534771vsp.34.1605255955013; Fri, 13 Nov 2020 00:25:55 -0800 (PST) MIME-Version: 1.0 References: <23007.1604344604@localhost> In-Reply-To: From: Ines Robles Date: Fri, 13 Nov 2020 10:25:19 +0200 Message-ID: To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="000000000000f8e5ac05b3f8c65d" Archived-At: Subject: Re: [Roll] IETF 109 - Agenda Requests 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, 13 Nov 2020 08:25:58 -0000 --000000000000f8e5ac05b3f8c65d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear all, Please find an updated agenda for IETF 109: https://datatracker.ietf.org/meeting/109/materials/agenda-109-roll-03 Comments welcome, Thanks, Ines and Dominique On Mon, Nov 2, 2020 at 9:39 PM Ines Robles wrote: > Hi, > > Great!, we have 30 min slot-free, thus RFC6550bis would have 40 min if > there are no further meeting requests. > > Thank you, > > Ines. > > On Mon, Nov 2, 2020 at 9:16 PM Michael Richardson > wrote: > >> >> Ines Robles wrote: >> > - RPLv2 status (10 min) >> >> Who is doing this? [was it me?] >> I don't think that 10 minutes is enough. >> >> Rather than talk about RPLv2, let's talk about planning for RFC6550bis. >> I think that needs a bunch of planning. >> >> -- >> Michael Richardson . o O ( IPv6 I=C3=B8T consu= lting >> ) >> Sandelman Software Works Inc, Ottawa and Worldwide >> >> >> >> >> _______________________________________________ >> Roll mailing list >> Roll@ietf.org >> https://www.ietf.org/mailman/listinfo/roll >> > --000000000000f8e5ac05b3f8c65d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

Please find an updated agenda= for IETF 109:=C2=A0=C2=A0https://datatracker.ietf.org/meeting/109/m= aterials/agenda-109-roll-03

Comments welcome,<= /div>

Thanks,

Ines and Dominiqu= e

On Mon, Nov 2, 2020 at 9:39 PM Ines Robles <mariainesrobles@googlemail.com> wrote:=
Hi,=C2=A0

Great!, we have 30 min slot-free, thus=C2=A0 RFC6550bis=C2=A0 would have 40 min if there are no further meeting requests= .=C2=A0

Thank you,=C2=A0

= Ines.

On Mon, Nov 2, 2020 at 9:16 PM Michael Richardson <mcr+ietf@sandelman.ca> wrote:
Ines Robles <mariainesrobles=3D40googlemail.com@dmarc.ietf.org> wrote:<= br> =C2=A0 =C2=A0 > - RPLv2 status (10 min)

Who is doing this? [was it me?]
I don't think that 10 minutes is enough.

Rather than talk about RPLv2, let's talk about planning for RFC6550bis.=
I think that needs a bunch of planning.

--
Michael Richardson <mcr+IETF@sandelman.ca>=C2=A0 =C2=A0. o O ( IPv6 I=C3=B8T co= nsulting )
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sandelman Software Works Inc, Otta= wa and Worldwide




_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--000000000000f8e5ac05b3f8c65d-- From nobody Fri Nov 13 07:17:50 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A8E53A0D95 for ; Fri, 13 Nov 2020 07:17:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, 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 kRxMoKxzC0oE for ; Fri, 13 Nov 2020 07:17:45 -0800 (PST) Received: from mail-vs1-xe35.google.com (mail-vs1-xe35.google.com [IPv6:2607:f8b0:4864:20::e35]) (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 BB7803A0D98 for ; Fri, 13 Nov 2020 07:17:45 -0800 (PST) Received: by mail-vs1-xe35.google.com with SMTP id x11so5346057vsx.12 for ; Fri, 13 Nov 2020 07:17:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=FeuiLdWG2oJHbUqDlzo4S9IDgapZ4iGV75MIUizG0f4=; b=BnevehaVtIQU8aNImrvFMj3jOBInjWKud3Mflsopk5aGpMSsI8xmxGJ9zu+wJM1IiU wWQI9+H7s3YRn2N9Ev3QVpwogddFh0VGLTzfX8c7EDQwUF7w+pt1mIo1ADlvw3FPCzK6 KH3Z9NnzpFITGIEwY5zSY/yDLGN2eiF6Rb04YsoezuMREGNGtSzoqINHLcrrdlxrwJfO 5Ti8TY63bcc7RDEQ+4nVqEBzm9nqZpCsWVl4vctB3DNu+cUxzMeFZgLifHsSTwHUo7jw sWESEKJ+OjFXB/FXlmluI7dNPNHY6fjDHJARhgKYbTNniZZHYDNSFMJWq96uy6bRX5Lv 5SPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=FeuiLdWG2oJHbUqDlzo4S9IDgapZ4iGV75MIUizG0f4=; b=mK64+eEaHsmzgDvBY1ncmj8C+7KWuT+AYn5Ncu3jnyyLiWANdf/8g7fc2J/wOwGm1W +eMpTOLWssigfLHFJ0dDUo8pC6n9PHPQ1htYMkrxsrvOHA6HPaGVr1bxkRQO1PWooMVw avyaxuoRiZb7BkTzXZlIjI7NsUc97CZxMo6WjxKK8UbhaX0cq/ehU4C9sAo+VHbrRT9D prDQ105qv9iSaR/Uv4uwB91i7/Zy1qKb512Pos+mxeLhh2raWmRjK0y7U5tSaL9hFDkf ZQhaWopxmitE0YGNp1pXCbrYLuYMSybe2YwJ6aWFgOWeYmG5sjOcPjHh9Up0/QwP/Ak+ qlmQ== X-Gm-Message-State: AOAM530evDqEM21oXRgZ8Du/kylWYmtppYTyYY/J5mmPJhytNEQCfYwa V/JLvN4KrZqtkRIVkp9730c7D5UzHEeCj7+RQKoLIszKEL0= X-Google-Smtp-Source: ABdhPJwPxuw3Bqh5GmDAappSRsW4WDHl4zR5Igswhc9en3Kyvy2feK+im7JcJM0BbAHDn2opeQXNdbq0ulBt/lJWEeY= X-Received: by 2002:a67:fa10:: with SMTP id i16mr1725648vsq.3.1605280662946; Fri, 13 Nov 2020 07:17:42 -0800 (PST) MIME-Version: 1.0 References: <23007.1604344604@localhost> In-Reply-To: From: Ines Robles Date: Fri, 13 Nov 2020 17:17:06 +0200 Message-ID: To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="000000000000ae068005b3fe87ba" Archived-At: Subject: Re: [Roll] IETF 109 - Agenda Requests 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, 13 Nov 2020 15:17:49 -0000 --000000000000ae068005b3fe87ba Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Presenters, Please upload your slides for the IETF 109 in pdf format by Wednesday 18th November at 11:00am UTC. Link to upload the slide set: https://datatracker.ietf.org/meeting/109/session/roll Thank you, Ines and Dominique On Fri, Nov 13, 2020 at 10:25 AM Ines Robles wrote: > Dear all, > > Please find an updated agenda for IETF 109: > https://datatracker.ietf.org/meeting/109/materials/agenda-109-roll-03 > > Comments welcome, > > Thanks, > > Ines and Dominique > > On Mon, Nov 2, 2020 at 9:39 PM Ines Robles > wrote: > >> Hi, >> >> Great!, we have 30 min slot-free, thus RFC6550bis would have 40 min if >> there are no further meeting requests. >> >> Thank you, >> >> Ines. >> >> On Mon, Nov 2, 2020 at 9:16 PM Michael Richardson >> wrote: >> >>> >>> Ines Robles wrote: >>> > - RPLv2 status (10 min) >>> >>> Who is doing this? [was it me?] >>> I don't think that 10 minutes is enough. >>> >>> Rather than talk about RPLv2, let's talk about planning for RFC6550bis. >>> I think that needs a bunch of planning. >>> >>> -- >>> Michael Richardson . o O ( IPv6 I=C3=B8T >>> consulting ) >>> Sandelman Software Works Inc, Ottawa and Worldwide >>> >>> >>> >>> >>> _______________________________________________ >>> Roll mailing list >>> Roll@ietf.org >>> https://www.ietf.org/mailman/listinfo/roll >>> >> --000000000000ae068005b3fe87ba Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Presenters,

Please upload your sli= des for the IETF 109 in pdf=C2=A0format by Wednesday 18th November at 11:0= 0am UTC.


Thank you,

Ines and Domi= nique

On Fri, Nov 13, 2020 at 10:25 AM Ines Robles <mariainesrobles@googlemail.com> = wrote:
Dear all,

Please find an updated agenda for IET= F 109:=C2=A0=C2=A0https://datatracker.ietf.org/mee= ting/109/materials/agenda-109-roll-03

Comments= welcome,

Thanks,

Ines an= d Dominique

On Mon, Nov 2, 2020 at 9:39 PM Ines Robles <mariainesrobles@g= ooglemail.com> wrote:
Hi,=C2=A0

Great!, we have = 30 min slot-free, thus=C2=A0 RFC6550bis=C2=A0 would have 40 min if there are no further meeting requests= .=C2=A0

Thank you,=C2=A0

= Ines.

On Mon, Nov 2, 2020 at 9:16 PM Michael Richardson <mcr+ietf@sandelman.ca> wrote:
Ines Robles <mariainesrobles=3D40googlemail.com@dmarc.ietf.org> wrote:<= br> =C2=A0 =C2=A0 > - RPLv2 status (10 min)

Who is doing this? [was it me?]
I don't think that 10 minutes is enough.

Rather than talk about RPLv2, let's talk about planning for RFC6550bis.=
I think that needs a bunch of planning.

--
Michael Richardson <mcr+IETF@sandelman.ca>=C2=A0 =C2=A0. o O ( IPv6 I=C3=B8T co= nsulting )
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sandelman Software Works Inc, Otta= wa and Worldwide




_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--000000000000ae068005b3fe87ba-- From nobody Fri Nov 13 16:02:32 2020 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D007A3A100D; Fri, 13 Nov 2020 16:02:30 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.22.0 Auto-Submitted: auto-generated Precedence: bulk CC: draft-ietf-roll-useofrplinfo@ietf.org, roll-chairs@ietf.org, roll@ietf.org, consultancy@vanderstok.org, aretana.ietf@gmail.com, Peter Van der Stok Reply-To: last-call@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <160531215077.6454.1313886041200146512@ietfa.amsl.com> Date: Fri, 13 Nov 2020 16:02:30 -0800 Archived-At: Subject: [Roll] Last Call: (Using RPI Option Type, Routing Header for Source Routes and IPv6-in-IPv6 encapsulation in the RPL Data Plane) to Proposed Standard 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: Sat, 14 Nov 2020 00:02:31 -0000 The IESG has received a request from the Routing Over Low power and Lossy networks WG (roll) to consider the following document: - 'Using RPI Option Type, Routing Header for Source Routes and IPv6-in- IPv6 encapsulation in the RPL Data Plane' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2020-12-09. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This document looks at different data flows through LLN (Low-Power and Lossy Networks) where RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) is used to establish routing. The document enumerates the cases where RFC6553 (RPI Option Type), RFC6554 (Routing Header for Source Routes) and IPv6-in-IPv6 encapsulation is required in data plane. This analysis provides the basis on which to design efficient compression of these headers. This document updates RFC6553 adding a change to the RPI Option Type. Additionally, this document updates RFC6550 defining a flag in the DIO Configuration option to indicate about this change and updates RFC8138 as well to consider the new Option Type when the RPL Option is decompressed. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-roll-useofrplinfo/ No IPR declarations have been submitted directly on this I-D. From nobody Fri Nov 13 16:03:35 2020 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 184F03A0FB9; Fri, 13 Nov 2020 16:03:27 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 7.22.0 Auto-Submitted: auto-generated Precedence: bulk CC: JADHAV Rahul , rahul.ietf@gmail.com, roll@ietf.org, roll-chairs@ietf.org, draft-ietf-roll-unaware-leaves@ietf.org, aretana.ietf@gmail.com Reply-To: last-call@ietf.org Sender: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <160531220707.30519.5664991236018422977@ietfa.amsl.com> Date: Fri, 13 Nov 2020 16:03:27 -0800 Archived-At: Subject: [Roll] Last Call: (Routing for RPL Leaves) to Proposed Standard 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: Sat, 14 Nov 2020 00:03:34 -0000 The IESG has received a request from the Routing Over Low power and Lossy networks WG (roll) to consider the following document: - 'Routing for RPL Leaves' as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the last-call@ietf.org mailing lists by 2020-12-09. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This specification updates RFC6550, RFC6775, and RFC8505, to provide routing services to RPL Unaware Leaves that implement 6LoWPAN ND and the extensions therein. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-roll-unaware-leaves/ No IPR declarations have been submitted directly on this I-D. From nobody Sun Nov 15 06:54:40 2020 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C563E3A1317 for ; Sun, 15 Nov 2020 06:54:38 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: X-Test-IDTracker: no X-IETF-IDTracker: 7.22.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <160545207879.26703.362118040334570156@ietfa.amsl.com> Date: Sun, 15 Nov 2020 06:54:38 -0800 From: IETF Secretariat Archived-At: Subject: [Roll] Milestones changed for roll WG X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Nov 2020 14:54:39 -0000 Changed milestone "Initial Submission of a proposal with uses cases for RPI, RH3 and IPv6-in-IPv6 encapsulation to the IESG", resolved as "Done". URL: https://datatracker.ietf.org/wg/roll/about/ From nobody Wed Nov 18 12:27:12 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 846A63A0BFD for ; Wed, 18 Nov 2020 12:27:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, 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 39znNvwCy8mo for ; Wed, 18 Nov 2020 12:27:09 -0800 (PST) Received: from mail-ua1-x92a.google.com (mail-ua1-x92a.google.com [IPv6:2607:f8b0:4864:20::92a]) (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 C373B3A0BF1 for ; Wed, 18 Nov 2020 12:27:09 -0800 (PST) Received: by mail-ua1-x92a.google.com with SMTP id v16so1125726uat.9 for ; Wed, 18 Nov 2020 12:27:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=03VKbxRbd5dxjpKvoh0B5u9rIbqPL0E8t9fMmz/I/U8=; b=U+DUgcvcsqfyGqgAI9qZGpkgdPOJ9ib61q1ihNBcl1M/c+ku2UX7bqGElF+GwAF7qL dMLVGHLkKnrFv7VZ7N+53HoNgecKhEowCrLyfakPHkoyppbTjHsBqNS8GRWl93tywfak d0gPihiIm8hjOuh1KEIvNL2qwy8goVyenRmvoOD83NKpBmNB8l3UoTYNc4uIOdbsAp/h RkWdLFtxT3r5xOiZkx5BnZ2grQbOwVEbI9kL4dOWgqxyJ8SsTr1lTMZiiN73wR/KKbTg uBh+LgNVKVNZeqjVWwJIxuQjXgJhx4GdUygSn/AZR2KaM0+6DUVKFiMrHc7Hmbx0W2ms 3NrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=03VKbxRbd5dxjpKvoh0B5u9rIbqPL0E8t9fMmz/I/U8=; b=eyJ1BFj91Ax8vq7+4PNGsqITE5Mi5c0eO9NZ0x+RDsMeYmMpJhkOV30qm4FrwbojSY iaM09AQPqDwks83wl7dBJJHqTV1kN0sk9K+J2hKLcSyQY4lqQBU7KUI5sUwlBl8NuwuA gx3KuoktSF3ieey1jGgDuEgzYS+L+2mRLuTNOsRECw/M5m7Qrni7phk0WKuDHvlvti1H Q61wB57PDucNyM5yTlO9Vc6qf7NjONV9DGJ7X5ste0evId19lGHu3caj3c6teRs1JEP3 z8pi2zRFAHor72kT5skVlfFuQZqPrIyvdv1ccsKA/+ngY7QPBZXOZHZDkbrmyGxqrMiK Fcyg== X-Gm-Message-State: AOAM532wHgQTqjh//RzhfR/EqJ3tFCt1do/MmbDB5jkgH2z0/dkCOD8d IlUGF98+XeC58Bk8WvjwEu7z4CgJa/8/3XSoraKl7doEXuE= X-Google-Smtp-Source: ABdhPJxR4V/JGhTkwzK4St0uz/89orD5C4sDunzzZbAkjHs3v29NvGwcm6xD9gXIh3imym554uGoOdRk3gBRIRB/DTk= X-Received: by 2002:ab0:53cd:: with SMTP id l13mr5310275uaa.107.1605731228419; Wed, 18 Nov 2020 12:27:08 -0800 (PST) MIME-Version: 1.0 References: <23007.1604344604@localhost> In-Reply-To: From: Ines Robles Date: Wed, 18 Nov 2020 22:26:32 +0200 Message-ID: To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="000000000000798ce805b4676f91" Archived-At: Subject: [Roll] IETF 109 - Complete Set of 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: Wed, 18 Nov 2020 20:27:12 -0000 --000000000000798ce805b4676f91 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear all, Please find below the link to the slide set for the IETF 109 https://datatracker.ietf.org/meeting/109/materials/slides-109-roll-roll-iet= f109-completesetofslides-00 Please let us know if you would like to help us as minute taker. Agenda with times in UTC and links to the tools (meetecho, codimd, etc.): https://datatracker.ietf.org/meeting/109/agenda-utc Comments welcome, Thank you very much in advance, Ines and Dominique. On Fri, Nov 13, 2020 at 5:17 PM Ines Robles wrote: > Dear Presenters, > > Please upload your slides for the IETF 109 in pdf format by Wednesday 18t= h > November at 11:00am UTC. > > Link to upload the slide set: > https://datatracker.ietf.org/meeting/109/session/roll > > Thank you, > > Ines and Dominique > > On Fri, Nov 13, 2020 at 10:25 AM Ines Robles < > mariainesrobles@googlemail.com> wrote: > >> Dear all, >> >> Please find an updated agenda for IETF 109: >> https://datatracker.ietf.org/meeting/109/materials/agenda-109-roll-03 >> >> Comments welcome, >> >> Thanks, >> >> Ines and Dominique >> >> On Mon, Nov 2, 2020 at 9:39 PM Ines Robles < >> mariainesrobles@googlemail.com> wrote: >> >>> Hi, >>> >>> Great!, we have 30 min slot-free, thus RFC6550bis would have 40 min i= f >>> there are no further meeting requests. >>> >>> Thank you, >>> >>> Ines. >>> >>> On Mon, Nov 2, 2020 at 9:16 PM Michael Richardson >>> wrote: >>> >>>> >>>> Ines Robles wrote: >>>> > - RPLv2 status (10 min) >>>> >>>> Who is doing this? [was it me?] >>>> I don't think that 10 minutes is enough. >>>> >>>> Rather than talk about RPLv2, let's talk about planning for RFC6550bis= . >>>> I think that needs a bunch of planning. >>>> >>>> -- >>>> Michael Richardson . o O ( IPv6 I=C3=B8T >>>> consulting ) >>>> Sandelman Software Works Inc, Ottawa and Worldwide >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Roll mailing list >>>> Roll@ietf.org >>>> https://www.ietf.org/mailman/listinfo/roll >>>> >>> --000000000000798ce805b4676f91 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,=C2=A0

Please find = below the link to the slide set for the IETF 109

<= a href=3D"https://datatracker.ietf.org/meeting/109/materials/slides-109-rol= l-roll-ietf109-completesetofslides-00">https://datatracker.ietf.org/meeting= /109/materials/slides-109-roll-roll-ietf109-completesetofslides-00
<= /div>

Please let us know if you would like to help us as= minute taker.=C2=A0

Agenda with times in UTC and = links to the tools (meetecho, codimd, etc.):=C2=A0https://datatracker.ietf.org/meeting= /109/agenda-utc

Comments welcome,
Thank you very much in advance,

Ines = and Dominique.=C2=A0

On Fri, Nov 13, 2020 at 5:17 PM Ines Robles <mariainesrobles@googlemail.com<= /a>> wrote:
<= div dir=3D"ltr">Dear Presenters,

Please upload your slid= es for the IETF 109 in pdf=C2=A0format by Wednesday 18th November at 11:00= am UTC.


Thank you,

Ines and Domi= nique

On Fri, Nov 13, 2020 at 10:25 AM Ines Robles <mariainesrobles@googl= email.com> wrote:
Dear all,

Please find an upd= ated agenda for IETF 109:=C2=A0=C2=A0https://datat= racker.ietf.org/meeting/109/materials/agenda-109-roll-03

=
Comments welcome,

Thanks,
Ines and Dominique

On Mon, Nov 2, 2020 at 9:39 PM Ines Ro= bles <mariainesrobles@googlemail.com> wrote:
Hi,=C2=A0

<= div>Great!, we have 30 min slot-free, thus=C2=A0 RFC6550bis=C2=A0 would have 40 min if there are no further meeting requests= .=C2=A0

Thank you,=C2=A0

= Ines.

On Mon, Nov 2, 2020 at 9:16 PM Michael Richardson <mcr+ietf@sandelman.ca> wrote:
Ines Robles <mariainesrobles=3D40googlemail.com@dmarc.ietf.org> wrote:<= br> =C2=A0 =C2=A0 > - RPLv2 status (10 min)

Who is doing this? [was it me?]
I don't think that 10 minutes is enough.

Rather than talk about RPLv2, let's talk about planning for RFC6550bis.=
I think that needs a bunch of planning.

--
Michael Richardson <mcr+IETF@sandelman.ca>=C2=A0 =C2=A0. o O ( IPv6 I=C3=B8T co= nsulting )
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sandelman Software Works Inc, Otta= wa and Worldwide




_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--000000000000798ce805b4676f91-- From nobody Wed Nov 18 22:54:47 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 602343A0AB6 for ; Wed, 18 Nov 2020 22:54:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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, 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 fMBlE6oxR6_8 for ; Wed, 18 Nov 2020 22:54:44 -0800 (PST) Received: from mail-ua1-x936.google.com (mail-ua1-x936.google.com [IPv6:2607:f8b0:4864:20::936]) (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 466703A0A96 for ; Wed, 18 Nov 2020 22:54:44 -0800 (PST) Received: by mail-ua1-x936.google.com with SMTP id k12so1567448uae.13 for ; Wed, 18 Nov 2020 22:54:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4iVopOGHftjgRGZ2u01zAi7uG+emjwBvWL8q7P2IiNw=; b=Pi2DAC8NTMRXot49Ff147BlrT3FNE789kYbcGRjmA6GD96siIDnWYmGfEeT9eW0SFZ iZS+lMrotXeLx1VvAN+f0cm0kxVz9rjG9VCSFOUrAVU5XQBhbwGUusy5S5K4M12cSsKP m1ueHHDLsYSle0B0V5q7XIRbjQIxeySFEoDoWJdo+tgE4PSQhyn8iqOmVoMecFh24kUM 272WyoVlr6mgHVNK2PJ17czzghC2xGUzMrfHMUcg7EwSAbMb6B7plKVK6dgHVJWh3vFc pnxdzFFuj3pJMZc5STtVJvxQa8xK4M2M+tv8RFA9ztSwbearO5OFfUPxGQFL2tYyFKwM eUvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4iVopOGHftjgRGZ2u01zAi7uG+emjwBvWL8q7P2IiNw=; b=E4NggGv21LjZFhooIkmwejqKaD0OE5CHcMbbRy9AjVbOQYDObMref9ftnC/ixZyTFz TPhVEFENdFsRknwVnK5fxTlnBPYfCxg03GSXNouFzotvbf6ifTOWhQZJac1rGfV2FAVF bSjD2147qJkJFN+TBBWfSzDZx3bl7adJw5cC54QW5fv0esAsPTpArs0nWV0mwdzdhFBB VeIGdaEYzLKFsiPn0C/3nmAIBDrhvnD+IsDkGiAsEwqzWoWpptWhlInW9vQGOYfePOgz L7lN1lBeksNAlWvUGjOyhIpiFaY+gcgJGy3H42lZSoJg/n3gX12Isbk+OKWEGS/6wh+g Tujg== X-Gm-Message-State: AOAM533meak9WktNBe49z5X7cjnSODJFVZCxM+mINdq7EsjGLv8QHT74 9quZ21wHFDHD9JUETRdEQSBkE07QGMA7jbgJvFOM3bCWNVc= X-Google-Smtp-Source: ABdhPJyyBXEwuxekyPiEBMWzNNIFs3WLuPTLk7jdp/PV2rDh3UrfQWQBxY1aexQUEb+p/UqsQsREzX1Q8TTh5wBb3pQ= X-Received: by 2002:ab0:330e:: with SMTP id r14mr9670090uao.46.1605768881857; Wed, 18 Nov 2020 22:54:41 -0800 (PST) MIME-Version: 1.0 References: <23007.1604344604@localhost> In-Reply-To: From: Ines Robles Date: Thu, 19 Nov 2020 08:54:05 +0200 Message-ID: To: Routing Over Low power and Lossy networks Content-Type: multipart/alternative; boundary="000000000000cb6af405b47033e5" Archived-At: Subject: Re: [Roll] IETF 109 - Complete Set of 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: Thu, 19 Nov 2020 06:54:46 -0000 --000000000000cb6af405b47033e5 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear all, Please find the link to the updated slide set https://datatracker.ietf.org/meeting/109/materials/slides-109-roll-roll-iet= f109-completesetofslides-01 Thanks, Ines and Dominique On Wed, Nov 18, 2020 at 10:26 PM Ines Robles wrote: > Dear all, > > Please find below the link to the slide set for the IETF 109 > > > https://datatracker.ietf.org/meeting/109/materials/slides-109-roll-roll-i= etf109-completesetofslides-00 > > Please let us know if you would like to help us as minute taker. > > Agenda with times in UTC and links to the tools (meetecho, codimd, etc.): > https://datatracker.ietf.org/meeting/109/agenda-utc > > Comments welcome, > > Thank you very much in advance, > > Ines and Dominique. > > On Fri, Nov 13, 2020 at 5:17 PM Ines Robles < > mariainesrobles@googlemail.com> wrote: > >> Dear Presenters, >> >> Please upload your slides for the IETF 109 in pdf format by Wednesday >> 18th November at 11:00am UTC. >> >> Link to upload the slide set: >> https://datatracker.ietf.org/meeting/109/session/roll >> >> Thank you, >> >> Ines and Dominique >> >> On Fri, Nov 13, 2020 at 10:25 AM Ines Robles < >> mariainesrobles@googlemail.com> wrote: >> >>> Dear all, >>> >>> Please find an updated agenda for IETF 109: >>> https://datatracker.ietf.org/meeting/109/materials/agenda-109-roll-03 >>> >>> Comments welcome, >>> >>> Thanks, >>> >>> Ines and Dominique >>> >>> On Mon, Nov 2, 2020 at 9:39 PM Ines Robles < >>> mariainesrobles@googlemail.com> wrote: >>> >>>> Hi, >>>> >>>> Great!, we have 30 min slot-free, thus RFC6550bis would have 40 min >>>> if there are no further meeting requests. >>>> >>>> Thank you, >>>> >>>> Ines. >>>> >>>> On Mon, Nov 2, 2020 at 9:16 PM Michael Richardson < >>>> mcr+ietf@sandelman.ca> wrote: >>>> >>>>> >>>>> Ines Robles wrote= : >>>>> > - RPLv2 status (10 min) >>>>> >>>>> Who is doing this? [was it me?] >>>>> I don't think that 10 minutes is enough. >>>>> >>>>> Rather than talk about RPLv2, let's talk about planning for RFC6550bi= s. >>>>> I think that needs a bunch of planning. >>>>> >>>>> -- >>>>> Michael Richardson . o O ( IPv6 I=C3=B8T >>>>> consulting ) >>>>> Sandelman Software Works Inc, Ottawa and Worldwide >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> Roll mailing list >>>>> Roll@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/roll >>>>> >>>> --000000000000cb6af405b47033e5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear all,

Please find the link to the u= pdated slide set


Thanks,=

Ines and Dominique

On Wed, Nov 18, 2020 at 1= 0:26 PM Ines Robles <= mariainesrobles@googlemail.com> wrote:
Dear all,=C2=A0

Please find below the link to the slide set for the IETF = 109


Pl= ease let us know if you would like to help us as minute taker.=C2=A0
<= div>
Agenda with times in UTC and links to the tools (meetech= o, codimd, etc.):=C2=A0https://datatracker.ietf.org/meeting/109/agen= da-utc

Comments welcome,

<= div>Thank you very much in advance,

Ines and Domin= ique.=C2=A0

On Fri, Nov 13, 2020 at 5:17 PM Ines Robles <mariainesrobles@google= mail.com> wrote:
Dear Presenters,

Please upload = your slides for the IETF 109 in pdf=C2=A0format by Wednesday 18th November= at 11:00am UTC.


Thank you,

Ines and Domi= nique

On Fri, Nov 13, 2020 at 10:25 AM Ines Robles <mariainesrobles@googl= email.com> wrote:
Dear all,

Please find an upd= ated agenda for IETF 109:=C2=A0=C2=A0https://datat= racker.ietf.org/meeting/109/materials/agenda-109-roll-03

=
Comments welcome,

Thanks,
Ines and Dominique

On Mon, Nov 2, 2020 at 9:39 PM Ines Ro= bles <mariainesrobles@googlemail.com> wrote:
Hi,=C2=A0

<= div>Great!, we have 30 min slot-free, thus=C2=A0 RFC6550bis=C2=A0 would have 40 min if there are no further meeting requests= .=C2=A0

Thank you,=C2=A0

= Ines.

On Mon, Nov 2, 2020 at 9:16 PM Michael Richardson <mcr+ietf@sandelman.ca> wrote:
Ines Robles <mariainesrobles=3D40googlemail.com@dmarc.ietf.org> wrote:<= br> =C2=A0 =C2=A0 > - RPLv2 status (10 min)

Who is doing this? [was it me?]
I don't think that 10 minutes is enough.

Rather than talk about RPLv2, let's talk about planning for RFC6550bis.=
I think that needs a bunch of planning.

--
Michael Richardson <mcr+IETF@sandelman.ca>=C2=A0 =C2=A0. o O ( IPv6 I=C3=B8T co= nsulting )
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Sandelman Software Works Inc, Otta= wa and Worldwide




_______________________________________________
Roll mailing list
Roll@ietf.org
https://www.ietf.org/mailman/listinfo/roll
--000000000000cb6af405b47033e5-- From nobody Tue Nov 24 05:22:25 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 532683A0CBB for ; Tue, 24 Nov 2020 05:22:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.719 X-Spam-Level: X-Spam-Status: No, score=-7.719 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=h772U6q1; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=TOF91abW 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 eT94AXQy5k0B for ; Tue, 24 Nov 2020 05:22:20 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 930283A0CC0 for ; Tue, 24 Nov 2020 05:22:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9849; q=dns/txt; s=iport; t=1606224140; x=1607433740; h=from:to:subject:date:message-id:mime-version; bh=9xSMKQxQMb/+FdcDB2OuWSjZ53+W5TM29LXiJ/9e/yA=; b=h772U6q1Pze3drdHVIkJ7cEmPWF65NJjHNS9yWRFjbEQGS7KzN9ZOm/q C8mLRmy5ywu4oBsbkYBSBMteZ0LvsZGSb8/NDhD+iQRUR//cYsxbeRMFW ZY4AvZFZHjiyjsfKIHMvU98HXtuPB2b8++SoZmvBi32pk8+/OytzuYleX k=; X-IPAS-Result: =?us-ascii?q?A0CzCQDYB71f/51dJa1igQmCci9RB3RZLy4Kh3wDnlmDF?= =?us-ascii?q?oRwgUKBEQNUCwEBAQ0BASMKAgQBAYRKAoIsAiU4EwIDAQEBAwIDAQEBAQUBA?= =?us-ascii?q?QECAQYEcYVhDIYLGxMBATgRAYEAJgEEGxqDBYF+VwMuAQ6ieAKBPIhodIE0g?= =?us-ascii?q?wQBAQWBNwQMQYMVGIIQAwaBOIJzik0bgUE/gRBEhBGBWQIDAYEhPCuDHYIsk?= =?us-ascii?q?HyKF506CoJuiRSJXIhSogaeYZVfAgQCBAUCDgEBBYFrI4FXcBU7gmlQFwINk?= =?us-ascii?q?hCFFIVEdDcCBgoBAQMJfI45AYEQAQE?= IronPort-PHdr: =?us-ascii?q?9a23=3ADhNK1hRixK3DfH9dx77BmLhfWNpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESQBN+J6v9YhazRqa+zEWAD4JPUtncEfdQMUh?= =?us-ascii?q?IekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsutZlDOrDu19zFBUh?= =?us-ascii?q?n6PBB+c+LyHIOahs+r1ue0rpvUZQgAhDe0bb5oahusqgCEvcgNiowkIaE0mR?= =?us-ascii?q?Y=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,366,1599523200"; d="scan'208,217";a="591845648" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Nov 2020 13:22:19 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AODMJQ4001721 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 24 Nov 2020 13:22:19 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 24 Nov 2020 07:22:19 -0600 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 24 Nov 2020 08:22:18 -0500 Received: from NAM11-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 24 Nov 2020 07:22:18 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SjjGVJUNQjjT1YjYNuTSj/3nfdOEsddUx0C3Jsi2tOGP/mWO93/8rroQIP4/yv3vvThklTDSCzls/jiViMLhfKH10VAq267KcdFWLFzbLnqIdVxDiA4ALDAgYko0jhFHQ/N1rbN4T3xT2bPyKVvoeAJRgXNexdV4kNdAOKBpW5GWaIYzgaJD1MR1qlYOtzGlwCF4bccVBMw+FFioar+cUHrAP0LCcuy1o8zIPhujWdamw+KhEMVrLbqesVjOPZSAn5PIchO96kcitwPfndWUeAjlMfiT5TPtLfdobkCBdEhIw8SjPLOqVjsBfm0/cWByw/uRPa/rrBvwtetdD/2Ghg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=v1nHdL06eaciW5RXF897cUeXMDuSyerVAf1NTDQaneE=; b=fSkkiyqvIWAvwNvt/i535lLgqU40W3Z3LLdwrjlvZoKdOseE9UstpnZWIrYO3iHcxUAMYEwm4+hU6tpTuMX/6K8v/PEU0HJQaaMRdkrdBdqi5N6tB4/DJbfaHQGaDNctYbleq1mLcb1mFslhxdstdvZ3Nz2amzPI6YEUrCVfIeYPlJen3gXp7a2IEdDG/SOWl4RkEQZAOC7QcxQbECicWySe/5p0F10F4WweWfy2kF2FfuL1QvGYYUdmTliUHvGRj55K4nqeobYAEVnkgA1KQsQR1cgz9WHhJgCX6qYZKAca8pviKIJRdx1VTMsU3bjuxbTEfr7AQ/sA2X1+WCJUWw== 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=v1nHdL06eaciW5RXF897cUeXMDuSyerVAf1NTDQaneE=; b=TOF91abWmtBVCJ3pWKulRttt+iKfWY9lQ4EBdlpa9lnZBcyuDRIS85E+iEaTg9j//7+xVYRfuM832h1gzHmkwNN+OPP5idwQd/uj16vQzuL03xMzMjFB30b/PbbpGLt0+v0+ZzLBmFZYY63IQ1VoqQC/DVe0dQVAIznOR5S7ZJw= Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by MWHPR11MB1840.namprd11.prod.outlook.com (2603:10b6:300:112::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.29; Tue, 24 Nov 2020 13:22:17 +0000 Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::fc25:3e72:3e83:7df6]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::fc25:3e72:3e83:7df6%4]) with mapi id 15.20.3564.025; Tue, 24 Nov 2020 13:22:17 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: IETF 109 open Questions on P-DAO Thread-Index: AdbCY32NelMcR5MvThCvhSSTyZHQKg== Date: Tue, 24 Nov 2020 13:22:04 +0000 Deferred-Delivery: Tue, 24 Nov 2020 13:21:36 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.220.44] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e96e518a-bc15-4347-3026-08d8907bf73a x-ms-traffictypediagnostic: MWHPR11MB1840: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 6RNOJxQiUiBQaD44no6v8NeIKdPam4+jyHe4fvpLW5z+FvH2WW4xd5DTIOfp0TPwOKjNmgeXE4cfWa3K1WTKXiACj8Pp/Wzl8FABsrqFLsqhXSY4U7OlVTP1meaKAlH0o8PEsSTDfU6jJWJ+V/W+CBeVwtH8vInaawj/1H3zpjcvx64iiWRCEekW6XR0teGNWuF9+s43jXv8Oh6GUgVLJ0p+8Faa2ebq7CNmcVsxAACno1vnoibCc7LRh1g/EsoOPPeIDqvSfXkZKKsYV2MYJ/pucDksgNTJ8+AcuvQw54m/pEw5J8+GBSMLzB9ecFPDqsWruyp8o/JgDClufFkow0p0iGOZL7gC+hjOuu8WhgLQ2WjkpbOy5ksB+zrELuiVEWyTAEGHXqPl1RP6MQEg4Q== 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:(396003)(346002)(376002)(136003)(39860400002)(366004)(166002)(33656002)(5660300002)(71200400001)(66556008)(76116006)(64756008)(316002)(9686003)(66446008)(66476007)(186003)(55016002)(52536014)(2906002)(26005)(8676002)(6916009)(66946007)(478600001)(86362001)(6506007)(8936002)(7696005)(6666004)(966005)(83380400001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?6l8GBlLrU0AX7bsTGakV3f5H5EUWbpLIC2vj2aMJSvThvJx95FPSR9cbKEjH?= =?us-ascii?Q?JJYAewHs5S3VwAjQE+8iHmEoHNbvHr6UW1vgX7QERg9nML8dEmcQTuE9sraY?= =?us-ascii?Q?3FTB++cIfuF4osX9oJDm+D1k9siFqNBg31q90wogNzRYylHPwv1cV1u4bkAn?= =?us-ascii?Q?9R7mQ1aR7oVW4KSyOmyrnC1k5IVfLdifQEkFZCKjERh1k/knq8Yj4nkyqxih?= =?us-ascii?Q?OVofRWM+slBHbrR1Ebp1sMjMocuYtV1MXaLk0H7C9J9rOGkIekVqTKD4w0ix?= =?us-ascii?Q?83uhlhQ3OTCYqM9G0kGVNalOVrreSiVm/vaEvUxA9ZG+reitXWQbu0hrXRx2?= =?us-ascii?Q?K0bUspFPmpHbAfVclmfeXapiNhBA3aQDObX7Mml5cZX2sa16OJeAUjmn5o7I?= =?us-ascii?Q?b+TD7kqrX4Yin/yw4xH3NPd8hgFtTTITGfu7qCrPpVfrRd5dsruEcYPLuhBD?= =?us-ascii?Q?DwxXqbkCu4F8K5TIb1iJd4nzto7//8zrGZymz8hCq8CqTFTHiXpLfUohnhuj?= =?us-ascii?Q?KE0qQ1bm02++M9UV1RwZtKC8YK39i2JTPDoNnMeqflpGiicvivX8Y+JfZx+y?= =?us-ascii?Q?OMG1e2c3i5VuGTtq6Iyx/ZvdTIYbphi/qUaYS4D8K+GBipV17HaxdMES8V2H?= =?us-ascii?Q?itjlOFwYPMJK8NmsSEM72gN4yTkSsMBXL4d/qB6PsInPZUmxhzxDa+jDkvOd?= =?us-ascii?Q?antYYYLtwc93Hvti0Ko/P8VQk6RKiKCs8Ew7/huZwoX/iVdB4s6MFin9np8O?= =?us-ascii?Q?ZnszmrYvPvOVJV+RWEVmQx+2eHCzW0wtKx2d+rmsRwuzWHA1BtaE5Q3uQnPs?= =?us-ascii?Q?tsQ7doqQ9F2wzLKw8Lv8r8Ibc1bstj9JihKC+4wHEFv3DRTE2lGalhoxdtRM?= =?us-ascii?Q?7EIm6XIEU06dUQTwhho3L64LZfrrfD3uiAMplPcI5C+ZmmT6XhRN0Xoi0Cnu?= =?us-ascii?Q?O96rCVP0pY/23Xv5qbVahr50Egr60i1UcUboJmzq3JtWzVA0k3HzLRiS/lp6?= =?us-ascii?Q?tywb?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CO1PR11MB4881B348B4A224DBAEE5BA74D8FB0CO1PR11MB4881namp_" 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: e96e518a-bc15-4347-3026-08d8907bf73a X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Nov 2020 13:22:17.5411 (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: 3lOgHhj0+u9N21zNQ2IZZDwPZyL2UPVMIArP1p+4D1JywRUfDLh4Ii8ahhG4ciUZjeGj0cmsZSBQwIk1gs6ViQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1840 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: [Roll] IETF 109 open Questions on P-DAO 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, 24 Nov 2020 13:22:23 -0000 --_000_CO1PR11MB4881B348B4A224DBAEE5BA74D8FB0CO1PR11MB4881namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all The slides for the P-DAO discussion at IETF 109 are available here: https://datatracker.ietf.org/doc/slides-109-roll-dao-projection/ There are a number of open questions that we starting discussing, and would= need to progress on the list. Some of them were expressed on the list, e.g., from Huimin She. I'd like to= progress on them all with individual threads. The questions are: 1. Lifetime Unit: could we use a different unit for P-DAO? 2. How to differentiate a P-DAO from a normal DAO in a local instance; n= ew flag? 3. Make P-DAO bidirectional? 4. Who sends the PDR? Does it have to be the ingress? If it was egress i= t could propose a TrackId from its namespace. Else could the ingress be the= root? 5. Maintaining the sibling state. Should we have text on using RFC 8505 = there? 6. Whether ingress and egress are listed in NPO? Today they are both, in= gress to indicate the packet source in case of encapsulation and for SRH-6L= oRH compression reference and egress to build the full SRH-6LoRH. Note that= the ingress must consume the first entry and use it as source. 7. Track in Track vs. SR Header reload models, see slides Let me open threads to follow up. Keep safe Pascal --_000_CO1PR11MB4881B348B4A224DBAEE5BA74D8FB0CO1PR11MB4881namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all

 

The slides for the P-DAO discussion at IETF 109 are availabl= e here:

 

https://datatracker.ietf.org/doc/slides-109-roll-dao-proje= ction/

 

There are a number of open questions that we starting discus= sing, and would need to progress on the list.

Some of them were expressed on the list, e.g., from Huimin S= he. I’d like to progress on them all with individual threads.

The questions are:

 

  1. Li= fetime Unit: could we use a different unit for P-DAO?
  2. How to differentiate a P-DAO from a normal DAO in a local instance; n= ew flag?
  3. Make P-DAO bidirectional?
  4. Who sends the PDR? Does it have to be the ingress? If it was= egress it could propose a TrackId from its namespace. Else could the ingress be the root?
  5. Maintaining the = sibling state. Should we have text on using RFC 8505 there?
  6. Whether ingress and egress are listed in NPO? Today they are bo= th, ingress to indicate the packet source in case of encapsulation and for SRH-6LoRH compression reference and egress to build the full SRH-6= LoRH. Note that the ingress must consume the first entry and use it as sour= ce.
  7. Track in Track vs. SR Header reload models, = see slides

 

Let me open threads to follow up.

 

Keep safe

 

Pascal

 

 

--_000_CO1PR11MB4881B348B4A224DBAEE5BA74D8FB0CO1PR11MB4881namp_-- From nobody Tue Nov 24 05:39:26 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CCC03A0DA8 for ; Tue, 24 Nov 2020 05:39:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.719 X-Spam-Level: X-Spam-Status: No, score=-7.719 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=MMiLiU2k; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=llvK5ICM 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 ii3GmpfT5Xke for ; Tue, 24 Nov 2020 05:39:23 -0800 (PST) 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 382BE3A0DAC for ; Tue, 24 Nov 2020 05:39:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16219; q=dns/txt; s=iport; t=1606225163; x=1607434763; h=from:to:subject:date:message-id:mime-version; bh=/iY7HanYrq423N93JXH82MRSyvw7aU2UcyPcOIlUDVE=; b=MMiLiU2kWJ/Vv315beUDlbYN2lQnFlEfL1jrm4MU2LKRLGzKIe2XL0qX /3x7Gewk9YCHoygodhnYV+e1liDokcgdgmEj+U9cFM03ZXHxwxFba6rJi H69XxZVKE+8JO7Cz4hltSyC/9hOS3nCAbbnuaTo8QTo0SkvMj8DXpDXf0 0=; X-IPAS-Result: =?us-ascii?q?A0DLCAAgC71ffZ1dJa1igQmCci9Re1kvLgqHfAOeWIMWh?= =?us-ascii?q?HCBQoERA1QLAQEBDQEBIwoCBAEBhEoCgiwCJTgTAgMBAQEDAgMBAQEBBQEBA?= =?us-ascii?q?QIBBgQUAQGGPAyFcgEBFxsTAQE4EQEZAQMBAWEXBgkBBBMIGoMFgX5XAy4BD?= =?us-ascii?q?qJpAoE8iGh0gTSDBAEBBYE3BAxBgxUYghADBoE4gnOKTRuBQT+BEESCIYFwg?= =?us-ascii?q?VkCAwGBIRwgJAeDHYIskHyKF506CoJuiRSJXIhSgxqKGZRTOp4nlV8CBAIEB?= =?us-ascii?q?QIOAQEFgWshgVlwFTuCaVAXAg2SEIUUhUR0NwIGCgEBAwl8jQYtgQYBgRABA?= =?us-ascii?q?Q?= IronPort-PHdr: =?us-ascii?q?9a23=3A/Ih6bhcX2tKAeqGfoP3ts1yLlGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwaQB9fa5u5Kze3MvPOoVW8B5MOHt3YPONxJWg?= =?us-ascii?q?QegMob1wonHIaeCEL9IfKrCk5yHMlLWFJ/uX3uN09TFZX/akHc5Hqo4m1aFh?= =?us-ascii?q?D2LwEgIOPzF8bbhNi20Obn/ZrVbk1IiTOxbKk0Ig+xqFDat9Idhs1pLaNixw?= =?us-ascii?q?=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,366,1599523200"; d="scan'208,217";a="614213050" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 24 Nov 2020 13:39:19 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AODdJF5023493 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 24 Nov 2020 13:39:19 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 24 Nov 2020 07:39:19 -0600 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 24 Nov 2020 07:39:18 -0600 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 24 Nov 2020 07:39:18 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=WuJPUi9H83iQkBX9RPZCePGV9XSbQBRt3McEz6uvjRsn3SvCekn2HnKiVw56SPd9lk3+qTzjpck4ybneGyMtIhDFBdj9uiXPVuW2ggO+mTRpPCQ80DmQNVSqASFkhw8NkBFTtxdkTjd2dXXaQIiwQg9aS6q9Ksm+e13XI8IT9h9Q237neb2LSssJqMQ2YHb36DPzq4dB/JgR4ReTxxHik5LHyU2wtWCj8Hr5KyOWW6AcKNDC2d6j8PAMsKosLrI8pyOQ/HDq+GcbNwzBxlN/EzZsvkxI+ojTEENLiEfOq0xtGjpWdUu+uASUR40zGyhHsEtM5n5rdcYi6N9B4NOL5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=LMZHjsFAPzc2G+ZK15gppajf2JDOrueuBk7PVuKGdTk=; b=J8kGX3E3cvuuDZxdnZaFAcaKNSP7znTbqUdGIOTeLnUpq1+Z0j6xH7PiJpuIx56BsCtOb3EahnUMPK7RQfM69gnbmxvaHnMFH/o1jCwqcj1w1Q5OXCU0aSqrLqgnD6C5c2Cd5WBxlp1asOny5HvOqz/Af//nNW1iaeeZzM7iuE5Oo32hvfJbnlffvjrCXKeJvqHUpW21WYDJPa8h6LVSBK4EWgLpG54KIptyYHwAecZ77Z+p8uSHen8NBjS9zfSEl39JY+j6ag7L1A30Pn6o8l8tfsUSJTZg197p9SmwPRft2JANExgecH6qEVgb3oFy1O/iEzSHj8TSsto7yGlETA== 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=LMZHjsFAPzc2G+ZK15gppajf2JDOrueuBk7PVuKGdTk=; b=llvK5ICMXHRD39P51lBOS0uYcuaa5xkS7MlhRgn6Xt0Royo084v85wAQIQwZLdz/WEFO/SyiYrTdlFp5eR+DQdV2sI31COPj9QKFrIZ/81OST/sleiTE6eZh3iQ6G1++FfmssPhTdRY7VwXU3TDJJy/+G5A1ztc/PxW6aLLzAl4= Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by MWHPR1101MB2126.namprd11.prod.outlook.com (2603:10b6:301:50::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.28; Tue, 24 Nov 2020 13:39:17 +0000 Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::fc25:3e72:3e83:7df6]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::fc25:3e72:3e83:7df6%4]) with mapi id 15.20.3564.025; Tue, 24 Nov 2020 13:39:17 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: Make P-DAO bidirectional [extends] IETF 109 open Questions on P-DAO Thread-Index: AdbCZRGxaZJsqD20SLuISSoVqF9MEg== Date: Tue, 24 Nov 2020 13:39:09 +0000 Deferred-Delivery: Tue, 24 Nov 2020 13:38:47 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.220.44] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 26e9efb2-f821-4b94-4b21-08d8907e5733 x-ms-traffictypediagnostic: MWHPR1101MB2126: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: V7I7M5/gefFeIQ3grt+jYU4uIqJLWbO9xDpuKcqSvW/pA+UEbtKErdlDDLzHLMknaue/J0dSoKYBy8NfpTFMZp3HFVy/HhHgxyqRdPv5tpDDFTgDPu2FobVbTXlzvkJvBsS8oNwh+9tjIWmCgjNpa/bOHKSq9zGHCsYVRU4k2tcGpIbhSyqK51Ej5+a3IqrOK3D0mVg8eablcww42hQ76lJz0z4YltvQSXRVgdV156P/dDbaxYeWB+KzaSVgLZ1c5Ly90BTm4e6Eys08ydz6yxSjO74jAc4dJ3tsdCrvWCZoSppbYjAmgHBGtVevAGHkS8PbEL4olf0DzUJMbW4s0eoJG6EaN/V8gFsDTZTSjezTRYIJejXIJCHqTaYqYewor6VJlgBWVuN3tssu0C0D1Q== 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:(366004)(396003)(376002)(39860400002)(136003)(346002)(8676002)(71200400001)(186003)(6666004)(33656002)(9686003)(55016002)(478600001)(66946007)(26005)(86362001)(52536014)(83380400001)(8936002)(5660300002)(6916009)(316002)(53546011)(76116006)(66446008)(64756008)(66556008)(66476007)(966005)(6506007)(166002)(7696005)(2906002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?R0Rv6nR+l9n3j499O1FXdMG9ci5ByOOLYE/CObSGwqK5nYeON+y4P5jBHbHV?= =?us-ascii?Q?xovi77s1+CrhZHZcvQl/sWbELn2+mioOG9/12Fu2bvsTFcuV1I0ohI0NqjQY?= =?us-ascii?Q?PwYCNpyaWKC/DnR2HZIWb50xHbMurDKKspvA968/KfEeyX6IgRKp3+anw1nb?= =?us-ascii?Q?i0dpFXiwoUyd9oDMFPr97S6mWw8C1riREpRQYinMtYtphjL6prxPKOIUukVN?= =?us-ascii?Q?Amf0LFpYCBY+lquawft00HqqZ6KevGYm20By3F2txT2tR8BxeNTBz8JhfIwB?= =?us-ascii?Q?XTG3Y4tJzMLXVzG2sgpd8sgokDHPKCqHlc5KMGPfDvtYDDqaWALhzDMvupNo?= =?us-ascii?Q?rxwvZwh6lGmcHghMCXylvYg3FcoyqW9WL4r8fkl+aLhc7Mijej3EZ547XEXN?= =?us-ascii?Q?NSwKiqW0xN8eUz+Zv6o5Nx0WrnZeQJdMWF+q3cSRMtMPY8Z+cIJgB6F4TE2K?= =?us-ascii?Q?6hU54h+evzbgsIM+GCYid+NN/Uv/4uyR4GOl3fCLhsvticd/nYoAPi1VSER4?= =?us-ascii?Q?RnTyEBCgYEJFtHGwyq71xlRxTxRciSWq0NFCp8PoMx7q3XfylZKGYPXnhXH1?= =?us-ascii?Q?IQQ4J5tPaUdjCj+QjzZFcvYaomuw1/qMoTj6L2tAv4gqhsvqfxnaKd9GMddo?= =?us-ascii?Q?LFYE9hcBePbTQGpYWBMUQkXJxOsI+46i2B3/Bbau2ntbgySRVtTGM3yzeH+c?= =?us-ascii?Q?xPNtLVl5IpgSCou2MPqXCLwf9lyE4kjq4VGsjj/1aWASl9eZ7Cb2jWEHZjWL?= =?us-ascii?Q?C3inNQApqaDLT/v0gaa75D8Srk0xbnmQb+2uopX6VgggG5/+u/lbzkXfAvs4?= =?us-ascii?Q?rjojwhy7QxSXA0gsDX0Fe/gKnssjseUTmwLt9TdZIMA131JCHz3wXUs8uNAO?= =?us-ascii?Q?iMkdjiUpjyRF12zxCjOU58TR94Qe/OaQPokVugleHjXZ3dxqOd+pTz6j2mfn?= =?us-ascii?Q?tRAv6GrIGoa6x6HaUcdjf7kf9PTICwyP9Ct9Pt2xmy7JG4DOePDvcNg/5U96?= =?us-ascii?Q?ffe6?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CO1PR11MB4881CE0521CFB876B608188BD8FB0CO1PR11MB4881namp_" 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: 26e9efb2-f821-4b94-4b21-08d8907e5733 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Nov 2020 13:39:17.5436 (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: hc2qJmUTindshbUFdCYBp1nCxGHBE5GQxTzXzNcyejTPmf3BrDFf0xzrOwurOqUAaiT/EZtAYlUim/CxiIMwqA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1101MB2126 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questions on P-DAO 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, 24 Nov 2020 13:39:25 -0000 --_000_CO1PR11MB4881CE0521CFB876B608188BD8FB0CO1PR11MB4881namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all Whether to make the P-DAO bidirectional is an intriguing question. It could= be done, just like we can send packets DOWN a classical DODAG. But if we take that path, we reopen the question of who is root and which d= irection the P-DAO flies. Could we make either the ingress OR the egress root? How does it matter? At the moment the Root is the egress and the storing-mode P-DAO flies from = the Track egress to the track ingress, and the track egress is the root. Th= is is not the way RPL usually works as the DAO flies towards the root. The = reason was that we wanted a single egress for the Track, as we build unicas= t Track. If we wanted to build multicast Tracks the root should logically b= e the ingress. And for bidirectional Tracks it could be either. Up to -24 the 6TiSCH Architecture expected the ingress to be root. I change= d in the latest to map we do here, that it is the egress; maybe a flag in t= he DAO would indicate which direction the flow, from root, to root, or both= ? Also if we build bidir Tracks in storing mode, the nodes that forward the D= AO will have to build routes in both directions based on the P-DAO, both to= wards egress and ingress; but only the path from which the P-DAO comes has = been validated by the P-DAO itself. Should we send a P-DAO to each end, eac= h setting up one way? Please let me know your thoughts Pascal From: Roll On Behalf Of Pascal Thubert (pthubert) Sent: mardi 24 novembre 2020 14:22 To: Routing Over Low power and Lossy networks Subject: [Roll] IETF 109 open Questions on P-DAO Dear all The slides for the P-DAO discussion at IETF 109 are available here: https://datatracker.ietf.org/doc/slides-109-roll-dao-projection/ There are a number of open questions that we starting discussing, and would= need to progress on the list. Some of them were expressed on the list, e.g., from Huimin She. I'd like to= progress on them all with individual threads. The questions are: 1. Lifetime Unit: could we use a different unit for P-DAO? 2. How to differentiate a P-DAO from a normal DAO in a local instance; n= ew flag? 3. Make P-DAO bidirectional? 4. Who sends the PDR? Does it have to be the ingress? If it was egress i= t could propose a TrackId from its namespace. Else could the ingress be the= root? 5. Maintaining the sibling state. Should we have text on using RFC 8505 = there? 6. Whether ingress and egress are listed in NPO? Today they are both, in= gress to indicate the packet source in case of encapsulation and for SRH-6L= oRH compression reference and egress to build the full SRH-6LoRH. Note that= the ingress must consume the first entry and use it as source. 7. Track in Track vs. SR Header reload models, see slides Let me open threads to follow up. Keep safe Pascal --_000_CO1PR11MB4881CE0521CFB876B608188BD8FB0CO1PR11MB4881namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all

 

Whether to make the P-DAO bidirectional is an intriguing que= stion. It could be done, just like we can send packets DOWN a classical DOD= AG.

But if we take that path, we reopen the question of who is r= oot and which direction the P-DAO flies.

 

Could we make either the ingress OR the egress root? How doe= s it matter?

 

At the moment the Root is the egress and the storing-mode P-= DAO flies from the Track egress to the track ingress, and the track egress = is the root. This is not the way RPL usually works as the DAO flies towards the root. The reason was that we wanted a s= ingle egress for the Track, as we build unicast Track. If we wanted to buil= d multicast Tracks the root should logically be the ingress. And for bidire= ctional Tracks it could be either.

 

Up to -24 the 6TiSCH Architecture expected the ingress to be= root. I changed in the latest to map we do here, that it is the egress; ma= ybe a flag in the DAO would indicate which direction the flow, from root, to root, or both?<= /p>

 

Also if we build bidir Tracks in storing mode, the nodes tha= t forward the DAO will have to build routes in both directions based on the= P-DAO, both towards egress and ingress; but only the path from which the P-DAO comes has been validated by the P-D= AO itself. Should we send a P-DAO to each end, each setting up one way?

 

Please let me know your thoughts

 

Pascal

 

 

From: Roll <roll-bo= unces@ietf.org> On Behalf Of Pascal Thubert = (pthubert)
Sent: mardi 24 novembre 2020= 14:22
To: Routing Over Low power a= nd Lossy networks <roll@ietf.org>
Subject: [Roll] IETF 109 ope= n Questions on P-DAO

 

Dear all

 

The slides for the P-DAO discussion at IETF 109 are availabl= e here:

 

https://datatracker.ietf.org/doc/slides-109-roll-dao-proje= ction/

 

There are a number of open questions that we starting discus= sing, and would need to progress on the list.

Some of them were expressed on the list, e.g., from Huimin S= he. I’d like to progress on them all with individual threads.

The questions are:

 

  1. Li= fetime Unit: could we use a different unit for P-DAO?
  2. How to differentiate a P-DAO from a normal DAO in a local instance; n= ew flag?
  3. Make P-DAO bidirectional?
  4. Who sends the PDR? Does it have to be the ingress? If it was= egress it could propose a TrackId from its namespace. Else could the ingress be the root?
  5. Maintaining the = sibling state. Should we have text on using RFC 8505 there?
  6. Whether ingress and egress are listed in NPO? Today they are bo= th, ingress to indicate the packet source in case of encapsulation and for SRH-6LoRH compression reference and egress to build the full SRH-6= LoRH. Note that the ingress must consume the first entry and use it as sour= ce.
  7. Track in Track vs. SR Header reload models, = see slides

 

Let me open threads to follow up.

 

Keep safe

 

Pascal

 

 

--_000_CO1PR11MB4881CE0521CFB876B608188BD8FB0CO1PR11MB4881namp_-- From nobody Tue Nov 24 18:14:58 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87D563A0C26 for ; Tue, 24 Nov 2020 18:14:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 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_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=dE2UefAg; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=VpGYW72A 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 R8DeU69Qc43T for ; Tue, 24 Nov 2020 18:14:55 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC92C3A0C21 for ; Tue, 24 Nov 2020 18:14:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2882; q=dns/txt; s=iport; t=1606270494; x=1607480094; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=9Vy/VFEGtj8IDQ+1gR1ei3pZx5PDRFkDPcOkU2TgS/A=; b=dE2UefAg0Pf+PEmTHsm2lh15FUxDb6TaTs7rNHqvS4p8aWF0J8cDi/mw 5gFD6n+msMCbx/UMCjFpGwv01ICAo+JpGUep+0WiN2JjGv/csWsr+XiSB ZagojDlqcAwEHT2k56mI3T9jVOa3IPFq1QmupVooVCnYH215OGTQaDPtB U=; X-IPAS-Result: =?us-ascii?q?A0BaCQCmu71ffYQNJK1igQmDIVF7WS8uCoQzg0kDjTQmm?= =?us-ascii?q?QSBQoERA1QLAQEBDQEBIwoCBAEBhEoCF4IVAiU4EwIDAQEBAwIDAQEBAQUBA?= =?us-ascii?q?QECAQYEFAEBhjwBC4VyAQYSEREMAQE4EQEIEQMBAgMCJgIEMBUICgQTIoJ/B?= =?us-ascii?q?AEBglUDLgEOozQCgTyIaHaBMoMEAQEFgTcEDEFEgnMDFYIQAwaBDiqCc4N2h?= =?us-ascii?q?lcbgUE/gRAoDBCCIS4+gQSBWQIDAYEhHCUQDxSCXTOCLJB8gnWjT4ENCoJui?= =?us-ascii?q?RSJXIgwAx+iBpNdiwSVXwIEAgQFAg4BAQWBayEPgUpwFTsqAYI+UBcCDY43g?= =?us-ascii?q?1mFFIVEdAIBNAIGCgEBAwl8jgABgRABAQ?= IronPort-PHdr: =?us-ascii?q?9a23=3AuabLthXKSHi3u3CR5SYET9CWgh3V8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSBNyBufNJl+SQtLrvCiQM4peE5XYFdpEEFx?= =?us-ascii?q?oIkt4fkAFoBsmZQVb6I/jnY21ffoxCWVZp8mv9PR1TH8DzNFzfvnP06iQdSV?= =?us-ascii?q?3zMANvLbHzHYjfx828y+G1/cjVZANFzDqwaL9/NlO4twLU48IXmoBlbK02z0?= =?us-ascii?q?jE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,367,1599523200"; d="scan'208";a="636534791" Received: from alln-core-10.cisco.com ([173.36.13.132]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Nov 2020 02:14:53 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-10.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AP2Er9C021058 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 25 Nov 2020 02:14:53 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 24 Nov 2020 20:14:53 -0600 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 24 Nov 2020 20:14:52 -0600 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 24 Nov 2020 20:14:52 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fg9fVpnJbkisjcZVhGr0G3HxgYxd/Rx2caKFu1n6+cHNpnsX6wYKOI+HbFgon/bpKKEcoiAlK7ahDFPeyzZcuNwFBFUbF9hx4BQGM9ZknHEiyYUthaCeb0oIlWkvhhycpzj/bzjJF7spp5rvB4mz1XTZV5kuOxugcIFweFon80SaMowtJxWP0jWLAEY80k+GuGXVZQzUHWGhLfku0FshQUzLforgB0Ik1sLWHigp0fH9zdLiHHuF5GfxaKLIjEqwTxuXMxyRgq3uF+KVZK3Z2UXeBd0JTSZZtizSCUq+PRXnCMPrR46z/ZsDwtGdXwA7sG44sCB7CPuMm19RXce1kA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9Vy/VFEGtj8IDQ+1gR1ei3pZx5PDRFkDPcOkU2TgS/A=; b=jNBLaRCb9Lzb0QYrqBZW/EoSrlRvYhO7n8gnG6KcRC8KdJTH/fssRkifY+9eIkfOzvWrUN8NmU639aM1iRq/D6zQDWw9dOrde0pAoIQ0+GCGLETYE8FnWEv7gIAL03mmoRG9XXLPark0tLFEQSf35uOPko5hD66qqt5j1W5Ce3oR2Jc6mFiWVXowoZ6DhvRad99yVsbxWJwlcHMKZM1XqB2bGSNe8GQnxLj3ibYtz0T7H/UrUwYM/2IcMRv5K8McmEHDY+ZgZ7Cf82/xQc4QSRzJmcLz+Z56Ral1mkB+XwAVy1ncEX1aCqummXEOWJN777JiC6+fLuAyzPoZrSU5gw== 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=9Vy/VFEGtj8IDQ+1gR1ei3pZx5PDRFkDPcOkU2TgS/A=; b=VpGYW72ANVVhGV9RJ96cX3EaMcEGr//EP4XVMdcsbaHXT0FJ8MqiE/MOI15/mz3Imk/NFXN9Phe/kJKBGipyJzOFdysBiusLHHKvTkE279MlzWPehhS3q+1DjjYg/kTTG6nLVSiUR0wc9R2rBlyPKZGX7nYbaQAwNv/a8AVUpUA= Received: from DM6PR11MB3803.namprd11.prod.outlook.com (2603:10b6:5:141::30) by DM5PR11MB2010.namprd11.prod.outlook.com (2603:10b6:3:12::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.29; Wed, 25 Nov 2020 02:14:52 +0000 Received: from DM6PR11MB3803.namprd11.prod.outlook.com ([fe80::51a2:6f3b:817c:8dc8]) by DM6PR11MB3803.namprd11.prod.outlook.com ([fe80::51a2:6f3b:817c:8dc8%6]) with mapi id 15.20.3611.021; Wed, 25 Nov 2020 02:14:52 +0000 From: "Huimin She (hushe)" To: "roll@ietf.org" Thread-Topic: [Roll] IETF 109 open Questions on P-DAO Thread-Index: AQHWwtDCJQPNj8lETkK/af1PwLwXBA== Date: Wed, 25 Nov 2020 02:14:52 +0000 Message-ID: <2C3A2B54-0B51-4533-A3C4-D4FE042C637A@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [64.104.125.228] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e5019ed5-79d8-414f-672c-08d890e7e4be x-ms-traffictypediagnostic: DM5PR11MB2010: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Hq7Idc09H9EAjd/7FD6vKJdz0pu6YE7OEgmCcDCWFBh7SsaPjCmoGOevMA2HghJrmdwf0Sb4qUbsaD4fjByzOEcXCjswdTnEisrGCxN1cNzcaDhZ1rUm7hPWQuyc58NERy0XSyCct67j4io0wDmv53s0e19sgBVNnJt8SRpXsv30l6mupdAusRmYF9tGhUc/3wYbrpjwjyVfe/pdSSxeAcoVqdGalEzs9EghUW8knXLcjt2/ElWo7kzM931oqAsXTQPYCXekhL0K+0YLtwkuY1voEyJD4eNLLC03hixrV7DC99VbHsEPuAEVvHc9wHPfFNtXmTlhOY7kysil7QPYQW2dWMNG/xqke2CwQSekqwz5WkmROEm4g2dQNbLomyahjWxaAjlJcR9HRKfx8l6qcA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB3803.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(396003)(346002)(39860400002)(136003)(376002)(6486002)(36756003)(186003)(5660300002)(83380400001)(966005)(6506007)(33656002)(478600001)(53546011)(86362001)(26005)(316002)(8676002)(71200400001)(2616005)(76116006)(8936002)(66946007)(66556008)(66446008)(64756008)(66476007)(6512007)(91956017)(2906002)(6916009); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: BedQX2jVBBfLLZAOaJkcfVtCirr/S6kQ4NwcLZgNpXFd2Vb0WFwQ6/MDS8VxZJNZJ0VKaJxEjec/ZzgpXzppE/sMmGEZh2Mi66b6RbTzRXQB+qRt1BnUfsP3mZfdNcIMjr6hAjh+s/QIxjh6RMrkfpuZxh0G06qLJcZCGCp1ZmmBfy3OFMKh6HZ0sOqQpwDF9mwk5gsbCx1HlHFjj3XaNY52iiNqTypmuACHiBfuOoXMWpbS9p3Rk0qcVZZar9EFDt70FC9cSYm3o70xJlnjzqTck6mmpKth1u74qT3EbPoiC9/xaJzGFU61OXddRLwhJIV/7M/iF7llXXLFlqJU43rdqxR1nd2PsOaCLz0bcN0IqoefhH9m1nNswkLEiIVgyhbd7WQlnFMmp+rSe1tYwGZpxTq+lD060dbMCWg3L8cAn90+deZbj5F+OWlwv5kAdCHzZHbtxTORedWSHK/D2KpKIsQ29ZmBqkvZ4Ry+7UoCD/n/8oSowwqyGupVHEMQnXU2WIecRe+rdsHwW4qqW9FWbMkCsIJAwaVmVbZaatheFn9pgTjLGFEBMnQww8SGmJFl2zZwrL5g+Ngl6oZzpK3nryqFXR7JiyUNgW/uMgkZ+VobyKodciMpgNPg4HjW5zb29s3C9wq6JnXdgDOBCra/bFi8UtzPAyNMfAtkT+62/WotyAWa1ZzAggdSV5dTcRRV8wD+ux3o+M3SUtLXe97L6W9Z8Z04tyy3cFEmwEjfkcGSghC356daDkaDFI/xrd2fAnJww2kDd8CeWa9GneuoNjfCcFyxMXHZ/jpcD07wN8UUQsHfc9+O2tBBLUmtHNvAlrfaQxkAJSiA8MO2c3/CPQ9EOjQV4IuboC0dk7F08ozaRzHfX8R11SqACMaebbd7SeoX2I+MPm/KUojFSg== x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <018F9CEE7C5F9143A30E54728AA103DF@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB3803.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: e5019ed5-79d8-414f-672c-08d890e7e4be X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Nov 2020 02:14:52.2054 (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: a+6M/vZvD2xGg+VHWjW68MVpl0UxCs2nSsUQ0Abgsu+4sD4uOrHuDIytPkoXAEjk X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR11MB2010 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: alln-core-10.cisco.com Archived-At: Subject: Re: [Roll] IETF 109 open Questions on P-DAO 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, 25 Nov 2020 02:14:57 -0000 VGhhbmsgeW91LCBQYXNjYWwuDQoNCkkgaGF2ZSBhIGZldyBtb3JlIHF1ZXN0aW9ucyBhcyBmb2xs b3dpbmcuDQoNCjEuIEhvdyBkb2VzIHRoZSBlZ3Jlc3Mga25vdyB0aGF0IGEgbG9jYWwgUlBMIGlu c3RhbmNlIGlzIGFzc29jaWF0ZWQgd2l0aCBpdD8gRm9yIGV4YW1wbGUsIGluIG5vbi1zdG9yaW5n IG1vZGUsIHRoZSBQLURBTyBtZXNzYWdlIGlzIHNlbnQgdG8gdGhlIGluZ3Jlc3MuDQoNCjIuIEEg bG9jYWwgUlBMIGluc3RhbmNlIGlzIHJvb3RlZCBhdCB0aGUgZWdyZXNzLiBJbiBmYWN0LCBpdCBp cyBub3QgYSBub3JtYWwgUlBMIHNpbmNlIHRoZXJlIGlzIG5vIFJQTCBtYWludGFpbmluZyBtZXNz YWdlcyBzdWNoIGFzOiBESU8sIE5TLCBEQU8gZXRjLg0KDQoNCkJlc3QgcmVnYXJkcywNCkh1aW1p biANCg0KICAgIERhdGU6IFR1ZSwgMjQgTm92IDIwMjAgMTM6MjI6MDQgKzAwMDANCiAgICBGcm9t OiAiUGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0KSIgPHB0aHViZXJ0QGNpc2NvLmNvbT4NCiAgICBU bzogUm91dGluZyBPdmVyIExvdyBwb3dlciBhbmQgTG9zc3kgbmV0d29ya3MgPHJvbGxAaWV0Zi5v cmc+DQogICAgU3ViamVjdDogW1JvbGxdIElFVEYgMTA5IG9wZW4gUXVlc3Rpb25zIG9uIFAtREFP DQogICAgTWVzc2FnZS1JRDoNCiAgICAJPENPMVBSMTFNQjQ4ODFCMzQ4QjRBMjI0REJBRUU1QkE3 NEQ4RkIwQENPMVBSMTFNQjQ4ODEubmFtcHJkMTEucHJvZC5vdXRsb29rLmNvbT4NCg0KICAgIENv bnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD0idXMtYXNjaWkiDQoNCiAgICBEZWFyIGFs bA0KDQogICAgVGhlIHNsaWRlcyBmb3IgdGhlIFAtREFPIGRpc2N1c3Npb24gYXQgSUVURiAxMDkg YXJlIGF2YWlsYWJsZSBoZXJlOg0KDQogICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9k b2Mvc2xpZGVzLTEwOS1yb2xsLWRhby1wcm9qZWN0aW9uLw0KDQogICAgVGhlcmUgYXJlIGEgbnVt YmVyIG9mIG9wZW4gcXVlc3Rpb25zIHRoYXQgd2Ugc3RhcnRpbmcgZGlzY3Vzc2luZywgYW5kIHdv dWxkIG5lZWQgdG8gcHJvZ3Jlc3Mgb24gdGhlIGxpc3QuDQogICAgU29tZSBvZiB0aGVtIHdlcmUg ZXhwcmVzc2VkIG9uIHRoZSBsaXN0LCBlLmcuLCBmcm9tIEh1aW1pbiBTaGUuIEknZCBsaWtlIHRv IHByb2dyZXNzIG9uIHRoZW0gYWxsIHdpdGggaW5kaXZpZHVhbCB0aHJlYWRzLg0KICAgIFRoZSBx dWVzdGlvbnMgYXJlOg0KDQoNCiAgICAgIDEuICBMaWZldGltZSBVbml0OiBjb3VsZCB3ZSB1c2Ug YSBkaWZmZXJlbnQgdW5pdCBmb3IgUC1EQU8/DQogICAgICAyLiAgSG93IHRvIGRpZmZlcmVudGlh dGUgYSBQLURBTyBmcm9tIGEgbm9ybWFsIERBTyBpbiBhIGxvY2FsIGluc3RhbmNlOyBuZXcgZmxh Zz8NCiAgICAgIDMuICBNYWtlIFAtREFPIGJpZGlyZWN0aW9uYWw/DQogICAgICA0LiAgV2hvIHNl bmRzIHRoZSBQRFI/IERvZXMgaXQgaGF2ZSB0byBiZSB0aGUgaW5ncmVzcz8gSWYgaXQgd2FzIGVn cmVzcyBpdCBjb3VsZCBwcm9wb3NlIGEgVHJhY2tJZCBmcm9tIGl0cyBuYW1lc3BhY2UuIEVsc2Ug Y291bGQgdGhlIGluZ3Jlc3MgYmUgdGhlIHJvb3Q/DQogICAgICA1LiAgTWFpbnRhaW5pbmcgdGhl IHNpYmxpbmcgc3RhdGUuIFNob3VsZCB3ZSBoYXZlIHRleHQgb24gdXNpbmcgUkZDIDg1MDUgdGhl cmU/DQogICAgICA2LiAgV2hldGhlciBpbmdyZXNzIGFuZCBlZ3Jlc3MgYXJlIGxpc3RlZCBpbiBO UE8/IFRvZGF5IHRoZXkgYXJlIGJvdGgsIGluZ3Jlc3MgdG8gaW5kaWNhdGUgdGhlIHBhY2tldCBz b3VyY2UgaW4gY2FzZSBvZiBlbmNhcHN1bGF0aW9uIGFuZCBmb3IgU1JILTZMb1JIIGNvbXByZXNz aW9uIHJlZmVyZW5jZSBhbmQgZWdyZXNzIHRvIGJ1aWxkIHRoZSBmdWxsIFNSSC02TG9SSC4gTm90 ZSB0aGF0IHRoZSBpbmdyZXNzIG11c3QgY29uc3VtZSB0aGUgZmlyc3QgZW50cnkgYW5kIHVzZSBp dCBhcyBzb3VyY2UuDQogICAgICA3LiAgVHJhY2sgaW4gVHJhY2sgdnMuIFNSIEhlYWRlciByZWxv YWQgbW9kZWxzLCBzZWUgc2xpZGVzDQoNCiAgICBMZXQgbWUgb3BlbiB0aHJlYWRzIHRvIGZvbGxv dyB1cC4NCg0KICAgIEtlZXAgc2FmZQ0KDQogICAgUGFzY2FsDQoNCg0KICAgIA0KDQoNCg== From nobody Tue Nov 24 20:56:57 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6CF3A0D84 for ; Tue, 24 Nov 2020 20:56:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=kG9WaU11; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=XJj2C8Om 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 dUrrG0DxeBoh for ; Tue, 24 Nov 2020 20:56:53 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21ED83A0994 for ; Tue, 24 Nov 2020 20:56:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15854; q=dns/txt; s=iport; t=1606280213; x=1607489813; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=uDPNNmvomyXH5pWIcWFULKxPfneSY9GGaMX9C/ERBVo=; b=kG9WaU113ETkQzDG6JbIwD3+omNEtJO0f0HAFPQTx9lkstTnaSCJb0n6 Cn0n+8eYHV8E/SFhLBUdU0/j2fA8Cox+i3inP1oMegZu46C89d/ccnMY7 yrnAB8v76wnCdc6HWWySe/CVLv3kKmnang0flMLZ2zlhSaUg+VB18ipO7 s=; X-IPAS-Result: =?us-ascii?q?A0DZCAC4471ffZxdJa1igQmCci9Re1kvLogGA41fkH6DF?= =?us-ascii?q?oRwgUKBEQNUCwEBAQ0BASMKAgQBAYRKAoIsAiU4EwIDAQEBAwIDAQEBAQUBA?= =?us-ascii?q?QECAQYEFAEBhjwMhXIBAQEEEi4BASUTDwIBCBEBAgEBAR4RMhcGCAEBBBMIG?= =?us-ascii?q?oMFgX5XAy4BDqMNAoE8iGh0gTSDBAEBBYE3BAxBgzEYghADBoE4gnOCZk6HG?= =?us-ascii?q?YIbgRBEgVFQLj6BBIFZAgMBgSEcIB4GB4MdgiyBRgGPNYoXnToGBIJuiRSJX?= =?us-ascii?q?IhSgxqKGZRTnmGRJ4Q4AgQCBAUCDgEBBYFrIYFZcFCBHoFLUBcCDZIQhRSFR?= =?us-ascii?q?HQ3AgYKAQEDCXyMTS2CFwEB?= IronPort-PHdr: =?us-ascii?q?9a23=3AjBPUPBBmGuN1v4QO5o36UyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qw01g3IUJnVrfVehLmev6PhXDkG5pCM+DAHfYdXXh?= =?us-ascii?q?AIwcMRg0Q7AcGDBEG6SZyibyEzEMlYElMw+Xa9PBtUFdrwIVrIrS764TsbAB?= =?us-ascii?q?6qMw1zK6z8EZLTiMLi0ee09tXTbgxEiSD7b6l1KUC9rB7asY8dho4xJw=3D=?= =?us-ascii?q?3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,368,1599523200"; d="scan'208,217";a="636629272" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Nov 2020 04:56:51 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AP4upB5013374 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 25 Nov 2020 04:56:51 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 24 Nov 2020 22:56:50 -0600 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 24 Nov 2020 23:56:49 -0500 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 24 Nov 2020 22:56:49 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aCv4R4JYbAsD5Fk56R172sX/kEC4UkgU4vOgWSMV1Km1AAJxy33bMgzOm5iNhIi/qntbusPojOqxpwPfTVZsmokWNSQJEn6ZYSMdoSUWpmjRjpfnfnFhip3IUYkSSbJpX1RoiXU9S5SEHAV5rCnJYv72GYJVQTYh7gJnyIzr4mvGkO5ZLkbo5rS5hL6gNMnlWeYhGuTi8fu76yIXad/0FdNBHTtq5n0l9Tb3lGnqraMmOm8u8xsUHDqbnoKoS0s56tkPFpkSgMAjOSIkBPHMAl1+/fu6xZwEB8xYpC8dn5hae5besNP/0aaVtSJroDuCBpxsh0WZAWLHjCy69SUChg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JfoQvThGjwyvh1RVXItubu7TOJi93w2PohwXXexzeSs=; b=lIFl1N0/FBgdwMTZvEYRSPS5TIecFYpoqrTYswGQiioTp61uMfrW+ut8V6JeFKsUrbLxVwPHjp375mliJmkHfUuN+NJAlSOl1yuJDgHSAwZR/OiR0Un7hnpnbx7sxbenuBcMqqc0G+zV67TQF/P6Cazjb9CmI+s2jPrg0XeMsGBDrjIAVzO+q+m8gTeGLKzLQHZQRR2dH2Pf3xjMffWFmTqj8FQ/MkuKYknpLn2X6iRrwBZDc1AWWbI+CtNYrgEZE7/VT6QUik0aY0Yf3NV/G9IGuAHm9fSWuMqE9Awy7mDAaMVdMmIwgS35MxXI53Fr+uxy3QQt0j+4GCjk0APuhg== 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=JfoQvThGjwyvh1RVXItubu7TOJi93w2PohwXXexzeSs=; b=XJj2C8Omb3RSDoKAY/nTn7d8rfJr5wF6He3fq5eNHmFS/pk7RGRKB8MTNJa4h6LPOlyaRAhsijC5iQ0LGDh/FOGaww9az/CB8dEKDffttLpR+OQ3UZw7Pv8GL3pEhqiTxSKvOjryVI2IC5xstqSisdZ9pia0cjdlrZVvU/DhIfA= Received: from MWHPR11MB1742.namprd11.prod.outlook.com (2603:10b6:300:113::13) by CO1PR11MB4978.namprd11.prod.outlook.com (2603:10b6:303:91::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.20; Wed, 25 Nov 2020 04:56:49 +0000 Received: from MWHPR11MB1742.namprd11.prod.outlook.com ([fe80::5819:88b4:cdaf:610a]) by MWHPR11MB1742.namprd11.prod.outlook.com ([fe80::5819:88b4:cdaf:610a%9]) with mapi id 15.20.3589.030; Wed, 25 Nov 2020 04:56:48 +0000 From: "Li Zhao (liz3)" To: Routing Over Low power and Lossy networks Thread-Topic: Make P-DAO bidirectional [extends] IETF 109 open Questions on P-DAO Thread-Index: AdbCZRGxaZJsqD20SLuISSoVqF9MEgAgkqIO Date: Wed, 25 Nov 2020 04:56:48 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2001:420:588c:1252:ed42:30ae:45fa:1f11] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c33cd4b6-6169-4422-0017-08d890fe845e x-ms-traffictypediagnostic: CO1PR11MB4978: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: dVB80S3acI12YIUDrWbmTrCR9UCtZfLWIExrLaHEA2db92J2z4tOhQV8y/Ela/PC/B6TxisnoWCbiI4q7FX+83ML/d6Rwx6zeMTq+VOVInAtt2QC13ou7lTkrGI4dVEv+xaYirOY7lu5La0KJZ80mBJx92/8vqJbMeWhZ2t/qFxF0rK1L7+IXwm46FnFbq/wY/lkY4d+1LX2GwwoxwzvjnosTw4M7rWW00wngjL8czBJ9EwWRzKBymbLhV+tFX52hLzA6c9NasLfCl738QooBYROHmaPelrgzmIZbExfN7xMLFBpvON7ceYr8sNIm/oNfEDWzcLeUAJaBVn3nXkFOS8Uv6m35vmHdElyc0ox3muoU0dgYCz42crk0M6hxZKMIwTD7FH2ydMfbZ5D8JqSIskz2Tk3vK8Gzco5XQPomqb3Rrzwn/nwfuoJFhI7ro5M5s61Pj0/xlOMU8QZHI3Ruw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MWHPR11MB1742.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(39860400002)(376002)(346002)(366004)(396003)(7696005)(5660300002)(53546011)(186003)(478600001)(83380400001)(2906002)(66556008)(52536014)(6506007)(76116006)(316002)(33656002)(71200400001)(86362001)(55016002)(166002)(66446008)(6916009)(9686003)(64756008)(8936002)(66476007)(66946007)(8676002)(91956017)(966005)(88722002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?Windows-1252?Q?6sdhBBJrv78TjvihIYiwPDDZJvuMljGOANcUYJfu4tVtD0x53VK5GYxX?= =?Windows-1252?Q?Xf9+RB7Im+1A9LU0tVK9iUv287jCRN4G61wTvw6ewNTkwtL9lOeQ48n/?= =?Windows-1252?Q?5pwsAinSgE3xuItOVWJSaAx2E9ZeKp471icPphBnjnB3lhUX0VgwcmHZ?= =?Windows-1252?Q?fOlKQ58SyaqIweqGHL5l39ik0LmBguVsF46aq3z0zuWV2iavLZ3KvzWb?= =?Windows-1252?Q?NI98DTUQYKjcIXsBmhGdOu9yiRrhgK0Bl87CV+9dYIsRmmGQjCek0Idp?= =?Windows-1252?Q?pMX4Y2vYbFtJK7RRwLSjluEhcn3aUvMp3xgIcFsv/3djhSBWh03xTHCa?= =?Windows-1252?Q?HO3PQaPbcDyB2w2VoOax6V4fkdP4kHWc398Np+qooUE7GdBU5RMiAYOV?= =?Windows-1252?Q?U94uYyXkremlrao2A7zYrEz86VSdysX/bTUVIifDiGj1ZHNHv4aeWbuf?= =?Windows-1252?Q?jM6eI8K66X63mFCh0yw1hM09zeNmqcM8YvOJtmCXqOScd80EjVgdJuch?= =?Windows-1252?Q?sQ5yNTH4ePBfQH3QWdEN44YUxLoYltRahlRehDILbAhaQUztyAMnIoHY?= =?Windows-1252?Q?IEuPsieJm7sWE/DaGGGeFFhdAxjcoTgC1HqI4PESIYurPPZcs7nb/fB/?= =?Windows-1252?Q?LnxRNouSPkEcJkxwnEjC1JxcXHoQDv8SIRikFzpFDd/pnv1YScD7+C3U?= =?Windows-1252?Q?Y5pexy+Y82CY2PBDGSRigHm43tKYtjHg+HmkyXUlFpSG8zcJufxnLqh7?= =?Windows-1252?Q?wKcD3gsp7Qit6wQPKiTQKEuWnniuL1/JYCU3vEjFSuS7LSycv9MSvlYX?= =?Windows-1252?Q?9X6BC0Vjuc4qIQAiK/KczQmDvaGXkPRyxVGUjiu1Y+rHwTo1+MlkLVfN?= =?Windows-1252?Q?1GwfpPmkQMll8/8n71Oa0VohmK/S8r0D1xjRxun5/LD2UVsZkEzxC8kz?= =?Windows-1252?Q?/oRNK7G0z/QVt0Jsfz2iIKzCDZvs0oSk1pN4CR2iYWQ839HMn90TjW5v?= =?Windows-1252?Q?hdh1+R+pNvI/4oSJfHqaftdemxdYvjLiIvDU627tiEf/XLR0lGRCeTx+?= =?Windows-1252?Q?NH+ArQ5jk2ClhoASat85zEDlTIOooK9Kt5JEVqxxkIIPyWP7ljVNfa0i?= =?Windows-1252?Q?oxTeYPYJSbXnO4u6nWIV7qn/gTmxkSNrAqteTy7mXWNzag=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MWHPR11MB17424F37A16E1B048096B1428CFA0MWHPR11MB1742namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MWHPR11MB1742.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: c33cd4b6-6169-4422-0017-08d890fe845e X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Nov 2020 04:56:48.8511 (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: JPJh5QrTLvajG/ls3XQmb4Daum9vVhMpWKmnmcRxtZQT+5uJM/WhzGVtV1MhzDuZ X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR11MB4978 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questions on P-DAO 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, 25 Nov 2020 04:56:56 -0000 --_000_MWHPR11MB17424F37A16E1B048096B1428CFA0MWHPR11MB1742namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello Pascal, Ingress as Root looks better because 1. It is consistent with the way RPL usually works. RPL Local instance, ao= dv-rpl, p2p-rpl all use ingress as root. 2. For non-storing-mode P-DAO, currently ingress sends upward traffic to e= gress(root) with SR header. But in RPL, only downward traffic carries SR he= ader. 3. Only ingress can send PDR makes sense. Behavior of TrackId is similar a= s Local Instance ID. Ingress as root can propose TrackId from its namespace= . And for storing-mode P-DAO, if we make ingress as root and ingress sends PD= R, can PCE send P-DAO to egress then egress forwards it towards predecessor= to ingress? Maybe it helps to make P-DAO looks like a DAO message. Best regards, Li From: Roll Date: Tuesday, November 24, 2020 at 21:39 To: Routing Over Low power and Lossy networks Subject: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questions = on P-DAO Dear all Whether to make the P-DAO bidirectional is an intriguing question. It could= be done, just like we can send packets DOWN a classical DODAG. But if we take that path, we reopen the question of who is root and which d= irection the P-DAO flies. Could we make either the ingress OR the egress root? How does it matter? At the moment the Root is the egress and the storing-mode P-DAO flies from = the Track egress to the track ingress, and the track egress is the root. Th= is is not the way RPL usually works as the DAO flies towards the root. The = reason was that we wanted a single egress for the Track, as we build unicas= t Track. If we wanted to build multicast Tracks the root should logically b= e the ingress. And for bidirectional Tracks it could be either. Up to -24 the 6TiSCH Architecture expected the ingress to be root. I change= d in the latest to map we do here, that it is the egress; maybe a flag in t= he DAO would indicate which direction the flow, from root, to root, or both= ? Also if we build bidir Tracks in storing mode, the nodes that forward the D= AO will have to build routes in both directions based on the P-DAO, both to= wards egress and ingress; but only the path from which the P-DAO comes has = been validated by the P-DAO itself. Should we send a P-DAO to each end, eac= h setting up one way? Please let me know your thoughts Pascal From: Roll On Behalf Of Pascal Thubert (pthubert) Sent: mardi 24 novembre 2020 14:22 To: Routing Over Low power and Lossy networks Subject: [Roll] IETF 109 open Questions on P-DAO Dear all The slides for the P-DAO discussion at IETF 109 are available here: https://datatracker.ietf.org/doc/slides-109-roll-dao-projection/ There are a number of open questions that we starting discussing, and would= need to progress on the list. Some of them were expressed on the list, e.g., from Huimin She. I=92d like = to progress on them all with individual threads. The questions are: 1. Lifetime Unit: could we use a different unit for P-DAO? 2. How to differentiate a P-DAO from a normal DAO in a local instance; n= ew flag? 3. Make P-DAO bidirectional? 4. Who sends the PDR? Does it have to be the ingress? If it was egress i= t could propose a TrackId from its namespace. Else could the ingress be the= root? 5. Maintaining the sibling state. Should we have text on using RFC 8505 = there? 6. Whether ingress and egress are listed in NPO? Today they are both, in= gress to indicate the packet source in case of encapsulation and for SRH-6L= oRH compression reference and egress to build the full SRH-6LoRH. Note that= the ingress must consume the first entry and use it as source. 7. Track in Track vs. SR Header reload models, see slides Let me open threads to follow up. Keep safe Pascal --_000_MWHPR11MB17424F37A16E1B048096B1428CFA0MWHPR11MB1742namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hello Pascal,=

 

Ingress as Root looks better be= cause

1.  It is consistent with = the way RPL usually works. RPL Local instance, = aodv-rpl, p2p-rpl all use ingress as root.

2.  For non-storing-mode P= -DAO, currently ingress sends upward traffic to egress(root) with SR header= . But in RPL, only downward traffic carries SR header.

3.  Only ingress can = send PDR makes sense. Behavior of TrackId is similar as Local Instance ID. Ingress as root can propose TrackId from its namespace.

 

 

And for storing-mode P-DAO, if = we make ingress as root and ingress sends PDR, can PCE send P-DAO to egress= then egress forwards it towards predecessor to ingress?

Maybe it helps to make P-DAO lo= oks like a DAO message.

 

 

Best regards,=

Li

 

 

From: Roll <roll-bounc= es@ietf.org>
Date: Tuesday, November 24, 2020 at 21:39
To: Routing Over Low power and Lossy networks <roll@ietf.org><= br> Subject: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Que= stions on P-DAO

Dear all

 

Whether to make the P-DAO bidirectional is an intrig= uing question. It could be done, just like we can send packets DOWN a class= ical DODAG.

But if we take that path, we reopen the question of = who is root and which direction the P-DAO flies.

 

Could we make either the ingress OR the egress root?= How does it matter?

 

At the moment the Root is the egress and the storing= -mode P-DAO flies from the Track egress to the track ingress, and the track= egress is the root. This is not the way RPL usually works as the DAO flies= towards the root. The reason was that we wanted a single egress for the Track, as we build unicast Track. I= f we wanted to build multicast Tracks the root should logically be the ingr= ess. And for bidirectional Tracks it could be either.

 

Up to -24 the 6TiSCH Architecture expected the ingre= ss to be root. I changed in the latest to map we do here, that it is the eg= ress; maybe a flag in the DAO would indicate which direction the flow, from= root, to root, or both?

 

Also if we build bidir Tracks in storing mode, the n= odes that forward the DAO will have to build routes in both directions base= d on the P-DAO, both towards egress and ingress; but only the path from whi= ch the P-DAO comes has been validated by the P-DAO itself. Should we send a P-DAO to each end, each setting up o= ne way?

 

Please let me know your thoughts

 

Pascal

 

 

From: Roll <roll-bounces@ietf.org> O= n Behalf Of Pascal Thubert (pthubert)
Sent: mardi 24 novembre 2020 14:22
To: Routing Over Low power and Lossy networks <roll@ietf.org><= br> Subject: [Roll] IETF 109 open Questions on P-DAO

 

Dear all

 

The slides for the P-DAO discussion at IETF 109 are = available here:

 

https://datatracker.ietf.org/doc/slides-109-roll-d= ao-projection/

 

There are a number of open questions that we startin= g discussing, and would need to progress on the list.

Some of them were expressed on the list, e.g., from = Huimin She. I=92d like to progress on them all with individual threads.

The questions are:

 

  1. Lifetime Unit: could we use a different unit for P-DAO?
  2. How to differentiate a P-DAO from a normal DAO in a local instance;= new flag?
  3. Make P-DAO bidirectional?
    4. Who sends the PDR? Does it have to be the ingress? If it was egress it = could propose a TrackId from its namespace. Else could the ingress be the r= oot?
  4. Maintaining the sibling state. Should we have tex= t on using RFC 8505 there?
  5. Whether ingress and egress = are listed in NPO? Today they are both, ingress to indicate the packet sour= ce in case of encapsulation and for SRH-6LoRH compression reference and egr= ess to build the full SRH-6LoRH. Note that the ingress must consume the first = entry and use it as source.
  6. Track in Track vs. SR Head= er reload models, see slides

 

Let me open threads to follow up.

 

Keep safe

 

Pascal

 

 

--_000_MWHPR11MB17424F37A16E1B048096B1428CFA0MWHPR11MB1742namp_-- From nobody Wed Nov 25 01:28:27 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E77F13A1312 for ; Wed, 25 Nov 2020 01:28:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.62 X-Spam-Level: X-Spam-Status: No, score=-9.62 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.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=QYrx7jWj; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=zARuEd9P 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 7PNbMowpvCK3 for ; Wed, 25 Nov 2020 01:28:23 -0800 (PST) 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 E3F943A1311 for ; Wed, 25 Nov 2020 01:28:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3411; q=dns/txt; s=iport; t=1606296502; x=1607506102; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ktSnF6WKV4mEu7GulHU6BNngvHFI5s6Uv9vhG1rj34M=; b=QYrx7jWjX/9SmSNxfdiBBzVOi+MT413vi1HlgEpj1DunOdWOJYbvVbui WC5m5albqAfKnhGkEXazrvTsyNymK95Z5ra8lLOBqg6toVDkFfOmHIUrP 8sfiJpK7S3anFmstWOI0nt+pjW1jV+j3S02X9Y1eAlR5XV72swHJLriCv 4=; X-IPAS-Result: =?us-ascii?q?A0DiCABXIb5ffYENJK1igQmDIVF7WS8uCod8A41hmQWBQ?= =?us-ascii?q?oERA1QLAQEBDQEBGAsKAgQBAYFsAYJdAoIvAiU4EwIDAQEBAwIDAQEBAQUBA?= =?us-ascii?q?QECAQYEFAEBhjwMhXIBAQEBAgEBARAoBgEBLAwECwIBCBECAQECHxAnCx0IA?= =?us-ascii?q?gQTCBqCfwQCglUDDiABDqMPAoE8iGh0gTSDBAEBBYE3BAxBgzADFYIQCYE4g?= =?us-ascii?q?nOCZk6HGRuBQT+BEESCIS4+gQSBWQEBAwGBIRwgBR+DJIIskHynWQqCbokVk?= =?us-ascii?q?jCiDJ5mkSiEOQIEAgQFAg4BAQWBayEPgUpwFTuCaQlHFwINkhCFFIVEdAIBN?= =?us-ascii?q?AIGCgEBAwl8jWgBgRABAQ?= IronPort-PHdr: =?us-ascii?q?9a23=3AY2S3txD3QSUHGJVjypIlUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qw01g3IUJnVrfVehLmev6PhXDkG5pCM+DAHfYdXXh?= =?us-ascii?q?AIwcMRg0Q7AcGDBEG6SZyibyEzEMlYElMw+Xa9PBtUFdrwIVrIrS764TsbAB?= =?us-ascii?q?6qMw1zK6z8EZLTiMLi0ee09tXTbgxEiSD7b6l1KUC9rB7asY8dho4xJw=3D=?= =?us-ascii?q?3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,368,1599523200"; d="scan'208";a="615138045" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Nov 2020 09:28:21 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AP9SLE3028140 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 25 Nov 2020 09:28:21 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 25 Nov 2020 03:28:21 -0600 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 25 Nov 2020 03:28:20 -0600 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 25 Nov 2020 03:28:20 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BAEzrwBRkBbK3sZj/5BgXkB82rV8TiONFOJVeqBGGS0K+nlqRugoUaytgvciFak+pj+RmRFL600H3OEXhr0EUwz5gOhyG+r3N5HTja0rLfsq5y9EqAhlLrzFLk9DIJ998NE1T+qH8KxIpsK8bR84jZ9We1vUHP9JDI9p6nB3fpzJX+CszZCKyL9Y0HcY8ieYpHBrHFk5i/3smNCmXxzNFMuvBh+5Pcv4FV3gyPJF3iCfDTruhmZgjSKeQks9nQrRJUdR3aDcVazUOrj3NvkVEB9PmT/UPXBqtLiHcS7VyIj2jG/Zmgu4yX9zNlbnGR/77EEJOHPbr/z22/Rkxh1H+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-SenderADCheck; bh=tWxXdiroYI8+M05f5+iM0UbJq/WKJzvqgGyscs3tUcc=; b=R5f8mKBQe4MxL2bSjHJeYZ/nFN2MlxC+LBpqxBDlE8TrGo4SMngSm8ov1LUrQPF7YND2zQDVhgDjjx3uWs4OUzRrx1PKNbhdYJr2i37nZOpjyaN8YOjYelLye0OA87YasQxkyE4ORFhdbeaPyuV8ah57Vs2ALHxQWC75e8T50fxek534SE5d/Xz/N4aYnd0Eug5hFc290AexlOd3sGowE7VJWZottf7rj+e+6TgjiSG9Pz5v7VX2KAb8SJJ1lfztfm6iDSY4XojoQjseABXyEBwbP34nBz8JoDzFnA3E0zOqE+fgyw8f9vD3k7g1CCcMYTA6JnNNgbU9+mga1pO4Pw== 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=tWxXdiroYI8+M05f5+iM0UbJq/WKJzvqgGyscs3tUcc=; b=zARuEd9PJsRMHi/AX1OZc2GOnvYwSoC0ktwXrojxM3n352l6LZMedQ8S8Lgu7jsjY/RgOtaxC4K3u712tYlMx7K4LFZuNKxWkZbevvvOPRxlkpJJu/A3O0ByxTQAhp9dSi5UEOf6YdEoS5XmezRb1Y6LHNmvoZr0qn+DsH59QLg= Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by CO1PR11MB4865.namprd11.prod.outlook.com (2603:10b6:303:9c::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.20; Wed, 25 Nov 2020 09:28:18 +0000 Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::fc25:3e72:3e83:7df6]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::fc25:3e72:3e83:7df6%4]) with mapi id 15.20.3564.025; Wed, 25 Nov 2020 09:28:18 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] IETF 109 open Questions on P-DAO Thread-Index: AQHWwtDCJQPNj8lETkK/af1PwLwXBKnYeLig Date: Wed, 25 Nov 2020 09:27:55 +0000 Deferred-Delivery: Wed, 25 Nov 2020 09:27:31 +0000 Message-ID: References: <2C3A2B54-0B51-4533-A3C4-D4FE042C637A@cisco.com> In-Reply-To: <2C3A2B54-0B51-4533-A3C4-D4FE042C637A@cisco.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.220.42] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d06d8d93-655b-4752-da05-08d8912471c3 x-ms-traffictypediagnostic: CO1PR11MB4865: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: YFOBgN5Mm3AAb5RSz5B4hAIja6VY9AszXODJPEz7pqScYP8gEx6Eef5z6U3wyATXPJQsy8mKcn77MJvcr1E/9AQ8lLsX37TXzpKgCS1S3S0lVq/77g1B0lU2WkTvrMYCgqv1RJzvZGbBn/EzTw+QQvuG4r88MOFmVw9Aqx7BK0eykULtNTqgw5sQSXQWhC4AH/ccH3Sgha5B7hqtNQvmfuvud03jf+vBwbjJv7TXWIt5d7jfMSurS5fnCzenW5XQbuwUSLhVgOJiQZvbiefHy4wS+cQfOASgxQQ/lB9+G9GTzY4MYx8C7FnI/vd87Rd9Y069C7mYdO3gcFAiIbsT2gsalvWRdlC6kmRUDAYvbHBok/kD9jge02YED0bXVWEFrAxJ3G1uosymi652n+5ozg== 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:(396003)(376002)(39860400002)(366004)(136003)(346002)(83380400001)(9686003)(66476007)(45080400002)(966005)(86362001)(2906002)(478600001)(66946007)(5660300002)(66446008)(26005)(76116006)(52536014)(66556008)(33656002)(64756008)(6666004)(8676002)(53546011)(6506007)(316002)(186003)(71200400001)(6916009)(8936002)(7696005)(55016002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?xzn21iN764d+3y3hIerMxVlDx/5/mb8BwMzh8e5AnhzsozhQ97zFeIUNOuDc?= =?us-ascii?Q?Mx2M5Nb9iAz36WrYEjyL52bvDC5OZspzmt8WFTHM9x7WQWD2PyAKDqp1ndho?= =?us-ascii?Q?+BujhaS7s42ouP3+OvAKhdgq0tY4CYJQqaQng2FAMyvjl+Tdfb1rOAqjRGON?= =?us-ascii?Q?Q7EUYbrkhlphWm53vgI1TWDHZIxxkKrkd3C+nsmJ4at2PXQjaOT4ylm+JtCk?= =?us-ascii?Q?vsXYwJVMTvfM48qbQAf+luSPNcbYs7G+U3sF58fvHvwkzrCN+/HaSNZt7rJQ?= =?us-ascii?Q?LncEEn8PM89ZJ5uRPiYMUaIGp1Yx/NwYMVqLNmvVz+C5PUBSUAMJtvMhZMfi?= =?us-ascii?Q?vRvmLJV3gEclL2lbeRugK2NO/r2r2imRDTgmx+SidCaq9trddJVjHho5bDMi?= =?us-ascii?Q?+eFfXBZVeVj8PnT610p+nUBtIOlqT9xqUU3W30qdBT1YWgYQRdv9/WFEdxxE?= =?us-ascii?Q?yNkDSL1bDq0KmKFgaN5DasDEPG5Kr675wCs2pYajaUqDySMu8GncZYvXX7CI?= =?us-ascii?Q?8GakPjW2LmVdf59x0r4a+a95MBXCH7ffmpBsS1W/OPZYcvoYHTU5GIpCkWNc?= =?us-ascii?Q?Un4Jk+ERdOzCFuRr6gQqKMfapgGXtILIWOQIplIgqfdTS6yXz3TehS2wXPxm?= =?us-ascii?Q?Z9QxzlLg4Fj6DAdteIDkOaxTRaZfdmPudQmMjFRp6gJYjKWxYLebHI28re0l?= =?us-ascii?Q?CtlwfpFC64yiynmzK4kl3KNMSpNoMk8gPin5rm/wvv8PTRnVUDM/AaUFxzbp?= =?us-ascii?Q?bJ/MpLqxUIfdI1oOns3ipr2yXPMqtuVmUlKWUaU4bWb+Qkr4mZ7U34V+Kbb+?= =?us-ascii?Q?MU5lLv0lJzmPwIXAsiF31ocAwee5uNg6mr9patFjkYo+BSm5Erhu2wqVFfl+?= =?us-ascii?Q?OOwE6sPUSERCT3f5VA8UoEYnRGBG2HVmuGHm4L7GAs9qizUA2AuSeKcLsDdY?= =?us-ascii?Q?tLcOi9BX/bJKDQo/rVIPBm25cqnahIuyPsyuIPe14OUAp73jY29WS4GWP/qA?= =?us-ascii?Q?BzLW?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB4881.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: d06d8d93-655b-4752-da05-08d8912471c3 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Nov 2020 09:28:18.5291 (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: O+pf1w9Yn/cCFW6fNa808iv8TY3wwCy23f0D4WecqTrLLCc1DmuqzO4NcTBwoEqLpRU460npKk7PILszeUDd9w== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR11MB4865 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: Re: [Roll] IETF 109 open Questions on P-DAO 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, 25 Nov 2020 09:28:25 -0000 Hello Huimin >=20 > I have a few more questions as following. >=20 > 1. How does the egress know that a local RPL instance is associated with = it? For > example, in non-storing mode, the P-DAO message is sent to the ingress. =20 This is related to the discussion of item 4, and Li's answer to the spun of= f " Make P-DAO bidirectional [extends] IETF 109 open Questions on P-DAO" th= read. If the route is established with a PDR from the ingress and the ingress is = root then the ingress can suggest a TrackID from its pool.=20 But without a PDR, how can the root find an available TrackID?=20 - Should we have a message from the Root to get one, like a "PDR request" f= rom the root to stimulate a PDR? Or do we expect that there's always a PDR = and that the "PDR request" is an external mechanism?=20 - Or that the stimulus is an external thing? > 2. A local RPL instance is rooted at the egress. In fact, it is not a nor= mal RPL since > there is no RPL maintaining messages such as: DIO, NS, DAO etc. =20 True that there is no DIO since the Root forms the DODAG in memory so DIO i= s not needed.=20 The P-DAO is a DAO, though. If we make the ingress the Root then the storin= g mode P-DAO does pretty much what a normal DAO does, though it flies over = a constrained path as opposed to the one found by DIO. Take care, Pascal >=20 > Best regards, > Huimin >=20 > Date: Tue, 24 Nov 2020 13:22:04 +0000 > From: "Pascal Thubert (pthubert)" > To: Routing Over Low power and Lossy networks > Subject: [Roll] IETF 109 open Questions on P-DAO > Message-ID: >=20 > 1.namprd11.prod.outlook.com> >=20 > Content-Type: text/plain; charset=3D"us-ascii" >=20 > Dear all >=20 > The slides for the P-DAO discussion at IETF 109 are available here: >=20 > https://datatracker.ietf.org/doc/slides-109-roll-dao-projection/ >=20 > There are a number of open questions that we starting discussing, and= would > need to progress on the list. > Some of them were expressed on the list, e.g., from Huimin She. I'd l= ike to > progress on them all with individual threads. > The questions are: >=20 >=20 > 1. Lifetime Unit: could we use a different unit for P-DAO? > 2. How to differentiate a P-DAO from a normal DAO in a local insta= nce; new > flag? > 3. Make P-DAO bidirectional? > 4. Who sends the PDR? Does it have to be the ingress? If it was eg= ress it > could propose a TrackId from its namespace. Else could the ingress be the= root? > 5. Maintaining the sibling state. Should we have text on using RFC= 8505 > there? > 6. Whether ingress and egress are listed in NPO? Today they are bo= th, > ingress to indicate the packet source in case of encapsulation and for SR= H-6LoRH > compression reference and egress to build the full SRH-6LoRH. Note that t= he > ingress must consume the first entry and use it as source. > 7. Track in Track vs. SR Header reload models, see slides >=20 > Let me open threads to follow up. >=20 > Keep safe >=20 > Pascal >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Roll mailing list > Roll@ietf.org > https://www.ietf.org/mailman/listinfo/roll From nobody Wed Nov 25 05:53:56 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E3143A13F3 for ; Wed, 25 Nov 2020 05:53:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=YQjonS+c; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Mn+VKYkv 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 6WgNd4GadCAE for ; Wed, 25 Nov 2020 05:53:53 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 03FF53A13EC for ; Wed, 25 Nov 2020 05:53:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25294; q=dns/txt; s=iport; t=1606312433; x=1607522033; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=bD+dU7s7TKI/YY6APnXrz3D240KSXdPWzE7xLsOZelo=; b=YQjonS+cKLjCUzNvoBTLFp5piGxCf206x0dxRV9nGcwWSNAZZJ/1noI/ cuK93wvcmf9OZedPwp3PYq6xAlFoI180DMr3RUlY8H87gfVX/sDZ//V9m /Uvazh6uJfP/2MUoqUhHyFCZQ39jxKmZaCiWlruFTTwy1cWiIuse6wcPj Y=; X-IPAS-Result: =?us-ascii?q?A0D+BwDSXr5ffZldJa1igQmBT4EjAS5Re1kvLgqHfAONY?= =?us-ascii?q?JB/iAaBQoERA1QLAQEBDQEBIwoCBAEBhEoCgiQCJTcGDgIDAQEBAwIDAQEBA?= =?us-ascii?q?QUBAQECAQYEFAEBhg8IJQyFcgEBAQQSGxMBASUTDwIBCBEBAgEBASEHBzIUA?= =?us-ascii?q?wYIAQEEEwgagwWBflcDLgEOomYCgTyIaHSBNIMEAQEFgTcEDEGDIBiCEAMGg?= =?us-ascii?q?TiCc4JmTocZG4FBP4EQRIFRUC4+gQSBWQIDAYEhHCAeBgcJgxSCLJB+ihidQ?= =?us-ascii?q?gqCbokWiV+IVYMbihyUVp5mkSiEOgIEAgQFAg4BAQWBaiKBWXAVO4JpUBcCD?= =?us-ascii?q?Yd8ihSFFIVEdDcCBgoBAQMJfI0NLYEGAYEQAQE?= IronPort-PHdr: =?us-ascii?q?9a23=3AN5btXBTLw9Z7vUAvDylJxsm1Wtpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESQBN+J6v9YhazRqa+zEWAD4JPUtncEfdQMUh?= =?us-ascii?q?IekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsutZlDOrDu19zFBUh?= =?us-ascii?q?n6PBB+c+LyHIOahs+r1ue0rpvUZQgAhDe0bb5oahusqgCEvcgNiowkIaE0mR?= =?us-ascii?q?Y=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,368,1599523200"; d="scan'208,217";a="637008291" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Nov 2020 13:53:51 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 0APDrpUZ008496 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Wed, 25 Nov 2020 13:53:51 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 25 Nov 2020 07:53:51 -0600 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 25 Nov 2020 08:53:50 -0500 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 25 Nov 2020 08:53:49 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=luuFOhnZ4xC4sUBC89iPc3nIKq7xxAPqseWW+tfztmEI+l8/hluZjI1jqdGZo7Q7meTlpYMqvt58GDZceQpGbZ74X32oOx4aeEWCyzaL21/JMI03W9i//CE8Ic7iHKToRM8914gJPTLLbL9gF8wJpbFASI/3zUgRmmtq928cNqTdW20NBPhNbr0UYJANWw7eb00SXThJWAqQdV98oVsE+/y/+Y4sddz19zNWcx4tznWTrrha3e2I7oXu6d6/WvMtI9YGn0whwQIE1UPFEiAt6hhySwQGZ5V1O8lpFL4vNih5GDPbFzZWNQEjoW5XfwyInc8xBSrwxrRWg5FKeW3mrg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dOgpAB1lK9tayRHCGGAroJk+dGLM9S9YhCNt//WU0cE=; b=WXrQ+UtOut/yXlrDltSj5+2uRVIO9l2XkX90C0LdrKybYF9/LInd2S2W5c4Vhnj8cgBVueFB5+zTqvMK0nzJ9pu5RJwiK+0lBZF/PQ1KxdoCgqgJ7qLqJTcuHYfNtGg3NtiZnt+kW24PQ6XtzmzM83FSnXmI3t73Tqn4UfHsxb1/unDwGTvFY7r/1+ZAjD4Vtx9Ene8dmnOSa1NMW0efD3jW0FQNM9pz4kbRy0bKTvDH5b0bu+RxoAdQZxwA4ygbXmM3aknkYvETWYMU9MZ59YOoE8cXgvb3PItygRqDVFkhESRQp2HtzuH4vg7895bHqqZe19dqByehG8n//feRVw== 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=dOgpAB1lK9tayRHCGGAroJk+dGLM9S9YhCNt//WU0cE=; b=Mn+VKYkvRkZe680PxAwbyBRBF5eVZU/eHWz0ieMCNoeVDN6w4RT2Iry5CSUOUSnX74YPJqcxoNFsOfddRhKg0Th0HqTEywGJ+LXuHo7azOA+kKQWf8z61G4rL630092dePEmzm0yRmvK6g/S1k9Rg+spbFjt6VPKei85vFdMfLY= Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by CO1PR11MB4963.namprd11.prod.outlook.com (2603:10b6:303:91::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.20; Wed, 25 Nov 2020 13:53:48 +0000 Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::fc25:3e72:3e83:7df6]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::fc25:3e72:3e83:7df6%4]) with mapi id 15.20.3564.025; Wed, 25 Nov 2020 13:53:48 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: Make P-DAO bidirectional [extends] IETF 109 open Questions on P-DAO Thread-Index: AdbCZRGxaZJsqD20SLuISSoVqF9MEgAgkqIOABJ37jA= Date: Wed, 25 Nov 2020 13:53:36 +0000 Deferred-Delivery: Wed, 25 Nov 2020 13:52:35 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.220.42] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 76f017ac-5f13-4e59-7989-08d8914988f3 x-ms-traffictypediagnostic: CO1PR11MB4963: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: PqgVKtB+s9CiHPX1pz2c/oWoqNwJMnJhhysmNIlivxesneWgD58LsPErk8nI2jCh0d5Zqq3Rcm0KR/r6IZrbYg+TbtJ5/nDiRMkGwhK5M2qAqthLODawH4zTEUQkKWdhv8sWI+ZdPAuUhKjJcXmR1nGCZn05QJNNAuuslk681FjOudLyPEKcNqxOKWvMHtmQvROUdKmx3RvMRSBQfqhpPVGm2C5riQEmfdQAQMre7Yn1nofsAMOr8tHOuJeV7IrnQTFKJ14tp7KT68hwzOpkz4x+Bj756nyybGWM77jm23AdPEPi3V3ybvDOiV7iNhQjwj37X6S06nVLdzCNwvtOsTt3kUl9ANXnGl+/dNboYDA19lFlOJmLRKxJyoUjlVYRdQOGXzSv3g/JMTEibO02gA== 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:(376002)(136003)(39860400002)(396003)(346002)(366004)(966005)(33656002)(86362001)(316002)(64756008)(66556008)(6506007)(66476007)(8676002)(5660300002)(66946007)(66446008)(166002)(478600001)(7696005)(55016002)(53546011)(26005)(52536014)(6916009)(71200400001)(76116006)(83380400001)(186003)(8936002)(9686003)(2906002)(6666004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?N8kjC2TULg0hRU7leUr87FENNuOrWPiswwesChRF0cSQrnePMOJ1l40jGK9Q?= =?us-ascii?Q?xdlglNhziTqFDbhU1ksPMcSdHibCt+9esJVpl3E5ZReCBJNjqT1ziSE5DZC6?= =?us-ascii?Q?zrOmULLmAI0MnVt+oLiGf6s2fxjzjf2Zri6xHBl/JdqJZmVRD9HlpgmhPvc/?= =?us-ascii?Q?v8kAgSNwV9yC2dPbGYJVlkzOJphwEdYK+coaQE1s/JcgzrJT9wl9lyLgm+dT?= =?us-ascii?Q?dvh+yPKtoyf1ZyfDJz8fAkVtP2gHTi/SdFBdbA+RNHlvqq6NcNNpwJJ9iENR?= =?us-ascii?Q?4Rg6VVCDL3bXrOH8WIZVSEmwc0HV7TmGHzJ0vpSFeegbxJmQ428RmorEESIl?= =?us-ascii?Q?vJwXqEPcohZ8DMK+jHRzyhEHbfNlJpCA01zGelRGQhQxI35f+rs+SuT6Mm6f?= =?us-ascii?Q?LEJT2+t4fSfVlrRsuz5rl38u4H61YlIalsWMZKV+vCiGvxPM/bgwV/vr07FS?= =?us-ascii?Q?w/Vh9AUOhPDHyQAFJWhwVKdgSDG/xKfZy2xrouFx6mZO1y9YPwnrPAZFYYRf?= =?us-ascii?Q?cu4YClB3NWsBgykUoKB0HZqGPKPwIe87zRfnohJ6GfdQFM2C6sNHJBGgZ9LG?= =?us-ascii?Q?3N9nnwv4nZKqhMIlIOI89LYMvm6qYvzcuY6u7qO8iA23cLCv1J0IeOwt33S9?= =?us-ascii?Q?uFmexpaZ2xiGOxS5Rv87TM98zLYYpv2JoNWhWc3P3vEODbPy0B5wMy0/n/Mh?= =?us-ascii?Q?saVyqUpDndJWanuHw0KglLXSc90ZGEKgqUK2zrQadclEaQEYhNXmj1urhxfs?= =?us-ascii?Q?TIbwXy4owSZ2ith7MuuFs3n6FMOBVxQBKcy/8Q2heMa8cP+k0kUJY7ZXpIj3?= =?us-ascii?Q?DklAJVo8bN5VbRit6DTOZO3b4/17x/PUQWuYtu6l53JFSvVkm8vOC12s9uaJ?= =?us-ascii?Q?8fvrKkdJ1iY8irzLR2YPr55eXxu4WNlvAukyeeRS3wUtQ94Am79nku5tHgMM?= =?us-ascii?Q?uub0MbZF3EOGAEByD1LSrj9MBY2UzDyeu127Ku7T2x3kNvoyA+BjBHU46qOP?= =?us-ascii?Q?hOIe?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CO1PR11MB48819F71CFF279AC9BD7240DD8FA0CO1PR11MB4881namp_" 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: 76f017ac-5f13-4e59-7989-08d8914988f3 X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Nov 2020 13:53:48.7550 (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: 1g5tLg1kE73Gs5bQ1Dm+x0d5jTCKRIwIRCkUak6s6b4Zy7/twe/m0K7jElGqTuHz+xnRnhuJ+7vgCMG4qXalog== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR11MB4963 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questions on P-DAO 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, 25 Nov 2020 13:53:56 -0000 --_000_CO1PR11MB48819F71CFF279AC9BD7240DD8FA0CO1PR11MB4881namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Li; Well noted. This was the original intent. The change was made to egress bec= ause the idea was that the track could enable multiple sources to reach the= egress, like a tree rooted at the egress that flows traverse going down. B= ut the idea of a bidirectional track kinda blocks that idea and the other i= ssues like the one you point out seem to get us back to the original view. = I recently made the change from ingress to egress in the 6TiSCH architectur= e, waiting in RFC editor queue. I could reverse back, or maybe say "either = source or destination" so it can be egress or egress and we are covered for= bidirectional. What do you think? Or should a reversable Track be really a pair of tracks? Keep safe; Pascal From: Roll On Behalf Of Li Zhao (liz3) Sent: mercredi 25 novembre 2020 05:57 To: Routing Over Low power and Lossy networks Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questi= ons on P-DAO Hello Pascal, Ingress as Root looks better because 1. It is consistent with the way RPL usually works. RPL Local instance, ao= dv-rpl, p2p-rpl all use ingress as root. 2. For non-storing-mode P-DAO, currently ingress sends upward traffic to e= gress(root) with SR header. But in RPL, only downward traffic carries SR he= ader. 3. Only ingress can send PDR makes sense. Behavior of TrackId is similar a= s Local Instance ID. Ingress as root can propose TrackId from its namespace= . And for storing-mode P-DAO, if we make ingress as root and ingress sends PD= R, can PCE send P-DAO to egress then egress forwards it towards predecessor= to ingress? Maybe it helps to make P-DAO looks like a DAO message. Best regards, Li From: Roll > Date: Tuesday, November 24, 2020 at 21:39 To: Routing Over Low power and Lossy networks > Subject: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questions = on P-DAO Dear all Whether to make the P-DAO bidirectional is an intriguing question. It could= be done, just like we can send packets DOWN a classical DODAG. But if we take that path, we reopen the question of who is root and which d= irection the P-DAO flies. Could we make either the ingress OR the egress root? How does it matter? At the moment the Root is the egress and the storing-mode P-DAO flies from = the Track egress to the track ingress, and the track egress is the root. Th= is is not the way RPL usually works as the DAO flies towards the root. The = reason was that we wanted a single egress for the Track, as we build unicas= t Track. If we wanted to build multicast Tracks the root should logically b= e the ingress. And for bidirectional Tracks it could be either. Up to -24 the 6TiSCH Architecture expected the ingress to be root. I change= d in the latest to map we do here, that it is the egress; maybe a flag in t= he DAO would indicate which direction the flow, from root, to root, or both= ? Also if we build bidir Tracks in storing mode, the nodes that forward the D= AO will have to build routes in both directions based on the P-DAO, both to= wards egress and ingress; but only the path from which the P-DAO comes has = been validated by the P-DAO itself. Should we send a P-DAO to each end, eac= h setting up one way? Please let me know your thoughts Pascal From: Roll > On Behalf = Of Pascal Thubert (pthubert) Sent: mardi 24 novembre 2020 14:22 To: Routing Over Low power and Lossy networks > Subject: [Roll] IETF 109 open Questions on P-DAO Dear all The slides for the P-DAO discussion at IETF 109 are available here: https://datatracker.ietf.org/doc/slides-109-roll-dao-projection/ There are a number of open questions that we starting discussing, and would= need to progress on the list. Some of them were expressed on the list, e.g., from Huimin She. I'd like to= progress on them all with individual threads. The questions are: 1. Lifetime Unit: could we use a different unit for P-DAO? 2. How to differentiate a P-DAO from a normal DAO in a local instance; n= ew flag? 3. Make P-DAO bidirectional? 4. Who sends the PDR? Does it have to be the ingress? If it was egress i= t could propose a TrackId from its namespace. Else could the ingress be the= root? 5. Maintaining the sibling state. Should we have text on using RFC 8505 = there? 6. Whether ingress and egress are listed in NPO? Today they are both, in= gress to indicate the packet source in case of encapsulation and for SRH-6L= oRH compression reference and egress to build the full SRH-6LoRH. Note that= the ingress must consume the first entry and use it as source. 7. Track in Track vs. SR Header reload models, see slides Let me open threads to follow up. Keep safe Pascal --_000_CO1PR11MB48819F71CFF279AC9BD7240DD8FA0CO1PR11MB4881namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Li;

 

Well noted. This was the original intent. The change was mad= e to egress because the idea was that the track could enable multiple sourc= es to reach the egress, like a tree rooted at the egress that flows traverse going down. But the idea of a bidirectio= nal track kinda blocks that idea and the other issues like the one you poin= t out seem to get us back to the original view. I recently made the change = from ingress to egress in the 6TiSCH architecture, waiting in RFC editor queue. I could reverse back, or maybe = say “either source or destination” so it can be egress or egres= s and we are covered for bidirectional.

What do you think?

Or should a reversable Track be really a pair of tracks?

 

Keep safe;

 

Pascal

 

From: Roll <roll-bo= unces@ietf.org> On Behalf Of Li Zhao (liz3)<= br> Sent: mercredi 25 novembre 2= 020 05:57
To: Routing Over Low power a= nd Lossy networks <roll@ietf.org>
Subject: Re: [Roll] Make P-D= AO bidirectional [extends] IETF 109 open Questions on P-DAO

 

Hello Pascal,

 

Ingress as Root looks better because

1.  It is consistent with the way RPL usually works. RPL Local instance, aodv-rpl, p2p-= rpl all use ingress as root.

2.  For non-storing-mode P-DAO, currently ingress sends= upward traffic to egress(root) with SR header. But in RPL, only downward traffic carries SR header.

3.  Only ingress can send PDR m= akes sense. Behavior of TrackId is = similar as Local Instance ID. Ingress as root can propose TrackId fr= om its namespace.

 

 

And for storing-mode P-DAO, if we make ingress as root and i= ngress sends PDR, can PCE send P-DAO to egress then egress forwards it towards predecessor to ingress?

Maybe it helps to make P-DAO looks like a DAO message.

 

 

Best regards,

Li

 

 

From: Roll <roll= -bounces@ietf.org>
Date: Tuesday, November 24, = 2020 at 21:39
To: Routing Over Low power a= nd Lossy networks <roll@ietf.org>= ;
Subject: [Roll] Make P-DAO b= idirectional [extends] IETF 109 open Questions on P-DAO

Dear all

 

Whether to make the P-DAO bidirectional is an intriguing que= stion. It could be done, just like we can send packets DOWN a classical DOD= AG.

But if we take that path, we reopen the question of who is r= oot and which direction the P-DAO flies.

 

Could we make either the ingress OR the egress root? How doe= s it matter?

 

At the moment the Root is the egress and the storing-mode P-= DAO flies from the Track egress to the track ingress, and the track egress = is the root. This is not the way RPL usually works as the DAO flies towards the root. The reason was that we wanted a s= ingle egress for the Track, as we build unicast Track. If we wanted to buil= d multicast Tracks the root should logically be the ingress. And for bidire= ctional Tracks it could be either.

 

Up to -24 the 6TiSCH Architecture expected the ingress to be= root. I changed in the latest to map we do here, that it is the egress; ma= ybe a flag in the DAO would indicate which direction the flow, from root, to root, or both?<= /p>

 

Also if we build bidir Tracks in storing mode, the nodes tha= t forward the DAO will have to build routes in both directions based on the= P-DAO, both towards egress and ingress; but only the path from which the P-DAO comes has been validated by the P-D= AO itself. Should we send a P-DAO to each end, each setting up one way?

 

Please let me know your thoughts

 

Pascal

 

 

From: Roll <roll-bounces@ietf.org> On Behalf Of Pascal Thubert = (pthubert)
Sent: mardi 24 novembre 2020= 14:22
To: Routing Over Low power a= nd Lossy networks <roll@ietf.org>= ;
Subject: [Roll] IETF 109 ope= n Questions on P-DAO

 

Dear all

 

The slides for the P-DAO discussion at IETF 109 are availabl= e here:

 

https://datatracker.ietf.org/doc/slides-109-roll-dao-proje= ction/

 

There are a number of open questions that we starting discus= sing, and would need to progress on the list.

Some of them were expressed on the list, e.g., from Huimin S= he. I’d like to progress on them all with individual threads.

The questions are:

 

  1. Li= fetime Unit: could we use a different unit for P-DAO?
  2. How to differentiate a P-DAO from a normal DAO in a local instance; n= ew flag?
  3. Make P-DAO bidirectional?
  4. Who sends the PDR? Does it have to be the ingress? If it was= egress it could propose a TrackId from its namespace. Else could the ingress be the root?
  5. Maintaining the = sibling state. Should we have text on using RFC 8505 there?
  6. Whether ingress and egress are listed in NPO? Today they are bo= th, ingress to indicate the packet source in case of encapsulation and for SRH-6LoRH compression reference and egress to build the full SRH-6= LoRH. Note that the ingress must consume the first entry and use it as sour= ce.
  7. Track in Track vs. SR Header reload models, = see slides

 

Let me open threads to follow up.

 

Keep safe

 

Pascal

 

 

--_000_CO1PR11MB48819F71CFF279AC9BD7240DD8FA0CO1PR11MB4881namp_-- From nobody Wed Nov 25 18:44:47 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 098E73A0BFD for ; Wed, 25 Nov 2020 18:44:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=AP1qF+As; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=w+7NIYtf 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 2lY4vcQioCNq for ; Wed, 25 Nov 2020 18:44:42 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10AC43A0BFA for ; Wed, 25 Nov 2020 18:44:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20550; q=dns/txt; s=iport; t=1606358682; x=1607568282; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=DwRg0UYRAroDQNsZkc/I2y9d1ueR2nMe4zQiSmjxYfk=; b=AP1qF+Asu4xnOZnAIrEeSEXSFZHJK+H3RThr9+T/F4vYYWYPghdK8Qhf Lf6yLNKTLgUjouVByTQw3xOLrJd43TQvqocAe+ymOGnEsm2/web50LMim nPxWUGYvbPF22uPkzhYXCjS9Fj+aysGi4kmYvxxgDJcfV5wKWNklxkMJA g=; X-IPAS-Result: =?us-ascii?q?A0DdCADPFL9ffYgNJK1YCoEJgnIvUXxaLy6IBgONY5B/i?= =?us-ascii?q?AaBQoERA1QLAQEBDQEBIwoCBAEBhEoCgiQCJTgTAgMBAQEDAgMBAQEBBQEBA?= =?us-ascii?q?QIBBgQUAQGGDwglDIVyAQEBBBIuAQElEw8CAQgRAQIBAQEeCgcyFAMGCAEBB?= =?us-ascii?q?BMIGoMFgX5XAy4BDqMjAoE8iGl0gTSDBAEBBYE3BAxBgyYYghADBoE4gnOCZ?= =?us-ascii?q?k6HGYIbgRABQ4FRUC4+gQSBWQIDAYEhDQ8gHgYHCYMUgiyBRgGPN4oYnUIGB?= =?us-ascii?q?IJuiRaJX4hVgmA7ihyUVp5mkSiEOgIEAgQFAg4BAQWBbSGBWXBQgR6BS1AXA?= =?us-ascii?q?g2HfooUhRSFRHQ3AgYKAQEDCXyMai2CFwEB?= IronPort-PHdr: =?us-ascii?q?9a23=3APdk2Lh/9x/7wnf9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+7ZRaN5PhxghnOR4qIo/5Hiu+DtafmVCRA5Juaq3kNfdRKUA?= =?us-ascii?q?NNksQZmQEsQavnQU32JfLndWo2ScJFUlI2/nynPw5SAsmtL1HXq2e5uDgVHB?= =?us-ascii?q?i3PAFpJ+PzT4jVicn/1+2795DJJQtSgz/oarJpJxLwpgLU5cQ=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,370,1599523200"; d="scan'208,217";a="637602055" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Nov 2020 02:44:40 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AQ2iehl019973 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 26 Nov 2020 02:44:40 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 25 Nov 2020 20:44:39 -0600 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 25 Nov 2020 21:44:38 -0500 Received: from NAM12-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 25 Nov 2020 20:44:38 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GTIlUJUtLSZf402UrIp2sJ+ayI4Mdt1RsJ0/z5Iu3ejvNKUljQZCHdEDInXX8unP+LnMWcqKpTjF2rxyB8SkGzWL5PiT8/Pw/VCwmhpRhDF90rVsptUyxw/m5mmHdAlKHPcBGm41wcI9hn6QfoNS+O3YowMC1P88wiX4Gd8x/D1uqXLQ7nEyqjSBGrXeRp5QgWMH46vVQpiag2SHvebGkJhT/pCAOhHTdMYFqW8P+Jaixq2R2mBcir51qInS70yZIY2l9yWaZKxHJqiMbhhF9AZqytHJEjOAXZ6vbPfdYxGGCd2t6rJOo/vqT+0BlzO2hEUfQ6gGX76568/yPZ7TuA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5D+gP7li6Ghv9qx4wjkrfh9khaBFC9nCDBd69HCr0iA=; b=GY9y8wKIPt6oHtzRSvCP0sxbddugIIz/AMODjPdtm+wtYVljvTyS/cIGTDnFF94qFI2HTCZxfdw7qHzkXug4fB1SfVBJeZbvrYOAwPXpXRLbu4J8ZcMYbMJ9EZDHS3kF8VqE1NvbjZ6W5OpJGahMq8ZOEq/51YwEy7EKWORgNeJkItNQx6LtcX/H4OTJGXEQHX9Ui2QytWbd4ZlfMjqL4afmZSKHJmLzLVHtHtr/dQASrIyOwk2e8BqIft5rkZ+j5dALKOdCvMu9jQ5zXSsqZv1JaL74H4adMn4sGCuIh4Mt/kWCW803L+tNVHbjrKNiEEhPkmwg9koGfxmHNmTQjQ== 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=5D+gP7li6Ghv9qx4wjkrfh9khaBFC9nCDBd69HCr0iA=; b=w+7NIYtfmyTi0mArrRbsGporvnUDRiEC9gTyAQCRh7/TV5PD5Qlk7sum1eGZRToK9nRvG5k2MDPyErMBiq1JFTmWGqjCAFhe/0YNqie8rvnH8S8CRJcDm6lN+GHjhhfuTJsvYuX6dxFrJERa09nty1QKEDdx2/DVCm2SKsWrQMQ= Received: from MWHPR11MB1742.namprd11.prod.outlook.com (2603:10b6:300:113::13) by MWHPR11MB1679.namprd11.prod.outlook.com (2603:10b6:301:f::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.30; Thu, 26 Nov 2020 02:44:37 +0000 Received: from MWHPR11MB1742.namprd11.prod.outlook.com ([fe80::5819:88b4:cdaf:610a]) by MWHPR11MB1742.namprd11.prod.outlook.com ([fe80::5819:88b4:cdaf:610a%9]) with mapi id 15.20.3589.030; Thu, 26 Nov 2020 02:44:37 +0000 From: "Li Zhao (liz3)" To: Routing Over Low power and Lossy networks Thread-Topic: Make P-DAO bidirectional [extends] IETF 109 open Questions on P-DAO Thread-Index: AdbCZRGxaZJsqD20SLuISSoVqF9MEgAgkqIOABJ37jAAGm3GHQ== Date: Thu, 26 Nov 2020 02:44:37 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2001:420:588c:1252:ed42:30ae:45fa:1f11] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 79bc7073-d699-4cba-e84b-08d891b53739 x-ms-traffictypediagnostic: MWHPR11MB1679: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: VDpthEM+ngdDq5f2icepyEgOe2h29Loi+1vLDwD15qMvEG+LSh1OIfvBXdFmat4YTICqXQyBYUvo56C9Ed16oSHxAg9fIlw6bsc+k8X5DIZwESJbAy0IH6dwh3pYqqwfPYNrTtM0V2nyDxqhxob/KiGOKdFwNC0WhZeBkyRPSFkhxrjuCo0iOx/UvRwLYRMaSoityrKBd2vMyR34qquodkEj6FC6SzbvF/xsbAQwTWza73H2NMhSv3LonLTRac9HcwddAcDdpaw/REHQP8Ns+rKkwhU+KYmqc54T1LQh2oG6DM6uQXjidNaP11zdBQc8Py4XFgpVVJVIvc5mqm8NCD0gS+T/7BG4qd0Z+wDAzsMsj4hqsrGPfvLpVhXU4iaZL14gP978EmsuZQ6ZhgM6duWEqojgByEetgqBwe88eSujVqlYSgbtmPa5oDMH83xewmTqJKQHBuz/zZFgq4X4Kg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MWHPR11MB1742.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(39860400002)(376002)(136003)(396003)(346002)(366004)(478600001)(55016002)(86362001)(33656002)(8936002)(7696005)(2906002)(966005)(186003)(8676002)(6916009)(53546011)(6506007)(9686003)(66446008)(166002)(76116006)(5660300002)(83380400001)(91956017)(66946007)(52536014)(316002)(66556008)(71200400001)(64756008)(66476007)(88722002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?Windows-1252?Q?V6L63WkBMf/Now4e7CncUfvkzZC9WtY1h4zkcwO1XLhWVMtSzko6rJmm?= =?Windows-1252?Q?lDF1ztATcCW/+V9+zz0TePvBrw9xlM5A7bZ2gcuftfjiwC4Tb31ZePKL?= =?Windows-1252?Q?E4mYHfD26fQiBX1iWOquO+iAo23x8jjyzlz28yn2LwAJQOb82cabXXI+?= =?Windows-1252?Q?72q8yDKb80mWUmb5f/gmL+GRAm/E89n5rNS0VMbx5PwtTQ9uvdA3GrdM?= =?Windows-1252?Q?L1ScJ5RgMQtgERnKljNyKT18T44+nxW+P0/9vahw1GO9o5TIKUVjA99V?= =?Windows-1252?Q?WcGM+3kP576aNYDfmk0+/b8tlk+K+LQR+Fp320cJlrX6LRjVi3l0R3B7?= =?Windows-1252?Q?ziFS994l7Z15bq7smJy2iFsT4H73zURK5hnzuluCwjGFkIXAAdopOYrR?= =?Windows-1252?Q?Bff5K8wxhq5l2HkeWRYpMgCpmtxNazw1NrkIXhEu6YZk4YqIMmOhjXRX?= =?Windows-1252?Q?P3vzS2r5BPyM1AdKoI1NqPzCi8pc4aD9bw6w2G336tSMzUC/9Frvs2tZ?= =?Windows-1252?Q?CAYxEX1NADiPoh7HqIL4g7tlUCl4e0v+1YXpi3rfB19Lm+EmZia5tqKk?= =?Windows-1252?Q?QbpzXMn2V0EEUsxfDqG72w+y+pC8mOsu3Xajf/7oqR/wOelwP0o0itdw?= =?Windows-1252?Q?IUmTHCgRKzc3khjn3XmPM8lAsPiKf862jIEAd/qbjPeqoSRmbmBmhoB2?= =?Windows-1252?Q?zTB25FRlNOmeyRh3JhbsmBTwlipZFAbcaFte9HDA4cBI9/a+aybEQKwR?= =?Windows-1252?Q?dqq3vq+3UKHsF2mCLJLRFliIjE4ICmuA2Z4AzfigkfoQn29nF0LTgR5s?= =?Windows-1252?Q?9mtbTcyDq64ZtyX0eGNrqLzC1KQJf4ll2Pez/5PNFy1ilNAGUhvtiFNh?= =?Windows-1252?Q?gjwlrbnE0E6o12a0UzIbIj1RHUurELBwkBRwBENGovUL45N1Atqm2qwD?= =?Windows-1252?Q?MgEOczTmJsKxS/qq8v+BIDONmovIX2vPoTwiaFEatmegqBVBgjB4yYWl?= =?Windows-1252?Q?XqU3vXA08G1vrNjCmNAa8fOuqVsaRw4nOR/4Kh5OJ8OlWA7Jx02Q7Cbe?= =?Windows-1252?Q?RIrzp+L00s0XYlM+riIGd7chBcrN6u6A1Scs/9RBGG+t29vdtcPguCVF?= =?Windows-1252?Q?KCzPZFTkr0/AM/cUGxPou7miSTReE4mmjKZnKxCSwZbKtg=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MWHPR11MB17423564937E277312C6BCB78CF90MWHPR11MB1742namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MWHPR11MB1742.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 79bc7073-d699-4cba-e84b-08d891b53739 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Nov 2020 02:44:37.2716 (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: 6+qMNOr4VAcwCiWwiikwlmM8h10XeN2PbJDGidpGbv5c/gE3bKK31PbSAj1hVcHg X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1679 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: alln-core-3.cisco.com Archived-At: Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questions on P-DAO 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, 26 Nov 2020 02:44:45 -0000 --_000_MWHPR11MB17423564937E277312C6BCB78CF90MWHPR11MB1742namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello Pascal, If either source or destination can be root, it=92s better to identify when= or in which case source or destination can be root. Otherwise, it=92s hard= to interop between different implement even though they both follow RFC st= andard. E.g. for non-storing mode PDAO, if source is root, PCE only responses PDR-A= CK after receiving PDR from source. But if destination is root, PCE should also notify destination which tracki= d is used. Maybe we need bring new message for this notification? Take care, Li From: Roll Date: Wednesday, November 25, 2020 at 21:54 To: Routing Over Low power and Lossy networks Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questi= ons on P-DAO Hello Li; Well noted. This was the original intent. The change was made to egress bec= ause the idea was that the track could enable multiple sources to reach the= egress, like a tree rooted at the egress that flows traverse going down. B= ut the idea of a bidirectional track kinda blocks that idea and the other i= ssues like the one you point out seem to get us back to the original view. = I recently made the change from ingress to egress in the 6TiSCH architectur= e, waiting in RFC editor queue. I could reverse back, or maybe say =93eithe= r source or destination=94 so it can be egress or egress and we are covered= for bidirectional. What do you think? Or should a reversable Track be really a pair of tracks? Keep safe; Pascal From: Roll On Behalf Of Li Zhao (liz3) Sent: mercredi 25 novembre 2020 05:57 To: Routing Over Low power and Lossy networks Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questi= ons on P-DAO Hello Pascal, Ingress as Root looks better because 1. It is consistent with the way RPL usually works. RPL Local instance, ao= dv-rpl, p2p-rpl all use ingress as root. 2. For non-storing-mode P-DAO, currently ingress sends upward traffic to e= gress(root) with SR header. But in RPL, only downward traffic carries SR he= ader. 3. Only ingress can send PDR makes sense. Behavior of TrackId is similar a= s Local Instance ID. Ingress as root can propose TrackId from its namespace= . And for storing-mode P-DAO, if we make ingress as root and ingress sends PD= R, can PCE send P-DAO to egress then egress forwards it towards predecessor= to ingress? Maybe it helps to make P-DAO looks like a DAO message. Best regards, Li From: Roll > Date: Tuesday, November 24, 2020 at 21:39 To: Routing Over Low power and Lossy networks > Subject: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questions = on P-DAO Dear all Whether to make the P-DAO bidirectional is an intriguing question. It could= be done, just like we can send packets DOWN a classical DODAG. But if we take that path, we reopen the question of who is root and which d= irection the P-DAO flies. Could we make either the ingress OR the egress root? How does it matter? At the moment the Root is the egress and the storing-mode P-DAO flies from = the Track egress to the track ingress, and the track egress is the root. Th= is is not the way RPL usually works as the DAO flies towards the root. The = reason was that we wanted a single egress for the Track, as we build unicas= t Track. If we wanted to build multicast Tracks the root should logically b= e the ingress. And for bidirectional Tracks it could be either. Up to -24 the 6TiSCH Architecture expected the ingress to be root. I change= d in the latest to map we do here, that it is the egress; maybe a flag in t= he DAO would indicate which direction the flow, from root, to root, or both= ? Also if we build bidir Tracks in storing mode, the nodes that forward the D= AO will have to build routes in both directions based on the P-DAO, both to= wards egress and ingress; but only the path from which the P-DAO comes has = been validated by the P-DAO itself. Should we send a P-DAO to each end, eac= h setting up one way? Please let me know your thoughts Pascal From: Roll > On Behalf = Of Pascal Thubert (pthubert) Sent: mardi 24 novembre 2020 14:22 To: Routing Over Low power and Lossy networks > Subject: [Roll] IETF 109 open Questions on P-DAO Dear all The slides for the P-DAO discussion at IETF 109 are available here: https://datatracker.ietf.org/doc/slides-109-roll-dao-projection/ There are a number of open questions that we starting discussing, and would= need to progress on the list. Some of them were expressed on the list, e.g., from Huimin She. I=92d like = to progress on them all with individual threads. The questions are: 1. Lifetime Unit: could we use a different unit for P-DAO? 2. How to differentiate a P-DAO from a normal DAO in a local instance; n= ew flag? 3. Make P-DAO bidirectional? 4. Who sends the PDR? Does it have to be the ingress? If it was egress i= t could propose a TrackId from its namespace. Else could the ingress be the= root? 5. Maintaining the sibling state. Should we have text on using RFC 8505 = there? 6. Whether ingress and egress are listed in NPO? Today they are both, in= gress to indicate the packet source in case of encapsulation and for SRH-6L= oRH compression reference and egress to build the full SRH-6LoRH. Note that= the ingress must consume the first entry and use it as source. 7. Track in Track vs. SR Header reload models, see slides Let me open threads to follow up. Keep safe Pascal --_000_MWHPR11MB17423564937E277312C6BCB78CF90MWHPR11MB1742namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hello Pascal,=

 

If either source or dest= ination can be root, it=92s better to identify when or= in which case source or destination can be root. Otherwise, i= t=92s hard to interop between different implement even though they both fol= low RFC standard.

 

E.g. for non-storing mode PDAO,= if source is root, PCE only responses PDR-ACK after recei= ving PDR from source.

But if destination is root, PCE should also notify destination whi= ch trackid is used. Maybe we need bring new message for this notification?<= o:p>

 

 

Take care,

Li

 

From: Roll <roll-bounc= es@ietf.org>
Date: Wednesday, November 25, 2020 at 21:54
To: Routing Over Low power and Lossy networks <roll@ietf.org><= br> Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open= Questions on P-DAO

Hello Li;

 

Well noted. This was the original intent. The change= was made to egress because the idea was that the track could enable multip= le sources to reach the egress, like a tree rooted at the egress that flows= traverse going down. But the idea of a bidirectional track kinda blocks that idea and the other issues like = the one you point out seem to get us back to the original view. I recently = made the change from ingress to egress in the 6TiSCH architecture, waiting = in RFC editor queue. I could reverse back, or maybe say =93either source or destination=94 so it can be egress = or egress and we are covered for bidirectional.

What do you think?

Or should a reversable Track be really a pair of tra= cks?

 

Keep safe;

 

Pascal

 

From: Roll <roll-bounces@ietf.org> O= n Behalf Of Li Zhao (liz3)
Sent: mercredi 25 novembre 2020 05:57
To: Routing Over Low power and Lossy networks <roll@ietf.org><= br> Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open= Questions on P-DAO

 

Hello Pascal,

 

Ingress as Root looks better because

1.  It is consistent with the way RPL usually w= orks. RPL Local instance, aodv-rpl, p2p-rpl all use ingress as root.

2.  For non-storing-mode P-DAO, currently ingre= ss sends upward traffic to egress(root) with SR header. But in RPL, only do= wnward traffic carries SR header.

3.  Only ingress can send PDR makes sense. Behavior of TrackId is similar as Local= Instance ID. Ingress as root can propose TrackId from its namespace.

 

 

And for storing-mode P-DAO, if we make ingress as ro= ot and ingress sends PDR, can PCE send P-DAO to egress then egress forwards= it towards predecessor to ingress?

Maybe it helps to make P-DAO looks like a DAO messag= e.

 

 

Best regards,

Li

 

 

From: Roll <roll= -bounces@ietf.org&g= t;
Date: Tuesday, November 24, 2020 at 21:39
To: Routing Over Low power and Lossy networks <roll@ietf.org= >
Subject: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Que= stions on P-DAO

Dear all

 

Whether to make the P-DAO bidirectional is an intrig= uing question. It could be done, just like we can send packets DOWN a class= ical DODAG.

But if we take that path, we reopen the question of = who is root and which direction the P-DAO flies.

 

Could we make either the ingress OR the egress root?= How does it matter?

 

At the moment the Root is the egress and the storing= -mode P-DAO flies from the Track egress to the track ingress, and the track= egress is the root. This is not the way RPL usually works as the DAO flies= towards the root. The reason was that we wanted a single egress for the Track, as we build unicast Track. I= f we wanted to build multicast Tracks the root should logically be the ingr= ess. And for bidirectional Tracks it could be either.

 

Up to -24 the 6TiSCH Architecture expected the ingre= ss to be root. I changed in the latest to map we do here, that it is the eg= ress; maybe a flag in the DAO would indicate which direction the flow, from= root, to root, or both?

 

Also if we build bidir Tracks in storing mode, the n= odes that forward the DAO will have to build routes in both directions base= d on the P-DAO, both towards egress and ingress; but only the path from whi= ch the P-DAO comes has been validated by the P-DAO itself. Should we send a P-DAO to each end, each setting up o= ne way?

 

Please let me know your thoughts

 

Pascal

 

 

From: Roll <roll-bounces@ietf.org> On Behalf Of Pascal Thubert (pthubert)
Sent: mardi 24 novembre 2020 14:22
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Subject: [Roll] IETF 109 open Questions on P-DAO

 

Dear all

 

The slides for the P-DAO discussion at IETF 109 are = available here:

 

https://datatracker.ietf.org/doc/slides-109-roll-d= ao-projection/

 

There are a number of open questions that we startin= g discussing, and would need to progress on the list.

Some of them were expressed on the list, e.g., from = Huimin She. I=92d like to progress on them all with individual threads.

The questions are:

 

  1. Lifetime Unit: could we use a different unit for P-DAO?
  2. How to differentiate a P-DAO from a normal DAO in a local instance;= new flag?
  3. Make P-DAO bidirectional?
    4. Who sends the PDR? Does it have to be the ingress? If it was egress it = could propose a TrackId from its namespace. Else could the ingress be the r= oot?
  4. Maintaining the sibling state. Should we have tex= t on using RFC 8505 there?
  5. Whether ingress and egress = are listed in NPO? Today they are both, ingress to indicate the packet sour= ce in case of encapsulation and for SRH-6LoRH compression reference and egr= ess to build the full SRH-6LoRH. Note that the ingress must consume the first = entry and use it as source.
  6. Track in Track vs. SR Head= er reload models, see slides

 

Let me open threads to follow up.

 

Keep safe

 

Pascal

 

 

--_000_MWHPR11MB17423564937E277312C6BCB78CF90MWHPR11MB1742namp_-- From nobody Thu Nov 26 02:47:58 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC2A23A1128 for ; Thu, 26 Nov 2020 02:47:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.619 X-Spam-Level: X-Spam-Status: No, score=-9.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Np3EwFre; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=qFbG7KOJ 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 E-T0NqgSdMuL for ; Thu, 26 Nov 2020 02:47:54 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E73EC3A1125 for ; Thu, 26 Nov 2020 02:47:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=42381; q=dns/txt; s=iport; t=1606387674; x=1607597274; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=PTJIIzB+WGZ+zGigkGmgqYjnGH8l5OmxdJTM5mOZxPA=; b=Np3EwFreK6/phdfWhX1q/SzoRd6vT/StjhETaaJMd8abyWVRxlcrOWOR bvlAGAKcwtTpYSGlosMxjqh0IyAE80H+STw7ZhCCks7wYBj/VOSTWS7iZ /ixg9MASBwgEL53kH9mgzSBeFwdGrmaEjPpNPApitko1XQdniRr36cqDe I=; X-IPAS-Result: =?us-ascii?q?A0DkCAAWhr9ffZBdJa1YCoEJgnIBLikofFovLogGA41ck?= =?us-ascii?q?H+IBoFCgREDVAsBAQENAQEjCgIEAQGESgKCKAIlOBMCAwEBAQMCAwEBAQEFA?= =?us-ascii?q?QEBAgEGBBQBAYYPCCUMhXIBAQEEEhsTAQElEw8CAQgRAQIBAQEhAQYHMhQDB?= =?us-ascii?q?ggBAQQTCBqDBYF+VwMuAQ6jXwKBPIhpdIE0gwQBAQWBNwQMQYMrGIIQAwaBO?= =?us-ascii?q?IJzgmZOhxkbgUE/gRABQ4FXUC4+gQSBWQIDAYEhDQ8gHgYHCYMUgiyRAooan?= =?us-ascii?q?UkKgm6JFolfiFeCYTuKHJRZnmmRKoQ8AgQCBAUCDgEBBYFtIYFZcBU7gmlQF?= =?us-ascii?q?wINh36HSAEHgkSFFIVEdDcCBgoBAQMJfIx4LYIXAQE?= IronPort-PHdr: =?us-ascii?q?9a23=3A9BBo5RMr/flMw+Dp9kgl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEvKw33l7EQYud7OhL2KLasKHlDGoH55vJ8HUPa4dFWB?= =?us-ascii?q?JNj8IK1xchD8iIBQyeTrbqYiU2Ed4EWApj+He2YklYBMi4YEfd8TW+6DcIEU?= =?us-ascii?q?D5Mgx4bu3+Bo/ViZGx0Oa/s53eaglFnnyze7R3eR63tg7W8MIRhNhv?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,371,1599523200"; d="scan'208,217";a="600798269" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Nov 2020 10:47:52 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AQAlqDP022900 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 26 Nov 2020 10:47:52 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 26 Nov 2020 04:47:52 -0600 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 26 Nov 2020 04:47:51 -0600 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 26 Nov 2020 05:47:50 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=hGvlcKZQ/RbThsEEdLi0Y3h9OIUbcuf2YDPo9EeOGBqf4RnxI3smfo8ImSmkauGL7LCYIqshi2h8NbHWn7FXULRla4udEU9pqBnbLIRNy5UWwE+A5DwYiWN1Vzm/GjZjLR6cnLkYoS6QgBidM3q7NrL7SGp0XODztvgSS2jRd3azaqzcQVJetp5vffb3HwrVJv9966zQOhGBFoiRyzbJUx/a/N6M9LttUsZazWmNnvvcvvkhiEdIVtrJP/kUkr6b05YZ3tsDeFdch7nf29RG2tU7mAMYRgQnE/RNBJsMx9gJ2WX2LJmk5q78KiGDJwSdRd5wYqkCpbQ01RSbV0tDOw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=+Mj31j2xtS2CDYK8BR49UBMX7J0TKXfoKaFBPq73E5o=; b=mGeNGDoCgWOjDKO3xMP7DSDahwqavHiLzZgXZb90dBjrlzH3Cw9jpdyBRLP9TJ600TO7ITkv9cWFNm3F5/+jUx3OIj9J9yLmG8Wot1nv4CnqrEpHIXR69VvMiB6ZNhZ1TK1vR/jlbYyYvRrWpjn3535fkiTQTA7iPDUa9pQLK4Ijzn2uPieEm90mdFnb0Vfw3A+wSLM52P8IxCaWXtjXjBe5O4e5/rcbPE8oUY5VUp/wRfh5P/bkT/4n4PFC4U5sPzMO5gxPno+RXaQFmDLNTjO9ulMwdyVv4q17gwP2h/sWPordJldIsMEXJe2tRW5deDrMk6YNMyca4AtQ5ZUTRA== 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=+Mj31j2xtS2CDYK8BR49UBMX7J0TKXfoKaFBPq73E5o=; b=qFbG7KOJIzGKYXkrwAypIqIW4hx3qmjf+GZcUY03FbYAdzmp79CAoqAO9lptZcSvkhlFmiWR0T1wTVXFQHIcrPBnB7AQ2qbHq4zSuaRFVpx98WE4Z3QHpbJgVw0xdrIHqtQrDn/LCnbH3+FYaLUhXcq+A+2iwE4zFBxdUszQhJs= Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by MW3PR11MB4652.namprd11.prod.outlook.com (2603:10b6:303:5a::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.22; Thu, 26 Nov 2020 10:47:49 +0000 Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::fc25:3e72:3e83:7df6]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::fc25:3e72:3e83:7df6%4]) with mapi id 15.20.3564.025; Thu, 26 Nov 2020 10:47:49 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: Make P-DAO bidirectional [extends] IETF 109 open Questions on P-DAO Thread-Index: AdbCZRGxaZJsqD20SLuISSoVqF9MEgAgkqIOABJ37jAAGm3GHQALqPgA Date: Thu, 26 Nov 2020 10:47:22 +0000 Deferred-Delivery: Thu, 26 Nov 2020 10:47:14 +0000 Message-ID: References: , In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2a01:cb1d:4ec:2200:ddb0:2d6e:3802:39be] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1670db26-1185-4070-da06-08d891f8b813 x-ms-traffictypediagnostic: MW3PR11MB4652: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 3DjVyw3P7WLFWAFzVO6QhobtwjgDVoQJHhkQmKCXzDelk3OJHOxyxDuL0bMo6V3r+1QR4tW74kWks9cqMfXnLtyNE5PGoVn1MJThBTgvK0l2VPXtvorZjC4r1wTCL0rEqU/b7KZ8gLjhhaAmjSr19qug+rr/0sEZiol9zsHcAaDtNcoOW67pqM0PJmXqGBIXVoQui5mwc4ipoHlzCwb9FXgolJHriIUV7aAW3uMRJHte0GsfgDVBShCrw7NrZHVuPqktPu2OV/hU2JcCDwXEVJY1Qc5RzHgkrwAM0v6h3cUn9RfJ/tUfaFmgRZzxT7qXpRQnhJWZO78y+q8Xk1tTOF5MsRO8RdannR/Ee+TZYpoX+x5sovfyo/qNxJOefqe0yRvbp63P4GfrBL9jYVi5uw== 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:(376002)(366004)(346002)(396003)(39860400002)(136003)(86362001)(966005)(33656002)(9686003)(478600001)(71200400001)(55016002)(8676002)(7696005)(5660300002)(2906002)(8936002)(166002)(52536014)(186003)(83380400001)(53546011)(316002)(76116006)(6506007)(64756008)(66556008)(66446008)(66476007)(6666004)(6916009)(66946007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?FWxJvTRiY3N4f3NjwGFrzBy55u7g7mkj+JJ+puBXh5jGWLqD+s62dW+QtkAa?= =?us-ascii?Q?voLEXBgTvNk91Hb7vsATRjhdk+prk29oTx5idS8PN/icdUQE7kasZ3FvTbbk?= =?us-ascii?Q?mH0c4Qy+Puc6fZGzoOhRRweRjcnbEDriOpXo6KJsy1O/1iT0QGSoHFvO8DEJ?= =?us-ascii?Q?H1nWpPw9Nhpv6/oe97nKugYLxrUD6zU+TY5r36F1QyaldDYPRkZxl3ucdyUD?= =?us-ascii?Q?HqHZeIh3KKWvnd3pUrR0gvbml6rNTOBvnLeyHIoYUAqvtSVL6XiwnVBfUlMl?= =?us-ascii?Q?7DxB/I0ohC5OSnIamGXyy02WvIeBJRObsHvw3wVMKYKfvIL24vgtYdFSXkeS?= =?us-ascii?Q?uC7MDeMwBSt36R01UHmYvhvfMnYJMONxxUciwq79FRhLs0TjNlPpfrpZFxJZ?= =?us-ascii?Q?ndIIryOpseN71UWv2G8H9UgCqKp+TA83bRaVF5BYEMY1rVfRZrwFJVIr1M8A?= =?us-ascii?Q?dnbujC0SdCKIRhrTDLuZgOMJUkyN6dmCxwmeOrPKYm2CU8lc2iBuRmX2i/pD?= =?us-ascii?Q?fp2Gg5u3YKZxqnHL5zhBmb7y27ayz9bJKZII64IMMZQSep/AwIc0jvOQX4yc?= =?us-ascii?Q?6dW3e4rfs2KtXnEb4ek/1i/afxA5n+sGHT56DRNGihxiaBtrlCTCFPvoAZcD?= =?us-ascii?Q?O96qefkOJynL/jI7PTHBFUDN+USNcI8dCf3hUSYWE4jSicMCIUs7AqvzH5Sj?= =?us-ascii?Q?1HJN2TxDFOyaqRxTxdg/XrnVFont0b6behkFWYavX1Tte82AKXfi6vy6Erya?= =?us-ascii?Q?VA7ZZNXguTZY5wl6SdasaFl/VkQACwmgELHg4u044Vmkscq9QOc9xmi6mOOC?= =?us-ascii?Q?KsNld5etQn4c0fuQmsqaeiz5JSjZt9tayQTibege97OzqOkll9S3dYH75RX7?= =?us-ascii?Q?BX6JfPXWv/9zg6NH6dv3eryX/mGuZjzXuEmejHhGTY12Igymm7pDaRqNfW6c?= =?us-ascii?Q?DhMES7zpi+21HX/DdeixqTp5K3E7gZSFf5MpD4RYmDwpK6Bif+IZdY7DrlHE?= =?us-ascii?Q?Yt0byMomxej/MYx5n2mTQ7q5c0Kf6pXDlHgAddbT0S29RapxsP1ry64gTbfI?= =?us-ascii?Q?jCi/Nfr0?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CO1PR11MB488112E5FE83F6C36E19E05ED8F90CO1PR11MB4881namp_" 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: 1670db26-1185-4070-da06-08d891f8b813 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Nov 2020 10:47:49.7906 (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: 4Xz6hd9tKOc9nrOra2cwgT8bDhpi4/wkf+mgdly9HMjsi+1ylM2MtcC+r37iAgFNndp3lNnglxrX/JQ92knRgQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR11MB4652 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: rcdn-core-8.cisco.com Archived-At: Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questions on P-DAO 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, 26 Nov 2020 10:47:57 -0000 --_000_CO1PR11MB488112E5FE83F6C36E19E05ED8F90CO1PR11MB4881namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Li In the packet, there's a bit in the RPI to say if the root is the source or= the destination. That's RFC 6550. I guess the discussion is related to the PDR and P-DAO, not data packet, th= ough it impacts the ICMP error reporting. In a packet along the P-Route, the idea was so far that the DODAG is a conv= ergecast to the destination so the destination is the root. If we say that = there's a single ingress and a single egress then the dodag is reversible a= nd either can be the root. If we want to support multicast tracks in the fu= ture, then the ingress should be root. If the Track has a single ingress and a single egress, then the DODAG is re= versible into another DODAG and it does not matter which is root, so we can= make it bidir as Huimin asked. The storing mode P DAO would look a lot more like a DAO, as you pointed out= , if it goes towards the root. If we want to take that path, a node could l= earn both directions with a single storing mode P DAO. To be continued... For non-storing, making bidir is really hard. It seems easier to install a = Track in both directions and couple them. As a summary of the proposed changes: General - we make the root the ingress - ICMP errors sent to the Root, using the main DODAG if the track is not re= versible Storing mode P DAO: - we also make the root the ingress, P-DAO from egress to ingress are now m= ore similar to RPL DAO operation - the track could be made bi-directional, but that's more code; if so: - the packet forwarding leverages the RPI to indicate the direction, from= or to root - ICMP errors sent to the Root, could be source or destination. Non storing mode P DAO: - tracks remain directional, can be coupled, how is tbd - the RPI is mostly useless since the intermediate nodes do not know the in= stance (they see neither the DIO nor the P-DAO); they have no idea of their= Rank. Still, it is interesting to have is for error determination in an IC= PMP error at eth root. It is also interesting if the SRH forwarding nodes h= ave a state associated to the Track, e.g., reserved time slots or priority = queues. - the RPI is still a SHOULD when there's no compression and a MUST when the= re is. We need to clarify what to do, that's another of Huimin's questions,= taken separately. - ICMP errors forwarding packets are sent to the root which is now the ingr= ess, aka the source of the packet, and the encapsulator field if the packet= is encapsulated and compressed. This is common to any non-storing operatio= n, whether it is a main Instance, local Instance, or Track. The RPI therein= is useful to indicate the Track in Error. So for that matter the forwarder= does not need to make a difference Track vs. other form of RPL local insta= nce. - this impacts the discussion in SRH reloading we had at IETF 109, when a = N-S mode loose track is forwarded along a segment that is also NS mode. We'= ll probably need to re-encapsulate now. In case of re-encapsulation, the r= e-encapsulator becomes source and root of the segment, which now has to be = considered as a serial Track; as tunnel headends do, it will have to decaps= ulate the tunneled packet to send the packet in error back to the ingress o= f the loose track Doe that work? Pascal From: Roll On Behalf Of Li Zhao (liz3) Sent: jeudi 26 novembre 2020 03:45 To: Routing Over Low power and Lossy networks Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questi= ons on P-DAO Hello Pascal, If either source or destination can be root, it's better to identify when o= r in which case source or destination can be root. Otherwise, it's hard to = interop between different implement even though they both follow RFC standa= rd. E.g. for non-storing mode PDAO, if source is root, PCE only responses PDR-A= CK after receiving PDR from source. But if destination is root, PCE should also notify destination which tracki= d is used. Maybe we need bring new message for this notification? Take care, Li From: Roll > Date: Wednesday, November 25, 2020 at 21:54 To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questi= ons on P-DAO Hello Li; Well noted. This was the original intent. The change was made to egress bec= ause the idea was that the track could enable multiple sources to reach the= egress, like a tree rooted at the egress that flows traverse going down. B= ut the idea of a bidirectional track kinda blocks that idea and the other i= ssues like the one you point out seem to get us back to the original view. = I recently made the change from ingress to egress in the 6TiSCH architectur= e, waiting in RFC editor queue. I could reverse back, or maybe say "either = source or destination" so it can be egress or egress and we are covered for= bidirectional. What do you think? Or should a reversable Track be really a pair of tracks? Keep safe; Pascal From: Roll > On Behalf = Of Li Zhao (liz3) Sent: mercredi 25 novembre 2020 05:57 To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questi= ons on P-DAO Hello Pascal, Ingress as Root looks better because 1. It is consistent with the way RPL usually works. RPL Local instance, ao= dv-rpl, p2p-rpl all use ingress as root. 2. For non-storing-mode P-DAO, currently ingress sends upward traffic to e= gress(root) with SR header. But in RPL, only downward traffic carries SR he= ader. 3. Only ingress can send PDR makes sense. Behavior of TrackId is similar a= s Local Instance ID. Ingress as root can propose TrackId from its namespace= . And for storing-mode P-DAO, if we make ingress as root and ingress sends PD= R, can PCE send P-DAO to egress then egress forwards it towards predecessor= to ingress? Maybe it helps to make P-DAO looks like a DAO message. Best regards, Li From: Roll > Date: Tuesday, November 24, 2020 at 21:39 To: Routing Over Low power and Lossy networks > Subject: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questions = on P-DAO Dear all Whether to make the P-DAO bidirectional is an intriguing question. It could= be done, just like we can send packets DOWN a classical DODAG. But if we take that path, we reopen the question of who is root and which d= irection the P-DAO flies. Could we make either the ingress OR the egress root? How does it matter? At the moment the Root is the egress and the storing-mode P-DAO flies from = the Track egress to the track ingress, and the track egress is the root. Th= is is not the way RPL usually works as the DAO flies towards the root. The = reason was that we wanted a single egress for the Track, as we build unicas= t Track. If we wanted to build multicast Tracks the root should logically b= e the ingress. And for bidirectional Tracks it could be either. Up to -24 the 6TiSCH Architecture expected the ingress to be root. I change= d in the latest to map we do here, that it is the egress; maybe a flag in t= he DAO would indicate which direction the flow, from root, to root, or both= ? Also if we build bidir Tracks in storing mode, the nodes that forward the D= AO will have to build routes in both directions based on the P-DAO, both to= wards egress and ingress; but only the path from which the P-DAO comes has = been validated by the P-DAO itself. Should we send a P-DAO to each end, eac= h setting up one way? Please let me know your thoughts Pascal From: Roll > On Behalf = Of Pascal Thubert (pthubert) Sent: mardi 24 novembre 2020 14:22 To: Routing Over Low power and Lossy networks > Subject: [Roll] IETF 109 open Questions on P-DAO Dear all The slides for the P-DAO discussion at IETF 109 are available here: https://datatracker.ietf.org/doc/slides-109-roll-dao-projection/ There are a number of open questions that we starting discussing, and would= need to progress on the list. Some of them were expressed on the list, e.g., from Huimin She. I'd like to= progress on them all with individual threads. The questions are: 1. Lifetime Unit: could we use a different unit for P-DAO? 2. How to differentiate a P-DAO from a normal DAO in a local instance; n= ew flag? 3. Make P-DAO bidirectional? 4. Who sends the PDR? Does it have to be the ingress? If it was egress i= t could propose a TrackId from its namespace. Else could the ingress be the= root? 5. Maintaining the sibling state. Should we have text on using RFC 8505 = there? 6. Whether ingress and egress are listed in NPO? Today they are both, in= gress to indicate the packet source in case of encapsulation and for SRH-6L= oRH compression reference and egress to build the full SRH-6LoRH. Note that= the ingress must consume the first entry and use it as source. 7. Track in Track vs. SR Header reload models, see slides Let me open threads to follow up. Keep safe Pascal --_000_CO1PR11MB488112E5FE83F6C36E19E05ED8F90CO1PR11MB4881namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Li

 

In the packet, there’s a bit in the RPI to say if the = root is the source or the destination. That’s RFC 6550.

I guess the discussion is related to the PDR and P-DAO, not = data packet, though it impacts the ICMP error reporting.<= /font>

 

In a packet along the P-Route, the idea was so far that the = DODAG is a convergecast to the destination so the destination is the root. = If we say that there’s a single ingress and a single egress then the dodag is reversible and either can be the roo= t. If we want to support multicast tracks in the future, then the ingress s= hould be root.

 

If the Track has a single ingress and a single egress, then = the DODAG is reversible into another DODAG and it does not matter which is = root, so we can make it bidir as Huimin asked.

The storing mode P DAO would look a lot more like a DAO, as = you pointed out, if it goes towards the root. If we want to take that path,= a node could learn both directions with a single storing mode P DAO. To be continued…

 

For non-storing, making bidir is really hard. It seems easie= r to install a Track in both directions and couple them.<= /font>

 

As a summary of the proposed changes:

 

General

- we make the root the ingress

- ICMP errors sent to the Root, using the main DODAG if the = track is not reversible

 

 

Storing mode P DAO:

- we also make the root the ingress, P-DAO from egress to in= gress are now more similar to RPL DAO operation

- the track could be made bi-directional, but that’s m= ore code; if so:

  - the packet forwarding leverages the RPI to indicate= the direction, from or to root

  - ICMP errors sent to the Root, could be source or de= stination.

 

Non storing mode P DAO:

- tracks remain directional, can be coupled, how is tbd=

- the RPI is mostly useless since the intermediate nodes do = not know the instance (they see neither the DIO nor the P-DAO); they have n= o idea of their Rank. Still, it is interesting to have is for error determination in an ICPMP error at eth root. It is al= so interesting if the SRH forwarding nodes have a state associated to the T= rack, e.g., reserved time slots or priority queues.

- the RPI is still a SHOULD when there’s no compressio= n and a MUST when there is. We need to clarify what to do, that’s ano= ther of Huimin’s questions, taken separately.

- ICMP errors forwarding packets are sent to the root which = is now the ingress, aka the source of the packet, and the encapsulator fiel= d if the packet is encapsulated and compressed. This is common to any non-storing operation, whether it is a main Instance= , local Instance, or Track. The RPI therein is useful to indicate the Track= in Error. So for that matter the forwarder does not need to make a differe= nce Track vs. other form of RPL local instance.

- this impacts the discussion in SRH reloading we had at IET= F 109, when a  N-S mode loose track is forwarded along a segment that = is also NS mode. We’ll probably need to re-encapsulate now.  In case of re-encapsulation, the re-encapsulator becomes source= and root of the segment, which now has to be considered as a serial Track;= as tunnel headends do, it will have to decapsulate the tunneled packet to = send the packet in error back to the ingress of the loose track

 

 

Doe that work?

 

Pascal

 

From: Roll <roll-bo= unces@ietf.org> On Behalf Of Li Zhao (liz3)<= br> Sent: jeudi 26 novembre 2020= 03:45
To: Routing Over Low power a= nd Lossy networks <roll@ietf.org>
Subject: Re: [Roll] Make P-D= AO bidirectional [extends] IETF 109 open Questions on P-DAO

 

Hello Pascal,

 

If either source or destination can be root, it’s better t= o identify when or in which case source or destination can be root. Otherwi= se, it’s hard to interop between different implement even though they= both follow RFC standard.

 

E.g. for non-storing mode PDAO, if source is root, PCE only responses PDR-ACK after receiving PD= R from source.

But if destination is root, PCE should also notify destination which= trackid is used. Maybe we need bring new message for this notification?

 

 

Take care,

Li

 

From: Roll <roll-bounces@ie= tf.org>
Date: Wednesday, November 25= , 2020 at 21:54
To: Routing Over Low power a= nd Lossy networks <roll@ietf.org= >
Subject: Re: [Roll] Make P-D= AO bidirectional [extends] IETF 109 open Questions on P-DAO

Hello Li;

 

Well noted. This was the original intent. The change was mad= e to egress because the idea was that the track could enable multiple sourc= es to reach the egress, like a tree rooted at the egress that flows traverse going down. But the idea of a bidirectio= nal track kinda blocks that idea and the other issues like the one you poin= t out seem to get us back to the original view. I recently made the change = from ingress to egress in the 6TiSCH architecture, waiting in RFC editor queue. I could reverse back, or maybe = say “either source or destination” so it can be egress or egres= s and we are covered for bidirectional.

What do you think?

Or should a reversable Track be really a pair of tracks?

 

Keep safe;

 

Pascal

 

From: Roll <roll-bounces@ietf.org> On Behalf Of Li Zhao (liz3)<= br> Sent: mercredi 25 novembre 2= 020 05:57
To: Routing Over Low power a= nd Lossy networks <roll@ietf.org>= ;
Subject: Re: [Roll] Make P-D= AO bidirectional [extends] IETF 109 open Questions on P-DAO

 

Hello Pascal,

 

Ingress as Root looks better because

1.  It is consistent with the way RPL usually works. RP= L Local instance, aodv-rpl, p2p-rpl all use ingress as root.

2.  For non-storing-mode P-DAO, currently ingress sends= upward traffic to egress(root) with SR header. But in RPL, only downward t= raffic carries SR header.

3.  Only i= ngress can send PDR makes sense. Behavior of TrackId is similar as Local Instance= ID. Ingress as root can propose TrackId from its namespace.<= o:p>

 

 

And for storing-mode P-DAO, if we make ingress as root and i= ngress sends PDR, can PCE send P-DAO to egress then egress forwards it towa= rds predecessor to ingress?

Maybe it helps to make P-DAO looks like a DAO message.

 

 

Best regards,

Li

 

 

From: Roll <roll-bounces@ie= tf.org>
Date: Tuesday, November 24, = 2020 at 21:39
To: Routing Over Low power a= nd Lossy networks <roll@ietf.org= >
Subject: [Roll] Make P-DAO b= idirectional [extends] IETF 109 open Questions on P-DAO<= /o:p>

Dear all

 

Whether to make the P-DAO bidirectional is an intriguing que= stion. It could be done, just like we can send packets DOWN a classical DOD= AG.

But if we take that path, we reopen the question of who is r= oot and which direction the P-DAO flies.

 

Could we make either the ingress OR the egress root? How doe= s it matter?

 

At the moment the Root is the egress and the storing-mode P-= DAO flies from the Track egress to the track ingress, and the track egress = is the root. This is not the way RPL usually works as the DAO flies towards the root. The reason was that we wanted a s= ingle egress for the Track, as we build unicast Track. If we wanted to buil= d multicast Tracks the root should logically be the ingress. And for bidire= ctional Tracks it could be either.

 

Up to -24 the 6TiSCH Architecture expected the ingress to be= root. I changed in the latest to map we do here, that it is the egress; ma= ybe a flag in the DAO would indicate which direction the flow, from root, to root, or both?<= /p>

 

Also if we build bidir Tracks in storing mode, the nodes tha= t forward the DAO will have to build routes in both directions based on the= P-DAO, both towards egress and ingress; but only the path from which the P-DAO comes has been validated by the P-D= AO itself. Should we send a P-DAO to each end, each setting up one way?

 

Please let me know your thoughts

 

Pascal

 

 

From: Roll <roll-bounces@ietf.org> On Behalf Of Pascal Thubert = (pthubert)
Sent: mardi 24 novembre 2020= 14:22
To: Routing Over Low power a= nd Lossy networks <roll@ietf.org>= ;
Subject: [Roll] IETF 109 ope= n Questions on P-DAO

 

Dear all

 

The slides for the P-DAO discussion at IETF 109 are availabl= e here:

 

https://datatracker.ietf.org/doc/slides-109-roll-dao-proje= ction/

 

There are a number of open questions that we starting discus= sing, and would need to progress on the list.

Some of them were expressed on the list, e.g., from Huimin S= he. I’d like to progress on them all with individual threads.

The questions are:

 

  1. Li= fetime Unit: could we use a different unit for P-DAO?
  2. How to differentiate a P-DAO from a normal DAO in a local instance; n= ew flag?
  3. Make P-DAO bidirectional?
  4. Who sends the PDR? Does it have to be the ingress? If it was= egress it could propose a TrackId from its namespace. Else could the ingress be the root?
  5. Maintaining the = sibling state. Should we have text on using RFC 8505 there?
  6. Whether ingress and egress are listed in NPO? Today they are bo= th, ingress to indicate the packet source in case of encapsulation and for SRH-6LoRH compression reference and egress to build the full SRH-6= LoRH. Note that the ingress must consume the first entry and use it as sour= ce.
  7. Track in Track vs. SR Header reload models, = see slides

 

Let me open threads to follow up.

 

Keep safe

 

Pascal

 

 

--_000_CO1PR11MB488112E5FE83F6C36E19E05ED8F90CO1PR11MB4881namp_-- From nobody Thu Nov 26 18:51:31 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6160B3A10A2 for ; Thu, 26 Nov 2020 18:51:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=doWD1pU+; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=lI25RDMI 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 4tVJf8ptmZ7H for ; Thu, 26 Nov 2020 18:51:26 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4AE323A10A0 for ; Thu, 26 Nov 2020 18:51:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35124; q=dns/txt; s=iport; t=1606445486; x=1607655086; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=wh1nxH3tlOoQ7G6PKeUHROkSAcj7tf039fOzA5xXc4M=; b=doWD1pU+U6Rq3Io3CDvwKsBA6vFeQKqPHJdrPActJRlaaB7cushmU/zJ EMB+DuvmeMht9Uy1nyxrOtwKXL+i9Ng/ne5jOA0qif/Bg7agywYXDdnXM 5WjmP3vNkndeOnpNw8O4Gj6y6unFlPucb+F0ysqpUCh3OcnE5I0wJVfMl I=; X-IPAS-Result: =?us-ascii?q?A0DkCADPaMBffZ1dJa1YCoEJgnIvKSh8Wi8uiAYDjV2Qf?= =?us-ascii?q?4gGgUKBEQNUCwEBAQ0BASMKAgQBAYRKAoIoAiU4EwIDAQEBAwIDAQEBAQUBA?= =?us-ascii?q?QECAQYEFAEBhg8IJQyFcgEBAQEDEi4BASUTDwIBCBEBAgEBAR4DAQYHMhQDB?= =?us-ascii?q?ggBAQQTCBqDBYF+VwMuAQ6kPQKBPIhpdIE0gwQBAQWBNwQMQYMzGIIQAwaBO?= =?us-ascii?q?IJzgmZOhxmCG4EQAUOBV1AuPoEEgVkCAwGBIQ0PIB4GBwmDFIIsgUYBjzuKG?= =?us-ascii?q?p1KBgSCbokXiV+IV4JhO4oclFmeaZEqhDwCBAIEBQIOAQEFgW0hgVlwUIEeg?= =?us-ascii?q?UtQFwINh36HSAEHgkSFFIVEdDcCBgoBAQMJfIxELYIXAQE?= IronPort-PHdr: =?us-ascii?q?9a23=3A3m+LgBejcYvgF0mIsLwlSWgzlGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwaQB9fa5u5Kze3MvPOoVW8B5MOHt3YPONxJWg?= =?us-ascii?q?QegMob1wonHIaeCEL9IfKrCk5yHMlLWFJ/uX3uN09TFZX/akHc5Hqo4m1aFh?= =?us-ascii?q?D2LwEgIOPzF8bbhNi20Obn/ZrVbk1IiTOxbKk0Ig+xqFDat9Idhs1pLaNixw?= =?us-ascii?q?=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,373,1599523200"; d="scan'208,217";a="623592167" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Nov 2020 02:51:25 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AR2pPoW027111 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 27 Nov 2020 02:51:25 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 26 Nov 2020 20:51:24 -0600 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 26 Nov 2020 20:51:23 -0600 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 26 Nov 2020 20:51:23 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=AJRH4lRzWlJ52wUnx2zmrBy16zpJrNIjX4WW96Tclkzp4xBhVXSZa/cPTvbZn5lEPoqr9QIDtKuFenEy8i5SvlL5Y8//BKQ7k1R6FdsO6Fr5pUb2Nv/50zCeWw7qrmHSZ2Tzo2qtoOQmxi36r2plCjee8jTujKqoqYBCUAQI7vX3T90xiH5Rh2pcOofVLq6bGKQhf1Dqd4AVUkLkqKNtHbxCHA7d3TsuW848HViuGTrxzzssWFb9VDBaU4Jzz3xnanq4QwUOvQoQc4GApikmnaRE2F2YatESPaAs1kA1Ml1EOAyAhXL//3JGlMV8jzbL3U/sU2dunmq57G1FYYEEjQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=gUtDdFkDzjdpPcFkE9Q3+iahyRQCKCXdmZxR30SnL9g=; b=MQe5kp+wmUBhHRb5AquR+uBFWCWGOUGypa+Qf03TrI58kXJ/0wwUEJbeQ7er+vXZD5/c0+ax1IO30R3MYe6JkpXe6ICZpeq+F3yPeq4XVNMecbT1ZC26XMiw56UYjuM/GvorFNCac8FxuCJd5xnCNP3At3kc6J1ygF4zpBhRJ19YUSMKHE5h77slxu1Bkr4iwZOc8qLtDYv8/xiU8vOHzYAh7NC6nzMinq7dnA10oPnMXjT+K0vatyVU0pklbJaeBtsC8Hiy10eDhWtHYp3QKXuoqmugQWeFhwQHH+/u/nLj9CsbHYV6TWIvbbrYVlNEszonWxOOSvGiIjBYgzKcPQ== 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=gUtDdFkDzjdpPcFkE9Q3+iahyRQCKCXdmZxR30SnL9g=; b=lI25RDMIj/zgnoTiOQPMwhu+v8HS2QE2DG5ATr0NpTDFCsKCs5U9N5LQEZpHVPN1TqJVEH4a6KCb9dOfTiJw+4C8MsKYdGKmnDfYjWTl357+WVn0YFbGoDq8/pjUSQnglmpRFg1fykR9eZBsJLMjEc58qV5X5+iM0Vep1QVACGc= Received: from MWHPR11MB1742.namprd11.prod.outlook.com (2603:10b6:300:113::13) by CO1PR11MB4913.namprd11.prod.outlook.com (2603:10b6:303:9f::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.21; Fri, 27 Nov 2020 02:51:21 +0000 Received: from MWHPR11MB1742.namprd11.prod.outlook.com ([fe80::19ac:46a:36f1:4dfa]) by MWHPR11MB1742.namprd11.prod.outlook.com ([fe80::19ac:46a:36f1:4dfa%3]) with mapi id 15.20.3611.025; Fri, 27 Nov 2020 02:51:21 +0000 From: "Li Zhao (liz3)" To: Routing Over Low power and Lossy networks Thread-Topic: Make P-DAO bidirectional [extends] IETF 109 open Questions on P-DAO Thread-Index: AdbCZRGxaZJsqD20SLuISSoVqF9MEgAgkqIOABJ37jAAGm3GHQALqPgAACcj8zo= Date: Fri, 27 Nov 2020 02:51:21 +0000 Message-ID: References: , , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2001:420:588c:1252:ed42:30ae:45fa:1f11] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b5a9ab7a-f286-4634-8bf5-08d8927f52b9 x-ms-traffictypediagnostic: CO1PR11MB4913: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: W8dAxQP6vu9ys75VZQvVtAH8hwdNQpaniU6cSd++GXoJdSKs9knfkMZddiypXr0F6PsGanJdn7CeZlPrvUZJhtxy7c0VdYxf+TmjoFO/Doah+5ILEjVQNZhGUDPn1+CihT959p0qOAQu7XdPuiUjMPHXrlraksKpEzdKH35Rwy2sifcojsM/+QUOas5LwsNZ8Cn6U7t6mvoMZoHQHxVMT7yiUGmt9GAUDZalEAbFDSqw+4o0GRWCMQnBbbJTYao2dK45Y4tQmZvjRDJarezsuya467uKgNF99ODNqOoRU4tbnUgKVnZLSXexnwu/NvrhM1Xu02ty7nYvXmnOTCmb7TwtvKfu7icIdUXrYDm1Jz3JlLLOWETWknATdYBezrPb4cxDOYP0s/ZFg53AF7CQwQFyCsK3ztHc+shz956VCBoNOIFpDNA6RStfkjDrP15a1DfVxj1NnoPST/GxZ26IeA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MWHPR11MB1742.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(136003)(39860400002)(366004)(396003)(346002)(376002)(83380400001)(966005)(166002)(2906002)(478600001)(7696005)(71200400001)(6916009)(52536014)(8936002)(53546011)(9686003)(186003)(66446008)(33656002)(66476007)(316002)(5660300002)(76116006)(64756008)(66946007)(66556008)(55016002)(91956017)(86362001)(6506007)(8676002)(88722002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?Windows-1252?Q?LpTpzsyT1l1V3sL/aavzDSrCETKi9Bim6nwaLt0/+ep4NB+y/Db3NmzT?= =?Windows-1252?Q?Em6zz5QP1kz6pBmAzIHioOiEh203G9eks8LvFmVpJD16dvhgsYe/GUSi?= =?Windows-1252?Q?SNzz/oP5sDTDWUwoKQ6KdyPOr7bkX25ot0Z/qjzSaOjyEpgHhe90Gu/Q?= =?Windows-1252?Q?mj6mgmR43KBMYl1W55H6mwh3tNG9BiRHzq8ix35Gpb3JPOCA5wQogMV5?= =?Windows-1252?Q?O3x3PrkYDn5AmmKtb/+3bPKBG0jAKef50jfNiRMjticwP3AJwxMidEJR?= =?Windows-1252?Q?viesie7wgpvAG4nwos8/18koMHrEZxcTwNCXWg67jA4YJ41bPeGvidIM?= =?Windows-1252?Q?9xVLiTz/yQ+n8v8uCNhPVuDLdR7ROcbEKDojR8Xanss41R6Mj3G2g9ui?= =?Windows-1252?Q?5QHuLbO7kS9NcgyhcYltPC+bFTDt7yubp4EP/0IWPR5ayxYWqlgETEC1?= =?Windows-1252?Q?MA74NzCbC6hGHdDE+C1ueBaZzoJ7vEaoSiHxHeXwaQC+VlvmNt2JtccO?= =?Windows-1252?Q?5if4js4pmWytSdDtFtIMDnqDsO3Bi/seiXvJWMCrVpA1mo/CNbgVGJ7A?= =?Windows-1252?Q?/XPeKhUt9QmLPbP6T0tSjupafA0o20BLsLyMPtjo0MUu+zaxLt6Fcgla?= =?Windows-1252?Q?vh9M30m8ueGxVNIXKkijgPYcjdaPn/PfLC+2JrsIbNS40r0Q3AqAC1js?= =?Windows-1252?Q?L3kmEWb6Qd1tBL78yFKTj1gJeg51PW0cJr9UieY4xQI9YjKw1NX/2lYy?= =?Windows-1252?Q?ixzuxpfB4ouMw/c2FVbW+ZeY9RDSrHV170IkwHkGNZ5pp12zqvO3G8QY?= =?Windows-1252?Q?lJ4mU68dq8TOpP1JR2coqZonigSREP66RPwpBa6MHkRhU7771phIR1G1?= =?Windows-1252?Q?29EShkdtPGCYmXMEm9DfqGV/dWyspSdOE4IWCgEQPfrQVPcHR9g0YBQt?= =?Windows-1252?Q?9jf2NowjjwR+hXuYrXlyH74diBkB6e0hUbxzdXBdRpOKfoYpZyhouRai?= =?Windows-1252?Q?bBkueMPNUBuFdCmaOxHQg3DJ8HlJfxXgm/tjiRMe/D3QcdJQkYbRQwXS?= =?Windows-1252?Q?mXBWEerjLlTC8JGntg/vFUTs7V2/c9W+V2SlxTkJrp1powebexmxMgij?= =?Windows-1252?Q?KpKKyKOlWfmKxgffMrpX7UAgzZZFurhwmxBHoN4kIsKfLA=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MWHPR11MB17427CA37479A6A1BE99B6648CF80MWHPR11MB1742namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MWHPR11MB1742.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: b5a9ab7a-f286-4634-8bf5-08d8927f52b9 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Nov 2020 02:51:21.7619 (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: X2Es964TrNrp3LqzpArsFLZZHm6oTTBhsk7o0qMBFNPg8o/KvVmp/QMFSxNoSXbT X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR11MB4913 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questions on P-DAO 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, 27 Nov 2020 02:51:29 -0000 --_000_MWHPR11MB17427CA37479A6A1BE99B6648CF80MWHPR11MB1742namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello Pascal, It looks good for me. Only one question about ICMP errors. Section 7.9 of pdao-draft defines a new code for ICMPv6 error message "Err= or in Projected Route". Does it only work for ICMP errors sent to the main = Root? In non-storing PDAO, forwarder can=92t recognize whether data packet is in = PDAO instance. Forwarder should send ICMP Destination Unreachable error to = root (the source of the packet), then root generates ICMPv6 error message w= ith "Error in Projected Route=94 to main Root. Is it correct? In storing PDAO, forwarder can recognize the PDAO instance from the RPI. It= can send "Error in Projected Route=94 or =93Destination Unreachable error= =94 to root. Maybe we need more claims for which code forwarder should use. Best regards, Li From: Roll Date: Thursday, November 26, 2020 at 18:48 To: Routing Over Low power and Lossy networks Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questi= ons on P-DAO Hello Li In the packet, there=92s a bit in the RPI to say if the root is the source = or the destination. That=92s RFC 6550. I guess the discussion is related to the PDR and P-DAO, not data packet, th= ough it impacts the ICMP error reporting. In a packet along the P-Route, the idea was so far that the DODAG is a conv= ergecast to the destination so the destination is the root. If we say that = there=92s a single ingress and a single egress then the dodag is reversible= and either can be the root. If we want to support multicast tracks in the = future, then the ingress should be root. If the Track has a single ingress and a single egress, then the DODAG is re= versible into another DODAG and it does not matter which is root, so we can= make it bidir as Huimin asked. The storing mode P DAO would look a lot more like a DAO, as you pointed out= , if it goes towards the root. If we want to take that path, a node could l= earn both directions with a single storing mode P DAO. To be continued=85 For non-storing, making bidir is really hard. It seems easier to install a = Track in both directions and couple them. As a summary of the proposed changes: General - we make the root the ingress - ICMP errors sent to the Root, using the main DODAG if the track is not re= versible Storing mode P DAO: - we also make the root the ingress, P-DAO from egress to ingress are now m= ore similar to RPL DAO operation - the track could be made bi-directional, but that=92s more code; if so: - the packet forwarding leverages the RPI to indicate the direction, from= or to root - ICMP errors sent to the Root, could be source or destination. Non storing mode P DAO: - tracks remain directional, can be coupled, how is tbd - the RPI is mostly useless since the intermediate nodes do not know the in= stance (they see neither the DIO nor the P-DAO); they have no idea of their= Rank. Still, it is interesting to have is for error determination in an IC= PMP error at eth root. It is also interesting if the SRH forwarding nodes h= ave a state associated to the Track, e.g., reserved time slots or priority = queues. - the RPI is still a SHOULD when there=92s no compression and a MUST when t= here is. We need to clarify what to do, that=92s another of Huimin=92s ques= tions, taken separately. - ICMP errors forwarding packets are sent to the root which is now the ingr= ess, aka the source of the packet, and the encapsulator field if the packet= is encapsulated and compressed. This is common to any non-storing operatio= n, whether it is a main Instance, local Instance, or Track. The RPI therein= is useful to indicate the Track in Error. So for that matter the forwarder= does not need to make a difference Track vs. other form of RPL local insta= nce. - this impacts the discussion in SRH reloading we had at IETF 109, when a = N-S mode loose track is forwarded along a segment that is also NS mode. We= =92ll probably need to re-encapsulate now. In case of re-encapsulation, th= e re-encapsulator becomes source and root of the segment, which now has to = be considered as a serial Track; as tunnel headends do, it will have to dec= apsulate the tunneled packet to send the packet in error back to the ingres= s of the loose track Doe that work? Pascal From: Roll On Behalf Of Li Zhao (liz3) Sent: jeudi 26 novembre 2020 03:45 To: Routing Over Low power and Lossy networks Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questi= ons on P-DAO Hello Pascal, If either source or destination can be root, it=92s better to identify when= or in which case source or destination can be root. Otherwise, it=92s hard= to interop between different implement even though they both follow RFC st= andard. E.g. for non-storing mode PDAO, if source is root, PCE only responses PDR-A= CK after receiving PDR from source. But if destination is root, PCE should also notify destination which tracki= d is used. Maybe we need bring new message for this notification? Take care, Li From: Roll > Date: Wednesday, November 25, 2020 at 21:54 To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questi= ons on P-DAO Hello Li; Well noted. This was the original intent. The change was made to egress bec= ause the idea was that the track could enable multiple sources to reach the= egress, like a tree rooted at the egress that flows traverse going down. B= ut the idea of a bidirectional track kinda blocks that idea and the other i= ssues like the one you point out seem to get us back to the original view. = I recently made the change from ingress to egress in the 6TiSCH architectur= e, waiting in RFC editor queue. I could reverse back, or maybe say =93eithe= r source or destination=94 so it can be egress or egress and we are covered= for bidirectional. What do you think? Or should a reversable Track be really a pair of tracks? Keep safe; Pascal From: Roll > On Behalf = Of Li Zhao (liz3) Sent: mercredi 25 novembre 2020 05:57 To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questi= ons on P-DAO Hello Pascal, Ingress as Root looks better because 1. It is consistent with the way RPL usually works. RPL Local instance, ao= dv-rpl, p2p-rpl all use ingress as root. 2. For non-storing-mode P-DAO, currently ingress sends upward traffic to e= gress(root) with SR header. But in RPL, only downward traffic carries SR he= ader. 3. Only ingress can send PDR makes sense. Behavior of TrackId is similar a= s Local Instance ID. Ingress as root can propose TrackId from its namespace= . And for storing-mode P-DAO, if we make ingress as root and ingress sends PD= R, can PCE send P-DAO to egress then egress forwards it towards predecessor= to ingress? Maybe it helps to make P-DAO looks like a DAO message. Best regards, Li From: Roll > Date: Tuesday, November 24, 2020 at 21:39 To: Routing Over Low power and Lossy networks > Subject: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questions = on P-DAO Dear all Whether to make the P-DAO bidirectional is an intriguing question. It could= be done, just like we can send packets DOWN a classical DODAG. But if we take that path, we reopen the question of who is root and which d= irection the P-DAO flies. Could we make either the ingress OR the egress root? How does it matter? At the moment the Root is the egress and the storing-mode P-DAO flies from = the Track egress to the track ingress, and the track egress is the root. Th= is is not the way RPL usually works as the DAO flies towards the root. The = reason was that we wanted a single egress for the Track, as we build unicas= t Track. If we wanted to build multicast Tracks the root should logically b= e the ingress. And for bidirectional Tracks it could be either. Up to -24 the 6TiSCH Architecture expected the ingress to be root. I change= d in the latest to map we do here, that it is the egress; maybe a flag in t= he DAO would indicate which direction the flow, from root, to root, or both= ? Also if we build bidir Tracks in storing mode, the nodes that forward the D= AO will have to build routes in both directions based on the P-DAO, both to= wards egress and ingress; but only the path from which the P-DAO comes has = been validated by the P-DAO itself. Should we send a P-DAO to each end, eac= h setting up one way? Please let me know your thoughts Pascal From: Roll > On Behalf = Of Pascal Thubert (pthubert) Sent: mardi 24 novembre 2020 14:22 To: Routing Over Low power and Lossy networks > Subject: [Roll] IETF 109 open Questions on P-DAO Dear all The slides for the P-DAO discussion at IETF 109 are available here: https://datatracker.ietf.org/doc/slides-109-roll-dao-projection/ There are a number of open questions that we starting discussing, and would= need to progress on the list. Some of them were expressed on the list, e.g., from Huimin She. I=92d like = to progress on them all with individual threads. The questions are: 1. Lifetime Unit: could we use a different unit for P-DAO? 2. How to differentiate a P-DAO from a normal DAO in a local instance; n= ew flag? 3. Make P-DAO bidirectional? 4. Who sends the PDR? Does it have to be the ingress? If it was egress i= t could propose a TrackId from its namespace. Else could the ingress be the= root? 5. Maintaining the sibling state. Should we have text on using RFC 8505 = there? 6. Whether ingress and egress are listed in NPO? Today they are both, in= gress to indicate the packet source in case of encapsulation and for SRH-6L= oRH compression reference and egress to build the full SRH-6LoRH. Note that= the ingress must consume the first entry and use it as source. 7. Track in Track vs. SR Header reload models, see slides Let me open threads to follow up. Keep safe Pascal --_000_MWHPR11MB17427CA37479A6A1BE99B6648CF80MWHPR11MB1742namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hello Pascal,

 

It looks good for me. Only one = question about ICMP errors.

 

Section 7.9 of pdao-draft defin= es a new code for  ICMPv6 error message "Error in Projected Route= ". Does it only work for ICMP errors sent to the main Root?

In non-storing PDAO, forwarder = can=92t recognize whether data packet is in PDAO instance. Forwarder should= send ICMP Destination Unreachable error to root (the source of the = packet), then root generates ICMPv6 error message with "Erro= r in Projected Route=94 to main Root.  Is it correct?

In storing PDAO, forwarder can = recognize the PDAO instance from the RPI. It can send "Error in Projected Route=94 or  =93<= /span>Destination Unreachable error=94 to root. Maybe we need more claims for which code forwarder = should use.

 

 

Best regards,=

Li

 

 

 

From: Roll <roll-bounc= es@ietf.org>
Date: Thursday, November 26, 2020 at 18:48
To: Routing Over Low power and Lossy networks <roll@ietf.org><= br> Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open= Questions on P-DAO

Hello Li

 

In the packet, there=92s a bit in the RPI to say if = the root is the source or the destination. That=92s RFC 6550.

I guess the discussion is related to the PDR and P-D= AO, not data packet, though it impacts the ICMP error reporting.=

 

In a packet along the P-Route, the idea was so far t= hat the DODAG is a convergecast to the destination so the destination is th= e root. If we say that there=92s a single ingress and a single egress then = the dodag is reversible and either can be the root. If we want to support multicast tracks in the future, then th= e ingress should be root.

 

If the Track has a single ingress and a single egres= s, then the DODAG is reversible into another DODAG and it does not matter w= hich is root, so we can make it bidir as Huimin asked.

The storing mode P DAO would look a lot more like a = DAO, as you pointed out, if it goes towards the root. If we want to take th= at path, a node could learn both directions with a single storing mode P DA= O. To be continued=85

 

For non-storing, making bidir is really hard. It see= ms easier to install a Track in both directions and couple them.=

 

As a summary of the proposed changes:

 

General

- we make the root the ingress

- ICMP errors sent to the Root, using the main DODAG= if the track is not reversible

 

 

Storing mode P DAO:

- we also make the root the ingress, P-DAO from egre= ss to ingress are now more similar to RPL DAO operation

- the track could be made bi-directional, but that= =92s more code; if so:

  - the packet forwarding leverages the RPI to = indicate the direction, from or to root

  - ICMP errors sent to the Root, could be sour= ce or destination.

 

Non storing mode P DAO:

- tracks remain directional, can be coupled, how is = tbd

- the RPI is mostly useless since the intermediate n= odes do not know the instance (they see neither the DIO nor the P-DAO); the= y have no idea of their Rank. Still, it is interesting to have is for error= determination in an ICPMP error at eth root. It is also interesting if the SRH forwarding nodes have a state = associated to the Track, e.g., reserved time slots or priority queues.=

- the RPI is still a SHOULD when there=92s no compre= ssion and a MUST when there is. We need to clarify what to do, that=92s ano= ther of Huimin=92s questions, taken separately.

- ICMP errors forwarding packets are sent to the roo= t which is now the ingress, aka the source of the packet, and the encapsula= tor field if the packet is encapsulated and compressed. This is common to a= ny non-storing operation, whether it is a main Instance, local Instance, or Track. The RPI therein is useful= to indicate the Track in Error. So for that matter the forwarder does not = need to make a difference Track vs. other form of RPL local instance.<= /o:p>

- this impacts the discussion in SRH reloading we ha= d at IETF 109, when a  N-S mode loose track is forwarded along a segme= nt that is also NS mode. We=92ll probably need to re-encapsulate now. = In case of re-encapsulation, the re-encapsulator becomes source and root of the segment, which now has to be considered as = a serial Track; as tunnel headends do, it will have to decapsulate the tunn= eled packet to send the packet in error back to the ingress of the loose tr= ack

 

 

Doe that work?

 

Pascal

 

From: Roll <roll-bounces@ietf.org> O= n Behalf Of Li Zhao (liz3)
Sent: jeudi 26 novembre 2020 03:45
To: Routing Over Low power and Lossy networks <roll@ietf.org><= br> Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open= Questions on P-DAO

 

Hello Pascal,

 

If either source or destination can be root, it=92s = better to identify when or in which case source or destination can be root.= Otherwise, it=92s hard to interop between different implement even though = they both follow RFC standard.

 

E.g. for non-storing mode PDAO, if source is root, P= CE only responses PDR-ACK after receiving PDR from source.

But if destination is root, PCE should also notify d= estination which trackid is used. Maybe we need bring new message for this = notification?

 

 

Take care,

Li

 

From: Roll <roll= -bounces@ietf.org&g= t;
Date: Wednesday, November 25, 2020 at 21:54
To: Routing Over Low power and Lossy networks <roll@ietf.org= >
Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open= Questions on P-DAO

Hello Li;

 

Well noted. This was the original intent. The change= was made to egress because the idea was that the track could enable multip= le sources to reach the egress, like a tree rooted at the egress that flows= traverse going down. But the idea of a bidirectional track kinda blocks that idea and the other issues like = the one you point out seem to get us back to the original view. I recently = made the change from ingress to egress in the 6TiSCH architecture, waiting = in RFC editor queue. I could reverse back, or maybe say =93either source or destination=94 so it can be egress = or egress and we are covered for bidirectional.

What do you think?

Or should a reversable Track be really a pair of tra= cks?

 

Keep safe;

 

Pascal

 

From: Roll <roll-bounces@ietf.org> On Behalf Of Li Zhao (liz3)
Sent: mercredi 25 novembre 2020 05:57
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open= Questions on P-DAO

 

Hello Pascal,

 

Ingress as Root looks better because

1.  It is consistent with the way RPL usually w= orks. RPL Local instance, aodv-rpl, p2p-rpl all use ingress as root.

2.  For non-storing-mode P-DAO, currently ingre= ss sends upward traffic to egress(root) with SR header. But in RPL, only do= wnward traffic carries SR header.

3.  Only ingress can send PDR makes sense. Behavior of TrackId is similar as Local= Instance ID. Ingress as root can propose TrackId from its namespace.

 

 

And for storing-mode P-DAO, if we make ingress as ro= ot and ingress sends PDR, can PCE send P-DAO to egress then egress forwards= it towards predecessor to ingress?

Maybe it helps to make P-DAO looks like a DAO messag= e.

 

 

Best regards,

Li

 

 

From: Roll <roll= -bounces@ietf.org&g= t;
Date: Tuesday, November 24, 2020 at 21:39
To: Routing Over Low power and Lossy networks <roll@ietf.org= >
Subject: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Que= stions on P-DAO

Dear all

 

Whether to make the P-DAO bidirectional is an intrig= uing question. It could be done, just like we can send packets DOWN a class= ical DODAG.

But if we take that path, we reopen the question of = who is root and which direction the P-DAO flies.

 

Could we make either the ingress OR the egress root?= How does it matter?

 

At the moment the Root is the egress and the storing= -mode P-DAO flies from the Track egress to the track ingress, and the track= egress is the root. This is not the way RPL usually works as the DAO flies= towards the root. The reason was that we wanted a single egress for the Track, as we build unicast Track. I= f we wanted to build multicast Tracks the root should logically be the ingr= ess. And for bidirectional Tracks it could be either.

 

Up to -24 the 6TiSCH Architecture expected the ingre= ss to be root. I changed in the latest to map we do here, that it is the eg= ress; maybe a flag in the DAO would indicate which direction the flow, from= root, to root, or both?

 

Also if we build bidir Tracks in storing mode, the n= odes that forward the DAO will have to build routes in both directions base= d on the P-DAO, both towards egress and ingress; but only the path from whi= ch the P-DAO comes has been validated by the P-DAO itself. Should we send a P-DAO to each end, each setting up o= ne way?

 

Please let me know your thoughts

 

Pascal

 

 

From: Roll <roll-bounces@ietf.org> On Behalf Of Pascal Thubert (pthubert)
Sent: mardi 24 novembre 2020 14:22
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Subject: [Roll] IETF 109 open Questions on P-DAO

 

Dear all

 

The slides for the P-DAO discussion at IETF 109 are = available here:

 

https://datatracker.ietf.org/doc/slides-109-roll-d= ao-projection/

 

There are a number of open questions that we startin= g discussing, and would need to progress on the list.

Some of them were expressed on the list, e.g., from = Huimin She. I=92d like to progress on them all with individual threads.

The questions are:

 

  1. Lifetime Unit: could we use a different unit for P-DAO?
  2. How to differentiate a P-DAO from a normal DAO in a local instance;= new flag?
  3. Make P-DAO bidirectional?
    4. Who sends the PDR? Does it have to be the ingress? If it was egress it = could propose a TrackId from its namespace. Else could the ingress be the r= oot?
  4. Maintaining the sibling state. Should we have tex= t on using RFC 8505 there?
  5. Whether ingress and egress = are listed in NPO? Today they are both, ingress to indicate the packet sour= ce in case of encapsulation and for SRH-6LoRH compression reference and egr= ess to build the full SRH-6LoRH. Note that the ingress must consume the first = entry and use it as source.
  6. Track in Track vs. SR Head= er reload models, see slides

 

Let me open threads to follow up.

 

Keep safe

 

Pascal

 

 

--_000_MWHPR11MB17427CA37479A6A1BE99B6648CF80MWHPR11MB1742namp_-- From nobody Thu Nov 26 23:43:57 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A34713A1464 for ; Thu, 26 Nov 2020 23:43:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.9 X-Spam-Level: X-Spam-Status: No, score=-11.9 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_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=XpJ5w5VK; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=uGfdYUcL 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 XuHQ08EUtKeh for ; Thu, 26 Nov 2020 23:43:53 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9E1993A1466 for ; Thu, 26 Nov 2020 23:43:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17475; q=dns/txt; s=iport; t=1606463033; x=1607672633; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=SaTf9pcTNIuG4mpcCXXVwSu/DVnFCMWJe94eNheIf1w=; b=XpJ5w5VKnjxsq3TVJPJTOEz7ndfm9cO0wYVclWTaLIBSXoTX93/gego5 UZ0pBAZbHqFAdvbUdQ1P5buTgnlYoioC5PxC596QrBib0PWqiEj5rfWYW iByB92KyLNShjcHJckd6OGkqc7bxzuWL796Xsm+w0OrZdUxqyG1uSgwhC w=; X-IPAS-Result: =?us-ascii?q?A0DRCAC3rMBffZtdJa1igQmCci9RfFovLogGA41ckH+IB?= =?us-ascii?q?oFCgREDVAsBAQENAQEjCgIEAQGESgKCKQIlOBMCAwEBAQMCAwEBAQEFAQEBA?= =?us-ascii?q?gEGBBQBAYY8DIVyAQEBBBIbEwEBOA8CAQgRBAEBLzIdCAEBBBMIGoMFgX5XA?= =?us-ascii?q?y4BDqRiAoE8iGl0gTSDBAEBBYE3BAxBgycYghADBoE4gnOKTRuBQT+BEESCV?= =?us-ascii?q?T6BBIFZAgMBgSEcICQHgx2CLJECihqdSgqCbokXiV+IV6IRnmmVZgIEAgQFA?= =?us-ascii?q?g4BAQWBbSGBWXAVO4JpUBcCDZIShRSFRHQ3AgYKAQEDCXyOYwEB?= IronPort-PHdr: =?us-ascii?q?9a23=3A85kHqhDWFhbOkTXY4qOWUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qw01g3IUJnVrfVehLmev6PhXDkG5pCM+DAHfYdXXh?= =?us-ascii?q?AIwcMRg0Q7AcGDBEG6SZyibyEzEMlYElMw+Xa9PBtUFdrwIVrIrS764TsbAB?= =?us-ascii?q?6qMw1zK6z8EZLTiMLi0ee09tXTbgxEiSD7b6l1KUC9rB7asY8dho4xJw=3D=?= =?us-ascii?q?3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,373,1599523200"; d="scan'208,217";a="623763386" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Nov 2020 07:43:52 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AR7hqjJ019152 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 27 Nov 2020 07:43:52 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-001.cisco.com (173.36.7.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 27 Nov 2020 01:43:52 -0600 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 27 Nov 2020 01:43:52 -0600 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 27 Nov 2020 01:43:51 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QNLfypCMqm/cM8/xs6lkWFBuQuNOVOTXbRERdE//0fvFgNfWIUTPj77yxo9LVGhRb7zo5qOLzgc3XWV+njfY2Uiet+ldyAwp2eoLkJtOn0/CAkV9ZlEeO/mtQ8Nnxf7k/1PaCziXb7VMvRydLgwtrETrblRuR9NK2/mUfyr/IcwMyERekGK0C/QvY3QFbAdFJ9nUCaNyjXfA1Qq3oq8b8+iudiGWcR8i9qm0ik/BryJCUIsGMLGDn8jdNrcU37Ka6gYLM5wZ1pH8a1OqUIF1A4q9D1DFHwBInqkX2FHD+l0bperqbC9s6HM6K1nnkgacCI9mxa5y6HhLX/U0CEKo5g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=NDz8RRAWd2KZcVkNhg6pTkgwUdgGHR9QSSLjRmalJYE=; b=esoNuuFNKQ4TMlNPS6o2PT1lT2o8Zk64KzZn378TmzL5Wh+CVqsW01MiMzsf3PHc35chYKAXYXYyZM/2GhKoeb5WS/8JVfePky0l6vt/Fn0frH4GlGILy88BhTk64ttpcVW9muFimYpAWvagS3pxMK+GMX5KqdEUutrAhj6l02w4HL6tHk8HEbTXXRfHQCXKgi2PSWcL6nBIONF+w42pwQC7SGNmTZ5bkvG9q6cTXd8INGDh/Y8NDOb/I1EJ98b92T5rdnG+QrsDSGhmMMaJyoPLFhJUjSFBQZm7K5yYsV8ZvVeW07O9eOLC78B6Ai485MRvba2oM22eu63ngNXUTA== 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=NDz8RRAWd2KZcVkNhg6pTkgwUdgGHR9QSSLjRmalJYE=; b=uGfdYUcLjzo0dyLWVV0eABTFaU7RfNm2gvyBqLqIex11S0B6KfJq+qZHzePmWcd81atG2muj7ixFsQOV3eCvWfbCCXwHK8jOcRHgzNVw+rkM8LsCznROQ3VAnB8ZXciVZGXkkk7nyFT2ztr8KW/2gUFFRIdWntyakTm1NQErgs4= Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by CO1PR11MB5091.namprd11.prod.outlook.com (2603:10b6:303:6c::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.22; Fri, 27 Nov 2020 07:43:51 +0000 Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::fc25:3e72:3e83:7df6]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::fc25:3e72:3e83:7df6%4]) with mapi id 15.20.3564.025; Fri, 27 Nov 2020 07:43:51 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: IETF 109 open Questions on P-DAO Thread-Index: AdbCY32NelMcR5MvThCvhSSTyZHQKgCLIpZA Date: Fri, 27 Nov 2020 07:43:18 +0000 Deferred-Delivery: Fri, 27 Nov 2020 07:43:14 +0000 Message-ID: References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2a01:cb1d:4ec:2200:7891:aeba:23f1:629c] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c74a865e-b0d6-4349-6cdd-08d892a82ec9 x-ms-traffictypediagnostic: CO1PR11MB5091: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: zAF9zv7rYFcHv9+Fj1vhPeFKz/5xdQNrgzz626fZQRfpyE5l5jhyqvsrRGJlLHyY1+9Q5DmA8WzQp4sOT7nip9nWP/tQPwfCPI0oXH7Qbbt82XvIUuqk7KE3kSSfnH048RtyeZd9yVTWmLPE95V/uwkap26H0lHK8j4MxTLVlk/xwWwT8hhCla8/UcwDQiYb5AFtXxGpf6eNZ9kGwuToXMjUb3+zB3FjjIscrsMcNwD2mL2kVc15ssxX6AJiL9+bu94JbHm4Az0Zp0jEs289mvQ1yHIbRyXtQPU7G1/8ipEIlz8S/Uue8SzdbdRVa5lIbTzJ2fF5Nok10XKAKz21tVKS+MayaqDkKJQI3auKnMwG4AfW09+acqRlox1mGlrlmTTIYSWTiUjfeNoiN7emTQ== 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:(376002)(346002)(366004)(39860400002)(136003)(396003)(66946007)(186003)(7696005)(9686003)(53546011)(2906002)(6506007)(966005)(6916009)(478600001)(316002)(55016002)(6666004)(33656002)(66476007)(64756008)(76116006)(66446008)(66556008)(8676002)(166002)(5660300002)(86362001)(71200400001)(83380400001)(8936002)(52536014); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?4qGZyRnyPH5hnWGxPIpzcWHNiNHN9RUJdzttzpaqE3ZUVp0H/+7b+SUnnIOw?= =?us-ascii?Q?QVNJwIxV3+tW8A8IUoCIJ+ujOeq2kgEacrLR/xwFOCmITi1BPAb386H8Pxqn?= =?us-ascii?Q?6ebS3S6JNbfyFObjVFqzLVsEDrKw7mK0GGg9a8vawv3O6kx9rKcAAs+er2X9?= =?us-ascii?Q?xKciLW5iuKnI/ilf87ptEoIf79Ds4jxq1TTJ1u3tu47YGSq1UxMSY3+Q5ChA?= =?us-ascii?Q?giHkJYz6H7t4URDhsR8lxEV8FQKMun7jA8ovmFR9DBTzpg5Rm417hU277WF7?= =?us-ascii?Q?vrLsRl8Cxx/s0KgUa439TQpYdEuVMP1YGM/zWJPmbxsHEQxWmN/x50ycPcrw?= =?us-ascii?Q?kuRsuvN3TfI1ecrm2p1Mu8Mjciz2R5Sk0CBi3FEvSXG6LIdQJ5rETzJxocVR?= =?us-ascii?Q?6/psXEsBrArDK2OO2fMnoYsIQTzo7EiXnwiLAQI5KbM3i0zsHSQLdCbxwIjn?= =?us-ascii?Q?05XOU70YyEnlRZLTnah2qIoDHELtU74bIgqkOwkTHxIr5vWY7ZK+7XbdwuYU?= =?us-ascii?Q?QhamDLdWq+sXeqDc4kWwP2Weonab7+/aloWAFF378SRi/qCP66XSg7tDBvT5?= =?us-ascii?Q?IMQC9M+i9MHeEv1i91g6Fl6FaO6YYpxznJz9dy4vtmwH4ST0qMh+md4q+Idd?= =?us-ascii?Q?pNyd9iXK7WpW//LntXT7qk6MRsFEsIJaZQErL7L88G/rtguwHzLbOjtbpb4g?= =?us-ascii?Q?fzXhxRIyMohvoxEoHKWld7S5N8cDMkN/J60BN3aRO193Lrxscb6tW3aNiHLE?= =?us-ascii?Q?91YilNJu/HJwNthhnKnR4RYW7q/1Q1WC+9a8lThIPcIX3f3KYAOGxZeSQZQJ?= =?us-ascii?Q?0aA/ChuUiqTNI/vsgi2+kWoV7AlVSCti3Vt4IHL+ueCH3tjK+f+LvLSSUV4d?= =?us-ascii?Q?eL0lFgIoWjdMtbWNHzAeANl7H9w936phuMLcG/mTf8561aSDRz8Gs+2OWQSl?= =?us-ascii?Q?8m9loH7JZgw6My+a3KaT9pkUb1uUjyRuODuryX1ErK/e+xG/C9NxbOH2S0TX?= =?us-ascii?Q?JdiqXFcBWtoHppV9I5bs/HAgGJqq+S3i9zlsF5Uzh2o0bpDOZnNgWBBrEGx+?= =?us-ascii?Q?2ST7BE5z?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CO1PR11MB48818AF6B81AED230CF30B92D8F80CO1PR11MB4881namp_" 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: c74a865e-b0d6-4349-6cdd-08d892a82ec9 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Nov 2020 07:43:50.8196 (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: FfZuenYZr+i+VWtT5e1EC1fQZQWs7Fo18N4ZgrFj1+2vGLTl3z2oCj+hLSn4k1Q+33Le5pk1kEvuvXeSSqZImQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: CO1PR11MB5091 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: Re: [Roll] IETF 109 open Questions on P-DAO 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, 27 Nov 2020 07:43:57 -0000 --_000_CO1PR11MB48818AF6B81AED230CF30B92D8F80CO1PR11MB4881namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all: Updating the list: 1. Lifetime Unit: could we use a different unit for P-DAO? 2. How to differentiate a P-DAO from a normal DAO in a local instance; n= ew flag? 3. Make P-DAO bidirectional? 4. Who sends the PDR? Does it have to be the ingress? If it was egress i= t could propose a TrackId from its namespace. Else could the ingress be the= root? 5. Maintaining the sibling state. Should we have text on using RFC 8505 = there? 6. Whether ingress and egress are listed in NPO? Today they are both, in= gress to indicate the packet source in case of encapsulation and for SRH-6L= oRH compression reference and egress to build the full SRH-6LoRH. Note that= the ingress must consume the first entry and use it as source. 7. Track in Track vs. SR Header reload models, see slides 8. Error flows, which ICMP errors and to which root? The draft should pr= esent the flows. 9. how can the Main Root find an available TrackID? Keep safe; Pascal From: Pascal Thubert (pthubert) Sent: mardi 24 novembre 2020 14:22 To: Routing Over Low power and Lossy networks Subject: IETF 109 open Questions on P-DAO Dear all The slides for the P-DAO discussion at IETF 109 are available here: https://datatracker.ietf.org/doc/slides-109-roll-dao-projection/ There are a number of open questions that we starting discussing, and would= need to progress on the list. Some of them were expressed on the list, e.g., from Huimin She. I'd like to= progress on them all with individual threads. The questions are: 1. Lifetime Unit: could we use a different unit for P-DAO? 2. How to differentiate a P-DAO from a normal DAO in a local instance; n= ew flag? 3. Make P-DAO bidirectional? 4. Who sends the PDR? Does it have to be the ingress? If it was egress i= t could propose a TrackId from its namespace. Else could the ingress be the= root? 5. Maintaining the sibling state. Should we have text on using RFC 8505 = there? 6. Whether ingress and egress are listed in NPO? Today they are both, in= gress to indicate the packet source in case of encapsulation and for SRH-6L= oRH compression reference and egress to build the full SRH-6LoRH. Note that= the ingress must consume the first entry and use it as source. 7. Track in Track vs. SR Header reload models, see slides Let me open threads to follow up. Keep safe Pascal --_000_CO1PR11MB48818AF6B81AED230CF30B92D8F80CO1PR11MB4881namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all:

 

Updating the list:

 

  1. Li= fetime Unit: could we use a different unit for P-DAO?
  2. How to differentiate a P-DAO from a normal DAO in a local instance; n= ew flag?
  3. Make P-DAO bidirectional?
  4. Who sends the PDR? Does it have to be the ingress? If it was= egress it could propose a TrackId from its namespace. Else could the ingress be the root?
  5. Maintaining the = sibling state. Should we have text on using RFC 8505 there?
  6. Whether ingress and egress are listed in NPO? Today they are bo= th, ingress to indicate the packet source in case of encapsulation and for SRH-6LoRH compression reference and egress to build the full SRH-6= LoRH. Note that the ingress must consume the first entry and use it as sour= ce.
  7. Track in Track vs. SR Header reload models, = see slides
  8. Error flows, which ICMP errors and to= which root? The draft should present the flows.
  9. how can the Main Root find an available TrackID?

 

Keep safe;

 

Pascal

 

 

 

From: Pascal Thubert (= pthubert)
Sent: mardi 24 novembre 2020= 14:22
To: Routing Over Low power a= nd Lossy networks <roll@ietf.org>
Subject: IETF 109 open Quest= ions on P-DAO

 

Dear all

 

The slides for the P-DAO discussion at IETF 109 are availabl= e here:

 

https://datatracker.ietf.org/doc/slides-109-roll-dao-proje= ction/

 

There are a number of open questions that we starting discus= sing, and would need to progress on the list.

Some of them were expressed on the list, e.g., from Huimin S= he. I’d like to progress on them all with individual threads.

The questions are:

 

  1. Li= fetime Unit: could we use a different unit for P-DAO?
  2. How to differentiate a P-DAO from a normal DAO in a local instance; n= ew flag?
  3. Make P-DAO bidirectional?
  4. Who sends the PDR? Does it have to be the ingress? If it was= egress it could propose a TrackId from its namespace. Else could the ingress be the root?
  5. Maintaining the = sibling state. Should we have text on using RFC 8505 there?
  6. Whether ingress and egress are listed in NPO? Today they are bo= th, ingress to indicate the packet source in case of encapsulation and for SRH-6LoRH compression reference and egress to build the full SRH-6= LoRH. Note that the ingress must consume the first entry and use it as sour= ce.
  7. Track in Track vs. SR Header reload models, = see slides

 

Let me open threads to follow up.

 

Keep safe

 

Pascal

 

 

--_000_CO1PR11MB48818AF6B81AED230CF30B92D8F80CO1PR11MB4881namp_-- From nobody Thu Nov 26 23:48:30 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C441A3A1475 for ; Thu, 26 Nov 2020 23:48:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.919 X-Spam-Level: X-Spam-Status: No, score=-11.919 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_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=XucvXDd2; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=dpHuLGSS 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 l7rIxgocDv7g for ; Thu, 26 Nov 2020 23:48:25 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3E0643A1471 for ; Thu, 26 Nov 2020 23:48:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=57684; q=dns/txt; s=iport; t=1606463305; x=1607672905; h=from:to:subject:date:message-id:mime-version; bh=cDEWL8JYxUPrKcSFd96LHnDE/ZON00K3ZeR3iMfIw08=; b=XucvXDd2famCP+S1Ie9V1ioRFUZZokRGIkt6fHlqSuN7ia7/QdeQBzVG P3rLOjTCw315psuvp53VJolNrKaPvsKVdveGVL8Tb/h5HFV1XMrTZ7sdp OzRQ5yif9/JjjYeuwT3VeReOuiY1K0TYBtTFBkZVBKcBK66RIU0IDBVn+ o=; X-IPAS-Result: =?us-ascii?q?A0CuCQDhrcBf/5xdJa1YCh4BAQsSDECCcgEuKSgHdVovL?= =?us-ascii?q?ogGA41dkH+IBoFCgREDVAsBAQENAQElCAIEAQGESgKCKQIlOBMCAwEBAQMCA?= =?us-ascii?q?wEBAQEFAQEBAgEGBHGFNAglDIVyAQEEEwgTEwEBJRMEDQEZAQIBAQEhAQY5F?= =?us-ascii?q?AMGCQEEEwgagwWBflcDDiABDqRhAoE8iGl0gTSDBAEBBYE3BAxBgzQYghADB?= =?us-ascii?q?oE4gnOCZk6HGRuBQT+BEAFDgVdQbIEEgVkBAQIBAYEhDQ8gHgYHCYMUgiyRA?= =?us-ascii?q?ooajByRLgqCbgSJE4lfiFeCYTuKHJRZnmmRKoQ8AgQCBAUCDgEBBYFtI4FXc?= =?us-ascii?q?BU7gmlQFwINh36GIzduAQeCRIUUhUR0AjUCBgoBAQMJfIwfLYIXAQE?= IronPort-PHdr: =?us-ascii?q?9a23=3ABEyNmB8pPw9y2v9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+7ZRaN5PhxghnOR4qIo/5Hiu+DtafmVCRA5Juaq3kNfdRKUA?= =?us-ascii?q?NNksQZmQEsQavnQU32JfLndWo2ScJFUlI2/nynPw5SAsmtL1HXq2e5uDgVHB?= =?us-ascii?q?i3PAFpJ+PzT4jVicn/1+2795DJJQtSgz/oarJpJxLwpgLU5cQ=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,373,1599523200"; d="scan'208,217";a="594860881" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Nov 2020 07:48:23 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AR7mN2B032603 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 27 Nov 2020 07:48:23 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 27 Nov 2020 01:48:23 -0600 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 27 Nov 2020 01:48:22 -0600 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 27 Nov 2020 01:48:22 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=enP6eCy6fJ1CYjqnxsjK6y8KsK92vsl1JG44H2eMHqmBGaoF96WNfPMijz9KG+UMf1cpG1yWt0IfQ7LMlIPA4MJd/2VsUWhf5vnVJemce49k16OAIKxyAhIw4rQ4NiL3rPVpgWh+s9vaYs7jOfMh5ntW/y/JQU8TlUDoYx2sK/tHPBa/NSCGpk2BQD/fC5y7ZHbWM1NR5lCYgiYKaxMmrCy4qbpNgFmji6HoHjjY48C9/4vdjuSIRaJP9Izdceb0V5Vav3ifVEg1GLEkKS+o3vbx+QdItHiojtckttzw5MwKwxhguIdQQU/J9JCn7+B8751TI+6cRLMQMBvtruIAqA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=e4hvsUp0+QAi90lIHdk8txdO3LDv4GIRt9QGnrKxjxY=; b=evR4oTgxTMMGYYaK6d3h/dMw3dqCEmBIN8COKIKTp/HZGBAGxqiH51sSZjjh7Y6sW8+XWTqGkKsjHrtW3vMdL8C/xBhUkaROi6ieAZJiLk/SeBUGeNgblaoO+xyWZOfS27SuU7pjFIRcrSnnjBfMEUMXPYPmXf/nR61b9SmdkPz9okpKOm1kbOQjqE274sbKGn75hzObS91XokkGa1YXWaq6ysGTt/WCvhH2bwVkDNobl8/PXy5ih2fZ+rZXR8surS0la7TN0lezfrPv2XvMSh6xeoY0p+BwsoC4elacD3RPCHXpvmoZjD+AQ/FrsQx+VSMj3FmSLzWjA175xSZkcw== 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=e4hvsUp0+QAi90lIHdk8txdO3LDv4GIRt9QGnrKxjxY=; b=dpHuLGSSobwLZSXOJ1wIYXdRQwr3SFeFcwbxfKZV0Zt2FHrwe3hPfRaz0JHhvJzKhQAB+zCyhrHn5fjf8/9kc4+u8sAfA41xCqcTUJmamzOMHNxB2UliBfSRVzq9VEV+uOhNotULT4PPxiEEShsVQyvVfUcMf4M+fwHiPzAR4t0= Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by MWHPR11MB1552.namprd11.prod.outlook.com (2603:10b6:301:e::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.20; Fri, 27 Nov 2020 07:48:21 +0000 Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::fc25:3e72:3e83:7df6]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::fc25:3e72:3e83:7df6%4]) with mapi id 15.20.3564.025; Fri, 27 Nov 2020 07:48:21 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: Error flows, which ICMP errors and to which root?: [extends] IETF 109 open Questions on P-DAO Thread-Index: AdbEkO8SsU8bA9FQQ86QQ+UeowvePg== Date: Fri, 27 Nov 2020 07:47:22 +0000 Deferred-Delivery: Fri, 27 Nov 2020 07:34:18 +0000 Message-ID: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2a01:cb1d:4ec:2200:7891:aeba:23f1:629c] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5a031386-57ac-49c9-8ac5-08d892a8cfbb x-ms-traffictypediagnostic: MWHPR11MB1552: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: j1vj1szumCJyQtqGzThGBn2q5OvlvJ/ruduuW3xTU8gAyWcvBZcP35ZNS6RvleQo3UOLkFPwbB3+lVg8bLN2hKDhrbmy3pmSDgKwhCXwQ0inF8ZMvOetxiMSf7zBl2Cx5uL4A5cTyqshxYM1WrWs1ObWhcM+zpVE6X2ENCTb5vJXd9dHl9Z6ohjrTtgbCJ8nubYYAvFCrHW3WZvIDfZ+jNRT8DAdOHQhm7gWD6Sz4ov1wHYGotDbgoj6TU72tX129ZnQ6LbMLenogSp01k/MNC/VPQG8G2zKRX+9o9wKktwfx8J6C5YCaOI5kQGoU7HWdl9sxas3T3zMtkO8JQuJl5bxMyXG0+v+Y/Tawdra+Kv0H+lZ7o02F8DlW6B8YtKHgWCWexy25lVp/T5e3NCD/w== 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:(136003)(346002)(376002)(366004)(39860400002)(396003)(53546011)(6506007)(7696005)(966005)(186003)(55016002)(9686003)(6916009)(30864003)(166002)(8936002)(76116006)(66446008)(33656002)(66946007)(64756008)(66476007)(66556008)(8676002)(83380400001)(2906002)(71200400001)(316002)(5660300002)(86362001)(478600001)(52536014); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?pcnqsn6YwxCOU3lL1vBYk1TqZ4l8e9z5nrl/TE4fNunGxoXYdHG0dkUV2+pi?= =?us-ascii?Q?Vq/nzrN9b0TCuqwT65gKMPefoPg7iMUpbihZ0x3n6NinQvGF/xVyBLTw6wkj?= =?us-ascii?Q?y8X1fN3ClCnHIWl2wMgHbXCuKDaOQFRP7azD3VLYSRj/sUDr90CwFOC8042o?= =?us-ascii?Q?K1qAp0UCjK27UzvyWLHX5d3M0/2EZXUElmRKIkxwypYViap5EAaMB5mnJ3M8?= =?us-ascii?Q?NyLRvXwOs51BbY7dPzDLbG3wEFC1HBpqSiV3VhW72IlDkfmb9n61bk5E523O?= =?us-ascii?Q?vR9cCSuqDGv/4gv3Q0yVaQ7vdgdC0ZonxcKEgsyB6dvBAe1NiRm4371bL+Vb?= =?us-ascii?Q?EBeIR7JGifMSWGODZ5lHpxlXkyaRyhrpOGdjv1jusYBXbo+MKDISAvOu6XWH?= =?us-ascii?Q?1OTtrEGnb6INXbcupF4BfIphH2JbJWTwtRKeivsJqOIvCWMm9wR9EE+5sLAd?= =?us-ascii?Q?1rBvkDLECDIP/49LoXXsuNv5wOkRZr1L+F+tR0ueDtYa8nD+ZAwO8crNE0s9?= =?us-ascii?Q?T04AeFHXI2z1XOG8izUha8fmpXhvLQqX6YvnegSM7mbq32iuf4Y5DkbdT1B2?= =?us-ascii?Q?umwFUeYMlHkF6Chl2BEXg0Ao3JW0BJidB8pyJPR0T/205xQY485OBdyBKoFZ?= =?us-ascii?Q?qcy4BlfFdK1QkvsZxC269joaEToLvQTxBZIYlYQmtWPBm3zy1kwXhLnwmWi3?= =?us-ascii?Q?Lr2LVtVoqIOvggR4dqXgKsFI9JnHylfrPVfwB7J2VCfEQOhyDQaqrl/emOsU?= =?us-ascii?Q?74YTy4sUfdsr0ij7vWK1PcY3eHLJOsI+L5NA+N5yCqEjibzhubWmNdHZOVQj?= =?us-ascii?Q?lKDsr/0bxngfuihy7Zvxbaob9WCE2fNWJWZeLbJltYdGIjnPuVeMVjowYyo8?= =?us-ascii?Q?eFofIfovIRJWkmdQ9OiRGjQO1qTOU7cOBdEXd9mEGr+6iZOvM9yGzMWc/GvN?= =?us-ascii?Q?dPcaTdCVqv5zHpTfL+YX1dF3dSNv0wUD8um9qevhNNfRBpmC+b4QZabskAIm?= =?us-ascii?Q?MVGjQ18d1ITopGyGozvJZo7dNyPT41tj+lxVG2QIz0Xa1uGj0FyMQTvZUmh1?= =?us-ascii?Q?kA//Zqrv?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CO1PR11MB4881A724B04EA29D32DC9C81D8F80CO1PR11MB4881namp_" 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: 5a031386-57ac-49c9-8ac5-08d892a8cfbb X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Nov 2020 07:48:20.8209 (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: lEtH8j1puTjYpC7ZVVgLm4hmPjtG75WyjUOMKE1AiqaYyq4T6D7T4emBRu7HYeZzPcGvLADSqFxDMOh3YCJZJw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1552 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: [Roll] Error flows, which ICMP errors and to which root?: [extends] IETF 109 open Questions on P-DAO 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, 27 Nov 2020 07:48:29 -0000 --_000_CO1PR11MB4881A724B04EA29D32DC9C81D8F80CO1PR11MB4881namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello Li This is the wrong thread. I created a new one. > Section 7.9 of pdao-draft defines a new code for ICMPv6 error message "E= rror in Projected Route". Does it only work for ICMP errors sent to the mai= n Root? Section 5 says " In case of a forwarding error along a Projected Route, an ICMP error is sent to the Root with a new Code "Error in Projected Route" (See Section 7.9). The Root can then modify or remove the Projected Route. The "Error in Projected Route" message has the same format as the "Destination Unreachable Message", as specified in RFC 4443 [RFC4443]. " So yes the intention was to send the ICMP to the main Root. But as you poin= t out the packet does not indicate it is following a P-route. This was rela= ted to storing mode P DAO. In non-storing the node does not know it's a P-r= oute. > In non-storing PDAO, forwarder can't recognize whether data packet is in = PDAO instance. Forwarder should send ICMP Destination Unreachable error to = root (the source of the packet), then root generates ICMPv6 error message w= ith "Error in Projected Route" to main Root. Is it correct? That would work. Seems neat. The alternate would be to signal it is a P rou= te in the RPI. That's item 2) in the list in this thread. If we do that the= current text works. What makes more sense to you? > In storing PDAO, forwarder can recognize the PDAO instance from the RPI. = It can send "Error in Projected Route" or "Destination Unreachable error" = to root. Maybe we need more claims for which code forwarder should use. We have to decide if we send it to the main root as written in the current = draft or to the Track Root. If the P route is reversible could be done that= way. But that's added complexity. I'm not very convinced either way. The O= kham razor could be to do the simplest. Keep safe! Pascal From: Roll On Behalf Of Li Zhao (liz3) Sent: vendredi 27 novembre 2020 03:51 To: Routing Over Low power and Lossy networks Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questi= ons on P-DAO Hello Pascal, It looks good for me. Only one question about ICMP errors. Section 7.9 of pdao-draft defines a new code for ICMPv6 error message "Err= or in Projected Route". Does it only work for ICMP errors sent to the main = Root? In non-storing PDAO, forwarder can't recognize whether data packet is in PD= AO instance. Forwarder should send ICMP Destination Unreachable error to ro= ot (the source of the packet), then root generates ICMPv6 error message wit= h "Error in Projected Route" to main Root. Is it correct? In storing PDAO, forwarder can recognize the PDAO instance from the RPI. It= can send "Error in Projected Route" or "Destination Unreachable error" to= root. Maybe we need more claims for which code forwarder should use. Best regards, Li From: Roll > Date: Thursday, November 26, 2020 at 18:48 To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questi= ons on P-DAO Hello Li In the packet, there's a bit in the RPI to say if the root is the source or= the destination. That's RFC 6550. I guess the discussion is related to the PDR and P-DAO, not data packet, th= ough it impacts the ICMP error reporting. In a packet along the P-Route, the idea was so far that the DODAG is a conv= ergecast to the destination so the destination is the root. If we say that = there's a single ingress and a single egress then the dodag is reversible a= nd either can be the root. If we want to support multicast tracks in the fu= ture, then the ingress should be root. If the Track has a single ingress and a single egress, then the DODAG is re= versible into another DODAG and it does not matter which is root, so we can= make it bidir as Huimin asked. The storing mode P DAO would look a lot more like a DAO, as you pointed out= , if it goes towards the root. If we want to take that path, a node could l= earn both directions with a single storing mode P DAO. To be continued... For non-storing, making bidir is really hard. It seems easier to install a = Track in both directions and couple them. As a summary of the proposed changes: General - we make the root the ingress - ICMP errors sent to the Root, using the main DODAG if the track is not re= versible Storing mode P DAO: - we also make the root the ingress, P-DAO from egress to ingress are now m= ore similar to RPL DAO operation - the track could be made bi-directional, but that's more code; if so: - the packet forwarding leverages the RPI to indicate the direction, from= or to root - ICMP errors sent to the Root, could be source or destination. Non storing mode P DAO: - tracks remain directional, can be coupled, how is tbd - the RPI is mostly useless since the intermediate nodes do not know the in= stance (they see neither the DIO nor the P-DAO); they have no idea of their= Rank. Still, it is interesting to have is for error determination in an IC= PMP error at eth root. It is also interesting if the SRH forwarding nodes h= ave a state associated to the Track, e.g., reserved time slots or priority = queues. - the RPI is still a SHOULD when there's no compression and a MUST when the= re is. We need to clarify what to do, that's another of Huimin's questions,= taken separately. - ICMP errors forwarding packets are sent to the root which is now the ingr= ess, aka the source of the packet, and the encapsulator field if the packet= is encapsulated and compressed. This is common to any non-storing operatio= n, whether it is a main Instance, local Instance, or Track. The RPI therein= is useful to indicate the Track in Error. So for that matter the forwarder= does not need to make a difference Track vs. other form of RPL local insta= nce. - this impacts the discussion in SRH reloading we had at IETF 109, when a = N-S mode loose track is forwarded along a segment that is also NS mode. We'= ll probably need to re-encapsulate now. In case of re-encapsulation, the r= e-encapsulator becomes source and root of the segment, which now has to be = considered as a serial Track; as tunnel headends do, it will have to decaps= ulate the tunneled packet to send the packet in error back to the ingress o= f the loose track Doe that work? Pascal From: Roll > On Behalf = Of Li Zhao (liz3) Sent: jeudi 26 novembre 2020 03:45 To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questi= ons on P-DAO Hello Pascal, If either source or destination can be root, it's better to identify when o= r in which case source or destination can be root. Otherwise, it's hard to = interop between different implement even though they both follow RFC standa= rd. E.g. for non-storing mode PDAO, if source is root, PCE only responses PDR-A= CK after receiving PDR from source. But if destination is root, PCE should also notify destination which tracki= d is used. Maybe we need bring new message for this notification? Take care, Li From: Roll > Date: Wednesday, November 25, 2020 at 21:54 To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questi= ons on P-DAO Hello Li; Well noted. This was the original intent. The change was made to egress bec= ause the idea was that the track could enable multiple sources to reach the= egress, like a tree rooted at the egress that flows traverse going down. B= ut the idea of a bidirectional track kinda blocks that idea and the other i= ssues like the one you point out seem to get us back to the original view. = I recently made the change from ingress to egress in the 6TiSCH architectur= e, waiting in RFC editor queue. I could reverse back, or maybe say "either = source or destination" so it can be egress or egress and we are covered for= bidirectional. What do you think? Or should a reversable Track be really a pair of tracks? Keep safe; Pascal From: Roll > On Behalf = Of Li Zhao (liz3) Sent: mercredi 25 novembre 2020 05:57 To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questi= ons on P-DAO Hello Pascal, Ingress as Root looks better because 1. It is consistent with the way RPL usually works. RPL Local instance, ao= dv-rpl, p2p-rpl all use ingress as root. 2. For non-storing-mode P-DAO, currently ingress sends upward traffic to e= gress(root) with SR header. But in RPL, only downward traffic carries SR he= ader. 3. Only ingress can send PDR makes sense. Behavior of TrackId is similar a= s Local Instance ID. Ingress as root can propose TrackId from its namespace= . And for storing-mode P-DAO, if we make ingress as root and ingress sends PD= R, can PCE send P-DAO to egress then egress forwards it towards predecessor= to ingress? Maybe it helps to make P-DAO looks like a DAO message. Best regards, Li From: Roll > Date: Tuesday, November 24, 2020 at 21:39 To: Routing Over Low power and Lossy networks > Subject: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questions = on P-DAO Dear all Whether to make the P-DAO bidirectional is an intriguing question. It could= be done, just like we can send packets DOWN a classical DODAG. But if we take that path, we reopen the question of who is root and which d= irection the P-DAO flies. Could we make either the ingress OR the egress root? How does it matter? At the moment the Root is the egress and the storing-mode P-DAO flies from = the Track egress to the track ingress, and the track egress is the root. Th= is is not the way RPL usually works as the DAO flies towards the root. The = reason was that we wanted a single egress for the Track, as we build unicas= t Track. If we wanted to build multicast Tracks the root should logically b= e the ingress. And for bidirectional Tracks it could be either. Up to -24 the 6TiSCH Architecture expected the ingress to be root. I change= d in the latest to map we do here, that it is the egress; maybe a flag in t= he DAO would indicate which direction the flow, from root, to root, or both= ? Also if we build bidir Tracks in storing mode, the nodes that forward the D= AO will have to build routes in both directions based on the P-DAO, both to= wards egress and ingress; but only the path from which the P-DAO comes has = been validated by the P-DAO itself. Should we send a P-DAO to each end, eac= h setting up one way? Please let me know your thoughts Pascal From: Roll > On Behalf = Of Pascal Thubert (pthubert) Sent: mardi 24 novembre 2020 14:22 To: Routing Over Low power and Lossy networks > Subject: [Roll] IETF 109 open Questions on P-DAO Dear all The slides for the P-DAO discussion at IETF 109 are available here: https://datatracker.ietf.org/doc/slides-109-roll-dao-projection/ There are a number of open questions that we starting discussing, and would= need to progress on the list. Some of them were expressed on the list, e.g., from Huimin She. I'd like to= progress on them all with individual threads. The questions are: 1. Lifetime Unit: could we use a different unit for P-DAO? 2. How to differentiate a P-DAO from a normal DAO in a local instance; n= ew flag? 3. Make P-DAO bidirectional? 4. Who sends the PDR? Does it have to be the ingress? If it was egress i= t could propose a TrackId from its namespace. Else could the ingress be the= root? 5. Maintaining the sibling state. Should we have text on using RFC 8505 = there? 6. Whether ingress and egress are listed in NPO? Today they are both, in= gress to indicate the packet source in case of encapsulation and for SRH-6L= oRH compression reference and egress to build the full SRH-6LoRH. Note that= the ingress must consume the first entry and use it as source. 7. Track in Track vs. SR Header reload models, see slides Let me open threads to follow up. Keep safe Pascal --_000_CO1PR11MB4881A724B04EA29D32DC9C81D8F80CO1PR11MB4881namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello Li

 

This is the wrong thread. I created a new one.

 

> Section 7.9= of pdao-draft defines a new code for  ICMPv6 error message "Erro= r in Projected Route". Does it only work for ICMP errors sent to the main Root?

 

Section 5 says “

 

   In case of a forwarding error along a Projected Route, an ICM=
P error
   is sent to the Root with a new Code "Error in Projected =
Route" (See
   Section 7.9).  The Root can then modify o=
r remove the Projected
   Route.  The "Error in Projected Route" message=
 has the same format as
   the "Destination Unreachable Message", as specified=
 in RFC 4443=

   [RFC4443]=
.

 

“

 

So yes the intention was to send the ICMP to the main Root. = But as you point out the packet does not indicate it is following a P-route= . This was related to storing mode P DAO. In non-storing the node does not know it’s a P-route.

 

 

> In non-storing PDAO, forwarder can’t recognize wh= ether data packet is in PDAO instance. Forwarder should send ICMP Destinati= on Unreachable error to root (the source of the packet), then root generates ICMPv6 error message with "Error in Projected Rou= te” to main Root.  Is it correct?

 

That would work. Seems neat. The alternate would be to signa= l it is a P route in the RPI. That’s item 2) in the list in this thre= ad. If we do that the current text works. What makes more sense to you?

 

> In storing PDAO, forwarder can recognize the PDAO insta= nce from the RPI. It can send "Error in Projected Route” or &nbs= p;“Destination Unreachable error” to root. Maybe we need more claims for which code forwarder should use.

 

We have to decide if we send it to the main root as written = in the current draft or to the Track Root. If the P route is reversible cou= ld be done that way. But that’s added complexity. I’m not very convinced either way. The Okham razor could be to do th= e simplest.

 

Keep safe!

 

Pascal

 

 

From: Roll <roll-bo= unces@ietf.org> On Behalf Of Li Zhao (liz3)<= br> Sent: vendredi 27 novembre 2= 020 03:51
To: Routing Over Low power a= nd Lossy networks <roll@ietf.org>
Subject: Re: [Roll] Make P-D= AO bidirectional [extends] IETF 109 open Questions on P-DAO

 

Hello Pascal,

 

It looks good for me. Only one question about ICMP errors.

 

Section 7.9 of pdao-draft defines a new code for  ICMPv= 6 error message "Error in Projected Route". Does it only work for= ICMP errors sent to the main Root?

In non-storing PDAO, forwarder can’t recognize whether data packe= t is in PDAO instance. Forwarder should send ICMP Destination Unreachable error to root (the source of the pac= ket), then root generates ICMPv6 error message with "Error in Projecte= d Route” to main Root.  Is it correct?

In storing PDAO, forwarder can recognize the PDAO instance from the RPI= . It can send "Error in Projected Route” or  “Destination Unreachable error” to root. Maybe we need m= ore claims for which code forwarder should use.

 

 

Best regards,

Li

 

 

 

From: Roll <roll-bounces@ie= tf.org>
Date: Thursday, November 26,= 2020 at 18:48
To: Routing Over Low power a= nd Lossy networks <roll@ietf.org= >
Subject: Re: [Roll] Make P-D= AO bidirectional [extends] IETF 109 open Questions on P-DAO

Hello Li

 

In the packet, there’s a bit in the RPI to say if the = root is the source or the destination. That’s RFC 6550.

I guess the discussion is related to the PDR and P-DAO, not = data packet, though it impacts the ICMP error reporting.<= /font>

 

In a packet along the P-Route, the idea was so far that the = DODAG is a convergecast to the destination so the destination is the root. = If we say that there’s a single ingress and a single egress then the dodag is reversible and either can be the roo= t. If we want to support multicast tracks in the future, then the ingress s= hould be root.

 

If the Track has a single ingress and a single egress, then = the DODAG is reversible into another DODAG and it does not matter which is = root, so we can make it bidir as Huimin asked.

The storing mode P DAO would look a lot more like a DAO, as = you pointed out, if it goes towards the root. If we want to take that path,= a node could learn both directions with a single storing mode P DAO. To be continued…

 

For non-storing, making bidir is really hard. It seems easie= r to install a Track in both directions and couple them.<= /font>

 

As a summary of the proposed changes:

 

General

- we make the root the ingress

- ICMP errors sent to the Root, using the main DODAG if the = track is not reversible

 

 

Storing mode P DAO:

- we also make the root the ingress, P-DAO from egress to in= gress are now more similar to RPL DAO operation

- the track could be made bi-directional, but that’s m= ore code; if so:

  - the packet forwarding leverages the RPI to indicate= the direction, from or to root

  - ICMP errors sent to the Root, could be source or de= stination.

 

Non storing mode P DAO:

- tracks remain directional, can be coupled, how is tbd=

- the RPI is mostly useless since the intermediate nodes do = not know the instance (they see neither the DIO nor the P-DAO); they have n= o idea of their Rank. Still, it is interesting to have is for error determination in an ICPMP error at eth root. It is al= so interesting if the SRH forwarding nodes have a state associated to the T= rack, e.g., reserved time slots or priority queues.

- the RPI is still a SHOULD when there’s no compressio= n and a MUST when there is. We need to clarify what to do, that’s ano= ther of Huimin’s questions, taken separately.

- ICMP errors forwarding packets are sent to the root which = is now the ingress, aka the source of the packet, and the encapsulator fiel= d if the packet is encapsulated and compressed. This is common to any non-storing operation, whether it is a main Instance= , local Instance, or Track. The RPI therein is useful to indicate the Track= in Error. So for that matter the forwarder does not need to make a differe= nce Track vs. other form of RPL local instance.

- this impacts the discussion in SRH reloading we had at IET= F 109, when a  N-S mode loose track is forwarded along a segment that = is also NS mode. We’ll probably need to re-encapsulate now.  In case of re-encapsulation, the re-encapsulator becomes source= and root of the segment, which now has to be considered as a serial Track;= as tunnel headends do, it will have to decapsulate the tunneled packet to = send the packet in error back to the ingress of the loose track

 

 

Doe that work?

 

Pascal

 

From: Roll <roll-bounces@ietf.org> On Behalf Of Li Zhao (liz3)<= br> Sent: jeudi 26 novembre 2020= 03:45
To: Routing Over Low power a= nd Lossy networks <roll@ietf.org>= ;
Subject: Re: [Roll] Make P-D= AO bidirectional [extends] IETF 109 open Questions on P-DAO

 

Hello Pascal,

 

If either source or destination can be root, it’s bett= er to identify when or in which case source or destination can be root. Oth= erwise, it’s hard to interop between different implement even though they both follow RFC standard.

 

E.g. for non-storing mode PDAO, if source is root, PCE only = responses PDR-ACK after receiving PDR from source.=

But if destination is root, PCE should also notify destinati= on which trackid is used. Maybe we need bring new message for this notifica= tion?

 

 

Take care,

Li

 

From: Roll <roll-bounces@ie= tf.org>
Date: Wednesday, November 25= , 2020 at 21:54
To: Routing Over Low power a= nd Lossy networks <roll@ietf.org= >
Subject: Re: [Roll] Make P-D= AO bidirectional [extends] IETF 109 open Questions on P-DAO

Hello Li;

 

Well noted. This was the original intent. The change was mad= e to egress because the idea was that the track could enable multiple sourc= es to reach the egress, like a tree rooted at the egress that flows traverse going down. But the idea of a bidirectio= nal track kinda blocks that idea and the other issues like the one you poin= t out seem to get us back to the original view. I recently made the change = from ingress to egress in the 6TiSCH architecture, waiting in RFC editor queue. I could reverse back, or maybe = say “either source or destination” so it can be egress or egres= s and we are covered for bidirectional.

What do you think?

Or should a reversable Track be really a pair of tracks?

 

Keep safe;

 

Pascal

 

From: Roll <roll-bounces@ietf.org> On Behalf Of Li Zhao (liz3)<= br> Sent: mercredi 25 novembre 2= 020 05:57
To: Routing Over Low power a= nd Lossy networks <roll@ietf.org>= ;
Subject: Re: [Roll] Make P-D= AO bidirectional [extends] IETF 109 open Questions on P-DAO

 

Hello Pascal,

 

Ingress as Root looks better because

1.  It is consistent with the way RPL usually works. RP= L Local instance, aodv-rpl, p2p-rpl all use ingress as root.

2.  For non-storing-mode P-DAO, currently ingress sends= upward traffic to egress(root) with SR header. But in RPL, only downward t= raffic carries SR header.

3.  Only i= ngress can send PDR makes sense. Behavior of TrackId is similar as Local Instance= ID. Ingress as root can propose TrackId from its namespace.<= o:p>

 

 

And for storing-mode P-DAO, if we make ingress as root and i= ngress sends PDR, can PCE send P-DAO to egress then egress forwards it towa= rds predecessor to ingress?

Maybe it helps to make P-DAO looks like a DAO message.

 

 

Best regards,

Li

 

 

From: Roll <roll-bounces@ie= tf.org>
Date: Tuesday, November 24, = 2020 at 21:39
To: Routing Over Low power a= nd Lossy networks <roll@ietf.org= >
Subject: [Roll] Make P-DAO b= idirectional [extends] IETF 109 open Questions on P-DAO<= /o:p>

Dear all

 

Whether to make the P-DAO bidirectional is an intriguing que= stion. It could be done, just like we can send packets DOWN a classical DOD= AG.

But if we take that path, we reopen the question of who is r= oot and which direction the P-DAO flies.

 

Could we make either the ingress OR the egress root? How doe= s it matter?

 

At the moment the Root is the egress and the storing-mode P-= DAO flies from the Track egress to the track ingress, and the track egress = is the root. This is not the way RPL usually works as the DAO flies towards the root. The reason was that we wanted a s= ingle egress for the Track, as we build unicast Track. If we wanted to buil= d multicast Tracks the root should logically be the ingress. And for bidire= ctional Tracks it could be either.

 

Up to -24 the 6TiSCH Architecture expected the ingress to be= root. I changed in the latest to map we do here, that it is the egress; ma= ybe a flag in the DAO would indicate which direction the flow, from root, to root, or both?<= /p>

 

Also if we build bidir Tracks in storing mode, the nodes tha= t forward the DAO will have to build routes in both directions based on the= P-DAO, both towards egress and ingress; but only the path from which the P-DAO comes has been validated by the P-D= AO itself. Should we send a P-DAO to each end, each setting up one way?

 

Please let me know your thoughts

 

Pascal

 

 

From: Roll <roll-bounces@ietf.org> On Behalf Of Pascal Thubert = (pthubert)
Sent: mardi 24 novembre 2020= 14:22
To: Routing Over Low power a= nd Lossy networks <roll@ietf.org>= ;
Subject: [Roll] IETF 109 ope= n Questions on P-DAO

 

Dear all

 

The slides for the P-DAO discussion at IETF 109 are availabl= e here:

 

https://datatracker.ietf.org/doc/slides-109-roll-dao-proje= ction/

 

There are a number of open questions that we starting discus= sing, and would need to progress on the list.

Some of them were expressed on the list, e.g., from Huimin S= he. I’d like to progress on them all with individual threads.

The questions are:

 

  1. Li= fetime Unit: could we use a different unit for P-DAO?
  2. How to differentiate a P-DAO from a normal DAO in a local instance; n= ew flag?
  3. Make P-DAO bidirectional?
  4. Who sends the PDR? Does it have to be the ingress? If it was= egress it could propose a TrackId from its namespace. Else could the ingress be the root?
  5. Maintaining the = sibling state. Should we have text on using RFC 8505 there?
  6. Whether ingress and egress are listed in NPO? Today they are bo= th, ingress to indicate the packet source in case of encapsulation and for SRH-6LoRH compression reference and egress to build the full SRH-6= LoRH. Note that the ingress must consume the first entry and use it as sour= ce.
  7. Track in Track vs. SR Header reload models, = see slides

 

Let me open threads to follow up.

 

Keep safe

 

Pascal

 

 

--_000_CO1PR11MB4881A724B04EA29D32DC9C81D8F80CO1PR11MB4881namp_-- From nobody Fri Nov 27 00:52:12 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 274E73A1451 for ; Fri, 27 Nov 2020 00:52:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.619 X-Spam-Level: X-Spam-Status: No, score=-9.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Qd7YLd1e; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=cnNkPqSw 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 ngU-l8cEkn2R for ; Fri, 27 Nov 2020 00:52:07 -0800 (PST) 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 A44C93A02BB for ; Fri, 27 Nov 2020 00:52:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=42905; q=dns/txt; s=iport; t=1606467127; x=1607676727; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=s4oDUatKcsT34rAOTLsODiP6BGziQPc6IFPCABBjQes=; b=Qd7YLd1eaRsTNOndmhRghwobR/iwc/DrEbdV3Um4wtcI4ovYRzJejSjC ShI9KfziLT+sivrq4QaH/bHZ0x1HMaRnoYKZ4Rr5tZiC6YjAtyyeIlK1d MLT3qoBG4UH2xu0Ll+QMDvQPUDvJXCnpcN4fCrXS66KDM0ZSh+9NTHshJ Y=; X-IPAS-Result: =?us-ascii?q?A0DmCADYu8BffZldJa1YCh4BAQsSDECCci8pKHxaLy6IB?= =?us-ascii?q?gONXpB/iAaBQoERA1QLAQEBDQEBJQgCBAEBhEoCgikCJTgTAgMBAQEDAgMBA?= =?us-ascii?q?QEBBQEBAQIBBgQUAQGGDwglDIVyAQEBAwESCCYBASUTBAsCAQgRAQIBAQEhA?= =?us-ascii?q?QYHMhQDBggBAQQTCBqDBYF+VwMOIAEOpGYCgTyIaXSBNIMEAQEFgTcEDEGDJ?= =?us-ascii?q?RiCEAMGgTiCc4JmTocZghuBEAFDgVdQLj6CXQEBAgEBgSENDyAeBgcJgxSCL?= =?us-ascii?q?IFGAY87ihqMHJAfgQ8GBIJuiReJX4hXgmE7ihyUWZVliQSRKoQ8AgQCBAUCD?= =?us-ascii?q?gEBBYFtIYFZcFCBHoFLUBcCDYd+hiM3bgEHgkSFFIVEdAI1AgYKAQEDCXyMH?= =?us-ascii?q?y2CFwEB?= IronPort-PHdr: =?us-ascii?q?9a23=3Au7eY3xapI2l6BLk7k2KpD7v/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el21QaTD4TW9/wCjPDZ4OjsWm0FtJCGtn1KMJlBTA?= =?us-ascii?q?QMhshemQs8SNWEBkv2IL+PDWQ6Ec1OWUUj8yS9Nk5YS8fze1OUpWe9vnYeHx?= =?us-ascii?q?zlPl9zIeL4UofZk8Ww0bW0/JveKwVFjTawe/V8NhKz+A7QrcIRx4BlL/U8?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,373,1599523200"; d="scan'208,217";a="617120030" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Nov 2020 08:52:06 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AR8q6Eg019814 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 27 Nov 2020 08:52:06 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 27 Nov 2020 02:52:05 -0600 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 27 Nov 2020 02:52:05 -0600 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 27 Nov 2020 03:52:04 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=GhDgeC5SPXmtcWlWr0BeCiBOfrSr0i5IzCpvu7FRfKnCV7Ie63O79OUIL/MukN7MwMtUt+qb2bWooEttCXDEU5cA1ILAKauVpnTVsrD7ssFKv0ZzKsu1O/nIpcJze6/kpkZDus5NYDFMwgFwYRQK27dzTJAtD6FcSn8DxNjg/CYYBpgmYzMSth1zAnvDS89CNOZSnDBNBtBT5EsIoYj4rwLy0M1/eOi2wh3GHTR+tf5nNcNFfBWrfHQ9nRZTNgpOZhiG9ZiCLKgA00YUNgeBqfvSQTNBF+k5r1mkqxblno1Hdvh7DV80L/Uh1GiN1uI9Englg3C/ua8FhgHsK/Bvbw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aM5qeNaqDoe9s01s3xECMYj6+eXFUjVa3Risz+Reddk=; b=G6JEtupMqcrphhxcWK1H6K1xBlszhSViNQEZZ7ZXLKiSv8jTunMsu3bXY3bVxA+y1mVB2VJnArfoxopsbjGYNTLbekCPcbxWwGy0RtIMxpo7XJutO2S4h27Dky1SIIOOPoCmSLOVFJoIpM8TDh8Rp6xN5YHnHbNegljjh72pb3AHwcobO38urivFweWjl+HJws3+Gp/hwx2HIUgQZ+jr/MvOiI9UitW6J1wE/s4Uaay1cTWf2jQAyXOTkSE/Z7kGNTb+W7i57sEPhrnar41o8F93KU08Y8WCrwG92B0OPlHE9x8LC2ggatBZLz8061CgD9O+hy79VPFcfKyo34Kdvw== 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=aM5qeNaqDoe9s01s3xECMYj6+eXFUjVa3Risz+Reddk=; b=cnNkPqSwmR2rCjMEy3ZEW8qnxbDx8AYyc22N3nlyJuUwu9juj2BY9XPJu1Vt+ca6k22Q3JKTuAqXI9L6tUqzEuXCdeDtbKUaYBsqEZSQ2qyftYU3ooTNNMzl4sjcuB87TQwV11rJi5gknaX5vjdVbYy9CvKLCoHhCxiU7FCtnbw= Received: from MWHPR11MB1742.namprd11.prod.outlook.com (2603:10b6:300:113::13) by MW3PR11MB4539.namprd11.prod.outlook.com (2603:10b6:303:2f::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.20; Fri, 27 Nov 2020 08:52:02 +0000 Received: from MWHPR11MB1742.namprd11.prod.outlook.com ([fe80::19ac:46a:36f1:4dfa]) by MWHPR11MB1742.namprd11.prod.outlook.com ([fe80::19ac:46a:36f1:4dfa%3]) with mapi id 15.20.3611.025; Fri, 27 Nov 2020 08:52:02 +0000 From: "Li Zhao (liz3)" To: Routing Over Low power and Lossy networks Thread-Topic: Error flows, which ICMP errors and to which root?: [extends] IETF 109 open Questions on P-DAO Thread-Index: AdbEkO8SsU8bA9FQQ86QQ+UeowvePgACGCRc Date: Fri, 27 Nov 2020 08:52:02 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2001:420:588c:1252:ed42:30ae:45fa:1f11] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 814dc4be-9a66-4dad-399e-08d892b1b5a9 x-ms-traffictypediagnostic: MW3PR11MB4539: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 9F0uqkVhZ9bqKCNVZlKJ0D2X3f9R1XgiSFR4eImT59+uWJhparr6B3+/6fdml9Riaztw5ueSIVUgGmObtWGtrn5pqDmyLcBFxIFQAdWj7jVxSuGdF6c+LbnmjfozYMKzTJ4KQZwGFWQdt/jDVbk/oyU2j1+OCp0IqTnq/1F8uC0CruUZ/8fpJYT87oOzQtwYoZuuqkx+fuunrXDMrGlYMScodyxB4KkUXb64MRjWt/87wSze0JTp75FvxCnvsV2FNF2lAQxoHpVIXpAXaZEKlcl0s7PuGMQTELWi7MK3HMrziE08pqzn+c4aBua+OFZgICxW6940noKqbD5ZhXd6daWFqESbcTJ5VSzX+8GROlSoHuqsD3fT4+UcMKwsifd/brLqduNt5nYnb3jNnrMuqC+DMSKoqScQ7YVXqZWUf7MmQhT4LKlQinn+1LHcav1fMhbRfSSgssPCdNH11nrEHw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MWHPR11MB1742.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(366004)(346002)(396003)(136003)(39860400002)(478600001)(8676002)(7696005)(6916009)(966005)(316002)(53546011)(166002)(6506007)(86362001)(83380400001)(30864003)(2906002)(5660300002)(33656002)(66946007)(66446008)(64756008)(66556008)(66476007)(52536014)(91956017)(76116006)(186003)(55016002)(8936002)(9686003)(71200400001)(88722002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?Windows-1252?Q?pAI8I32A08FRjN7nsS3ajnKo4HrEsbE9oCUFctFisE9qEg0m/d+KcgtD?= =?Windows-1252?Q?Qub4xPvAUK0AnwY5cRNaGgHCXVOlZvXDqzJiFUzcN/gbHzkcM60Z+HgW?= =?Windows-1252?Q?944fNHsQyMxQP3HsiiqXaxfo/WURfluC33jGV+JDvP3I0gfiPbUfUo5+?= =?Windows-1252?Q?qWSE/7sJsksY++U4PZH8l00E9Qtk3xkQj2M2pm17u3OHw3Ylk5q6jiHP?= =?Windows-1252?Q?8XxiUZ0lTjOIN2WL4i2FjDniFwuP67vE5gkkEl6J6RP5rB+xYsYWZV/5?= =?Windows-1252?Q?P2+hiXLA+qToxEkzXtoplTCQGaW96flGWPMgFnwQm3ZdxfKJQo+wFGmz?= =?Windows-1252?Q?kFbjCECC0upL8cD5ROIrqC+il+/aO/jRysmu4cBHsfYHtSJAmgkzKaBg?= =?Windows-1252?Q?oUpN9igo/0XRB2VPAxOgdq5/uGnel4zTUay2n578bF77e9rBRdryinO7?= =?Windows-1252?Q?PXmQCujeiPuq4NNekbMQ60f0saKfIbx3JxB58U6YYTQLWbbDXDnJERRu?= =?Windows-1252?Q?FiA5g4OomKCo/mekunQrHX2J71UF/mzU58PStMaHHydWf1m5eHZvHlPN?= =?Windows-1252?Q?qOf4G2YXMKezZYUUDzNgI22WZh1N/KWnv59M/BRv0ji86ErI4g2nqOAG?= =?Windows-1252?Q?OCR7odM/RfEZVeMVTXreCxf6VsEjmEOqCSQfqPvl/leUiz+ARlDFD/GG?= =?Windows-1252?Q?eHyxVfcxWFEZ93WGsOZreqHFoxujdgoNk0T0oolRyK6Ee3ZVEVJXy/7m?= =?Windows-1252?Q?Phxk607jS9T320R/WkH4yvtC28D5jX2f80uotPcKHk46t0cCEMX7PA+5?= =?Windows-1252?Q?BTi0Mp4drvoCiyTYXSt1Gz01sSzgQLJdwpYSX8Xv7Cu/KJ/bYlVdcKQ2?= =?Windows-1252?Q?M+pHHGrmyB5/jhG8IhJOjs3PXvUn8nfBCg2kvUi7J2rKBhgn5qw7S/l7?= =?Windows-1252?Q?7UH3Q0ryb/kyJGK2Jar5aL6Idzw5DtvQ9Vtvp1ci+zkvgED+gzuFZ6RP?= =?Windows-1252?Q?24o4u6rDcPgxqiG0dGOmkxSgcf7FpnN8EOGHIurMTPt46URGS23+pZ5I?= =?Windows-1252?Q?rD3S0WScxkFzvghVQOkK4aRXN6LXbXgu4cjf1sLeAG5qbul4INMXAOuc?= =?Windows-1252?Q?7lKurTba1+0cP/lqQc7Qo4HrZ14TBoNqzBHjC8Jg9pYSXw=3D=3D?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MWHPR11MB1742533826B09172E5FACDFE8CF80MWHPR11MB1742namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MWHPR11MB1742.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 814dc4be-9a66-4dad-399e-08d892b1b5a9 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Nov 2020 08:52:02.7248 (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: AGy6OvsSaVfBE5MmfOd4mKRZNHDVi90VypL6kiBSJPXqwILsmp41iuPlTlCwypX9 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR11MB4539 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: Re: [Roll] Error flows, which ICMP errors and to which root?: [extends] IETF 109 open Questions on P-DAO 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, 27 Nov 2020 08:52:11 -0000 --_000_MWHPR11MB1742533826B09172E5FACDFE8CF80MWHPR11MB1742namp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hello Pascal, Signal P route in the RPI looks better because we also need this flag to ig= nore SenderRank check in RPI for non-storing PDAO. Can we update the RFC6553 easily? For example, add 1-bit flag in reserved f= ield. Best regards, Li From: Roll Date: Friday, November 27, 2020 at 15:48 To: Routing Over Low power and Lossy networks Subject: [Roll] Error flows, which ICMP errors and to which root?: [extends= ] IETF 109 open Questions on P-DAO Hello Li This is the wrong thread. I created a new one. > Section 7.9 of pdao-draft defines a new code for ICMPv6 error message "E= rror in Projected Route". Does it only work for ICMP errors sent to the mai= n Root? Section 5 says =93 In case of a forwarding error along a Projected Route, an ICMP error is sent to the Root with a new Code "Error in Projected Route" (See Section 7.9). The Root can then modify or remove the Projected Route. The "Error in Projected Route" message has the same format as the "Destination Unreachable Message", as specified in RFC 4443 [RFC4443]. =93 So yes the intention was to send the ICMP to the main Root. But as you poin= t out the packet does not indicate it is following a P-route. This was rela= ted to storing mode P DAO. In non-storing the node does not know it=92s a P= -route. > In non-storing PDAO, forwarder can=92t recognize whether data packet is i= n PDAO instance. Forwarder should send ICMP Destination Unreachable error t= o root (the source of the packet), then root generates ICMPv6 error message= with "Error in Projected Route=94 to main Root. Is it correct? That would work. Seems neat. The alternate would be to signal it is a P rou= te in the RPI. That=92s item 2) in the list in this thread. If we do that t= he current text works. What makes more sense to you? > In storing PDAO, forwarder can recognize the PDAO instance from the RPI. = It can send "Error in Projected Route=94 or =93Destination Unreachable err= or=94 to root. Maybe we need more claims for which code forwarder should us= e. We have to decide if we send it to the main root as written in the current = draft or to the Track Root. If the P route is reversible could be done that= way. But that=92s added complexity. I=92m not very convinced either way. T= he Okham razor could be to do the simplest. Keep safe! Pascal From: Roll On Behalf Of Li Zhao (liz3) Sent: vendredi 27 novembre 2020 03:51 To: Routing Over Low power and Lossy networks Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questi= ons on P-DAO Hello Pascal, It looks good for me. Only one question about ICMP errors. Section 7.9 of pdao-draft defines a new code for ICMPv6 error message "Err= or in Projected Route". Does it only work for ICMP errors sent to the main = Root? In non-storing PDAO, forwarder can=92t recognize whether data packet is in = PDAO instance. Forwarder should send ICMP Destination Unreachable error to = root (the source of the packet), then root generates ICMPv6 error message w= ith "Error in Projected Route=94 to main Root. Is it correct? In storing PDAO, forwarder can recognize the PDAO instance from the RPI. It= can send "Error in Projected Route=94 or =93Destination Unreachable error= =94 to root. Maybe we need more claims for which code forwarder should use. Best regards, Li From: Roll > Date: Thursday, November 26, 2020 at 18:48 To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questi= ons on P-DAO Hello Li In the packet, there=92s a bit in the RPI to say if the root is the source = or the destination. That=92s RFC 6550. I guess the discussion is related to the PDR and P-DAO, not data packet, th= ough it impacts the ICMP error reporting. In a packet along the P-Route, the idea was so far that the DODAG is a conv= ergecast to the destination so the destination is the root. If we say that = there=92s a single ingress and a single egress then the dodag is reversible= and either can be the root. If we want to support multicast tracks in the = future, then the ingress should be root. If the Track has a single ingress and a single egress, then the DODAG is re= versible into another DODAG and it does not matter which is root, so we can= make it bidir as Huimin asked. The storing mode P DAO would look a lot more like a DAO, as you pointed out= , if it goes towards the root. If we want to take that path, a node could l= earn both directions with a single storing mode P DAO. To be continued=85 For non-storing, making bidir is really hard. It seems easier to install a = Track in both directions and couple them. As a summary of the proposed changes: General - we make the root the ingress - ICMP errors sent to the Root, using the main DODAG if the track is not re= versible Storing mode P DAO: - we also make the root the ingress, P-DAO from egress to ingress are now m= ore similar to RPL DAO operation - the track could be made bi-directional, but that=92s more code; if so: - the packet forwarding leverages the RPI to indicate the direction, from= or to root - ICMP errors sent to the Root, could be source or destination. Non storing mode P DAO: - tracks remain directional, can be coupled, how is tbd - the RPI is mostly useless since the intermediate nodes do not know the in= stance (they see neither the DIO nor the P-DAO); they have no idea of their= Rank. Still, it is interesting to have is for error determination in an IC= PMP error at eth root. It is also interesting if the SRH forwarding nodes h= ave a state associated to the Track, e.g., reserved time slots or priority = queues. - the RPI is still a SHOULD when there=92s no compression and a MUST when t= here is. We need to clarify what to do, that=92s another of Huimin=92s ques= tions, taken separately. - ICMP errors forwarding packets are sent to the root which is now the ingr= ess, aka the source of the packet, and the encapsulator field if the packet= is encapsulated and compressed. This is common to any non-storing operatio= n, whether it is a main Instance, local Instance, or Track. The RPI therein= is useful to indicate the Track in Error. So for that matter the forwarder= does not need to make a difference Track vs. other form of RPL local insta= nce. - this impacts the discussion in SRH reloading we had at IETF 109, when a = N-S mode loose track is forwarded along a segment that is also NS mode. We= =92ll probably need to re-encapsulate now. In case of re-encapsulation, th= e re-encapsulator becomes source and root of the segment, which now has to = be considered as a serial Track; as tunnel headends do, it will have to dec= apsulate the tunneled packet to send the packet in error back to the ingres= s of the loose track Doe that work? Pascal From: Roll > On Behalf = Of Li Zhao (liz3) Sent: jeudi 26 novembre 2020 03:45 To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questi= ons on P-DAO Hello Pascal, If either source or destination can be root, it=92s better to identify when= or in which case source or destination can be root. Otherwise, it=92s hard= to interop between different implement even though they both follow RFC st= andard. E.g. for non-storing mode PDAO, if source is root, PCE only responses PDR-A= CK after receiving PDR from source. But if destination is root, PCE should also notify destination which tracki= d is used. Maybe we need bring new message for this notification? Take care, Li From: Roll > Date: Wednesday, November 25, 2020 at 21:54 To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questi= ons on P-DAO Hello Li; Well noted. This was the original intent. The change was made to egress bec= ause the idea was that the track could enable multiple sources to reach the= egress, like a tree rooted at the egress that flows traverse going down. B= ut the idea of a bidirectional track kinda blocks that idea and the other i= ssues like the one you point out seem to get us back to the original view. = I recently made the change from ingress to egress in the 6TiSCH architectur= e, waiting in RFC editor queue. I could reverse back, or maybe say =93eithe= r source or destination=94 so it can be egress or egress and we are covered= for bidirectional. What do you think? Or should a reversable Track be really a pair of tracks? Keep safe; Pascal From: Roll > On Behalf = Of Li Zhao (liz3) Sent: mercredi 25 novembre 2020 05:57 To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questi= ons on P-DAO Hello Pascal, Ingress as Root looks better because 1. It is consistent with the way RPL usually works. RPL Local instance, ao= dv-rpl, p2p-rpl all use ingress as root. 2. For non-storing-mode P-DAO, currently ingress sends upward traffic to e= gress(root) with SR header. But in RPL, only downward traffic carries SR he= ader. 3. Only ingress can send PDR makes sense. Behavior of TrackId is similar a= s Local Instance ID. Ingress as root can propose TrackId from its namespace= . And for storing-mode P-DAO, if we make ingress as root and ingress sends PD= R, can PCE send P-DAO to egress then egress forwards it towards predecessor= to ingress? Maybe it helps to make P-DAO looks like a DAO message. Best regards, Li From: Roll > Date: Tuesday, November 24, 2020 at 21:39 To: Routing Over Low power and Lossy networks > Subject: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questions = on P-DAO Dear all Whether to make the P-DAO bidirectional is an intriguing question. It could= be done, just like we can send packets DOWN a classical DODAG. But if we take that path, we reopen the question of who is root and which d= irection the P-DAO flies. Could we make either the ingress OR the egress root? How does it matter? At the moment the Root is the egress and the storing-mode P-DAO flies from = the Track egress to the track ingress, and the track egress is the root. Th= is is not the way RPL usually works as the DAO flies towards the root. The = reason was that we wanted a single egress for the Track, as we build unicas= t Track. If we wanted to build multicast Tracks the root should logically b= e the ingress. And for bidirectional Tracks it could be either. Up to -24 the 6TiSCH Architecture expected the ingress to be root. I change= d in the latest to map we do here, that it is the egress; maybe a flag in t= he DAO would indicate which direction the flow, from root, to root, or both= ? Also if we build bidir Tracks in storing mode, the nodes that forward the D= AO will have to build routes in both directions based on the P-DAO, both to= wards egress and ingress; but only the path from which the P-DAO comes has = been validated by the P-DAO itself. Should we send a P-DAO to each end, eac= h setting up one way? Please let me know your thoughts Pascal From: Roll > On Behalf = Of Pascal Thubert (pthubert) Sent: mardi 24 novembre 2020 14:22 To: Routing Over Low power and Lossy networks > Subject: [Roll] IETF 109 open Questions on P-DAO Dear all The slides for the P-DAO discussion at IETF 109 are available here: https://datatracker.ietf.org/doc/slides-109-roll-dao-projection/ There are a number of open questions that we starting discussing, and would= need to progress on the list. Some of them were expressed on the list, e.g., from Huimin She. I=92d like = to progress on them all with individual threads. The questions are: 1. Lifetime Unit: could we use a different unit for P-DAO? 2. How to differentiate a P-DAO from a normal DAO in a local instance; n= ew flag? 3. Make P-DAO bidirectional? 4. Who sends the PDR? Does it have to be the ingress? If it was egress i= t could propose a TrackId from its namespace. Else could the ingress be the= root? 5. Maintaining the sibling state. Should we have text on using RFC 8505 = there? 6. Whether ingress and egress are listed in NPO? Today they are both, in= gress to indicate the packet source in case of encapsulation and for SRH-6L= oRH compression reference and egress to build the full SRH-6LoRH. Note that= the ingress must consume the first entry and use it as source. 7. Track in Track vs. SR Header reload models, see slides Let me open threads to follow up. Keep safe Pascal --_000_MWHPR11MB1742533826B09172E5FACDFE8CF80MWHPR11MB1742namp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable

Hello Pascal,=

 

Signal P route in the RP= I looks better because we also need this flag to ignor= e SenderRank check in RPI for non-storing PDAO.

Can we update the RFC6553 easil= y? For example, add 1-bit flag in reserved field.

 

 

Best regards,=

Li

 

From: Roll <roll-bounc= es@ietf.org>
Date: Friday, November 27, 2020 at 15:48
To: Routing Over Low power and Lossy networks <roll@ietf.org><= br> Subject: [Roll] Error flows, which ICMP errors and to which root?: [= extends] IETF 109 open Questions on P-DAO

Hello Li

 

This is the wrong thread. I created a new one.<= /o:p>

 

> Section 7.9 of= pdao-draft defines a new code for  ICMPv6 error message "Error i= n Projected Route". Does it only work for ICMP errors sent to the main Root?

 

Section 5 says =93

 

   In case of a forwarding error along a Projected Route, an=
 ICMP error
   is sent to the Root with a new Code "Error in Projec=
ted Route" (See
   Section 7.9).  The Root can then modi=
fy or remove the Projected
   Route.  The "Error in Projected Route" mes=
sage has the same format as
   the "Destination Unreachable Message", as speci=
fied in RFC 4443
   [RFC4443<=
/a>].

 

=93

 

So yes the intention was to send the ICMP to the mai= n Root. But as you point out the packet does not indicate it is following a= P-route. This was related to storing mode P DAO. In non-storing the node d= oes not know it=92s a P-route.

 

 

> In non-storing PDAO, forwarder can=92t recogniz= e whether data packet is in PDAO instance. Forwarder should send ICMP Desti= nation Unreachable error to root (the source of the packet), then root gene= rates ICMPv6 error message with "Error in Projected Route=94 to main Root.  Is it correct?

 

That would work. Seems neat. The alternate would be = to signal it is a P route in the RPI. That=92s item 2) in the list in this = thread. If we do that the current text works. What makes more sense to you?=

 

> In storing PDAO, forwarder can recognize the PD= AO instance from the RPI. It can send "Error in Projected Route=94 or =  =93Destination Unreachable error=94 to root. Maybe we need more claim= s for which code forwarder should use.

 

We have to decide if we send it to the main root as = written in the current draft or to the Track Root. If the P route is revers= ible could be done that way. But that=92s added complexity. I=92m not very = convinced either way. The Okham razor could be to do the simplest.

 

Keep safe!

 

Pascal

 

 

From: Roll <roll-bounces@ietf.org> O= n Behalf Of Li Zhao (liz3)
Sent: vendredi 27 novembre 2020 03:51
To: Routing Over Low power and Lossy networks <roll@ietf.org><= br> Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open= Questions on P-DAO

 

Hello Pascal,

 

It looks good for me. Only one question about ICMP e= rrors.

 

Section 7.9 of pdao-draft defines a new code for &nb= sp;ICMPv6 error message "Error in Projected Route". Does it only = work for ICMP errors sent to the main Root?

In non-storing PDAO= , forwarder can=92t recognize whether data packet is in PDAO instance. Forw= arder should send ICMP Destination Unreachable error to root (the so= urce of the packet), then root generates ICMPv6 error message with "Error in Projected Route=94 to main Root. =  Is it correct?

In storing PDAO, fo= rwarder can recognize the PDAO instance from the RPI. It can send "Err= or in Projected Route=94 or  =93Destination Unreachable error=94 to ro= ot. Maybe we need more claims for which code forwarder should use.

 

 

Best regards,

Li

 

 

 

From: Roll <roll= -bounces@ietf.org&g= t;
Date: Thursday, November 26, 2020 at 18:48
To: Routing Over Low power and Lossy networks <roll@ietf.org= >
Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open= Questions on P-DAO

Hello Li

 

In the packet, there=92s a bit in the RPI to say if = the root is the source or the destination. That=92s RFC 6550.

I guess the discussion is related to the PDR and P-D= AO, not data packet, though it impacts the ICMP error reporting.=

 

In a packet along the P-Route, the idea was so far t= hat the DODAG is a convergecast to the destination so the destination is th= e root. If we say that there=92s a single ingress and a single egress then = the dodag is reversible and either can be the root. If we want to support multicast tracks in the future, then th= e ingress should be root.

 

If the Track has a single ingress and a single egres= s, then the DODAG is reversible into another DODAG and it does not matter w= hich is root, so we can make it bidir as Huimin asked.

The storing mode P DAO would look a lot more like a = DAO, as you pointed out, if it goes towards the root. If we want to take th= at path, a node could learn both directions with a single storing mode P DA= O. To be continued=85

 

For non-storing, making bidir is really hard. It see= ms easier to install a Track in both directions and couple them.=

 

As a summary of the proposed changes:

 

General

- we make the root the ingress

- ICMP errors sent to the Root, using the main DODAG= if the track is not reversible

 

 

Storing mode P DAO:

- we also make the root the ingress, P-DAO from egre= ss to ingress are now more similar to RPL DAO operation

- the track could be made bi-directional, but that= =92s more code; if so:

  - the packet forwarding leverages the RPI to = indicate the direction, from or to root

  - ICMP errors sent to the Root, could be sour= ce or destination.

 

Non storing mode P DAO:

- tracks remain directional, can be coupled, how is = tbd

- the RPI is mostly useless since the intermediate n= odes do not know the instance (they see neither the DIO nor the P-DAO); the= y have no idea of their Rank. Still, it is interesting to have is for error= determination in an ICPMP error at eth root. It is also interesting if the SRH forwarding nodes have a state = associated to the Track, e.g., reserved time slots or priority queues.=

- the RPI is still a SHOULD when there=92s no compre= ssion and a MUST when there is. We need to clarify what to do, that=92s ano= ther of Huimin=92s questions, taken separately.

- ICMP errors forwarding packets are sent to the roo= t which is now the ingress, aka the source of the packet, and the encapsula= tor field if the packet is encapsulated and compressed. This is common to a= ny non-storing operation, whether it is a main Instance, local Instance, or Track. The RPI therein is useful= to indicate the Track in Error. So for that matter the forwarder does not = need to make a difference Track vs. other form of RPL local instance.<= /o:p>

- this impacts the discussion in SRH reloading we ha= d at IETF 109, when a  N-S mode loose track is forwarded along a segme= nt that is also NS mode. We=92ll probably need to re-encapsulate now. = In case of re-encapsulation, the re-encapsulator becomes source and root of the segment, which now has to be considered as = a serial Track; as tunnel headends do, it will have to decapsulate the tunn= eled packet to send the packet in error back to the ingress of the loose tr= ack

 

 

Doe that work?

 

Pascal

 

From: Roll <roll-bounces@ietf.org> On Behalf Of Li Zhao (liz3)
Sent: jeudi 26 novembre 2020 03:45
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open= Questions on P-DAO

 

Hello Pascal,

 

If either source or destination can be root, it=92s = better to identify when or in which case source or destination can be root.= Otherwise, it=92s hard to interop between different implement even though = they both follow RFC standard.

 

E.g. for non-storing mode PDAO, if source is root, P= CE only responses PDR-ACK after receiving PDR from source.

But if destination is root, PCE should also notify d= estination which trackid is used. Maybe we need bring new message for this = notification?

 

 

Take care,

Li

 

From: Roll <roll= -bounces@ietf.org&g= t;
Date: Wednesday, November 25, 2020 at 21:54
To: Routing Over Low power and Lossy networks <roll@ietf.org= >
Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open= Questions on P-DAO

Hello Li;

 

Well noted. This was the original intent. The change= was made to egress because the idea was that the track could enable multip= le sources to reach the egress, like a tree rooted at the egress that flows= traverse going down. But the idea of a bidirectional track kinda blocks that idea and the other issues like = the one you point out seem to get us back to the original view. I recently = made the change from ingress to egress in the 6TiSCH architecture, waiting = in RFC editor queue. I could reverse back, or maybe say =93either source or destination=94 so it can be egress = or egress and we are covered for bidirectional.

What do you think?

Or should a reversable Track be really a pair of tra= cks?

 

Keep safe;

 

Pascal

 

From: Roll <roll-bounces@ietf.org> On Behalf Of Li Zhao (liz3)
Sent: mercredi 25 novembre 2020 05:57
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open= Questions on P-DAO

 

Hello Pascal,

 

Ingress as Root looks better because

1.  It is consistent with the way RPL usually w= orks. RPL Local instance, aodv-rpl, p2p-rpl all use ingress as root.

2.  For non-storing-mode P-DAO, currently ingre= ss sends upward traffic to egress(root) with SR header. But in RPL, only do= wnward traffic carries SR header.

3.  Only ingress can send PDR makes sense. Behavior of TrackId is similar as Local= Instance ID. Ingress as root can propose TrackId from its namespace.

 

 

And for storing-mode P-DAO, if we make ingress as ro= ot and ingress sends PDR, can PCE send P-DAO to egress then egress forwards= it towards predecessor to ingress?

Maybe it helps to make P-DAO looks like a DAO messag= e.

 

 

Best regards,

Li

 

 

From: Roll <roll= -bounces@ietf.org&g= t;
Date: Tuesday, November 24, 2020 at 21:39
To: Routing Over Low power and Lossy networks <roll@ietf.org= >
Subject: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Que= stions on P-DAO

Dear all

 

Whether to make the P-DAO bidirectional is an intrig= uing question. It could be done, just like we can send packets DOWN a class= ical DODAG.

But if we take that path, we reopen the question of = who is root and which direction the P-DAO flies.

 

Could we make either the ingress OR the egress root?= How does it matter?

 

At the moment the Root is the egress and the storing= -mode P-DAO flies from the Track egress to the track ingress, and the track= egress is the root. This is not the way RPL usually works as the DAO flies= towards the root. The reason was that we wanted a single egress for the Track, as we build unicast Track. I= f we wanted to build multicast Tracks the root should logically be the ingr= ess. And for bidirectional Tracks it could be either.

 

Up to -24 the 6TiSCH Architecture expected the ingre= ss to be root. I changed in the latest to map we do here, that it is the eg= ress; maybe a flag in the DAO would indicate which direction the flow, from= root, to root, or both?

 

Also if we build bidir Tracks in storing mode, the n= odes that forward the DAO will have to build routes in both directions base= d on the P-DAO, both towards egress and ingress; but only the path from whi= ch the P-DAO comes has been validated by the P-DAO itself. Should we send a P-DAO to each end, each setting up o= ne way?

 

Please let me know your thoughts

 

Pascal

 

 

From: Roll <roll-bounces@ietf.org> On Behalf Of Pascal Thubert (pthubert)
Sent: mardi 24 novembre 2020 14:22
To: Routing Over Low power and Lossy networks <roll@ietf.org>
Subject: [Roll] IETF 109 open Questions on P-DAO

 

Dear all

 

The slides for the P-DAO discussion at IETF 109 are = available here:

 

https://datatracker.ietf.org/doc/slides-109-roll-d= ao-projection/

 

There are a number of open questions that we startin= g discussing, and would need to progress on the list.

Some of them were expressed on the list, e.g., from = Huimin She. I=92d like to progress on them all with individual threads.

The questions are:

 

  1. Lifetime Unit: could we use a different unit for P-DAO?
  2. How to differentiate a P-DAO from a normal DAO in a local instance;= new flag?
  3. Make P-DAO bidirectional?
    4. Who sends the PDR? Does it have to be the ingress? If it was egress it = could propose a TrackId from its namespace. Else could the ingress be the r= oot?
  4. Maintaining the sibling state. Should we have tex= t on using RFC 8505 there?
  5. Whether ingress and egress = are listed in NPO? Today they are both, ingress to indicate the packet sour= ce in case of encapsulation and for SRH-6LoRH compression reference and egr= ess to build the full SRH-6LoRH. Note that the ingress must consume the first = entry and use it as source.
  6. Track in Track vs. SR Head= er reload models, see slides

 

Let me open threads to follow up.

 

Keep safe

 

Pascal

 

 

--_000_MWHPR11MB1742533826B09172E5FACDFE8CF80MWHPR11MB1742namp_-- From nobody Fri Nov 27 00:58:05 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5EBE3A0F35 for ; Fri, 27 Nov 2020 00:58:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.6 X-Spam-Level: X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=l+1SlBcf; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=zjiitNJA 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 d61qdpsnHoGq for ; Fri, 27 Nov 2020 00:58:00 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 314E53A0E02 for ; Fri, 27 Nov 2020 00:58:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=57237; q=dns/txt; s=iport; t=1606467480; x=1607677080; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=d7E97aCVt/POehoc+dGqomlLKWdn1it9gT98u+/jXho=; b=l+1SlBcf6ld+WX1az4XOW1U472wd8mc5lv/Sk5d3O35CInzcMwNctf7D c6U2HhGpuILx5d+h6u35qUh4wT5UhT6I9XswY1F65hx0TjQ8pTuyx/TJG b/4rp4b1rsKJGrZ0PXZeVJQbHKzQHi/raoRLves+gQfEVPri7kJY4DsRk 0=; X-IPAS-Result: =?us-ascii?q?A0B4BwDpvcBffZBdJa1YCh0BAQEBCQESAQUFAYIPgSMvK?= =?us-ascii?q?Sh8Wi8uhD2DSQONXpkFgUKBEQNPBQsBAQENAQEYAQwIAgQBAYRKAheCEgIlO?= =?us-ascii?q?BMCAwEBAQMCAwEBAQEFAQEBAgEGBBQBAYYPCCUMhXIBAQEDAQEBEAgJHQEBJ?= =?us-ascii?q?QcMBAsCAQgRAQIBAQEhAQIEAwICAiULFAMGCAEBBBMigwQBgX5XAw4gAQ6kc?= =?us-ascii?q?gKBPIhpdoEygwQBAQWBNwQMQYMoGIIQAwaBOIJzgmZOQoZXG4FBP4EQASccg?= =?us-ascii?q?VdQLj6BBIFZAQECAQGBIQ0PPgYHCYJhM4IskQKCdockjByQH4EPCoJuiReJX?= =?us-ascii?q?4g1Ax+CYTuKHJRZlWWJBJEqhDwCBAIEBQIOAQEFgW0hgVlwFTsqAYI+UBcCD?= =?us-ascii?q?Yd+hiMYH24BB4JEhRSFRHQCNQIGAQkBAQMJfIwfLYIXAQE?= IronPort-PHdr: =?us-ascii?q?9a23=3A3xDvoRbkfkEqHAog9xUPApn/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el21QaTD4TW9/wCjPDZ4OjsWm0FtJCGtn1KMJlBTA?= =?us-ascii?q?QMhshemQs8SNWEBkv2IL+PDWQ6Ec1OWUUj8yS9Nk5YS8fze1OUpWe9vnYeHx?= =?us-ascii?q?zlPl9zIeL4UofZk8Ww0bW0/JveKwVFjTawe/V8NhKz+A7QrcIRx4BlL/U8?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,373,1599523200"; d="scan'208,217";a="620583915" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Nov 2020 08:57:58 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-8.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AR8vwgl013089 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 27 Nov 2020 08:57:58 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 27 Nov 2020 02:57:58 -0600 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 27 Nov 2020 02:57:58 -0600 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 27 Nov 2020 02:57:58 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XdUjhkSRl/sVBXDLSZCcsbXo7l1DbNDJJg1p2udFk8kworV3xLxDMla0C0EeOz9C2b1O6g9I4wKcVaSPlYVbo9E1OBOKQOcmiwOLCKVLGeqRIMFC2ZFaluXF/gyAc5bpMRuglvVfOm9WadDsUwdMXz5EYkcvYm8QdeaoEOjwp/FRDqooNVz5aOEf0jEL6m7UQ5s1uHOonJZCEzpVOwYmqsgqI9z6xHfgqj2fXy4VH07/Ooe3BeKdqX86O+CrJY56iNcT/ixrcD0KOZSuA8NjRFw+Cuuo/0BaiGRAUQIxo5tfwFQPvyoSICkk7KSr/RAzWG0+Og58DYR56agffbYWGw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=d7E97aCVt/POehoc+dGqomlLKWdn1it9gT98u+/jXho=; b=NueJsnhgGUNCeLg5JVKs9wMtfJre2azgjV1L+H8SCjzRnP7qONBbpsImEh4YHcPJ2zmgLeUlyDj/9uqBfK1lTgjLLYKvqUV0erVj9YzOv1PlKuCsNg0pIKmQP7nC83jiHcI3qoF/eIRPBytUFx6aCR6hDsO+EH/IxWWSs75NG1XgDU8UihPw/2Vwfh3Wgt1m60PeVzVQwlLhbEXvnBXWN3JiyFJi1f/0OjwfZFqv0NqgzqdnSBugLsbqAkrmJJYMC0ITiUYdd68qYxe4Pjiukb0WRS3+OXptBZYEoEN+1ycP1NNOdPwEL5idttvlaBZ+71K2XgDYJZC3I3cSmnW05g== 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=d7E97aCVt/POehoc+dGqomlLKWdn1it9gT98u+/jXho=; b=zjiitNJABvpfPUt+o7GmDUjpVtGoVofl7I/bCI6wmmfevu3RbmwQzgwsP5x6pxP3jPEjVV8egEwuio8XJ6cVXL+fOlEKa2aiTMDxNAQmDg6bsn8sWA+aZrjZPITiK6x06dqoLd+ai/SHDweZFrUua/AYh3L+PW+F46HYob+rf3c= Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by MWHPR11MB1773.namprd11.prod.outlook.com (2603:10b6:300:10f::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3589.22; Fri, 27 Nov 2020 08:57:57 +0000 Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::fc25:3e72:3e83:7df6]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::fc25:3e72:3e83:7df6%4]) with mapi id 15.20.3564.025; Fri, 27 Nov 2020 08:57:57 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] Error flows, which ICMP errors and to which root?: [extends] IETF 109 open Questions on P-DAO Thread-Index: AdbEkO8SsU8bA9FQQ86QQ+UeowvePgACGCRcAACFn0A= Date: Fri, 27 Nov 2020 08:57:56 +0000 Message-ID: References: , In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2a01:cb1d:4ec:2200:3432:fea4:e634:93ce] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b82f84d6-eb6b-4876-9697-08d892b288cf x-ms-traffictypediagnostic: MWHPR11MB1773: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: avhZ5GF2oL8/2NwBLRYJvUfP8CDKmH1q+AZ57SXZajTQVLvt9TFCE9Mbj17srap2G2E2ru34pzoOcOupMe5hPqAT9f1NeqV1us8h8u8TimPoucGIsG9nR6bYm2sDA+L8nyozUiLqrkYyDXWrFRSkYcUva/Kj/BqcrQbZphRQyF/gHW2u77N8/LBspRJ/PWH60V+w1w+muBraHSYpebKBRjHo0bT/HxQMW4C9uI7QMNT1F8qvHYj+4pFXURXhHfHObVeO/FxOTnEQcb4q6rs46B9KBCFeyMi47G9jKg8BDMxQgXj/vtiEWlUnnycijvtgv4ljNKHQah5Wb0t5ry/danoaEYjnRfi3lJfrx+PctGhy6z2AkU1WP9Go+oR182ydQEp7pnuPdU094LfhROgLnkes44QtDbhG0mLPsKmyUzs7SSv/stPDrrYWwgcJp1OKZfjSauJAu4lpCnbBwJZNoQ== 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:(136003)(346002)(39860400002)(376002)(396003)(366004)(66476007)(66946007)(66446008)(8936002)(6486002)(8676002)(316002)(478600001)(91956017)(76116006)(966005)(66556008)(186003)(66574015)(166002)(6506007)(30864003)(2616005)(53546011)(33656002)(6916009)(2906002)(36756003)(83380400001)(71200400001)(86362001)(5660300002)(6512007)(64756008)(244885003); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?SXBUSG1HY3MzOG5KYm9tTXBJYnpBSUtIZnZONEdsdEVLdlJYTjc4elloanc0?= =?utf-8?B?eUZQUVhZbzZXNnFSVG84YWJXVUdQV2JTWW1ZOFlZRGJGL2lqK2FORDVqOUhP?= =?utf-8?B?Ky93RDMrYzBQVDVUTzdNRzlYOEtmVTQrLzNNL0trU0ROS3dOeGZJTmNiN2g4?= =?utf-8?B?UXFXc01YNWlnQWZFTUxjL2kycFJRU0Z4Y0dNbm51U3pwY1VYM0taeVhUK1FY?= =?utf-8?B?ODZlRlYwT3M5S2VGb0JMdEUzeEhYcmF4MVkvL20yU3RSQSs1T1F3UEVVbW10?= =?utf-8?B?TGZPMmw2YnVnOW56b2hrdC9ZLzB2bSsvRzZubTU2d1l6ek5NRkM1STE4ejFZ?= =?utf-8?B?dkh3RWpQQ3RCYm5XU2VPMUE3bitDYkY3bGxPN1l1N3NvOUdFRXF3cHhIVWxM?= =?utf-8?B?WkFIUVNwSC9SNHU1TEEwRnd1ZVAvbDVSTkwyL2liRUNCYjNJb1lPb3FUd2J0?= =?utf-8?B?cmRDYys4cURScjVnNzBmRDk5c2laendkcFhsKzJSejhxSmFueWhvcG80bTRS?= =?utf-8?B?L1VMZlg4V29QSDcxRGwweFIrT3Y4aStTeTZxSC9LSmRPc3pwR1lZUDJkanlS?= =?utf-8?B?dkhzWmxVbmpPeHJSUXNaZG5SUEU5cXV5bjlNUDgyUWpibTVWUE1jSExaMmRD?= =?utf-8?B?U1VraXhyUlhUcjNoVHowMVIzZmxPdzFoRkc5V2M2djFvMjJGYTAwRnpSU2NX?= =?utf-8?B?NWowVzNBcktoZmhZaldmcGh6cEIvd3pyQVBoYWNCM3RjcHBzM3lsaG5XSWc2?= =?utf-8?B?VlZGeXlMb0RBd0VqbURtWjZqSjBsOFhpNFRBR2NVRmtPRlY3NnlaZGFaRjNF?= =?utf-8?B?QWsrYlkwWGp0Wlp4eVpkb29jSWFRSDBwbUt4b0VhczZUVXhNNmxaU0IvL3ln?= =?utf-8?B?Nm1xbldHUVZ1a2kyanE1TmZNa2MyamUxSlkrSmNqWHpmbFZYUngyR3A3VG9k?= =?utf-8?B?UnRlVy9tUGx2WDZiSi9LQVN0TjFCcENnOXVmbTBwcWxqSVhEZXU4MEhGTkhj?= =?utf-8?B?Q2Q2YW5Gd2hOcnFZeTdjcVlLU3ZYQjMxTGlBTWVnSldMTVozaFo3ZzhucGFJ?= =?utf-8?B?bE9nVUgvOUtSdjZtdFFoem9aSWI3TnVzVkZqbmc2cUpuVUYvb3NwTWNic1hk?= =?utf-8?B?RURKZ01TcTFBRXpudEczRC9uYVFNRmJMQkh3bHNHRWdheG83WVVTejRuak91?= =?utf-8?B?ZjAxOGxFbGZVYksyNTcybGtuTXpZbjVYenl3dCtVUEVGWkxiY1dkbFBlLzZO?= =?utf-8?B?OFpLeVQzN1I5dUVwTFVIbllRY0FtTlVaamVvTVcxTlRzK2h2TlpaUk1WS3pm?= =?utf-8?B?OExHZFFnWUcwalBmL3dudnNrK3FqMThiTnhQbk5zekxtaVBPNW95NDhQQ3R5?= =?utf-8?B?TGVnNmtHdTdWc0Jpb1BheGIvRFJuV0FnN2VaNHBmUmxueE5DTitTS3BNT0ZK?= =?utf-8?Q?AW1Id/Wu?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_AC612802904C4FA781EDE661E1E50212ciscocom_" 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: b82f84d6-eb6b-4876-9697-08d892b288cf X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Nov 2020 08:57:56.8372 (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: 7LIqVF2CkvmTLWQjptyyJ95F/lcxnHzedEqi2GNw0WGDcRz8bPr/Ar8KZAdkRNRR3HOj17XsThIHVXi/kEQvBQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1773 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: rcdn-core-8.cisco.com Archived-At: Subject: Re: [Roll] Error flows, which ICMP errors and to which root?: [extends] IETF 109 open Questions on P-DAO 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, 27 Nov 2020 08:58:04 -0000 --_000_AC612802904C4FA781EDE661E1E50212ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2UgY2VydGFpbmx5IGNhbiwgTGkuDQoNCg0KUmVnYXJkcywNCg0KUGFzY2FsDQoNCkxlIDI3IG5v di4gMjAyMCDDoCAwOTo1MiwgTGkgWmhhbyAobGl6MykgPGxpejM9NDBjaXNjby5jb21AZG1hcmMu aWV0Zi5vcmc+IGEgw6ljcml0IDoNCg0K77u/DQpIZWxsbyBQYXNjYWwsDQoNClNpZ25hbCBQIHJv dXRlIGluIHRoZSBSUEkgbG9va3MgYmV0dGVyIGJlY2F1c2Ugd2UgYWxzbyBuZWVkIHRoaXMgZmxh ZyB0byBpZ25vcmUgU2VuZGVyUmFuayBjaGVjayBpbiBSUEkgZm9yIG5vbi1zdG9yaW5nIFBEQU8u DQpDYW4gd2UgdXBkYXRlIHRoZSBSRkM2NTUzIGVhc2lseT8gRm9yIGV4YW1wbGUsIGFkZCAxLWJp dCBmbGFnIGluIHJlc2VydmVkIGZpZWxkLg0KDQoNCkJlc3QgcmVnYXJkcywNCkxpDQoNCkZyb206 IFJvbGwgPHJvbGwtYm91bmNlc0BpZXRmLm9yZz4NCkRhdGU6IEZyaWRheSwgTm92ZW1iZXIgMjcs IDIwMjAgYXQgMTU6NDgNClRvOiBSb3V0aW5nIE92ZXIgTG93IHBvd2VyIGFuZCBMb3NzeSBuZXR3 b3JrcyA8cm9sbEBpZXRmLm9yZz4NClN1YmplY3Q6IFtSb2xsXSBFcnJvciBmbG93cywgd2hpY2gg SUNNUCBlcnJvcnMgYW5kIHRvIHdoaWNoIHJvb3Q/OiBbZXh0ZW5kc10gSUVURiAxMDkgb3BlbiBR dWVzdGlvbnMgb24gUC1EQU8NCkhlbGxvIExpDQoNClRoaXMgaXMgdGhlIHdyb25nIHRocmVhZC4g SSBjcmVhdGVkIGEgbmV3IG9uZS4NCg0KPiBTZWN0aW9uIDcuOSBvZiBwZGFvLWRyYWZ0IGRlZmlu ZXMgYSBuZXcgY29kZSBmb3IgIElDTVB2NiBlcnJvciBtZXNzYWdlICJFcnJvciBpbiBQcm9qZWN0 ZWQgUm91dGUiLiBEb2VzIGl0IG9ubHkgd29yayBmb3IgSUNNUCBlcnJvcnMgc2VudCB0byB0aGUg bWFpbiBSb290Pw0KDQpTZWN0aW9uIDUgc2F5cyDigJwNCg0KDQogICBJbiBjYXNlIG9mIGEgZm9y d2FyZGluZyBlcnJvciBhbG9uZyBhIFByb2plY3RlZCBSb3V0ZSwgYW4gSUNNUCBlcnJvcg0KDQog ICBpcyBzZW50IHRvIHRoZSBSb290IHdpdGggYSBuZXcgQ29kZSAiRXJyb3IgaW4gUHJvamVjdGVk IFJvdXRlIiAoU2VlDQoNCiAgIFNlY3Rpb24gNy45PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLXJvbGwtZGFvLXByb2plY3Rpb24tMTQjc2VjdGlvbi03Ljk+KS4gIFRoZSBS b290IGNhbiB0aGVuIG1vZGlmeSBvciByZW1vdmUgdGhlIFByb2plY3RlZA0KDQogICBSb3V0ZS4g IFRoZSAiRXJyb3IgaW4gUHJvamVjdGVkIFJvdXRlIiBtZXNzYWdlIGhhcyB0aGUgc2FtZSBmb3Jt YXQgYXMNCg0KICAgdGhlICJEZXN0aW5hdGlvbiBVbnJlYWNoYWJsZSBNZXNzYWdlIiwgYXMgc3Bl Y2lmaWVkIGluIFJGQyA0NDQzPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0NDQzPg0K DQogICBbUkZDNDQ0MzxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDQ0Mz5dLg0KDQri gJwNCg0KU28geWVzIHRoZSBpbnRlbnRpb24gd2FzIHRvIHNlbmQgdGhlIElDTVAgdG8gdGhlIG1h aW4gUm9vdC4gQnV0IGFzIHlvdSBwb2ludCBvdXQgdGhlIHBhY2tldCBkb2VzIG5vdCBpbmRpY2F0 ZSBpdCBpcyBmb2xsb3dpbmcgYSBQLXJvdXRlLiBUaGlzIHdhcyByZWxhdGVkIHRvIHN0b3Jpbmcg bW9kZSBQIERBTy4gSW4gbm9uLXN0b3JpbmcgdGhlIG5vZGUgZG9lcyBub3Qga25vdyBpdOKAmXMg YSBQLXJvdXRlLg0KDQoNCj4gSW4gbm9uLXN0b3JpbmcgUERBTywgZm9yd2FyZGVyIGNhbuKAmXQg cmVjb2duaXplIHdoZXRoZXIgZGF0YSBwYWNrZXQgaXMgaW4gUERBTyBpbnN0YW5jZS4gRm9yd2Fy ZGVyIHNob3VsZCBzZW5kIElDTVAgRGVzdGluYXRpb24gVW5yZWFjaGFibGUgZXJyb3IgdG8gcm9v dCAodGhlIHNvdXJjZSBvZiB0aGUgcGFja2V0KSwgdGhlbiByb290IGdlbmVyYXRlcyBJQ01QdjYg ZXJyb3IgbWVzc2FnZSB3aXRoICJFcnJvciBpbiBQcm9qZWN0ZWQgUm91dGXigJ0gdG8gbWFpbiBS b290LiAgSXMgaXQgY29ycmVjdD8NCg0KVGhhdCB3b3VsZCB3b3JrLiBTZWVtcyBuZWF0LiBUaGUg YWx0ZXJuYXRlIHdvdWxkIGJlIHRvIHNpZ25hbCBpdCBpcyBhIFAgcm91dGUgaW4gdGhlIFJQSS4g VGhhdOKAmXMgaXRlbSAyKSBpbiB0aGUgbGlzdCBpbiB0aGlzIHRocmVhZC4gSWYgd2UgZG8gdGhh dCB0aGUgY3VycmVudCB0ZXh0IHdvcmtzLiBXaGF0IG1ha2VzIG1vcmUgc2Vuc2UgdG8geW91Pw0K DQo+IEluIHN0b3JpbmcgUERBTywgZm9yd2FyZGVyIGNhbiByZWNvZ25pemUgdGhlIFBEQU8gaW5z dGFuY2UgZnJvbSB0aGUgUlBJLiBJdCBjYW4gc2VuZCAiRXJyb3IgaW4gUHJvamVjdGVkIFJvdXRl 4oCdIG9yICDigJxEZXN0aW5hdGlvbiBVbnJlYWNoYWJsZSBlcnJvcuKAnSB0byByb290LiBNYXli ZSB3ZSBuZWVkIG1vcmUgY2xhaW1zIGZvciB3aGljaCBjb2RlIGZvcndhcmRlciBzaG91bGQgdXNl Lg0KDQpXZSBoYXZlIHRvIGRlY2lkZSBpZiB3ZSBzZW5kIGl0IHRvIHRoZSBtYWluIHJvb3QgYXMg d3JpdHRlbiBpbiB0aGUgY3VycmVudCBkcmFmdCBvciB0byB0aGUgVHJhY2sgUm9vdC4gSWYgdGhl IFAgcm91dGUgaXMgcmV2ZXJzaWJsZSBjb3VsZCBiZSBkb25lIHRoYXQgd2F5LiBCdXQgdGhhdOKA mXMgYWRkZWQgY29tcGxleGl0eS4gSeKAmW0gbm90IHZlcnkgY29udmluY2VkIGVpdGhlciB3YXku IFRoZSBPa2hhbSByYXpvciBjb3VsZCBiZSB0byBkbyB0aGUgc2ltcGxlc3QuDQoNCktlZXAgc2Fm ZSENCg0KUGFzY2FsDQoNCg0KRnJvbTogUm9sbCA8cm9sbC1ib3VuY2VzQGlldGYub3JnPiBPbiBC ZWhhbGYgT2YgTGkgWmhhbyAobGl6MykNClNlbnQ6IHZlbmRyZWRpIDI3IG5vdmVtYnJlIDIwMjAg MDM6NTENClRvOiBSb3V0aW5nIE92ZXIgTG93IHBvd2VyIGFuZCBMb3NzeSBuZXR3b3JrcyA8cm9s bEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbUm9sbF0gTWFrZSBQLURBTyBiaWRpcmVjdGlvbmFs IFtleHRlbmRzXSBJRVRGIDEwOSBvcGVuIFF1ZXN0aW9ucyBvbiBQLURBTw0KDQpIZWxsbyBQYXNj YWwsDQoNCkl0IGxvb2tzIGdvb2QgZm9yIG1lLiBPbmx5IG9uZSBxdWVzdGlvbiBhYm91dCBJQ01Q IGVycm9ycy4NCg0KU2VjdGlvbiA3Ljkgb2YgcGRhby1kcmFmdCBkZWZpbmVzIGEgbmV3IGNvZGUg Zm9yICBJQ01QdjYgZXJyb3IgbWVzc2FnZSAiRXJyb3IgaW4gUHJvamVjdGVkIFJvdXRlIi4gRG9l cyBpdCBvbmx5IHdvcmsgZm9yIElDTVAgZXJyb3JzIHNlbnQgdG8gdGhlIG1haW4gUm9vdD8NCklu IG5vbi1zdG9yaW5nIFBEQU8sIGZvcndhcmRlciBjYW7igJl0IHJlY29nbml6ZSB3aGV0aGVyIGRh dGEgcGFja2V0IGlzIGluIFBEQU8gaW5zdGFuY2UuIEZvcndhcmRlciBzaG91bGQgc2VuZCBJQ01Q IERlc3RpbmF0aW9uIFVucmVhY2hhYmxlIGVycm9yIHRvIHJvb3QgKHRoZSBzb3VyY2Ugb2YgdGhl IHBhY2tldCksIHRoZW4gcm9vdCBnZW5lcmF0ZXMgSUNNUHY2IGVycm9yIG1lc3NhZ2Ugd2l0aCAi RXJyb3IgaW4gUHJvamVjdGVkIFJvdXRl4oCdIHRvIG1haW4gUm9vdC4gIElzIGl0IGNvcnJlY3Q/ DQpJbiBzdG9yaW5nIFBEQU8sIGZvcndhcmRlciBjYW4gcmVjb2duaXplIHRoZSBQREFPIGluc3Rh bmNlIGZyb20gdGhlIFJQSS4gSXQgY2FuIHNlbmQgIkVycm9yIGluIFByb2plY3RlZCBSb3V0ZeKA nSBvciAg4oCcRGVzdGluYXRpb24gVW5yZWFjaGFibGUgZXJyb3LigJ0gdG8gcm9vdC4gTWF5YmUg d2UgbmVlZCBtb3JlIGNsYWltcyBmb3Igd2hpY2ggY29kZSBmb3J3YXJkZXIgc2hvdWxkIHVzZS4N Cg0KDQpCZXN0IHJlZ2FyZHMsDQpMaQ0KDQoNCg0KRnJvbTogUm9sbCA8cm9sbC1ib3VuY2VzQGll dGYub3JnPG1haWx0bzpyb2xsLWJvdW5jZXNAaWV0Zi5vcmc+Pg0KRGF0ZTogVGh1cnNkYXksIE5v dmVtYmVyIDI2LCAyMDIwIGF0IDE4OjQ4DQpUbzogUm91dGluZyBPdmVyIExvdyBwb3dlciBhbmQg TG9zc3kgbmV0d29ya3MgPHJvbGxAaWV0Zi5vcmc8bWFpbHRvOnJvbGxAaWV0Zi5vcmc+Pg0KU3Vi amVjdDogUmU6IFtSb2xsXSBNYWtlIFAtREFPIGJpZGlyZWN0aW9uYWwgW2V4dGVuZHNdIElFVEYg MTA5IG9wZW4gUXVlc3Rpb25zIG9uIFAtREFPDQpIZWxsbyBMaQ0KDQpJbiB0aGUgcGFja2V0LCB0 aGVyZeKAmXMgYSBiaXQgaW4gdGhlIFJQSSB0byBzYXkgaWYgdGhlIHJvb3QgaXMgdGhlIHNvdXJj ZSBvciB0aGUgZGVzdGluYXRpb24uIFRoYXTigJlzIFJGQyA2NTUwLg0KSSBndWVzcyB0aGUgZGlz Y3Vzc2lvbiBpcyByZWxhdGVkIHRvIHRoZSBQRFIgYW5kIFAtREFPLCBub3QgZGF0YSBwYWNrZXQs IHRob3VnaCBpdCBpbXBhY3RzIHRoZSBJQ01QIGVycm9yIHJlcG9ydGluZy4NCg0KSW4gYSBwYWNr ZXQgYWxvbmcgdGhlIFAtUm91dGUsIHRoZSBpZGVhIHdhcyBzbyBmYXIgdGhhdCB0aGUgRE9EQUcg aXMgYSBjb252ZXJnZWNhc3QgdG8gdGhlIGRlc3RpbmF0aW9uIHNvIHRoZSBkZXN0aW5hdGlvbiBp cyB0aGUgcm9vdC4gSWYgd2Ugc2F5IHRoYXQgdGhlcmXigJlzIGEgc2luZ2xlIGluZ3Jlc3MgYW5k IGEgc2luZ2xlIGVncmVzcyB0aGVuIHRoZSBkb2RhZyBpcyByZXZlcnNpYmxlIGFuZCBlaXRoZXIg Y2FuIGJlIHRoZSByb290LiBJZiB3ZSB3YW50IHRvIHN1cHBvcnQgbXVsdGljYXN0IHRyYWNrcyBp biB0aGUgZnV0dXJlLCB0aGVuIHRoZSBpbmdyZXNzIHNob3VsZCBiZSByb290Lg0KDQpJZiB0aGUg VHJhY2sgaGFzIGEgc2luZ2xlIGluZ3Jlc3MgYW5kIGEgc2luZ2xlIGVncmVzcywgdGhlbiB0aGUg RE9EQUcgaXMgcmV2ZXJzaWJsZSBpbnRvIGFub3RoZXIgRE9EQUcgYW5kIGl0IGRvZXMgbm90IG1h dHRlciB3aGljaCBpcyByb290LCBzbyB3ZSBjYW4gbWFrZSBpdCBiaWRpciBhcyBIdWltaW4gYXNr ZWQuDQpUaGUgc3RvcmluZyBtb2RlIFAgREFPIHdvdWxkIGxvb2sgYSBsb3QgbW9yZSBsaWtlIGEg REFPLCBhcyB5b3UgcG9pbnRlZCBvdXQsIGlmIGl0IGdvZXMgdG93YXJkcyB0aGUgcm9vdC4gSWYg d2Ugd2FudCB0byB0YWtlIHRoYXQgcGF0aCwgYSBub2RlIGNvdWxkIGxlYXJuIGJvdGggZGlyZWN0 aW9ucyB3aXRoIGEgc2luZ2xlIHN0b3JpbmcgbW9kZSBQIERBTy4gVG8gYmUgY29udGludWVk4oCm DQoNCkZvciBub24tc3RvcmluZywgbWFraW5nIGJpZGlyIGlzIHJlYWxseSBoYXJkLiBJdCBzZWVt cyBlYXNpZXIgdG8gaW5zdGFsbCBhIFRyYWNrIGluIGJvdGggZGlyZWN0aW9ucyBhbmQgY291cGxl IHRoZW0uDQoNCkFzIGEgc3VtbWFyeSBvZiB0aGUgcHJvcG9zZWQgY2hhbmdlczoNCg0KR2VuZXJh bA0KLSB3ZSBtYWtlIHRoZSByb290IHRoZSBpbmdyZXNzDQotIElDTVAgZXJyb3JzIHNlbnQgdG8g dGhlIFJvb3QsIHVzaW5nIHRoZSBtYWluIERPREFHIGlmIHRoZSB0cmFjayBpcyBub3QgcmV2ZXJz aWJsZQ0KDQoNClN0b3JpbmcgbW9kZSBQIERBTzoNCi0gd2UgYWxzbyBtYWtlIHRoZSByb290IHRo ZSBpbmdyZXNzLCBQLURBTyBmcm9tIGVncmVzcyB0byBpbmdyZXNzIGFyZSBub3cgbW9yZSBzaW1p bGFyIHRvIFJQTCBEQU8gb3BlcmF0aW9uDQotIHRoZSB0cmFjayBjb3VsZCBiZSBtYWRlIGJpLWRp cmVjdGlvbmFsLCBidXQgdGhhdOKAmXMgbW9yZSBjb2RlOyBpZiBzbzoNCiAgLSB0aGUgcGFja2V0 IGZvcndhcmRpbmcgbGV2ZXJhZ2VzIHRoZSBSUEkgdG8gaW5kaWNhdGUgdGhlIGRpcmVjdGlvbiwg ZnJvbSBvciB0byByb290DQogIC0gSUNNUCBlcnJvcnMgc2VudCB0byB0aGUgUm9vdCwgY291bGQg YmUgc291cmNlIG9yIGRlc3RpbmF0aW9uLg0KDQpOb24gc3RvcmluZyBtb2RlIFAgREFPOg0KLSB0 cmFja3MgcmVtYWluIGRpcmVjdGlvbmFsLCBjYW4gYmUgY291cGxlZCwgaG93IGlzIHRiZA0KLSB0 aGUgUlBJIGlzIG1vc3RseSB1c2VsZXNzIHNpbmNlIHRoZSBpbnRlcm1lZGlhdGUgbm9kZXMgZG8g bm90IGtub3cgdGhlIGluc3RhbmNlICh0aGV5IHNlZSBuZWl0aGVyIHRoZSBESU8gbm9yIHRoZSBQ LURBTyk7IHRoZXkgaGF2ZSBubyBpZGVhIG9mIHRoZWlyIFJhbmsuIFN0aWxsLCBpdCBpcyBpbnRl cmVzdGluZyB0byBoYXZlIGlzIGZvciBlcnJvciBkZXRlcm1pbmF0aW9uIGluIGFuIElDUE1QIGVy cm9yIGF0IGV0aCByb290LiBJdCBpcyBhbHNvIGludGVyZXN0aW5nIGlmIHRoZSBTUkggZm9yd2Fy ZGluZyBub2RlcyBoYXZlIGEgc3RhdGUgYXNzb2NpYXRlZCB0byB0aGUgVHJhY2ssIGUuZy4sIHJl c2VydmVkIHRpbWUgc2xvdHMgb3IgcHJpb3JpdHkgcXVldWVzLg0KLSB0aGUgUlBJIGlzIHN0aWxs IGEgU0hPVUxEIHdoZW4gdGhlcmXigJlzIG5vIGNvbXByZXNzaW9uIGFuZCBhIE1VU1Qgd2hlbiB0 aGVyZSBpcy4gV2UgbmVlZCB0byBjbGFyaWZ5IHdoYXQgdG8gZG8sIHRoYXTigJlzIGFub3RoZXIg b2YgSHVpbWlu4oCZcyBxdWVzdGlvbnMsIHRha2VuIHNlcGFyYXRlbHkuDQotIElDTVAgZXJyb3Jz IGZvcndhcmRpbmcgcGFja2V0cyBhcmUgc2VudCB0byB0aGUgcm9vdCB3aGljaCBpcyBub3cgdGhl IGluZ3Jlc3MsIGFrYSB0aGUgc291cmNlIG9mIHRoZSBwYWNrZXQsIGFuZCB0aGUgZW5jYXBzdWxh dG9yIGZpZWxkIGlmIHRoZSBwYWNrZXQgaXMgZW5jYXBzdWxhdGVkIGFuZCBjb21wcmVzc2VkLiBU aGlzIGlzIGNvbW1vbiB0byBhbnkgbm9uLXN0b3Jpbmcgb3BlcmF0aW9uLCB3aGV0aGVyIGl0IGlz IGEgbWFpbiBJbnN0YW5jZSwgbG9jYWwgSW5zdGFuY2UsIG9yIFRyYWNrLiBUaGUgUlBJIHRoZXJl aW4gaXMgdXNlZnVsIHRvIGluZGljYXRlIHRoZSBUcmFjayBpbiBFcnJvci4gU28gZm9yIHRoYXQg bWF0dGVyIHRoZSBmb3J3YXJkZXIgZG9lcyBub3QgbmVlZCB0byBtYWtlIGEgZGlmZmVyZW5jZSBU cmFjayB2cy4gb3RoZXIgZm9ybSBvZiBSUEwgbG9jYWwgaW5zdGFuY2UuDQotIHRoaXMgaW1wYWN0 cyB0aGUgZGlzY3Vzc2lvbiBpbiBTUkggcmVsb2FkaW5nIHdlIGhhZCBhdCBJRVRGIDEwOSwgd2hl biBhICBOLVMgbW9kZSBsb29zZSB0cmFjayBpcyBmb3J3YXJkZWQgYWxvbmcgYSBzZWdtZW50IHRo YXQgaXMgYWxzbyBOUyBtb2RlLiBXZeKAmWxsIHByb2JhYmx5IG5lZWQgdG8gcmUtZW5jYXBzdWxh dGUgbm93LiAgSW4gY2FzZSBvZiByZS1lbmNhcHN1bGF0aW9uLCB0aGUgcmUtZW5jYXBzdWxhdG9y IGJlY29tZXMgc291cmNlIGFuZCByb290IG9mIHRoZSBzZWdtZW50LCB3aGljaCBub3cgaGFzIHRv IGJlIGNvbnNpZGVyZWQgYXMgYSBzZXJpYWwgVHJhY2s7IGFzIHR1bm5lbCBoZWFkZW5kcyBkbywg aXQgd2lsbCBoYXZlIHRvIGRlY2Fwc3VsYXRlIHRoZSB0dW5uZWxlZCBwYWNrZXQgdG8gc2VuZCB0 aGUgcGFja2V0IGluIGVycm9yIGJhY2sgdG8gdGhlIGluZ3Jlc3Mgb2YgdGhlIGxvb3NlIHRyYWNr DQoNCg0KRG9lIHRoYXQgd29yaz8NCg0KUGFzY2FsDQoNCkZyb206IFJvbGwgPHJvbGwtYm91bmNl c0BpZXRmLm9yZzxtYWlsdG86cm9sbC1ib3VuY2VzQGlldGYub3JnPj4gT24gQmVoYWxmIE9mIExp IFpoYW8gKGxpejMpDQpTZW50OiBqZXVkaSAyNiBub3ZlbWJyZSAyMDIwIDAzOjQ1DQpUbzogUm91 dGluZyBPdmVyIExvdyBwb3dlciBhbmQgTG9zc3kgbmV0d29ya3MgPHJvbGxAaWV0Zi5vcmc8bWFp bHRvOnJvbGxAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtSb2xsXSBNYWtlIFAtREFPIGJpZGly ZWN0aW9uYWwgW2V4dGVuZHNdIElFVEYgMTA5IG9wZW4gUXVlc3Rpb25zIG9uIFAtREFPDQoNCkhl bGxvIFBhc2NhbCwNCg0KSWYgZWl0aGVyIHNvdXJjZSBvciBkZXN0aW5hdGlvbiBjYW4gYmUgcm9v dCwgaXTigJlzIGJldHRlciB0byBpZGVudGlmeSB3aGVuIG9yIGluIHdoaWNoIGNhc2Ugc291cmNl IG9yIGRlc3RpbmF0aW9uIGNhbiBiZSByb290LiBPdGhlcndpc2UsIGl04oCZcyBoYXJkIHRvIGlu dGVyb3AgYmV0d2VlbiBkaWZmZXJlbnQgaW1wbGVtZW50IGV2ZW4gdGhvdWdoIHRoZXkgYm90aCBm b2xsb3cgUkZDIHN0YW5kYXJkLg0KDQpFLmcuIGZvciBub24tc3RvcmluZyBtb2RlIFBEQU8sIGlm IHNvdXJjZSBpcyByb290LCBQQ0Ugb25seSByZXNwb25zZXMgUERSLUFDSyBhZnRlciByZWNlaXZp bmcgUERSIGZyb20gc291cmNlLg0KQnV0IGlmIGRlc3RpbmF0aW9uIGlzIHJvb3QsIFBDRSBzaG91 bGQgYWxzbyBub3RpZnkgZGVzdGluYXRpb24gd2hpY2ggdHJhY2tpZCBpcyB1c2VkLiBNYXliZSB3 ZSBuZWVkIGJyaW5nIG5ldyBtZXNzYWdlIGZvciB0aGlzIG5vdGlmaWNhdGlvbj8NCg0KDQpUYWtl IGNhcmUsDQpMaQ0KDQpGcm9tOiBSb2xsIDxyb2xsLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnJv bGwtYm91bmNlc0BpZXRmLm9yZz4+DQpEYXRlOiBXZWRuZXNkYXksIE5vdmVtYmVyIDI1LCAyMDIw IGF0IDIxOjU0DQpUbzogUm91dGluZyBPdmVyIExvdyBwb3dlciBhbmQgTG9zc3kgbmV0d29ya3Mg PHJvbGxAaWV0Zi5vcmc8bWFpbHRvOnJvbGxAaWV0Zi5vcmc+Pg0KU3ViamVjdDogUmU6IFtSb2xs XSBNYWtlIFAtREFPIGJpZGlyZWN0aW9uYWwgW2V4dGVuZHNdIElFVEYgMTA5IG9wZW4gUXVlc3Rp b25zIG9uIFAtREFPDQpIZWxsbyBMaTsNCg0KV2VsbCBub3RlZC4gVGhpcyB3YXMgdGhlIG9yaWdp bmFsIGludGVudC4gVGhlIGNoYW5nZSB3YXMgbWFkZSB0byBlZ3Jlc3MgYmVjYXVzZSB0aGUgaWRl YSB3YXMgdGhhdCB0aGUgdHJhY2sgY291bGQgZW5hYmxlIG11bHRpcGxlIHNvdXJjZXMgdG8gcmVh Y2ggdGhlIGVncmVzcywgbGlrZSBhIHRyZWUgcm9vdGVkIGF0IHRoZSBlZ3Jlc3MgdGhhdCBmbG93 cyB0cmF2ZXJzZSBnb2luZyBkb3duLiBCdXQgdGhlIGlkZWEgb2YgYSBiaWRpcmVjdGlvbmFsIHRy YWNrIGtpbmRhIGJsb2NrcyB0aGF0IGlkZWEgYW5kIHRoZSBvdGhlciBpc3N1ZXMgbGlrZSB0aGUg b25lIHlvdSBwb2ludCBvdXQgc2VlbSB0byBnZXQgdXMgYmFjayB0byB0aGUgb3JpZ2luYWwgdmll dy4gSSByZWNlbnRseSBtYWRlIHRoZSBjaGFuZ2UgZnJvbSBpbmdyZXNzIHRvIGVncmVzcyBpbiB0 aGUgNlRpU0NIIGFyY2hpdGVjdHVyZSwgd2FpdGluZyBpbiBSRkMgZWRpdG9yIHF1ZXVlLiBJIGNv dWxkIHJldmVyc2UgYmFjaywgb3IgbWF5YmUgc2F5IOKAnGVpdGhlciBzb3VyY2Ugb3IgZGVzdGlu YXRpb27igJ0gc28gaXQgY2FuIGJlIGVncmVzcyBvciBlZ3Jlc3MgYW5kIHdlIGFyZSBjb3ZlcmVk IGZvciBiaWRpcmVjdGlvbmFsLg0KV2hhdCBkbyB5b3UgdGhpbms/DQpPciBzaG91bGQgYSByZXZl cnNhYmxlIFRyYWNrIGJlIHJlYWxseSBhIHBhaXIgb2YgdHJhY2tzPw0KDQpLZWVwIHNhZmU7DQoN ClBhc2NhbA0KDQpGcm9tOiBSb2xsIDxyb2xsLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOnJvbGwt Ym91bmNlc0BpZXRmLm9yZz4+IE9uIEJlaGFsZiBPZiBMaSBaaGFvIChsaXozKQ0KU2VudDogbWVy Y3JlZGkgMjUgbm92ZW1icmUgMjAyMCAwNTo1Nw0KVG86IFJvdXRpbmcgT3ZlciBMb3cgcG93ZXIg YW5kIExvc3N5IG5ldHdvcmtzIDxyb2xsQGlldGYub3JnPG1haWx0bzpyb2xsQGlldGYub3JnPj4N ClN1YmplY3Q6IFJlOiBbUm9sbF0gTWFrZSBQLURBTyBiaWRpcmVjdGlvbmFsIFtleHRlbmRzXSBJ RVRGIDEwOSBvcGVuIFF1ZXN0aW9ucyBvbiBQLURBTw0KDQpIZWxsbyBQYXNjYWwsDQoNCkluZ3Jl c3MgYXMgUm9vdCBsb29rcyBiZXR0ZXIgYmVjYXVzZQ0KMS4gIEl0IGlzIGNvbnNpc3RlbnQgd2l0 aCB0aGUgd2F5IFJQTCB1c3VhbGx5IHdvcmtzLiBSUEwgTG9jYWwgaW5zdGFuY2UsIGFvZHYtcnBs LCBwMnAtcnBsIGFsbCB1c2UgaW5ncmVzcyBhcyByb290Lg0KMi4gIEZvciBub24tc3RvcmluZy1t b2RlIFAtREFPLCBjdXJyZW50bHkgaW5ncmVzcyBzZW5kcyB1cHdhcmQgdHJhZmZpYyB0byBlZ3Jl c3Mocm9vdCkgd2l0aCBTUiBoZWFkZXIuIEJ1dCBpbiBSUEwsIG9ubHkgZG93bndhcmQgdHJhZmZp YyBjYXJyaWVzIFNSIGhlYWRlci4NCjMuICBPbmx5IGluZ3Jlc3MgY2FuIHNlbmQgUERSIG1ha2Vz IHNlbnNlLiBCZWhhdmlvciBvZiBUcmFja0lkIGlzIHNpbWlsYXIgYXMgTG9jYWwgSW5zdGFuY2Ug SUQuIEluZ3Jlc3MgYXMgcm9vdCBjYW4gcHJvcG9zZSBUcmFja0lkIGZyb20gaXRzIG5hbWVzcGFj ZS4NCg0KDQpBbmQgZm9yIHN0b3JpbmctbW9kZSBQLURBTywgaWYgd2UgbWFrZSBpbmdyZXNzIGFz IHJvb3QgYW5kIGluZ3Jlc3Mgc2VuZHMgUERSLCBjYW4gUENFIHNlbmQgUC1EQU8gdG8gZWdyZXNz IHRoZW4gZWdyZXNzIGZvcndhcmRzIGl0IHRvd2FyZHMgcHJlZGVjZXNzb3IgdG8gaW5ncmVzcz8N Ck1heWJlIGl0IGhlbHBzIHRvIG1ha2UgUC1EQU8gbG9va3MgbGlrZSBhIERBTyBtZXNzYWdlLg0K DQoNCkJlc3QgcmVnYXJkcywNCkxpDQoNCg0KRnJvbTogUm9sbCA8cm9sbC1ib3VuY2VzQGlldGYu b3JnPG1haWx0bzpyb2xsLWJvdW5jZXNAaWV0Zi5vcmc+Pg0KRGF0ZTogVHVlc2RheSwgTm92ZW1i ZXIgMjQsIDIwMjAgYXQgMjE6MzkNClRvOiBSb3V0aW5nIE92ZXIgTG93IHBvd2VyIGFuZCBMb3Nz eSBuZXR3b3JrcyA8cm9sbEBpZXRmLm9yZzxtYWlsdG86cm9sbEBpZXRmLm9yZz4+DQpTdWJqZWN0 OiBbUm9sbF0gTWFrZSBQLURBTyBiaWRpcmVjdGlvbmFsIFtleHRlbmRzXSBJRVRGIDEwOSBvcGVu IFF1ZXN0aW9ucyBvbiBQLURBTw0KRGVhciBhbGwNCg0KV2hldGhlciB0byBtYWtlIHRoZSBQLURB TyBiaWRpcmVjdGlvbmFsIGlzIGFuIGludHJpZ3VpbmcgcXVlc3Rpb24uIEl0IGNvdWxkIGJlIGRv bmUsIGp1c3QgbGlrZSB3ZSBjYW4gc2VuZCBwYWNrZXRzIERPV04gYSBjbGFzc2ljYWwgRE9EQUcu DQpCdXQgaWYgd2UgdGFrZSB0aGF0IHBhdGgsIHdlIHJlb3BlbiB0aGUgcXVlc3Rpb24gb2Ygd2hv IGlzIHJvb3QgYW5kIHdoaWNoIGRpcmVjdGlvbiB0aGUgUC1EQU8gZmxpZXMuDQoNCkNvdWxkIHdl IG1ha2UgZWl0aGVyIHRoZSBpbmdyZXNzIE9SIHRoZSBlZ3Jlc3Mgcm9vdD8gSG93IGRvZXMgaXQg bWF0dGVyPw0KDQpBdCB0aGUgbW9tZW50IHRoZSBSb290IGlzIHRoZSBlZ3Jlc3MgYW5kIHRoZSBz dG9yaW5nLW1vZGUgUC1EQU8gZmxpZXMgZnJvbSB0aGUgVHJhY2sgZWdyZXNzIHRvIHRoZSB0cmFj ayBpbmdyZXNzLCBhbmQgdGhlIHRyYWNrIGVncmVzcyBpcyB0aGUgcm9vdC4gVGhpcyBpcyBub3Qg dGhlIHdheSBSUEwgdXN1YWxseSB3b3JrcyBhcyB0aGUgREFPIGZsaWVzIHRvd2FyZHMgdGhlIHJv b3QuIFRoZSByZWFzb24gd2FzIHRoYXQgd2Ugd2FudGVkIGEgc2luZ2xlIGVncmVzcyBmb3IgdGhl IFRyYWNrLCBhcyB3ZSBidWlsZCB1bmljYXN0IFRyYWNrLiBJZiB3ZSB3YW50ZWQgdG8gYnVpbGQg bXVsdGljYXN0IFRyYWNrcyB0aGUgcm9vdCBzaG91bGQgbG9naWNhbGx5IGJlIHRoZSBpbmdyZXNz LiBBbmQgZm9yIGJpZGlyZWN0aW9uYWwgVHJhY2tzIGl0IGNvdWxkIGJlIGVpdGhlci4NCg0KVXAg dG8gLTI0IHRoZSA2VGlTQ0ggQXJjaGl0ZWN0dXJlIGV4cGVjdGVkIHRoZSBpbmdyZXNzIHRvIGJl IHJvb3QuIEkgY2hhbmdlZCBpbiB0aGUgbGF0ZXN0IHRvIG1hcCB3ZSBkbyBoZXJlLCB0aGF0IGl0 IGlzIHRoZSBlZ3Jlc3M7IG1heWJlIGEgZmxhZyBpbiB0aGUgREFPIHdvdWxkIGluZGljYXRlIHdo aWNoIGRpcmVjdGlvbiB0aGUgZmxvdywgZnJvbSByb290LCB0byByb290LCBvciBib3RoPw0KDQpB bHNvIGlmIHdlIGJ1aWxkIGJpZGlyIFRyYWNrcyBpbiBzdG9yaW5nIG1vZGUsIHRoZSBub2RlcyB0 aGF0IGZvcndhcmQgdGhlIERBTyB3aWxsIGhhdmUgdG8gYnVpbGQgcm91dGVzIGluIGJvdGggZGly ZWN0aW9ucyBiYXNlZCBvbiB0aGUgUC1EQU8sIGJvdGggdG93YXJkcyBlZ3Jlc3MgYW5kIGluZ3Jl c3M7IGJ1dCBvbmx5IHRoZSBwYXRoIGZyb20gd2hpY2ggdGhlIFAtREFPIGNvbWVzIGhhcyBiZWVu IHZhbGlkYXRlZCBieSB0aGUgUC1EQU8gaXRzZWxmLiBTaG91bGQgd2Ugc2VuZCBhIFAtREFPIHRv IGVhY2ggZW5kLCBlYWNoIHNldHRpbmcgdXAgb25lIHdheT8NCg0KUGxlYXNlIGxldCBtZSBrbm93 IHlvdXIgdGhvdWdodHMNCg0KUGFzY2FsDQoNCg0KRnJvbTogUm9sbCA8cm9sbC1ib3VuY2VzQGll dGYub3JnPG1haWx0bzpyb2xsLWJvdW5jZXNAaWV0Zi5vcmc+PiBPbiBCZWhhbGYgT2YgUGFzY2Fs IFRodWJlcnQgKHB0aHViZXJ0KQ0KU2VudDogbWFyZGkgMjQgbm92ZW1icmUgMjAyMCAxNDoyMg0K VG86IFJvdXRpbmcgT3ZlciBMb3cgcG93ZXIgYW5kIExvc3N5IG5ldHdvcmtzIDxyb2xsQGlldGYu b3JnPG1haWx0bzpyb2xsQGlldGYub3JnPj4NClN1YmplY3Q6IFtSb2xsXSBJRVRGIDEwOSBvcGVu IFF1ZXN0aW9ucyBvbiBQLURBTw0KDQpEZWFyIGFsbA0KDQpUaGUgc2xpZGVzIGZvciB0aGUgUC1E QU8gZGlzY3Vzc2lvbiBhdCBJRVRGIDEwOSBhcmUgYXZhaWxhYmxlIGhlcmU6DQoNCmh0dHBzOi8v ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL3NsaWRlcy0xMDktcm9sbC1kYW8tcHJvamVjdGlvbi8N Cg0KVGhlcmUgYXJlIGEgbnVtYmVyIG9mIG9wZW4gcXVlc3Rpb25zIHRoYXQgd2Ugc3RhcnRpbmcg ZGlzY3Vzc2luZywgYW5kIHdvdWxkIG5lZWQgdG8gcHJvZ3Jlc3Mgb24gdGhlIGxpc3QuDQpTb21l IG9mIHRoZW0gd2VyZSBleHByZXNzZWQgb24gdGhlIGxpc3QsIGUuZy4sIGZyb20gSHVpbWluIFNo ZS4gSeKAmWQgbGlrZSB0byBwcm9ncmVzcyBvbiB0aGVtIGFsbCB3aXRoIGluZGl2aWR1YWwgdGhy ZWFkcy4NClRoZSBxdWVzdGlvbnMgYXJlOg0KDQoNCiAgMS4gIExpZmV0aW1lIFVuaXQ6IGNvdWxk IHdlIHVzZSBhIGRpZmZlcmVudCB1bml0IGZvciBQLURBTz8NCiAgMi4gIEhvdyB0byBkaWZmZXJl bnRpYXRlIGEgUC1EQU8gZnJvbSBhIG5vcm1hbCBEQU8gaW4gYSBsb2NhbCBpbnN0YW5jZTsgbmV3 IGZsYWc/DQogIDMuICBNYWtlIFAtREFPIGJpZGlyZWN0aW9uYWw/DQogIDQuICBXaG8gc2VuZHMg dGhlIFBEUj8gRG9lcyBpdCBoYXZlIHRvIGJlIHRoZSBpbmdyZXNzPyBJZiBpdCB3YXMgZWdyZXNz IGl0IGNvdWxkIHByb3Bvc2UgYSBUcmFja0lkIGZyb20gaXRzIG5hbWVzcGFjZS4gRWxzZSBjb3Vs ZCB0aGUgaW5ncmVzcyBiZSB0aGUgcm9vdD8NCiAgNS4gIE1haW50YWluaW5nIHRoZSBzaWJsaW5n IHN0YXRlLiBTaG91bGQgd2UgaGF2ZSB0ZXh0IG9uIHVzaW5nIFJGQyA4NTA1IHRoZXJlPw0KICA2 LiAgV2hldGhlciBpbmdyZXNzIGFuZCBlZ3Jlc3MgYXJlIGxpc3RlZCBpbiBOUE8/IFRvZGF5IHRo ZXkgYXJlIGJvdGgsIGluZ3Jlc3MgdG8gaW5kaWNhdGUgdGhlIHBhY2tldCBzb3VyY2UgaW4gY2Fz ZSBvZiBlbmNhcHN1bGF0aW9uIGFuZCBmb3IgU1JILTZMb1JIIGNvbXByZXNzaW9uIHJlZmVyZW5j ZSBhbmQgZWdyZXNzIHRvIGJ1aWxkIHRoZSBmdWxsIFNSSC02TG9SSC4gTm90ZSB0aGF0IHRoZSBp bmdyZXNzIG11c3QgY29uc3VtZSB0aGUgZmlyc3QgZW50cnkgYW5kIHVzZSBpdCBhcyBzb3VyY2Uu DQogIDcuICBUcmFjayBpbiBUcmFjayB2cy4gU1IgSGVhZGVyIHJlbG9hZCBtb2RlbHMsIHNlZSBz bGlkZXMNCg0KTGV0IG1lIG9wZW4gdGhyZWFkcyB0byBmb2xsb3cgdXAuDQoNCktlZXAgc2FmZQ0K DQpQYXNjYWwNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KUm9sbCBtYWlsaW5nIGxpc3QNClJvbGxAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vcm9sbA0K --_000_AC612802904C4FA781EDE661E1E50212ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQpX ZSBjZXJ0YWlubHkgY2FuLCBMaS4NCjxkaXY+PGJyPg0KPGRpdiBkaXI9Imx0ciI+DQo8ZGl2Pjxi cj4NCjwvZGl2Pg0KUmVnYXJkcywNCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlBhc2NhbDwvZGl2 Pg0KPC9kaXY+DQo8ZGl2IGRpcj0ibHRyIj48YnI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj5M ZSAyNyBub3YuIDIwMjAgw6AgMDk6NTIsIExpIFpoYW8gKGxpejMpICZsdDtsaXozPTQwY2lzY28u Y29tQGRtYXJjLmlldGYub3JnJmd0OyBhIMOpY3JpdCZuYnNwOzo8YnI+DQo8YnI+DQo8L2Jsb2Nr cXVvdGU+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHR5cGU9ImNpdGUiPg0KPGRpdiBkaXI9Imx0ciI+ 77u/DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChm aWx0ZXJlZCBtZWRpdW0pIj4NCiA8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQg NSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6RGVuZ1hpYW47DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5 OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiXEBEZW5nWGlhbiI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEg MTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwg ZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsNCgl0ZXh0LWRlY29yYXRp b246dW5kZXJsaW5lO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxl LWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowY207DQoJbWFyZ2luLWJv dHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Ijt9DQpwLk1zb0xpc3RQYXJhZ3JhcGgsIGxpLk1zb0xpc3RQYXJhZ3JhcGgsIGRpdi5Nc29M aXN0UGFyYWdyYXBoDQoJe21zby1zdHlsZS1wcmlvcml0eTozNDsNCgltYXJnaW4tdG9wOjBjbTsN CgltYXJnaW4tcmlnaHQ6MGNtOw0KCW1hcmdpbi1ib3R0b206MGNtOw0KCW1hcmdpbi1sZWZ0OjM2 LjBwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCnNwYW4uSFRNTFByZWZvcm1hdHRlZENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IkhUTUwg UHJlZm9ybWF0dGVkIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt bGluazoiSFRNTCBQcmVmb3JtYXR0ZWQiOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0K c3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAu MHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJn aW46NzAuODVwdCA3MC44NXB0IDcwLjg1cHQgNzAuODVwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJ e3BhZ2U6V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJ e21zby1saXN0LWlkOjMzODQyODAwNjsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlz dC10ZW1wbGF0ZS1pZHM6LTQyOTI1Mjg0NiA2NzY5ODcwNSA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5 ODcwMyA2NzY5ODcxMyA2NzY5ODcxNSA2NzY5ODcwMyA2NzY5ODcxMyA2NzY5ODcxNTt9DQpAbGlz dCBsMDpsZXZlbDENCgl7bXNvLWxldmVsLXRleHQ6IiUxXCkiOw0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot MTguMHB0O30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBo YS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9w Om5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDot OS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBs aXN0IGwwOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCglt c28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxp c3QgbDA6bGV2ZWw3DQoJe21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotMTguMHB0O30NCkBsaXN0IGwwOmxldmVs OA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDphbHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LTE4LjBwdDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDENCgl7bXNv LWxpc3QtaWQ6MTYyMzk5MzMwNDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE4Nzg2MDk0Mjg7 fQ0Kb2wNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0KdWwNCgl7bWFyZ2luLWJvdHRvbTowY207fQ0K LS0+PC9zdHlsZT4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+SGVsbG8gUGFzY2FsLDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+ Uzwvc3Bhbj5pZ25hbCBQIHJvdXRlIGluIHRoZSBSUEk8c3BhbiBsYW5nPSJFTi1VUyI+IGxvb2tz IGJldHRlciBiZWNhdXNlIHdlIGFsc28gbmVlZCB0aGlzIGZsYWcgdG8gaWdub3JlIFNlbmRlclJh bmsgY2hlY2sgaW4gUlBJIGZvciBub24tc3RvcmluZyBQREFPLg0KPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkNhbiB3ZSB1cGRh dGUgdGhlIFJGQzY1NTMgZWFzaWx5PyBGb3IgZXhhbXBsZSwgYWRkIDEtYml0IGZsYWcgaW4gcmVz ZXJ2ZWQgZmllbGQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gbGFuZz0iRU4tVVMiPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+TGk8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXYg c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6Ymxh Y2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9y OmJsYWNrIj5Sb2xsICZsdDtyb2xsLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+RGF0ZTog PC9iPkZyaWRheSwgTm92ZW1iZXIgMjcsIDIwMjAgYXQgMTU6NDg8YnI+DQo8Yj5UbzogPC9iPlJv dXRpbmcgT3ZlciBMb3cgcG93ZXIgYW5kIExvc3N5IG5ldHdvcmtzICZsdDtyb2xsQGlldGYub3Jn Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5bUm9sbF0gRXJyb3IgZmxvd3MsIHdoaWNoIElDTVAg ZXJyb3JzIGFuZCB0byB3aGljaCByb290PzogW2V4dGVuZHNdIElFVEYgMTA5IG9wZW4gUXVlc3Rp b25zIG9uIFAtREFPPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5IZWxsbyBMaTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGlzIGlzIHRoZSB3cm9u ZyB0aHJlYWQuIEkgY3JlYXRlZCBhIG5ldyBvbmUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZn dDsgPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQiPlNlY3Rpb24gNy45IG9mIHBkYW8tZHJh ZnQgZGVmaW5lcyBhIG5ldyBjb2RlIGZvciAmbmJzcDtJQ01QdjYgZXJyb3IgbWVzc2FnZSAmcXVv dDtFcnJvciBpbiBQcm9qZWN0ZWQgUm91dGUmcXVvdDsuIERvZXMgaXQgb25seSB3b3JrIGZvcg0K PC9zcGFuPklDTVAgZXJyb3JzIHNlbnQgdG8gdGhlIG1haW4gUm9vdD8gPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlNlY3Rpb24gNSBzYXlzIOKAnDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cHJlPiZuYnNwOyZuYnNwOyBJbiBjYXNl IG9mIGEgZm9yd2FyZGluZyBlcnJvciBhbG9uZyBhIFByb2plY3RlZCBSb3V0ZSwgYW4gSUNNUCBl cnJvcjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBpcyBzZW50IHRvIHRoZSBS b290IHdpdGggYSBuZXcgQ29kZSAmcXVvdDtFcnJvciBpbiBQcm9qZWN0ZWQgUm91dGUmcXVvdDsg KFNlZTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1yb2xsLWRhby1wcm9qZWN0aW9uLTE0I3Nl Y3Rpb24tNy45Ij5TZWN0aW9uIDcuOTwvYT4pLiZuYnNwOyBUaGUgUm9vdCBjYW4gdGhlbiBtb2Rp Znkgb3IgcmVtb3ZlIHRoZSBQcm9qZWN0ZWQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsm bmJzcDsgUm91dGUuJm5ic3A7IFRoZSAmcXVvdDtFcnJvciBpbiBQcm9qZWN0ZWQgUm91dGUmcXVv dDsgbWVzc2FnZSBoYXMgdGhlIHNhbWUgZm9ybWF0IGFzPG86cD48L286cD48L3ByZT4NCjxwcmU+ Jm5ic3A7Jm5ic3A7IHRoZSAmcXVvdDtEZXN0aW5hdGlvbiBVbnJlYWNoYWJsZSBNZXNzYWdlJnF1 b3Q7LCBhcyBzcGVjaWZpZWQgaW4gPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L3JmYzQ0NDMiPlJGQyA0NDQzPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNw OyBbPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzQ0NDMiPlJGQzQ0NDM8 L2E+XS48bzpwPjwvbzpwPjwvcHJlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj7igJw8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+U28geWVzIHRoZSBpbnRlbnRpb24gd2FzIHRvIHNlbmQgdGhlIElDTVAgdG8gdGhlIG1haW4g Um9vdC4gQnV0IGFzIHlvdSBwb2ludCBvdXQgdGhlIHBhY2tldCBkb2VzIG5vdCBpbmRpY2F0ZSBp dCBpcyBmb2xsb3dpbmcgYSBQLXJvdXRlLiBUaGlzIHdhcyByZWxhdGVkIHRvIHN0b3JpbmcgbW9k ZSBQIERBTy4gSW4gbm9uLXN0b3JpbmcgdGhlIG5vZGUgZG9lcyBub3Qga25vdyBpdOKAmXMgYSBQ LXJvdXRlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgSW4gbm9uLXN0b3JpbmcgUERBTywgZm9yd2FyZGVyIGNh buKAmXQgcmVjb2duaXplIHdoZXRoZXIgZGF0YSBwYWNrZXQgaXMgaW4gUERBTyBpbnN0YW5jZS4g Rm9yd2FyZGVyIHNob3VsZCBzZW5kIElDTVAgRGVzdGluYXRpb24gVW5yZWFjaGFibGUgZXJyb3Ig dG8gcm9vdCAodGhlIHNvdXJjZSBvZiB0aGUgcGFja2V0KSwgdGhlbiByb290IGdlbmVyYXRlcyBJ Q01QdjYgZXJyb3IgbWVzc2FnZSB3aXRoICZxdW90O0Vycm9yDQogaW4gUHJvamVjdGVkIFJvdXRl 4oCdIHRvIG1haW4gUm9vdC4gJm5ic3A7SXMgaXQgY29ycmVjdD88bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VGhhdCB3b3VsZCB3b3JrLiBTZWVtcyBuZWF0LiBUaGUgYWx0ZXJuYXRlIHdvdWxkIGJl IHRvIHNpZ25hbCBpdCBpcyBhIFAgcm91dGUgaW4gdGhlIFJQSS4gVGhhdOKAmXMgaXRlbSAyKSBp biB0aGUgbGlzdCBpbiB0aGlzIHRocmVhZC4gSWYgd2UgZG8gdGhhdCB0aGUgY3VycmVudCB0ZXh0 IHdvcmtzLiBXaGF0IG1ha2VzIG1vcmUgc2Vuc2UgdG8geW91PzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mZ3Q7IEluIHN0b3JpbmcgUERBTywgZm9yd2FyZGVyIGNhbiByZWNvZ25pemUgdGhlIFBE QU8gaW5zdGFuY2UgZnJvbSB0aGUgUlBJLiBJdCBjYW4gc2VuZCAmcXVvdDtFcnJvciBpbiBQcm9q ZWN0ZWQgUm91dGXigJ0gb3IgJm5ic3A74oCcRGVzdGluYXRpb24gVW5yZWFjaGFibGUgZXJyb3Li gJ0gdG8gcm9vdC4gTWF5YmUgd2UgbmVlZCBtb3JlIGNsYWltcyBmb3Igd2hpY2ggY29kZSBmb3J3 YXJkZXIgc2hvdWxkIHVzZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2UgaGF2ZSB0byBkZWNp ZGUgaWYgd2Ugc2VuZCBpdCB0byB0aGUgbWFpbiByb290IGFzIHdyaXR0ZW4gaW4gdGhlIGN1cnJl bnQgZHJhZnQgb3IgdG8gdGhlIFRyYWNrIFJvb3QuIElmIHRoZSBQIHJvdXRlIGlzIHJldmVyc2li bGUgY291bGQgYmUgZG9uZSB0aGF0IHdheS4gQnV0IHRoYXTigJlzIGFkZGVkIGNvbXBsZXhpdHku IEnigJltIG5vdCB2ZXJ5IGNvbnZpbmNlZCBlaXRoZXIgd2F5LiBUaGUgT2toYW0gcmF6b3INCiBj b3VsZCBiZSB0byBkbyB0aGUgc2ltcGxlc3QuIDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5LZWVw IHNhZmUhPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBhc2NhbDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRl ci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2 Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0 O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJv bTo8L2I+IFJvbGwgJmx0O3JvbGwtYm91bmNlc0BpZXRmLm9yZyZndDsgPGI+T24gQmVoYWxmIE9m IDwvYj4NCkxpIFpoYW8gKGxpejMpPGJyPg0KPGI+U2VudDo8L2I+IHZlbmRyZWRpIDI3IG5vdmVt YnJlIDIwMjAgMDM6NTE8YnI+DQo8Yj5Ubzo8L2I+IFJvdXRpbmcgT3ZlciBMb3cgcG93ZXIgYW5k IExvc3N5IG5ldHdvcmtzICZsdDtyb2xsQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9i PiBSZTogW1JvbGxdIE1ha2UgUC1EQU8gYmlkaXJlY3Rpb25hbCBbZXh0ZW5kc10gSUVURiAxMDkg b3BlbiBRdWVzdGlvbnMgb24gUC1EQU88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkhlbGxvIFBhc2NhbCwgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IGxvb2tzIGdv b2QgZm9yIG1lLiBPbmx5IG9uZSBxdWVzdGlvbiBhYm91dCBJQ01QIGVycm9ycy4gPG86cD4NCjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+U2VjdGlvbiA3Ljkgb2YgcGRhby1kcmFmdCBkZWZpbmVzIGEgbmV3 IGNvZGUgZm9yICZuYnNwO0lDTVB2NiBlcnJvciBtZXNzYWdlICZxdW90O0Vycm9yIGluIFByb2pl Y3RlZCBSb3V0ZSZxdW90Oy4gRG9lcyBpdCBvbmx5IHdvcmsgZm9yIElDTVAgZXJyb3JzIHNlbnQg dG8gdGhlIG1haW4gUm9vdD8NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SW4gbm9uLXN0b3Jpbmc8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdCI+IFBEQU8sIGZvcndh cmRlciBjYW7igJl0IHJlY29nbml6ZSB3aGV0aGVyIGRhdGEgcGFja2V0IGlzIGluIFBEQU8gaW5z dGFuY2UuIEZvcndhcmRlciBzaG91bGQgc2VuZCBJQ01QIERlc3RpbmF0aW9uIFVucmVhY2hhYmxl IGVycm9yIHRvIHJvb3QgKDwvc3Bhbj50aGUgc291cmNlIG9mIHRoZSBwYWNrZXQpLCB0aGVuIHJv b3QgZ2VuZXJhdGVzDQogSUNNUHY2IGVycm9yIG1lc3NhZ2Ugd2l0aCAmcXVvdDtFcnJvciBpbiBQ cm9qZWN0ZWQgUm91dGXigJ0gdG8gbWFpbiBSb290LiAmbmJzcDtJcyBpdCBjb3JyZWN0PzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gc3RvcmluZzxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0Ij4gUERBTywgZm9yd2FyZGVyIGNhbiByZWNvZ25pemUgdGhlIFBEQU8g aW5zdGFuY2UgZnJvbSB0aGUgUlBJLiBJdCBjYW4gc2VuZCAmcXVvdDtFcnJvciBpbiBQcm9qZWN0 ZWQgUm91dGXigJ0gb3IgJm5ic3A74oCcRGVzdGluYXRpb24gVW5yZWFjaGFibGUgZXJyb3LigJ0g dG8gcm9vdC4gTWF5YmUgd2UgbmVlZCBtb3JlIGNsYWltcyBmb3Igd2hpY2ggY29kZSBmb3J3YXJk ZXINCiBzaG91bGQgdXNlLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXN0IHJlZ2FyZHMsPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5MaTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERG IDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Y29sb3I6YmxhY2siPlJvbGwgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86cm9s bC1ib3VuY2VzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+cm9sbC1i b3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtj b2xvcjpibGFjayI+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UaHVyc2RheSwgTm92ZW1iZXIgMjYs IDIwMjAgYXQgMTg6NDg8YnI+DQo8Yj5UbzogPC9iPlJvdXRpbmcgT3ZlciBMb3cgcG93ZXIgYW5k IExvc3N5IG5ldHdvcmtzICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOnJvbGxAaWV0Zi5vcmci PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5yb2xsQGlldGYub3JnPC9zcGFuPjwvYT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Jmd0Ozxicj4NCjxiPlN1 YmplY3Q6IDwvYj5SZTogW1JvbGxdIE1ha2UgUC1EQU8gYmlkaXJlY3Rpb25hbCBbZXh0ZW5kc10g SUVURiAxMDkgb3BlbiBRdWVzdGlvbnMgb24gUC1EQU88L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhlbGxvIExpPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkluIHRoZSBwYWNrZXQsIHRoZXJl4oCZcyBhIGJpdCBpbiB0aGUgUlBJIHRvIHNheSBpZiB0 aGUgcm9vdCBpcyB0aGUgc291cmNlIG9yIHRoZSBkZXN0aW5hdGlvbi4gVGhhdOKAmXMgUkZDIDY1 NTAuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgZ3Vlc3MgdGhlIGRp c2N1c3Npb24gaXMgcmVsYXRlZCB0byB0aGUgUERSIGFuZCBQLURBTywgbm90IGRhdGEgcGFja2V0 LCB0aG91Z2ggaXQgaW1wYWN0cyB0aGUgSUNNUCBlcnJvciByZXBvcnRpbmcuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkluIGEgcGFja2V0IGFsb25nIHRoZSBQLVJvdXRlLCB0aGUgaWRlYSB3YXMg c28gZmFyIHRoYXQgdGhlIERPREFHIGlzIGEgY29udmVyZ2VjYXN0IHRvIHRoZSBkZXN0aW5hdGlv biBzbyB0aGUgZGVzdGluYXRpb24gaXMgdGhlIHJvb3QuIElmIHdlIHNheSB0aGF0IHRoZXJl4oCZ cyBhIHNpbmdsZSBpbmdyZXNzIGFuZCBhIHNpbmdsZSBlZ3Jlc3MgdGhlbiB0aGUgZG9kYWcgaXMg cmV2ZXJzaWJsZSBhbmQgZWl0aGVyIGNhbg0KIGJlIHRoZSByb290LiBJZiB3ZSB3YW50IHRvIHN1 cHBvcnQgbXVsdGljYXN0IHRyYWNrcyBpbiB0aGUgZnV0dXJlLCB0aGVuIHRoZSBpbmdyZXNzIHNo b3VsZCBiZSByb290LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB0aGUgVHJhY2sgaGFzIGEg c2luZ2xlIGluZ3Jlc3MgYW5kIGEgc2luZ2xlIGVncmVzcywgdGhlbiB0aGUgRE9EQUcgaXMgcmV2 ZXJzaWJsZSBpbnRvIGFub3RoZXIgRE9EQUcgYW5kIGl0IGRvZXMgbm90IG1hdHRlciB3aGljaCBp cyByb290LCBzbyB3ZSBjYW4gbWFrZSBpdCBiaWRpciBhcyBIdWltaW4gYXNrZWQuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgc3RvcmluZyBtb2RlIFAgREFPIHdvdWxk IGxvb2sgYSBsb3QgbW9yZSBsaWtlIGEgREFPLCBhcyB5b3UgcG9pbnRlZCBvdXQsIGlmIGl0IGdv ZXMgdG93YXJkcyB0aGUgcm9vdC4gSWYgd2Ugd2FudCB0byB0YWtlIHRoYXQgcGF0aCwgYSBub2Rl IGNvdWxkIGxlYXJuIGJvdGggZGlyZWN0aW9ucyB3aXRoIGEgc2luZ2xlIHN0b3JpbmcgbW9kZSBQ IERBTy4gVG8gYmUgY29udGludWVk4oCmPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZvciBub24t c3RvcmluZywgbWFraW5nIGJpZGlyIGlzIHJlYWxseSBoYXJkLiBJdCBzZWVtcyBlYXNpZXIgdG8g aW5zdGFsbCBhIFRyYWNrIGluIGJvdGggZGlyZWN0aW9ucyBhbmQgY291cGxlIHRoZW0uPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkFzIGEgc3VtbWFyeSBvZiB0aGUgcHJvcG9zZWQgY2hhbmdlczo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+R2VuZXJhbDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+LSB3ZSBtYWtlIHRoZSByb290IHRoZSBpbmdyZXNzPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIElDTVAgZXJyb3JzIHNlbnQgdG8gdGhlIFJvb3QsIHVz aW5nIHRoZSBtYWluIERPREFHIGlmIHRoZSB0cmFjayBpcyBub3QgcmV2ZXJzaWJsZTxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPlN0b3JpbmcgbW9kZSBQIERBTzo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPi0gd2UgYWxzbyBtYWtlIHRoZSByb290IHRoZSBpbmdyZXNzLCBQLURBTyBmcm9tIGVncmVz cyB0byBpbmdyZXNzIGFyZSBub3cgbW9yZSBzaW1pbGFyIHRvIFJQTCBEQU8gb3BlcmF0aW9uDQo8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gdGhlIHRyYWNrIGNvdWxkIGJl IG1hZGUgYmktZGlyZWN0aW9uYWwsIGJ1dCB0aGF04oCZcyBtb3JlIGNvZGU7IGlmIHNvOjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IC0gdGhlIHBhY2tldCBmb3J3 YXJkaW5nIGxldmVyYWdlcyB0aGUgUlBJIHRvIGluZGljYXRlIHRoZSBkaXJlY3Rpb24sIGZyb20g b3IgdG8gcm9vdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IC0g SUNNUCBlcnJvcnMgc2VudCB0byB0aGUgUm9vdCwgY291bGQgYmUgc291cmNlIG9yIGRlc3RpbmF0 aW9uLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5vbiBzdG9yaW5nIG1vZGUgUCBEQU86PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIHRyYWNrcyByZW1haW4gZGlyZWN0 aW9uYWwsIGNhbiBiZSBjb3VwbGVkLCBob3cgaXMgdGJkPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4tIHRoZSBSUEkgaXMgbW9zdGx5IHVzZWxlc3Mgc2luY2UgdGhlIGludGVy bWVkaWF0ZSBub2RlcyBkbyBub3Qga25vdyB0aGUgaW5zdGFuY2UgKHRoZXkgc2VlIG5laXRoZXIg dGhlIERJTyBub3IgdGhlIFAtREFPKTsgdGhleSBoYXZlIG5vIGlkZWEgb2YgdGhlaXIgUmFuay4g U3RpbGwsIGl0IGlzIGludGVyZXN0aW5nIHRvIGhhdmUgaXMgZm9yIGVycm9yIGRldGVybWluYXRp b24gaW4gYW4gSUNQTVAgZXJyb3IgYXQNCiBldGggcm9vdC4gSXQgaXMgYWxzbyBpbnRlcmVzdGlu ZyBpZiB0aGUgU1JIIGZvcndhcmRpbmcgbm9kZXMgaGF2ZSBhIHN0YXRlIGFzc29jaWF0ZWQgdG8g dGhlIFRyYWNrLCBlLmcuLCByZXNlcnZlZCB0aW1lIHNsb3RzIG9yIHByaW9yaXR5IHF1ZXVlcy48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0gdGhlIFJQSSBpcyBzdGlsbCBh IFNIT1VMRCB3aGVuIHRoZXJl4oCZcyBubyBjb21wcmVzc2lvbiBhbmQgYSBNVVNUIHdoZW4gdGhl cmUgaXMuIFdlIG5lZWQgdG8gY2xhcmlmeSB3aGF0IHRvIGRvLCB0aGF04oCZcyBhbm90aGVyIG9m IEh1aW1pbuKAmXMgcXVlc3Rpb25zLCB0YWtlbiBzZXBhcmF0ZWx5LjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+LSBJQ01QIGVycm9ycyBmb3J3YXJkaW5nIHBhY2tldHMgYXJl IHNlbnQgdG8gdGhlIHJvb3Qgd2hpY2ggaXMgbm93IHRoZSBpbmdyZXNzLCBha2EgdGhlIHNvdXJj ZSBvZiB0aGUgcGFja2V0LCBhbmQgdGhlIGVuY2Fwc3VsYXRvciBmaWVsZCBpZiB0aGUgcGFja2V0 IGlzIGVuY2Fwc3VsYXRlZCBhbmQgY29tcHJlc3NlZC4gVGhpcyBpcyBjb21tb24gdG8gYW55IG5v bi1zdG9yaW5nIG9wZXJhdGlvbiwgd2hldGhlcg0KIGl0IGlzIGEgbWFpbiBJbnN0YW5jZSwgbG9j YWwgSW5zdGFuY2UsIG9yIFRyYWNrLiBUaGUgUlBJIHRoZXJlaW4gaXMgdXNlZnVsIHRvIGluZGlj YXRlIHRoZSBUcmFjayBpbiBFcnJvci4gU28gZm9yIHRoYXQgbWF0dGVyIHRoZSBmb3J3YXJkZXIg ZG9lcyBub3QgbmVlZCB0byBtYWtlIGEgZGlmZmVyZW5jZSBUcmFjayB2cy4gb3RoZXIgZm9ybSBv ZiBSUEwgbG9jYWwgaW5zdGFuY2UuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4tIHRoaXMgaW1wYWN0cyB0aGUgZGlzY3Vzc2lvbiBpbiBTUkggcmVsb2FkaW5nIHdlIGhhZCBh dCBJRVRGIDEwOSwgd2hlbiBhICZuYnNwO04tUyBtb2RlIGxvb3NlIHRyYWNrIGlzIGZvcndhcmRl ZCBhbG9uZyBhIHNlZ21lbnQgdGhhdCBpcyBhbHNvIE5TIG1vZGUuIFdl4oCZbGwgcHJvYmFibHkg bmVlZCB0byByZS1lbmNhcHN1bGF0ZSBub3cuJm5ic3A7IEluIGNhc2Ugb2YgcmUtZW5jYXBzdWxh dGlvbiwgdGhlIHJlLWVuY2Fwc3VsYXRvcg0KIGJlY29tZXMgc291cmNlIGFuZCByb290IG9mIHRo ZSBzZWdtZW50LCB3aGljaCBub3cgaGFzIHRvIGJlIGNvbnNpZGVyZWQgYXMgYSBzZXJpYWwgVHJh Y2s7IGFzIHR1bm5lbCBoZWFkZW5kcyBkbywgaXQgd2lsbCBoYXZlIHRvIGRlY2Fwc3VsYXRlIHRo ZSB0dW5uZWxlZCBwYWNrZXQgdG8gc2VuZCB0aGUgcGFja2V0IGluIGVycm9yIGJhY2sgdG8gdGhl IGluZ3Jlc3Mgb2YgdGhlIGxvb3NlIHRyYWNrPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RG9lIHRoYXQgd29yaz88bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+UGFzY2FsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8 ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEu MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ RnJvbTo8L2I+IFJvbGwgJmx0OzxhIGhyZWY9Im1haWx0bzpyb2xsLWJvdW5jZXNAaWV0Zi5vcmci PnJvbGwtYm91bmNlc0BpZXRmLm9yZzwvYT4mZ3Q7DQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkxpIFpo YW8gKGxpejMpPGJyPg0KPGI+U2VudDo8L2I+IGpldWRpIDI2IG5vdmVtYnJlIDIwMjAgMDM6NDU8 YnI+DQo8Yj5Ubzo8L2I+IFJvdXRpbmcgT3ZlciBMb3cgcG93ZXIgYW5kIExvc3N5IG5ldHdvcmtz ICZsdDs8YSBocmVmPSJtYWlsdG86cm9sbEBpZXRmLm9yZyI+cm9sbEBpZXRmLm9yZzwvYT4mZ3Q7 PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbUm9sbF0gTWFrZSBQLURBTyBiaWRpcmVjdGlvbmFs IFtleHRlbmRzXSBJRVRGIDEwOSBvcGVuIFF1ZXN0aW9ucyBvbiBQLURBTzxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGU8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dCI+bGxvIFBhc2NhbCw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklmIGVpdGhlciBz b3VyY2Ugb3IgZGVzdGluYXRpb24gY2FuIGJlIHJvb3QsIGl04oCZcyBiZXR0ZXIgdG8gaWRlbnRp Znkgd2hlbiBvciBpbiB3aGljaCBjYXNlIHNvdXJjZSBvciBkZXN0aW5hdGlvbiBjYW4gYmUgcm9v dC4gT3RoZXJ3aXNlLCBpdOKAmXMgaGFyZCB0byBpbnRlcm9wIGJldHdlZW4gZGlmZmVyZW50IGlt cGxlbWVudCBldmVuIHRob3VnaCB0aGV5IGJvdGggZm9sbG93IFJGQyBzdGFuZGFyZC48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+RS5nLiBmb3Igbm9uLXN0b3JpbmcgbW9kZSBQREFPLCBpZiBzb3Vy Y2UgaXMgcm9vdCwgUENFIG9ubHkgcmVzcG9uc2VzIFBEUi1BQ0sgYWZ0ZXIgcmVjZWl2aW5nIFBE UiBmcm9tIHNvdXJjZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJ1dCBp ZiBkZXN0aW5hdGlvbiBpcyByb290LCBQQ0Ugc2hvdWxkIGFsc28gbm90aWZ5IGRlc3RpbmF0aW9u IHdoaWNoIHRyYWNraWQgaXMgdXNlZC4gTWF5YmUgd2UgbmVlZCBicmluZyBuZXcgbWVzc2FnZSBm b3IgdGhpcyBub3RpZmljYXRpb24/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGFrZSBjYXJlLDxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TGk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPlJvbGwgJmx0Ozwvc3Bh bj48YSBocmVmPSJtYWlsdG86cm9sbC1ib3VuY2VzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdCI+cm9sbC1ib3VuY2VzQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtjb2xvcjpibGFjayI+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5X ZWRuZXNkYXksIE5vdmVtYmVyIDI1LCAyMDIwIGF0IDIxOjU0PGJyPg0KPGI+VG86IDwvYj5Sb3V0 aW5nIE92ZXIgTG93IHBvd2VyIGFuZCBMb3NzeSBuZXR3b3JrcyAmbHQ7PC9zcGFuPjxhIGhyZWY9 Im1haWx0bzpyb2xsQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+cm9s bEBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6 YmxhY2siPiZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtSb2xsXSBNYWtlIFAtREFPIGJp ZGlyZWN0aW9uYWwgW2V4dGVuZHNdIElFVEYgMTA5IG9wZW4gUXVlc3Rpb25zIG9uIFAtREFPPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZWxsbyBM aTs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2VsbCBub3RlZC4gVGhpcyB3YXMgdGhlIG9yaWdp bmFsIGludGVudC4gVGhlIGNoYW5nZSB3YXMgbWFkZSB0byBlZ3Jlc3MgYmVjYXVzZSB0aGUgaWRl YSB3YXMgdGhhdCB0aGUgdHJhY2sgY291bGQgZW5hYmxlIG11bHRpcGxlIHNvdXJjZXMgdG8gcmVh Y2ggdGhlIGVncmVzcywgbGlrZSBhIHRyZWUgcm9vdGVkIGF0IHRoZSBlZ3Jlc3MgdGhhdCBmbG93 cyB0cmF2ZXJzZSBnb2luZyBkb3duLiBCdXQgdGhlIGlkZWENCiBvZiBhIGJpZGlyZWN0aW9uYWwg dHJhY2sga2luZGEgYmxvY2tzIHRoYXQgaWRlYSBhbmQgdGhlIG90aGVyIGlzc3VlcyBsaWtlIHRo ZSBvbmUgeW91IHBvaW50IG91dCBzZWVtIHRvIGdldCB1cyBiYWNrIHRvIHRoZSBvcmlnaW5hbCB2 aWV3LiBJIHJlY2VudGx5IG1hZGUgdGhlIGNoYW5nZSBmcm9tIGluZ3Jlc3MgdG8gZWdyZXNzIGlu IHRoZSA2VGlTQ0ggYXJjaGl0ZWN0dXJlLCB3YWl0aW5nIGluIFJGQyBlZGl0b3IgcXVldWUuIEkg Y291bGQgcmV2ZXJzZQ0KIGJhY2ssIG9yIG1heWJlIHNheSDigJxlaXRoZXIgc291cmNlIG9yIGRl c3RpbmF0aW9u4oCdIHNvIGl0IGNhbiBiZSBlZ3Jlc3Mgb3IgZWdyZXNzIGFuZCB3ZSBhcmUgY292 ZXJlZCBmb3IgYmlkaXJlY3Rpb25hbC4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+V2hhdCBkbyB5b3UgdGhpbms/IDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T3Igc2hvdWxkIGEgcmV2ZXJzYWJsZSBUcmFjayBiZSByZWFsbHkgYSBwYWlyIG9mIHRy YWNrcz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+S2VlcCBzYWZlOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5QYXNjYWw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw OzxvOnA+PC9vOnA+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29s aWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAwY20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0 eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzoz LjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gUm9s bCAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJvbGwtYm91bmNlc0BpZXRmLm9yZyI+cm9sbC1ib3VuY2Vz QGlldGYub3JnPC9hPiZndDsNCjxiPk9uIEJlaGFsZiBPZiA8L2I+TGkgWmhhbyAobGl6Myk8YnI+ DQo8Yj5TZW50OjwvYj4gbWVyY3JlZGkgMjUgbm92ZW1icmUgMjAyMCAwNTo1Nzxicj4NCjxiPlRv OjwvYj4gUm91dGluZyBPdmVyIExvdyBwb3dlciBhbmQgTG9zc3kgbmV0d29ya3MgJmx0OzxhIGhy ZWY9Im1haWx0bzpyb2xsQGlldGYub3JnIj5yb2xsQGlldGYub3JnPC9hPiZndDs8YnI+DQo8Yj5T dWJqZWN0OjwvYj4gUmU6IFtSb2xsXSBNYWtlIFAtREFPIGJpZGlyZWN0aW9uYWwgW2V4dGVuZHNd IElFVEYgMTA5IG9wZW4gUXVlc3Rpb25zIG9uIFAtREFPPG86cD48L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj5IZWxsbyBQYXNjYWwsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklu Z3Jlc3MgYXMgUm9vdCBsb29rcyBiZXR0ZXIgYmVjYXVzZSA8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjEuICZuYnNwO0l0IGlzIGNvbnNpc3RlbnQgd2l0aCB0aGUgd2F5IFJQ TCB1c3VhbGx5IHdvcmtzLiBSUEwgTG9jYWwgaW5zdGFuY2UsIGFvZHYtcnBsLCBwMnAtcnBsIGFs bCB1c2UgaW5ncmVzcyBhcyByb290LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Mi4gJm5ic3A7Rm9yIG5vbi1zdG9yaW5nLW1vZGUgUC1EQU8sIGN1cnJlbnRseSBpbmdyZXNz IHNlbmRzIHVwd2FyZCB0cmFmZmljIHRvIGVncmVzcyhyb290KSB3aXRoIFNSIGhlYWRlci4gQnV0 IGluIFJQTCwgb25seSBkb3dud2FyZCB0cmFmZmljIGNhcnJpZXMgU1IgaGVhZGVyLg0KPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2si PjMuICZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtjb2xvcjpibGFj ayI+T25seSBpPC9zcGFuPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+bmdyZXNzIGNhbiBzZW5k IFBEUiBtYWtlcyBzZW5zZS4gQmVoYXZpb3Igb2YgVHJhY2tJZCBpcyBzaW1pbGFyIGFzIExvY2Fs IEluc3RhbmNlIElELiBJbmdyZXNzIGFzIHJvb3QgY2FuIHByb3Bvc2UgVHJhY2tJZA0KIGZyb20g aXRzIG5hbWVzcGFjZS48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5kIGZvciBzdG9yaW5nLW1vZGUgUC1E QU8sIGlmIHdlIG1ha2UgaW5ncmVzcyBhcyByb290IGFuZCBpbmdyZXNzIHNlbmRzIFBEUiwgY2Fu IFBDRSBzZW5kIFAtREFPIHRvIGVncmVzcyB0aGVuIGVncmVzcyBmb3J3YXJkcyBpdCB0b3dhcmRz IHByZWRlY2Vzc29yIHRvIGluZ3Jlc3M/DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk1heWJlIGl0IGhlbHBzIHRvIG1ha2UgUC1EQU8gbG9va3MgbGlrZSBhIERBTyBtZXNz YWdlLiA8bzpwPg0KPC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkxpPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Y29sb3I6YmxhY2siPlJvbGwgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86cm9sbC1i b3VuY2VzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+cm9sbC1ib3Vu Y2VzQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xv cjpibGFjayI+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UdWVzZGF5LCBOb3ZlbWJlciAyNCwgMjAy MCBhdCAyMTozOTxicj4NCjxiPlRvOiA8L2I+Um91dGluZyBPdmVyIExvdyBwb3dlciBhbmQgTG9z c3kgbmV0d29ya3MgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86cm9sbEBpZXRmLm9yZyI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPnJvbGxAaWV0Zi5vcmc8L3NwYW4+PC9hPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4mZ3Q7PGJyPg0KPGI+U3ViamVj dDogPC9iPltSb2xsXSBNYWtlIFAtREFPIGJpZGlyZWN0aW9uYWwgW2V4dGVuZHNdIElFVEYgMTA5 IG9wZW4gUXVlc3Rpb25zIG9uIFAtREFPPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5EZWFyIGFsbDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XaGV0 aGVyIHRvIG1ha2UgdGhlIFAtREFPIGJpZGlyZWN0aW9uYWwgaXMgYW4gaW50cmlndWluZyBxdWVz dGlvbi4gSXQgY291bGQgYmUgZG9uZSwganVzdCBsaWtlIHdlIGNhbiBzZW5kIHBhY2tldHMgRE9X TiBhIGNsYXNzaWNhbCBET0RBRy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PkJ1dCBpZiB3ZSB0YWtlIHRoYXQgcGF0aCwgd2UgcmVvcGVuIHRoZSBxdWVzdGlvbiBvZiB3aG8g aXMgcm9vdCBhbmQgd2hpY2ggZGlyZWN0aW9uIHRoZSBQLURBTyBmbGllcy4NCjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5Db3VsZCB3ZSBtYWtlIGVpdGhlciB0aGUgaW5ncmVzcyBPUiB0aGUgZWdy ZXNzIHJvb3Q/IEhvdyBkb2VzIGl0IG1hdHRlcj88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXQg dGhlIG1vbWVudCB0aGUgUm9vdCBpcyB0aGUgZWdyZXNzIGFuZCB0aGUgc3RvcmluZy1tb2RlIFAt REFPIGZsaWVzIGZyb20gdGhlIFRyYWNrIGVncmVzcyB0byB0aGUgdHJhY2sgaW5ncmVzcywgYW5k IHRoZSB0cmFjayBlZ3Jlc3MgaXMgdGhlIHJvb3QuIFRoaXMgaXMgbm90IHRoZSB3YXkgUlBMIHVz dWFsbHkgd29ya3MgYXMgdGhlIERBTyBmbGllcyB0b3dhcmRzIHRoZSByb290LiBUaGUgcmVhc29u IHdhcw0KIHRoYXQgd2Ugd2FudGVkIGEgc2luZ2xlIGVncmVzcyBmb3IgdGhlIFRyYWNrLCBhcyB3 ZSBidWlsZCB1bmljYXN0IFRyYWNrLiBJZiB3ZSB3YW50ZWQgdG8gYnVpbGQgbXVsdGljYXN0IFRy YWNrcyB0aGUgcm9vdCBzaG91bGQgbG9naWNhbGx5IGJlIHRoZSBpbmdyZXNzLiBBbmQgZm9yIGJp ZGlyZWN0aW9uYWwgVHJhY2tzIGl0IGNvdWxkIGJlIGVpdGhlci48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+VXAgdG8gLTI0IHRoZSA2VGlTQ0ggQXJjaGl0ZWN0dXJlIGV4cGVjdGVkIHRoZSBpbmdy ZXNzIHRvIGJlIHJvb3QuIEkgY2hhbmdlZCBpbiB0aGUgbGF0ZXN0IHRvIG1hcCB3ZSBkbyBoZXJl LCB0aGF0IGl0IGlzIHRoZSBlZ3Jlc3M7IG1heWJlIGEgZmxhZyBpbiB0aGUgREFPIHdvdWxkIGlu ZGljYXRlIHdoaWNoIGRpcmVjdGlvbiB0aGUgZmxvdywgZnJvbSByb290LCB0byByb290LCBvciBi b3RoPzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbHNvIGlmIHdlIGJ1aWxkIGJpZGlyIFRyYWNr cyBpbiBzdG9yaW5nIG1vZGUsIHRoZSBub2RlcyB0aGF0IGZvcndhcmQgdGhlIERBTyB3aWxsIGhh dmUgdG8gYnVpbGQgcm91dGVzIGluIGJvdGggZGlyZWN0aW9ucyBiYXNlZCBvbiB0aGUgUC1EQU8s IGJvdGggdG93YXJkcyBlZ3Jlc3MgYW5kIGluZ3Jlc3M7IGJ1dCBvbmx5IHRoZSBwYXRoIGZyb20g d2hpY2ggdGhlIFAtREFPIGNvbWVzIGhhcyBiZWVuIHZhbGlkYXRlZA0KIGJ5IHRoZSBQLURBTyBp dHNlbGYuIFNob3VsZCB3ZSBzZW5kIGEgUC1EQU8gdG8gZWFjaCBlbmQsIGVhY2ggc2V0dGluZyB1 cCBvbmUgd2F5PzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QbGVhc2UgbGV0IG1lIGtub3cgeW91 ciB0aG91Z2h0czxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QYXNjYWw8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTti b3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAx LjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PkZyb206PC9iPiBSb2xsICZsdDs8YSBocmVmPSJtYWlsdG86cm9sbC1ib3VuY2VzQGlldGYub3Jn Ij5yb2xsLWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmd0Ow0KPGI+T24gQmVoYWxmIE9mIDwvYj5QYXNj YWwgVGh1YmVydCAocHRodWJlcnQpPGJyPg0KPGI+U2VudDo8L2I+IG1hcmRpIDI0IG5vdmVtYnJl IDIwMjAgMTQ6MjI8YnI+DQo8Yj5Ubzo8L2I+IFJvdXRpbmcgT3ZlciBMb3cgcG93ZXIgYW5kIExv c3N5IG5ldHdvcmtzICZsdDs8YSBocmVmPSJtYWlsdG86cm9sbEBpZXRmLm9yZyI+cm9sbEBpZXRm Lm9yZzwvYT4mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFtSb2xsXSBJRVRGIDEwOSBvcGVuIFF1 ZXN0aW9ucyBvbiBQLURBTzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ RGVhcjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij4gYWxsPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5UaGUgc2xpZGVzIGZvciB0aGUgUC1EQU8gZGlzY3Vzc2lvbiBhdCBJRVRG IDEwOSBhcmUgYXZhaWxhYmxlIGhlcmU6PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxhIGhyZWY9 Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL3NsaWRlcy0xMDktcm9sbC1kYW8tcHJv amVjdGlvbi8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL3NsaWRlcy0xMDktcm9s bC1kYW8tcHJvamVjdGlvbi88L2E+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXJlIGFyZSBh IG51bWJlciBvZiBvcGVuIHF1ZXN0aW9ucyB0aGF0IHdlIHN0YXJ0aW5nIGRpc2N1c3NpbmcsIGFu ZCB3b3VsZCBuZWVkIHRvIHByb2dyZXNzIG9uIHRoZSBsaXN0Lg0KPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5Tb21lIG9mIHRoZW0gd2VyZSBleHByZXNzZWQgb24gdGhlIGxp c3QsIGUuZy4sIGZyb20gSHVpbWluIFNoZS4gSeKAmWQgbGlrZSB0byBwcm9ncmVzcyBvbiB0aGVt IGFsbCB3aXRoIGluZGl2aWR1YWwgdGhyZWFkcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPlRoZSBxdWVzdGlvbnMgYXJlOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8b2wgc3R5bGU9Im1hcmdpbi10b3A6MGNt IiBzdGFydD0iMSIgdHlwZT0iMSI+DQo8bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxl PSJtYXJnaW4tbGVmdDowY207bXNvLWxpc3Q6bDAgbGV2ZWwxIGxmbzMiPkxpZmV0aW1lIFVuaXQ6 IGNvdWxkIHdlIHVzZSBhIGRpZmZlcmVudCB1bml0IGZvciBQLURBTz88bzpwPjwvbzpwPjwvbGk+ PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGNtO21zby1s aXN0OmwwIGxldmVsMSBsZm8zIj5Ib3cgdG8gZGlmZmVyZW50aWF0ZSBhIFAtREFPIGZyb20gYSBu b3JtYWwgREFPIGluIGEgbG9jYWwgaW5zdGFuY2U7IG5ldyBmbGFnPzxvOnA+PC9vOnA+PC9saT48 bGkgY2xhc3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowY207bXNvLWxp c3Q6bDAgbGV2ZWwxIGxmbzMiPk1ha2UgUC1EQU8gYmlkaXJlY3Rpb25hbD88bzpwPjwvbzpwPjwv bGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2luLWxlZnQ6MGNtO21z by1saXN0OmwwIGxldmVsMSBsZm8zIj5XaG8gc2VuZHMgdGhlIFBEUj8gRG9lcyBpdCBoYXZlIHRv IGJlIHRoZSBpbmdyZXNzPyBJZiBpdCB3YXMgZWdyZXNzIGl0IGNvdWxkIHByb3Bvc2UgYSBUcmFj a0lkIGZyb20gaXRzIG5hbWVzcGFjZS4gRWxzZSBjb3VsZCB0aGUgaW5ncmVzcyBiZSB0aGUgcm9v dD88bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFy Z2luLWxlZnQ6MGNtO21zby1saXN0OmwwIGxldmVsMSBsZm8zIj5NYWludGFpbmluZyB0aGUgc2li bGluZyBzdGF0ZS4gU2hvdWxkIHdlIGhhdmUgdGV4dCBvbiB1c2luZyBSRkMgODUwNSB0aGVyZT88 bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0ibWFyZ2lu LWxlZnQ6MGNtO21zby1saXN0OmwwIGxldmVsMSBsZm8zIj5XaGV0aGVyIGluZ3Jlc3MgYW5kIGVn cmVzcyBhcmUgbGlzdGVkIGluIE5QTz8gVG9kYXkgdGhleSBhcmUgYm90aCwgaW5ncmVzcyB0byBp bmRpY2F0ZSB0aGUgcGFja2V0IHNvdXJjZSBpbiBjYXNlIG9mIGVuY2Fwc3VsYXRpb24gYW5kIGZv ciBTUkgtNkxvUkggY29tcHJlc3Npb24gcmVmZXJlbmNlIGFuZCBlZ3Jlc3MNCiB0byBidWlsZCB0 aGUgZnVsbCBTUkgtNkxvUkguIE5vdGUgdGhhdCB0aGUgaW5ncmVzcyBtdXN0IGNvbnN1bWUgdGhl IGZpcnN0IGVudHJ5IGFuZCB1c2UgaXQgYXMgc291cmNlLjxvOnA+PC9vOnA+PC9saT48bGkgY2xh c3M9Ik1zb0xpc3RQYXJhZ3JhcGgiIHN0eWxlPSJtYXJnaW4tbGVmdDowY207bXNvLWxpc3Q6bDAg bGV2ZWwxIGxmbzMiPlRyYWNrIGluIFRyYWNrIHZzLiBTUiBIZWFkZXIgcmVsb2FkIG1vZGVscywg c2VlIHNsaWRlczxvOnA+PC9vOnA+PC9saT48L29sPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5MZXQgbWUgb3BlbiB0aHJl YWRzIHRvIGZvbGxvdyB1cC48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+S2VlcCBzYWZlPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPlBhc2NhbDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8 c3Bhbj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwvc3Bh bj48YnI+DQo8c3Bhbj5Sb2xsIG1haWxpbmcgbGlzdDwvc3Bhbj48YnI+DQo8c3Bhbj5Sb2xsQGll dGYub3JnPC9zcGFuPjxicj4NCjxzcGFuPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vcm9sbDwvc3Bhbj48YnI+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_AC612802904C4FA781EDE661E1E50212ciscocom_-- From nobody Fri Nov 27 03:52:02 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED16E3A09B5 for ; Fri, 27 Nov 2020 03:51:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -11.9 X-Spam-Level: X-Spam-Status: No, score=-11.9 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_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=dpVjKpb4; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=jZwgGHXr 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 Hz5JYhHD_u9R for ; Fri, 27 Nov 2020 03:51:56 -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 B02423A09AD for ; Fri, 27 Nov 2020 03:51:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=98428; q=dns/txt; s=iport; t=1606477915; x=1607687515; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=2wyssjDNkSrYGmfKiYTQKSvGLXNYmLsQOdhxpnyPCEo=; b=dpVjKpb4hsFK9s93ts89gb7IRgEJv2BduzBsgMztSJS/Lyl3BT01ekbz Cttx6egca6q8NU/XzUaSuAOEFK0a+mfKlrbfNlzJYAlEwMI0tp3cvgIZI zKc4pV0SzNN08FSkLLeD5dMb4inhvxI2PjkRGx0VO7ATWrJxulT5d4puf Q=; X-IPAS-Result: =?us-ascii?q?A0DrCAA258BffYUNJK1YCoEJgnIBLikofFovLogGA41dg?= =?us-ascii?q?QWPeogHgUKBEQNUCwEBAQ0BASMKAgQBAYRKAoIpAiU4EwIDAQEBAwIDAQEBA?= =?us-ascii?q?QUBAQECAQYEFAEBhg8IJQyFcgEBAQQSCAEMBhMBASUTDwIBCBEBAgEBASEBB?= =?us-ascii?q?gcyFAMGCAEBBBMIGoMFgX5XAy4BDqUMAoE8iGl0gQEzgwQBAQWBNwQMQYMlG?= =?us-ascii?q?IIQAwaBOIJzgmZOhxkbgUE/gRABQ4FXSQcuPoEEgVkCAwGBIQ0PIB4GBwmDF?= =?us-ascii?q?IIskC8kMoobKIt4kS4Kgm+JF4lfiFiCYjuKHZRanmuRLIQ8AgQCBAUCDgEBB?= =?us-ascii?q?YFtIYFZcBU7gmlQFwINh36GLxeBAgEHgkSFFIVEdDcCBgoBAQMJfIwaLYIXA?= =?us-ascii?q?QE?= IronPort-PHdr: =?us-ascii?q?9a23=3A0H8Z5hJ6wn6DUVXjZ9mcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeGvK8/jVLVU8Pc8f0Xw+bVsqW1X2sG7N7BtX0Za5VDWl?= =?us-ascii?q?cDjtlehA0vBsOJSCiZZP7nZiA3BoJOAVli+XzoMEVJFoD5fVKB6nG35CQZTx?= =?us-ascii?q?P4Mwc9L+/pG4nU2sKw0e36+5DabwhSwjSnZrYnJxStpgKXvc4T0oY=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,374,1599523200"; d="scan'208,217";a="601800913" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Nov 2020 11:51:54 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id 0ARBprtf025965 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 27 Nov 2020 11:51:54 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 27 Nov 2020 05:51:53 -0600 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 27 Nov 2020 05:51:52 -0600 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 27 Nov 2020 05:51:52 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Tb48KW4AfLT3HcAyFkEe6GeODakhHjc0W9lkZKWojcFMwUwxKygLmqsoJTggvXRhBnIH7UdJXhWLHq5mRddIXdqicyQrJj2Oy7hUiO8p0cTakku74CfZnOGlJmtO5PGdiDGUneG3MJLEH7UCFBeMhM1mkrAzwLurejY/UDvH8sYNu/4u2RiowntZP19pVr3v3k2/DADA7bw+j/OrPzNvIRj4IB66HqB3aEu9jHmZcEj+AJTLFndI91rX0kXlBEgCR4mb/mYaCRDnUQxsJpfjsuZc/zp0TN80DCVyRl0Id23cjaEXnTW9yVpMyOe5G8uNaJ8f0iuTN21/pNnEJPd+OQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZU6YbGp4klb0mgnL17bpEpwz8NjmHH/1Iii3LozZY5E=; b=KavOaCoU2NZafzAMy+eyYGidaFjLYUfQ8110nuiWRznAcgYzrywNIQmAQrIZFmQV20AU5eDc+M1rc5Ca0Yy/q00itMmkUYeDxvan441KTVtGhJlaeLDT0RDNmsRLMdNAEhzezf7Y3jR8NdQGNYyf6NJEIT3lG0Y/UDSlTKvj/DnXXlj5LH+y2quC+HXwxzsIOs68Yer5hk4HyEiuJNGQz6JpS7ABvl4nFGxijjzz9SyEIA175yR1aZuWac7kqVXMwmoUy5JtEO15/f+n5GRibPc0Hs2RQqbmWe03OxJ9/EhqUM5U/j+YEw1LLzaGfI+3Qb3uomiYgZ4yheEFH4VsxA== 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=ZU6YbGp4klb0mgnL17bpEpwz8NjmHH/1Iii3LozZY5E=; b=jZwgGHXrOkaz8W9nm+tGzAHIW3hxtPUJfpP7hKEaN6wP3CRuNyfHsPP/XhuS83ACRsztRNQ4jY37ey0EGsKPmIRC/8iVSdY9lKrDWh9RGptX5pmIl4qS/jPAqRiGYN52M7uxWv++K6/sxW2hpzHHUWeDdJHHZzCsvsTJkzuvYGs= Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by MWHPR11MB1709.namprd11.prod.outlook.com (2603:10b6:300:25::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.20; Fri, 27 Nov 2020 11:51:51 +0000 Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::fc25:3e72:3e83:7df6]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::fc25:3e72:3e83:7df6%4]) with mapi id 15.20.3564.025; Fri, 27 Nov 2020 11:51:51 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: Make P-DAO bidirectional [extends] IETF 109 open Questions on P-DAO Thread-Index: AdbCZRGxaZJsqD20SLuISSoVqF9MEgAgkqIOABJ37jAAGm3GHQALqPgAADNsT9A= Date: Fri, 27 Nov 2020 11:51:25 +0000 Deferred-Delivery: Fri, 27 Nov 2020 11:50:13 +0000 Message-ID: References: , In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2a01:cb1d:4ec:2200:4537:3354:1495:3c15] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e39ff4c0-554e-41e6-d004-08d892cad40b x-ms-traffictypediagnostic: MWHPR11MB1709: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: yIoWQIBvMuUo0PjteehLNdasEGO7AfHL8jG/KP643NrwxdJU0atRUpuoWbfUX0d6jREt6sioNfnSwZSITxfke14dPufl4QOsnBhPunP7SRqFuaMHMkzgP6735KRH76NM3KEW8NpS9q4r26nCWT4EbE5iSemVHSEjXBwMeTKnWBUVhdWuXo+F13j7AkNRcOq77GeAAdJnpCbzAtkN+2+bGucVTbkDyPjes5lU6dsAppFOX6Shy3PutSnFS7PzudUAw2M11fP/wL8PLtsYE+pgyHCWsxcSC2A7l2BpoeDwAJ0miS9NsazRgxafDYcXNcd6bf4j4lcQ7ZjiHh9sKAp0r2XKcSJkxfAW2X70RInuzv9GmvwfgXAKpkQtLtf97eyC1ahBGH8ebO1Jy5kN9FkVnQ== 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:(136003)(366004)(376002)(39860400002)(396003)(346002)(52536014)(53546011)(6506007)(7696005)(5660300002)(8936002)(8676002)(2906002)(33656002)(64756008)(186003)(55016002)(66946007)(316002)(6666004)(71200400001)(66556008)(76116006)(66446008)(66476007)(9686003)(166002)(478600001)(30864003)(66574015)(966005)(86362001)(83380400001)(6916009)(559001)(579004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?7xonj53pt79WiamUGsQi4WGIxcLcEtmG3ERuQOAKSwQ043IRd9MyAFqlMNM/?= =?us-ascii?Q?vmszOSAVUTY9UVOef2muRDqNgK0lMP3cgYC5PVVr6c5GSMdt7on1KQzx4TyC?= =?us-ascii?Q?3/17PSK+0/irwZozq4zxXZZ3aLNRIX+5WuFEX3w9hmFFsgtZJF+dMhO364bA?= =?us-ascii?Q?vurymZzOVI1MmaAos1gG0sIqtzWVfrTvdEgQ0/fVI6PRJLo4UdmXKjJFR42i?= =?us-ascii?Q?3wffFIn9S3cx22nZzRWurRMAM7AsDm5g/nKgrsTMhDewnoYaRLs0gzBWGFrP?= =?us-ascii?Q?CX4Gyb9g70+EYY6EldunBboYZy5PsY5SYJNNXPK31E/49LUXEwjyF1pcAMUD?= =?us-ascii?Q?f6s5Jy+MmJA3qDv2lpg1v+6QyFCR5R3/vNnUCbyznPE/10OYAptJRsCrCTCC?= =?us-ascii?Q?gdgumd3yzNQlyXJLrgxVnIJ9P+h6KRS6iwHf9xhoeEzf5+rbvdpxhiUWrdhR?= =?us-ascii?Q?gsenals1iGu7fLV9jiKWK6kMzE8lcqs/MMV8+wSJVKOnkIDqzSzXWaEifGHy?= =?us-ascii?Q?96CskUzCHbsqstf5zn1UMn9GZ3M56BeZ61Np2ZBx4zgUwAjgISmM8mTdoSNO?= =?us-ascii?Q?zX8AlObLtp+G4U5d7GBli1fVTBfwvWI8i73xlj/SQfzgXZrUgqmTP0jBQBAe?= =?us-ascii?Q?B1hkjzoWm02ZYh1ubiHP12Ka0mn0zAhUSu+xh/rmWBScOfcMsv1A9FgNNBPR?= =?us-ascii?Q?F9M/K47+MbsI2O25XeevlTi59MFChJi/I2Q7DNAJOi5mkJHw+rHI77QEqWWC?= =?us-ascii?Q?6Oh3cOJp9LJ+JWwNhtPBuPXztyEruFaeIFlSwajhv+146kHaHQZBxKS6l5HZ?= =?us-ascii?Q?WVNH8TRxrfGN6GY4Sx06YLtgjXjZVY17Jl1hcGEb2vSxuWZf8HVXWg40L3aQ?= =?us-ascii?Q?RZqsNT2blCTIwyzE//TIYXiupLlefS70eH+S3aPACzysiLkBYUj+7JptDQlZ?= =?us-ascii?Q?pbG2Tu53vpfMRtUdOSwo7e00ngDElgtngbDmMQGffpV5znKFCyNCp5b3IoT7?= =?us-ascii?Q?/ixJ5v5yyceKhVlZcuZ6uIN+kO9+jQ0HUeBg3qWfqGs9bR5nUpfkAmSVD217?= =?us-ascii?Q?5+uQoU1Z?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_CO1PR11MB48819304E7BE2BD815A8DB42D8F80CO1PR11MB4881namp_" 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: e39ff4c0-554e-41e6-d004-08d892cad40b X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Nov 2020 11:51:51.0243 (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: +qEDGuZc3MIzGbj/GmL/A7NvznJKY2Nb9ACTiFD0RPiZcMD5r13EFVUiUj70tJYcZNiLUpQT+SFrEzMW6Egb7Q== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1709 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: alln-core-11.cisco.com Archived-At: Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questions on P-DAO 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, 27 Nov 2020 11:52:00 -0000 --_000_CO1PR11MB48819304E7BE2BD815A8DB42D8F80CO1PR11MB4881namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all On this thread we decided to change the Root from being the Track egress to= being the ingress. That is cool for many reasons, but as i said that kills= the possibility to "reload" the routing header in a multi-segment Track wh= ere the segments are expressed as non-storing P-DAOs. Why? The operation I presented at IETF 109 involves changing the packet source a= t the segment stitching point and still recognize the packet as being part = of a Track. The change above makes the packet source is the Root of the Tra= ck, so the packet source now identifies the Track (together with the RPI). = Non-storing P-DAOs require to add a routing header. If header insertion was= allowed then that would not be an issue. But to add a RH cleanly at the segments stitching point, the connecting rou= ter needs to decapsulate the previous segment and encapsulate the next segm= ent with the RH. The connecting router becomes the source, thus the root. M= eaning that the segment is in fact a Track in its own right as opposed to a= segment of the complex Track. Another way to say that there is no segment in non-storing mode anymore. Th= ere are only Tracks that can be further assembled into more complex graphs.= That is, unless as I said we allow RH insertion despite the disputes we ob= serve on the same subject at 6MAN about Segment Routing. Or the TrackID is = taken from the Global Instance IDs name space. At the moment I'm ignoring t= hose options which lead to either political issues or technical limitations= . A complex Track can still be expressed as a collection of loose source rout= ing paths from a same Ingress =3D=3D Root. Think of it as a Segment Routing Policy for those familiar with SR. The dif= ference is that in SR the loose hops are ECMP path served by the IGP. Here we'll need either non-storing Tracks or storing mode segments, the dif= ference being that the storing mode segments do not required re-encapsulati= on. Note that in either case, there can be multiple NECMP possibilities. An example maybe? Say we have ------ F A------B------C------D------E < ------ G A is Track ingress, E is track Egress. C is stitching point. F and G are E'= s neighbors, "external" to the Track, and reachable from A over the Track A= ->E. In a general manner we want: * PDAO 1 signals A->B->C * PDAO 2 signals C->B->E * PDAO 3 signals F and G via the A->E Track PDAO 3 being loose, it can only be non-storing. Note that since the Root is= always the ingress of a Track, and all SR-VIOs are now Track, the Root bei= ng signaled in the DAO base object can now be elided in the VIA list in SR-= VIO. This enables the construction by the main root of the RFC 8138 optimiz= ed SRH-6LoRH in the SR-VIO, to be placed as is in the packet by the Root. 1) Storing mode Segments -------------------------------- A->B->C and C->D->E are segments of a same Track. Note that the storing mode signaling imposes strict continuity in a segment= . This may also avoid weird loops. Case 1.1) Stitched Segments 1. storing mode PDAO 1 is sent to E. It has Root =3D A, VIO =3D C, D, E,= Track ID 129 from A's namespace, Target =3D E, F, G 2. storing mode PDAO 2 is then sent to C. It has Root =3D A, VIO =3D A, = B, C, Track ID 129 from A's namespace, Target =3D E, F, G E recognizes that it is egress because it is a Target and a segment endpoin= t. Packets along the Track have source=3D A, destination =3D E | F | G, and RP= I =3D 129. >From PDAO 2: A forwards to B and B forwards to C. >From PDAO 1: C forwards to D and D forwards to E. Case 1.2) External routes 1. storing mode PDAO 1 is sent to E. It has Root =3D A, VIO =3D C, D, E,= Track ID 129 from A's namespace, Target =3D E 2. storing mode PDAO 2 is then sent to C. It has Root =3D A, VIO =3D A, = B, C, Track ID 129 from A's namespace, Target =3D E 3. non storing mode PDAO 3 is then sent to A. It has Root =3D A, SRVIO = =3D E, Track ID 129 from A's namespace, Target =3D F, G >From PDAO 3: A encapsulates packets with dest =3D F | G as below; Packets along the Track have source=3D A, destination =3D E, and RPI =3D 12= 9. >From PDAO 2: A forwards to B and B forwards to C. >From PDAO 1: C forwards to D and D forwards to E. E decapsulates if encapsulated packet. Case 1.3) Segment Routing 1. storing mode PDAO 1 is sent to E. It has Root =3D A, VIO =3D C, D, E,= Track ID 129 from A's namespace, Target =3D E 2. storing mode PDAO 2 is then sent to B. It has Root =3D A, VIO =3D A, = B, Track ID 129 from A's namespace, Target =3D B, C 3. non storing mode PDAO 3 is then sent to A. It has Root =3D A, SRVIO = =3D C, E, Track ID 129 from A's namespace, Target =3D F, G >From PDAO 3: A encapsulates packets with dest =3D F | G as below; Packets from A have source=3D A, destination =3D C, SRH =3D E, and RPI =3D = 129. >From PDAO 2: A forwards to B. B forwards to C based on a sibling connected route; C consumes the RH and m= akes the destination E. >From PDAO 1: C forwards to D and D forwards to E. E decapsulates if encapsulated packet. 2) Non Storing mode joining Tracks --------------------------------------------- A->B->C and C->D->E are Tracks expressed as non-storing P-DAOs. Case 2.1 Stitched Tracks 1. non storing mode PDAO 1 is sent to C. It has Root =3D C, VIO =3D D, E= , Track ID 131 from C's namespace, Target =3D E, F, G 2. non storing mode PDAO 2 is then sent to A. It has Root =3D A, VIO =3D= B, C, Track ID 129 from A's namespace, Target =3D E, F, G >From PDAO 2: A encapsulates packets with dest =3D E | F | G. The outer hea= der has source =3D A, destination =3D B, SRH =3D C and RPI =3D 129. Packets forwarded by B have source=3D A, destination =3D C , SRH =3D, and R= PI =3D 129. C decapsulates. >From PDAO 1: C encapsulates packets with dest =3D E | F | G. The outer he= ader has source=3D C, destination =3D D, SRH =3D E and RPI =3D 131. E decapsulates. Case 2.2 External routes 1. non storing mode PDAO 1 is sent to C. It has Root =3D C, VIO =3D D, E= , Track ID 131 from C's namespace, Target =3D E 2. non storing mode PDAO 2 is then sent to A. It has Root =3D A, VIO =3D= B, C, Track ID 129 from A's namespace, Target =3D E 3. non storing mode PDAO 3 is then sent to A. It has Root =3D A, SRVIO = =3D E, Track ID 141 from A's namespace, Target =3D F, G >From PDAO 3: A encapsulates packets with dest =3D F | G. The outer header= has source =3D A, destination =3D E, and RPI =3D 141. This may recurse with: >From PDAO 2: A encapsulates packets with dest =3D E. The outer header has = source =3D A, destination =3D B, SRH =3D C and RPI =3D 129. Packets forwarded by B have source=3D A, destination =3D C , SRH =3D, and R= PI =3D 129. C decapsulates. >From PDAO 1: C encapsulates packets with dest =3D E. The outer header has= source=3D C, destination =3D D, SRH =3D E and RPI =3D 131. E decapsulates if encapsulated. Case 2.3 Segment Routing 1. non storing mode PDAO 1 is sent to C. It has Root =3D C, VIO =3D D, E= , Track ID 131 from C's namespace, Target =3D E 2. non storing mode PDAO 2 is then sent to A. It has Root =3D A, VIO =3D= B, Track ID 129 from A's namespace, Target =3D C, E 3. non storing mode PDAO 3 is then sent to A. It has Root =3D A, SRVIO = =3D C, E, Track ID 141 from A's namespace, Target =3D F, G >From PDAO 3: A encapsulates packets with dest =3D F | G. The outer header= has source =3D A, destination =3D C, SRH =3D E, and RPI =3D 141. This may recurse with: >From PDAO 2: A encapsulates packets with dest =3D C | E . The outer header= has source =3D A, destination =3D B, and RPI =3D 129. B decapsulates forwards to C based on a sibling connected route; C consumes= the RH and makes the destination E. >From PDAO 1: C encapsulates packets with dest =3D E. The outer header has= source=3D C, destination =3D D, SRH =3D E and RPI =3D 131. E decapsulates, twice for dest =3D F | G. Does that work so far? Keep safe Pascal From: Roll On Behalf Of Pascal Thubert (pthubert) Sent: jeudi 26 novembre 2020 11:47 To: Routing Over Low power and Lossy networks Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questi= ons on P-DAO Hello Li In the packet, there's a bit in the RPI to say if the root is the source or= the destination. That's RFC 6550. I guess the discussion is related to the PDR and P-DAO, not data packet, th= ough it impacts the ICMP error reporting. In a packet along the P-Route, the idea was so far that the DODAG is a conv= ergecast to the destination so the destination is the root. If we say that = there's a single ingress and a single egress then the dodag is reversible a= nd either can be the root. If we want to support multicast tracks in the fu= ture, then the ingress should be root. If the Track has a single ingress and a single egress, then the DODAG is re= versible into another DODAG and it does not matter which is root, so we can= make it bidir as Huimin asked. The storing mode P DAO would look a lot more like a DAO, as you pointed out= , if it goes towards the root. If we want to take that path, a node could l= earn both directions with a single storing mode P DAO. To be continued... For non-storing, making bidir is really hard. It seems easier to install a = Track in both directions and couple them. As a summary of the proposed changes: General - we make the root the ingress - ICMP errors sent to the Root, using the main DODAG if the track is not re= versible Storing mode P DAO: - we also make the root the ingress, P-DAO from egress to ingress are now m= ore similar to RPL DAO operation - the track could be made bi-directional, but that's more code; if so: - the packet forwarding leverages the RPI to indicate the direction, from= or to root - ICMP errors sent to the Root, could be source or destination. Non storing mode P DAO: - tracks remain directional, can be coupled, how is tbd - the RPI is mostly useless since the intermediate nodes do not know the in= stance (they see neither the DIO nor the P-DAO); they have no idea of their= Rank. Still, it is interesting to have is for error determination in an IC= PMP error at eth root. It is also interesting if the SRH forwarding nodes h= ave a state associated to the Track, e.g., reserved time slots or priority = queues. - the RPI is still a SHOULD when there's no compression and a MUST when the= re is. We need to clarify what to do, that's another of Huimin's questions,= taken separately. - ICMP errors forwarding packets are sent to the root which is now the ingr= ess, aka the source of the packet, and the encapsulator field if the packet= is encapsulated and compressed. This is common to any non-storing operatio= n, whether it is a main Instance, local Instance, or Track. The RPI therein= is useful to indicate the Track in Error. So for that matter the forwarder= does not need to make a difference Track vs. other form of RPL local insta= nce. - this impacts the discussion in SRH reloading we had at IETF 109, when a = N-S mode loose track is forwarded along a segment that is also NS mode. We'= ll probably need to re-encapsulate now. In case of re-encapsulation, the r= e-encapsulator becomes source and root of the segment, which now has to be = considered as a serial Track; as tunnel headends do, it will have to decaps= ulate the tunneled packet to send the packet in error back to the ingress o= f the loose track Doe that work? Pascal From: Roll On Behalf Of Li Zhao (liz3) Sent: jeudi 26 novembre 2020 03:45 To: Routing Over Low power and Lossy networks Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questi= ons on P-DAO Hello Pascal, If either source or destination can be root, it's better to identify when o= r in which case source or destination can be root. Otherwise, it's hard to = interop between different implement even though they both follow RFC standa= rd. E.g. for non-storing mode PDAO, if source is root, PCE only responses PDR-A= CK after receiving PDR from source. But if destination is root, PCE should also notify destination which tracki= d is used. Maybe we need bring new message for this notification? Take care, Li From: Roll > Date: Wednesday, November 25, 2020 at 21:54 To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questi= ons on P-DAO Hello Li; Well noted. This was the original intent. The change was made to egress bec= ause the idea was that the track could enable multiple sources to reach the= egress, like a tree rooted at the egress that flows traverse going down. B= ut the idea of a bidirectional track kinda blocks that idea and the other i= ssues like the one you point out seem to get us back to the original view. = I recently made the change from ingress to egress in the 6TiSCH architectur= e, waiting in RFC editor queue. I could reverse back, or maybe say "either = source or destination" so it can be egress or egress and we are covered for= bidirectional. What do you think? Or should a reversable Track be really a pair of tracks? Keep safe; Pascal From: Roll > On Behalf = Of Li Zhao (liz3) Sent: mercredi 25 novembre 2020 05:57 To: Routing Over Low power and Lossy networks > Subject: Re: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questi= ons on P-DAO Hello Pascal, Ingress as Root looks better because 1. It is consistent with the way RPL usually works. RPL Local instance, ao= dv-rpl, p2p-rpl all use ingress as root. 2. For non-storing-mode P-DAO, currently ingress sends upward traffic to e= gress(root) with SR header. But in RPL, only downward traffic carries SR he= ader. 3. Only ingress can send PDR makes sense. Behavior of TrackId is similar a= s Local Instance ID. Ingress as root can propose TrackId from its namespace= . And for storing-mode P-DAO, if we make ingress as root and ingress sends PD= R, can PCE send P-DAO to egress then egress forwards it towards predecessor= to ingress? Maybe it helps to make P-DAO looks like a DAO message. Best regards, Li From: Roll > Date: Tuesday, November 24, 2020 at 21:39 To: Routing Over Low power and Lossy networks > Subject: [Roll] Make P-DAO bidirectional [extends] IETF 109 open Questions = on P-DAO Dear all Whether to make the P-DAO bidirectional is an intriguing question. It could= be done, just like we can send packets DOWN a classical DODAG. But if we take that path, we reopen the question of who is root and which d= irection the P-DAO flies. Could we make either the ingress OR the egress root? How does it matter? At the moment the Root is the egress and the storing-mode P-DAO flies from = the Track egress to the track ingress, and the track egress is the root. Th= is is not the way RPL usually works as the DAO flies towards the root. The = reason was that we wanted a single egress for the Track, as we build unicas= t Track. If we wanted to build multicast Tracks the root should logically b= e the ingress. And for bidirectional Tracks it could be either. Up to -24 the 6TiSCH Architecture expected the ingress to be root. I change= d in the latest to map we do here, that it is the egress; maybe a flag in t= he DAO would indicate which direction the flow, from root, to root, or both= ? Also if we build bidir Tracks in storing mode, the nodes that forward the D= AO will have to build routes in both directions based on the P-DAO, both to= wards egress and ingress; but only the path from which the P-DAO comes has = been validated by the P-DAO itself. Should we send a P-DAO to each end, eac= h setting up one way? Please let me know your thoughts Pascal From: Roll > On Behalf = Of Pascal Thubert (pthubert) Sent: mardi 24 novembre 2020 14:22 To: Routing Over Low power and Lossy networks > Subject: [Roll] IETF 109 open Questions on P-DAO Dear all The slides for the P-DAO discussion at IETF 109 are available here: https://datatracker.ietf.org/doc/slides-109-roll-dao-projection/ There are a number of open questions that we starting discussing, and would= need to progress on the list. Some of them were expressed on the list, e.g., from Huimin She. I'd like to= progress on them all with individual threads. The questions are: 1. Lifetime Unit: could we use a different unit for P-DAO? 2. How to differentiate a P-DAO from a normal DAO in a local instance; n= ew flag? 3. Make P-DAO bidirectional? 4. Who sends the PDR? Does it have to be the ingress? If it was egress i= t could propose a TrackId from its namespace. Else could the ingress be the= root? 5. Maintaining the sibling state. Should we have text on using RFC 8505 = there? 6. Whether ingress and egress are listed in NPO? Today they are both, in= gress to indicate the packet source in case of encapsulation and for SRH-6L= oRH compression reference and egress to build the full SRH-6LoRH. Note that= the ingress must consume the first entry and use it as source. 7. Track in Track vs. SR Header reload models, see slides Let me open threads to follow up. Keep safe Pascal --_000_CO1PR11MB48819304E7BE2BD815A8DB42D8F80CO1PR11MB4881namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all

 

<hard thinking here, sorry, been scratching my head quite= a bit, so please bear with me>

 

On this thread we decided to change the Root from being the = Track egress to being the ingress. That is cool for many reasons, but as i = said that kills the possibility to “reload” the routing header in a multi-segment Track where the segments are express= ed as non-storing P-DAOs. Why?

 

The operation I presented at IETF 109 involves changing the = packet source at the segment stitching point and still recognize the packet= as being part of a Track. The change above makes the packet source is the Root of the Track, so the packet source now= identifies the Track (together with the RPI). Non-storing P-DAOs require t= o add a routing header. If header insertion was allowed then that would not= be an issue.

 

But to add a RH cleanly at the segments stitching point, the= connecting router needs to decapsulate the previous segment and encapsulat= e the next segment with the RH. The connecting router becomes the source, thus the root. Meaning that the segment is in f= act a Track in its own right as opposed to a segment of the complex Track.

 

Another way to say that there is no segment in non-storing m= ode anymore. There are only Tracks that can be further assembled into more = complex graphs. That is, unless as I said we allow RH insertion despite the disputes we observe on the same subject = at 6MAN about Segment Routing. Or the TrackID is taken from the Global Inst= ance IDs name space. At the moment I’m ignoring those options which l= ead to either political issues or technical limitations.

 

 

A complex Track can still be expressed as a collection of lo= ose source routing paths from a same Ingress =3D=3D Root.

 

Think of it as a Segment Routing Policy for those familiar w= ith SR. The difference is that in SR the loose hops are ECMP path served by= the IGP.

 

Here we’ll need either non-storing Tracks or storing m= ode segments, the difference being that the storing mode segments do not re= quired re-encapsulation. Note that in either case, there can be multiple NECMP possibilities.

 

 

An example maybe?

 

 

Say we have

 

   &n= bsp;            = ;             &= nbsp;  ------ F

A------B------C-----= -D------E <

   &n= bsp;            = ;            &n= bsp;   ------ G

 

 

A is Track ingress, E is track Egress. C is stitching point.= F and G are E’s neighbors, “external” to the Track, and = reachable from A over the Track A->E.

In a general manner we want:

  • PD= AO 1 signals A->B->C
  • PDAO 2 signals C->= B->E
  • PDAO 3 signals F and G via the A->E Track

 

PDAO 3 being loose, it can only be non-storing. Note that si= nce the Root is always the ingress of a Track, and all SR-VIOs are now Trac= k, the Root being signaled in the DAO base object can now be elided in the VIA list in SR-VIO. This enables the const= ruction by the main root of the RFC 8138 optimized SRH-6LoRH in the SR-VIO,= to be placed as is in the packet by the Root.

 

 

1) Storing mode Segments

--------------------------------

 

A->B->C and C->D->E are segments of a same Track= .

Note that the storing mode signaling imposes strict continui= ty in a segment. This may also avoid weird loops.<= /p>

 

Case 1.1) Stitched Segments

 

  1. st= oring mode PDAO 1 is sent to E. It has Root =3D A, VIO =3D C, D, E, Track I= D 129 from A’s namespace, Target =3D E, F, G=
  2. storing mode PDAO 2 is then sent to C. It has Root =3D A, VIO =3D A, B, = C, Track ID 129 from A’s namespace, Target =3D E, F, G

 

E recognizes that it is egress because it is a Target and a = segment endpoint.

 

Packets along the Track have source=3D A, destination =3D E = | F | G, and RPI =3D 129.

From PDAO 2: A forwards to B and B forwards to C.=

From PDAO 1: C forwards to D and D forwards to E.=

 

 

Case 1.2) External routes

 

  1. st= oring mode PDAO 1 is sent to E. It has Root =3D A, VIO =3D C, D, E, Track I= D 129 from A’s namespace, Target =3D E
    2. <= li class=3D"MsoListParagraph" style=3D"margin-left:0cm;mso-list:l3 level1 l= fo6">sto= ring mode PDAO 2 is then sent to C. It has Root =3D A, VIO =3D A, B, C, Tra= ck ID 129 from A’s namespace, Target =3D E
  2. non storing mode PDAO 3 is then sent to A. It h= as Root =3D A, SRVIO =3D E, Track ID 129 from A’s namespace, Target = =3D F, G

 

From PDAO 3: A encapsulates packets with dest =3D  &nbs= p;F | G as below;

Packets along the Track have source=3D A, destination =3D E,= and RPI =3D 129.

From PDAO 2: A forwards to B and B forwards to C.=

From PDAO 1: C forwards to D and D forwards to E.=

E decapsulates if encapsulated packet.

 

 

 

Case 1.3) Segment Routing

 

  1. s= toring mode PDAO 1 is sent to E. It has Root =3D A, VIO =3D C, D, E, Track = ID 129 from A’s namespace, Target =3D E
    2. =
  2. s= toring mode PDAO 2 is then sent to B. It has Root =3D A, VIO =3D A, B, Trac= k ID 129 from A’s namespace, Target =3D B, C
  3. non storing mode PDAO 3 is then sent to A. It = has Root =3D A, SRVIO =3D C, E, Track ID 129 from A’s namespace, Targ= et =3D F, G

 

 

From PDAO 3: A encapsulates packets with dest =3D  &nbs= p;F | G as below;

Packets from A have source=3D A, destination =3D C, SRH =3D = E, and RPI =3D 129.

From PDAO 2: A forwards to B.

B forwards to C based on a sibling connected route; C consum= es the RH and makes the destination E.

From PDAO 1: C forwards to D and D forwards to E.

E decapsulates if encapsulated packet.

 

 

 

2) Non Storing mode joining Tracks

---------------------------------------------

 

A->B->C and C->D->E are Tracks expressed as non-= storing P-DAOs.

 

Case 2.1 Stitched Tracks

 

  1. n= on storing mode PDAO 1 is sent to C. It has Root =3D C, VIO =3D D, E, Track= ID 131 from C’s namespace, Target =3D E, F, G
  2. non storing mode PDAO 2 is then sent to A. It has Root =3D A, VIO =3D= B, C, Track ID 129 from A’s namespace, Target =3D E, F, G

 

From PDAO 2: A encapsulates packets with dest =3D  E | = F | G. The outer header has source =3D A, destination =3D B, SRH =3D C and = RPI =3D 129.

Packets forwarded by B have source=3D A, destination =3D C ,= SRH =3D, and RPI =3D 129. C decapsulates.

From PDAO 1: C  encapsulates packets with dest =3D &nbs= p;E | F | G. The outer header has source=3D C, destination =3D D, SRH =3D E= and RPI =3D 131.

E decapsulates.

 

 

Case 2.2 External routes

 

  1. n= on storing mode PDAO 1 is sent to C. It has Root =3D C, VIO =3D D, E, Track= ID 131 from C’s namespace, Target =3D E
  2. = non storing mode PDAO 2 is then sent to A. It has Root =3D A, VIO =3D B, C,= Track ID 129 from A’s namespace, Target =3D E
  3. non storing mode PDAO 3 is then sent to A. It has Root =3D A, SRVIO = =3D E, Track ID 141 from A’s namespace, Target =3D F, G

 

 

From PDAO 3: A encapsulates packets with dest =3D  &nbs= p;F | G. The outer header has source =3D A, destination =3D E, and RPI =3D = 141.

This may recurse with:

From PDAO 2: A encapsulates packets with dest =3D  E. T= he outer header has source =3D A, destination =3D B, SRH =3D C and RPI =3D = 129.

Packets forwarded by B have source=3D A, destination =3D C ,= SRH =3D, and RPI =3D 129. C decapsulates.

From PDAO 1: C  encapsulates packets with dest =3D &nbs= p;E. The outer header has source=3D C, destination =3D D, SRH =3D E and RPI= =3D 131.

E decapsulates if encapsulated.

 

 

Case 2.3 Segment Routing

 

  1. n= on storing mode PDAO 1 is sent to C. It has Root =3D C, VIO =3D D, E, Track= ID 131 from C’s namespace, Target =3D E
  2. = non storing mode PDAO 2 is then sent to A. It has Root =3D A, VIO =3D B, &n= bsp;Track ID 129 from A’s namespace, Target =3D C, E
  3. non storing mode PDAO 3 is then sent to A. It has Root =3D A, S= RVIO =3D C, E, Track ID 141 from A’s namespace, Target =3D F, G

 

 

From PDAO 3: A encapsulates packets with dest =3D  &nbs= p;F | G. The outer header has source =3D A, destination =3D C, SRH =3D E, a= nd RPI =3D 141.

This may recurse with:

From PDAO 2: A encapsulates packets with dest =3D  C | = E . The outer header has source =3D A, destination =3D B, and RPI =3D 129.

B decapsulates forwards to C based on a sibling connected ro= ute; C consumes the RH and makes the destination E.

From PDAO 1: C  encapsulates packets with dest =3D &nbs= p;E. The outer header has source=3D C, destination =3D D, SRH =3D E and RPI= =3D 131.

E decapsulates, twice for dest =3D   F | G.

 

 

Does that work so far?

 

Keep safe

 

Pascal

 

 

From: Roll <roll-bo= unces@ietf.org> On Behalf Of Pascal Thubert = (pthubert)
Sent: jeudi 26 novembre 2020= 11:47
To: Routing Over Low power a= nd Lossy networks <roll@ietf.org>
Subject: Re: [Roll] Make P-D= AO bidirectional [extends] IETF 109 open Questions on P-DAO

 

Hello Li

 

In the packet, there’s a bit in the RPI to say if the = root is the source or the destination. That’s RFC 6550.

I guess the discussion is related to the PDR and P-DAO, not = data packet, though it impacts the ICMP error reporting.<= /font>

 

In a packet along the P-Route, the idea was so far that the = DODAG is a convergecast to the destination so the destination is the root. = If we say that there’s a single ingress and a single egress then the dodag is reversible and either can be the roo= t. If we want to support multicast tracks in the future, then the ingress s= hould be root.

 

If the Track has a single ingress and a single egress, then = the DODAG is reversible into another DODAG and it does not matter which is = root, so we can make it bidir as Huimin asked.

The storing mode P DAO would look a lot more like a DAO, as = you pointed out, if it goes towards the root. If we want to take that path,= a node could learn both directions with a single storing mode P DAO. To be continued…

 

For non-storing, making bidir is really hard. It seems easie= r to install a Track in both directions and couple them.<= /font>

 

As a summary of the proposed changes:

 

General

- we make the root the ingress

- ICMP errors sent to the Root, using the main DODAG if the = track is not reversible

 

 

Storing mode P DAO:

- we also make the root the ingress, P-DAO from egress to in= gress are now more similar to RPL DAO operation

- the track could be made bi-directional, but that’s m= ore code; if so:

  - the packet forwarding leverages the RPI to indicate= the direction, from or to root

  - ICMP errors sent to the Root, could be source or de= stination.

 

Non storing mode P DAO:

- tracks remain directional, can be coupled, how is tbd=

- the RPI is mostly useless since the intermediate nodes do = not know the instance (they see neither the DIO nor the P-DAO); they have n= o idea of their Rank. Still, it is interesting to have is for error determination in an ICPMP error at eth root. It is al= so interesting if the SRH forwarding nodes have a state associated to the T= rack, e.g., reserved time slots or priority queues.

- the RPI is still a SHOULD when there’s no compressio= n and a MUST when there is. We need to clarify what to do, that’s ano= ther of Huimin’s questions, taken separately.

- ICMP errors forwarding packets are sent to the root which = is now the ingress, aka the source of the packet, and the encapsulator fiel= d if the packet is encapsulated and compressed. This is common to any non-storing operation, whether it is a main Instance= , local Instance, or Track. The RPI therein is useful to indicate the Track= in Error. So for that matter the forwarder does not need to make a differe= nce Track vs. other form of RPL local instance.

- this impacts the discussion in SRH reloading we had at IET= F 109, when a  N-S mode loose track is forwarded along a segment that = is also NS mode. We’ll probably need to re-encapsulate now.  In case of re-encapsulation, the re-encapsulator becomes source= and root of the segment, which now has to be considered as a serial Track;= as tunnel headends do, it will have to decapsulate the tunneled packet to = send the packet in error back to the ingress of the loose track

 

 

Doe that work?

 

Pascal

 

From: Roll <roll-bo= unces@ietf.org> On Behalf Of Li Zhao (liz3)<= br> Sent: jeudi 26 novembre 2020= 03:45
To: Routing Over Low power a= nd Lossy networks <roll@ietf.org>
Subject: Re: [Roll] Make P-D= AO bidirectional [extends] IETF 109 open Questions on P-DAO

 

Hello Pascal,

 

If either source or destination can be root, it’s bett= er to identify when or in which case source or destination can be root. Oth= erwise, it’s hard to interop between different implement even though they both follow RFC standard.

 

E.g. for non-storing mode PDAO, if source is root, PCE only = responses PDR-ACK after receiving PDR from source.=

But if destination is root, PCE should also notify destinati= on which trackid is used. Maybe we need bring new message for this notifica= tion?

 

 

Take care,

Li

 

From: Roll <roll-bounces@ie= tf.org>
Date: Wednesday, November 25= , 2020 at 21:54
To: Routing Over Low power a= nd Lossy networks <roll@ietf.org= >
Subject: Re: [Roll] Make P-D= AO bidirectional [extends] IETF 109 open Questions on P-DAO

Hello Li;

 

Well noted. This was the original intent. The change was mad= e to egress because the idea was that the track could enable multiple sourc= es to reach the egress, like a tree rooted at the egress that flows traverse going down. But the idea of a bidirectio= nal track kinda blocks that idea and the other issues like the one you poin= t out seem to get us back to the original view. I recently made the change = from ingress to egress in the 6TiSCH architecture, waiting in RFC editor queue. I could reverse back, or maybe = say “either source or destination” so it can be egress or egres= s and we are covered for bidirectional.

What do you think?

Or should a reversable Track be really a pair of tracks?

 

Keep safe;

 

Pascal

 

From: Roll <roll-bounces@ietf.org> On Behalf Of Li Zhao (liz3)<= br> Sent: mercredi 25 novembre 2= 020 05:57
To: Routing Over Low power a= nd Lossy networks <roll@ietf.org>= ;
Subject: Re: [Roll] Make P-D= AO bidirectional [extends] IETF 109 open Questions on P-DAO

 

Hello Pascal,

 

Ingress as Root looks better because

1.  It is consistent with the way RPL usually works. RP= L Local instance, aodv-rpl, p2p-rpl all use ingress as root.

2.  For non-storing-mode P-DAO, currently ingress sends= upward traffic to egress(root) with SR header. But in RPL, only downward t= raffic carries SR header.

3.  Only i= ngress can send PDR makes sense. Behavior of TrackId is similar as Local Instance= ID. Ingress as root can propose TrackId from its namespace.<= o:p>

 

 

And for storing-mode P-DAO, if we make ingress as root and i= ngress sends PDR, can PCE send P-DAO to egress then egress forwards it towa= rds predecessor to ingress?

Maybe it helps to make P-DAO looks like a DAO message.

 

 

Best regards,

Li

 

 

From: Roll <roll-bounces@ie= tf.org>
Date: Tuesday, November 24, = 2020 at 21:39
To: Routing Over Low power a= nd Lossy networks <roll@ietf.org= >
Subject: [Roll] Make P-DAO b= idirectional [extends] IETF 109 open Questions on P-DAO<= /o:p>

Dear all

 

Whether to make the P-DAO bidirectional is an intriguing que= stion. It could be done, just like we can send packets DOWN a classical DOD= AG.

But if we take that path, we reopen the question of who is r= oot and which direction the P-DAO flies.

 

Could we make either the ingress OR the egress root? How doe= s it matter?

 

At the moment the Root is the egress and the storing-mode P-= DAO flies from the Track egress to the track ingress, and the track egress = is the root. This is not the way RPL usually works as the DAO flies towards the root. The reason was that we wanted a s= ingle egress for the Track, as we build unicast Track. If we wanted to buil= d multicast Tracks the root should logically be the ingress. And for bidire= ctional Tracks it could be either.

 

Up to -24 the 6TiSCH Architecture expected the ingress to be= root. I changed in the latest to map we do here, that it is the egress; ma= ybe a flag in the DAO would indicate which direction the flow, from root, to root, or both?<= /p>

 

Also if we build bidir Tracks in storing mode, the nodes tha= t forward the DAO will have to build routes in both directions based on the= P-DAO, both towards egress and ingress; but only the path from which the P-DAO comes has been validated by the P-D= AO itself. Should we send a P-DAO to each end, each setting up one way?

 

Please let me know your thoughts

 

Pascal

 

 

From: Roll <roll-bounces@ietf.org> On Behalf Of Pascal Thubert = (pthubert)
Sent: mardi 24 novembre 2020= 14:22
To: Routing Over Low power a= nd Lossy networks <roll@ietf.org>= ;
Subject: [Roll] IETF 109 ope= n Questions on P-DAO

 

Dear all

 

The slides for the P-DAO discussion at IETF 109 are availabl= e here:

 

https://datatracker.ietf.org/doc/slides-109-roll-dao-proje= ction/

 

There are a number of open questions that we starting discus= sing, and would need to progress on the list.

Some of them were expressed on the list, e.g., from Huimin S= he. I’d like to progress on them all with individual threads.

The questions are:

 

  1. Li= fetime Unit: could we use a different unit for P-DAO?
  2. How to differentiate a P-DAO from a normal DAO in a local instance; n= ew flag?
  3. Make P-DAO bidirectional?
  4. Who sends the PDR? Does it have to be the ingress? If it was= egress it could propose a TrackId from its namespace. Else could the ingress be the root?
  5. Maintaining the = sibling state. Should we have text on using RFC 8505 there?
  6. Whether ingress and egress are listed in NPO? Today they are bo= th, ingress to indicate the packet source in case of encapsulation and for SRH-6LoRH compression reference and egress to build the full SRH-6= LoRH. Note that the ingress must consume the first entry and use it as sour= ce.
  7. Track in Track vs. SR Header reload models, = see slides

 

Let me open threads to follow up.

 

Keep safe

 

Pascal

 

 

--_000_CO1PR11MB48819304E7BE2BD815A8DB42D8F80CO1PR11MB4881namp_-- From nobody Fri Nov 27 10:05:27 2020 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CF753A0B10; Fri, 27 Nov 2020 10:05:25 -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.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: roll@ietf.org Message-ID: <160650032506.26731.4890830454345261477@ietfa.amsl.com> Date: Fri, 27 Nov 2020 10:05:25 -0800 Archived-At: Subject: [Roll] I-D Action: draft-ietf-roll-dao-projection-15.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2020 18:05:25 -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 Matthew Gillmore Filename : draft-ietf-roll-dao-projection-15.txt Pages : 36 Date : 2020-11-27 Abstract: This document extends RFC 6550 and RFC 6553 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-15.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-dao-projection-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Nov 27 10:10:28 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 214143A0B12 for ; Fri, 27 Nov 2020 10:10:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.62 X-Spam-Level: X-Spam-Status: No, score=-9.62 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.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=inkFCbgH; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=kogVjkgd 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 JwhXrYRNShxZ for ; Fri, 27 Nov 2020 10:10:25 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DA933A0B15 for ; Fri, 27 Nov 2020 10:10:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2472; q=dns/txt; s=iport; t=1606500625; x=1607710225; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=nMo9wVGPEF2AgAwPFLuzqyMM0BQUgjii9lSzBZ5uTCA=; b=inkFCbgHK51ZF2IGhPUWUcvcj4/heXL9fhoadlkwumVg7geVNs/21t1B KvsAazo16p98B0PFHn6G2tCzhmAIuRo4hIbgSe4WMtCX8q6xQO4TBTOvV ZyXylXQyv/PJNs/27GHhJqkvmxJ5F4OARqV79zrHbNwpCku1+H+M8f6c/ U=; X-IPAS-Result: =?us-ascii?q?A0D0DABgQMFffYYNJK1igQmBUYFQUXxaLy6IBgONX5B/i?= =?us-ascii?q?AeBQoERA1QLAQEBDQEBGAsKAgQBAYRKAoIpAiU5BQ0CAwEBAQMCAwEBAQEFA?= =?us-ascii?q?QEBAgEGBBQBAYY8DIVyAQEBBAEBECgGAQEsDAsEAgEIEQQBAR8QJwsbAQEFA?= =?us-ascii?q?wIEEwgagwWCVQMuAQ6lBAKBPIhpdIE0gwQBAQWBNwIOQYM3GIIQCYE4gnOKT?= =?us-ascii?q?RuBQT+BVIJVPoJdAQEBAQEBFYEMHCCDSIIsuG4Kgm+JF4lfiFiDHYEriHKUW?= =?us-ascii?q?p5rlWgCBAIEBQIOAQEFgW4ggVlwFRohgmkJRxcCDZIShRSFRHQCNQIGCgEBA?= =?us-ascii?q?wl8jnsBAQ?= IronPort-PHdr: =?us-ascii?q?9a23=3AXEtH7RHXHEa20SIcwjCSPZ1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e401QWbXIjH5bRDkeWF+6zjWGlV55GHvThCdZFXTB?= =?us-ascii?q?YKhI0QmBBoG8+KD0D3bZuIJyw3FchPThlpqne8N0UGGcviaRvVuHLhpTIXEw?= =?us-ascii?q?/0YAxyIOm9E4XOjsOxgua1/ZCbYwhBiDenJ71oKxDjpgTKvc5Qioxneas=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,375,1599523200"; d="scan'208";a="601964886" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 27 Nov 2020 18:10:23 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 0ARIAN87031129 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 27 Nov 2020 18:10:23 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 27 Nov 2020 12:10:23 -0600 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Fri, 27 Nov 2020 12:10:22 -0600 Received: from NAM04-BN8-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Fri, 27 Nov 2020 12:10:22 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fQ3J6zoFSDPOe0AU0r+xh6iMZxpsuWsB/nYfeGCmCmK+nWNtVCF9eQcoRJA7rewRFoa1iFbf5fHjJ1imLYBHW3d8aodazpQ26KQFgHC/vVjS7Hei5AlIWdexibqvUEvwFsMZILUtEsBsujWpbZUrrZLyeVrfJ+EK0msz4JTOxMADRkrskBJ4B5Ooqtkev8zbAP5klMD99E4+6Hr8Ce+56TDenGt0IHsQhEt98ibBa2XgtomxPEDR/ptaw9EFXEj756+JtwIGTNaKQRoHBv+HhREAOZTykWTWwJzGCdHp6R8Hy7GUBBgXlg+jU2wE0d6jWH/c+ok+tNxVBFeRUwHVlw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=f5gVJfhdoEKCYZ4wohRH2Sy4ATB92RcOoCX9ztDbfy0=; b=n2Fm+NvplXcvdM7smkRwYl4jipjmSg9kAaGjXWiOeMVwArNqQdOXXhdulnHmjBVUneiSW3hYexKX3XkKtoanzywCS7akIx1ObZFXpqA8xHvX0l3e9jAkGHyMT/2UkDM1lWoLHarOqgL3IY/ZrjTKEJ5ZggRaTzLtDeCOEtE56vi99OMpjoDeYAoZWijm0pSk6/zJPg6xB93UUYfr+v2HG1HbZYnQ5VIAvHJyFwsX/tMO64Y5qjAiAGbTinQb6SxSqvzGie95a4xSCe0Wz+I9CSvX2QQ1am6h65puNr3lzCyf0fR5jAzo25rzf9LYF3akTdzJ76NeoIXEvTzdmEcjpA== 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=f5gVJfhdoEKCYZ4wohRH2Sy4ATB92RcOoCX9ztDbfy0=; b=kogVjkgdYK/wzS1Uw6AbYL7R+AIc3AR1A9fx3sb6CnDjGFyPfGSTPmBadLj80bgqBL95M1JW2UY51O7sBL+J4X5kbywHCVY4DaAtmS6cJH+QcvFP60qhJ3qyoA6rSvbVwsDtAmiBBoyT6jW0QMx82+sXdq+8MvxY78zHjJZZhUo= Received: from CO1PR11MB4881.namprd11.prod.outlook.com (2603:10b6:303:91::20) by MWHPR1101MB2080.namprd11.prod.outlook.com (2603:10b6:301:56::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.25; Fri, 27 Nov 2020 18:10:21 +0000 Received: from CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::fc25:3e72:3e83:7df6]) by CO1PR11MB4881.namprd11.prod.outlook.com ([fe80::fc25:3e72:3e83:7df6%4]) with mapi id 15.20.3564.025; Fri, 27 Nov 2020 18:10:21 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] I-D Action: draft-ietf-roll-dao-projection-15.txt Thread-Index: AQHWxOf/nU7dkXrybECi670ZhKHpL6ncRkdg Date: Fri, 27 Nov 2020 18:10:16 +0000 Deferred-Delivery: Fri, 27 Nov 2020 18:10:10 +0000 Message-ID: References: <160650032506.26731.4890830454345261477@ietfa.amsl.com> In-Reply-To: <160650032506.26731.4890830454345261477@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2a01:cb1d:4ec:2200:c8f2:5373:2d8d:7ffa] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 59ac3a2e-e141-4007-387a-08d892ffb482 x-ms-traffictypediagnostic: MWHPR1101MB2080: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:7691; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 4kNprz+fZI0RzzVAEZLe7Odk1e7m1SDLZq5MyW+/fG+2hvoDbEtWX0tk1E2K72V5b72RPaywicLnW3D6iaYZkNrUu9gok87H2LrJPs1+AHXyAX3tQjQMWWwsGuyiVmAdZGGMJVK2VdS2u506JT1wrTM+SGc3l5x+0gbcoSHeXw86F3qH+EMtT/M48FhKlnYZbI8pPEtdRXIUjcRO6xA87CMaKw+sWyF7fNIsi1YlU9MAKJTVGOPcPnvXaYd6JwPC+nZMvhGvei1NWn51Zw8YxD5OGbpUUCu/DQBMBLo4vBenc/ngBp0ceuqtG1GokDuLs/ifQ7tQn7jht+mPxUjkTSBqE41rHnIG5sujJ01MlRbpB/x6Z18pVVJFSN7E6fyfaRgNBUYJhiOZoftEYQ/ShA== 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:(366004)(39860400002)(136003)(376002)(346002)(396003)(2906002)(71200400001)(966005)(4001150100001)(53546011)(8676002)(83380400001)(55016002)(86362001)(7696005)(5660300002)(66946007)(316002)(9686003)(76116006)(6506007)(66446008)(6916009)(8936002)(64756008)(66556008)(66476007)(52536014)(33656002)(6666004)(186003)(478600001)(66574015); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?us-ascii?Q?IXZevQCTLlylUEVhQQYkQUmQvf4EJZ4yE06m6urKaFEMtq7YgsTyQ4yw/plV?= =?us-ascii?Q?vCFcZwEKjVTa+MS8LMrcEoGkAt8+0zHESvybvJ8zwe9say3tJxy9F74G4Qol?= =?us-ascii?Q?7sD8uV5iFH1wCx3DaWpS5bwGc4yv8ML7OMLqjDPX8usOT5Om9DMXhXJ/sv0W?= =?us-ascii?Q?64jVPnQ6tRX039HAqGrbIIECaKdXkYYeecj3W2/A3rJN+dxEAbAMoF0YT+4u?= =?us-ascii?Q?O7lfOnMV++VRHDcSC2XAQkeMm60wldK2eCYkFL8HnfltxzF8Zu7c44ak+fti?= =?us-ascii?Q?IVcmZh3FJRiDS97gOXBACemucOxaLuPLpCoNBSYZxUSkEH+Lv1y9zL8k8cs5?= =?us-ascii?Q?yE810e3JDs7lS+zVoVoTg/0kuOLH6+NLj3Duy/tLPmudhvMXvHibct9nAmDI?= =?us-ascii?Q?E1HlCXdfCqrBJxg8jogQ35SfDtRi/9CNr/FKTfYErHa21Olauv0Nv+umLiQA?= =?us-ascii?Q?+Gx3oAlfwRyrQrIn9DO4T6WDWoTQHAQ0trVQ2RDBuM6UURSMMGXjTyOK/V35?= =?us-ascii?Q?rFPnhKw7Lu3q2SQE+YbUGejtQceyeHgNHI2rqYP/Z1cR46dph1el1Rr7mo9G?= =?us-ascii?Q?WyTxGSGmitBAEuiJKIhHqlTBBgtTvQE7dOGpLF1hxxwerYSJ71kPlBMpmlKl?= =?us-ascii?Q?uJXsNz1H9mIHhR1i77do7b1mQF14PZ29CZbjEU4IuMxd0ae8aZoEwpimWD/r?= =?us-ascii?Q?8LBTouSV7nXF1RHxJ9LazD3UWgiyfjBlG7QiJsLV2dgeOb5f4e0z50o2YKEO?= =?us-ascii?Q?QB4kQBQnlaoUPtmj9Oi8W8goRdVDF9OBbdSDvUkVhhw4tbdCUcYnEp32PbhC?= =?us-ascii?Q?6W6+DviiD/WwaCXJ1CSCHLkcVs5sk6ypaqOoYZRrB5VYuBpMHv1V+kK3m2gv?= =?us-ascii?Q?1+K+AhjJs7ySinRF1PoKg0ViUxidSRSXJHYzXdCJjFwPIHqmJtXHW6Osj4hi?= =?us-ascii?Q?SQl9j+hCBD+v8Pg/T+vvy5a1r+5EIg4ATNZdHfRXZF7uwbQUvG0NMczwtB+c?= =?us-ascii?Q?6R34acJbpgH0Y+rVZE3wQ1nMhh0NmFGYyt8NS+nM3cduy8KP2SG3vcir7yS4?= =?us-ascii?Q?CUQHK2wX?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: CO1PR11MB4881.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 59ac3a2e-e141-4007-387a-08d892ffb482 X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Nov 2020 18:10:21.3483 (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: p6bMuHbMWF+BB5KqQU0qXG8XUyXnTCFLOUHx58N3nGTjpID6Zf8Heez7TEIntNtEt1lURB96tmeXL9K3BXc/fg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR1101MB2080 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: [Roll] FW: I-D Action: draft-ietf-roll-dao-projection-15.txt X-BeenThere: roll@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Routing Over Low power and Lossy networks List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Nov 2020 18:10:27 -0000 Dear all: As discussed in recent threads, I made a first round of changes. The main change is the fact that the Track Root is now the ingress; I also = added a flag in the RPI to signal that the packet ids forwarded along a pro= jected route, including the RFC 8138 compression. There's more to do to address the issues listed at IETF 109. Also need of c= leanup and reshuffling. Please let me know what you think? Pascal -----Original Message----- From: Roll On Behalf Of internet-drafts@ietf.org Sent: vendredi 27 novembre 2020 19:05 To: i-d-announce@ietf.org Cc: roll@ietf.org Subject: [Roll] I-D Action: draft-ietf-roll-dao-projection-15.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 Matthew Gillmore Filename : draft-ietf-roll-dao-projection-15.txt Pages : 36 Date : 2020-11-27 Abstract: This document extends RFC 6550 and RFC 6553 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-15.html A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-roll-dao-projection-15 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Roll mailing list Roll@ietf.org https://www.ietf.org/mailman/listinfo/roll From nobody Sun Nov 29 01:56:14 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C3C93A13CC for ; Sun, 29 Nov 2020 01:56:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.117 X-Spam-Level: X-Spam-Status: No, score=-2.117 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, 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=orange.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 bLrWPi7hHSFJ for ; Sun, 29 Nov 2020 01:56:11 -0800 (PST) Received: from relais-inet.orange.com (relais-inet.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6ED2D3A13CB for ; Sun, 29 Nov 2020 01:56:11 -0800 (PST) Received: from opfednr01.francetelecom.fr (unknown [xx.xx.xx.65]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id 4CkNzY5cc8zCqsT; Sun, 29 Nov 2020 10:56:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=orange.com; s=ORANGE001; t=1606643769; bh=WyXxdQ7zphfm4QXnlpcPpWasFAQEFsa0UJBG6xQIGMo=; h=From:To:Subject:Date:Message-ID:Content-Type:MIME-Version; b=StXVH2Zr/pTSYJ5bAgGznXdazhc3VO2bJ4YrZMOqnbqTwJtOHvDE8IMH4sXDWD2Fs JTSaloLaAr/IoqOZM2sM7EGFkzrPxW2vmAotApEOzYWKq1ARbkm/gUP4g0ommJRRad 5B/oDnoBjifg1H82hYU0dTaC3gTzFWkVT0n/ac1CJxKTUj/R/kbrfvv/BofXB4qVaM gCBnufxSbYHKUIuSxPK2X5EVv4DNBy6IbbfsUQiSGRWrdGPbVwmtAtcVf0So0D0lUW G+oBk008ehJCSUk71hBiriXfBFRduj6RFgIVqPRNVpUa9W6BrEYe/r1dHKSf9A/brT tjPxu6V08Zukw== Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.51]) by opfednr01.francetelecom.fr (ESMTP service) with ESMTP id 4CkNzY4sVRzDq7B; Sun, 29 Nov 2020 10:56:09 +0100 (CET) From: To: Alvaro Retana , "roll@ietf.org" CC: "mariainesrobles@googlemail.com" Thread-Topic: RootAck discussion at IETF109 ROLL session Thread-Index: AQHWxjXc/MyqBxFoXEeJ3FhMYSJqGA== Date: Sun, 29 Nov 2020 09:56:08 +0000 Message-ID: <19942_1606643769_5FC37039_19942_221_1_DBE92EC6.7CF9B%dominique.barthel@orange.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.7.3.170325 x-originating-ip: [10.114.13.247] Content-Type: multipart/alternative; boundary="_000_DBE92EC67CF9Bdominiquebarthelorangecom_" MIME-Version: 1.0 Archived-At: Subject: [Roll] RootAck discussion at IETF109 ROLL session 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, 29 Nov 2020 09:56:14 -0000 --_000_DBE92EC67CF9Bdominiquebarthelorangecom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gYWxsLA0KDQpGb2xsb3dpbmcgb3VyIFJPTEwgc2Vzc2lvbiBhdCB0aGUgSUVURjEwOSBt ZWV0aW5nLCBJIGhhZCBhbiBhY3Rpb24gcG9pbnQgdG8gZGlnIHVwIHBvaW50ZXJzIHRvIHByaW9y IGRpc2N1c3Npb25zIGFib3V0IERBTy9EQU8tQUNLcyBpbiBzdG9yaW5nIG1vZGUgYW5kIHRoZSBk ZWNpc2lvbiB0byBnbyBmb3IgYSBSb290QUNLLg0KDQpJZiB5b3Ugd2FudCBvbmx5IG9uZSBwb2lu dGVyLCB0aGF0IHdvdWxkIGJlIHRoZSB2aWRlbyBvZiB0aGUgUk9MTCBzZXNzaW9uIGF0IHRoZSBJ RVRGMTAzIG1lZXRpbmcgaHR0cHM6Ly95b3V0dS5iZS83Y3doTUxhZGRxVT90PTM0MDggLCAoc3Rh cnQgdGltZSA1Njo0NSwgZHVyYXRpb24gYWJvdXQgNiBtbikuDQoNCk1vcmUgcG9pbnRlcnMgYmVs b3cNCi0gZGlzY3Vzc2lvbnMgb24gTUwgYWJvdXQgaW50ZXJwcmV0YXRpb24gb2YgREFPLUFDSyBi ZWhhdmlvdXIsIGUuZy4gYXMgZmFyIGJhY2sgYXMgMjAxNQ0KICBodHRwczovL21haWxhcmNoaXZl LmlldGYub3JnL2FyY2gvbXNnL3JvbGwvOGpmN0I0T19TU3o1NzVmanY1OUVNSDJ4czdnLw0KLSBk ZXNjcmlwdGlvbiBvZiB0aGUgaXNzdWVzIGluIGRyYWZ0LWlldGYtcm9sbC1ycGwtb2JzZXJ2YXRp b25zLCBTZWN0aW9uIDQsIGZpcnN0IHB1Ymxpc2hlZCBpbiBTZXB0IDIwMTgNCiAgaHR0cHM6Ly90 b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcm9sbC1ycGwtb2JzZXJ2YXRpb25zLTA0DQot IFJPTEwgc2Vzc2lvbiBhdCBJRVQxMDMgbWVldGluZyAoTm92IDUsIDIwMTgsIEJhbmdrb2spDQog IHNsaWRlczogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzEwMy9tYXRlcmlh bHMvc2xpZGVzLTEwMy1yb2xsLXJvbGwtaWV0ZjEwMy12Mi0wMC5wZGYNCiAgbWludXRlczogaHR0 cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvbWludXRlcy0xMDMtcm9sbC8NCiAgRXhjZXJw dCDigJxQYXNjYWw6IHdlIGNvdWxkIHNwZWNpZnkgYSBtZWNoYW5pc20gdG8gZ2V0IGFuIEFDSyBm cm9tIHRoZSByb290IGFsbCB0aGUNCiAgd2F5IGRvd24gdGhlIERPREFHLiBDb3VsZCBiZSBhIG5l dyBkcmFmdC4gQUNUSU9OOiBuZXcgZHJhZnQgb24gQUNLIGZyb20gdGhlIHJvb3Q/4oCdDQotIFZp ZGVvOiAoZnJvbSB0aW1lIDU2OjQ1LCBhYm91dCA2IG1uKSBodHRwczovL3lvdXR1LmJlLzdjd2hN TGFkZHFVP3Q9MzQwOA0KLSBlbnN1aW5nIGRyYWZ0IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWphZGhhdi1yb2xsLXN0b3Jpbmctcm9vdGFjay8gZmlyc3QgcHVibGlzaGVk IEFwciAyMDIwDQoNCkJlc3QgcmVnYXJkcw0KDQpEb21pbmlxdWUNCgpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCgpDZSBtZXNz YWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlv bnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVlcyBldCBuZSBkb2l2ZW50IGRvbmMKcGFz IGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3BpZXMgc2FucyBhdXRvcmlzYXRpb24uIFNp IHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVycmV1ciwgdmV1aWxsZXogbGUgc2lnbmFs ZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUgYWluc2kgcXVlIGxlcyBwaWVjZXMgam9p bnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMgZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0 ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVzcG9uc2FiaWxpdGUgc2kgY2UgbWVzc2Fn ZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lmaWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdl IGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIG9yIHByaXZpbGVn ZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVjdGVkIGJ5IGxhdzsKdGhleSBzaG91bGQg bm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGllZCB3aXRob3V0IGF1dGhvcmlzYXRpb24u CklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkg dGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2FnZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpB cyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBpcyBub3QgbGlhYmxlIGZvciBtZXNzYWdl cyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdlZCBvciBmYWxzaWZpZWQuClRoYW5rIHlv dS4KCg== --_000_DBE92EC67CF9Bdominiquebarthelorangecom_ Content-Type: text/html; charset="utf-8" Content-ID: <27C82A97F932364982A836763F185D89@adroot.infra.ftgroup> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5IZWxsbyBhbGws PC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5Gb2xsb3dpbmcgb3VyIFJPTEwgc2Vzc2lv biBhdCB0aGUgSUVURjEwOSBtZWV0aW5nLCBJIGhhZCBhbiBhY3Rpb24gcG9pbnQgdG8gZGlnIHVw IHBvaW50ZXJzIHRvIHByaW9yIGRpc2N1c3Npb25zIGFib3V0IERBTy9EQU8tQUNLcyBpbiBzdG9y aW5nIG1vZGUgYW5kIHRoZSBkZWNpc2lvbiB0byBnbyBmb3IgYSBSb290QUNLLjwvZGl2Pg0KPGRp dj48YnI+DQo8L2Rpdj4NCjxkaXY+SWYgeW91IHdhbnQgb25seSBvbmUgcG9pbnRlciwgdGhhdCB3 b3VsZCBiZSB0aGUgdmlkZW8gb2YgdGhlIFJPTEwgc2Vzc2lvbiBhdCB0aGUgSUVURjEwMyBtZWV0 aW5nJm5ic3A7PGEgaHJlZj0iaHR0cHM6Ly95b3V0dS5iZS83Y3doTUxhZGRxVT90PTM0MDgiPmh0 dHBzOi8veW91dHUuYmUvN2N3aE1MYWRkcVU/dD0zNDA4PC9hPiZuYnNwOywgKHN0YXJ0IHRpbWUg NTY6NDUsIGR1cmF0aW9uIGFib3V0IDYgbW4pLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxk aXY+TW9yZSBwb2ludGVycyBiZWxvdzwvZGl2Pg0KPGRpdj4NCjxkaXY+LSBkaXNjdXNzaW9ucyBv biBNTCBhYm91dCBpbnRlcnByZXRhdGlvbiBvZiBEQU8tQUNLIGJlaGF2aW91ciwgZS5nLiBhcyBm YXIgYmFjayBhcyAyMDE1PC9kaXY+DQo8ZGl2PiZuYnNwOyBodHRwczovL21haWxhcmNoaXZlLmll dGYub3JnL2FyY2gvbXNnL3JvbGwvOGpmN0I0T19TU3o1NzVmanY1OUVNSDJ4czdnLzwvZGl2Pg0K PGRpdj4tIGRlc2NyaXB0aW9uIG9mIHRoZSBpc3N1ZXMgaW4gZHJhZnQtaWV0Zi1yb2xsLXJwbC1v YnNlcnZhdGlvbnMsIFNlY3Rpb24gNCwgZmlyc3QgcHVibGlzaGVkIGluIFNlcHQgMjAxODwvZGl2 Pg0KPGRpdj4mbmJzcDsgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcm9s bC1ycGwtb2JzZXJ2YXRpb25zLTA0PC9kaXY+DQo8ZGl2Pi0gUk9MTCBzZXNzaW9uIGF0IElFVDEw MyBtZWV0aW5nIChOb3YgNSwgMjAxOCwgQmFuZ2tvayk8L2Rpdj4NCjxkaXY+Jm5ic3A7IHNsaWRl czogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9tZWV0aW5nLzEwMy9tYXRlcmlhbHMvc2xp ZGVzLTEwMy1yb2xsLXJvbGwtaWV0ZjEwMy12Mi0wMC5wZGY8L2Rpdj4NCjxkaXY+Jm5ic3A7IG1p bnV0ZXM6IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL21pbnV0ZXMtMTAzLXJvbGwv PC9kaXY+DQo8ZGl2PiZuYnNwOyBFeGNlcnB0IOKAnFBhc2NhbDogd2UgY291bGQgc3BlY2lmeSBh IG1lY2hhbmlzbSB0byBnZXQgYW4gQUNLIGZyb20gdGhlIHJvb3QgYWxsIHRoZTwvZGl2Pg0KPGRp dj4mbmJzcDsgd2F5IGRvd24gdGhlIERPREFHLiBDb3VsZCBiZSBhIG5ldyBkcmFmdC4gQUNUSU9O OiBuZXcgZHJhZnQgb24gQUNLIGZyb20gdGhlIHJvb3Q/4oCdPC9kaXY+DQo8ZGl2Pi0gVmlkZW86 IChmcm9tIHRpbWUgNTY6NDUsIGFib3V0IDYgbW4pIGh0dHBzOi8veW91dHUuYmUvN2N3aE1MYWRk cVU/dD0zNDA4PC9kaXY+DQo8ZGl2Pi0gZW5zdWluZyBkcmFmdCBodHRwczovL2RhdGF0cmFja2Vy LmlldGYub3JnL2RvYy9kcmFmdC1qYWRoYXYtcm9sbC1zdG9yaW5nLXJvb3RhY2svIGZpcnN0IHB1 Ymxpc2hlZCBBcHIgMjAyMDwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5C ZXN0IHJlZ2FyZHM8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PkRvbWluaXF1ZTwvZGl2 Pg0KPFBSRT5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fCgpDZSBtZXNzYWdlIGV0IHNlcyBwaWVjZXMgam9pbnRlcyBwZXV2ZW50 IGNvbnRlbmlyIGRlcyBpbmZvcm1hdGlvbnMgY29uZmlkZW50aWVsbGVzIG91IHByaXZpbGVnaWVl cyBldCBuZSBkb2l2ZW50IGRvbmMKcGFzIGV0cmUgZGlmZnVzZXMsIGV4cGxvaXRlcyBvdSBjb3Bp ZXMgc2FucyBhdXRvcmlzYXRpb24uIFNpIHZvdXMgYXZleiByZWN1IGNlIG1lc3NhZ2UgcGFyIGVy cmV1ciwgdmV1aWxsZXogbGUgc2lnbmFsZXIKYSBsJ2V4cGVkaXRldXIgZXQgbGUgZGV0cnVpcmUg YWluc2kgcXVlIGxlcyBwaWVjZXMgam9pbnRlcy4gTGVzIG1lc3NhZ2VzIGVsZWN0cm9uaXF1ZXMg ZXRhbnQgc3VzY2VwdGlibGVzIGQnYWx0ZXJhdGlvbiwKT3JhbmdlIGRlY2xpbmUgdG91dGUgcmVz cG9uc2FiaWxpdGUgc2kgY2UgbWVzc2FnZSBhIGV0ZSBhbHRlcmUsIGRlZm9ybWUgb3UgZmFsc2lm aWUuIE1lcmNpLgoKVGhpcyBtZXNzYWdlIGFuZCBpdHMgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4g Y29uZmlkZW50aWFsIG9yIHByaXZpbGVnZWQgaW5mb3JtYXRpb24gdGhhdCBtYXkgYmUgcHJvdGVj dGVkIGJ5IGxhdzsKdGhleSBzaG91bGQgbm90IGJlIGRpc3RyaWJ1dGVkLCB1c2VkIG9yIGNvcGll ZCB3aXRob3V0IGF1dGhvcmlzYXRpb24uCklmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwg aW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgbWVzc2Fn ZSBhbmQgaXRzIGF0dGFjaG1lbnRzLgpBcyBlbWFpbHMgbWF5IGJlIGFsdGVyZWQsIE9yYW5nZSBp cyBub3QgbGlhYmxlIGZvciBtZXNzYWdlcyB0aGF0IGhhdmUgYmVlbiBtb2RpZmllZCwgY2hhbmdl ZCBvciBmYWxzaWZpZWQuClRoYW5rIHlvdS4KPC9QUkU+PC9ib2R5Pg0KPC9odG1sPg0K --_000_DBE92EC67CF9Bdominiquebarthelorangecom_-- From nobody Mon Nov 30 00:15:27 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC11B3A1103 for ; Mon, 30 Nov 2020 00:15:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 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_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Sh80djGf; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=zlywPcfF 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 bSOA-cpEypry for ; Mon, 30 Nov 2020 00:15:24 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E489F3A1102 for ; Mon, 30 Nov 2020 00:15:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3716; q=dns/txt; s=iport; t=1606724123; x=1607933723; h=from:to:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=kzMZtc85DEjc4dvxpQ2PQ2g2rcpEvsBVjiTyqN1DKU8=; b=Sh80djGfGkvSKkJtR1JhNyXG6IvdDhMkoGWCyCzf9IJCfZPO+LKSYryR d1HlRwFIbbEPCXpVWFOjVgTBnCvsvNmTEeqYRyNgp78/qSMx7yUuG/UYp 1Kc0qfSsFCKyhgJjZLgkKkFeSMVX4Ma45qgAj3nJ0Z+QTgZKveuO2dHbs s=; X-IPAS-Result: =?us-ascii?q?A0AtCQCsqcRffYYNJK1igQmDIVF8Wi8uCoQzg0kDjVqZB?= =?us-ascii?q?oJTA1QLAQEBDQEBJQgCBAEBhEoCF4ISAiU4EwIDAQEBAwIDAQEBAQUBAQECA?= =?us-ascii?q?QYEFAEBhjwBC4VyAQEEARIREQwBATgRAQgRAwECAwImAgQwFQgKBBMign8EA?= =?us-ascii?q?QGCVQMOIAEOoQYCgTyIaXaBMoMEAQEFgkyCOgMVghADBoEOKoJzgmZOQoZXG?= =?us-ascii?q?4FBP4EQASccgicuPoJdAQECAYE+HgcQDxSCXTOCLJN8k0SRLgqCcIkXkhUDH?= =?us-ascii?q?6IUk2WLB5EshDwCBAIEBQIOAQEFgW0hD4FKcBU7KgGCPlAXAg2SEoUUhUR0A?= =?us-ascii?q?gE0AgYKAQEDCXyNaQGBEAEB?= IronPort-PHdr: =?us-ascii?q?9a23=3A9BMKwhxivV5orenXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5ZRWFt/RgkFGPWp/UuLpIiOvT5qbnX2FIoZOMq2sLf5EEUR?= =?us-ascii?q?gZwd4XkAotDI/gawX7IffmYjZ8EJFEU1lorHC2LUYTH9zxNBXep3So5msUHR?= =?us-ascii?q?PyfQN+OuXyHNvUiMK6n+C/8pHeeUNGnj24NLhzNx6x6w7Ws5ob?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,381,1599523200"; d="scan'208";a="626013641" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Nov 2020 08:15:22 +0000 Received: from XCH-ALN-004.cisco.com (xch-aln-004.cisco.com [173.36.7.14]) by alln-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AU8F4bW026437 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 30 Nov 2020 08:15:21 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-004.cisco.com (173.36.7.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 30 Nov 2020 02:15:14 -0600 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 30 Nov 2020 02:15:14 -0600 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 30 Nov 2020 02:15:14 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=BQcQ/8gRqmCf7A5XSUwwMNkbQV3ED/3HsI93mOapkPfH+eGEyniPJcjN7k4iOBKetJptU19oNut5fyHPdqC2jlkgYQzPvbz8BiAt/WZsWx44lOkrcAmJbzFWZXm//uwevOpDNgs+QUZzn4SLS5fGWZ5sWBfaW4PMGsh758zSd0rBQtCzlqjo465tTOWqyr1iPfiQXMpl6NMMbbe8rxa/tLFo7rNGHZav8476UAIul4niUWue6KXTeBxFz2UQexsgrCuetQOHZoTc+zMYvlkn6wuV5mXbot9MDmXFCa4+2jac5OS5ZTLm46ERArUvsrpQadfrhoF8RKTSbUGv71+P8A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=kzMZtc85DEjc4dvxpQ2PQ2g2rcpEvsBVjiTyqN1DKU8=; b=V/1OSlggZTiApaW71hzu41wpL/E3EfLFQtNQYrfIxREo3m/rY5j6j0cOwkUX8hrNVn8pGbcq0ya7RzG+glxgTIcvWCLW/VzPfjYcQ7+QpyPUtaYan4fmyWQFItxsj4dJm9HfkBvgrOcYmciQZOlbpQIVU3QSvm2KYL1LoW7su7NzLLcHhr8XKOJfwX6yLTVYiuZK0CJsM4bDY8GvwtcIuotJg5rkS7j6P0Dt4NEqw6ftdDbn0QeRyY6ryNRIihk7yLtB26aqOe9AWxxP5QOGfp+t2IoAhjyYSs7yX5aDdNJ86P+opYFpI7mtJO2Mjx89w4qpllrZ7dtTb1rLIj6Szw== 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=kzMZtc85DEjc4dvxpQ2PQ2g2rcpEvsBVjiTyqN1DKU8=; b=zlywPcfFAabN/rcqL+plcZE72siIsLvz5YrN7Jt4udIPSJaQhIHeBYEyv7KWiU8kj50GBneoLazPH/yLBHpBL86LynMZQFB/0ayjDWIXY0LkcL7L9eGPTxNdsPDyTVgCexb2iRWfo1mjd1ti8J37PcJ4unS0Ex9RZSfyRjJ77YY= Received: from DM6PR11MB3803.namprd11.prod.outlook.com (2603:10b6:5:141::30) by DM6PR11MB2716.namprd11.prod.outlook.com (2603:10b6:5:c7::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3541.25; Mon, 30 Nov 2020 08:15:13 +0000 Received: from DM6PR11MB3803.namprd11.prod.outlook.com ([fe80::51a2:6f3b:817c:8dc8]) by DM6PR11MB3803.namprd11.prod.outlook.com ([fe80::51a2:6f3b:817c:8dc8%6]) with mapi id 15.20.3611.031; Mon, 30 Nov 2020 08:15:12 +0000 From: "Huimin She (hushe)" To: "roll@ietf.org" Thread-Topic: [Roll] Error flows, which ICMP errors and to which root Thread-Index: AQHWxvDsqJzT1olGwECZKYhlRsF+1A== Date: Mon, 30 Nov 2020 08:15:12 +0000 Message-ID: <26D2BCD1-D47E-46CA-9F3E-781A17A60398@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/16.39.20071300 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [64.104.125.237] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 659633bb-ce44-40ca-f0af-08d895080fbb x-ms-traffictypediagnostic: DM6PR11MB2716: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: A/TZO+6Xt+qfSG2PhWSyS+w/lx99Z8Ca86c4OHPwY6huk5qooKCH4YTkUDRNFQmDZC1JkREnIMO3z3MfR+L40tgzCB1k47+R7Drjm34a4urbBb8cK0Kdzrbef/eF7LoKAEtLAJa3VtT/l223OewcmxmWMs5L4HfK+pvqT6YaP3euhPtgqitbj63RoylL+uO259AZNsPM8Mm5rHxWOvqM8/LMJytjMSsU1BWOey/xx4ZbNBVfEOkRCJGg7GKv/0x7VEhdjqEXG/MHVxQAI9jjFcVMJSh1b3FqYKhwnJlAS9D1M+8EyM/PK088K8rOyMf7mZRWSfUFn4HBqqAzVjU4Upvq5fwWj4hNZJi0WFVB0RXXgeZHOwgRN3vs/Of0uT3ik6JXDM0PvgAaQp+3J2RJMQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DM6PR11MB3803.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(396003)(346002)(136003)(366004)(376002)(39860400002)(66556008)(86362001)(26005)(83380400001)(6512007)(186003)(33656002)(2616005)(71200400001)(316002)(36756003)(478600001)(66446008)(2906002)(64756008)(76116006)(8676002)(6916009)(91956017)(8936002)(66476007)(66946007)(5660300002)(6486002)(53546011)(6506007); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?UXdUbnl2YjR0SmRCcVZoUWtFcDBqQ1U2STJWb1hKS3ovVmlvWjZKL0xVU3Zs?= =?utf-8?B?a21CUEQwUkprRURNQ0JmRkJjK3JXanhpNUlOak5VcHpxa25zREticTZnbGZk?= =?utf-8?B?U0RnQUQrdkc0b2NsR050NnFabFVwdG84ejBQdHdTOEd5SGNEOHVockVxOFN5?= =?utf-8?B?ZlF2Lzdpd3J1ejJGNEJkWWgrNG15am1EdmxUcG52Ni81akZHaUlJQVBXTEts?= =?utf-8?B?ODZRUjRoenhQWmZSd0JlWXB0SUY1MWlwVnhtbzZkQm1CeGNaSnErSHJCMERx?= =?utf-8?B?cFF2a2pHa2ZTVGVocEo0ZzQwZXdSN2RhT3JoVWZxbGlMa2luQ1lYbXRsSFhF?= =?utf-8?B?eWdaWDZtelFMRE03N2dWSm9hT1R3S242WGtHakZaM0VKUElucXYvQUJhNWI3?= =?utf-8?B?ck11WUNtWUNSQXJzYXp5Sk54eUZXOHhSWDczcHhlRlMrUVNiVlNsMitGVHl5?= =?utf-8?B?RnJDNGhiRStZQ1RtWm9yaitLSjNnQzg5Q1NKeC9NcjFLa3k3dVFmQ0xBa25n?= =?utf-8?B?Q1ZyYXRVdEhqa1BJeHBqUTNIVzFRTDk3VkdXL2RiN2tzeXE2aXllb1YwMXRU?= =?utf-8?B?cHd5UkllcUlEeDJnVzdXSTR5RGFoeXd3YTRWNzRndkNPbHZqMGhkQ0VTNlMw?= =?utf-8?B?bWw1VE41Q3R1cFdqSWpDbGJ3d0ZHejM4S0tEL0tCN2lEQVIzMyswaWI4U05R?= =?utf-8?B?Zitjc3ZKUy9KUHgrb2pxUjJvNUEycENvdW1tNmNFVzNxaEs0SkV0ek9kbVNC?= =?utf-8?B?bFh0b1hVendjQzVTOWtJNGVEVkgra2lyUy9jaUczeE1lMG9PR2JCamJpdnZ6?= =?utf-8?B?dkErbUM0TnBTMDFGSjFRdWJIcUg2NGE1TVB3ZmNSMHZyTHVyNUpGQjdXL1lO?= =?utf-8?B?TFFVanE0UVVLeXVPU1k4dDV5a0dnaW04WEdJclhOWitUWGpQbjljWk5FNmFQ?= =?utf-8?B?bUhESDBTQkxoSVVCRWZKS201TnNCTmJEV004dlc4QTNMNGorYnhEZ3VkOE0v?= =?utf-8?B?Wmt6QU9ZQ3lZUnZKY0ZkTlI4azVIMmd1Vk5YY0pSbXJRMEJRN0ZyeEJEZkdz?= =?utf-8?B?dHJIREI2ZWI1TTFMb1BzVENZbFZrL1BlYXpjWW1ITmF4THpNV3duazh3L3pm?= =?utf-8?B?dGk0UkE1elNJSVBLeVpkNkxBQ1A1V0V1d1FhYk1RcmVMWFptYllkNjRTNG1h?= =?utf-8?B?ZW1HbDcxVUJjb2wxcjREc0FienAva2FINTllNEQ5YjE0SXdkM3Fuc3VybTlD?= =?utf-8?B?UGdTaHpzaGVReXJyQmc3V09hdWh3YVNUdlhCOHdSeEQ5d1hnS3o1b05wL3J4?= =?utf-8?Q?6oegPmWdgY+HgFZ22gXQ0i8CirGbO3cVDw?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <1923136AF180C0448CA03341B02BC1D8@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: DM6PR11MB3803.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 659633bb-ce44-40ca-f0af-08d895080fbb X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Nov 2020 08:15:12.7478 (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: SXCb3zCA8ch6Smd2uwNmOz3PpQQ64L/2i9V/dfD4NjfKHihbVJ2hXYMkbnhyAGwT X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR11MB2716 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.14, xch-aln-004.cisco.com X-Outbound-Node: alln-core-12.cisco.com Archived-At: Subject: Re: [Roll] Error flows, which ICMP errors and to which root 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, 30 Nov 2020 08:15:26 -0000 SGkgUGFzY2FsLA0KDQpSRkMgNjU1MCBzZWN0aW9uIDExLjEgc2F5cyB0aGUgSUNNUHY2IGVycm9y IGluIFNSSCBzaG91bGQgYmUgc2VudCB0byB0aGUgc291cmNlIG9mIHRoZSBwYWNrZXQuDQoNCkJl c3QgcmVnYXJkcywNCkh1aW1pbg0KDQogICAgTWVzc2FnZTogMg0KICAgIERhdGU6IEZyaSwgMjcg Tm92IDIwMjAgMDc6NDc6MjIgKzAwMDANCiAgICBGcm9tOiAiUGFzY2FsIFRodWJlcnQgKHB0aHVi ZXJ0KSIgPHB0aHViZXJ0QGNpc2NvLmNvbT4NCiAgICBUbzogUm91dGluZyBPdmVyIExvdyBwb3dl ciBhbmQgTG9zc3kgbmV0d29ya3MgPHJvbGxAaWV0Zi5vcmc+DQogICAgU3ViamVjdDogW1JvbGxd IEVycm9yIGZsb3dzLCB3aGljaCBJQ01QIGVycm9ycyBhbmQgdG8gd2hpY2ggcm9vdD86DQogICAg CVtleHRlbmRzXSBJRVRGIDEwOSBvcGVuIFF1ZXN0aW9ucyBvbiBQLURBTw0KICAgIE1lc3NhZ2Ut SUQ6DQogICAgCTxDTzFQUjExTUI0ODgxQTcyNEIwNEVBMjlEMzJEQzlDODFEOEY4MEBDTzFQUjEx TUI0ODgxLm5hbXByZDExLnByb2Qub3V0bG9vay5jb20+DQoNCiAgICBDb250ZW50LVR5cGU6IHRl eHQvcGxhaW47IGNoYXJzZXQ9InVzLWFzY2lpIg0KDQogICAgSGVsbG8gTGkNCg0KICAgIFRoaXMg aXMgdGhlIHdyb25nIHRocmVhZC4gSSBjcmVhdGVkIGEgbmV3IG9uZS4NCg0KICAgID4gU2VjdGlv biA3Ljkgb2YgcGRhby1kcmFmdCBkZWZpbmVzIGEgbmV3IGNvZGUgZm9yICBJQ01QdjYgZXJyb3Ig bWVzc2FnZSAiRXJyb3IgaW4gUHJvamVjdGVkIFJvdXRlIi4gRG9lcyBpdCBvbmx5IHdvcmsgZm9y IElDTVAgZXJyb3JzIHNlbnQgdG8gdGhlIG1haW4gUm9vdD8NCg0KICAgIFNlY3Rpb24gNSBzYXlz ICINCg0KDQogICAgICAgSW4gY2FzZSBvZiBhIGZvcndhcmRpbmcgZXJyb3IgYWxvbmcgYSBQcm9q ZWN0ZWQgUm91dGUsIGFuIElDTVAgZXJyb3INCg0KICAgICAgIGlzIHNlbnQgdG8gdGhlIFJvb3Qg d2l0aCBhIG5ldyBDb2RlICJFcnJvciBpbiBQcm9qZWN0ZWQgUm91dGUiIChTZWUNCg0KICAgICAg IFNlY3Rpb24gNy45PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJvbGwt ZGFvLXByb2plY3Rpb24tMTQjc2VjdGlvbi03Ljk+KS4gIFRoZSBSb290IGNhbiB0aGVuIG1vZGlm eSBvciByZW1vdmUgdGhlIFByb2plY3RlZA0KDQogICAgICAgUm91dGUuICBUaGUgIkVycm9yIGlu IFByb2plY3RlZCBSb3V0ZSIgbWVzc2FnZSBoYXMgdGhlIHNhbWUgZm9ybWF0IGFzDQoNCiAgICAg ICB0aGUgIkRlc3RpbmF0aW9uIFVucmVhY2hhYmxlIE1lc3NhZ2UiLCBhcyBzcGVjaWZpZWQgaW4g UkZDIDQ0NDM8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzQ0NDM+DQoNCiAgICAgICBb UkZDNDQ0MzxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDQ0Mz5dLg0KDQogICAgIg0K DQogICAgU28geWVzIHRoZSBpbnRlbnRpb24gd2FzIHRvIHNlbmQgdGhlIElDTVAgdG8gdGhlIG1h aW4gUm9vdC4gQnV0IGFzIHlvdSBwb2ludCBvdXQgdGhlIHBhY2tldCBkb2VzIG5vdCBpbmRpY2F0 ZSBpdCBpcyBmb2xsb3dpbmcgYSBQLXJvdXRlLiBUaGlzIHdhcyByZWxhdGVkIHRvIHN0b3Jpbmcg bW9kZSBQIERBTy4gSW4gbm9uLXN0b3JpbmcgdGhlIG5vZGUgZG9lcyBub3Qga25vdyBpdCdzIGEg UC1yb3V0ZS4NCg0KDQogICAgPiBJbiBub24tc3RvcmluZyBQREFPLCBmb3J3YXJkZXIgY2FuJ3Qg cmVjb2duaXplIHdoZXRoZXIgZGF0YSBwYWNrZXQgaXMgaW4gUERBTyBpbnN0YW5jZS4gRm9yd2Fy ZGVyIHNob3VsZCBzZW5kIElDTVAgRGVzdGluYXRpb24gVW5yZWFjaGFibGUgZXJyb3IgdG8gcm9v dCAodGhlIHNvdXJjZSBvZiB0aGUgcGFja2V0KSwgdGhlbiByb290IGdlbmVyYXRlcyBJQ01QdjYg ZXJyb3IgbWVzc2FnZSB3aXRoICJFcnJvciBpbiBQcm9qZWN0ZWQgUm91dGUiIHRvIG1haW4gUm9v dC4gIElzIGl0IGNvcnJlY3Q/DQoNCiAgICBUaGF0IHdvdWxkIHdvcmsuIFNlZW1zIG5lYXQuIFRo ZSBhbHRlcm5hdGUgd291bGQgYmUgdG8gc2lnbmFsIGl0IGlzIGEgUCByb3V0ZSBpbiB0aGUgUlBJ LiBUaGF0J3MgaXRlbSAyKSBpbiB0aGUgbGlzdCBpbiB0aGlzIHRocmVhZC4gSWYgd2UgZG8gdGhh dCB0aGUgY3VycmVudCB0ZXh0IHdvcmtzLiBXaGF0IG1ha2VzIG1vcmUgc2Vuc2UgdG8geW91Pw0K DQogICAgPiBJbiBzdG9yaW5nIFBEQU8sIGZvcndhcmRlciBjYW4gcmVjb2duaXplIHRoZSBQREFP IGluc3RhbmNlIGZyb20gdGhlIFJQSS4gSXQgY2FuIHNlbmQgIkVycm9yIGluIFByb2plY3RlZCBS b3V0ZSIgb3IgICJEZXN0aW5hdGlvbiBVbnJlYWNoYWJsZSBlcnJvciIgdG8gcm9vdC4gTWF5YmUg d2UgbmVlZCBtb3JlIGNsYWltcyBmb3Igd2hpY2ggY29kZSBmb3J3YXJkZXIgc2hvdWxkIHVzZS4N Cg0KICAgIFdlIGhhdmUgdG8gZGVjaWRlIGlmIHdlIHNlbmQgaXQgdG8gdGhlIG1haW4gcm9vdCBh cyB3cml0dGVuIGluIHRoZSBjdXJyZW50IGRyYWZ0IG9yIHRvIHRoZSBUcmFjayBSb290LiBJZiB0 aGUgUCByb3V0ZSBpcyByZXZlcnNpYmxlIGNvdWxkIGJlIGRvbmUgdGhhdCB3YXkuIEJ1dCB0aGF0 J3MgYWRkZWQgY29tcGxleGl0eS4gSSdtIG5vdCB2ZXJ5IGNvbnZpbmNlZCBlaXRoZXIgd2F5LiBU aGUgT2toYW0gcmF6b3IgY291bGQgYmUgdG8gZG8gdGhlIHNpbXBsZXN0Lg0KDQogICAgS2VlcCBz YWZlIQ0KDQogICAgUGFzY2FsDQoNCg0KICAgIA0KDQoNCg== From nobody Mon Nov 30 01:27:56 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B77BE3A1187 for ; Mon, 30 Nov 2020 01:27:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.601 X-Spam-Level: X-Spam-Status: No, score=-9.601 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_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=OfMecleo; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=A1q9jVlY 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 p65TH_0uTVk9 for ; Mon, 30 Nov 2020 01:27:53 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC29B3A1103 for ; Mon, 30 Nov 2020 01:27:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5034; q=dns/txt; s=iport; t=1606728472; x=1607938072; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=8IBZXoLaVO+cAC82I6LzOfZvt3/HI9v1cwbrXzwBr3s=; b=OfMecleoz1HpL4pv2RHXEDXciHXp6dPJ25iRKHSgDBH01uQxaSFW5ZSG 9hg2Tdl25E1lPbRHYH1gMiPYrGIouCO8SIFI7tlY+ZeW4D9o3dbgfTU5C 2nU0pHngnX4DJnFPvLS74Z0M7KGnOV0+PwLcpiP0wVQv9b9bS8pv8veiO E=; X-IPAS-Result: =?us-ascii?q?A0DpCABbuMRffYwNJK1cBoEJgyEjLnxaLy6EPYNJA41am?= =?us-ascii?q?QaBQoERA1QLAQEBDQEBGA0IAgQBAYRKAheCEgIlOBMCAwEBAQMCAwEBAQEFA?= =?us-ascii?q?QEBAgEGBBQBAYY8DIVyAQEBAwEBARAREQwBASwMBAsCAQgRAwECAwImAgICJ?= =?us-ascii?q?QsVCAgCBBMign8EAQGCVQMOIAEOoQwCgTyIaXaBMoMEAQEFgkyCOAMVghADB?= =?us-ascii?q?oEOKoJzgmZOQoZXG4FBP4EQASccgicuPoJdAQECAYEeIA4QBxAPFIJdM4Isk?= =?us-ascii?q?3ykcgqCcIkXkhUDH4Mdih2UWpVniQWRLIQ8AgQCBAUCDgEBBYFtIQ+BSnAVO?= =?us-ascii?q?yoBgj5QFwINkhKFFIVEdAIBNAIGAQkBAQMJfI56AQE?= IronPort-PHdr: =?us-ascii?q?9a23=3Au0SoihWxMUmMePJ/+SfdD6EibkXV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSBNyBufNJl+SQtLrvCiQM4peE5XYFdpEEFx?= =?us-ascii?q?oIkt4fkAFoBsmZQVb6I/jnY21ffoxCWVZp8mv9PR1TH8DzNFzfvnP06iQdSV?= =?us-ascii?q?3zMANvLbHzHYjfx828y+G1/cjVZANFzDqwaL9/NlO4twLU48IXmoBlbK02z0?= =?us-ascii?q?jE?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,381,1599523200"; d="scan'208";a="622821643" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Nov 2020 09:27:51 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by alln-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 0AU9Rpjr009941 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Mon, 30 Nov 2020 09:27:51 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 30 Nov 2020 03:27:51 -0600 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 30 Nov 2020 03:27:51 -0600 Received: from NAM12-BN8-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 30 Nov 2020 04:27:50 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ZJ3auRMM3X3knEU1YR+Eckwjx7UCoM/K0XmtwqRObIwMxOQHkVerOlD3tF+Va8N1WVdT9EaxG0+yj8gUSPo7/btHzlu5fzWxRdsW9HPiiKMLh+lXfGlk8DvgDeUWCoYhU7xGu5nMChR69a75MkcY8DVOUxSIlSDYbJmnNtZm3Axiwm5J5kPqTEFQZGYeteOE+09pfJehujNUWKoQgV6Wu0OUXZraAoVGUjLz9HDDKp97+5FkY+43NWG55EnmtQy6jFv7LOZ7OnyUSjQZu+UP8aR6b+DAHstPhEa2F1Rcs1LeSPfXcoj1ZeXXkHK1LyJoNFmbxiTBXeVJvcq5hP7XnQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8IBZXoLaVO+cAC82I6LzOfZvt3/HI9v1cwbrXzwBr3s=; b=LGUpbefvzWj5zIZF8J/rqVy+KsYDN23LrYWKEpsFZSllyCNNmixnAsJYBjj7TA7IKeFnBQMCybeYuKKk59D9Fu2QzVcr4X7G6IJwQ/hkiJ5EzwhP/ZNEhmI8B/Do1sJJ6JtT4RzaAeE8FmqUYANhW4/9ACX4k3+Gj5tZWeXmekb7k0hh0sHv729XN8Qr8BnKwYI0sMo3inEUU57Ykz3crkBNrSGDrWCgGLj9ZytbuMGeWgu1OGwAQvuXGLouRvy+j5fUoeqnJylrPTfihHEGr7pJRrTNEDJspyW6/Q4TZzA8VWwWt/ep4IbBhJvSfP0c7NVitF6f/LrXsSBk7M1qng== 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=8IBZXoLaVO+cAC82I6LzOfZvt3/HI9v1cwbrXzwBr3s=; b=A1q9jVlY0gD0Jb9t7oOWvD14C0LNkwWXWHDllhL3LX1skHYTmmvQ9DOfm6yFuyiYzexxOOFkuAglWvemSPlvg1ZY+xGoF3I0gxjqJ9wHdvW/50oCd8krv1ys68+s1r3/H2/eNobweY0rqjTnudJogJoxRGH2+8MpmFtUrlgnxFk= Received: from PH0PR11MB4885.namprd11.prod.outlook.com (2603:10b6:510:35::14) by PH0PR11MB5190.namprd11.prod.outlook.com (2603:10b6:510:3c::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.23; Mon, 30 Nov 2020 09:27:50 +0000 Received: from PH0PR11MB4885.namprd11.prod.outlook.com ([fe80::d9d7:eaa0:34c9:91ee]) by PH0PR11MB4885.namprd11.prod.outlook.com ([fe80::d9d7:eaa0:34c9:91ee%7]) with mapi id 15.20.3611.025; Mon, 30 Nov 2020 09:27:49 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] Error flows, which ICMP errors and to which root Thread-Index: AQHWxvDsqJzT1olGwECZKYhlRsF+1KngaEJH Date: Mon, 30 Nov 2020 09:27:49 +0000 Message-ID: References: <26D2BCD1-D47E-46CA-9F3E-781A17A60398@cisco.com> In-Reply-To: <26D2BCD1-D47E-46CA-9F3E-781A17A60398@cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2a01:cb1d:4ec:2200:f4a1:d1aa:16a1:765a] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a4238485-f596-46f5-8d00-08d8951234c1 x-ms-traffictypediagnostic: PH0PR11MB5190: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 0QCsBIFFqiM5rNC4awOpb6tZFSBpT/XlXoyYsDVdUbAg4kAfLenHJj6CrSB6xXcBD3S9xT+XkKZKfOyVpneIfgbBY0X+l2Bf1opV+0OAiHdlW7WiLRBROUeY/sSjY2Z4b0srt10KCH//7QHOuRLw5ml9xIccMCxrDUYvUjvB6Z2tPFavS/RSwIFP2q+884ZnmgYe68IVx3GYtDTeW56itMeaFvtHwVneKZnApmY0iBFAzZZB9/P15DuNufhEKjT+Nyj25fe6B7u9emxck6A6kc0EIGxD3xEoVHnEQbeyfSqTSBySXkMbExkuN1bG+GpGu6lU2UUqQbEf2PrjwoXEUsBkq4DQJJQt3xalmuQOWbwM43PX+kIcTObfqrDQLFeejPoLc7/XwxIUYS88M9eYpA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB4885.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(376002)(366004)(136003)(39860400002)(396003)(346002)(6512007)(53546011)(66446008)(66556008)(186003)(2616005)(6506007)(91956017)(64756008)(76116006)(6486002)(66476007)(86362001)(66946007)(83380400001)(8676002)(66574015)(316002)(6916009)(5660300002)(36756003)(8936002)(71200400001)(478600001)(33656002)(2906002)(966005); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?QW5NU2IrMWFJd1RYZW5MbFR3VnpXbGxlK0x5TzN2eC9pT0xPY1A1MEo4RnBH?= =?utf-8?B?elhKWlV0SFQyazRtTjl3NG5wYm1GdFR1WUM2MCszc1JSdnBHd1p4YmVaK01x?= =?utf-8?B?VFFQUXh3ekVNcGcrSTBkZjNMTmFhZ1FudDArZndzZ3BQMlhnYUlKbktZeXdC?= =?utf-8?B?TnNUb3hHMklueHF0ZkhleVlSUUhOVGl4Ykh0Q0MxSXllL003djNXM3FjUzl3?= =?utf-8?B?b3VzbXMrWHNkaWRVUDZVM0JNRzZrSFZFU0txbVprMTNvNjlHb3VUYVg3L0Ev?= =?utf-8?B?SjE2WnN4UkUwZHBwNk9OZHM3YTkvMytvVzE4a3dvYlZySjFQZWxyaGpsc0dl?= =?utf-8?B?SWdHWllyVnZ1MitaZXpHc3M1TTVuSG1nQ1RBdmVGTXVSYTFUdzNNckxBR1g0?= =?utf-8?B?aUxNSUUrTmVBUnp6cjBRZVZySVVia3pNVkozanVyZzhodUNQY3BvMitoUlI1?= =?utf-8?B?c3pBTDFQY3FMR1JuNTlvdDZ2U1BTSmlQUUVURnNjMlJPaWNuS0NXb25OMHpB?= =?utf-8?B?eTFoUTNJZ3JUaEphUUYzS3RCRDBIYzZvM3JpcFUyZTdWK0ZpN2N3bWc4ZXk0?= =?utf-8?B?L1JGMzh6WW9Uay96SEdkVTh2aUhBQXIvaHpUOW54Sy90OTFDOHJsT2dCQWhH?= =?utf-8?B?alF5M3g0Yk5NZnVPODlmYmVsaGJRRm91RFU0Q1ptMzdqNDhtTWdvYkpremVy?= =?utf-8?B?STVnaDhWaEc4MlUrcWtDcTk0WnFaSGJrcjI4RUR6VW5vY3orY2dWV3R2b3dv?= =?utf-8?B?RjdYT3p4cTdkUi9vM0tzVU9CenNEdUQ3UkV1V0o0NVF6TEN3SForeWpPcWxM?= =?utf-8?B?UXZLWUd5VnA3QWlwbWxveHE4cnVra0ZoQjlVakxuN2g5STdOMWZLUjVCeGZ2?= =?utf-8?B?cDdaZmt6L0ttbCtocTJmU2t6ci90cEdhK3FaZUNuTmV1anRSWGJ3U1NDbzRB?= =?utf-8?B?R1MwOFRCNE9KdlFGcnJEZVRUdFEvdnFGOEdmN2RMQ3ZOend5Y0wvdG0rbVF5?= =?utf-8?B?eHlEbVJ3Y215SHlUa0ZIRHY3bVJnOXorZ0ZWMzJmeEg2SzU1Z0U2SXM4dDJG?= =?utf-8?B?MW5LYjRrL3p5dUNSbVhRT1dHcDkzVVNPNmx4WElCNC85MURiaDlMMDg4QmNs?= =?utf-8?B?VmFCVDdxOUcycEdHZFR5ZXBxcWlkUnhQeG9pWndwMzZzUEdiRTZaOTVvMDhz?= =?utf-8?B?aGZFZnYza0NqWWdMTnBHK3RnODBzVnpISGpRK3RGM0k1VEorSldscytqUVBy?= =?utf-8?B?c2pwdTd1T2RobytJbnZmREhnNE95WlRCYnRORUEzT2tWQVJlTWQ0ZWorcTVB?= =?utf-8?B?d2tPVmRrODFzNWFGN0oxVVQ3aklmVU5aQm81Qzk2aDNlQk5ma084aXR3ZXZN?= =?utf-8?B?cnhXLzlsUG1BQUVWbHd2d0FrSFpJQlhGUDhwZjViUjFUQ1JCY1g1eU9JTmZ6?= =?utf-8?Q?68ge9W2l?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4885.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: a4238485-f596-46f5-8d00-08d8951234c1 X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Nov 2020 09:27:49.8839 (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: b9hy0+dPHoPTAqJCpuvnU5/W3eQ3Sdki+EBFxBZRt4mINsN50H4zQqsnTIHWZmgk9LCIJDFdtPWhenDyPOdlpQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB5190 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: alln-core-7.cisco.com Archived-At: Subject: Re: [Roll] Error flows, which ICMP errors and to which root 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, 30 Nov 2020 09:27:55 -0000 WWVzIEh1aW1pbg0KDQpBbmQgdGhpcyBpcyB0aGUgbm9ybWFsIGJlaGF2aW9yLg0KDQpXaXRoIFBE QU8gd2UgY3JlYXRlZCB0aGUgdW51c3VhbCBiZWhhdmlvciB0byBzZW5kIHRoZSBlcnJvciBpbiBw LXJvdXRlIHRvIHRoZSByb290LiBUaGlzIHdhcyB0byBtYWtlIHRoaW5ncyBmYXN0ZXIgc2luY2Ug dGhlIGNvbW11bmljYXRpb24gdGhyb3VnaCB0aGUgVHJhY2sgaXMgZGlyZWN0aW9uYWwgc28geW91 IGNhbm5vdCB0YWxrIGJhY2suIEFsc28gaW4gbm9uIHN0b3JpbmcgdGFsa2luZyB0byB0aGUgc291 cmNlIGlzIHZpYSB0aGUgUm9vdCBhbmQgdWx0aW1hdGVseSB0aGUgUm9vdCBuZWVkcyB0byB1cGRh dGUgdGhlIFAgREFPLg0KDQpXaXRoIFJBVyB3ZSBtYXkgd2FudCB0byB0byBzb21ldGhpbmcgZmFz dGVyIGJ1dCB1bmNsZWFyIGZvciBub3cuDQoNClBsZWFzZSBub3RlIHRoYXQgYWZ0ZXIgdGhlIGRp c2N1c3Npb24gd2l0aCB5b3UgYW5kIExpIEkgcHVibGlzaGVkIGEgcmV2aXNpb24gdGhhdCBoYXMg dGhlIGZsYWcgaW4gdGhlIFJQSSB0aGF0IGluZGljYXRlcyB0aGF0IHRoZSBwYWNrZXQgaXMgZm9y d2FyZGVkIG9uIGEgUC1yb3V0ZS4NCg0KRG8geW91IHdhbnQgdG8gY2hhbmdlIHRoZSBlcnJvciBm bG93Pw0KDQpQYXNjYWwNCg0KPiBMZSAzMCBub3YuIDIwMjAgw6AgMDk6MTUsIEh1aW1pbiBTaGUg KGh1c2hlKSA8aHVzaGU9NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmc+IGEgw6ljcml0IDoNCj4g DQo+IO+7v0hpIFBhc2NhbCwNCj4gDQo+IFJGQyA2NTUwIHNlY3Rpb24gMTEuMSBzYXlzIHRoZSBJ Q01QdjYgZXJyb3IgaW4gU1JIIHNob3VsZCBiZSBzZW50IHRvIHRoZSBzb3VyY2Ugb2YgdGhlIHBh Y2tldC4NCj4gDQo+IEJlc3QgcmVnYXJkcywNCj4gSHVpbWluDQo+IA0KPiAgICBNZXNzYWdlOiAy DQo+ICAgIERhdGU6IEZyaSwgMjcgTm92IDIwMjAgMDc6NDc6MjIgKzAwMDANCj4gICAgRnJvbTog IlBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkiIDxwdGh1YmVydEBjaXNjby5jb20+DQo+ICAgIFRv OiBSb3V0aW5nIE92ZXIgTG93IHBvd2VyIGFuZCBMb3NzeSBuZXR3b3JrcyA8cm9sbEBpZXRmLm9y Zz4NCj4gICAgU3ViamVjdDogW1JvbGxdIEVycm9yIGZsb3dzLCB3aGljaCBJQ01QIGVycm9ycyBh bmQgdG8gd2hpY2ggcm9vdD86DQo+ICAgICAgICBbZXh0ZW5kc10gSUVURiAxMDkgb3BlbiBRdWVz dGlvbnMgb24gUC1EQU8NCj4gICAgTWVzc2FnZS1JRDoNCj4gICAgICAgIDxDTzFQUjExTUI0ODgx QTcyNEIwNEVBMjlEMzJEQzlDODFEOEY4MEBDTzFQUjExTUI0ODgxLm5hbXByZDExLnByb2Qub3V0 bG9vay5jb20+DQo+IA0KPiAgICBDb250ZW50LVR5cGU6IHRleHQvcGxhaW47IGNoYXJzZXQ9InVz LWFzY2lpIg0KPiANCj4gICAgSGVsbG8gTGkNCj4gDQo+ICAgIFRoaXMgaXMgdGhlIHdyb25nIHRo cmVhZC4gSSBjcmVhdGVkIGEgbmV3IG9uZS4NCj4gDQo+PiBTZWN0aW9uIDcuOSBvZiBwZGFvLWRy YWZ0IGRlZmluZXMgYSBuZXcgY29kZSBmb3IgIElDTVB2NiBlcnJvciBtZXNzYWdlICJFcnJvciBp biBQcm9qZWN0ZWQgUm91dGUiLiBEb2VzIGl0IG9ubHkgd29yayBmb3IgSUNNUCBlcnJvcnMgc2Vu dCB0byB0aGUgbWFpbiBSb290Pw0KPiANCj4gICAgU2VjdGlvbiA1IHNheXMgIg0KPiANCj4gDQo+ ICAgICAgIEluIGNhc2Ugb2YgYSBmb3J3YXJkaW5nIGVycm9yIGFsb25nIGEgUHJvamVjdGVkIFJv dXRlLCBhbiBJQ01QIGVycm9yDQo+IA0KPiAgICAgICBpcyBzZW50IHRvIHRoZSBSb290IHdpdGgg YSBuZXcgQ29kZSAiRXJyb3IgaW4gUHJvamVjdGVkIFJvdXRlIiAoU2VlDQo+IA0KPiAgICAgICBT ZWN0aW9uIDcuOTxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1yb2xsLWRh by1wcm9qZWN0aW9uLTE0I3NlY3Rpb24tNy45PikuICBUaGUgUm9vdCBjYW4gdGhlbiBtb2RpZnkg b3IgcmVtb3ZlIHRoZSBQcm9qZWN0ZWQNCj4gDQo+ICAgICAgIFJvdXRlLiAgVGhlICJFcnJvciBp biBQcm9qZWN0ZWQgUm91dGUiIG1lc3NhZ2UgaGFzIHRoZSBzYW1lIGZvcm1hdCBhcw0KPiANCj4g ICAgICAgdGhlICJEZXN0aW5hdGlvbiBVbnJlYWNoYWJsZSBNZXNzYWdlIiwgYXMgc3BlY2lmaWVk IGluIFJGQyA0NDQzPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0NDQzPg0KPiANCj4g ICAgICAgW1JGQzQ0NDM8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzQ0NDM+XS4NCj4g DQo+ICAgICINCj4gDQo+ICAgIFNvIHllcyB0aGUgaW50ZW50aW9uIHdhcyB0byBzZW5kIHRoZSBJ Q01QIHRvIHRoZSBtYWluIFJvb3QuIEJ1dCBhcyB5b3UgcG9pbnQgb3V0IHRoZSBwYWNrZXQgZG9l cyBub3QgaW5kaWNhdGUgaXQgaXMgZm9sbG93aW5nIGEgUC1yb3V0ZS4gVGhpcyB3YXMgcmVsYXRl ZCB0byBzdG9yaW5nIG1vZGUgUCBEQU8uIEluIG5vbi1zdG9yaW5nIHRoZSBub2RlIGRvZXMgbm90 IGtub3cgaXQncyBhIFAtcm91dGUuDQo+IA0KPiANCj4+IEluIG5vbi1zdG9yaW5nIFBEQU8sIGZv cndhcmRlciBjYW4ndCByZWNvZ25pemUgd2hldGhlciBkYXRhIHBhY2tldCBpcyBpbiBQREFPIGlu c3RhbmNlLiBGb3J3YXJkZXIgc2hvdWxkIHNlbmQgSUNNUCBEZXN0aW5hdGlvbiBVbnJlYWNoYWJs ZSBlcnJvciB0byByb290ICh0aGUgc291cmNlIG9mIHRoZSBwYWNrZXQpLCB0aGVuIHJvb3QgZ2Vu ZXJhdGVzIElDTVB2NiBlcnJvciBtZXNzYWdlIHdpdGggIkVycm9yIGluIFByb2plY3RlZCBSb3V0 ZSIgdG8gbWFpbiBSb290LiAgSXMgaXQgY29ycmVjdD8NCj4gDQo+ICAgIFRoYXQgd291bGQgd29y ay4gU2VlbXMgbmVhdC4gVGhlIGFsdGVybmF0ZSB3b3VsZCBiZSB0byBzaWduYWwgaXQgaXMgYSBQ IHJvdXRlIGluIHRoZSBSUEkuIFRoYXQncyBpdGVtIDIpIGluIHRoZSBsaXN0IGluIHRoaXMgdGhy ZWFkLiBJZiB3ZSBkbyB0aGF0IHRoZSBjdXJyZW50IHRleHQgd29ya3MuIFdoYXQgbWFrZXMgbW9y ZSBzZW5zZSB0byB5b3U/DQo+IA0KPj4gSW4gc3RvcmluZyBQREFPLCBmb3J3YXJkZXIgY2FuIHJl Y29nbml6ZSB0aGUgUERBTyBpbnN0YW5jZSBmcm9tIHRoZSBSUEkuIEl0IGNhbiBzZW5kICJFcnJv ciBpbiBQcm9qZWN0ZWQgUm91dGUiIG9yICAiRGVzdGluYXRpb24gVW5yZWFjaGFibGUgZXJyb3Ii IHRvIHJvb3QuIE1heWJlIHdlIG5lZWQgbW9yZSBjbGFpbXMgZm9yIHdoaWNoIGNvZGUgZm9yd2Fy ZGVyIHNob3VsZCB1c2UuDQo+IA0KPiAgICBXZSBoYXZlIHRvIGRlY2lkZSBpZiB3ZSBzZW5kIGl0 IHRvIHRoZSBtYWluIHJvb3QgYXMgd3JpdHRlbiBpbiB0aGUgY3VycmVudCBkcmFmdCBvciB0byB0 aGUgVHJhY2sgUm9vdC4gSWYgdGhlIFAgcm91dGUgaXMgcmV2ZXJzaWJsZSBjb3VsZCBiZSBkb25l IHRoYXQgd2F5LiBCdXQgdGhhdCdzIGFkZGVkIGNvbXBsZXhpdHkuIEknbSBub3QgdmVyeSBjb252 aW5jZWQgZWl0aGVyIHdheS4gVGhlIE9raGFtIHJhem9yIGNvdWxkIGJlIHRvIGRvIHRoZSBzaW1w bGVzdC4NCj4gDQo+ICAgIEtlZXAgc2FmZSENCj4gDQo+ICAgIFBhc2NhbA0KPiANCj4gDQo+IA0K PiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+IFJvbGwgbWFpbGluZyBsaXN0DQo+IFJvbGxAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsDQo= From nobody Mon Nov 30 05:29:02 2020 Return-Path: X-Original-To: roll@ietf.org Delivered-To: roll@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D7B83A0AB8; Mon, 30 Nov 2020 05:28:57 -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.23.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: roll@ietf.org Message-ID: <160674293712.9006.6947929548588804311@ietfa.amsl.com> Date: Mon, 30 Nov 2020 05:28:57 -0800 Archived-At: Subject: [Roll] I-D Action: draft-ietf-roll-rpl-observations-05.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, 30 Nov 2020 13:28:57 -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 : RPL Observations Authors : Rahul Arvind Jadhav Rabi Narayan Sahoo Yuefeng Wu Filename : draft-ietf-roll-rpl-observations-05.txt Pages : 20 Date : 2020-11-30 Abstract: This document describes RPL protocol design issues, various observations and possible consequences of the design and implementation choices. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-roll-rpl-observations/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-roll-rpl-observations-05 https://datatracker.ietf.org/doc/html/draft-ietf-roll-rpl-observations-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-roll-rpl-observations-05 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Nov 30 21:34:38 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14A083A09D9 for ; Mon, 30 Nov 2020 21:34:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.619 X-Spam-Level: X-Spam-Status: No, score=-9.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=GX1F2Ryd; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=gruRGD/u 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 fG6NLqJEsZqe for ; Mon, 30 Nov 2020 21:34:35 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E24A23A09D8 for ; Mon, 30 Nov 2020 21:34:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17686; q=dns/txt; s=iport; t=1606800874; x=1608010474; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=2vQX6JcPGDwbNafSY6VUtiAvkuoKkxV0A1lAcV/QHdo=; b=GX1F2RydRLar7/B3UISWPPSKoLvE8PdP5bTTYaMzI7Y/VjSLMZWV22bJ 9KdnEy/edOvtz9OKNL7uebogmqqba7EcNKmJYTCmoqyx5wvsH6IdBmQX0 4eBj6mzBjJkVSYyOZCCpg0pmvOBarAMraaMwKryd2PgFZCb01E0ZGit/P w=; X-IPAS-Result: =?us-ascii?q?A0C+CQC51MVf/5xdJa1cBh4BAQsSDIMyLyMuB3VaLy6Df?= =?us-ascii?q?ECDSQONWZQVhHGBQoERA1QLAQEBDQEBGAEMCAIEAQGESgIXghICJTgTAgMBA?= =?us-ascii?q?QEDAgMBAQEBBQEBAQIBBgRxhWEMhXIBAQEBAgEBAQoGER0BASwMBAsCAQYCE?= =?us-ascii?q?QMBAisCAgIlCx0IAgQTCBqCfwQCgX5XAw4gAQ6QbJBrAoE8iGl2gTKDBAEBB?= =?us-ascii?q?YUMAxWCEAMGgTiCc4JmTkKGV4IbgRABQ4InLj6CXQEBAgGBHiAOEgUQCQYHg?= =?us-ascii?q?mozgiyBRgGSNoclnVAGBIJwiReSN4Mgih2UX5VsiQWRLoQ8AgQCBAUCDgEBB?= =?us-ascii?q?YFtIw2BSnBQgR6BS1AXAg2OIYNxhRSFRHQCATQCBgEJAQEDCXyOaQEB?= IronPort-PHdr: =?us-ascii?q?9a23=3ATNk3ahdyDCZoZy+j/J3xdKo5lGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwaQB9fa5u5Kze3MvPOoVW8B5MOHt3YPONxJWg?= =?us-ascii?q?QegMob1wonHIaeCEL9IfKrCk5yHMlLWFJ/uX3uN09TFZX/akHc5Hqo4m1aFh?= =?us-ascii?q?D2LwEgIOPzF8bbhNi20Obn/ZrVbk1IiTOxbKk0Ig+xqFDat9Idhs1pLaNixw?= =?us-ascii?q?=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,383,1599523200"; d="scan'208,217";a="598454625" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Dec 2020 05:34:33 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 0B15YX3u020879 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 1 Dec 2020 05:34:33 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 30 Nov 2020 23:34:33 -0600 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 30 Nov 2020 23:34:32 -0600 Received: from NAM12-MW2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 30 Nov 2020 23:34:32 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=QbIvMVAu8DdJzJdYoBr+vtsfnC080/LQrrSnFweNVxSR+v1xlHUo6viaf/3C2UjRxeEzfSzfzmRlj8B/n52Z51uN3EHHVu+lOIWaf0UpQdPYuN0Wu9sq64z5DEFLUYyabqqzdZpOpvIyMuM69SNRIS8EySzqkagsQEgnI+TgSWb9b5a4Kcfw2fILWjY64ivTRdbhCt7M/ZbqEZ9WRl7EmFTzKZR5FIw97qJRCHFe07AvNvK3twsRtEPJJKbYwUde8ALqrksgIRrmzAeVjZouYHNwpwQ5Qr1TWQPPhi/G22tFqcfnceDPdgJkNj2EFL46j5I+NTw7Qr9T+Ah5mX+qwQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2vQX6JcPGDwbNafSY6VUtiAvkuoKkxV0A1lAcV/QHdo=; b=m53boWCb9qhc3hUfYsMxBlgglpklY6pKqi1Lh/GZ7RuYKST8uPcsh5K/iDUhQyF1VlnyiqF8kU2cOrerlN1wJNxsKYNXJDXiF/15+D8j86akjJvUqIwYHcDREMkspFIHBtxCbp2lpX8L0ZcNVIXGs9PvoqTfQK9MrKul6bF1h99WE1rsZEANjFCeLU9YPp8mu0bNtA78yYAq4lKOVMQqIHxWw8x4ZUm8crZAlFimSw5gL3Sb2BhEtrvtVd08ssfiyUfJ8wFYe4AAlX07swETRdidThSgOhuRZ52ntlyAGF1IL+Pw6iA0JSf3e8IjcVwDF9HMFJvMICLvPtNiao8/JA== 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=2vQX6JcPGDwbNafSY6VUtiAvkuoKkxV0A1lAcV/QHdo=; b=gruRGD/uJya6X6zdWiGwPBMdA7uLfms3doxDJ91NQhCj0Oe6Ahbd5B50dq6i37Sf736OQVdVaVOnolHE5UmggopFpPVqpIhvSSe4F8jHyANUWAKcerfjG+NkJkKnOnYVb+tx7kVNkHzRKm5dyFG6SaKXn3vzQaNkBBRXunJulXg= Received: from MWHPR11MB1742.namprd11.prod.outlook.com (2603:10b6:300:113::13) by MW3PR11MB4539.namprd11.prod.outlook.com (2603:10b6:303:2f::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.20; Tue, 1 Dec 2020 05:34:31 +0000 Received: from MWHPR11MB1742.namprd11.prod.outlook.com ([fe80::19ac:46a:36f1:4dfa]) by MWHPR11MB1742.namprd11.prod.outlook.com ([fe80::19ac:46a:36f1:4dfa%3]) with mapi id 15.20.3611.025; Tue, 1 Dec 2020 05:34:31 +0000 From: "Li Zhao (liz3)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] Error flows, which ICMP errors and to which root Thread-Index: AQHWxvDsqJzT1olGwECZKYhlRsF+1KngaEJHgAFPuow= Date: Tue, 1 Dec 2020 05:34:31 +0000 Message-ID: References: <26D2BCD1-D47E-46CA-9F3E-781A17A60398@cisco.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2001:420:588c:1252:ed42:30ae:45fa:1f11] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 21361863-17fb-471a-83c8-08d895bac780 x-ms-traffictypediagnostic: MW3PR11MB4539: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: 4ZUjo1yOzZCDElrb54eMGB0f0WQWcdStFhok88SBUZmqgaHBI/ZHIoqDYgnf+Mjg6fwALeyYt6o0RKmdedP7yrfI+D/kAOCklyEkvFHisbUvvIRBaWwhCVVMlXAfIU/tlWy9f1pMwccVg5HtSj7L0jNuHEA4g0zooFmUpOfnTdXFvlNDPxRMWpyvqhujbwp9ei/+L+Ykywme8PVrKHG1ZNmqt+he7TCEJnRBZ/hojn++shan9qQmNefOykgOcLly4p9D2dEUEbqrOyoe422FFZoGd9764fff7j5/gXdvgRMg3l/llX037Zw8iw2eZsRtFVjr9Z8LmkFL1v5Ii48o5IBt72Elu9BiJXCBCtKrfnBdFLQIfOugB1i2kqrdGHQdcU7mXd8QPV66xOpOElSqtevkVmF0wqZlmzIVfF93GScTxqkSa5sJLH9t9jL6s8HiZUi7Lh1pfN8Y9gaPhgneKg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MWHPR11MB1742.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(39860400002)(376002)(346002)(136003)(396003)(52536014)(5660300002)(71200400001)(45080400002)(86362001)(2906002)(91956017)(66446008)(76116006)(66556008)(66476007)(9686003)(316002)(966005)(55016002)(8936002)(64756008)(7696005)(478600001)(66946007)(8676002)(53546011)(6506007)(33656002)(6916009)(186003)(66574015)(83380400001)(166002)(88722002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?bE5OdzlvOWxvNnd1T1FMUnhjSmdpZFFZajIzYktLVWxjaWNRcUdCUDZ1VjB2?= =?utf-8?B?cVNLWHppR0dOSDZ3TlRFZjlQcG5IN2RNMnhqcGEzTHVhclVXdlQrcDdZTTQv?= =?utf-8?B?V1ZvZGRySVF2K1JDZFdLOFh4YVVnTEJoQlJlaUMzTllkZ3JrU0dNVHpNaEhv?= =?utf-8?B?UkFPOGhYb2xpKzRTTkJLWis4SUJJazNhT1dSM1FMdnJyNXo4N0h0MDBkSmpZ?= =?utf-8?B?eWFnanVJenYwZVF6b29NNVAxbzNBcnlvZCtRbS8zcGR6ZVQ3aGFZampDM2Zj?= =?utf-8?B?VDdsSWduK3lCZDY2bHI0M2VhQkZybmZObTRKMTA1NmE4Rk1IdVcxSU1tQXJ3?= =?utf-8?B?SDlsSXloWjVpV05BTnRrWFJFTlMyZFQxYWFUUGpoeVlrRmUwR3BydjE1anVG?= =?utf-8?B?OXBoUnNIVFJYYy9CeU1TVXRwb3V4T3plMk1lUzVFdjZvYlYrNVZHYWRVT2RO?= =?utf-8?B?SVJobTM3M01zNjk1WnYzcW1zUVQwTml1Tmw4YU01blBaM2dwdkt3aWE3aXdI?= =?utf-8?B?azRCSG1NbDE5ZERlYkRPUjg5VEFBS1A0UjFPUGhIbXBud3lhOTczMnJ3OE1U?= =?utf-8?B?NmlnNU5yZ3FJaGZlNkc3dWpZa0YzMy9tS2xHVEhzNnd1dmMzZEZDVlAxTDZn?= =?utf-8?B?cjIzT3pJWXJ2cnZWNTM3TGtwaDlCV3FsM2doa3pIYU1TZXBTWklPcHJmaTdz?= =?utf-8?B?ejd4aG1uenBOa0JhMVhCRDdLRmpLUlRCWFJvdWZYMkVNQWpiNHBvRTNOZXIw?= =?utf-8?B?a2N0Tzk5UEpnOEJDRUFzQTl4VnJEVWNJaEgwZWhGTFFwUDZFL1ZLYjF3MnFr?= =?utf-8?B?MCtwV3p2Um9sd1kzZnAzWUVyZEtId3BLb2h6NUtndzVxSmUxUW5JVW5zVXN6?= =?utf-8?B?QU96WDZvNjlXUVgyTnd5UTdBbTNEUEc5VXJzOWRYZjV5WUVaK0JWR2NQL0tw?= =?utf-8?B?UnBrQzRneE9IbDZCc2FBMlNDQ1F6SnEzN053T0E0UGJ0dmRuNk5JTHU3eS8z?= =?utf-8?B?UU9Ta2RjWjZ4RmFpZUFOS0Q2TGloajZVS0Vpem9NME92Sld5dDI2eWRENk4z?= =?utf-8?B?SkJYWDVnTGtRbW16M2Qzek1WTWlWZm13SXd0ai9TS3lHQnJjTUZZRXlhOG5M?= =?utf-8?B?NjdkQ3NxVE8weWUzQzRTR09pSTlrZ0tkQjYrbkRhRHB4UXl0ZFVSNmRtRkRP?= =?utf-8?B?c051TWIzelpKdFUzMWpiRGZ0YmsxSU51ZDUxSVNiTWVQWGFZNFRxWk9iRk9q?= =?utf-8?B?OUtjVkxLK0I3eTJhRUtzOCtBbVdtV3Y0K0M3dnMzVmJsY3RYWDY0YWRhTHpG?= =?utf-8?B?eWJrYkRQam5tN1FJZmJla3VacDlxbFJuSUxXOTBEMzBXS0JWMzliMVJTUXR6?= =?utf-8?B?ZEhnTnhPbytMMzVVdXArbHk5eG1ET2RZMHk5UW10c2FUWmZxUU9LK3RzS213?= =?utf-8?B?NDlwS244Tk5CRC9vVjM1dmxsNWhoSUhnR2ZLSGhBPT0=?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MWHPR11MB1742A66061E5BE87DD387CE88CF40MWHPR11MB1742namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MWHPR11MB1742.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 21361863-17fb-471a-83c8-08d895bac780 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Dec 2020 05:34:31.5519 (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: GKzbS/BjDw7laNRW/7zoUNgNnjrmbI7LJYmUfaIkZ0dPYdIAGkn4FG0bViuhKxBs X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW3PR11MB4539 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [Roll] Error flows, which ICMP errors and to which root 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, 01 Dec 2020 05:34:37 -0000 --_000_MWHPR11MB1742A66061E5BE87DD387CE88CF40MWHPR11MB1742namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gUGFzY2FsLA0KDQpPbmUgY29uY2VybiBmb3Igc2VjdGlvbiA0IOKAnEV4dGVuZGluZyBS RkMgNjU1M+KAnS4NCkFyZSBvdGhlciBmaWVsZHMg4oCcJ08nLCAnUicsICdGJyBmbGFncywgU2Vu ZGVyUmFuayDigJ0gbmVjZXNzYXJ5IHRvIGJlIHplcm8gaWYg4oCYUOKAmSBmbGFnIGlzIHNldD8N CkZvciBzdG9yaW5nLVBEQU8sIG1heWJlIHdlIGNhbiBsZXZlcmFnZSB0aGVzZSBmaWVsZHMgZm9y IGVycm9yLWRldGVjdGlvbiBpZiBuZWVkLiBTbyBkbyB3ZSBuZWVkIHJlcGxhY2Ug4oCcTVVTVOKA nSB0byDigJxTSE9VTETigJ0gb3Ig4oCcTUFZ4oCdIHRvIGtlZXAgdGhlIGZsZXhpYmlsaXR5Pw0K DQoNCkJlc3QgcmVnYXJkcywNCkxpDQoNCkZyb206IFJvbGwgPHJvbGwtYm91bmNlc0BpZXRmLm9y Zz4NCkRhdGU6IE1vbmRheSwgTm92ZW1iZXIgMzAsIDIwMjAgYXQgMTc6MjgNClRvOiBSb3V0aW5n IE92ZXIgTG93IHBvd2VyIGFuZCBMb3NzeSBuZXR3b3JrcyA8cm9sbEBpZXRmLm9yZz4NClN1Ympl Y3Q6IFJlOiBbUm9sbF0gRXJyb3IgZmxvd3MsIHdoaWNoIElDTVAgZXJyb3JzIGFuZCB0byB3aGlj aCByb290DQpZZXMgSHVpbWluDQoNCkFuZCB0aGlzIGlzIHRoZSBub3JtYWwgYmVoYXZpb3IuDQoN CldpdGggUERBTyB3ZSBjcmVhdGVkIHRoZSB1bnVzdWFsIGJlaGF2aW9yIHRvIHNlbmQgdGhlIGVy cm9yIGluIHAtcm91dGUgdG8gdGhlIHJvb3QuIFRoaXMgd2FzIHRvIG1ha2UgdGhpbmdzIGZhc3Rl ciBzaW5jZSB0aGUgY29tbXVuaWNhdGlvbiB0aHJvdWdoIHRoZSBUcmFjayBpcyBkaXJlY3Rpb25h bCBzbyB5b3UgY2Fubm90IHRhbGsgYmFjay4gQWxzbyBpbiBub24gc3RvcmluZyB0YWxraW5nIHRv IHRoZSBzb3VyY2UgaXMgdmlhIHRoZSBSb290IGFuZCB1bHRpbWF0ZWx5IHRoZSBSb290IG5lZWRz IHRvIHVwZGF0ZSB0aGUgUCBEQU8uDQoNCldpdGggUkFXIHdlIG1heSB3YW50IHRvIHRvIHNvbWV0 aGluZyBmYXN0ZXIgYnV0IHVuY2xlYXIgZm9yIG5vdy4NCg0KUGxlYXNlIG5vdGUgdGhhdCBhZnRl ciB0aGUgZGlzY3Vzc2lvbiB3aXRoIHlvdSBhbmQgTGkgSSBwdWJsaXNoZWQgYSByZXZpc2lvbiB0 aGF0IGhhcyB0aGUgZmxhZyBpbiB0aGUgUlBJIHRoYXQgaW5kaWNhdGVzIHRoYXQgdGhlIHBhY2tl dCBpcyBmb3J3YXJkZWQgb24gYSBQLXJvdXRlLg0KDQpEbyB5b3Ugd2FudCB0byBjaGFuZ2UgdGhl IGVycm9yIGZsb3c/DQoNClBhc2NhbA0KDQo+IExlIDMwIG5vdi4gMjAyMCDDoCAwOToxNSwgSHVp bWluIFNoZSAoaHVzaGUpIDxodXNoZT00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZz4gYSDDqWNy aXQgOg0KPg0KPiDvu79IaSBQYXNjYWwsDQo+DQo+IFJGQyA2NTUwIHNlY3Rpb24gMTEuMSBzYXlz IHRoZSBJQ01QdjYgZXJyb3IgaW4gU1JIIHNob3VsZCBiZSBzZW50IHRvIHRoZSBzb3VyY2Ugb2Yg dGhlIHBhY2tldC4NCj4NCj4gQmVzdCByZWdhcmRzLA0KPiBIdWltaW4NCj4NCj4gICAgTWVzc2Fn ZTogMg0KPiAgICBEYXRlOiBGcmksIDI3IE5vdiAyMDIwIDA3OjQ3OjIyICswMDAwDQo+ICAgIEZy b206ICJQYXNjYWwgVGh1YmVydCAocHRodWJlcnQpIiA8cHRodWJlcnRAY2lzY28uY29tPg0KPiAg ICBUbzogUm91dGluZyBPdmVyIExvdyBwb3dlciBhbmQgTG9zc3kgbmV0d29ya3MgPHJvbGxAaWV0 Zi5vcmc+DQo+ICAgIFN1YmplY3Q6IFtSb2xsXSBFcnJvciBmbG93cywgd2hpY2ggSUNNUCBlcnJv cnMgYW5kIHRvIHdoaWNoIHJvb3Q/Og0KPiAgICAgICAgW2V4dGVuZHNdIElFVEYgMTA5IG9wZW4g UXVlc3Rpb25zIG9uIFAtREFPDQo+ICAgIE1lc3NhZ2UtSUQ6DQo+ICAgICAgICA8Q08xUFIxMU1C NDg4MUE3MjRCMDRFQTI5RDMyREM5QzgxRDhGODBAQ08xUFIxMU1CNDg4MS5uYW1wcmQxMS5wcm9k Lm91dGxvb2suY29tPg0KPg0KPiAgICBDb250ZW50LVR5cGU6IHRleHQvcGxhaW47IGNoYXJzZXQ9 InVzLWFzY2lpIg0KPg0KPiAgICBIZWxsbyBMaQ0KPg0KPiAgICBUaGlzIGlzIHRoZSB3cm9uZyB0 aHJlYWQuIEkgY3JlYXRlZCBhIG5ldyBvbmUuDQo+DQo+PiBTZWN0aW9uIDcuOSBvZiBwZGFvLWRy YWZ0IGRlZmluZXMgYSBuZXcgY29kZSBmb3IgIElDTVB2NiBlcnJvciBtZXNzYWdlICJFcnJvciBp biBQcm9qZWN0ZWQgUm91dGUiLiBEb2VzIGl0IG9ubHkgd29yayBmb3IgSUNNUCBlcnJvcnMgc2Vu dCB0byB0aGUgbWFpbiBSb290Pw0KPg0KPiAgICBTZWN0aW9uIDUgc2F5cyAiDQo+DQo+DQo+ICAg ICAgIEluIGNhc2Ugb2YgYSBmb3J3YXJkaW5nIGVycm9yIGFsb25nIGEgUHJvamVjdGVkIFJvdXRl LCBhbiBJQ01QIGVycm9yDQo+DQo+ICAgICAgIGlzIHNlbnQgdG8gdGhlIFJvb3Qgd2l0aCBhIG5l dyBDb2RlICJFcnJvciBpbiBQcm9qZWN0ZWQgUm91dGUiIChTZWUNCj4NCj4gICAgICAgU2VjdGlv biA3Ljk8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcm9sbC1kYW8tcHJv amVjdGlvbi0xNCNzZWN0aW9uLTcuOT4pLiAgVGhlIFJvb3QgY2FuIHRoZW4gbW9kaWZ5IG9yIHJl bW92ZSB0aGUgUHJvamVjdGVkDQo+DQo+ICAgICAgIFJvdXRlLiAgVGhlICJFcnJvciBpbiBQcm9q ZWN0ZWQgUm91dGUiIG1lc3NhZ2UgaGFzIHRoZSBzYW1lIGZvcm1hdCBhcw0KPg0KPiAgICAgICB0 aGUgIkRlc3RpbmF0aW9uIFVucmVhY2hhYmxlIE1lc3NhZ2UiLCBhcyBzcGVjaWZpZWQgaW4gUkZD IDQ0NDM8aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzQ0NDM+DQo+DQo+ICAgICAgIFtS RkM0NDQzPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0NDQzPl0uDQo+DQo+ICAgICIN Cj4NCj4gICAgU28geWVzIHRoZSBpbnRlbnRpb24gd2FzIHRvIHNlbmQgdGhlIElDTVAgdG8gdGhl IG1haW4gUm9vdC4gQnV0IGFzIHlvdSBwb2ludCBvdXQgdGhlIHBhY2tldCBkb2VzIG5vdCBpbmRp Y2F0ZSBpdCBpcyBmb2xsb3dpbmcgYSBQLXJvdXRlLiBUaGlzIHdhcyByZWxhdGVkIHRvIHN0b3Jp bmcgbW9kZSBQIERBTy4gSW4gbm9uLXN0b3JpbmcgdGhlIG5vZGUgZG9lcyBub3Qga25vdyBpdCdz IGEgUC1yb3V0ZS4NCj4NCj4NCj4+IEluIG5vbi1zdG9yaW5nIFBEQU8sIGZvcndhcmRlciBjYW4n dCByZWNvZ25pemUgd2hldGhlciBkYXRhIHBhY2tldCBpcyBpbiBQREFPIGluc3RhbmNlLiBGb3J3 YXJkZXIgc2hvdWxkIHNlbmQgSUNNUCBEZXN0aW5hdGlvbiBVbnJlYWNoYWJsZSBlcnJvciB0byBy b290ICh0aGUgc291cmNlIG9mIHRoZSBwYWNrZXQpLCB0aGVuIHJvb3QgZ2VuZXJhdGVzIElDTVB2 NiBlcnJvciBtZXNzYWdlIHdpdGggIkVycm9yIGluIFByb2plY3RlZCBSb3V0ZSIgdG8gbWFpbiBS b290LiAgSXMgaXQgY29ycmVjdD8NCj4NCj4gICAgVGhhdCB3b3VsZCB3b3JrLiBTZWVtcyBuZWF0 LiBUaGUgYWx0ZXJuYXRlIHdvdWxkIGJlIHRvIHNpZ25hbCBpdCBpcyBhIFAgcm91dGUgaW4gdGhl IFJQSS4gVGhhdCdzIGl0ZW0gMikgaW4gdGhlIGxpc3QgaW4gdGhpcyB0aHJlYWQuIElmIHdlIGRv IHRoYXQgdGhlIGN1cnJlbnQgdGV4dCB3b3Jrcy4gV2hhdCBtYWtlcyBtb3JlIHNlbnNlIHRvIHlv dT8NCj4NCj4+IEluIHN0b3JpbmcgUERBTywgZm9yd2FyZGVyIGNhbiByZWNvZ25pemUgdGhlIFBE QU8gaW5zdGFuY2UgZnJvbSB0aGUgUlBJLiBJdCBjYW4gc2VuZCAiRXJyb3IgaW4gUHJvamVjdGVk IFJvdXRlIiBvciAgIkRlc3RpbmF0aW9uIFVucmVhY2hhYmxlIGVycm9yIiB0byByb290LiBNYXli ZSB3ZSBuZWVkIG1vcmUgY2xhaW1zIGZvciB3aGljaCBjb2RlIGZvcndhcmRlciBzaG91bGQgdXNl Lg0KPg0KPiAgICBXZSBoYXZlIHRvIGRlY2lkZSBpZiB3ZSBzZW5kIGl0IHRvIHRoZSBtYWluIHJv b3QgYXMgd3JpdHRlbiBpbiB0aGUgY3VycmVudCBkcmFmdCBvciB0byB0aGUgVHJhY2sgUm9vdC4g SWYgdGhlIFAgcm91dGUgaXMgcmV2ZXJzaWJsZSBjb3VsZCBiZSBkb25lIHRoYXQgd2F5LiBCdXQg dGhhdCdzIGFkZGVkIGNvbXBsZXhpdHkuIEknbSBub3QgdmVyeSBjb252aW5jZWQgZWl0aGVyIHdh eS4gVGhlIE9raGFtIHJhem9yIGNvdWxkIGJlIHRvIGRvIHRoZSBzaW1wbGVzdC4NCj4NCj4gICAg S2VlcCBzYWZlIQ0KPg0KPiAgICBQYXNjYWwNCj4NCj4NCj4NCj4NCj4NCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gUm9sbCBtYWlsaW5nIGxpc3QN Cj4gUm9sbEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3JvbGwNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpS b2xsIG1haWxpbmcgbGlzdA0KUm9sbEBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9yb2xsDQo= --_000_MWHPR11MB1742A66061E5BE87DD387CE88CF40MWHPR11MB1742namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIg NCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpEZW5nWGlhbjsN CglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJcQERlbmdYaWFuIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEg MSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxAU2ltU3VuIjsNCglwYW5vc2UtMToy IDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJZm9udC1zaXpl OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIu MHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9ImVuLUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl IiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhlbGxvPHNwYW4gbGFuZz0iRU4tVVMiPiBQYXNjYWws PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj5PbmUgY29uY2VybiBmb3Igc2VjdGlvbiA0IOKAnEV4dGVuZGlu ZyBSRkMgNjU1M+KAnS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5BcmUgb3RoZXIgZmllbGRzIOKAnCdPJywgJ1InLCAnRicg ZmxhZ3MsIFNlbmRlclJhbmsg4oCdIG5lY2Vzc2FyeSB0byBiZSB6ZXJvIGlmIOKAmFDigJkgZmxh ZyBpcyBzZXQ/DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyI+Rm9yIHN0b3JpbmctUERBTywgbWF5YmUgd2UgY2FuIGxldmVyYWdl IHRoZXNlIGZpZWxkcyBmb3IgZXJyb3ItZGV0ZWN0aW9uIGlmIG5lZWQuIFNvIGRvIHdlIG5lZWQg cmVwbGFjZSDigJxNVVNU4oCdIHRvIOKAnFNIT1VMROKAnSBvciDigJxNQVnigJ0gdG8ga2VlcCB0 aGUgZmxleGliaWxpdHk/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5CZXN0IHJlZ2FyZHMsPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyI+TGk8L3NwYW4+PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk aW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tYm90dG9tOjEyLjBwdCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6 YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Nv bG9yOmJsYWNrIj5Sb2xsICZsdDtyb2xsLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+RGF0 ZTogPC9iPk1vbmRheSwgTm92ZW1iZXIgMzAsIDIwMjAgYXQgMTc6Mjg8YnI+DQo8Yj5UbzogPC9i PlJvdXRpbmcgT3ZlciBMb3cgcG93ZXIgYW5kIExvc3N5IG5ldHdvcmtzICZsdDtyb2xsQGlldGYu b3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW1JvbGxdIEVycm9yIGZsb3dzLCB3aGlj aCBJQ01QIGVycm9ycyBhbmQgdG8gd2hpY2ggcm9vdDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlllcyBIdWltaW48YnI+DQo8YnI+DQpB bmQgdGhpcyBpcyB0aGUgbm9ybWFsIGJlaGF2aW9yLjxicj4NCjxicj4NCldpdGggUERBTyB3ZSBj cmVhdGVkIHRoZSB1bnVzdWFsIGJlaGF2aW9yIHRvIHNlbmQgdGhlIGVycm9yIGluIHAtcm91dGUg dG8gdGhlIHJvb3QuIFRoaXMgd2FzIHRvIG1ha2UgdGhpbmdzIGZhc3RlciBzaW5jZSB0aGUgY29t bXVuaWNhdGlvbiB0aHJvdWdoIHRoZSBUcmFjayBpcyBkaXJlY3Rpb25hbCBzbyB5b3UgY2Fubm90 IHRhbGsgYmFjay4gQWxzbyBpbiBub24gc3RvcmluZyB0YWxraW5nIHRvIHRoZSBzb3VyY2UgaXMg dmlhIHRoZSBSb290IGFuZA0KIHVsdGltYXRlbHkgdGhlIFJvb3QgbmVlZHMgdG8gdXBkYXRlIHRo ZSBQIERBTy48YnI+DQo8YnI+DQpXaXRoIFJBVyB3ZSBtYXkgd2FudCB0byB0byBzb21ldGhpbmcg ZmFzdGVyIGJ1dCB1bmNsZWFyIGZvciBub3cuPGJyPg0KPGJyPg0KUGxlYXNlIG5vdGUgdGhhdCBh ZnRlciB0aGUgZGlzY3Vzc2lvbiB3aXRoIHlvdSBhbmQgTGkgSSBwdWJsaXNoZWQgYSByZXZpc2lv biB0aGF0IGhhcyB0aGUgZmxhZyBpbiB0aGUgUlBJIHRoYXQgaW5kaWNhdGVzIHRoYXQgdGhlIHBh Y2tldCBpcyBmb3J3YXJkZWQgb24gYSBQLXJvdXRlLjxicj4NCjxicj4NCkRvIHlvdSB3YW50IHRv IGNoYW5nZSB0aGUgZXJyb3IgZmxvdz88YnI+DQo8YnI+DQpQYXNjYWw8YnI+DQo8YnI+DQomZ3Q7 IExlIDMwIG5vdi4gMjAyMCDDoCAwOToxNSwgSHVpbWluIFNoZSAoaHVzaGUpICZsdDtodXNoZT00 MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZyZndDsgYSDDqWNyaXQgOjxicj4NCiZndDsgPGJyPg0K Jmd0OyDvu79IaSBQYXNjYWwsPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFJGQyA2NTUwIHNlY3Rpb24g MTEuMSBzYXlzIHRoZSBJQ01QdjYgZXJyb3IgaW4gU1JIIHNob3VsZCBiZSBzZW50IHRvIHRoZSBz b3VyY2Ugb2YgdGhlIHBhY2tldC48YnI+DQomZ3Q7IDxicj4NCiZndDsgQmVzdCByZWdhcmRzLDxi cj4NCiZndDsgSHVpbWluPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE1l c3NhZ2U6IDI8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IERhdGU6IEZyaSwgMjcgTm92IDIw MjAgMDc6NDc6MjIgKzAwMDA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEZyb206ICZxdW90 O1Bhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkmcXVvdDsgJmx0O3B0aHViZXJ0QGNpc2NvLmNvbSZn dDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRvOiBSb3V0aW5nIE92ZXIgTG93IHBvd2Vy IGFuZCBMb3NzeSBuZXR3b3JrcyAmbHQ7cm9sbEBpZXRmLm9yZyZndDs8YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IFN1YmplY3Q6IFtSb2xsXSBFcnJvciBmbG93cywgd2hpY2ggSUNNUCBlcnJv cnMgYW5kIHRvIHdoaWNoIHJvb3Q/Ojxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgW2V4dGVuZHNdIElFVEYgMTA5IG9wZW4gUXVlc3Rpb25zIG9uIFAt REFPPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBNZXNzYWdlLUlEOjxicj4NCiZndDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O0NPMVBSMTFNQjQ4ODFB NzI0QjA0RUEyOUQzMkRDOUM4MUQ4RjgwQENPMVBSMTFNQjQ4ODEubmFtcHJkMTEucHJvZC5vdXRs b29rLmNvbSZndDs8YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgQ29udGVu dC1UeXBlOiB0ZXh0L3BsYWluOyBjaGFyc2V0PSZxdW90O3VzLWFzY2lpJnF1b3Q7PGJyPg0KJmd0 OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEhlbGxvIExpPGJyPg0KJmd0OyA8YnI+DQom Z3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoaXMgaXMgdGhlIHdyb25nIHRocmVhZC4gSSBjcmVhdGVk IGEgbmV3IG9uZS48YnI+DQomZ3Q7IDxicj4NCiZndDsmZ3Q7IFNlY3Rpb24gNy45IG9mIHBkYW8t ZHJhZnQgZGVmaW5lcyBhIG5ldyBjb2RlIGZvciZuYnNwOyBJQ01QdjYgZXJyb3IgbWVzc2FnZSAm cXVvdDtFcnJvciBpbiBQcm9qZWN0ZWQgUm91dGUmcXVvdDsuIERvZXMgaXQgb25seSB3b3JrIGZv ciBJQ01QIGVycm9ycyBzZW50IHRvIHRoZSBtYWluIFJvb3Q/PGJyPg0KJmd0OyA8YnI+DQomZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNlY3Rpb24gNSBzYXlzICZxdW90Ozxicj4NCiZndDsgPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEluIGNh c2Ugb2YgYSBmb3J3YXJkaW5nIGVycm9yIGFsb25nIGEgUHJvamVjdGVkIFJvdXRlLCBhbiBJQ01Q IGVycm9yPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IGlzIHNlbnQgdG8gdGhlIFJvb3Qgd2l0aCBhIG5ldyBDb2RlICZxdW90O0Vycm9yIGlu IFByb2plY3RlZCBSb3V0ZSZxdW90OyAoU2VlPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNlY3Rpb24gNy45Jmx0OzxhIGhyZWY9Imh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJvbGwtZGFvLXByb2plY3Rpb24tMTQj c2VjdGlvbi03LjkiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJvbGwt ZGFvLXByb2plY3Rpb24tMTQjc2VjdGlvbi03Ljk8L2E+Jmd0OykuJm5ic3A7IFRoZSBSb290IGNh biB0aGVuIG1vZGlmeSBvciByZW1vdmUgdGhlIFByb2plY3RlZDxicj4NCiZndDsgPGJyPg0KJmd0 OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBSb3V0ZS4mbmJzcDsgVGhlICZx dW90O0Vycm9yIGluIFByb2plY3RlZCBSb3V0ZSZxdW90OyBtZXNzYWdlIGhhcyB0aGUgc2FtZSBm b3JtYXQgYXM8YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsgdGhlICZxdW90O0Rlc3RpbmF0aW9uIFVucmVhY2hhYmxlIE1lc3NhZ2UmcXVvdDss IGFzIHNwZWNpZmllZCBpbiBSRkMgNDQ0MyZsdDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvcmZjNDQ0MyI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzQ0NDM8L2E+ Jmd0Ozxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyBbUkZDNDQ0MyZsdDtodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDQ0MyZndDtd Ljxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDs8YnI+DQomZ3Q7 IDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgU28geWVzIHRoZSBpbnRlbnRpb24gd2FzIHRv IHNlbmQgdGhlIElDTVAgdG8gdGhlIG1haW4gUm9vdC4gQnV0IGFzIHlvdSBwb2ludCBvdXQgdGhl IHBhY2tldCBkb2VzIG5vdCBpbmRpY2F0ZSBpdCBpcyBmb2xsb3dpbmcgYSBQLXJvdXRlLiBUaGlz IHdhcyByZWxhdGVkIHRvIHN0b3JpbmcgbW9kZSBQIERBTy4gSW4gbm9uLXN0b3JpbmcgdGhlIG5v ZGUgZG9lcyBub3Qga25vdyBpdCdzIGEgUC1yb3V0ZS48YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJy Pg0KJmd0OyZndDsgSW4gbm9uLXN0b3JpbmcgUERBTywgZm9yd2FyZGVyIGNhbid0IHJlY29nbml6 ZSB3aGV0aGVyIGRhdGEgcGFja2V0IGlzIGluIFBEQU8gaW5zdGFuY2UuIEZvcndhcmRlciBzaG91 bGQgc2VuZCBJQ01QIERlc3RpbmF0aW9uIFVucmVhY2hhYmxlIGVycm9yIHRvIHJvb3QgKHRoZSBz b3VyY2Ugb2YgdGhlIHBhY2tldCksIHRoZW4gcm9vdCBnZW5lcmF0ZXMgSUNNUHY2IGVycm9yIG1l c3NhZ2Ugd2l0aCAmcXVvdDtFcnJvciBpbiBQcm9qZWN0ZWQgUm91dGUmcXVvdDsNCiB0byBtYWlu IFJvb3QuJm5ic3A7IElzIGl0IGNvcnJlY3Q/PGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7IFRoYXQgd291bGQgd29yay4gU2VlbXMgbmVhdC4gVGhlIGFsdGVybmF0ZSB3b3Vs ZCBiZSB0byBzaWduYWwgaXQgaXMgYSBQIHJvdXRlIGluIHRoZSBSUEkuIFRoYXQncyBpdGVtIDIp IGluIHRoZSBsaXN0IGluIHRoaXMgdGhyZWFkLiBJZiB3ZSBkbyB0aGF0IHRoZSBjdXJyZW50IHRl eHQgd29ya3MuIFdoYXQgbWFrZXMgbW9yZSBzZW5zZSB0byB5b3U/PGJyPg0KJmd0OyA8YnI+DQom Z3Q7Jmd0OyBJbiBzdG9yaW5nIFBEQU8sIGZvcndhcmRlciBjYW4gcmVjb2duaXplIHRoZSBQREFP IGluc3RhbmNlIGZyb20gdGhlIFJQSS4gSXQgY2FuIHNlbmQgJnF1b3Q7RXJyb3IgaW4gUHJvamVj dGVkIFJvdXRlJnF1b3Q7IG9yJm5ic3A7ICZxdW90O0Rlc3RpbmF0aW9uIFVucmVhY2hhYmxlIGVy cm9yJnF1b3Q7IHRvIHJvb3QuIE1heWJlIHdlIG5lZWQgbW9yZSBjbGFpbXMgZm9yIHdoaWNoIGNv ZGUgZm9yd2FyZGVyIHNob3VsZCB1c2UuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IFdlIGhhdmUgdG8gZGVjaWRlIGlmIHdlIHNlbmQgaXQgdG8gdGhlIG1haW4gcm9vdCBh cyB3cml0dGVuIGluIHRoZSBjdXJyZW50IGRyYWZ0IG9yIHRvIHRoZSBUcmFjayBSb290LiBJZiB0 aGUgUCByb3V0ZSBpcyByZXZlcnNpYmxlIGNvdWxkIGJlIGRvbmUgdGhhdCB3YXkuIEJ1dCB0aGF0 J3MgYWRkZWQgY29tcGxleGl0eS4gSSdtIG5vdCB2ZXJ5IGNvbnZpbmNlZCBlaXRoZXIgd2F5LiBU aGUgT2toYW0gcmF6b3IgY291bGQgYmUgdG8gZG8gdGhlDQogc2ltcGxlc3QuPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEtlZXAgc2FmZSE8YnI+DQomZ3Q7IDxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsgUGFzY2FsPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZn dDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IFJvbGwgbWFpbGluZyBsaXN0PGJy Pg0KJmd0OyBSb2xsQGlldGYub3JnPGJyPg0KJmd0OyA8YSBocmVmPSJodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vcm9sbDwvYT48YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXzxicj4NClJvbGwgbWFpbGluZyBsaXN0PGJyPg0KUm9sbEBpZXRmLm9yZzxi cj4NCjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbCI+ aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsPC9hPjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_MWHPR11MB1742A66061E5BE87DD387CE88CF40MWHPR11MB1742namp_-- From nobody Mon Nov 30 22:35:51 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF85C3A0B5D for ; Mon, 30 Nov 2020 22:35:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.619 X-Spam-Level: X-Spam-Status: No, score=-9.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=ck5yHs3n; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=KOm/64iO 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 ue2mKWrcN24l for ; Mon, 30 Nov 2020 22:35:44 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37D423A0B5C for ; Mon, 30 Nov 2020 22:35:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30120; q=dns/txt; s=iport; t=1606804544; x=1608014144; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=KM+IqIR57tt9YbBkxpC85nEHH+qLIG+uvqECyOoYvkQ=; b=ck5yHs3n40tFNbTQjJEOVVmFUFC24+wHgZBQLBHF8jiQ4gBGdidA3jB2 G00OmBnO/oP92KmZP7TnZlclTaZXTcyx1SoC91pupwUx3znxYPJ6BvzfR Yx+dlIfcFB89xmb6FfFWBz9F7n/889YvBbDcGY101c9UwUT20Ok+8/lsY A=; X-IPAS-Result: =?us-ascii?q?A0B4BwDZ48VffZ1dJa1cBh0BAQEBCQESAQUFAYIPgSMBL?= =?us-ascii?q?iMufFovLoN8QINJA41amQaBQoERA1QLAQEBDQEBGAEMCAIEAQGBNIMWAheCE?= =?us-ascii?q?gIlOBMCAwEBAQMCAwEBAQEFAQEBAgEGBBQBAYY8DIVyAQEBAQIBAQEKBhEKE?= =?us-ascii?q?wEBLAwECwIBBgIRAwEBASEHAwICAiULFAkIAgQTCBqCfwQCgX5XAw4gAQ6QZ?= =?us-ascii?q?JBrAoE8iGl2gTKDBAEBBYUMAxWCEAMGgTiCc4JmTkKGVxuBQT+BEAFDgicuP?= =?us-ascii?q?oJdAQECAYEeIA4SBQcJCQYHCYJhM4Isk32HJZ1QCoJwiReSN4Mgih2UX5Vsi?= =?us-ascii?q?QWRLoQ8AgQCBAUCDgEBBYFtIQ+BSnAVO4JpUBcCDY4hg3GFFIVEdAIBNAIGA?= =?us-ascii?q?QkBAQMJfI5pAQE?= IronPort-PHdr: =?us-ascii?q?9a23=3AzQof9BJ7jZl7m2E9f9mcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeGvK8/jVLVU8Pc8f0Xw+bVsqW1X2sG7N7BtX0Za5VDWl?= =?us-ascii?q?cDjtlehA0vBsOJSCiZZP7nZiA3BoJOAVli+XzoMEVJFoD5fVKB6nG35CQZTx?= =?us-ascii?q?P4Mwc9L+/pG4nU2sKw0e36+5DabwhSwjSnZrYnJxStpgKXvc4T0oY=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,383,1599523200"; d="scan'208,217";a="604742826" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Dec 2020 06:35:42 +0000 Received: from XCH-RCD-004.cisco.com (xch-rcd-004.cisco.com [173.37.102.14]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id 0B16ZgCw016695 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 1 Dec 2020 06:35:42 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-RCD-004.cisco.com (173.37.102.14) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 1 Dec 2020 00:35:42 -0600 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 1 Dec 2020 00:35:41 -0600 Received: from NAM02-SN1-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 1 Dec 2020 00:35:42 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TKkwKhFnPzRn+veBdZV3a5ug289Bul2kIQo4kAfl1PHah1sm33D8wWt7TklnjHIkoXqWP6zcKqhk28c+q+7uODwer+auZ0btAgGUs1/uXmoxWlJitPWVaX9+48bhw6f7OiOsIe1XARtnaEuX1meY+QhVeW80VShsWBaJJ9jNhkeB7fTa1bNsAbOBW33227ueBrxat3U81MKuAAgnM2WI7WI0IvYSnIisgZgeDnfFe4rFFBh3CSNfo/5rNZsLSHNbigiScjBe3YCW6DuXQzxKlIgrwPE51mFWLPALW9/IMyywRUvgpCmy50Lx/ZRXSEgyRIOOD2Cf0q94amiRjIOVnQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KM+IqIR57tt9YbBkxpC85nEHH+qLIG+uvqECyOoYvkQ=; b=c1H4/Xgtsda9MnXFkouwB4lmq0SS1qFeLPVnd1rHWp8vheuqUBl2QzPoLy2zzNMNHJUuKfS4Uk9iR0Wa6cx3uIpTt2ERvU+LP5K8520VDSqM2HLinHU6VJxHmSqtakR5B3tT2ucHssf3SvcRy7PkQ7UiKgwm/bUwUfyFnqf5WVToZpGwLyyLPWw33/7a5HvY9OPkNKsa+VszdUHluT3pzc4to7+8PbPSg1dqRgNgkdkcO0tagf5+ibSitnFqa+ECnyeqrFMT6Htmw36Z4ZEXoHcZ50xFHIB+Re8466JNe3lmUTp+WEQOH5mvNuYKJCzQNzMTENRHN5nhLYhgjL8g8A== 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=KM+IqIR57tt9YbBkxpC85nEHH+qLIG+uvqECyOoYvkQ=; b=KOm/64iOfagJtfciBpWWVSx2BFv8N83WEKHz3QA49xND8OxOROzyZHNna2DIDa0YYrMBQDwF4rTuPdGnwnPStTsEKAF7Nvy6mNMya8Ybxm2H6l6n5a5Om45FnUKo3pRn9A7jVWneTmi2wOXBjpJUW/HvddiMyVaPaeeBOOwXjnc= Received: from PH0PR11MB4885.namprd11.prod.outlook.com (2603:10b6:510:35::14) by PH0PR11MB5078.namprd11.prod.outlook.com (2603:10b6:510:3e::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.22; Tue, 1 Dec 2020 06:35:41 +0000 Received: from PH0PR11MB4885.namprd11.prod.outlook.com ([fe80::d9d7:eaa0:34c9:91ee]) by PH0PR11MB4885.namprd11.prod.outlook.com ([fe80::d9d7:eaa0:34c9:91ee%7]) with mapi id 15.20.3611.025; Tue, 1 Dec 2020 06:35:41 +0000 From: "Pascal Thubert (pthubert)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] Error flows, which ICMP errors and to which root Thread-Index: AQHWxvDsqJzT1olGwECZKYhlRsF+1KngaEJHgAFPuoyAAAqV0A== Date: Tue, 1 Dec 2020 06:35:29 +0000 Deferred-Delivery: Tue, 1 Dec 2020 06:34:28 +0000 Message-ID: References: <26D2BCD1-D47E-46CA-9F3E-781A17A60398@cisco.com>, In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2a01:cb1d:4ec:2200:5915:fffd:1d6b:49a5] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4629e3c5-f985-4de1-f567-08d895c352bb x-ms-traffictypediagnostic: PH0PR11MB5078: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: P0oQUM2ZmpYv9eMPdZVybL+I6S1TltVUoV1M5toI51xlJudSYstOfqaY1jJiaaETYDyFN/1yAfKdxcksogkHaaNjenlRQotmbux9HJch/52O2qs6lBSOXtxRkrD0vrILPP394zS/aJZLCFsHUg4i5tQ7hL9WPygkLU1ifUpm/saUUrO4M3UGO42prZEi/3KFuVfPVztJKw1cKoy62lzza+N/4o3bpxcyDOIpr4V+//a4NbqEbZiTaH6ndlGv6fUOXK3wndHesVQqMEARjOCkGwk2vGHVN+tSrD2pOgX/33vGs5WkfOwTQMTD308VB2+hHY8wY3zEcv4cSwV67CllrC/Yvqa92NjLkKxhCc+kDgzg3Hm4EeHDcw65UmZxk6z4Js1Pfw5OE2ns5pmy+41+Ig== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:PH0PR11MB4885.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(396003)(39860400002)(346002)(136003)(376002)(86362001)(71200400001)(52536014)(6916009)(2906002)(5660300002)(6506007)(7696005)(316002)(83380400001)(966005)(6666004)(66574015)(33656002)(478600001)(53546011)(66946007)(66476007)(64756008)(66556008)(45080400002)(8676002)(66446008)(9686003)(8936002)(166002)(186003)(76116006)(55016002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?V0x6V2VSellrY1hSU3NOQzZ2dEZiY0RJS1pnK2EzT0hvbzNwNnFMbWkyejlU?= =?utf-8?B?MzN5NnZRSEpmeWtlVytPdDdjQXFWM1QyNU9nSTBQN2REdndST1h0Q2o2VXZL?= =?utf-8?B?S2hpaWlWQmFYQXoreXhjOExtc1poby9IR21jaURTZUVnejNQT2RHcDdBVkZp?= =?utf-8?B?bVVJelZNZ0dneXZnNHN0ZklZOG5waC9nZWlGVWZUdHNhcUc4WEV3bExzUHJV?= =?utf-8?B?VHJsME9WeGF1bU5TcGpNSml5WUxBTFI4c05HNFZCT0VXOHh0OUxrVE5pUlhF?= =?utf-8?B?ckNyc1BGczZ4MmprVThwdWpUOFdqbmVzbGVvSGQ1eEc0ZmVydmt3QXhDai9q?= =?utf-8?B?MkpmVXhKbVFjcWRYay8yNGxGR2xqSVVZOHNLQXNpK0h5QU1lY2JsY3p6ZWZU?= =?utf-8?B?SWpGNGJ4T2FNK092cnp2MU9ndWkwKzFtQUdHNStkVnhReS9JMlNuYU04TWdJ?= =?utf-8?B?eWNwUG5jVzBFdEVrK1NLSHBWd3VJS3ROMitJL1lWTlUyTUZHSFFoSk04L3px?= =?utf-8?B?cTloR2diYTg5d2V5VmRUcjIwZHhWbTd3YjllWVE2S21FUExSakpPWGxOMmdL?= =?utf-8?B?bVFDNllHQ1BjUGpCK3phRVBremhVcm1wcGpjazJoVkhMdldDOGpOZk0zbklS?= =?utf-8?B?QVJxQkQ1K3AvWkVUaUd6c3NKV0RFUkhEeXVOd0ZGYTQrUzMvYXp5WllHQVpU?= =?utf-8?B?ZFFNNHBJc1Z4UUNucWhEUmx3MWg3VGhJbVBnL2dha2hWbVFDR2tLdXhHWUo5?= =?utf-8?B?ZlhYSFJUa2F4clZSVDN1QjdlQVRFZm9zbHByNWdVMkdveFB4S2hnVEtja2pL?= =?utf-8?B?ZmNCVWJVaHdmS0ZuUXQzZXZhWGh4VkZyanI2RGRNMU1aNk5KLzRLRC9UTlRB?= =?utf-8?B?VFp0Q2QwbHVLWnpXRUFJdm1xa2ZUSXpjQkNnOWFoeERKa3c2VXBUckRuVDZq?= =?utf-8?B?R3RtMzRNVkRSVkJQb1o5aTJTSFNHdGJkREM1MmpxOXZyNllOVTRONzEzTlk0?= =?utf-8?B?WUVkbVp0MUpyYnJVZC91NzdReUZvM2x2M1VMZXNnbDIvdk8wVlFpeWNFbERs?= =?utf-8?B?b0JjckdzN092RjdsL0VmdGdCY0dudkk0SFRRKzNmSTZ0dG5Lb0F5dkJsMWtI?= =?utf-8?B?cXpvb2VBVXdrRFBLNUtBQ1lzWkN4SFdRNk9MUDA2YklDUUdnL3VLZ3VZODdN?= =?utf-8?B?bEhRZUIzTHhkSkxnczdJeDd5dlBsc1VRd0N2NjhURFdweno4Z3dadUFBRUt2?= =?utf-8?B?N3UwWEpwSURmeTJ2NXU4ZUQ1WGVLS3RGM1VRRmFMK2gzOHd6U0t1MlErdWZu?= =?utf-8?B?bG15dzl0UnM4S1VwQ1NwR3RZbENsMEp6aUdaOUYzMFc1RkRuNjZNSTUwNjN5?= =?utf-8?B?OTdhYjcxZVBtWjlEcHFKYWRyR2NHQlhDRnF5U2lZajN6eVhUQzdGNWF2Vzlq?= =?utf-8?Q?tER6+DVI?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_PH0PR11MB488590F8FA7632517929B0F1D8F40PH0PR11MB4885namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PH0PR11MB4885.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 4629e3c5-f985-4de1-f567-08d895c352bb X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Dec 2020 06:35:41.1489 (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: 6NbOV8228PueZoxcQwHGjuygwiSYBIE7T7U+IdjlzVorPQrX8Duh+tyUOjlGa3MXHNIp0HmUqO3EpBTIidDigA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR11MB5078 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.14, xch-rcd-004.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: Re: [Roll] Error flows, which ICMP errors and to which root 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, 01 Dec 2020 06:35:50 -0000 --_000_PH0PR11MB488590F8FA7632517929B0F1D8F40PH0PR11MB4885namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gTGkNCg0KQnV0IFAtREFPIGRvZXMgbm90IGRpc3RyaWJ1dGUgYSBSYW5rLiBUaGUgbmV3 IFAtU1JILTZMb1JIIGVsaWRlcyBpdC4gU28gdGhlIOKAmFLigJkgZmxhZyBkb2VzIG5vdCBtYWtl IHNlbnNlIGVpdGhlci4NCkZvciBub3cgdGhlIFRyYWNrIGlzIG5vdCByZXZlcnNpYmxlLCBzbyB0 aGUg4oCYT+KAmSBmbGFnIGlzIHVzZWxlc3MgYXMgd2VsbC4NCg0KSSB3YXMgd29uZGVyaW5nIGZv ciB0aGUg4oCYRuKAmSBmbGFnLiBXZSBjb3VsZCBzdGlsbCB1c2UgaXQgaW4gYm90aCBtb2Rlcy4g QnV0IHRoYXQgaXMgZXh0cmEgY29kZSwgbGl0dGxlIHZhbHVlIHNpbmNlIHRoZSBJQ01QIHRvIHRo ZSByb290IGlzIGFscmVhZHkgdGhlcmUuDQoNCkZpbmFsbHksIHlvdeKAmWxsIGZpbmQgdGhhdCB0 aGVyZSBpcyBubyByb29tIGxlZnQgaW4NCg0KICAgICAgICAgICAgICAgIDAgICAgICAgICAgICAg ICAgICAgMSAgICAgICAgICAgICAgICAgICAyDQogICAgICAgICAgICAgICAgMCAxIDIgMyA0IDUg NiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMNCiAgICAgICAgICAgICAgICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgICAgICAg ICAgIHwxfDB8RXwgTGVuZ3RoICB8IDZMb1JIIFR5cGUgNyAgfCBSUExJbnN0YW5jZUlEIHwNCiAg ICAgICAgICAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSsNCg0KVGhhdCBpcyBiZWNhdXNlIEkgd2FudCB0aGUgUC1SUEktNkxvUkggdG8gYmUgZWl0 aGVyIGVsZWN0aXZlIG9yIGNyaXRpY2FsLCB3aGljaCBpbXBsaWVzIHRoYXQgYnV0cyAzLi43IGFy ZSBhIGxlbmd0aCwgbm8gcm9vbSBmb3IgdGhlIOKAmEbigJkgYml0Lg0KRm9yIG1lbW9yeSwgdGhl IFJQSS02TG9SSCBpcyBjcml0aWNhbCwgeW91IEhBVkUgdG8gc3VwcG9ydCBpdCBpZiBpdCBpcyBp biB0aGUgcGFja2V0LCBlbHNlIHlvdSBkcm9wLiBJbiB0aGUgYWJvdmUgZm9ybWF0LCBpZiB0aGUg 4oCYReKAmSBiaXQgaXMgc2V0LCB0aGUgaW1wbGVtZW50YXRpb24gY2FuIGZ1bGx5IGlnbm9yZSB0 aGUgUlBJICh0aGF04oCZcyBvbmUgb2YgdGhlIG5pY2UgdGhpbmdzIGFib3V0IFJGQyA4MTM4KSwg d2hpY2ggY2FuIGJlIE9LIGluIHNvbWUgc3RyaWN0IHNvdXJjZSByb3V0aW5nIHNpdHVhdGlvbnMu DQoNClNvIEkgdGhvdWdodCwgbGV0IHVzIGlnbm9yZSBhbGwgdGhlIGJpdHMgYW5kIGtlZXAgdGhp bmdzIHNpbXBsZS4NCg0KV29ya3M/DQoNClBhc2NhbA0KDQoNCkZyb206IFJvbGwgPHJvbGwtYm91 bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIExpIFpoYW8gKGxpejMpDQpTZW50OiBtYXJkaSAx IGTDqWNlbWJyZSAyMDIwIDA2OjM1DQpUbzogUm91dGluZyBPdmVyIExvdyBwb3dlciBhbmQgTG9z c3kgbmV0d29ya3MgPHJvbGxAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW1JvbGxdIEVycm9yIGZs b3dzLCB3aGljaCBJQ01QIGVycm9ycyBhbmQgdG8gd2hpY2ggcm9vdA0KDQpIZWxsbyBQYXNjYWws DQoNCk9uZSBjb25jZXJuIGZvciBzZWN0aW9uIDQg4oCcRXh0ZW5kaW5nIFJGQyA2NTUz4oCdLg0K QXJlIG90aGVyIGZpZWxkcyDigJwnTycsICdSJywgJ0YnIGZsYWdzLCBTZW5kZXJSYW5rIOKAnSBu ZWNlc3NhcnkgdG8gYmUgemVybyBpZiDigJhQ4oCZIGZsYWcgaXMgc2V0Pw0KRm9yIHN0b3Jpbmct UERBTywgbWF5YmUgd2UgY2FuIGxldmVyYWdlIHRoZXNlIGZpZWxkcyBmb3IgZXJyb3ItZGV0ZWN0 aW9uIGlmIG5lZWQuIFNvIGRvIHdlIG5lZWQgcmVwbGFjZSDigJxNVVNU4oCdIHRvIOKAnFNIT1VM ROKAnSBvciDigJxNQVnigJ0gdG8ga2VlcCB0aGUgZmxleGliaWxpdHk/DQoNCg0KQmVzdCByZWdh cmRzLA0KTGkNCg0KRnJvbTogUm9sbCA8cm9sbC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpyb2xs LWJvdW5jZXNAaWV0Zi5vcmc+Pg0KRGF0ZTogTW9uZGF5LCBOb3ZlbWJlciAzMCwgMjAyMCBhdCAx NzoyOA0KVG86IFJvdXRpbmcgT3ZlciBMb3cgcG93ZXIgYW5kIExvc3N5IG5ldHdvcmtzIDxyb2xs QGlldGYub3JnPG1haWx0bzpyb2xsQGlldGYub3JnPj4NClN1YmplY3Q6IFJlOiBbUm9sbF0gRXJy b3IgZmxvd3MsIHdoaWNoIElDTVAgZXJyb3JzIGFuZCB0byB3aGljaCByb290DQpZZXMgSHVpbWlu DQoNCkFuZCB0aGlzIGlzIHRoZSBub3JtYWwgYmVoYXZpb3IuDQoNCldpdGggUERBTyB3ZSBjcmVh dGVkIHRoZSB1bnVzdWFsIGJlaGF2aW9yIHRvIHNlbmQgdGhlIGVycm9yIGluIHAtcm91dGUgdG8g dGhlIHJvb3QuIFRoaXMgd2FzIHRvIG1ha2UgdGhpbmdzIGZhc3RlciBzaW5jZSB0aGUgY29tbXVu aWNhdGlvbiB0aHJvdWdoIHRoZSBUcmFjayBpcyBkaXJlY3Rpb25hbCBzbyB5b3UgY2Fubm90IHRh bGsgYmFjay4gQWxzbyBpbiBub24gc3RvcmluZyB0YWxraW5nIHRvIHRoZSBzb3VyY2UgaXMgdmlh IHRoZSBSb290IGFuZCB1bHRpbWF0ZWx5IHRoZSBSb290IG5lZWRzIHRvIHVwZGF0ZSB0aGUgUCBE QU8uDQoNCldpdGggUkFXIHdlIG1heSB3YW50IHRvIHRvIHNvbWV0aGluZyBmYXN0ZXIgYnV0IHVu Y2xlYXIgZm9yIG5vdy4NCg0KUGxlYXNlIG5vdGUgdGhhdCBhZnRlciB0aGUgZGlzY3Vzc2lvbiB3 aXRoIHlvdSBhbmQgTGkgSSBwdWJsaXNoZWQgYSByZXZpc2lvbiB0aGF0IGhhcyB0aGUgZmxhZyBp biB0aGUgUlBJIHRoYXQgaW5kaWNhdGVzIHRoYXQgdGhlIHBhY2tldCBpcyBmb3J3YXJkZWQgb24g YSBQLXJvdXRlLg0KDQpEbyB5b3Ugd2FudCB0byBjaGFuZ2UgdGhlIGVycm9yIGZsb3c/DQoNClBh c2NhbA0KDQo+IExlIDMwIG5vdi4gMjAyMCDDoCAwOToxNSwgSHVpbWluIFNoZSAoaHVzaGUpIDxo dXNoZT00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZzxtYWlsdG86aHVzaGU9NDBjaXNjby5jb21A ZG1hcmMuaWV0Zi5vcmc+PiBhIMOpY3JpdCA6DQo+DQo+IO+7v0hpIFBhc2NhbCwNCj4NCj4gUkZD IDY1NTAgc2VjdGlvbiAxMS4xIHNheXMgdGhlIElDTVB2NiBlcnJvciBpbiBTUkggc2hvdWxkIGJl IHNlbnQgdG8gdGhlIHNvdXJjZSBvZiB0aGUgcGFja2V0Lg0KPg0KPiBCZXN0IHJlZ2FyZHMsDQo+ IEh1aW1pbg0KPg0KPiAgICBNZXNzYWdlOiAyDQo+ICAgIERhdGU6IEZyaSwgMjcgTm92IDIwMjAg MDc6NDc6MjIgKzAwMDANCj4gICAgRnJvbTogIlBhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkiIDxw dGh1YmVydEBjaXNjby5jb208bWFpbHRvOnB0aHViZXJ0QGNpc2NvLmNvbT4+DQo+ICAgIFRvOiBS b3V0aW5nIE92ZXIgTG93IHBvd2VyIGFuZCBMb3NzeSBuZXR3b3JrcyA8cm9sbEBpZXRmLm9yZzxt YWlsdG86cm9sbEBpZXRmLm9yZz4+DQo+ICAgIFN1YmplY3Q6IFtSb2xsXSBFcnJvciBmbG93cywg d2hpY2ggSUNNUCBlcnJvcnMgYW5kIHRvIHdoaWNoIHJvb3Q/Og0KPiAgICAgICAgW2V4dGVuZHNd IElFVEYgMTA5IG9wZW4gUXVlc3Rpb25zIG9uIFAtREFPDQo+ICAgIE1lc3NhZ2UtSUQ6DQo+ICAg ICAgICA8Q08xUFIxMU1CNDg4MUE3MjRCMDRFQTI5RDMyREM5QzgxRDhGODBAQ08xUFIxMU1CNDg4 MS5uYW1wcmQxMS5wcm9kLm91dGxvb2suY29tPG1haWx0bzpDTzFQUjExTUI0ODgxQTcyNEIwNEVB MjlEMzJEQzlDODFEOEY4MEBDTzFQUjExTUI0ODgxLm5hbXByZDExLnByb2Qub3V0bG9vay5jb20+ Pg0KPg0KPiAgICBDb250ZW50LVR5cGU6IHRleHQvcGxhaW47IGNoYXJzZXQ9InVzLWFzY2lpIg0K Pg0KPiAgICBIZWxsbyBMaQ0KPg0KPiAgICBUaGlzIGlzIHRoZSB3cm9uZyB0aHJlYWQuIEkgY3Jl YXRlZCBhIG5ldyBvbmUuDQo+DQo+PiBTZWN0aW9uIDcuOSBvZiBwZGFvLWRyYWZ0IGRlZmluZXMg YSBuZXcgY29kZSBmb3IgIElDTVB2NiBlcnJvciBtZXNzYWdlICJFcnJvciBpbiBQcm9qZWN0ZWQg Um91dGUiLiBEb2VzIGl0IG9ubHkgd29yayBmb3IgSUNNUCBlcnJvcnMgc2VudCB0byB0aGUgbWFp biBSb290Pw0KPg0KPiAgICBTZWN0aW9uIDUgc2F5cyAiDQo+DQo+DQo+ICAgICAgIEluIGNhc2Ug b2YgYSBmb3J3YXJkaW5nIGVycm9yIGFsb25nIGEgUHJvamVjdGVkIFJvdXRlLCBhbiBJQ01QIGVy cm9yDQo+DQo+ICAgICAgIGlzIHNlbnQgdG8gdGhlIFJvb3Qgd2l0aCBhIG5ldyBDb2RlICJFcnJv ciBpbiBQcm9qZWN0ZWQgUm91dGUiIChTZWUNCj4NCj4gICAgICAgU2VjdGlvbiA3Ljk8aHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWlldGYtcm9sbC1kYW8tcHJvamVjdGlvbi0xNCNz ZWN0aW9uLTcuOT4pLiAgVGhlIFJvb3QgY2FuIHRoZW4gbW9kaWZ5IG9yIHJlbW92ZSB0aGUgUHJv amVjdGVkDQo+DQo+ICAgICAgIFJvdXRlLiAgVGhlICJFcnJvciBpbiBQcm9qZWN0ZWQgUm91dGUi IG1lc3NhZ2UgaGFzIHRoZSBzYW1lIGZvcm1hdCBhcw0KPg0KPiAgICAgICB0aGUgIkRlc3RpbmF0 aW9uIFVucmVhY2hhYmxlIE1lc3NhZ2UiLCBhcyBzcGVjaWZpZWQgaW4gUkZDIDQ0NDM8aHR0cHM6 Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzQ0NDM+DQo+DQo+ICAgICAgIFtSRkM0NDQzPGh0dHBz Oi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0NDQzPl0uDQo+DQo+ICAgICINCj4NCj4gICAgU28g eWVzIHRoZSBpbnRlbnRpb24gd2FzIHRvIHNlbmQgdGhlIElDTVAgdG8gdGhlIG1haW4gUm9vdC4g QnV0IGFzIHlvdSBwb2ludCBvdXQgdGhlIHBhY2tldCBkb2VzIG5vdCBpbmRpY2F0ZSBpdCBpcyBm b2xsb3dpbmcgYSBQLXJvdXRlLiBUaGlzIHdhcyByZWxhdGVkIHRvIHN0b3JpbmcgbW9kZSBQIERB Ty4gSW4gbm9uLXN0b3JpbmcgdGhlIG5vZGUgZG9lcyBub3Qga25vdyBpdCdzIGEgUC1yb3V0ZS4N Cj4NCj4NCj4+IEluIG5vbi1zdG9yaW5nIFBEQU8sIGZvcndhcmRlciBjYW4ndCByZWNvZ25pemUg d2hldGhlciBkYXRhIHBhY2tldCBpcyBpbiBQREFPIGluc3RhbmNlLiBGb3J3YXJkZXIgc2hvdWxk IHNlbmQgSUNNUCBEZXN0aW5hdGlvbiBVbnJlYWNoYWJsZSBlcnJvciB0byByb290ICh0aGUgc291 cmNlIG9mIHRoZSBwYWNrZXQpLCB0aGVuIHJvb3QgZ2VuZXJhdGVzIElDTVB2NiBlcnJvciBtZXNz YWdlIHdpdGggIkVycm9yIGluIFByb2plY3RlZCBSb3V0ZSIgdG8gbWFpbiBSb290LiAgSXMgaXQg Y29ycmVjdD8NCj4NCj4gICAgVGhhdCB3b3VsZCB3b3JrLiBTZWVtcyBuZWF0LiBUaGUgYWx0ZXJu YXRlIHdvdWxkIGJlIHRvIHNpZ25hbCBpdCBpcyBhIFAgcm91dGUgaW4gdGhlIFJQSS4gVGhhdCdz IGl0ZW0gMikgaW4gdGhlIGxpc3QgaW4gdGhpcyB0aHJlYWQuIElmIHdlIGRvIHRoYXQgdGhlIGN1 cnJlbnQgdGV4dCB3b3Jrcy4gV2hhdCBtYWtlcyBtb3JlIHNlbnNlIHRvIHlvdT8NCj4NCj4+IElu IHN0b3JpbmcgUERBTywgZm9yd2FyZGVyIGNhbiByZWNvZ25pemUgdGhlIFBEQU8gaW5zdGFuY2Ug ZnJvbSB0aGUgUlBJLiBJdCBjYW4gc2VuZCAiRXJyb3IgaW4gUHJvamVjdGVkIFJvdXRlIiBvciAg IkRlc3RpbmF0aW9uIFVucmVhY2hhYmxlIGVycm9yIiB0byByb290LiBNYXliZSB3ZSBuZWVkIG1v cmUgY2xhaW1zIGZvciB3aGljaCBjb2RlIGZvcndhcmRlciBzaG91bGQgdXNlLg0KPg0KPiAgICBX ZSBoYXZlIHRvIGRlY2lkZSBpZiB3ZSBzZW5kIGl0IHRvIHRoZSBtYWluIHJvb3QgYXMgd3JpdHRl biBpbiB0aGUgY3VycmVudCBkcmFmdCBvciB0byB0aGUgVHJhY2sgUm9vdC4gSWYgdGhlIFAgcm91 dGUgaXMgcmV2ZXJzaWJsZSBjb3VsZCBiZSBkb25lIHRoYXQgd2F5LiBCdXQgdGhhdCdzIGFkZGVk IGNvbXBsZXhpdHkuIEknbSBub3QgdmVyeSBjb252aW5jZWQgZWl0aGVyIHdheS4gVGhlIE9raGFt IHJhem9yIGNvdWxkIGJlIHRvIGRvIHRoZSBzaW1wbGVzdC4NCj4NCj4gICAgS2VlcCBzYWZlIQ0K Pg0KPiAgICBQYXNjYWwNCj4NCj4NCj4NCj4NCj4NCj4gX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj4gUm9sbCBtYWlsaW5nIGxpc3QNCj4gUm9sbEBpZXRm Lm9yZzxtYWlsdG86Um9sbEBpZXRmLm9yZz4NCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1h bi9saXN0aW5mby9yb2xsDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KUm9sbCBtYWlsaW5nIGxpc3QNClJvbGxAaWV0Zi5vcmc8bWFpbHRvOlJvbGxAaWV0 Zi5vcmc+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3JvbGwNCg== --_000_PH0PR11MB488590F8FA7632517929B0F1D8F40PH0PR11MB4885namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25s eTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4w cHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiIHN0eWxlPSJ3b3JkLXdyYXA6YnJl YWstd29yZCI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPkhlbGxvIExpPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQiPkJ1dCBQLURBTyBkb2VzIG5vdCBkaXN0cmlidXRlIGEgUmFuay4g VGhlIG5ldyBQLVNSSC02TG9SSCBlbGlkZXMgaXQuIFNvIHRoZSDigJhS4oCZIGZsYWcgZG9lcyBu b3QgbWFrZSBzZW5zZSBlaXRoZXIuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij5Gb3Igbm93IHRoZSBUcmFjayBpcyBub3QgcmV2ZXJzaWJsZSwg c28gdGhlIOKAmE/igJkgZmxhZyBpcyB1c2VsZXNzIGFzIHdlbGwuPG86cD48L286cD48L3NwYW4+ PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNh bGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFj ZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkkgd2FzIHdvbmRlcmlu ZyBmb3IgdGhlIOKAmEbigJkgZmxhZy4gV2UgY291bGQgc3RpbGwgdXNlIGl0IGluIGJvdGggbW9k ZXMuIEJ1dCB0aGF0IGlzIGV4dHJhIGNvZGUsIGxpdHRsZSB2YWx1ZSBzaW5jZSB0aGUgSUNNUCB0 byB0aGUgcm9vdCBpcyBhbHJlYWR5IHRoZXJlLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250 PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmki PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5GaW5hbGx5LCB5b3XigJlsbCBmaW5kIHRo YXQgdGhlcmUgaXMgbm8gcm9vbSBsZWZ0IGluDQo8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ291cmllciBOZXci PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIg TmV3JnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAxJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDI8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ291cmllciBOZXciPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3 JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMCAxIDIgMyA0IDUgNiA3 IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDM8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ291cmllciBO ZXciPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9u dD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDb3VyaWVy IE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291 cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8MXwwfEV8IExlbmd0 aCZuYnNwOyB8IDZMb1JIIFR5cGUgNyZuYnNwOyB8IFJQTEluc3RhbmNlSUQgfDxvOnA+PC9vOnA+ PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIyIiBm YWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAr LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPG86cD48L286 cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIi IGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6 ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoYXQg aXMgYmVjYXVzZSBJIHdhbnQgdGhlIFAtUlBJLTZMb1JIIHRvIGJlIGVpdGhlciBlbGVjdGl2ZSBv ciBjcml0aWNhbCwgd2hpY2ggaW1wbGllcyB0aGF0IGJ1dHMgMy4uNyBhcmUgYSBsZW5ndGgsIG5v IHJvb20gZm9yIHRoZSDigJhG4oCZIGJpdC48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkZvciBtZW1vcnksIHRoZSBSUEktNkxvUkggaXMgY3Jp dGljYWwsIHlvdSBIQVZFIHRvIHN1cHBvcnQgaXQgaWYgaXQgaXMgaW4gdGhlIHBhY2tldCwgZWxz ZSB5b3UgZHJvcC4gSW4gdGhlIGFib3ZlIGZvcm1hdCwgaWYgdGhlIOKAmEXigJkgYml0IGlzIHNl dCwgdGhlIGltcGxlbWVudGF0aW9uIGNhbiBmdWxseSBpZ25vcmUNCiB0aGUgUlBJICh0aGF04oCZ cyBvbmUgb2YgdGhlIG5pY2UgdGhpbmdzIGFib3V0IFJGQyA4MTM4KSwgd2hpY2ggY2FuIGJlIE9L IGluIHNvbWUgc3RyaWN0IHNvdXJjZSByb3V0aW5nIHNpdHVhdGlvbnMuDQo8bzpwPjwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFj ZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIy IiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+U28gSSB0aG91 Z2h0LCBsZXQgdXMgaWdub3JlIGFsbCB0aGUgYml0cyBhbmQga2VlcCB0aGluZ3Mgc2ltcGxlLjxv OnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBz aXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxm b250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 Ij5Xb3Jrcz88bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Zm9udCBzaXplPSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdCI+UGFzY2FsPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3Bh ZGRpbmc6MGNtIDBjbSAwY20gNC4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25l O2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNt Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmki PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtd2VpZ2h0OmJvbGQiPkZyb206PC9z cGFuPjwvZm9udD48L2I+IFJvbGwgJmx0O3JvbGwtYm91bmNlc0BpZXRmLm9yZyZndDsNCjxiPjxz cGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5PbiBCZWhhbGYgT2YgPC9zcGFuPjwvYj5MaSBa aGFvIChsaXozKTxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5TZW50Ojwv c3Bhbj48L2I+IG1hcmRpIDEgZMOpY2VtYnJlIDIwMjAgMDY6MzU8YnI+DQo8Yj48c3BhbiBzdHls ZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86PC9zcGFuPjwvYj4gUm91dGluZyBPdmVyIExvdyBwb3dl ciBhbmQgTG9zc3kgbmV0d29ya3MgJmx0O3JvbGxAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+PHNwYW4g c3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6PC9zcGFuPjwvYj4gUmU6IFtSb2xsXSBF cnJvciBmbG93cywgd2hpY2ggSUNNUCBlcnJvcnMgYW5kIHRvIHdoaWNoIHJvb3Q8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXplPSIy IiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250IHNp emU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5IZWxs bzwvc3Bhbj48L2ZvbnQ+PGZvbnQgc2l6ZT0iMiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQiPiBQYXNjYWwsPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPk9uZSBjb25jZXJuIGZvciBzZWN0aW9uIDQg4oCcRXh0ZW5kaW5nIFJG QyA2NTUz4oCdLg0KPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij5BcmUgb3RoZXIgZmllbGRzIOKAnCdPJywgJ1InLCAnRicgZmxhZ3MsIFNlbmRl clJhbmsg4oCdIG5lY2Vzc2FyeSB0byBiZSB6ZXJvIGlmIOKAmFDigJkgZmxhZyBpcyBzZXQ/DQo8 bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQg c2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkZv ciBzdG9yaW5nLVBEQU8sIG1heWJlIHdlIGNhbiBsZXZlcmFnZSB0aGVzZSBmaWVsZHMgZm9yIGVy cm9yLWRldGVjdGlvbiBpZiBuZWVkLiBTbyBkbyB3ZSBuZWVkIHJlcGxhY2Ug4oCcTVVTVOKAnSB0 byDigJxTSE9VTETigJ0gb3Ig4oCcTUFZ4oCdIHRvIGtlZXAgdGhlIGZsZXhpYmlsaXR5PzxvOnA+ PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Zm9udCBzaXpl PSIyIiBmYWNlPSJDYWxpYnJpIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxmb250 IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPkJlc3QgcmVnYXJkcyw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGZvbnQgc2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQiPkxpPC9zcGFuPjwvZm9udD48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxmb250IHNpemU9IjIiIGZhY2U9IkNhbGlicmkiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KPGRp diBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRp bmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp bi1ib3R0b206MTIuMHB0Ij48Yj48Zm9udCBzaXplPSIzIiBjb2xvcj0iYmxhY2siIGZhY2U9IkNh bGlicmkiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrO2ZvbnQtd2Vp Z2h0OmJvbGQiPkZyb206DQo8L3NwYW4+PC9mb250PjwvYj48Zm9udCBzaXplPSIzIiBjb2xvcj0i YmxhY2siPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Sb2xsICZs dDs8L3NwYW4+PC9mb250PjxhIGhyZWY9Im1haWx0bzpyb2xsLWJvdW5jZXNAaWV0Zi5vcmciPjxm b250IHNpemU9IjMiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0Ij5yb2xsLWJvdW5jZXNA aWV0Zi5vcmc8L3NwYW4+PC9mb250PjwvYT48Zm9udCBzaXplPSIzIiBjb2xvcj0iYmxhY2siPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4mZ3Q7PGJyPg0KPGI+PHNw YW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj48L2I+TW9uZGF5LCBOb3Zl bWJlciAzMCwgMjAyMCBhdCAxNzoyODxicj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpi b2xkIj5UbzogPC9zcGFuPjwvYj5Sb3V0aW5nIE92ZXIgTG93IHBvd2VyIGFuZCBMb3NzeSBuZXR3 b3JrcyAmbHQ7PC9zcGFuPjwvZm9udD48YSBocmVmPSJtYWlsdG86cm9sbEBpZXRmLm9yZyI+PGZv bnQgc2l6ZT0iMyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQiPnJvbGxAaWV0Zi5vcmc8 L3NwYW4+PC9mb250PjwvYT48Zm9udCBzaXplPSIzIiBjb2xvcj0iYmxhY2siPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj4mZ3Q7PGJyPg0KPGI+PHNwYW4gc3R5bGU9 ImZvbnQtd2VpZ2h0OmJvbGQiPlN1YmplY3Q6IDwvc3Bhbj48L2I+UmU6IFtSb2xsXSBFcnJvciBm bG93cywgd2hpY2ggSUNNUCBlcnJvcnMgYW5kIHRvIHdoaWNoIHJvb3Q8bzpwPjwvbzpwPjwvc3Bh bj48L2ZvbnQ+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGZvbnQg c2l6ZT0iMiIgZmFjZT0iQ2FsaWJyaSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlll cyBIdWltaW48YnI+DQo8YnI+DQpBbmQgdGhpcyBpcyB0aGUgbm9ybWFsIGJlaGF2aW9yLjxicj4N Cjxicj4NCldpdGggUERBTyB3ZSBjcmVhdGVkIHRoZSB1bnVzdWFsIGJlaGF2aW9yIHRvIHNlbmQg dGhlIGVycm9yIGluIHAtcm91dGUgdG8gdGhlIHJvb3QuIFRoaXMgd2FzIHRvIG1ha2UgdGhpbmdz IGZhc3RlciBzaW5jZSB0aGUgY29tbXVuaWNhdGlvbiB0aHJvdWdoIHRoZSBUcmFjayBpcyBkaXJl Y3Rpb25hbCBzbyB5b3UgY2Fubm90IHRhbGsgYmFjay4gQWxzbyBpbiBub24gc3RvcmluZyB0YWxr aW5nIHRvIHRoZSBzb3VyY2UgaXMgdmlhIHRoZSBSb290IGFuZA0KIHVsdGltYXRlbHkgdGhlIFJv b3QgbmVlZHMgdG8gdXBkYXRlIHRoZSBQIERBTy48YnI+DQo8YnI+DQpXaXRoIFJBVyB3ZSBtYXkg d2FudCB0byB0byBzb21ldGhpbmcgZmFzdGVyIGJ1dCB1bmNsZWFyIGZvciBub3cuPGJyPg0KPGJy Pg0KUGxlYXNlIG5vdGUgdGhhdCBhZnRlciB0aGUgZGlzY3Vzc2lvbiB3aXRoIHlvdSBhbmQgTGkg SSBwdWJsaXNoZWQgYSByZXZpc2lvbiB0aGF0IGhhcyB0aGUgZmxhZyBpbiB0aGUgUlBJIHRoYXQg aW5kaWNhdGVzIHRoYXQgdGhlIHBhY2tldCBpcyBmb3J3YXJkZWQgb24gYSBQLXJvdXRlLjxicj4N Cjxicj4NCkRvIHlvdSB3YW50IHRvIGNoYW5nZSB0aGUgZXJyb3IgZmxvdz88YnI+DQo8YnI+DQpQ YXNjYWw8YnI+DQo8YnI+DQomZ3Q7IExlIDMwIG5vdi4gMjAyMCDDoCAwOToxNSwgSHVpbWluIFNo ZSAoaHVzaGUpICZsdDs8L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmh1c2hlPTQwY2lzY28uY29tQGRt YXJjLmlldGYub3JnIj5odXNoZT00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZzwvYT48L2ZvbnQ+ Jmd0OyBhIMOpY3JpdCA6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IO+7v0hpIFBhc2NhbCw8YnI+DQom Z3Q7IDxicj4NCiZndDsgUkZDIDY1NTAgc2VjdGlvbiAxMS4xIHNheXMgdGhlIElDTVB2NiBlcnJv ciBpbiBTUkggc2hvdWxkIGJlIHNlbnQgdG8gdGhlIHNvdXJjZSBvZiB0aGUgcGFja2V0Ljxicj4N CiZndDsgPGJyPg0KJmd0OyBCZXN0IHJlZ2FyZHMsPGJyPg0KJmd0OyBIdWltaW48YnI+DQomZ3Q7 IDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgTWVzc2FnZTogMjxicj4NCiZndDsmbmJzcDsm bmJzcDsmbmJzcDsgRGF0ZTogRnJpLCAyNyBOb3YgMjAyMCAwNzo0NzoyMiArMDAwMDxicj4NCiZn dDsmbmJzcDsmbmJzcDsmbmJzcDsgRnJvbTogJnF1b3Q7UGFzY2FsIFRodWJlcnQgKHB0aHViZXJ0 KSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnB0aHViZXJ0QGNpc2NvLmNvbSI+cHRodWJlcnRA Y2lzY28uY29tPC9hPiZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRvOiBSb3V0aW5n IE92ZXIgTG93IHBvd2VyIGFuZCBMb3NzeSBuZXR3b3JrcyAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJv bGxAaWV0Zi5vcmciPnJvbGxAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZndDsmbmJzcDsmbmJzcDsm bmJzcDsgU3ViamVjdDogW1JvbGxdIEVycm9yIGZsb3dzLCB3aGljaCBJQ01QIGVycm9ycyBhbmQg dG8gd2hpY2ggcm9vdD86PGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBbZXh0ZW5kc10gSUVURiAxMDkgb3BlbiBRdWVzdGlvbnMgb24gUC1EQU88YnI+ DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IE1lc3NhZ2UtSUQ6PGJyPg0KJmd0OyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7PGEgaHJlZj0ibWFpbHRvOkNPMVBS MTFNQjQ4ODFBNzI0QjA0RUEyOUQzMkRDOUM4MUQ4RjgwQENPMVBSMTFNQjQ4ODEubmFtcHJkMTEu cHJvZC5vdXRsb29rLmNvbSI+Q08xUFIxMU1CNDg4MUE3MjRCMDRFQTI5RDMyREM5QzgxRDhGODBA Q08xUFIxMU1CNDg4MS5uYW1wcmQxMS5wcm9kLm91dGxvb2suY29tPC9hPiZndDs8YnI+DQomZ3Q7 IDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBj aGFyc2V0PSZxdW90O3VzLWFzY2lpJnF1b3Q7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7IEhlbGxvIExpPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IFRoaXMgaXMgdGhlIHdyb25nIHRocmVhZC4gSSBjcmVhdGVkIGEgbmV3IG9uZS48YnI+DQomZ3Q7 IDxicj4NCiZndDsmZ3Q7IFNlY3Rpb24gNy45IG9mIHBkYW8tZHJhZnQgZGVmaW5lcyBhIG5ldyBj b2RlIGZvciZuYnNwOyBJQ01QdjYgZXJyb3IgbWVzc2FnZSAmcXVvdDtFcnJvciBpbiBQcm9qZWN0 ZWQgUm91dGUmcXVvdDsuIERvZXMgaXQgb25seSB3b3JrIGZvciBJQ01QIGVycm9ycyBzZW50IHRv IHRoZSBtYWluIFJvb3Q/PGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFNl Y3Rpb24gNSBzYXlzICZxdW90Ozxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEluIGNhc2Ugb2YgYSBmb3J3YXJkaW5nIGVy cm9yIGFsb25nIGEgUHJvamVjdGVkIFJvdXRlLCBhbiBJQ01QIGVycm9yPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGlzIHNlbnQgdG8gdGhl IFJvb3Qgd2l0aCBhIG5ldyBDb2RlICZxdW90O0Vycm9yIGluIFByb2plY3RlZCBSb3V0ZSZxdW90 OyAoU2VlPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IFNlY3Rpb24gNy45Jmx0OzxhIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRt bC9kcmFmdC1pZXRmLXJvbGwtZGFvLXByb2plY3Rpb24tMTQjc2VjdGlvbi03LjkiPmh0dHBzOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJvbGwtZGFvLXByb2plY3Rpb24tMTQjc2Vj dGlvbi03Ljk8L2E+Jmd0OykuJm5ic3A7IFRoZSBSb290IGNhbiB0aGVuIG1vZGlmeSBvciByZW1v dmUgdGhlIFByb2plY3RlZDxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBSb3V0ZS4mbmJzcDsgVGhlICZxdW90O0Vycm9yIGluIFByb2plY3Rl ZCBSb3V0ZSZxdW90OyBtZXNzYWdlIGhhcyB0aGUgc2FtZSBmb3JtYXQgYXM8YnI+DQomZ3Q7IDxi cj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgdGhlICZxdW90O0Rl c3RpbmF0aW9uIFVucmVhY2hhYmxlIE1lc3NhZ2UmcXVvdDssIGFzIHNwZWNpZmllZCBpbiBSRkMg NDQ0MyZsdDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDQ0MyI+aHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzQ0NDM8L2E+Jmd0Ozxicj4NCiZndDsgPGJyPg0K Jmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBbUkZDNDQ0MyZsdDs8YSBo cmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDQ0MyI+aHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzQ0NDM8L2E+Jmd0O10uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZxdW90Ozxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNw OyBTbyB5ZXMgdGhlIGludGVudGlvbiB3YXMgdG8gc2VuZCB0aGUgSUNNUCB0byB0aGUgbWFpbiBS b290LiBCdXQgYXMgeW91IHBvaW50IG91dCB0aGUgcGFja2V0IGRvZXMgbm90IGluZGljYXRlIGl0 IGlzIGZvbGxvd2luZyBhIFAtcm91dGUuIFRoaXMgd2FzIHJlbGF0ZWQgdG8gc3RvcmluZyBtb2Rl IFAgREFPLiBJbiBub24tc3RvcmluZyB0aGUgbm9kZSBkb2VzIG5vdCBrbm93IGl0J3MgYSBQLXJv dXRlLjxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jmd0OyBJbiBub24tc3RvcmluZyBQ REFPLCBmb3J3YXJkZXIgY2FuJ3QgcmVjb2duaXplIHdoZXRoZXIgZGF0YSBwYWNrZXQgaXMgaW4g UERBTyBpbnN0YW5jZS4gRm9yd2FyZGVyIHNob3VsZCBzZW5kIElDTVAgRGVzdGluYXRpb24gVW5y ZWFjaGFibGUgZXJyb3IgdG8gcm9vdCAodGhlIHNvdXJjZSBvZiB0aGUgcGFja2V0KSwgdGhlbiBy b290IGdlbmVyYXRlcyBJQ01QdjYgZXJyb3IgbWVzc2FnZSB3aXRoICZxdW90O0Vycm9yIGluIFBy b2plY3RlZCBSb3V0ZSZxdW90Ow0KIHRvIG1haW4gUm9vdC4mbmJzcDsgSXMgaXQgY29ycmVjdD88 YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhhdCB3b3VsZCB3b3JrLiBT ZWVtcyBuZWF0LiBUaGUgYWx0ZXJuYXRlIHdvdWxkIGJlIHRvIHNpZ25hbCBpdCBpcyBhIFAgcm91 dGUgaW4gdGhlIFJQSS4gVGhhdCdzIGl0ZW0gMikgaW4gdGhlIGxpc3QgaW4gdGhpcyB0aHJlYWQu IElmIHdlIGRvIHRoYXQgdGhlIGN1cnJlbnQgdGV4dCB3b3Jrcy4gV2hhdCBtYWtlcyBtb3JlIHNl bnNlIHRvIHlvdT88YnI+DQomZ3Q7IDxicj4NCiZndDsmZ3Q7IEluIHN0b3JpbmcgUERBTywgZm9y d2FyZGVyIGNhbiByZWNvZ25pemUgdGhlIFBEQU8gaW5zdGFuY2UgZnJvbSB0aGUgUlBJLiBJdCBj YW4gc2VuZCAmcXVvdDtFcnJvciBpbiBQcm9qZWN0ZWQgUm91dGUmcXVvdDsgb3ImbmJzcDsgJnF1 b3Q7RGVzdGluYXRpb24gVW5yZWFjaGFibGUgZXJyb3ImcXVvdDsgdG8gcm9vdC4gTWF5YmUgd2Ug bmVlZCBtb3JlIGNsYWltcyBmb3Igd2hpY2ggY29kZSBmb3J3YXJkZXIgc2hvdWxkIHVzZS48YnI+ DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgV2UgaGF2ZSB0byBkZWNpZGUgaWYg d2Ugc2VuZCBpdCB0byB0aGUgbWFpbiByb290IGFzIHdyaXR0ZW4gaW4gdGhlIGN1cnJlbnQgZHJh ZnQgb3IgdG8gdGhlIFRyYWNrIFJvb3QuIElmIHRoZSBQIHJvdXRlIGlzIHJldmVyc2libGUgY291 bGQgYmUgZG9uZSB0aGF0IHdheS4gQnV0IHRoYXQncyBhZGRlZCBjb21wbGV4aXR5LiBJJ20gbm90 IHZlcnkgY29udmluY2VkIGVpdGhlciB3YXkuIFRoZSBPa2hhbSByYXpvciBjb3VsZCBiZSB0byBk byB0aGUNCiBzaW1wbGVzdC48YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsg S2VlcCBzYWZlITxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBQYXNjYWw8 YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJy Pg0KJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCiZndDsgUm9sbCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IDxhIGhyZWY9Im1haWx0bzpSb2xs QGlldGYub3JnIj5Sb2xsQGlldGYub3JnPC9hPjxicj4NCiZndDsgPGEgaHJlZj0iaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3JvbGw8L2E+PGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX188YnI+DQpSb2xsIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9 Im1haWx0bzpSb2xsQGlldGYub3JnIj5Sb2xsQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbCI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xsPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_PH0PR11MB488590F8FA7632517929B0F1D8F40PH0PR11MB4885namp_-- From nobody Mon Nov 30 23:05:49 2020 Return-Path: X-Original-To: roll@ietfa.amsl.com Delivered-To: roll@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56B0E3A0CC3 for ; Mon, 30 Nov 2020 23:05:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.619 X-Spam-Level: X-Spam-Status: No, score=-9.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=DA6lo7Q7; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=JDe8Vee3 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 ReJDGHBV04DN for ; Mon, 30 Nov 2020 23:05:45 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16EC83A0CAC for ; Mon, 30 Nov 2020 23:05:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28016; q=dns/txt; s=iport; t=1606806345; x=1608015945; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=JErL2xJlCmDkwm1Al+gGiNvwRltLizTC4Avoz2SzxA0=; b=DA6lo7Q71fcc9yU9be71YKdGyZ0hfV4qTgGeBu6iBMHvBBbXaE0t36+p 4WnGRTr06rNG5NrvkJsKSjQjt38qyYIaEyip+HySC8260xSxhmx6Pg6Bx qLxBIqkLaXnk9WHCZM+U/PbQQ3C0CfpE7DAuKlvul1syFwnak+RiTUwNm M=; X-IPAS-Result: =?us-ascii?q?A0B0BwCo6cVffY9dJa1cBh0BAQEBCQESAQUFAYIPgSMvI?= =?us-ascii?q?y58Wi8ug3xAg0kDjVmZBoFCgREDVAsBAQENAQEYAQwIAgQBAYE0gxYCF4ISA?= =?us-ascii?q?iU4EwIDAQEBAwIDAQEBAQUBAQECAQYEFAEBhjwMhXIBAQEBAgEBAQoGER0BA?= =?us-ascii?q?SwMBAsCAQYCEQMBAQEoAwICAiULFAkIAgQTCBqCfwQCgX5XAw4gAQ6QVZBrA?= =?us-ascii?q?oE8iGl2gTKDBAEBBYUMAxWCEAMGgTiCc4JmTkKGV4IbgRABQ4InLj6CXQEBA?= =?us-ascii?q?gGBHiAOEgUQCQYHCYJhM4IsgUYBkjaHJZ1QBgSCcIkXkjeDIIodlF+VbIkFk?= =?us-ascii?q?S6EPAIEAgQFAg4BAQWBbSEPgUpwUIEegUtQFwINjiGDcYUUhUR0AgE0AgYBC?= =?us-ascii?q?QEBAwl8jmkBAQ?= IronPort-PHdr: =?us-ascii?q?9a23=3A6WyoLxTp/f1ZcFTJCaSfNZrZtdpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESQBN+J6v9YhazRqa+zEWAD4JPUtncEfdQMUh?= =?us-ascii?q?IekswZkkQmB9LNEkz0KvPmLklYVMRPXVNo5Te3ZE5SHsutZlDOrDu19zFBUh?= =?us-ascii?q?n6PBB+c+LyHIOahs+r1ue0rpvUZQgAhDe0bb5oahusqgCEvcgNiowkIaE0mR?= =?us-ascii?q?Y=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-AV: E=Sophos;i="5.78,383,1599523200"; d="scan'208,217";a="604859367" Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Dec 2020 07:05:43 +0000 Received: from XCH-RCD-002.cisco.com (xch-rcd-002.cisco.com [173.37.102.12]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 0B175huR017471 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 1 Dec 2020 07:05:43 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-002.cisco.com (173.37.102.12) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 1 Dec 2020 01:05:43 -0600 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Tue, 1 Dec 2020 02:05:42 -0500 Received: from NAM10-MW2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Tue, 1 Dec 2020 01:05:42 -0600 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=OfjHAp3m0aGvj5I9nmQTrG5AYS65/zquhUkM5kQomYG8F9Lt9JRPRhGzMW40pSbJJDyctClKTvPbJHUI3PPcd7EHqectpUvVRFBG+YTiz6KXstoQiUCdKCTB2+a5O8T3bUy7O1IT1ReYe+OECIW4Ezw9Fq/4H1YLp1MkyWryWVFs8Q3X9nQ/z85dMrXbPAj8BEW4MffHvWD//txcGj8Ee239iLUp75SkPCB/feT8cFRGp4vhwr7/kan5Y70oJQYP7SbKTnKhLs/KKFkyqOxGSoeioRXTS5K29W2oLRH617sfkj7jM6D3uZ2lkosEwUSTC00X+mw/bSDdxiS9Sxzykg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=JErL2xJlCmDkwm1Al+gGiNvwRltLizTC4Avoz2SzxA0=; b=IDVjiB227BH6Y+1+IIhvP987ep+LhOwcUYb/gEJr1kKN7J2Gtcv3J0vHeXCcmwjexe6usENR02fI9uc3r+mmGCJUgKPIXvtqlQ8j9yuVdjkYY7new+/5fBPBlPei4DJSTzJ1VThHCChgpCAiC4Gg7zlqx0b6xxaWbtDjkq/sbvxT3VapTCPGE12SnXG4aa1Ypmqizcd4s2JqnJMitgWUl1ZfK+aeZjdv6rkm6ZCb37cELv46eVX3bDKiqs6DNS96YUgKtNd7AnRujBkv9cFKE1h+CKVCIHqQFfy7uieAmEfri68eg0uLcgtdnhutXaLBx/BS/TdGhGMQKAUydyOCwA== 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=JErL2xJlCmDkwm1Al+gGiNvwRltLizTC4Avoz2SzxA0=; b=JDe8Vee3HcOozVOYimvFcirYc0ZmMzRofEdrteFhsUzMZQlrbSsAiqmT4XtTsdvI4MMWrnk1bSlNi9rUa8NnHkMxx27xtteBR9aFdiKbbMLc7KjnoSF5Rw5XhWVBKw1Gceqzj1dx3HV8vek77c+c/nYAVl1b1f5yZfGsgs5Ebw4= Received: from MWHPR11MB1742.namprd11.prod.outlook.com (2603:10b6:300:113::13) by MWHPR11MB1789.namprd11.prod.outlook.com (2603:10b6:300:108::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3611.25; Tue, 1 Dec 2020 07:05:40 +0000 Received: from MWHPR11MB1742.namprd11.prod.outlook.com ([fe80::19ac:46a:36f1:4dfa]) by MWHPR11MB1742.namprd11.prod.outlook.com ([fe80::19ac:46a:36f1:4dfa%3]) with mapi id 15.20.3611.025; Tue, 1 Dec 2020 07:05:40 +0000 From: "Li Zhao (liz3)" To: Routing Over Low power and Lossy networks Thread-Topic: [Roll] Error flows, which ICMP errors and to which root Thread-Index: AQHWxvDsqJzT1olGwECZKYhlRsF+1KngaEJHgAFPuoyAAAqV0IAAEA6l Date: Tue, 1 Dec 2020 07:05:40 +0000 Message-ID: References: <26D2BCD1-D47E-46CA-9F3E-781A17A60398@cisco.com>, , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=cisco.com; x-originating-ip: [2001:420:588c:1252:ed42:30ae:45fa:1f11] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3dc0d84f-6357-4df1-2957-08d895c7835b x-ms-traffictypediagnostic: MWHPR11MB1789: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: Igru6RVLGVrytafeeMmgB7qmRfgD6a0yyEld/1qb+kDIU1AvF17n7mzJpoxn8fjaNhga5JAfGmlWXdBxz21ubynTLlwhstjlDdGvxzns76lKjspbWN6JW2bDjkionqciRkv+aRN3FPY7B7NN5Ne5il63EOvcfWClvT7mMoMEDRNpLDahdE2mm6ltm6F8HeKML0fUAHUVa0dqq9ZP8yub49dwWxRd7hMLBQ/U+hh0RNnCpgXg8t4YTcqxRWX+2SpsfSn62WNdXqwqzaFfMhdxDkSZCz6lxXLV3X96QmswKmRbZjmfLXqekGarKnvkB10+8Ys1lVdIAyLjsC3fyGF2gzSRC0MdWOjTFYMcEu2ILzQzqdrHZ2MlB6oQIo1DyTXvoa1oS5FAXSHPjYlf0iUM78+o3M7z4SDnUhapBPxEuNRSJ60W9nd0W8pbRR1cvs3LgQuErfyAdwnWsOcr9bgKhA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:MWHPR11MB1742.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFS:(366004)(39860400002)(376002)(396003)(136003)(346002)(966005)(8936002)(7696005)(2906002)(83380400001)(316002)(8676002)(53546011)(6506007)(55016002)(9686003)(478600001)(71200400001)(5660300002)(66574015)(186003)(6916009)(33656002)(52536014)(86362001)(66946007)(66446008)(64756008)(91956017)(66476007)(76116006)(66556008)(45080400002)(166002)(88722002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: =?utf-8?B?VnJtemh3dE1GNk5DS0piRm5xd0pDUGpOYzJZdktFcjUzRTdERTYyOGNhWU9I?= =?utf-8?B?a1BLOUljM0tubHlyUmxXVTVXNTJHTGV0aHA4V0xGK241V2E1Tmx4UkxxcTkz?= =?utf-8?B?cm5FR2MvZSthMHZPZmZsNkMyRGVXRjhuUHozTFhDcVplUmRCQWpkazFSQ0xu?= =?utf-8?B?cDFJZVNWTW5PMTZ2SjY2Zi9saUhMN0JtUnRZbUdKTzNLU0QvK2ZpMFJkZ2h4?= =?utf-8?B?YlYzUnFWbHJLM1FVZkZlYlo0QVdzbGVXdVFoTnBtL09OazBIdE1wL2dXdXEr?= =?utf-8?B?ZDdCWTJWMTNOYWM2K1ozVmxYc1FHbE9Ud09KeUlOVDVteTY3OEV0RGlIU0g5?= =?utf-8?B?eDRtZklMKzdNUitZUlQ2dGtYbGdjZHR1K1g3MSt0Zm8yQXpMbWhHRHNnUmZS?= =?utf-8?B?Q2pQSzVqcndheGF5ZTlsODZqZWJvdGNvc0Z4T0RYOXhsNDNVNWtiTDYyVkx0?= =?utf-8?B?WnF6RXFaMHlpcU93dlM3Zkt6ZW4zMHdVWitXbWNiNkpGeGxVaW5IMXR4Zmdl?= =?utf-8?B?R1R1NlpmQ3JKWTYrUFhVWGtSQW45NmIwT1ZBNjNpdG9JWDllZ0VDbXFDVm01?= =?utf-8?B?RmF4Rzh4TkVzNEtvcHVXOWxxL3cyTERsc0hZVUZBeU02RWFBQ1hpNkNVY2E3?= =?utf-8?B?MDJqLzI0L3liZ1lKbG1tV3RPZ2hDRzlkam01M0d1MlBIVDlhOXZNUTNHTkFK?= =?utf-8?B?bXhMTldVc3ZuUGoxVmoxTXNQM1BKSHluWGpGZTNYS1pFUjcwMVZWdHdod3Ft?= =?utf-8?B?eW9pZmdOanY5eEZMdGxua1pDcDNXOVpiVzFiQlo0UEp1bGNsWGJUM01xenVF?= =?utf-8?B?UFZRMiszaHc1Zk5hTHFqZUFUQ1gwZWR1YWNTajZJbVpSQUI4ekhxRVUwV3hy?= =?utf-8?B?Y1lnZjNVMyszbmhDd3dHYmdKTXltSktnejRJR0xGanc5R05WSUdUdWxNWEgz?= =?utf-8?B?N2dhSTh6K2lFTklYTVQ0VzZxajFMMkdkV2RaM0dtY0ZVSm5SV1kzK2FhSmdH?= =?utf-8?B?ZWRaUE1xV28xZFZxQjdQTWF4Yk9QVHhkeEFyOHR0Ui9ORWxPcE4xbmJGemtV?= =?utf-8?B?UmUrMVlOUDg0QjFsdXVqV3lOVWtpbk1DT0wzM1RtT1ZTRmU1YnYwOUJiMHg2?= =?utf-8?B?dVRvWDJQTFhXT0tKRDhvaTZNZStZS2R0bUlvNjZ3N3NEOTQwUkJnV3pSYkZu?= =?utf-8?B?eDJhdGx3TVErNkZIK1VNb2ZqWmhORUFYVEpwSGI3Vk9QMWc4amkzdXFiWHdT?= =?utf-8?B?R05laW5ncVJ2UHZ5aGpSZndaRElXcXFWa2Ntb2hMMW5OSGswR1VId3p5V1Nt?= =?utf-8?B?TDlSSFdmOVBBTksxTEFZbkdmMTB6MnZZOFAvb3RNU1YzRkFNYWRvS2htQnlv?= =?utf-8?B?MmRCdjUwczUveGV2RkZGaFlhMXgycm1aYkFZQjRuVGxlaUp1T2d5SnpsK1hu?= =?utf-8?B?TW4vUVN0Z2FaaVp1bkkxVjlPKzlqemlCWVRhNmlBPT0=?= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_MWHPR11MB17422A28AE90AC86F8CEBEEF8CF40MWHPR11MB1742namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: MWHPR11MB1742.namprd11.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3dc0d84f-6357-4df1-2957-08d895c7835b X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Dec 2020 07:05:40.5996 (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: YWRRslo7shQaT9DMmc+F7eU2Q5ohru3nAJC40Bxe1/M+EQEkWm9wQKZjGpgof6Nf X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR11MB1789 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.12, xch-rcd-002.cisco.com X-Outbound-Node: rcdn-core-7.cisco.com Archived-At: Subject: Re: [Roll] Error flows, which ICMP errors and to which root 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, 01 Dec 2020 07:05:47 -0000 --_000_MWHPR11MB17422A28AE90AC86F8CEBEEF8CF40MWHPR11MB1742namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8gUGFzY2FsLA0KDQpBZ3JlZSB3aXRoIHlvdS4gQXMgdGhlcmUgaXMgbm8gcm9vbSBsZWZ0 IGluIFAtUlBJLTZMb1JILCBsZXTigJlzIGlnbm9yZSBhbGwgdGhlIGJpdHMgYW5kIGtlZXAgdGhp bmdzIHNpbXBsZS4NCg0KQmVzdCByZWdhcmRzLA0KTGkNCg0KRnJvbTogUm9sbCA8cm9sbC1ib3Vu Y2VzQGlldGYub3JnPg0KRGF0ZTogVHVlc2RheSwgRGVjZW1iZXIgMSwgMjAyMCBhdCAxNDozNg0K VG86IFJvdXRpbmcgT3ZlciBMb3cgcG93ZXIgYW5kIExvc3N5IG5ldHdvcmtzIDxyb2xsQGlldGYu b3JnPg0KU3ViamVjdDogUmU6IFtSb2xsXSBFcnJvciBmbG93cywgd2hpY2ggSUNNUCBlcnJvcnMg YW5kIHRvIHdoaWNoIHJvb3QNCkhlbGxvIExpDQoNCkJ1dCBQLURBTyBkb2VzIG5vdCBkaXN0cmli dXRlIGEgUmFuay4gVGhlIG5ldyBQLVNSSC02TG9SSCBlbGlkZXMgaXQuIFNvIHRoZSDigJhS4oCZ IGZsYWcgZG9lcyBub3QgbWFrZSBzZW5zZSBlaXRoZXIuDQpGb3Igbm93IHRoZSBUcmFjayBpcyBu b3QgcmV2ZXJzaWJsZSwgc28gdGhlIOKAmE/igJkgZmxhZyBpcyB1c2VsZXNzIGFzIHdlbGwuDQoN Ckkgd2FzIHdvbmRlcmluZyBmb3IgdGhlIOKAmEbigJkgZmxhZy4gV2UgY291bGQgc3RpbGwgdXNl IGl0IGluIGJvdGggbW9kZXMuIEJ1dCB0aGF0IGlzIGV4dHJhIGNvZGUsIGxpdHRsZSB2YWx1ZSBz aW5jZSB0aGUgSUNNUCB0byB0aGUgcm9vdCBpcyBhbHJlYWR5IHRoZXJlLg0KDQpGaW5hbGx5LCB5 b3XigJlsbCBmaW5kIHRoYXQgdGhlcmUgaXMgbm8gcm9vbSBsZWZ0IGluDQoNCiAgICAgICAgICAg ICAgICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMg0KICAgICAgICAg ICAgICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzDQog ICAgICAgICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rDQogICAgICAgICAgICAgICB8MXwwfEV8IExlbmd0aCAgfCA2TG9SSCBUeXBlIDcgIHwg UlBMSW5zdGFuY2VJRCB8DQogICAgICAgICAgICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rDQoNClRoYXQgaXMgYmVjYXVzZSBJIHdhbnQgdGhlIFAt UlBJLTZMb1JIIHRvIGJlIGVpdGhlciBlbGVjdGl2ZSBvciBjcml0aWNhbCwgd2hpY2ggaW1wbGll cyB0aGF0IGJ1dHMgMy4uNyBhcmUgYSBsZW5ndGgsIG5vIHJvb20gZm9yIHRoZSDigJhG4oCZIGJp dC4NCkZvciBtZW1vcnksIHRoZSBSUEktNkxvUkggaXMgY3JpdGljYWwsIHlvdSBIQVZFIHRvIHN1 cHBvcnQgaXQgaWYgaXQgaXMgaW4gdGhlIHBhY2tldCwgZWxzZSB5b3UgZHJvcC4gSW4gdGhlIGFi b3ZlIGZvcm1hdCwgaWYgdGhlIOKAmEXigJkgYml0IGlzIHNldCwgdGhlIGltcGxlbWVudGF0aW9u IGNhbiBmdWxseSBpZ25vcmUgdGhlIFJQSSAodGhhdOKAmXMgb25lIG9mIHRoZSBuaWNlIHRoaW5n cyBhYm91dCBSRkMgODEzOCksIHdoaWNoIGNhbiBiZSBPSyBpbiBzb21lIHN0cmljdCBzb3VyY2Ug cm91dGluZyBzaXR1YXRpb25zLg0KDQpTbyBJIHRob3VnaHQsIGxldCB1cyBpZ25vcmUgYWxsIHRo ZSBiaXRzIGFuZCBrZWVwIHRoaW5ncyBzaW1wbGUuDQoNCldvcmtzPw0KDQpQYXNjYWwNCg0KDQpG cm9tOiBSb2xsIDxyb2xsLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBMaSBaaGFvIChs aXozKQ0KU2VudDogbWFyZGkgMSBkw6ljZW1icmUgMjAyMCAwNjozNQ0KVG86IFJvdXRpbmcgT3Zl ciBMb3cgcG93ZXIgYW5kIExvc3N5IG5ldHdvcmtzIDxyb2xsQGlldGYub3JnPg0KU3ViamVjdDog UmU6IFtSb2xsXSBFcnJvciBmbG93cywgd2hpY2ggSUNNUCBlcnJvcnMgYW5kIHRvIHdoaWNoIHJv b3QNCg0KSGVsbG8gUGFzY2FsLA0KDQpPbmUgY29uY2VybiBmb3Igc2VjdGlvbiA0IOKAnEV4dGVu ZGluZyBSRkMgNjU1M+KAnS4NCkFyZSBvdGhlciBmaWVsZHMg4oCcJ08nLCAnUicsICdGJyBmbGFn cywgU2VuZGVyUmFuayDigJ0gbmVjZXNzYXJ5IHRvIGJlIHplcm8gaWYg4oCYUOKAmSBmbGFnIGlz IHNldD8NCkZvciBzdG9yaW5nLVBEQU8sIG1heWJlIHdlIGNhbiBsZXZlcmFnZSB0aGVzZSBmaWVs ZHMgZm9yIGVycm9yLWRldGVjdGlvbiBpZiBuZWVkLiBTbyBkbyB3ZSBuZWVkIHJlcGxhY2Ug4oCc TVVTVOKAnSB0byDigJxTSE9VTETigJ0gb3Ig4oCcTUFZ4oCdIHRvIGtlZXAgdGhlIGZsZXhpYmls aXR5Pw0KDQoNCkJlc3QgcmVnYXJkcywNCkxpDQoNCkZyb206IFJvbGwgPHJvbGwtYm91bmNlc0Bp ZXRmLm9yZzxtYWlsdG86cm9sbC1ib3VuY2VzQGlldGYub3JnPj4NCkRhdGU6IE1vbmRheSwgTm92 ZW1iZXIgMzAsIDIwMjAgYXQgMTc6MjgNClRvOiBSb3V0aW5nIE92ZXIgTG93IHBvd2VyIGFuZCBM b3NzeSBuZXR3b3JrcyA8cm9sbEBpZXRmLm9yZzxtYWlsdG86cm9sbEBpZXRmLm9yZz4+DQpTdWJq ZWN0OiBSZTogW1JvbGxdIEVycm9yIGZsb3dzLCB3aGljaCBJQ01QIGVycm9ycyBhbmQgdG8gd2hp Y2ggcm9vdA0KWWVzIEh1aW1pbg0KDQpBbmQgdGhpcyBpcyB0aGUgbm9ybWFsIGJlaGF2aW9yLg0K DQpXaXRoIFBEQU8gd2UgY3JlYXRlZCB0aGUgdW51c3VhbCBiZWhhdmlvciB0byBzZW5kIHRoZSBl cnJvciBpbiBwLXJvdXRlIHRvIHRoZSByb290LiBUaGlzIHdhcyB0byBtYWtlIHRoaW5ncyBmYXN0 ZXIgc2luY2UgdGhlIGNvbW11bmljYXRpb24gdGhyb3VnaCB0aGUgVHJhY2sgaXMgZGlyZWN0aW9u YWwgc28geW91IGNhbm5vdCB0YWxrIGJhY2suIEFsc28gaW4gbm9uIHN0b3JpbmcgdGFsa2luZyB0 byB0aGUgc291cmNlIGlzIHZpYSB0aGUgUm9vdCBhbmQgdWx0aW1hdGVseSB0aGUgUm9vdCBuZWVk cyB0byB1cGRhdGUgdGhlIFAgREFPLg0KDQpXaXRoIFJBVyB3ZSBtYXkgd2FudCB0byB0byBzb21l dGhpbmcgZmFzdGVyIGJ1dCB1bmNsZWFyIGZvciBub3cuDQoNClBsZWFzZSBub3RlIHRoYXQgYWZ0 ZXIgdGhlIGRpc2N1c3Npb24gd2l0aCB5b3UgYW5kIExpIEkgcHVibGlzaGVkIGEgcmV2aXNpb24g dGhhdCBoYXMgdGhlIGZsYWcgaW4gdGhlIFJQSSB0aGF0IGluZGljYXRlcyB0aGF0IHRoZSBwYWNr ZXQgaXMgZm9yd2FyZGVkIG9uIGEgUC1yb3V0ZS4NCg0KRG8geW91IHdhbnQgdG8gY2hhbmdlIHRo ZSBlcnJvciBmbG93Pw0KDQpQYXNjYWwNCg0KPiBMZSAzMCBub3YuIDIwMjAgw6AgMDk6MTUsIEh1 aW1pbiBTaGUgKGh1c2hlKSA8aHVzaGU9NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmc8bWFpbHRv Omh1c2hlPTQwY2lzY28uY29tQGRtYXJjLmlldGYub3JnPj4gYSDDqWNyaXQgOg0KPg0KPiDvu79I aSBQYXNjYWwsDQo+DQo+IFJGQyA2NTUwIHNlY3Rpb24gMTEuMSBzYXlzIHRoZSBJQ01QdjYgZXJy b3IgaW4gU1JIIHNob3VsZCBiZSBzZW50IHRvIHRoZSBzb3VyY2Ugb2YgdGhlIHBhY2tldC4NCj4N Cj4gQmVzdCByZWdhcmRzLA0KPiBIdWltaW4NCj4NCj4gICAgTWVzc2FnZTogMg0KPiAgICBEYXRl OiBGcmksIDI3IE5vdiAyMDIwIDA3OjQ3OjIyICswMDAwDQo+ICAgIEZyb206ICJQYXNjYWwgVGh1 YmVydCAocHRodWJlcnQpIiA8cHRodWJlcnRAY2lzY28uY29tPG1haWx0bzpwdGh1YmVydEBjaXNj by5jb20+Pg0KPiAgICBUbzogUm91dGluZyBPdmVyIExvdyBwb3dlciBhbmQgTG9zc3kgbmV0d29y a3MgPHJvbGxAaWV0Zi5vcmc8bWFpbHRvOnJvbGxAaWV0Zi5vcmc+Pg0KPiAgICBTdWJqZWN0OiBb Um9sbF0gRXJyb3IgZmxvd3MsIHdoaWNoIElDTVAgZXJyb3JzIGFuZCB0byB3aGljaCByb290PzoN Cj4gICAgICAgIFtleHRlbmRzXSBJRVRGIDEwOSBvcGVuIFF1ZXN0aW9ucyBvbiBQLURBTw0KPiAg ICBNZXNzYWdlLUlEOg0KPiAgICAgICAgPENPMVBSMTFNQjQ4ODFBNzI0QjA0RUEyOUQzMkRDOUM4 MUQ4RjgwQENPMVBSMTFNQjQ4ODEubmFtcHJkMTEucHJvZC5vdXRsb29rLmNvbTxtYWlsdG86Q08x UFIxMU1CNDg4MUE3MjRCMDRFQTI5RDMyREM5QzgxRDhGODBAQ08xUFIxMU1CNDg4MS5uYW1wcmQx MS5wcm9kLm91dGxvb2suY29tPj4NCj4NCj4gICAgQ29udGVudC1UeXBlOiB0ZXh0L3BsYWluOyBj aGFyc2V0PSJ1cy1hc2NpaSINCj4NCj4gICAgSGVsbG8gTGkNCj4NCj4gICAgVGhpcyBpcyB0aGUg d3JvbmcgdGhyZWFkLiBJIGNyZWF0ZWQgYSBuZXcgb25lLg0KPg0KPj4gU2VjdGlvbiA3Ljkgb2Yg cGRhby1kcmFmdCBkZWZpbmVzIGEgbmV3IGNvZGUgZm9yICBJQ01QdjYgZXJyb3IgbWVzc2FnZSAi RXJyb3IgaW4gUHJvamVjdGVkIFJvdXRlIi4gRG9lcyBpdCBvbmx5IHdvcmsgZm9yIElDTVAgZXJy b3JzIHNlbnQgdG8gdGhlIG1haW4gUm9vdD8NCj4NCj4gICAgU2VjdGlvbiA1IHNheXMgIg0KPg0K Pg0KPiAgICAgICBJbiBjYXNlIG9mIGEgZm9yd2FyZGluZyBlcnJvciBhbG9uZyBhIFByb2plY3Rl ZCBSb3V0ZSwgYW4gSUNNUCBlcnJvcg0KPg0KPiAgICAgICBpcyBzZW50IHRvIHRoZSBSb290IHdp dGggYSBuZXcgQ29kZSAiRXJyb3IgaW4gUHJvamVjdGVkIFJvdXRlIiAoU2VlDQo+DQo+ICAgICAg IFNlY3Rpb24gNy45PGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXJvbGwt ZGFvLXByb2plY3Rpb24tMTQjc2VjdGlvbi03Ljk+KS4gIFRoZSBSb290IGNhbiB0aGVuIG1vZGlm eSBvciByZW1vdmUgdGhlIFByb2plY3RlZA0KPg0KPiAgICAgICBSb3V0ZS4gIFRoZSAiRXJyb3Ig aW4gUHJvamVjdGVkIFJvdXRlIiBtZXNzYWdlIGhhcyB0aGUgc2FtZSBmb3JtYXQgYXMNCj4NCj4g ICAgICAgdGhlICJEZXN0aW5hdGlvbiBVbnJlYWNoYWJsZSBNZXNzYWdlIiwgYXMgc3BlY2lmaWVk IGluIFJGQyA0NDQzPGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0NDQzPg0KPg0KPiAg ICAgICBbUkZDNDQ0MzxodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZjNDQ0Mz5dLg0KPg0K PiAgICAiDQo+DQo+ICAgIFNvIHllcyB0aGUgaW50ZW50aW9uIHdhcyB0byBzZW5kIHRoZSBJQ01Q IHRvIHRoZSBtYWluIFJvb3QuIEJ1dCBhcyB5b3UgcG9pbnQgb3V0IHRoZSBwYWNrZXQgZG9lcyBu b3QgaW5kaWNhdGUgaXQgaXMgZm9sbG93aW5nIGEgUC1yb3V0ZS4gVGhpcyB3YXMgcmVsYXRlZCB0 byBzdG9yaW5nIG1vZGUgUCBEQU8uIEluIG5vbi1zdG9yaW5nIHRoZSBub2RlIGRvZXMgbm90IGtu b3cgaXQncyBhIFAtcm91dGUuDQo+DQo+DQo+PiBJbiBub24tc3RvcmluZyBQREFPLCBmb3J3YXJk ZXIgY2FuJ3QgcmVjb2duaXplIHdoZXRoZXIgZGF0YSBwYWNrZXQgaXMgaW4gUERBTyBpbnN0YW5j ZS4gRm9yd2FyZGVyIHNob3VsZCBzZW5kIElDTVAgRGVzdGluYXRpb24gVW5yZWFjaGFibGUgZXJy b3IgdG8gcm9vdCAodGhlIHNvdXJjZSBvZiB0aGUgcGFja2V0KSwgdGhlbiByb290IGdlbmVyYXRl cyBJQ01QdjYgZXJyb3IgbWVzc2FnZSB3aXRoICJFcnJvciBpbiBQcm9qZWN0ZWQgUm91dGUiIHRv IG1haW4gUm9vdC4gIElzIGl0IGNvcnJlY3Q/DQo+DQo+ICAgIFRoYXQgd291bGQgd29yay4gU2Vl bXMgbmVhdC4gVGhlIGFsdGVybmF0ZSB3b3VsZCBiZSB0byBzaWduYWwgaXQgaXMgYSBQIHJvdXRl IGluIHRoZSBSUEkuIFRoYXQncyBpdGVtIDIpIGluIHRoZSBsaXN0IGluIHRoaXMgdGhyZWFkLiBJ ZiB3ZSBkbyB0aGF0IHRoZSBjdXJyZW50IHRleHQgd29ya3MuIFdoYXQgbWFrZXMgbW9yZSBzZW5z ZSB0byB5b3U/DQo+DQo+PiBJbiBzdG9yaW5nIFBEQU8sIGZvcndhcmRlciBjYW4gcmVjb2duaXpl IHRoZSBQREFPIGluc3RhbmNlIGZyb20gdGhlIFJQSS4gSXQgY2FuIHNlbmQgIkVycm9yIGluIFBy b2plY3RlZCBSb3V0ZSIgb3IgICJEZXN0aW5hdGlvbiBVbnJlYWNoYWJsZSBlcnJvciIgdG8gcm9v dC4gTWF5YmUgd2UgbmVlZCBtb3JlIGNsYWltcyBmb3Igd2hpY2ggY29kZSBmb3J3YXJkZXIgc2hv dWxkIHVzZS4NCj4NCj4gICAgV2UgaGF2ZSB0byBkZWNpZGUgaWYgd2Ugc2VuZCBpdCB0byB0aGUg bWFpbiByb290IGFzIHdyaXR0ZW4gaW4gdGhlIGN1cnJlbnQgZHJhZnQgb3IgdG8gdGhlIFRyYWNr IFJvb3QuIElmIHRoZSBQIHJvdXRlIGlzIHJldmVyc2libGUgY291bGQgYmUgZG9uZSB0aGF0IHdh eS4gQnV0IHRoYXQncyBhZGRlZCBjb21wbGV4aXR5LiBJJ20gbm90IHZlcnkgY29udmluY2VkIGVp dGhlciB3YXkuIFRoZSBPa2hhbSByYXpvciBjb3VsZCBiZSB0byBkbyB0aGUgc2ltcGxlc3QuDQo+ DQo+ICAgIEtlZXAgc2FmZSENCj4NCj4gICAgUGFzY2FsDQo+DQo+DQo+DQo+DQo+DQo+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IFJvbGwgbWFpbGlu ZyBsaXN0DQo+IFJvbGxAaWV0Zi5vcmc8bWFpbHRvOlJvbGxAaWV0Zi5vcmc+DQo+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcm9sbA0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NClJvbGwgbWFpbGluZyBsaXN0DQpSb2xsQGlldGYu b3JnPG1haWx0bzpSb2xsQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9yb2xsDQo= --_000_MWHPR11MB17422A28AE90AC86F8CEBEEF8CF40MWHPR11MB1742namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseTpTaW1TdW47DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9 DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlhIE1hdGgiOw0KCXBhbm9zZS0xOjIg NCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpEZW5nWGlhbjsN CglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEgMSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNl DQoJe2ZvbnQtZmFtaWx5OiJcQERlbmdYaWFuIjsNCglwYW5vc2UtMToyIDEgNiAwIDMgMSAxIDEg MSAxO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxAU2ltU3VuIjsNCglwYW5vc2UtMToy IDEgNiAwIDMgMSAxIDEgMSAxO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1h bCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjowY207DQoJZm9udC1zaXpl OjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0K CXtzaXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIu MHB0O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9ImVuLUNOIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl IiBzdHlsZT0id29yZC13cmFwOmJyZWFrLXdvcmQiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5IZWxsbyBQYXNjYWws PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0i RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIGxhbmc9IkVOLVVTIj5BZ3JlZSB3aXRoIHlvdS4gQXMgdGhlcmUgaXMgbm8gcm9vbSBs ZWZ0IGluDQo8L3NwYW4+UC1SUEktNkxvUkg8c3BhbiBsYW5nPSJFTi1VUyI+LCBsZXTigJlzIDwv c3Bhbj5pZ25vcmUgYWxsIHRoZSBiaXRzIGFuZCBrZWVwIHRoaW5ncyBzaW1wbGUuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5CZXN0IHJlZ2FyZHMsPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPkxp PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0 REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOg0KPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtjb2xvcjpibGFjayI+Um9sbCAmbHQ7cm9sbC1ib3VuY2VzQGlldGYub3JnJmd0 Ozxicj4NCjxiPkRhdGU6IDwvYj5UdWVzZGF5LCBEZWNlbWJlciAxLCAyMDIwIGF0IDE0OjM2PGJy Pg0KPGI+VG86IDwvYj5Sb3V0aW5nIE92ZXIgTG93IHBvd2VyIGFuZCBMb3NzeSBuZXR3b3JrcyAm bHQ7cm9sbEBpZXRmLm9yZyZndDs8YnI+DQo8Yj5TdWJqZWN0OiA8L2I+UmU6IFtSb2xsXSBFcnJv ciBmbG93cywgd2hpY2ggSUNNUCBlcnJvcnMgYW5kIHRvIHdoaWNoIHJvb3Q8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhlbGxvIExpPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkJ1dCBQLURBTyBkb2VzIG5vdCBkaXN0cmlidXRlIGEgUmFuay4gVGhl IG5ldyBQLVNSSC02TG9SSCBlbGlkZXMgaXQuIFNvIHRoZSDigJhS4oCZIGZsYWcgZG9lcyBub3Qg bWFrZSBzZW5zZSBlaXRoZXIuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5G b3Igbm93IHRoZSBUcmFjayBpcyBub3QgcmV2ZXJzaWJsZSwgc28gdGhlIOKAmE/igJkgZmxhZyBp cyB1c2VsZXNzIGFzIHdlbGwuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgd2FzIHdvbmRlcmlu ZyBmb3IgdGhlIOKAmEbigJkgZmxhZy4gV2UgY291bGQgc3RpbGwgdXNlIGl0IGluIGJvdGggbW9k ZXMuIEJ1dCB0aGF0IGlzIGV4dHJhIGNvZGUsIGxpdHRsZSB2YWx1ZSBzaW5jZSB0aGUgSUNNUCB0 byB0aGUgcm9vdCBpcyBhbHJlYWR5IHRoZXJlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5GaW5h bGx5LCB5b3XigJlsbCBmaW5kIHRoYXQgdGhlcmUgaXMgbm8gcm9vbSBsZWZ0IGluIDxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOzwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgMCZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAxJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IDI8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVy IE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDAgMSAyIDMgNCA1 IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyB8MXwwfEV8IExlbmd0aCZuYnNwOyB8IDZMb1JIIFR5cGUg NyZuYnNwOyB8IFJQTEluc3RhbmNlSUQgfDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+VGhhdCBpcyBiZWNhdXNlIEkgd2FudCB0aGUgUC1SUEktNkxvUkgg dG8gYmUgZWl0aGVyIGVsZWN0aXZlIG9yIGNyaXRpY2FsLCB3aGljaCBpbXBsaWVzIHRoYXQgYnV0 cyAzLi43IGFyZSBhIGxlbmd0aCwgbm8gcm9vbSBmb3IgdGhlIOKAmEbigJkgYml0LjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9yIG1lbW9yeSwgdGhlIFJQSS02TG9SSCBp cyBjcml0aWNhbCwgeW91IEhBVkUgdG8gc3VwcG9ydCBpdCBpZiBpdCBpcyBpbiB0aGUgcGFja2V0 LCBlbHNlIHlvdSBkcm9wLiBJbiB0aGUgYWJvdmUgZm9ybWF0LCBpZiB0aGUg4oCYReKAmSBiaXQg aXMgc2V0LCB0aGUgaW1wbGVtZW50YXRpb24gY2FuIGZ1bGx5IGlnbm9yZSB0aGUgUlBJICh0aGF0 4oCZcyBvbmUgb2YgdGhlIG5pY2UgdGhpbmdzIGFib3V0IFJGQyA4MTM4KSwNCiB3aGljaCBjYW4g YmUgT0sgaW4gc29tZSBzdHJpY3Qgc291cmNlIHJvdXRpbmcgc2l0dWF0aW9ucy4gPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlNvIEkgdGhvdWdodCwgbGV0IHVzIGlnbm9yZSBhbGwgdGhlIGJpdHMg YW5kIGtlZXAgdGhpbmdzIHNpbXBsZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V29ya3M/PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPlBhc2NhbDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkIGJsdWUgMS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IFJv bGwgJmx0O3JvbGwtYm91bmNlc0BpZXRmLm9yZyZndDsgPGI+T24gQmVoYWxmIE9mIDwvYj4NCkxp IFpoYW8gKGxpejMpPGJyPg0KPGI+U2VudDo8L2I+IG1hcmRpIDEgZMOpY2VtYnJlIDIwMjAgMDY6 MzU8YnI+DQo8Yj5Ubzo8L2I+IFJvdXRpbmcgT3ZlciBMb3cgcG93ZXIgYW5kIExvc3N5IG5ldHdv cmtzICZsdDtyb2xsQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW1JvbGxd IEVycm9yIGZsb3dzLCB3aGljaCBJQ01QIGVycm9ycyBhbmQgdG8gd2hpY2ggcm9vdDxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGVsbG88c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjBwdCI+IFBhc2NhbCw8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uZSBj b25jZXJuIGZvciBzZWN0aW9uIDQg4oCcRXh0ZW5kaW5nIFJGQyA2NTUz4oCdLiA8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFyZSBvdGhlciBmaWVsZHMg4oCcJ08nLCAnUics ICdGJyBmbGFncywgU2VuZGVyUmFuayDigJ0gbmVjZXNzYXJ5IHRvIGJlIHplcm8gaWYg4oCYUOKA mSBmbGFnIGlzIHNldD8NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rm9y IHN0b3JpbmctUERBTywgbWF5YmUgd2UgY2FuIGxldmVyYWdlIHRoZXNlIGZpZWxkcyBmb3IgZXJy b3ItZGV0ZWN0aW9uIGlmIG5lZWQuIFNvIGRvIHdlIG5lZWQgcmVwbGFjZSDigJxNVVNU4oCdIHRv IOKAnFNIT1VMROKAnSBvciDigJxNQVnigJ0gdG8ga2VlcCB0aGUgZmxleGliaWxpdHk/PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+QmVzdCByZWdhcmRzLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ TGk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEu MHB0O3BhZGRpbmc6My4wcHQgMGNtIDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox Mi4wcHQ7Y29sb3I6YmxhY2siPlJvbGwgJmx0Ozwvc3Bhbj48YSBocmVmPSJtYWlsdG86cm9sbC1i b3VuY2VzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+cm9sbC1ib3Vu Y2VzQGlldGYub3JnPC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtjb2xv cjpibGFjayI+Jmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5Nb25kYXksIE5vdmVtYmVyIDMwLCAyMDIw IGF0IDE3OjI4PGJyPg0KPGI+VG86IDwvYj5Sb3V0aW5nIE92ZXIgTG93IHBvd2VyIGFuZCBMb3Nz eSBuZXR3b3JrcyAmbHQ7PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpyb2xsQGlldGYub3JnIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdCI+cm9sbEBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPiZndDs8YnI+DQo8Yj5TdWJqZWN0 OiA8L2I+UmU6IFtSb2xsXSBFcnJvciBmbG93cywgd2hpY2ggSUNNUCBlcnJvcnMgYW5kIHRvIHdo aWNoIHJvb3Q8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5ZZXMgSHVpbWluPGJyPg0KPGJyPg0KQW5kIHRoaXMgaXMgdGhlIG5vcm1hbCBi ZWhhdmlvci48YnI+DQo8YnI+DQpXaXRoIFBEQU8gd2UgY3JlYXRlZCB0aGUgdW51c3VhbCBiZWhh dmlvciB0byBzZW5kIHRoZSBlcnJvciBpbiBwLXJvdXRlIHRvIHRoZSByb290LiBUaGlzIHdhcyB0 byBtYWtlIHRoaW5ncyBmYXN0ZXIgc2luY2UgdGhlIGNvbW11bmljYXRpb24gdGhyb3VnaCB0aGUg VHJhY2sgaXMgZGlyZWN0aW9uYWwgc28geW91IGNhbm5vdCB0YWxrIGJhY2suIEFsc28gaW4gbm9u IHN0b3JpbmcgdGFsa2luZyB0byB0aGUgc291cmNlIGlzIHZpYSB0aGUgUm9vdCBhbmQNCiB1bHRp bWF0ZWx5IHRoZSBSb290IG5lZWRzIHRvIHVwZGF0ZSB0aGUgUCBEQU8uPGJyPg0KPGJyPg0KV2l0 aCBSQVcgd2UgbWF5IHdhbnQgdG8gdG8gc29tZXRoaW5nIGZhc3RlciBidXQgdW5jbGVhciBmb3Ig bm93Ljxicj4NCjxicj4NClBsZWFzZSBub3RlIHRoYXQgYWZ0ZXIgdGhlIGRpc2N1c3Npb24gd2l0 aCB5b3UgYW5kIExpIEkgcHVibGlzaGVkIGEgcmV2aXNpb24gdGhhdCBoYXMgdGhlIGZsYWcgaW4g dGhlIFJQSSB0aGF0IGluZGljYXRlcyB0aGF0IHRoZSBwYWNrZXQgaXMgZm9yd2FyZGVkIG9uIGEg UC1yb3V0ZS48YnI+DQo8YnI+DQpEbyB5b3Ugd2FudCB0byBjaGFuZ2UgdGhlIGVycm9yIGZsb3c/ PGJyPg0KPGJyPg0KUGFzY2FsPGJyPg0KPGJyPg0KJmd0OyBMZSAzMCBub3YuIDIwMjAgw6AgMDk6 MTUsIEh1aW1pbiBTaGUgKGh1c2hlKSAmbHQ7PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQi PjxhIGhyZWY9Im1haWx0bzpodXNoZT00MGNpc2NvLmNvbUBkbWFyYy5pZXRmLm9yZyI+aHVzaGU9 NDBjaXNjby5jb21AZG1hcmMuaWV0Zi5vcmc8L2E+PC9zcGFuPiZndDsgYSDDqWNyaXQgOjxicj4N CiZndDsgPGJyPg0KJmd0OyDvu79IaSBQYXNjYWwsPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFJGQyA2 NTUwIHNlY3Rpb24gMTEuMSBzYXlzIHRoZSBJQ01QdjYgZXJyb3IgaW4gU1JIIHNob3VsZCBiZSBz ZW50IHRvIHRoZSBzb3VyY2Ugb2YgdGhlIHBhY2tldC48YnI+DQomZ3Q7IDxicj4NCiZndDsgQmVz dCByZWdhcmRzLDxicj4NCiZndDsgSHVpbWluPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7IE1lc3NhZ2U6IDI8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IERhdGU6IEZy aSwgMjcgTm92IDIwMjAgMDc6NDc6MjIgKzAwMDA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7 IEZyb206ICZxdW90O1Bhc2NhbCBUaHViZXJ0IChwdGh1YmVydCkmcXVvdDsgJmx0OzxhIGhyZWY9 Im1haWx0bzpwdGh1YmVydEBjaXNjby5jb20iPnB0aHViZXJ0QGNpc2NvLmNvbTwvYT4mZ3Q7PGJy Pg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBUbzogUm91dGluZyBPdmVyIExvdyBwb3dlciBhbmQg TG9zc3kgbmV0d29ya3MgJmx0OzxhIGhyZWY9Im1haWx0bzpyb2xsQGlldGYub3JnIj5yb2xsQGll dGYub3JnPC9hPiZndDs8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFN1YmplY3Q6IFtSb2xs XSBFcnJvciBmbG93cywgd2hpY2ggSUNNUCBlcnJvcnMgYW5kIHRvIHdoaWNoIHJvb3Q/Ojxicj4N CiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgW2V4dGVuZHNd IElFVEYgMTA5IG9wZW4gUXVlc3Rpb25zIG9uIFAtREFPPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyBNZXNzYWdlLUlEOjxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsgJmx0OzxhIGhyZWY9Im1haWx0bzpDTzFQUjExTUI0ODgxQTcyNEIwNEVBMjlE MzJEQzlDODFEOEY4MEBDTzFQUjExTUI0ODgxLm5hbXByZDExLnByb2Qub3V0bG9vay5jb20iPkNP MVBSMTFNQjQ4ODFBNzI0QjA0RUEyOUQzMkRDOUM4MUQ4RjgwQENPMVBSMTFNQjQ4ODEubmFtcHJk MTEucHJvZC5vdXRsb29rLmNvbTwvYT4mZ3Q7PGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5i c3A7Jm5ic3A7IENvbnRlbnQtVHlwZTogdGV4dC9wbGFpbjsgY2hhcnNldD0mcXVvdDt1cy1hc2Np aSZxdW90Ozxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBIZWxsbyBMaTxi cj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBUaGlzIGlzIHRoZSB3cm9uZyB0 aHJlYWQuIEkgY3JlYXRlZCBhIG5ldyBvbmUuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jmd0OyBTZWN0 aW9uIDcuOSBvZiBwZGFvLWRyYWZ0IGRlZmluZXMgYSBuZXcgY29kZSBmb3ImbmJzcDsgSUNNUHY2 IGVycm9yIG1lc3NhZ2UgJnF1b3Q7RXJyb3IgaW4gUHJvamVjdGVkIFJvdXRlJnF1b3Q7LiBEb2Vz IGl0IG9ubHkgd29yayBmb3IgSUNNUCBlcnJvcnMgc2VudCB0byB0aGUgbWFpbiBSb290Pzxicj4N CiZndDsgPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyBTZWN0aW9uIDUgc2F5cyAmcXVvdDs8 YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyBJbiBjYXNlIG9mIGEgZm9yd2FyZGluZyBlcnJvciBhbG9uZyBhIFByb2plY3Rl ZCBSb3V0ZSwgYW4gSUNNUCBlcnJvcjxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpcyBzZW50IHRvIHRoZSBSb290IHdpdGggYSBuZXcgQ29k ZSAmcXVvdDtFcnJvciBpbiBQcm9qZWN0ZWQgUm91dGUmcXVvdDsgKFNlZTxicj4NCiZndDsgPGJy Pg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTZWN0aW9uIDcuOSZs dDs8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1yb2xsLWRh by1wcm9qZWN0aW9uLTE0I3NlY3Rpb24tNy45Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwv ZHJhZnQtaWV0Zi1yb2xsLWRhby1wcm9qZWN0aW9uLTE0I3NlY3Rpb24tNy45PC9hPiZndDspLiZu YnNwOyBUaGUgUm9vdCBjYW4gdGhlbiBtb2RpZnkgb3IgcmVtb3ZlIHRoZSBQcm9qZWN0ZWQ8YnI+ DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgUm91 dGUuJm5ic3A7IFRoZSAmcXVvdDtFcnJvciBpbiBQcm9qZWN0ZWQgUm91dGUmcXVvdDsgbWVzc2Fn ZSBoYXMgdGhlIHNhbWUgZm9ybWF0IGFzPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHRoZSAmcXVvdDtEZXN0aW5hdGlvbiBVbnJlYWNoYWJs ZSBNZXNzYWdlJnF1b3Q7LCBhcyBzcGVjaWZpZWQgaW4gUkZDIDQ0NDMmbHQ7PGEgaHJlZj0iaHR0 cHM6Ly90b29scy5pZXRmLm9yZy9odG1sL3JmYzQ0NDMiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9yZmM0NDQzPC9hPiZndDs8YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgW1JGQzQ0NDMmbHQ7PGEgaHJlZj0iaHR0cHM6Ly90b29scy5p ZXRmLm9yZy9odG1sL3JmYzQ0NDMiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9yZmM0NDQz PC9hPiZndDtdLjxicj4NCiZndDsgPGJyPg0KJmd0OyZuYnNwOyZuYnNwOyZuYnNwOyAmcXVvdDs8 YnI+DQomZ3Q7IDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgU28geWVzIHRoZSBpbnRlbnRp b24gd2FzIHRvIHNlbmQgdGhlIElDTVAgdG8gdGhlIG1haW4gUm9vdC4gQnV0IGFzIHlvdSBwb2lu dCBvdXQgdGhlIHBhY2tldCBkb2VzIG5vdCBpbmRpY2F0ZSBpdCBpcyBmb2xsb3dpbmcgYSBQLXJv dXRlLiBUaGlzIHdhcyByZWxhdGVkIHRvIHN0b3JpbmcgbW9kZSBQIERBTy4gSW4gbm9uLXN0b3Jp bmcgdGhlIG5vZGUgZG9lcyBub3Qga25vdyBpdCdzIGEgUC1yb3V0ZS48YnI+DQomZ3Q7IDxicj4N CiZndDsgPGJyPg0KJmd0OyZndDsgSW4gbm9uLXN0b3JpbmcgUERBTywgZm9yd2FyZGVyIGNhbid0 IHJlY29nbml6ZSB3aGV0aGVyIGRhdGEgcGFja2V0IGlzIGluIFBEQU8gaW5zdGFuY2UuIEZvcndh cmRlciBzaG91bGQgc2VuZCBJQ01QIERlc3RpbmF0aW9uIFVucmVhY2hhYmxlIGVycm9yIHRvIHJv b3QgKHRoZSBzb3VyY2Ugb2YgdGhlIHBhY2tldCksIHRoZW4gcm9vdCBnZW5lcmF0ZXMgSUNNUHY2 IGVycm9yIG1lc3NhZ2Ugd2l0aCAmcXVvdDtFcnJvciBpbiBQcm9qZWN0ZWQgUm91dGUmcXVvdDsN CiB0byBtYWluIFJvb3QuJm5ic3A7IElzIGl0IGNvcnJlY3Q/PGJyPg0KJmd0OyA8YnI+DQomZ3Q7 Jm5ic3A7Jm5ic3A7Jm5ic3A7IFRoYXQgd291bGQgd29yay4gU2VlbXMgbmVhdC4gVGhlIGFsdGVy bmF0ZSB3b3VsZCBiZSB0byBzaWduYWwgaXQgaXMgYSBQIHJvdXRlIGluIHRoZSBSUEkuIFRoYXQn cyBpdGVtIDIpIGluIHRoZSBsaXN0IGluIHRoaXMgdGhyZWFkLiBJZiB3ZSBkbyB0aGF0IHRoZSBj dXJyZW50IHRleHQgd29ya3MuIFdoYXQgbWFrZXMgbW9yZSBzZW5zZSB0byB5b3U/PGJyPg0KJmd0 OyA8YnI+DQomZ3Q7Jmd0OyBJbiBzdG9yaW5nIFBEQU8sIGZvcndhcmRlciBjYW4gcmVjb2duaXpl IHRoZSBQREFPIGluc3RhbmNlIGZyb20gdGhlIFJQSS4gSXQgY2FuIHNlbmQgJnF1b3Q7RXJyb3Ig aW4gUHJvamVjdGVkIFJvdXRlJnF1b3Q7IG9yJm5ic3A7ICZxdW90O0Rlc3RpbmF0aW9uIFVucmVh Y2hhYmxlIGVycm9yJnF1b3Q7IHRvIHJvb3QuIE1heWJlIHdlIG5lZWQgbW9yZSBjbGFpbXMgZm9y IHdoaWNoIGNvZGUgZm9yd2FyZGVyIHNob3VsZCB1c2UuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7Jm5i c3A7Jm5ic3A7Jm5ic3A7IFdlIGhhdmUgdG8gZGVjaWRlIGlmIHdlIHNlbmQgaXQgdG8gdGhlIG1h aW4gcm9vdCBhcyB3cml0dGVuIGluIHRoZSBjdXJyZW50IGRyYWZ0IG9yIHRvIHRoZSBUcmFjayBS b290LiBJZiB0aGUgUCByb3V0ZSBpcyByZXZlcnNpYmxlIGNvdWxkIGJlIGRvbmUgdGhhdCB3YXku IEJ1dCB0aGF0J3MgYWRkZWQgY29tcGxleGl0eS4gSSdtIG5vdCB2ZXJ5IGNvbnZpbmNlZCBlaXRo ZXIgd2F5LiBUaGUgT2toYW0gcmF6b3IgY291bGQgYmUgdG8gZG8gdGhlDQogc2ltcGxlc3QuPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7Jm5ic3A7Jm5ic3A7Jm5ic3A7IEtlZXAgc2FmZSE8YnI+DQomZ3Q7 IDxicj4NCiZndDsmbmJzcDsmbmJzcDsmbmJzcDsgUGFzY2FsPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IFJvbGwgbWFpbGlu ZyBsaXN0PGJyPg0KJmd0OyA8YSBocmVmPSJtYWlsdG86Um9sbEBpZXRmLm9yZyI+Um9sbEBpZXRm Lm9yZzwvYT48YnI+DQomZ3Q7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vcm9sbCI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9yb2xs PC9hPjxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KUm9sbCBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86Um9sbEBpZXRmLm9y ZyI+Um9sbEBpZXRmLm9yZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3JvbGwiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vcm9sbDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_MWHPR11MB17422A28AE90AC86F8CEBEEF8CF40MWHPR11MB1742namp_--