From nobody Fri Mar 1 05:15:52 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5607D130E7C for ; Fri, 1 Mar 2019 05:15:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 shCybt8_DSyc for ; Fri, 1 Mar 2019 05:15:47 -0800 (PST) Received: from mail-lj1-x22b.google.com (mail-lj1-x22b.google.com [IPv6:2a00:1450:4864:20::22b]) (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 7B96E130E73 for ; Fri, 1 Mar 2019 05:15:47 -0800 (PST) Received: by mail-lj1-x22b.google.com with SMTP id d14so20328097ljl.9 for ; Fri, 01 Mar 2019 05:15:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=vs4XkFBWlMFSe/ni3a3WfnaevWKxo3iS/hFoIFVR3mc=; b=gZFTBYfTvCmS+y2AjlWlZsSFi+/LfskSSWH+43+NrmQXwiSmJbCGlPCxnnYK9pMsqJ 2eSNODKaaK2yKIweGGvjhk1mU6ig/d6QNVLUFnT+H2jdI9YRSU1O5Amws7P+sr5yqjZO ddMOnzJqJuaSUvMtqqej5Ak40x5Z5gzZ4gNEGZ2MIPeDebwnnZc+i2S+Oas60/K0F4fV n1joVEjYaQkykKFBaWi1LIbHX5TU9EFpW7kCMLACj9smiOE9JmoQJI3ZTyuasRPrt7JT /uHcfWtcVE3yqQ08HYxqoxjOBhoXkOH2GhhbO2C0se4WfXZJHsSzzrpjcgV7nUqG0tDG 9bvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=vs4XkFBWlMFSe/ni3a3WfnaevWKxo3iS/hFoIFVR3mc=; b=OYJ1rB7gD9hFxphwQwEi+cU5aFJ37qEvkAaAAsaRaswY9ecn7PM1ygjce/4iqm13Jq iQ096q5MMy4axPhQEJ6ZQOFycqw7BZmKA/FuJs6c/4N60hiCkEXkebA8QzE/3TDQu+Qa Ou2nFdNlSLeF5XJVgu0OUuXBz4wnDyegOFYbIAskZQsz1YQbSd+zyXCw9wgRNOzS03B0 6fVzZaaeDkt8CmoXVeIN1En9+IqBknJO1wMMiHOzSbnh6ghAzi9KHFcok6V9A63z7+I/ l5mGGBaPuM8E8VSgdTHwnhtpmZnTEDpX/MLOmy0QDwy3iV9ia7uRmP/eAcTwveTjpxeo qL8w== X-Gm-Message-State: APjAAAXqJxUlT9Ah0CiETNnLUlMztm3/88tVqFIA1/R0KBD61BuSgTB5 sAit0eGqn4AJvpg7jZ+L6aC9opj2 X-Google-Smtp-Source: APXvYqxpeOqA6I+MQsnBrs8Uk/SvzFuUK2cCsldipogO0jpmy1Y5lpIVxcwr/HOqBPZ0RXJCs6RZPw== X-Received: by 2002:a2e:8092:: with SMTP id i18mr2723078ljg.91.1551446144945; Fri, 01 Mar 2019 05:15:44 -0800 (PST) Received: from secretmaker-188.ip.peterstar.net (secretmaker-188.ip.PeterStar.net. [217.195.72.188]) by smtp.gmail.com with ESMTPSA id v65sm4639654lje.77.2019.03.01.05.15.44 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Mar 2019 05:15:44 -0800 (PST) From: Alexander Okonnikov Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) Message-Id: <8CAFA47F-8188-4045-9CB8-CD1CFEC4DF1B@gmail.com> Date: Fri, 1 Mar 2019 16:15:43 +0300 To: lsr@ietf.org X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: [Lsr] Calculating OSPF external routes for non-zero FA X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 13:15:51 -0000 Hi WG, I don't know whether the problem below is known already, but I have not = found neither update nor corresponding errata for RFC 2328. RFC 2328, = section 16.4 says: "(3) ... Look up the routing table entries (potentially one per = attached area) for the AS boundary router (ASBR) that originated the = LSA. If no entries exist for router ASBR (i.e., ASBR is unreachable), do = nothing with this LSA and consider the next in the list. Else, this LSA describes an AS external path to destination N. Examine = the forwarding address specified in the AS-external-LSA. This indicates = the IP address to which packets for the destination should be forwarded. = ..." and "... If the forwarding address is non-zero, look up the forwarding = address in the routing table.[24] The matching routing table entry must = specify an intra-area or inter-area path; if no such path exists, do = nothing with the LSA and consider the next in the list. ..." In case when AS-external LSA has non-zero FA, why do we need to look up = the routing table entries for ASBR, that originated the LSA? It is = possible that FA is available via other ASBR(s). This is valid case when = there are more than one ASBRs, and all may originate AS-external LSA = with the same FA and metric for some external destination, but only one = (with highest RID) will originate such LSA (RFC 2328, section 12.4.4.1). = Another case with Type-7 to Type-5 translation doing by ABRs in = Candidate mode (RFC 3101). Per my understanding a calculating router should initially analyse FA = value and only then check availability of ASBR or FA, depending on = whether FA is zero or not. Am I missing something? Thanks.= From nobody Fri Mar 1 05:41:22 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84D53130E79 for ; Fri, 1 Mar 2019 05:41:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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=QIM63GSM; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Ki/PM7VE 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 8uChfr6UprgP for ; Fri, 1 Mar 2019 05:41:18 -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 44B56130E73 for ; Fri, 1 Mar 2019 05:41:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3112; q=dns/txt; s=iport; t=1551447678; x=1552657278; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=2jhHuTet2N7c7x2KgOefKxGwIPgTosEJ9ynMTiE8Xqs=; b=QIM63GSMeZYlyBSewK9X2oT82PJt6QJAbmJ8LOVrLV00EWVEsAd6hA6N 8w/0kgbW6kDmnaULfdaMD6Qw5eRytkPXcuaX6hGjxY9I5CJNpKb9HSSTD 1Y6DY5n5Nsvxq/HEIZ0PDPQ6DSyWaztc0epEscdgVQeMVqffCBa76pcwl Q=; IronPort-PHdr: =?us-ascii?q?9a23=3Ad/WSzh+XQZL8Uv9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+/YR7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfJq3UeaNpJXh?= =?us-ascii?q?4Bh98RmlkpC8OIIUb6N/XtKSc9GZcKWQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ANAADgNXlc/4UNJK1lGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBUQYBAQELAYExUANodAQLJwqDfoNHA4RQiwVKizuOcoEkA1QLAQE?= =?us-ascii?q?YCwmEQAIXhAkiNAkNAQMBAQMBAwJtHAyFSwIEAQEhEQwBASwMDwIBCBoCJgI?= =?us-ascii?q?CAh8GCxUQAgQBEoMiAYFdAxUBAgygLQKKFHGBL4J4AQEFgkWCQw0LggsDBYE?= =?us-ascii?q?Li0AXgX+BEScfgh4ugldHAQGEazGCJoxClwczCQKPMIM9GYF0kS2KYIEShXa?= =?us-ascii?q?LFwIEAgQFAg0BAQWBRziBVnAVOyoBgkGCHAwXg0uFFIU/coEojXwBgR4BAQ?= X-IronPort-AV: E=Sophos;i="5.58,427,1544486400"; d="scan'208";a="241411975" Received: from alln-core-11.cisco.com ([173.36.13.133]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Mar 2019 13:41:17 +0000 Received: from XCH-RCD-006.cisco.com (xch-rcd-006.cisco.com [173.37.102.16]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id x21DfGSE027010 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 1 Mar 2019 13:41:16 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-006.cisco.com (173.37.102.16) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Fri, 1 Mar 2019 07:41:16 -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.1473.3; Fri, 1 Mar 2019 07:41:15 -0600 Received: from NAM01-BY2-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.1473.3 via Frontend Transport; Fri, 1 Mar 2019 07:41:15 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2jhHuTet2N7c7x2KgOefKxGwIPgTosEJ9ynMTiE8Xqs=; b=Ki/PM7VEDzZpON0rb2GpWWM1+NzjvmiRJLsKiQ1DHkbfnD9gOlmFLepWflrJaGJ9Gs1jjxoKENu5fJaWP7cR9kBB37IgVPYhw5YYX3GUHt1VMhoN8E3xDVKko3u6amOiEHbYbjtSe9IqCztAGfquNTaP+5mF8qMqRoHHWnAjAJE= Received: from BN8PR11MB3683.namprd11.prod.outlook.com (20.178.220.74) by BN8PR11MB3665.namprd11.prod.outlook.com (20.178.220.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1643.21; Fri, 1 Mar 2019 13:41:14 +0000 Received: from BN8PR11MB3683.namprd11.prod.outlook.com ([fe80::c62:f0b7:72a0:e853]) by BN8PR11MB3683.namprd11.prod.outlook.com ([fe80::c62:f0b7:72a0:e853%4]) with mapi id 15.20.1665.015; Fri, 1 Mar 2019 13:41:14 +0000 From: "Acee Lindem (acee)" To: Alexander Okonnikov , "lsr@ietf.org" Thread-Topic: [Lsr] Calculating OSPF external routes for non-zero FA Thread-Index: AQHU0DD9d7E/j3LNqEqsI0BolzCRxaX2dKuA Date: Fri, 1 Mar 2019 13:41:14 +0000 Message-ID: References: <8CAFA47F-8188-4045-9CB8-CD1CFEC4DF1B@gmail.com> In-Reply-To: <8CAFA47F-8188-4045-9CB8-CD1CFEC4DF1B@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=acee@cisco.com; x-originating-ip: [173.38.117.79] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 5f80047a-acb5-4674-8b97-08d69e4b92ce x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BN8PR11MB3665; x-ms-traffictypediagnostic: BN8PR11MB3665: x-ms-exchange-purlcount: 1 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtCTjhQUjExTUIzNjY1OzIzOk91MFZjMHFvbHFNaHh4MEhFREVmMDZ5bkts?= =?utf-8?B?b3FkazdTWnlHa2RaeXNiNklHN3h4U1VEMTJnRzhtNURmL0xvOXFaQzlJR0xa?= =?utf-8?B?b1p0emY1MVFCSGJnbXBwc0VjU3FXV3FoMXQxVU9ldklrUFk1RFd4ZTdMcXNO?= =?utf-8?B?Q2xsazdQT1hTOEtDUy9BRVpnSi8xc2hmRm1FaHV4am9TRitVZitHUHErR09Y?= =?utf-8?B?Vzg3aEIyamNKbjl4TWJidUJ6SEhVYnBwNlJySmMzaU9Ra2pLL1czN1dVd0l3?= =?utf-8?B?OU93WHZqU2oxVXZkMXhJWldxY1hLVUtZTnlKSTBsRG9RK0JtZHY3MG1vb0hK?= =?utf-8?B?ZTNSYXhrZG9temdaY0ZjV0FFbXVYUTNUUmc0TXpaajhqR2trTWJuM3c1ZHpD?= =?utf-8?B?R1QzWDBGcUppazBrSFhqZnhmUHVuTlVjdmpNQ0ZxUmltUHZwajZWeGJLU2hH?= =?utf-8?B?SEZRM05oaXMyaXd1UWNmblpiaE5qNHZlK0FJL0d3VEd3NmZJeEtMNU5neVZ3?= =?utf-8?B?V25HalhTSGVKeGloZnNjdUIwSldwYWlQbWVIUWxzZm5wbVNBYWlpc014eDBr?= =?utf-8?B?bXF5NVJmNm5Hc2NwS25lcjN4Vit3NXBMRE1lSi9MQUlwOE8weEQ5MTRMcXli?= =?utf-8?B?cFpHWngxYWRGT0dSK1JJYjJCRUlzbHdtM2tBOEZuT1Y4QjhxNnc0T2dEUUFR?= =?utf-8?B?SGs2aTE5M2tITFZ0RUk4Lzg3Q0xseXNqUG1CbitrVXdZZ1FvanAxNTNTdnpN?= =?utf-8?B?blU4MXA2NTBMM29YTS9JZTZrMDQzT3pyc1NOeGhhUzlvZDQxeG5NWGNpdVZx?= =?utf-8?B?ZmlWYVdSWWpFdkdSeFBKckRoYVU2QVRYQVhQZEl4ZW00OG1kbmhsQ2RZTkZS?= =?utf-8?B?TE1hbElnZFZTWmdxWWQ1QUF1dHBJQzJFdGgrUTBKWStMRFVDMFRWNVN5dTRk?= =?utf-8?B?ZTFMczEzdGdMVWxCTjUweGllVWt0QjA5Ny9RTUFFSW9Bd010QzNkdUxRMDZz?= =?utf-8?B?UlZQaFJzV1RxeE5hNWxmTi9UNFRueWRvaFAvY3BmZnZiNDIzZGx3bUNFZzR1?= =?utf-8?B?YzFiYVRSZ2pDWEdGT3BxeklodTNIaXlTbUszVldWVzc5aUoxUFY4b2U4UnN2?= =?utf-8?B?ZWdyN3dJTUVIcFlkOWtURDlMTG5Tbjg5eHYxRE5DZ3k0Um5NMnhhLzdQK3FS?= =?utf-8?B?a2h4Vnl3UWw0YnpiY3ZIN0VkVUZuTmp4VTNwUG10YkZzSEFPK3JFb3FiMFcy?= =?utf-8?B?QW5aaitlSEJibmpwd3pEbTRQUkNtOWRTZE5FWFJVbGhKNUxkU0VxY0NZNXls?= =?utf-8?B?dW9KN2k5bmxEMFBreHIwNG1xQVFuQ3liVkVtajZXckN5c1NJd1QyMmdYTGJi?= =?utf-8?B?aWdsTkhSaTZhT1RlYzhRa2p3VkRUVlZqNzhQRUQwWXVTaFJLTytDMnVRa1pO?= =?utf-8?B?VFc1cVVmc3RRVnQwR0FvSkEzN3MxOTBXcUxSdGRndWlTUHZHOVNBSkM3YVRH?= =?utf-8?B?cnRwWGJGdkloWm9GanFvcWt6c3FSd1BCcGRPUnRtUmRNUVJKSm02d2Z2TUI3?= =?utf-8?B?enRWSGgzNFYxblQxS015NS8rUXFVL2plM1poRktVekZPNnE0NEdXcTR2aFFP?= =?utf-8?B?cGtBUXQ0L3E0S0I3b1lScS9wYkV1T05kS2RlQUtDOUxGZDNrZGVvcDZtQWZz?= =?utf-8?B?OFN3K25HV2gxc0hzc2wvY0xVQ1BuQ2tpSTJubEp5MzRIVStVeEFUTWhsT0dI?= =?utf-8?Q?vCm6GxvLW6D4w2/g1DAsHlkbcSF5UOnkE/oms=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 09634B1196 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(396003)(376002)(136003)(346002)(199004)(189003)(66066001)(186003)(966005)(305945005)(6436002)(6486002)(8936002)(97736004)(76176011)(106356001)(2906002)(7736002)(102836004)(14444005)(256004)(6506007)(25786009)(5024004)(110136005)(83716004)(71200400001)(478600001)(71190400001)(105586002)(53936002)(33656002)(6246003)(99286004)(81166006)(8676002)(14454004)(36756003)(6306002)(316002)(3846002)(81156014)(11346002)(6512007)(446003)(2616005)(86362001)(476003)(66574012)(26005)(82746002)(2501003)(5660300002)(229853002)(68736007)(6116002)(486006); DIR:OUT; SFP:1101; SCL:1; SRVR:BN8PR11MB3665; H:BN8PR11MB3683.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: qsmIPFVmz8Ne/aNO4rQIxVpOaWTvaA+awiR8j3Bb7y4bsIdRKw+PAZJTkMQ4qnuuNQkC4xE3bTdARHZlGO1/UhzwJhwaMF4UwD0nvk8TvSgh8PvvAwf1c5dpwjNmaU+zLUgPLLEAxxA41SIHggRJck4qVhuwZXA411ZaTxoCQ+/DOauTFqaTg562QpSnD3BwvkqeNvQIwRxdVzM4Ca8mgsm/q6kma2SXAOEKASYjOvkevmmmLIV4A3QRpqd+Gds18DUnNuf2/xsEMoJMOQLr8sCM8bcqJBpudILR9PK67Zh6Zeh8t/U62LrYgRAdy+MIJICuy5oKXuOrWbpnKZOOSUz6PfpFDp2gpTcSd+b6GKLECBmSsj7HFAQ+c1mx9vIKwWgh5P7BWaReFfjEc5bGgHlU9RkGjukq6GqI4TN6tHE= Content-Type: text/plain; charset="utf-8" Content-ID: <82F60193D1665E468D96FFF188E80F71@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 5f80047a-acb5-4674-8b97-08d69e4b92ce X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Mar 2019 13:41:14.1188 (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-Transport-CrossTenantHeadersStamped: BN8PR11MB3665 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.16, xch-rcd-006.cisco.com X-Outbound-Node: alln-core-11.cisco.com Archived-At: Subject: Re: [Lsr] Calculating OSPF external routes for non-zero FA X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 13:41:21 -0000 SGkgQWxleGFuZGVyLCANCklmIHRoZSBBU0JSIGlzIG5vdCByZWFjaGFibGUsIHRoZSBBUy1FeHRl cm5hbCBMU0EgY291bGQgYmUgc3RhbGUgYW5kIHRoZSByb3V0ZSBpdCBvcmlnaW5hbGx5IGFkdmVy dGlzZWQgY291bGQgYmUgdW5yZWFjaGFibGUgb3IgYWRtaW5pc3RyYXRpdmUgcHJvaGliaXRlZCBp cnJlc3BlY3RpdmUgb2YgdGhlIHJlYWNoYWJpbGl0eSBvZiB0aGUgZm9yd2FyZGluZyBhZGRyZXNz Lg0KVGhhbmtzLA0KQWNlZQ0KDQrvu79PbiAzLzEvMTksIDg6MTYgQU0sICJMc3Igb24gYmVoYWxm IG9mIEFsZXhhbmRlciBPa29ubmlrb3YiIDxsc3ItYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYg b2YgYWxleGFuZGVyLm9rb25uaWtvdkBnbWFpbC5jb20+IHdyb3RlOg0KDQogICAgSGkgV0csDQog ICAgDQogICAgSSBkb24ndCBrbm93IHdoZXRoZXIgdGhlIHByb2JsZW0gYmVsb3cgaXMga25vd24g YWxyZWFkeSwgYnV0IEkgaGF2ZSBub3QgZm91bmQgbmVpdGhlciB1cGRhdGUgbm9yIGNvcnJlc3Bv bmRpbmcgZXJyYXRhIGZvciBSRkMgMjMyOC4gUkZDIDIzMjgsIHNlY3Rpb24gMTYuNCBzYXlzOg0K ICAgIA0KICAgICIoMykgLi4uICBMb29rIHVwIHRoZSByb3V0aW5nIHRhYmxlIGVudHJpZXMgKHBv dGVudGlhbGx5IG9uZSBwZXIgYXR0YWNoZWQgYXJlYSkgZm9yIHRoZSBBUyBib3VuZGFyeSByb3V0 ZXIgKEFTQlIpIHRoYXQgb3JpZ2luYXRlZCB0aGUgTFNBLiBJZiBubyBlbnRyaWVzIGV4aXN0IGZv ciByb3V0ZXIgQVNCUiAoaS5lLiwgQVNCUiBpcyB1bnJlYWNoYWJsZSksIGRvIG5vdGhpbmcgd2l0 aCB0aGlzIExTQSBhbmQgY29uc2lkZXIgdGhlIG5leHQgaW4gdGhlIGxpc3QuDQogICAgDQogICAg RWxzZSwgdGhpcyBMU0EgZGVzY3JpYmVzIGFuIEFTIGV4dGVybmFsIHBhdGggdG8gZGVzdGluYXRp b24gTi4gIEV4YW1pbmUgdGhlIGZvcndhcmRpbmcgYWRkcmVzcyBzcGVjaWZpZWQgaW4gdGhlIEFT LWV4dGVybmFsLUxTQS4gIFRoaXMgaW5kaWNhdGVzIHRoZSBJUCBhZGRyZXNzIHRvIHdoaWNoIHBh Y2tldHMgZm9yIHRoZSBkZXN0aW5hdGlvbiBzaG91bGQgYmUgZm9yd2FyZGVkLiAuLi4iDQogICAg DQogICAgYW5kDQogICAgDQogICAgIi4uLiBJZiB0aGUgZm9yd2FyZGluZyBhZGRyZXNzIGlzIG5v bi16ZXJvLCBsb29rIHVwIHRoZSBmb3J3YXJkaW5nIGFkZHJlc3MgaW4gdGhlIHJvdXRpbmcgdGFi bGUuWzI0XSBUaGUgbWF0Y2hpbmcgcm91dGluZyB0YWJsZSBlbnRyeSBtdXN0IHNwZWNpZnkgYW4g aW50cmEtYXJlYSBvciBpbnRlci1hcmVhIHBhdGg7IGlmIG5vIHN1Y2ggcGF0aCBleGlzdHMsIGRv IG5vdGhpbmcgd2l0aCB0aGUgTFNBIGFuZCBjb25zaWRlciB0aGUgbmV4dCBpbiB0aGUgbGlzdC4g Li4uIg0KICAgIA0KICAgIA0KICAgIEluIGNhc2Ugd2hlbiBBUy1leHRlcm5hbCBMU0EgaGFzIG5v bi16ZXJvIEZBLCB3aHkgZG8gd2UgbmVlZCB0byBsb29rIHVwIHRoZSByb3V0aW5nIHRhYmxlIGVu dHJpZXMgZm9yIEFTQlIsIHRoYXQgb3JpZ2luYXRlZCB0aGUgTFNBPyBJdCBpcyBwb3NzaWJsZSB0 aGF0IEZBIGlzIGF2YWlsYWJsZSB2aWEgb3RoZXIgQVNCUihzKS4gVGhpcyBpcyB2YWxpZCBjYXNl IHdoZW4gdGhlcmUgYXJlIG1vcmUgdGhhbiBvbmUgQVNCUnMsIGFuZCBhbGwgbWF5IG9yaWdpbmF0 ZSBBUy1leHRlcm5hbCBMU0Egd2l0aCB0aGUgc2FtZSBGQSBhbmQgbWV0cmljIGZvciBzb21lIGV4 dGVybmFsIGRlc3RpbmF0aW9uLCBidXQgb25seSBvbmUgKHdpdGggaGlnaGVzdCBSSUQpIHdpbGwg b3JpZ2luYXRlIHN1Y2ggTFNBIChSRkMgMjMyOCwgc2VjdGlvbiAxMi40LjQuMSkuIEFub3RoZXIg Y2FzZSB3aXRoIFR5cGUtNyB0byBUeXBlLTUgdHJhbnNsYXRpb24gZG9pbmcgYnkgQUJScyBpbiBD YW5kaWRhdGUgbW9kZSAoUkZDIDMxMDEpLg0KICAgIA0KICAgIFBlciBteSB1bmRlcnN0YW5kaW5n IGEgY2FsY3VsYXRpbmcgcm91dGVyIHNob3VsZCBpbml0aWFsbHkgYW5hbHlzZSBGQSB2YWx1ZSBh bmQgb25seSB0aGVuIGNoZWNrIGF2YWlsYWJpbGl0eSBvZiBBU0JSIG9yIEZBLCBkZXBlbmRpbmcg b24gd2hldGhlciBGQSBpcyB6ZXJvIG9yIG5vdC4gQW0gSSBtaXNzaW5nIHNvbWV0aGluZz8NCiAg ICANCiAgICBUaGFua3MuDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCiAgICBMc3IgbWFpbGluZyBsaXN0DQogICAgTHNyQGlldGYub3JnDQogICAg aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sc3INCiAgICANCg0K From nobody Fri Mar 1 06:02:37 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D965129741 for ; Fri, 1 Mar 2019 06:02:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 CMrJObnJ9pED for ; Fri, 1 Mar 2019 06:02:33 -0800 (PST) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 161E612894E for ; Fri, 1 Mar 2019 06:02:33 -0800 (PST) Received: by mail-lj1-x235.google.com with SMTP id g80so20478762ljg.6 for ; Fri, 01 Mar 2019 06:02:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9aqwsTDmrzucFkvtfTlGM6dkI6wWJJ3yLlzsqw/kxHs=; b=l7ySZHTSU85MqncipzVxLKz8yavz9aAnjRVWS/ejtDvzvuJdfb71U/XUleFQlLTl4f TVqvEKdGelop5cXwTyKzfscehRQ2DKWyow05k/O++fzqNA/8ij6PD30hOAZMWTPfi6S8 VZIqqkkuUw0I+g6W+zBIXUevLBYbEGeRBffYxodEZLXu7xIGzOQGhUcwSxz3pFcXjlcG oOqRErXGdzmfmF6Qr1pQkwyp5gHO+R3+2M+4jB9N7V3K/LwssOvMFPwPLj502D2ByufJ X9rDjeCRygQ7PxheCJD0bRvy4AvTXwtnnK0U+A/VzZfoc/Gv1iVe3nZ5doFgnq0JnoCn s36g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=9aqwsTDmrzucFkvtfTlGM6dkI6wWJJ3yLlzsqw/kxHs=; b=do1LcFBYXjcj1Gp75t489nkrUANHNB3ZQwON+yI9QFwN7yScj22jqBEO0Zebh+V0YD Ydy+AXDuBNAbGlr8mPaX7YffaMGxrjMyZz4tbHnZK0R93eRih8nWmLN3xrld8b/3CbCM Mg3F62M/uERI1uqqgKVSnCvO/8tH1hAsgvjglo52I878winfFoM5bT+2a7BsAt/rHs2q ErzOtxz/gYjkMnNSwJXpg7M+Uc0OTfZiZ+6PCUIPjVAhEwjkxrKknHCWBJiDZbJjbTdg I9Dw/h+G4w6iE30sOZIheMgb0AMI2mf4bDZ47jgogC+/zQcKc0c3WQMB9B3Fg7wSse/X mvJQ== X-Gm-Message-State: APjAAAVKipSqoENqLvAEaLutKn4T9RZJiE/JzCPqL/PtV++eyb5Xjx2v iFC51gppi6+cokRwIELNo8E= X-Google-Smtp-Source: APXvYqw7F6SR3mAAhwX3wSmE+xdXLlrz2/jXS3u62P8jiPzEbk/zGcq2N0ZG/DeU9KHn6YGnTOpiWQ== X-Received: by 2002:a2e:2202:: with SMTP id i2mr2967356lji.170.1551448951062; Fri, 01 Mar 2019 06:02:31 -0800 (PST) Received: from secretmaker-188.ip.peterstar.net (secretmaker-188.ip.PeterStar.net. [217.195.72.188]) by smtp.gmail.com with ESMTPSA id m6sm2286447lfa.36.2019.03.01.06.02.29 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 01 Mar 2019 06:02:30 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Alexander Okonnikov In-Reply-To: Date: Fri, 1 Mar 2019 17:02:29 +0300 Cc: "lsr@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <8CAFA47F-8188-4045-9CB8-CD1CFEC4DF1B@gmail.com> To: "Acee Lindem (acee)" X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Lsr] Calculating OSPF external routes for non-zero FA X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 14:02:36 -0000 Hi Acee, Got it now. We don't know in advance whether there are other ASBRs = which, while having connectivity to FA, have external routing = information. Thank you for explanation! > 1 =D0=BC=D0=B0=D1=80=D1=82=D0=B0 2019 =D0=B3., =D0=B2 16:41, Acee = Lindem (acee) =D0=BD=D0=B0=D0=BF=D0=B8=D1=81=D0=B0=D0=BB(= =D0=B0): >=20 > Hi Alexander,=20 > If the ASBR is not reachable, the AS-External LSA could be stale and = the route it originally advertised could be unreachable or = administrative prohibited irrespective of the reachability of the = forwarding address. > Thanks, > Acee >=20 > =EF=BB=BFOn 3/1/19, 8:16 AM, "Lsr on behalf of Alexander Okonnikov" = wrote: >=20 > Hi WG, >=20 > I don't know whether the problem below is known already, but I have = not found neither update nor corresponding errata for RFC 2328. RFC = 2328, section 16.4 says: >=20 > "(3) ... Look up the routing table entries (potentially one per = attached area) for the AS boundary router (ASBR) that originated the = LSA. If no entries exist for router ASBR (i.e., ASBR is unreachable), do = nothing with this LSA and consider the next in the list. >=20 > Else, this LSA describes an AS external path to destination N. = Examine the forwarding address specified in the AS-external-LSA. This = indicates the IP address to which packets for the destination should be = forwarded. ..." >=20 > and >=20 > "... If the forwarding address is non-zero, look up the forwarding = address in the routing table.[24] The matching routing table entry must = specify an intra-area or inter-area path; if no such path exists, do = nothing with the LSA and consider the next in the list. ..." >=20 >=20 > In case when AS-external LSA has non-zero FA, why do we need to = look up the routing table entries for ASBR, that originated the LSA? It = is possible that FA is available via other ASBR(s). This is valid case = when there are more than one ASBRs, and all may originate AS-external = LSA with the same FA and metric for some external destination, but only = one (with highest RID) will originate such LSA (RFC 2328, section = 12.4.4.1). Another case with Type-7 to Type-5 translation doing by ABRs = in Candidate mode (RFC 3101). >=20 > Per my understanding a calculating router should initially analyse = FA value and only then check availability of ASBR or FA, depending on = whether FA is zero or not. Am I missing something? >=20 > Thanks. > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr >=20 >=20 From nobody Fri Mar 1 13:13:52 2019 Return-Path: X-Original-To: lsr@ietf.org Delivered-To: lsr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E159D130EFF; Fri, 1 Mar 2019 13:10:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: lsr@ietf.org, aretana.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.92.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155147460391.6101.14309511614879376026.idtracker@ietfa.amsl.com> Date: Fri, 01 Mar 2019 13:10:03 -0800 Archived-At: Subject: [Lsr] lsr - Requested sessions have been scheduled for IETF 104 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Mar 2019 21:10:15 -0000 Dear Acee Lindem, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. lsr Session 1 (1:30 requested) Wednesday, 27 March 2019, Morning Session II 1120-1320 Room Name: Congress Hall 3 size: 250 --------------------------------------------- lsr Session 2 (2:00 requested) Thursday, 28 March 2019, Afternoon Session II 1610-1810 Room Name: Congress Hall 1 size: 250 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/104/sessions/lsr.ics Request Information: --------------------------------------------------------- Working Group Name: Link State Routing Area Name: Routing Area Session Requester: Acee Lindem Number of Sessions: 2 Length of Session(s): 2 Hours, 1.5 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: rtgwg idr ipsecme lsvr Second Priority: rift netmod Third Priority: bier bess People who must be present: Acee Lindem Christian Hopps Alvaro Retana Resources Requested: Special Requests: --------------------------------------------------------- From nobody Sat Mar 2 09:57:47 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18E5012D4EF; Sat, 2 Mar 2019 09:57:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.onmicrosoft.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 6JBr3OuUpyfo; Sat, 2 Mar 2019 09:57:34 -0800 (PST) Received: from mail1.bemta26.messagelabs.com (mail1.bemta26.messagelabs.com [85.158.142.116]) (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 A1CD8130E09; Sat, 2 Mar 2019 09:57:29 -0800 (PST) Received: from [85.158.142.193] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-5.bemta.az-b.eu-central-1.aws.symcld.net id 6F/49-12473-604CA7C5; Sat, 02 Mar 2019 17:57:26 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WTWUwTURSGubOUsVIdisqxQR+KPlgzpRVJqon RmGiIxsQHfdCIMoWRVspQ2xIKxgQlatxAE3woipVacYEYa4o0uBMjKEqBB4iIEqQqYkSRBjTi MkvdXm6++///OffcyR0KV0cVGopzuzgHz9q0CiWxdNGXBQz5oHSb4Uaj0fS8xkeY2iKXSFPo5 iGFqbXzG1pFZFZ9C5CZfv9XbCO2lbTy5kJ3Nmlp833E7X6z+8Z4NVGGujYdQUqKoH04VDVNIH GjpisxeDt6GZc3/QiqR8KCM41S0Cvgev0Lhciz6AVwtvcYIYZw+jaCwLHnUiiJXgITFw4jOZQ Oox198TIvhy7PfUknhOJI05ikq+gsOPklQMqnVSC4ODkkhaYJp1X0+KQQoufA5OMGTGScToa+ iFdioGnw3wrjMs+Gd0M/SDlvhoHXtUjWtXCms5GUeR50e4/G9A3wcN+gwJTAqRAczhJnAHoIw ff2/lh/Hbwoj8ZqNVAbjsbLoZ6Z0PmzgZANG4zVf46FUqDd/10hhzwKCHn6penUdA60nRmPFc yHK8cHY9yJQ8v5hSeQrvqfy8nMQ/mBPqJa+kqJ8MgTIWTdAB87vLjMi6Gu9n2M0yAQfYr+1c+ h+CvIZHZY8yyuAtZqY4wGA2M0pjMZTEa6ni1lzHquiMnheJeDFUw9W+zUO0sKcmy5ep5zXUfC S8vdTWaE0IdDeS1oLoVpZ6s+1ZZuU88wF+aWWFinZYejyMY5W1AKRWlBFW4RvEQHl8e5d1ptw nP9bQOVoJ2lCoq2ymlnC5zWPNl6jNZQ93yDNThVEXgjrMEBcW2WVo/nbQ2uJvhCntMkqx6Kxb RYbCni/7T+/TN0o3maJBWKi4tTJ9g5R4HV9b8/gpIppE1SvW8WuiRYedefCUaE4TBhOGagWBz Oxf61NGXojrcmlL35ZWtva+HuYe96XXHVyoMT0bRQ02Bk61rLsoajiy/NuaYc2z6MTdVPpaRd 2zBFpGLjp8p2xY8G7RPhnj14yfRez9k7T9x105XrDKtP2xnfXf/8zZXc5Oje1Mzl+cuyuFdX2 THXz2adL5C/PnGlMpi9/1XmlvL8yvLGZ5iWcFpYow53ONlf4S0eTwcEAAA= X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-4.tower-238.messagelabs.com!1551549442!2131170!1 X-Originating-IP: [52.41.248.36] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.31.5; banners=ecitele.com,-,- X-VirusChecked: Checked Received: (qmail 2511 invoked from network); 2 Mar 2019 17:57:24 -0000 Received: from us-west-2a.mta.dlp.protect.symantec.com (HELO EUR03-DB5-obe.outbound.protection.outlook.com) (52.41.248.36) by server-4.tower-238.messagelabs.com with AES256-SHA256 encrypted SMTP; 2 Mar 2019 17:57:24 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/i63QDzV8//CyUlmZGWb8jJeENpimCWQdh2hfg8qnqs=; b=Ic7QYubpPxAJ2lF5EZfmQ3ZvY+BjfY7M8YsoKEq+HBRz4yiBnkZhOWrCRa7mD2dGWPtYXD5F/B5kfnGS1M2fZ+srvEwb1j+ukG21QlebkeuXJECcOwBre/5N7KjESfrUHfKO3AIj8ZO5qcfOPH4CiKrSGun6nXr3mBqhjg7cU94= Received: from AM0PR03MB3828.eurprd03.prod.outlook.com (52.135.146.159) by AM0PR03MB3635.eurprd03.prod.outlook.com (52.134.81.30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.16; Sat, 2 Mar 2019 17:57:19 +0000 Received: from AM0PR03MB3828.eurprd03.prod.outlook.com ([fe80::cd69:f7a:ee65:6435]) by AM0PR03MB3828.eurprd03.prod.outlook.com ([fe80::cd69:f7a:ee65:6435%6]) with mapi id 15.20.1665.019; Sat, 2 Mar 2019 17:57:19 +0000 From: Alexander Vainshtein To: Peter Psenak CC: "lsr@ietf.org" , "spring@ietf.org" , "draft-ietf-isis-segment-routing-extensions.all@ietf.org" Thread-Topic: [spring] FlexAlgo and Global Adj-SIDs Thread-Index: AdTPjdP9QRfJ5GzARfmqN1/BpEhW0gAEem2AAGBozJQ= Date: Sat, 2 Mar 2019 17:57:19 +0000 Message-ID: References: , <20493a62-cf70-a182-900d-e55dd68f5149@cisco.com> In-Reply-To: <20493a62-cf70-a182-900d-e55dd68f5149@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [52.142.119.234] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f46cff3f-6976-457d-f2ba-08d69f3883a2 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7153060)(7193020); SRVR:AM0PR03MB3635; x-ms-traffictypediagnostic: AM0PR03MB3635: x-ms-exchange-purlcount: 3 x-microsoft-exchange-diagnostics: =?Windows-1252?Q?1; AM0PR03MB3635; 23:ce369xH94TAYIiNjQvGiNfx9CGgn1cc/kI7/8?= =?Windows-1252?Q?WnGrX5IbjKzVGTRMEWz7PjYEZJcCcBD98/RbD4JOV/MuXpuCFACxKDnC?= =?Windows-1252?Q?i0CJP8fq5SbpqB/X/qUX80harD0t1C/z5z8d4D8L1eUKKbXTuQMt9vyr?= =?Windows-1252?Q?cOaf0D/ycdl/N98pLFysQxq9vSDVctoALa5hJY5etgDHDCRj8LIdID2A?= =?Windows-1252?Q?fsOVwO/PRZeyr9N0gD9gxr12CxVi/uMv1TQa+hLzdLFCD8f8zwvOoseT?= =?Windows-1252?Q?5qZbC+K+3KYq4fYhu1LDtdy3G8eYaCDIpgcRsUHsVJ2WXkCqjHwzT0WA?= =?Windows-1252?Q?TEIP6icAbXP8G/7LWwhvNUoHO8B9sNSTtdLOxKuZr5CsGP4BK5jWKmY1?= =?Windows-1252?Q?ib9kFzi8NihSea59joS+FkogPHqfMAevMvAmqyXV/lM6WLEsGvppPww1?= =?Windows-1252?Q?h3KMm03CtTDTrabKvzC1qem/3B9dN99XSeUDVpW1SXjXiCdZfv2bZJy2?= =?Windows-1252?Q?VQg+NkH6T/Dx9udKnCZhIV676ad7lvhdfjxZzDldK8t7Jdc3oDU3mGsK?= =?Windows-1252?Q?Da6XCJYafYZ/xI/nFWZUw2ZaAi/sNERxPpcxi0CrXjIR6FcnmVP5DCpm?= =?Windows-1252?Q?i68jLJnhzCdCEEpiyM5gT+MVoqupo/jZIXnrZxCMT3F4YXcK5l3zdHH0?= =?Windows-1252?Q?kjgoCnrpRSJIooTktsvvmQBcgYgu9OMG51Ge9av2APlG9r72uLuFhZ+9?= =?Windows-1252?Q?Dk25kxzlJPskotMJNMzPO4vQSYnBvimrupftPfuFfqgC4+nGXZhXxtYr?= =?Windows-1252?Q?cfsRMGIEyc/IuhlJqQaWOgnea7G0+ztjVoiSw0wFkTVrEQjZRXZaxa9e?= =?Windows-1252?Q?wWyuOA7iHE1g/mluzAqoDPOZiukmh0lsM3ZcYTYb/y5+bIYPGIlOGB0+?= =?Windows-1252?Q?6KqPlsLDEDEwkdibdsuUHhHKJ1o+1yq7eEXqYVSay02bW5Da1ChHUCbb?= =?Windows-1252?Q?QhMMsWKMs+gmEdOZG1UfiTtFZq/qWP176TwyEHzR4VP/ikqBq2L6/ViF?= =?Windows-1252?Q?EN391U0tcKeJCfI7JtO5Z/e224ePuOkJQ33lV2O7pBmMf8oYDLEqdfg7?= =?Windows-1252?Q?Y5vWivXXnnaGzjC2bWCCgy9W81553nYrOc7ePu/FlOiWyJDB9PY6/Ud2?= =?Windows-1252?Q?WZAJeo6C7GblUHHqnP2IX931aE5T/Xz4wkA80PBShp4BveVsQL/e4vmC?= =?Windows-1252?Q?14WUW+i/qYNywV8r491ZjB8jnMCAyXJeoA+4TU4wMd91GtS/ZMgQpAB7?= =?Windows-1252?Q?96e07gONULVx4K5sFksho9uTqhoE4ptyvNX8Uf1NGMDjNVbBbRnpvdTR?= =?Windows-1252?Q?ckQ7by03HadvlQQLkmYHBDAMjYgVR0E3I63CBpzRdzcOIY6am5IZBR+9?= =?Windows-1252?Q?ZW7FxVbtVzuEqi4r5DTwxBcr25EjaDH+rXZ4CKGGTUZhr5Tyk53RLeJh?= =?Windows-1252?Q?VOghUhy60cZ1ZSxWkwierNc1VGV?= x-microsoft-antispam-prvs: x-forefront-prvs: 09645BAC66 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(376002)(39850400004)(366004)(346002)(136003)(189003)(199004)(51874003)(54094003)(71200400001)(6436002)(71190400001)(52536013)(256004)(14444005)(5024004)(5660300002)(966005)(8936002)(53936002)(478600001)(106356001)(105586002)(72206003)(68736007)(476003)(11346002)(54896002)(6306002)(236005)(9686003)(6916009)(55016002)(74316002)(86362001)(446003)(486006)(229853002)(99286004)(2906002)(7736002)(6116002)(3846002)(7696005)(316002)(6506007)(53546011)(102836004)(66066001)(76176011)(186003)(33656002)(6246003)(97736004)(606006)(25786009)(4326008)(14454004)(54906003)(81166006)(81156014)(8676002)(26005); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR03MB3635; H:AM0PR03MB3828.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 2z6zq/MDCxnW7MSTC2fcLVdjN04mMupmyv6qRCfGRQ2fXnJZjynE4EnmxmeV3pqUfs8EL7RqoeRnN0PvHbvSH5u2nOn+a899LPnv93O3hIeTvo8nQYQhTvFNWKBKde6/xGo/oaFPV0o/rGClWHVrlA+h4uSME8u+U0+xEm91Tt1wFbMLhFg8fBd9pkuGYnUfLgzDOjLGZHfc8e38gvH8AxBbpboObGp0hDN7/Nk3yZvyJ6T1nczfsjkqe7GjQKcJGGe+D9ejI4t1wDqdXmq0eAuvsU1VPpIxrzGAl7kL90VzyoRme/GipnLTqtrbMpo5GkjfjnSi9QikzWVaKMRYa9E6FZqFc3Iv1xBIexZL38RufD7fgZP3+0/OKR7Y/TrxCMBcwxFc6Fb1JOaOU1MmFneIdIvFkrBPg4gVaVlDGJE= Content-Type: multipart/alternative; boundary="_000_AM0PR03MB38286EFCFC0357EDB1D782679D770AM0PR03MB3828eurp_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-Network-Message-Id: f46cff3f-6976-457d-f2ba-08d69f3883a2 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Mar 2019 17:57:19.3051 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR03MB3635 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Lsr] [spring] FlexAlgo and Global Adj-SIDs X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Mar 2019 17:57:38 -0000 --_000_AM0PR03MB38286EFCFC0357EDB1D782679D770AM0PR03MB3828eurp_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Peter, Lots of thanks for a prompt and hivhly informative response. It seems that per-FlexAlgo Adj-SIDs can be useful even if they are local. The relevant use case could be a protected local Adj-SID that is used in a= SR-TE LSP that has been set up with some constraints in mind. These const= raints would be preserved when the protected adjacency in question is UP, = but could be violated when it fails and the shortest path to the node at t= he remote end of adjacency is used. Local protected Adj-SIDs for sure have bern implemented, so this looks lik= e a more relevant use case than global adjacencies to me. What do you think? Regards, and lots of thanks in advance, Thumb typed by Sasha Vainshtein ________________________________ From: Peter Psenak Sent: Thursday, February 28, 2019 9:56:49 PM To: Alexander Vainshtein; draft-ietf-isis-segment-routing-extensions@ietf.= org Cc: lsr@ietf.org; spring@ietf.org Subject: Re: [spring] FlexAlgo and Global Adj-SIDs Hi Alexander, On 28/02/2019 19:19 , Alexander Vainshtein wrote: > Dear colleagues, > > I have a question regarding global Adj-SIDs in > draft-ietf-isis-segment-routing-extensions. > > > > Section 3.4 of RFC 8402 defines > definition and handling of global Adj-SIDs. > > The relevant text is given below: > > > > > > Similarly, when using a global Adj-SID, a packet injected anywhere > > within the SR domain with a segment list {SNL}, where SNL is a global= > > Adj-SID attached by node N to its adjacency over link L, will be > > forwarded along the shortest path to Nand then be switched by N, > > without any IP shortest-path consideration, towards link L. > > ... > > The use of global Adj-SID allows to reduce the size of the segment li= st > > When expressing a path at the cost of additional state (i.e., the glo= bal > > Adj-SID will be inserted by all routers within the area in their > > forwarding table). > > > > > > The definition of the Adjacency Segment Identifier=20Sub-TLV in Section > 2.2.1 of the draft matches the behavior defined in RFC 8402, i.e., it > allows advertisement of global Adj-SIDs. > > These advertisements can be associated with a specific IGP adjacency > and, in multi-topology scenarios, a specific topology. But it is not > associated with any specific algorithm since the default algorithm for > reaching the advertising node is implicitly assumed in full alignment > with RFC 8402. > > > > My question is about the situation in which multiple algorithms are > supported by the routers in the SR domain, so that each node advertises > a dedicated Node SID for each of these algorithm. > > In this scenario, the operator can set up a SR-TE LSP that meets > specific constraints (incorporated in one of these algorithms, see IGP > Flexible Algorithm > draft) by > using Node SIDs that have been advertised with the corresponding > algorithm and local Adj-SIDs. However, global Adj-SIDs cannot be used > (e.g.,=20for reducing the label stack depth) in this situation. > > I wonder if the possibility to advertise global Adj-SID (that can be > considered as replacing a combination of the Node SID of the advertising= > node and one of its local Adj-SIDs) as associated with a specific > algorithm has ever been considered? to be honest, it has been not. The usage of the global Adj-SID has not been widely considered due to the additional forwarding entries it requires on rest of the routers in the area. Not sure if there are implementations of the global ADj-SID out there. If you believe this is important, we can certainly addressed that in a small draft. thanks, Peter > > > > Regards, and lots of thanks in advance, > > Sasha > > > > Office: +972-39266302 > > Cell: +972-549266302 > > Email: Alexander.Vainshtein@ecitele.com > > > > > ________________________________________________________________________= ___ > > This e-mail message is intended for the recipient only and contains > information which is > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have > received this > transmission in error, please inform us by e-mail, phone or fax, and > then delete the original > and all copies thereof. > ________________________________________________________________________= ___ > > > _______________________________________________ > spring mailing list > spring@ietf.org > https://www.ietf.org/mailman/listinfo/spring > __________________________________________________________________________= _ This e-mail message is intended for the recipient only and contains inform= ation which is=20 CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this=20 transmission in error, please inform us by e-mail, phone or fax, and then = delete the original=20 and all copies thereof. __________________________________________________________________________= _ --_000_AM0PR03MB38286EFCFC0357EDB1D782679D770AM0PR03MB3828eurp_ Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Peter,
Lots of thanks for a prompt and hivhly informative response.

It seems that per-FlexAlgo Adj-SIDs can be useful even if they are local.<= br>
The relevant use case could be a protected local Adj-SID that is used in a= SR-TE LSP that has been set up with some constraints in mind. These const= raints would be preserved when the protected adjacency in question is UP, = but could be violated when it fails and the shortest path to the node at the remote end of adjacency is used.=

Local protected Adj-SIDs for sure have bern implemented, so this looks lik= e a more relevant use case than global adjacencies to me.

What do you think?

Regards, and lots of thanks in advance,

Thumb typed by Sasha Vainshtein

From: Peter Psenak <= ppsenak@cisco.com>
Sent: Thursday, February 28, 2019 9:56:49 PM
To: Alexander Vainshtein; draft-ietf-isis-segment-routing-extension= s@ietf.org
Cc: lsr@ietf.org; spring@ietf.org
Subject: Re: [spring] FlexAlgo and Global Adj-SIDs
 
Hi Alexander,

On 28/02/2019 19:19 , Alexander Vainshtein wrote:
> Dear colleagues,
>
> I have a question regarding global Adj-SIDs in
> draft-ietf-isis-segment-routing-extensions.
>
>
>
> Section 3.4 of RFC 8402 <https://tools.ietf.org/html/rfc8402>  defines
> definition and handling of global Adj-SIDs.
>
> The relevant text is given below:
>
>
>
> <quote>
>
>    Similarly, when using a global Adj-SID, a packet in= jected anywhere
>
>    within the SR domain with a segment list {SNL}, whe= re SNL is a global
>
>    Adj-SID attached by node N to its adjacency over li= nk L, will be
>
>    forwarded along the shortest path to Nand then be s= witched by N,
>
>    without any IP shortest-path consideration, towards= link L.
>
> ...
>
>    The use of global Adj-SID allows to reduce the size= of the segment list
>
>    When expressing a path at the cost of additional st= ate (i.e., the global
>
>    Adj-SID will be inserted by all routers within the = area in their
>
>    forwarding table).
>
> <end quote>
>
>
>
> The definition of the Adjacency Segment Identifier Sub-TLV in Section=
> 2.2.1 of the draft matches the behavior defined in RFC 8402, i.e., it=
> allows advertisement of global Adj-SIDs.
>
> These advertisements can be associated with a specific IGP adjacency<= br> > and, in multi-topology scenarios, a specific topology. But it is not<= br> > associated with any specific algorithm since the default algorithm fo= r
> reaching the advertising node is implicitly assumed in full alignment=
> with RFC 8402.
>
>
>
> My question is about the situation in which multiple algorithms are > supported by the routers in the SR domain, so that each node advertis= es
> a dedicated Node SID for each of these algorithm.
>
> In this scenario, the operator can set up a SR-TE LSP that meets
> specific constraints (incorporated in one of these algorithms, see IG= P
> Flexible Algorithm
> <https://tools.ietf.org/html/draft-ietf-lsr-flex-algo-01> draft) = by
> using Node SIDs that have been advertised with the corresponding
> algorithm and local Adj-SIDs. However, global Adj-SIDs cannot be used=
> (e.g., for reducing the label stack depth) in this situation.
>
> I wonder if the possibility to advertise global Adj-SID (that can be<= br> > considered as replacing a combination of the Node SID of the advertis= ing
> node and one of its local Adj-SIDs) as associated with a specific
= > algorithm has ever been considered?

to be honest, it has been not.

The usage of the global Adj-SID has not been widely considered due to
= the additional forwarding entries it requires on rest of the routers in the area. Not sure if there are implementations of the global ADj-SID
= out there.

If you believe this is important, we can certainly addressed that in a small draft.

thanks,
Peter




>
>
>
> Regards, and lots of thanks in advance,
>
> Sasha
>
>
>
> Office: +972-39266302
>
> Cell:      +972-549266302
>
> Email:   Alexander.Vainshtein@ecitele.com
>
>
>
>
> _____________________________________________________________________= ______
>
> This e-mail message is intended for the recipient only and contains > information which is
> CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have=
> received this
> transmission in error, please inform us by e-mail, phone or fax, and<= br> > then delete the original
> and all copies thereof.
> _____________________________________________________________________= ______
>
>
> _______________________________________________
> spring mailing list
> spring@ietf.org
> https://www.= ietf.org/mailman/listinfo/spring
>
__________________________________________________________________________= _

This e-mail message is intended for the recipient only and contains inform= ation which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this
transmission in error, please inform us by e-mail, phone or fax, and then = delete the original
and all copies thereof.
__________________________________________________________________________= _
--_000_AM0PR03MB38286EFCFC0357EDB1D782679D770AM0PR03MB3828eurp_-- From nobody Mon Mar 4 09:54:31 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15920130F2A for ; Mon, 4 Mar 2019 09:54:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.018, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 LGwswHqVlACD for ; Mon, 4 Mar 2019 09:54:26 -0800 (PST) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (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 DB143130FF3 for ; Mon, 4 Mar 2019 09:54:26 -0800 (PST) Received: by mail-pf1-x435.google.com with SMTP id n74so3543253pfi.9 for ; Mon, 04 Mar 2019 09:54:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:content-transfer-encoding:mime-version:subject :message-id:date:to; bh=ankPuJ5HFdbzGLEGQz5NDlOK/RWPPf4tT7T1CTDrPNI=; b=c+xEY3DM7jnfHWFM20XYpDbwuJ1T9f5P6X7loEnXsnPZcHHLelDrpWNs/GRlFqPzdX 53RFetWW/0Sc+yNdIgeZAkPa9MvOHjTIiKTk5q/izsEcYt1ouvr9qmo7GxjJypy4P4vh oJFJGeRD/J872Y6Ba09k0QFWJJ9Z/Nb0d6KEdWXqJneNIqgwyvmRL+Dd0NqZtzJt6jd9 Xku9MCbLSjR7qCShxcohbjPiHwnMZb7I2Klg0ykCJsZN6NG77z17vv274kofRaI+bwVy WcYYXp2dgErNyoMteLay0sCpNKCLHlF5T5WFPFnZoVhOWvdtXODCbSHaMh0hb54ytHJ4 T05A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:content-transfer-encoding :mime-version:subject:message-id:date:to; bh=ankPuJ5HFdbzGLEGQz5NDlOK/RWPPf4tT7T1CTDrPNI=; b=JM4/c5hOb2r5E992TkgO7hxxg2At4a9UGWqaycFk1rEcFugXoBU81CrFpMHbjjixwq IWh9SteAnpM+ya5yWvTpaOVQQ4lFXMTVOjwfC/VaikAnHmXr8nkCHFCreHtqaURjyO8p aA17QlTp+ZUnSg2ZMF/AF4dVQ1FHLrFP5w00qidXixrAd1F2pJSMBO6xU3qUTi9h6JeH BC54ecQKbUqPiWsVoVEB9wIOrOxdrXceu5Qn76sxIJkYtyHueSzpvdLG8ckCnf2eQYPx aQoIKw66F6dKZr8Dp0EE+fvuVk4Me71VQO7o+enhFu+ieoPiRvz8ub3JC55Wa4Nkafz1 jhCw== X-Gm-Message-State: AHQUAubXG8jBvWk/72MFu/mgbuMDn0RJSsarQ7XH6TVN0gFtxrnirnb8 cV60YLpkO0ejODIv6LpssuUiLg98 X-Google-Smtp-Source: APXvYqzZwz7aWoUzhvx41J+Jl058FiteyY6nlHidpsHd2Q75YfFWtzVblxRTWNwtpz8Jn4+ciuj5Bg== X-Received: by 2002:a62:53c7:: with SMTP id h190mr21591899pfb.204.1551722065916; Mon, 04 Mar 2019 09:54:25 -0800 (PST) Received: from [172.22.228.216] ([162.210.130.3]) by smtp.gmail.com with ESMTPSA id r86sm10818097pfa.82.2019.03.04.09.54.25 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 04 Mar 2019 09:54:25 -0800 (PST) Sender: Tony Li From: tony.li@tony.li Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-Id: Date: Mon, 4 Mar 2019 09:54:24 -0800 To: lsr@ietf.org X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: [Lsr] Open issues with Dynamic Flooding X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Mar 2019 17:54:29 -0000 Hello, There are still two issues that need to be discussed and I was hoping = that we could make progress on the mailing list before Prague. 1) Temporary additions to the flooding topology There are several cases where we would like to make temporary = additions to the flooding topology: repairing a partition of the = flooding topology or adding a node to the base topology for the first = time. We can: (a) Temporarily add all of the links that would appear to remedy the = partition. This has the advantage that it is very likely to heal the = partition and will do so in the minimal amount of convergence time. (b) For each node adjacent to the partition, add no more than a = single link across the partition. If that does not repair the partition = in a while (LSP propagation time + SPF time), then add another link. =20 Iterate as necessary. This has the advantage that it minimizes = the risk of creating a cascade failure. 2) Inclusion of pseduonodes in the System IDs TLV In the general case, a topology can include LANs. If a LAN is in = parallel with a P2P link, the Area Leader cannot currently distinguish = between the two links. This can be of importance if there are other=20 systems also on the LAN that should be using their LAN interface for = flooding. We propose to change the System IDs TLV to include a pseudo-node ID = as well as the system ID. It would also make sense to rename the TLV to = be the =E2=80=9CIS-IS Area Node IDs TLV=E2=80=9D. Behaviorally, we should add a requirement that if the Area Leader = includes a pseudonode in the flooding topology, then all systems with an = adjacency on that LAN should use the LAN as part of the=20 flooding topology, whether or not they are explicitly listed as = adjacent to the LAN in the Flooding Path TLV. Thoughts? Comments? Flames? Regards, Tony From nobody Mon Mar 4 20:16:29 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C41D7130E81 for ; Mon, 4 Mar 2019 20:16:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 iQvrEPNvj6Wt for ; Mon, 4 Mar 2019 20:16:25 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F19C130EC3 for ; Mon, 4 Mar 2019 20:16:25 -0800 (PST) Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 481CD9A2CBDC3CBB72F1 for ; Tue, 5 Mar 2019 04:16:23 +0000 (GMT) Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 5 Mar 2019 04:16:22 +0000 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.96]) by SJCEML703-CHM.china.huawei.com ([169.254.5.129]) with mapi id 14.03.0415.000; Mon, 4 Mar 2019 20:16:18 -0800 From: Huaimo Chen To: Tony Li CC: "Acee Lindem (acee)" , Christian Hopps , "lsr@ietf.org" Thread-Topic: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux] Thread-Index: AQHUuilbECC1DxP5/E+8dX31Ej0g66XL9lOggALa/AD//3qaEIAEyqeAgAs0jTCAATTTgIAGRA1AgACN4ACAA0GHUIAAy+kAgBI/VHA= Date: Tue, 5 Mar 2019 04:16:16 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D463B669E8@sjceml521-mbx.china.huawei.com> References: <5316A0AB3C851246A7CA5758973207D463B3B9D8@sjceml521-mbx.china.huawei.com> <8378287F-27B9-4663-A22B-F8A2EC6C9FC3@cisco.com> <5316A0AB3C851246A7CA5758973207D463B46315@sjceml521-mbx.china.huawei.com> <5316A0AB3C851246A7CA5758973207D463B4A6AB@sjceml521-mbx.china.huawei.com> <25021deb-2032-9fcc-4bf4-fcaaa21598b9@cisco.com> <5316A0AB3C851246A7CA5758973207D463B56620@sjceml521-mbx.china.huawei.com> <59b45885-3e06-e3d0-5c09-2cbee4cef341@cisco.com> <5316A0AB3C851246A7CA5758973207D463B57ED6@sjceml521-mbx.china.huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.237] Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D463B669E8sjceml521mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux] X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 04:16:29 -0000 --_000_5316A0AB3C851246A7CA5758973207D463B669E8sjceml521mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVG9ueSwNCg0KPkZyb206IFRvbnkgTGkgW21haWx0bzp0b255MWF0aG9tZUBnbWFpbC5jb21d DQo+U2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDIxLCAyMDE5IDEyOjMyIEFNDQo+VG86IEh1YWlt byBDaGVuIDxodWFpbW8uY2hlbkBodWF3ZWkuY29tPg0KPkNjOiBQZXRlciBQc2VuYWsgPHBwc2Vu YWtAY2lzY28uY29tPjsgQWNlZSBMaW5kZW0gKGFjZWUpIDxhY2VlQGNpc2NvLmNvbT47IENocmlz dGlhbiBIb3BwcyA+PGNob3Bwc0BjaG9wcHMub3JnPjsgbHNyQGlldGYub3JnDQo+U3ViamVjdDog UmU6IFtMc3JdIE1vdmluZyBGb3J3YXJkIFtSZTogRmxvb2RpbmcgUmVkdWN0aW9uIERyYWZ0IFJl ZHV4XQ0KPg0KPg0KPkhpIEh1YWltbywNCj4NCj4+VGhlIHdheSBpbiB3aGljaCB0aGUgZmxvb2Rp bmcgdG9wb2xvZ3kgY29udmVyZ2VzIGluIHRoZSBjZW50cmFsaXplZCBtb2RlL3NvbHV0aW9uIGlz IGRpZmZlcmVudA0KPj5mcm9tIHRoYXQgaW4gdGhlIGRpc3RyaWJ1dGVkIG1vZGUvc29sdXRpb24u IEluIHRoZSBmb3JtZXIsIGFmdGVyIHJlY2VpdmluZyB0aGUgbGluayBzdGF0ZXMgZm9yIHRoZSBm YWlsdXJlcywNCj4+dGhlIGxlYWRlciBjb21wdXRlcyBhIG5ldyBmbG9vZGluZyB0b3BvbG9neSBh bmQgZmxvb2RzIGl0IHRvIGV2ZXJ5IG90aGVyIG5vZGUsIHdoaWNoIHJlY2VpdmVzDQo+PmFuZCBp bnN0YWxscyB0aGUgbmV3IGZsb29kaW5nIHRvcG9sb2d5LiBUaGUgd29ya2luZyBsb2FkIG9uIGV2 ZXJ5IG5vbiBsZWFkZXIgbm9kZSBpcyBsaWdodC4gSXQgaGFzIG1vcmUNCj4+cHJvY2Vzc2luZyBw b3dlciBmb3IgYSBwcm9jZWR1cmUvbWV0aG9kIGZvciBmYXVsdCB0b2xlcmFuY2UgdG8gZmFpbHVy ZXMuDQo+Pkhvd2V2ZXIsIGluIHRoZSBsYXR0ZXIsIGV2ZXJ5IG5vZGUgY29tcHV0ZXMgYW5kIGlu c3RhbGxzIGEgbmV3IGZsb29kaW5nIHRvcG9sb2d5IGFmdGVyIHJlY2VpdmluZw0KPj50aGUgbGlu ayBzdGF0ZXMgZm9yIHRoZSBmYWlsdXJlcy4gSXQgaGFzIGxlc3MgcHJvY2Vzc2luZyBwb3dlciBm b3IgYSBwcm9jZWR1cmUvbWV0aG9kIGZvciBmYXVsdCB0b2xlcmFuY2UuDQo+Pkl0IGlzIGJldHRl ciB0byBsZXQgZWFjaCBvZiB0aGUgdHdvIG1vZGVzIHVzZSBpdHMgb3duIHByb2NlZHVyZS9tZXRo b2QgZm9yIGZhdWx0IHRvbGVyYW5jZSB0byBmYWlsdXJlcywNCj4+d2hpY2ggaXMgbW9yZSBhcHBy b3ByaWF0ZSB0byBpdC4NCj4NCj5JdOKAmXMgdHJ1ZSB0aGF0IGEgZGlzdHJpYnV0ZWQgc29sdXRp b24gd2lsbCBjYWxsIG1vcmUgb24gYW4gYXZlcmFnZSBub2RlIHRoYW4gYSBjZW50cmFsaXplZA0K PnNvbHV0aW9uIHdpbGwuIEhvd2V2ZXIsIHRoYXQgaXMgbm90IHRoZSBzdGVhZHkgc3RhdGUgZm9y IGVpdGhlci4gSW4gdGhlDQo+c3RlYWR5IHN0YXRlLCB0aGUgZmxvb2RpbmcgdG9wb2xvZ3kgaGFz IGJlZW4gY29tcHV0ZWQgYW5kIGhhcyBiZWVuIHB1dCBpbiBwbGFjZSBhbHJlYWR5Lg0KPlRodXMs IHRoZSBpbXBhY3Qgb2YgdGhlIHRvcG9sb2d5IGNvbXB1dGF0aW9uIGF0IHRoZSB0aW1lIG9mIHRo ZQ0KPnRvcG9sb2d5IGNoYW5nZSBpcyBuaWwuDQo+DQo+SW4gYWRkaXRpb24sIHRoZSBhbW91bnQg b2Ygd29yayB0byB0ZW1wb3JhcmlseSBhbWVuZCB0aGUgZmxvb2RpbmcgdG9wb2xvZ3kgc2hvdWxk IGFsc28NCj5iZSBtaW5pbWFsLCBhbmQgYnkgdGhhdCwgSSBtZWFuIE8obG9nIG4pLiAgVGhlIGRl Y2lzaW9uIHNob3VsZCBvbmx5DQo+YmUgd2hldGhlciBvciBub3QgdG8gdGVtcG9yYXJpbHkgYWRk IGEgbGluayB0byBmbG9vZGluZywgYW5kIHRoZSBvbmx5IGluZm9ybWF0aW9uIHRoYXQgYSBub2Rl DQo+bmVlZHMgdG8gZG8gdGhhdCBpcyB0byBkZXRlcm1pbmUgaWYgdGhlIG5vZGUgaXMgYWxyZWFk eSBvbiB0aGUNCj5mbG9vZGluZyB0b3BvbG9neS4gVGhhdCBzaG91bGQgYmUgYSBsb29rdXAgaW4g YSB0cmVlIHRoYXQgcmVwcmVzZW50cyB0aGUgbm9kZXMgb24gdGhlIHRvcG9sb2d5LA0KPmFuZCB0 aGF0IGxvb2t1cCBzaG91bGQgYmUgTyhsb2cgbikuIEluIG90aGVyIHdvcmRzLCBpdOKAmXMgZmFz dA0KPmFuZCBlZmZpY2llbnQgYW5kIG5vdCBhIHNpZ25pZmljYW50IGRyYWluIG9uIHJlc291cmNl cy4NCj4NCg0KV2hlbiBtdWx0aXBsZSBmYWlsdXJlcyBoYXBwZW4sIHRoZSBjdXJyZW50IGZsb29k aW5nIHRvcG9sb2d5IGNoYW5nZXMsIHRoZSBwcm9jZWR1cmUgZm9yIGZhdWx0IHRvbGVyYW5jZSB0 byBmYWlsdXJlcyBpcyB0cmlnZ2VyZWQgdG8gcnVuLCBhbmQgYSBuZXcgZmxvb2RpbmcgdG9wb2xv Z3kgaXMgdG8gYmUgY29tcHV0ZWQuIFdlIG5lZWQgdG8gaGF2ZSBhIGNvbnZlcmdlZCBmbG9vZGlu ZyB0b3BvbG9neSBhcyBzb29uIGFzIHBvc3NpYmxlLg0KSW4gdGhlIGRpc3RyaWJ1dGVkIHNvbHV0 aW9uL21vZGUsIGlmIGEgcHJvY2VkdXJlIGZvciBmYXVsdCB0b2xlcmFuY2UsIHdoaWNoIGlzIG5v dCBhcHByb3ByaWF0ZSB0byBpdCwgaXMgdXNlZCwgdGhlbiB3ZSB3aWxsIGhhdmUgYSBjb252ZXJn ZWQgZmxvb2RpbmcgdG9wb2xvZ3kgaW4gYSBsb25nZXIgdGltZS4NCkZvciBleGFtcGxlLCBhZnRl ciBtdWx0aXBsZSBmYWlsdXJlcyBvY2N1ciwgb25lIHByb2NlZHVyZSAoaW4gcm91Z2ggaWRlYSkg Zm9yIGZhdWx0IHRvbGVyYW5jZSBpbmNsdWRlczogMSkgZGV0ZXJtaW5lIHdoZXRoZXIgdGhlIGN1 cnJlbnQgZmxvb2RpbmcgdG9wb2xvZ3kgc3BsaXRzLCAyKSBjb21wdXRlIGJhY2t1cCBwYXRocyB0 byBjb25uZWN0IHRoZSBzcGxpdCBmbG9vZGluZyB0b3BvbG9neSwgMykgZW5hYmxlL3JlcXVlc3Qg dGhlIHRlbXBvcmFyeSBmbG9vZGluZyBvbiB0aGUgYmFja3VwIHBhdGhzIHRocm91Z2ggZXh0ZW5z aW9ucyB0byBIZWxsbyBwcm90b2NvbC4gV2UgY2FuIHNlZSB0aGF0IHRoaXMgcHJvY2VkdXJlIGZv ciBmYXVsdCB0b2xlcmFuY2UgdGFrZXMgYSBsb25nZXIgdGltZSB0aGFuIHRoZSBhbGdvcml0aG0g Y29tcHV0ZXMgYSBuZXcgZmxvb2RpbmcgdG9wb2xvZ3kuIFRoaXMgcHJvY2VkdXJlIHdpbGwgZGVs YXkgdGhlIGNvbnZlcmdlbmNlIG9mIGZsb29kaW5nIHRvcG9sb2d5LCB3aGljaCBpcyBub3QgYXBw cm9wcmlhdGUgdG8gdGhlIGRpc3RyaWJ1dGVkIHNvbHV0aW9uL21vZGUuDQpTbyBpdCBpcyBiZXR0 ZXIgZm9yIHRoZSBkaXN0cmlidXRlZCBzb2x1dGlvbi9tb2RlIHRvIHVzZSBhIHByb2NlZHVyZSBm b3IgZmF1bHQgdG9sZXJhbmNlLCB3aGljaCBpcyBtb3JlIGFwcHJvcHJpYXRlIHRvIGl0Lg0KDQo+ PkluIHRoZSBjZW50cmFsaXplZCBzb2x1dGlvbi9tb2RlLCBzY2hlZHVsaW5nIGFuIGFsZ29yaXRo bSB0byBjb21wdXRlIGZsb29kaW5nIHRvcG9sb2d5IGhhcHBlbnMNCj4+b25seSBvbiB0aGUgbGVh ZGVyLCBhbmQgdGhlbiBvbiB0aGUgYmFja3VwIGxlYWRlciBhZnRlciB0aGUgbGVhZGVyIGZhaWxz LiBUaGUgcGFyYW1ldGVycyBmb3INCj4+c2NoZWR1bGluZyBvbiB0aGUgbGVhZGVyIG1heSBiZSBk aWZmZXJlbnQgZnJvbSB0aG9zZSBmb3Igc2NoZWR1bGluZyBvbiB0aGUgYmFja3VwIGxlYWRlci4N Cj4+SG93ZXZlciwgaW4gdGhlIGRpc3RyaWJ1dGVkIHNvbHV0aW9uL21vZGUsIHNjaGVkdWxpbmcg YW4gYWxnb3JpdGhtIHRvIGNvbXB1dGUgZmxvb2RpbmcgdG9wb2xvZ3kNCj4+b2NjdXJzIG9uIGV2 ZXJ5IG5vZGUuIFRoZSBwYXJhbWV0ZXJzIGZvciBzY2hlZHVsaW5nIG9uIGFsbCB0aGUgbm9kZXMg bmVlZCB0byBiZSB0aGUgc2FtZS4NCj4NCj4NCj5BY3R1YWxseSwgdGhhdOKAmXMgbm90IHRydWUu ICBBbiBpbXBsZW1lbnRhdGlvbiBpcyBmcmVlIHRvIGRvIGl0cyBvd24gaW50ZXJuYWwgc2NoZWR1 bGluZw0KPmhvd2V2ZXIgaXQgY2hvb3NlcywgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIGl0IGltcGxl bWVudHMgYQ0KPmRpc3RyaWJ1dGVkIG9yIGNlbnRyYWxpemVkIGltcGxlbWVudGF0aW9uLg0KPg0K Pg0KPj5UaGUgcHJvY2VkdXJlIGZvciBhY2hpZXZpbmcgdGhpcyBpcyBzcGVjaWZpYyB0byB0aGUg ZGlzdHJpYnV0ZWQgbW9kZS9zb2x1dGlvbi4NCj4NCj5Nb3JlIGFjY3VyYXRlbHksIGl0IGlzIHNw ZWNpZmljIHRvIGEgZ2l2ZW4gaW1wbGVtZW50YXRpb24uDQo+DQo+DQo+PklmIGV2ZXJ5IHBhcnRp Y3VsYXIgYWxnb3JpdGhtIGZvciBjb21wdXRpbmcgZmxvb2RpbmcgdG9wb2xvZ3kgaW4gdGhlIGRp c3RyaWJ1dGVkIHNvbHV0aW9uL21vZGUNCj4+ZGVzY3JpYmVzIGEgcHJvY2VkdXJlIGZvciBzY2hl ZHVsaW5nIGluIGRldGFpbHMgaXRzZWxmLCB0aGVyZSB3aWxsIGJlIGR1cGxpY2F0ZWQgZGVzY3Jp cHRpb25zIG9mDQo+PnRoZSBzYW1lIHByb2NlZHVyZSBpbiBtdWx0aXBsZSBhbGdvcml0aG1zLCBv bmUgb2Ygd2hpY2ggaXMgc2VsZWN0ZWQgdG8gY29tcHV0ZSBmbG9vZGluZw0KPj50b3BvbG9neSBv biBldmVyeSBub2RlLiBJdCBpcyBiZXR0ZXIgZm9yIHRoZSBzYW1lIHNjaGVkdWxpbmcgcHJvY2Vk dXJlIGZvciBtdWx0aXBsZSBhbGdvcml0aG1zDQo+PnRvIGJlIGRlc2NyaWJlZCBpbiBvbmUgZG9j dW1lbnQuDQo+DQo+DQo+QWN0dWFsbHksIHNpbmNlIHRoZSBJRVRGIHNob3VsZCBub3QgYmUgc3Bl Y2lmeWluZyB0aGUgZGV0YWlscyBvZiBzY2hlZHVsaW5nIGFzIGl0IGlzIGFuDQo+aW1wbGVtZW50 YXRpb24gZGV0YWlsLCBhcyB0aGV5IGRvIG5vdCBhZmZlY3QgdGhlIGJlaGF2aW9yIG9mIHRoZSBw cm90b2NvbCwgaXQgc2hvdWxkIG5vdCBiZQ0KPmRpc2N1c3NlZCBpbiBhbnkgZG9jdW1lbnRzLg0K DQpJbiBtdWx0aXBsZSB2ZW5kb3IgbmV0d29ya3MsIHVzaW5nIGRpZmZlcmVudCBpbXBsZW1lbnRh dGlvbnMgd2lsbCBjcmVhdGUgbW9yZSBtaWNybyByb3V0aW5nIGxvb3BzIGR1cmluZyB0aGUgY29u dmVyZ2VuY2UgcHJvY2VzcyBkdWUgdG8gZGlzY3JlcGFuY2llcyBvZiBwYXJhbWV0ZXJzL3RpbWVy cyBmb3Igc2NoZWR1bGluZyB0aGFuIHVzaW5nIGEgc2FtZSBpbXBsZW1lbnRhdGlvbi4gTW9yZSBt aWNybyByb3V0aW5nIGxvb3BzIHdpbGwgbGVhZCB0byBtb3JlIHRyYWZmaWMgbG9zZS4gU2Vydmlj ZSBwcm92aWRlcnMgYXJlIGFscmVhZHkgYXdhcmUgdG8gdXNlIHNpbWlsYXIgdGltZXJzICh2YWx1 ZXMgYW5kIGJlaGF2aW9yKSwgYnV0IHNvbWV0aW1lcyBpdCBpcyBub3QgcG9zc2libGUgZHVlIHRv IGxpbWl0YXRpb25zIG9mIGltcGxlbWVudGF0aW9ucy4NCkhlcmUgd2UgY29tZSB0byBhIHBvaW50 IHdoZXRoZXIgd2UgbmVlZCB0byBoYXZlIGEgc2FtZSBzY2hlZHVsaW5nIHByb2NlZHVyZSBmb3Ig YSBmbG9vZGluZyB0b3BvbG9neSBjb21wdXRhdGlvbiBhbGdvcml0aG0gdG8gYmUgaW1wbGVtZW50 ZWQgYnkgbXVsdGlwbGUgdmVuZG9ycy4gSWYgd2UgZG8gbm90IGhhdmUgYSBzYW1lIHNjaGVkdWxp bmcgcHJvY2VkdXJlLCB0aGVuIHNlcnZpY2UgcHJvdmlkZXJzIHdpbGwgaGF2ZSBkaWZmZXJlbnQg c2NoZWR1bGluZyBpbXBsZW1lbnRhdGlvbnMvcHJvY2VkdXJlcyBmcm9tIGRpZmZlcmVudCB2ZW5k b3JzLCB3aGljaCB3aWxsIGNyZWF0ZSBtb3JlIG1pY3JvIHJvdXRpbmcgbG9vcHMsIGxlYWRpbmcg dG8gbW9yZSB0cmFmZmljIGxvc2UuIElmIHdlIGhhdmUgYSBzYW1lIHNjaGVkdWxpbmcgcHJvY2Vk dXJlLCB0aGVuIHNlcnZpY2UgcHJvdmlkZXJzIHdpbGwgaGF2ZSB0aGUgc2FtZSBzY2hlZHVsaW5n IHByb2NlZHVyZSBmcm9tIGRpZmZlcmVudCB2ZW5kb3JzLCB3aGljaCB3aWxsIGNyZWF0ZSBsZXNz IG1pY3JvIHJvdXRpbmcgbG9vcHMuIFRodXMgd2Ugd2lsbCBoYXZlIGxlc3MgdHJhZmZpYyBsb3Nl Lg0KV2UgY2FuIHNlZSB0aGF0IHRoZXJlIGlzIGEgbmVlZCB0byBoYXZlIGEgc2FtZSBzY2hlZHVs aW5nIHByb2NlZHVyZS4NCg0KDQpCZXN0IFJlZ2FyZHMsDQpIdWFpbW8NCg0KPlJlZ2FyZHMsDQo+ VG9ueQ0KDQo= --_000_5316A0AB3C851246A7CA5758973207D463B669E8sjceml521mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIg MSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0K CXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1p bHk6IlxARGVuZ1hpYW4iOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNw YW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0Mx Ow0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVy bGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWww LCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdp bi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFj ZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXtt c28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdv cmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4w aW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48 L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9 ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8 L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIi Pg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjpibGFjayI+SGkgVG9ueSw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7RnJvbTo8L3Nw YW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IFRvbnkgTGkgW21haWx0bzp0b255MWF0aG9tZUBnbWFp bC5jb21dDQo8YnI+DQo8Yj4mZ3Q7U2VudDo8L2I+IFRodXJzZGF5LCBGZWJydWFyeSAyMSwgMjAx OSAxMjozMiBBTTxicj4NCjxiPiZndDtUbzo8L2I+IEh1YWltbyBDaGVuICZsdDtodWFpbW8uY2hl bkBodWF3ZWkuY29tJmd0Ozxicj4NCjxiPiZndDtDYzo8L2I+IFBldGVyIFBzZW5hayAmbHQ7cHBz ZW5ha0BjaXNjby5jb20mZ3Q7OyBBY2VlIExpbmRlbSAoYWNlZSkgJmx0O2FjZWVAY2lzY28uY29t Jmd0OzsgQ2hyaXN0aWFuIEhvcHBzDQo8Yj4mZ3Q7PC9iPiZsdDtjaG9wcHNAY2hvcHBzLm9yZyZn dDs7IGxzckBpZXRmLm9yZzxicj4NCjxiPiZndDtTdWJqZWN0OjwvYj4gUmU6IFtMc3JdIE1vdmlu ZyBGb3J3YXJkIFtSZTogRmxvb2RpbmcgUmVkdWN0aW9uIERyYWZ0IFJlZHV4XTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0 Ozwvc3Bhbj48L2I+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs8L3NwYW4+PC9iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7PC9zcGFuPjwvYj5I aSBIdWFpbW8sPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiZndDs8L3NwYW4+PC9iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0Ozwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7 LHNhbnMtc2VyaWYiPlRoZSB3YXkgaW4gd2hpY2ggdGhlIGZsb29kaW5nIHRvcG9sb2d5IGNvbnZl cmdlcyBpbiB0aGUgY2VudHJhbGl6ZWQgbW9kZS9zb2x1dGlvbiBpcyBkaWZmZXJlbnQ8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PiZndDsmZ3Q7PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ZnJvbTwvc3Bhbj48c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9z cGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+dGhhdA0KIGluIHRoZSBkaXN0cmlidXRlZCBt b2RlL3NvbHV0aW9uLiBJbiB0aGUgZm9ybWVyLCBhZnRlciByZWNlaXZpbmcgdGhlIGxpbmsgc3Rh dGVzIGZvciB0aGUgZmFpbHVyZXMsPGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0 OyZndDs8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj50aGUgbGVhZGVyIGNvbXB1dGVzIGEg bmV3IGZsb29kaW5nIHRvcG9sb2d5IGFuZCBmbG9vZHMgaXQgdG8gZXZlcnkgb3RoZXIgbm9kZSwg d2hpY2ggcmVjZWl2ZXM8YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0Ozwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPmFuZCBpbnN0YWxscyB0aGUgbmV3IGZsb29kaW5n IHRvcG9sb2d5LiBUaGUgd29ya2luZyBsb2FkIG9uIGV2ZXJ5IG5vbiBsZWFkZXIgbm9kZSBpcyBs aWdodC4gSXQgaGFzIG1vcmU8L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0 aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWYiPjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+cHJvY2Vzc2luZyBwb3dlciBmb3IgYSBwcm9jZWR1cmUvbWV0aG9k IGZvciBmYXVsdCB0b2xlcmFuY2UgdG8gZmFpbHVyZXMuPGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+Jmd0OyZndDs8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5Ib3dldmVyLCBp biB0aGUgbGF0dGVyLCBldmVyeSBub2RlIGNvbXB1dGVzIGFuZCBpbnN0YWxscyBhIG5ldyBmbG9v ZGluZyB0b3BvbG9neSBhZnRlciByZWNlaXZpbmc8L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNv bnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1 b3Q7LHNhbnMtc2VyaWYiPjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+dGhlIGxpbmsgc3RhdGVzIGZvciB0aGUgZmFp bHVyZXMuIEl0IGhhcyBsZXNzIHByb2Nlc3NpbmcgcG93ZXIgZm9yIGEgcHJvY2VkdXJlL21ldGhv ZCBmb3IgZmF1bHQgdG9sZXJhbmNlLjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZn dDsmZ3Q7PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SXQgaXMgYmV0dGVyIHRvIGxldCBl YWNoIG9mIHRoZSB0d28gbW9kZXMgdXNlIGl0cyBvd24gcHJvY2VkdXJlL21ldGhvZCBmb3IgZmF1 bHQgdG9sZXJhbmNlIHRvIGZhaWx1cmVzLDxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYi PiZndDsmZ3Q7PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZh bWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+d2hpY2ggaXMgbW9yZSBhcHBy b3ByaWF0ZSB0byBpdC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs8L3NwYW4+PC9iPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7PC9zcGFuPjwv Yj5JdOKAmXMgdHJ1ZSB0aGF0IGEgZGlzdHJpYnV0ZWQgc29sdXRpb24gd2lsbCBjYWxsIG1vcmUg b24gYW4gYXZlcmFnZSBub2RlIHRoYW4gYSBjZW50cmFsaXplZA0KPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs8L3NwYW4+PC9iPnNv bHV0aW9uIHdpbGwuIEhvd2V2ZXIsIHRoYXQgaXMgbm90IHRoZSBzdGVhZHkgc3RhdGUgZm9yIGVp dGhlci4gSW4gdGhlJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs8L3NwYW4+PC9iPnN0ZWFkeSBzdGF0ZSwgdGhlIGZsb29k aW5nIHRvcG9sb2d5IGhhcyBiZWVuIGNvbXB1dGVkIGFuZCBoYXMgYmVlbiBwdXQgaW4gcGxhY2Ug YWxyZWFkeS4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4mZ3Q7PC9zcGFuPjwvYj5UaHVzLCB0aGUgaW1wYWN0IG9mIHRoZSB0b3BvbG9n eSBjb21wdXRhdGlvbiBhdCB0aGUgdGltZSBvZiB0aGUmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0Ozwvc3Bhbj48L2I+dG9w b2xvZ3kgY2hhbmdlIGlzIG5pbC4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0Ozwvc3Bhbj48L2I+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs8L3Nw YW4+PC9iPkluIGFkZGl0aW9uLCB0aGUgYW1vdW50IG9mIHdvcmsgdG8gdGVtcG9yYXJpbHkgYW1l bmQgdGhlIGZsb29kaW5nIHRvcG9sb2d5IHNob3VsZCBhbHNvDQo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0Ozwvc3Bhbj48L2I+YmUg bWluaW1hbCwgYW5kIGJ5IHRoYXQsIEkgbWVhbiBPKGxvZyBuKS4gJm5ic3A7VGhlIGRlY2lzaW9u IHNob3VsZCBvbmx5PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiZndDs8L3NwYW4+PC9iPmJlIHdoZXRoZXIgb3Igbm90IHRvIHRlbXBvcmFy aWx5IGFkZCBhIGxpbmsgdG8gZmxvb2RpbmcsIGFuZCB0aGUgb25seSBpbmZvcm1hdGlvbiB0aGF0 IGEgbm9kZQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiZndDs8L3NwYW4+PC9iPm5lZWRzIHRvIGRvIHRoYXQgaXMgdG8gZGV0ZXJtaW5l IGlmIHRoZSBub2RlIGlzIGFscmVhZHkgb24gdGhlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs8L3NwYW4+PC9iPmZsb29kaW5nIHRv cG9sb2d5LiBUaGF0IHNob3VsZCBiZSBhIGxvb2t1cCBpbiBhIHRyZWUgdGhhdCByZXByZXNlbnRz IHRoZSBub2RlcyBvbiB0aGUgdG9wb2xvZ3ksDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0Ozwvc3Bhbj48L2I+YW5kIHRoYXQgbG9v a3VwIHNob3VsZCBiZSBPKGxvZyBuKS4gSW4gb3RoZXIgd29yZHMsIGl04oCZcyBmYXN0PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs8 L3NwYW4+PC9iPmFuZCBlZmZpY2llbnQgYW5kIG5vdCBhIHNpZ25pZmljYW50IGRyYWluIG9uIHJl c291cmNlcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+Jmd0OzxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+V2hlbiBtdWx0aXBsZSBmYWlsdXJlcyBoYXBwZW4sIHRoZSBjdXJyZW50 IGZsb29kaW5nIHRvcG9sb2d5IGNoYW5nZXMsIHRoZSBwcm9jZWR1cmUgZm9yIGZhdWx0IHRvbGVy YW5jZSB0byBmYWlsdXJlcyBpcyB0cmlnZ2VyZWQgdG8gcnVuLCBhbmQgYSBuZXcgZmxvb2Rpbmcg dG9wb2xvZ3kgaXMgdG8gYmUNCiBjb21wdXRlZC4gV2UgbmVlZCB0byBoYXZlIGEgY29udmVyZ2Vk IGZsb29kaW5nIHRvcG9sb2d5IGFzIHNvb24gYXMgcG9zc2libGUuJm5ic3A7IDxvOnA+DQo8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5JbiB0 aGUgZGlzdHJpYnV0ZWQgc29sdXRpb24vbW9kZSwgaWYgYSBwcm9jZWR1cmUgZm9yIGZhdWx0IHRv bGVyYW5jZSwgd2hpY2ggaXMgbm90IGFwcHJvcHJpYXRlIHRvIGl0LCBpcyB1c2VkLCB0aGVuIHdl IHdpbGwgaGF2ZSBhIGNvbnZlcmdlZCBmbG9vZGluZyB0b3BvbG9neSBpbiBhIGxvbmdlciB0aW1l Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj5Gb3IgZXhhbXBsZSwgYWZ0ZXIgbXVsdGlwbGUgZmFpbHVyZXMgb2NjdXIsIG9uZSBw cm9jZWR1cmUgKGluIHJvdWdoIGlkZWEpIGZvciBmYXVsdCB0b2xlcmFuY2UgaW5jbHVkZXM6IDEp IGRldGVybWluZSB3aGV0aGVyIHRoZSBjdXJyZW50IGZsb29kaW5nIHRvcG9sb2d5IHNwbGl0cywg MikgY29tcHV0ZQ0KIGJhY2t1cCBwYXRocyB0byBjb25uZWN0IHRoZSBzcGxpdCBmbG9vZGluZyB0 b3BvbG9neSwgMykgZW5hYmxlL3JlcXVlc3QgdGhlIHRlbXBvcmFyeSBmbG9vZGluZyBvbiB0aGUg YmFja3VwIHBhdGhzIHRocm91Z2ggZXh0ZW5zaW9ucyB0byBIZWxsbyBwcm90b2NvbC4gV2UgY2Fu IHNlZSB0aGF0IHRoaXMgcHJvY2VkdXJlIGZvciBmYXVsdCB0b2xlcmFuY2UgdGFrZXMgYSBsb25n ZXIgdGltZSB0aGFuIHRoZSBhbGdvcml0aG0gY29tcHV0ZXMgYSBuZXcNCiBmbG9vZGluZyB0b3Bv bG9neS4gVGhpcyBwcm9jZWR1cmUgd2lsbCBkZWxheSB0aGUgY29udmVyZ2VuY2Ugb2YgZmxvb2Rp bmcgdG9wb2xvZ3ksIHdoaWNoIGlzIG5vdCBhcHByb3ByaWF0ZSB0byB0aGUgZGlzdHJpYnV0ZWQg c29sdXRpb24vbW9kZS48Yj4NCjxvOnA+PC9vOnA+PC9iPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPlNvIGl0IGlzIGJldHRlciBmb3IgdGhlIGRpc3Ry aWJ1dGVkIHNvbHV0aW9uL21vZGUgdG8gdXNlIGEgcHJvY2VkdXJlIGZvciBmYXVsdCB0b2xlcmFu Y2UsIHdoaWNoIGlzIG1vcmUgYXBwcm9wcmlhdGUgdG8gaXQuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDss c2Fucy1zZXJpZiI+SW4gdGhlIGNlbnRyYWxpemVkIHNvbHV0aW9uL21vZGUsIHNjaGVkdWxpbmcg YW4gYWxnb3JpdGhtIHRvIGNvbXB1dGUgZmxvb2RpbmcgdG9wb2xvZ3kgaGFwcGVuczwvc3Bhbj48 c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5i c3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KPC9zcGFuPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+Jmd0OyZndDs8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAu NXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5vbmx5IG9u IHRoZSBsZWFkZXIsIGFuZCB0aGVuIG9uIHRoZSBiYWNrdXAgbGVhZGVyIGFmdGVyIHRoZSBsZWFk ZXIgZmFpbHMuIFRoZSBwYXJhbWV0ZXJzIGZvcjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVv dDssc2Fucy1zZXJpZiI+PGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZndDs8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5zY2hlZHVsaW5nIG9uIHRoZSBsZWFkZXIgbWF5 IGJlIGRpZmZlcmVudCBmcm9tIHRob3NlIGZvciBzY2hlZHVsaW5nIG9uIHRoZSBiYWNrdXAgbGVh ZGVyLjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PGJyPg0KPC9z cGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZndDs8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj5Ib3dldmVyLCBpbiB0aGUgZGlzdHJpYnV0ZWQgc29sdXRpb24vbW9kZSwgc2NoZWR1bGlu ZyBhbiBhbGdvcml0aG0gdG8gY29tcHV0ZSBmbG9vZGluZyB0b3BvbG9neTxicj4NCjwvc3Bhbj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ b2NjdXJzIG9uIGV2ZXJ5IG5vZGUuIFRoZSBwYXJhbWV0ZXJzIGZvciBzY2hlZHVsaW5nIG9uIGFs bCB0aGUgbm9kZXMgbmVlZCB0byBiZSB0aGUgc2FtZS48L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxl LWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48L3NwYW4+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNh JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0Ozwvc3Bhbj48L2I+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs8L3Nw YW4+PC9iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4mZ3Q7PC9zcGFuPjwvYj5BY3R1YWxseSwgdGhhdOKAmXMgbm90IHRydWUu ICZuYnNwO0FuIGltcGxlbWVudGF0aW9uIGlzIGZyZWUgdG8gZG8gaXRzIG93biBpbnRlcm5hbCBz Y2hlZHVsaW5nDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+Jmd0Ozwvc3Bhbj48L2I+aG93ZXZlciBpdCBjaG9vc2VzLCByZWdhcmRsZXNz IG9mIHdoZXRoZXIgaXQgaW1wbGVtZW50cyBhPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs8L3NwYW4+PC9iPmRpc3RyaWJ1dGVkIG9y IGNlbnRyYWxpemVkIGltcGxlbWVudGF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7PC9zcGFuPjwvYj48YnI+DQo8Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0Ozwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPlRoZSBwcm9jZWR1cmUgZm9yIGFjaGlldmluZyB0aGlzIGlzIHNwZWNpZmljIHRv IHRoZSBkaXN0cmlidXRlZCBtb2RlL3NvbHV0aW9uLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0Ozwvc3Bhbj48L2I+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiZndDs8L3NwYW4+PC9iPk1vcmUgYWNjdXJhdGVseSwgaXQgaXMgc3BlY2lmaWMgdG8gYSBn aXZlbiBpbXBsZW1lbnRhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0Ozwvc3Bhbj48L2I+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs8L3NwYW4+PC9i PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4mZ3Q7Jmd0Ozwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPklmIGV2ZXJ5IHBh cnRpY3VsYXIgYWxnb3JpdGhtIGZvciBjb21wdXRpbmcgZmxvb2RpbmcgdG9wb2xvZ3kgaW4gdGhl IGRpc3RyaWJ1dGVkIHNvbHV0aW9uL21vZGU8YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4mZ3Q7Jmd0Ozwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPmRlc2NyaWJlcyBhIHByb2Nl ZHVyZSBmb3Igc2NoZWR1bGluZyBpbiBkZXRhaWxzIGl0c2VsZiwgdGhlcmUgd2lsbCBiZSBkdXBs aWNhdGVkIGRlc2NyaXB0aW9ucyBvZjwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+PGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZndDs8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj50aGUgc2FtZSBwcm9jZWR1cmUgaW4gbXVsdGlwbGUgYWxn b3JpdGhtcywgb25lIG9mIHdoaWNoIGlzIHNlbGVjdGVkIHRvIGNvbXB1dGUgZmxvb2Rpbmc8YnI+ DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0Ozwvc3Bhbj48L2I+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPnRvcG9sb2d5IG9uIGV2ZXJ5IG5vZGUuIEl0IGlzIGJldHRlciBmb3IgdGhlIHNh bWUgc2NoZWR1bGluZyBwcm9jZWR1cmUgZm9yIG11bHRpcGxlIGFsZ29yaXRobXM8L3NwYW4+PHNw YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNw Ozwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxicj4NCjwvc3Bhbj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiZndDsmZ3Q7PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+dG8gYmUgZGVz Y3JpYmVkIGluIG9uZSBkb2N1bWVudC4gJm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiZndDs8L3NwYW4+PC9iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7PC9zcGFuPjwvYj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0Ozwv c3Bhbj48L2I+QWN0dWFsbHksIHNpbmNlIHRoZSBJRVRGIHNob3VsZCBub3QgYmUgc3BlY2lmeWlu ZyB0aGUgZGV0YWlscyBvZiBzY2hlZHVsaW5nIGFzIGl0IGlzIGFuDQo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0Ozwvc3Bhbj48L2I+ aW1wbGVtZW50YXRpb24gZGV0YWlsLCBhcyB0aGV5IGRvIG5vdCBhZmZlY3QgdGhlIGJlaGF2aW9y IG9mIHRoZSBwcm90b2NvbCwgaXQgc2hvdWxkIG5vdCBiZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7PC9zcGFuPjwvYj5kaXNjdXNz ZWQgaW4gYW55IGRvY3VtZW50cy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SW4gbXVsdGlwbGUg dmVuZG9yIG5ldHdvcmtzLCB1c2luZyBkaWZmZXJlbnQgaW1wbGVtZW50YXRpb25zIHdpbGwgY3Jl YXRlIG1vcmUgbWljcm8gcm91dGluZyBsb29wcyBkdXJpbmcgdGhlIGNvbnZlcmdlbmNlIHByb2Nl c3MgZHVlIHRvIGRpc2NyZXBhbmNpZXMgb2YgcGFyYW1ldGVycy90aW1lcnMgZm9yIHNjaGVkdWxp bmcgdGhhbiB1c2luZyBhIHNhbWUgaW1wbGVtZW50YXRpb24uIE1vcmUgbWljcm8gcm91dGluZw0K IGxvb3BzIHdpbGwgbGVhZCB0byBtb3JlIHRyYWZmaWMgbG9zZS4gU2VydmljZSBwcm92aWRlcnMg YXJlIGFscmVhZHkgYXdhcmUgdG8gdXNlIHNpbWlsYXIgdGltZXJzICh2YWx1ZXMgYW5kIGJlaGF2 aW9yKSwgYnV0IHNvbWV0aW1lcyBpdCBpcyBub3QgcG9zc2libGUgZHVlIHRvIGxpbWl0YXRpb25z IG9mIGltcGxlbWVudGF0aW9ucy4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+SGVyZSB3ZSBjb21lIHRvIGEgcG9pbnQgd2hldGhlciB3ZSBuZWVkIHRvIGhhdmUgYSBzYW1l IHNjaGVkdWxpbmcgcHJvY2VkdXJlIGZvciBhIGZsb29kaW5nIHRvcG9sb2d5IGNvbXB1dGF0aW9u IGFsZ29yaXRobSB0byBiZSBpbXBsZW1lbnRlZCBieSBtdWx0aXBsZSB2ZW5kb3JzLiBJZiB3ZSBk byBub3QgaGF2ZSBhIHNhbWUgc2NoZWR1bGluZyBwcm9jZWR1cmUsIHRoZW4gc2VydmljZSBwcm92 aWRlcnMgd2lsbA0KIGhhdmUgZGlmZmVyZW50IHNjaGVkdWxpbmcgaW1wbGVtZW50YXRpb25zL3By b2NlZHVyZXMgZnJvbSBkaWZmZXJlbnQgdmVuZG9ycywgd2hpY2ggd2lsbCBjcmVhdGUgbW9yZSBt aWNybyByb3V0aW5nIGxvb3BzLCBsZWFkaW5nIHRvIG1vcmUgdHJhZmZpYyBsb3NlLiBJZiB3ZSBo YXZlIGEgc2FtZSBzY2hlZHVsaW5nIHByb2NlZHVyZSwgdGhlbiBzZXJ2aWNlIHByb3ZpZGVycyB3 aWxsIGhhdmUgdGhlIHNhbWUgc2NoZWR1bGluZyBwcm9jZWR1cmUgZnJvbQ0KIGRpZmZlcmVudCB2 ZW5kb3JzLCB3aGljaCB3aWxsIGNyZWF0ZSBsZXNzIG1pY3JvIHJvdXRpbmcgbG9vcHMuIFRodXMg d2Ugd2lsbCBoYXZlIGxlc3MgdHJhZmZpYyBsb3NlLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5XZSBjYW4gc2VlIHRoYXQgdGhlcmUgaXMgYSBuZWVkIHRvIGhhdmUgYSBz YW1lIHNjaGVkdWxpbmcgcHJvY2VkdXJlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlc3QgUmVnYXJkcyw8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkh1YWltbzxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs8L3NwYW4+PC9iPlJlZ2FyZHMsPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs8L3Nw YW4+PC9iPlRvbnk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_5316A0AB3C851246A7CA5758973207D463B669E8sjceml521mbxchi_-- From nobody Mon Mar 4 21:08:06 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C07B01200D7 for ; Mon, 4 Mar 2019 21:08:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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=NdVfvBZO; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=cm88QrKH 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 keTe5AdsGw95 for ; Mon, 4 Mar 2019 21:08:00 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 581AC130F30 for ; Mon, 4 Mar 2019 21:08:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=43636; q=dns/txt; s=iport; t=1551762480; x=1552972080; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=IHvnFrseLl+LrnRRirjlnFmiDAYYV5IWh+axf9xWUE8=; b=NdVfvBZOOmw9Zr11yyucWNovEFQwttqDtyL8j+rf6fqyC79A59bZBwU/ iFSubvHFAiXF7nsWKLW4rTx5TwTnmkk7KEcLAuYpRHrrp3snoA3KKLceX V5SbXWsYyx90B6gaTocZD944+LxkOEFCti5jMYcaup/nQUnUIY51Cx0W4 M=; IronPort-PHdr: =?us-ascii?q?9a23=3AWui3nRV2Znsvyq0FjWahopLaKZ7V8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSA9yJ8OpK3uzRta2oGXcN55qMqjgjSNRNTF?= =?us-ascii?q?dE7KdehAk8GIiAAEz/IuTtank1HcJZXlJ/8FmwMFNeH4D1YFiB6nA=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAABEA35c/5xdJa1lGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBDS8kBScDaHQECyeECINHA4RQiwCCV4kujnO?= =?us-ascii?q?BJANUCwEBLIRAAheEDiI0CQ0BAQMBAQMBAwJtHAyFSgEBAQQjChMBATcBDwI?= =?us-ascii?q?BCBEEAQEhAQYDAgICHxEUCQgCBAENBQgTgwiBEUwDFQECnUgCihRxgS+CeAE?= =?us-ascii?q?BBYUDDQuCCwiBLwGEWYR8gVIXgUA/gVeBTn6CV4FmKB4VH4JUMYImigNAA4F?= =?us-ascii?q?+hAWHJIs8KjMJAo81g1aBdIVii0yKZIcJixoCBAIEBQINAQEFgUc4gVZwFYM?= =?us-ascii?q?nggqBIwEHgkOKU3KBKI0gKoIjAQE?= X-IronPort-AV: E=Sophos;i="5.58,442,1544486400"; d="scan'208,217";a="528905975" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Mar 2019 05:07:58 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x2557wMa009745 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 5 Mar 2019 05:07:58 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 4 Mar 2019 23:07:57 -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.1473.3; Tue, 5 Mar 2019 00:07:56 -0500 Received: from NAM03-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.1473.3 via Frontend Transport; Mon, 4 Mar 2019 23:07:56 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=IHvnFrseLl+LrnRRirjlnFmiDAYYV5IWh+axf9xWUE8=; b=cm88QrKHjMxvXHmjgikfANy3YlFeAmeqmWBei9QTYMAcrUu7VjAeJh04eglGs4gwKw62eggRFOo/iwb2jySLvPtG39voIaCDf4peVU8apZhyXELZwxi8ol6cUT6gqhOydBM37060wc7MzsvLefXXJctbqpGzjr6PMpkNnYHaVYw= Received: from MN2PR11MB3647.namprd11.prod.outlook.com (20.178.251.26) by MN2PR11MB3551.namprd11.prod.outlook.com (20.178.250.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.19; Tue, 5 Mar 2019 05:07:54 +0000 Received: from MN2PR11MB3647.namprd11.prod.outlook.com ([fe80::51ef:109b:a44e:1a25]) by MN2PR11MB3647.namprd11.prod.outlook.com ([fe80::51ef:109b:a44e:1a25%4]) with mapi id 15.20.1665.019; Tue, 5 Mar 2019 05:07:54 +0000 From: "Les Ginsberg (ginsberg)" To: Huaimo Chen , Tony Li CC: "lsr@ietf.org" , Christian Hopps , "Acee Lindem (acee)" Thread-Topic: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux] Thread-Index: AQHUuilUQNpyPXkEuUWPo/7QhgsxnKXMYBoAgAJPrgCAAAO5AIAD3POAgAvHngCAAKHCgIAGzxQAgAAC2QCAA8lLAIAARCUAgBLG1gCAAAdLAA== Date: Tue, 5 Mar 2019 05:07:54 +0000 Message-ID: References: <5316A0AB3C851246A7CA5758973207D463B3B9D8@sjceml521-mbx.china.huawei.com> <8378287F-27B9-4663-A22B-F8A2EC6C9FC3@cisco.com> <5316A0AB3C851246A7CA5758973207D463B46315@sjceml521-mbx.china.huawei.com> <5316A0AB3C851246A7CA5758973207D463B4A6AB@sjceml521-mbx.china.huawei.com> <25021deb-2032-9fcc-4bf4-fcaaa21598b9@cisco.com> <5316A0AB3C851246A7CA5758973207D463B56620@sjceml521-mbx.china.huawei.com> <59b45885-3e06-e3d0-5c09-2cbee4cef341@cisco.com> <5316A0AB3C851246A7CA5758973207D463B57ED6@sjceml521-mbx.china.huawei.com> <5316A0AB3C851246A7CA5758973207D463B669E8@sjceml521-mbx.china.huawei.com> In-Reply-To: <5316A0AB3C851246A7CA5758973207D463B669E8@sjceml521-mbx.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ginsberg@cisco.com; x-originating-ip: [2001:420:c0c8:1007::2c6] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 481e8c0f-eaad-49e9-c989-08d6a1288656 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:MN2PR11MB3551; x-ms-traffictypediagnostic: MN2PR11MB3551: x-microsoft-exchange-diagnostics: =?utf-8?B?MTtNTjJQUjExTUIzNTUxOzIzOldwNVVTN1h3d0lSQWlmdDVXWkVVd2xMZi9V?= =?utf-8?B?L2JKbjVTMmpUWlNldVJsSklweTVzZVEwVVpHdDJRY1YrM2VXNEZqRDVCYkdN?= =?utf-8?B?UTNFQVY1UHJ1WEhFVEJKbDljeVFGd21QTkwybmdvTmJMMUFFMHZ3am9QQ0FK?= =?utf-8?B?ckJMOStHTFRrRTFTYUtvaER1NmZtRkxiRk9UZUljTDJyWjB4MDRybUd2L1l2?= =?utf-8?B?ZVZyaVBnSjFiaDI4eFcyUGUyR3A5RzIyWm5jT0NySXU3MElBZElvSzA0eHVp?= =?utf-8?B?dC91R3FmTEdMeDZnbmU0cm5RNHBYMnJJWW1qM3JJZFZFQVBtZUIwZ2pvdFcw?= =?utf-8?B?L3djaGVwRzdFZWlmUngrRWdtM0Qwa1E2bnIrRWp3TEJOWTBCa2QrTW1QM0o2?= =?utf-8?B?R0ZzbHpLMnVUUEdzZ25ueFprYUtucVpHcmxpTDVKdEFGWWYxbEthTUlPQTJT?= =?utf-8?B?MitjT1pRUTJyTlhoR0d6THYvRm9JYzlpM1Q2VG1kN2pYYlBuSWRtMGtCa05h?= =?utf-8?B?VWZLbzRiWWF3NUM5dEtyRmswSFczMXRMZE9WWkl6MFlKbTdKTW1TcmRhWWpv?= =?utf-8?B?ek1mYk9tTHJQNVdQOXlsemJNNW1hWWt2N0tHSnlvNXBlRFBabVB6bEdjZmF1?= =?utf-8?B?bUJxVWg2MGZ0MzVhRThWOVhSS1NVbTRKWHZFM0VkMnNZL0xzQzQ2c1BJN3ox?= =?utf-8?B?eU1oOXMrbjVBZlVZU0lCNENmeVlCN0pkVEwwYjVuZWRnNUZGeDdvMGUvYm5C?= =?utf-8?B?cFBqVGRuV2o5RFBXc2o3dU5XaGhRRnlmTHJKQWg5U3ZzZ29jTGsrMXhZejZy?= =?utf-8?B?TGxjWTFpajMyb2ljK2RRQkplZ2M2T2ZRS2hKSktFSGxZbHZmM2JPakFnb2pX?= =?utf-8?B?UWxOc1BYeHBnZ01PbTVkWWR1TlpvZTFpZjlPVm1xMDdaZ05VRWtXUGU5elhT?= =?utf-8?B?Ym10L2tjMm41WGhOa2ZGMWRvV3lCZXBuMHAvSXZGZUZkL1F4OW05N0JzdS9i?= =?utf-8?B?YVJ0T1FYSXJzZHY0N1plVTBTOHdHakQrSUk2Mnk3Vk1YM3JyejNzTEpzcHJZ?= =?utf-8?B?OHVTUFZVKzBsR21ROWFKVTh6aFNvdU9HSUJ6ZFhaWTRvL0hOZjNsZkE3WFRs?= =?utf-8?B?YWY1ZURvV3pQL3lWY1FUU0dIeERCUEVkNHJnMGwvaHFGUk5LNmU0SThzUWdH?= =?utf-8?B?bHNZV081dGlIZFV3ODNIcGU3Vmh6WFd5T3ArSVVMbHNYaS9zTFE4NmVsNGhv?= =?utf-8?B?YWVhWWFoY25FMSsvQVRHRlV6Z3lOLzJJa09RRHYyam0wTjlKNnJjQnFidHk4?= =?utf-8?B?K0VRV3c4UWtqSkFPMWk3RElqaFdOdUtsR3Vlc1dJQ1RlcVFtYTNJTVBFRU9o?= =?utf-8?B?QWoxVmhIaGFvR3RrM2JlTVFXWVZLY2Vzb2wxeVBPMll1cVFSMEI1YXpvcTJW?= =?utf-8?B?TDZYWENqdUU1MEoxQjA0MnR1WGQ0YjB2V2NzS21hd0hXWDJpK1NJVG5oYnI3?= =?utf-8?B?RGlYcEttaTVDb1A4TnRGKzN5V0FiTlZKVHBkUUFNMFZxbXBxRHRRYUFLVjMy?= =?utf-8?B?R3BmdjZpYVBrTEZVQ0lhZWZLZ2MzOGV0QW5mME9zdU53OTFtZUNtTDJvSkxJ?= =?utf-8?B?R3FnZFFlRzhUSHBwaUtaWFBxQ2Fib0ZaNXhCQmpoeVI2OXJlQjZCWGI5VWVp?= =?utf-8?B?emcwYmorY2ZzWi95T3Z0aUZ0K1FjSVZFemxBL0lWNDlSb1JxVG5vVE1DbS9E?= =?utf-8?B?cUpWZXhQcHIwRE5WMGwwdlk1eUloVGxwS05vZTN1dDQ0SmprT2FsODNMQkl3?= =?utf-8?Q?SBte3+FVHfHy0?= x-microsoft-antispam-prvs: x-forefront-prvs: 0967749BC1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(136003)(39860400002)(346002)(376002)(396003)(51444003)(189003)(199004)(8936002)(186003)(8676002)(81156014)(81166006)(446003)(11346002)(93886005)(102836004)(53546011)(486006)(97736004)(9686003)(236005)(55016002)(54896002)(6306002)(53936002)(105586002)(7736002)(106356001)(74316002)(790700001)(6116002)(68736007)(107886003)(478600001)(71200400001)(14454004)(71190400001)(6246003)(476003)(25786009)(76176011)(110136005)(5660300002)(54906003)(46003)(86362001)(256004)(14444005)(7696005)(6506007)(229853002)(2906002)(33656002)(4326008)(52536013)(316002)(99286004)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3551; H:MN2PR11MB3647.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 58GnSkvpzG23h3oCpPxp1DmTKxGtKn2pDrP2zGI71NAN0KuumILTdMag2T8GwTrwgBNRwpa9IDwMrb969OsKwViSJi5NiqQTjF2nTmEgYXM44RzbnzrvQkIOXFEbgoj/4F/rfuPtGwjbya0232GhxQdOn65pLqT7pb4pVwN9pUyIk8t4Ovn4D8UJfYTkcZUiENZnAfSCyeEeWsEfZTr2Y021YMjp+3ygRHmfPrnWEXKz//C9tcRk2gwDezBo4pN0r+JvzVr91037el11A1rfnucKo3fwaUDvkpFdUuI3lvJiqoDAFfXrJHS+HIfs3bvllpS1QG3sYAjfJEIBBewLQEb6QeCgV6pl+m5n7wczDUT/s6iU4rr13tawHwLEmRNsr21Ycc+bIbiPNGRiOWgV2W5lJscWYGUulQQMZxL6kTM= Content-Type: multipart/alternative; boundary="_000_MN2PR11MB36472B0D64D7D6838E2F56ACC1720MN2PR11MB3647namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 481e8c0f-eaad-49e9-c989-08d6a1288656 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2019 05:07:54.2891 (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-Transport-CrossTenantHeadersStamped: MN2PR11MB3551 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.18, xch-aln-008.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux] X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 05:08:04 -0000 --_000_MN2PR11MB36472B0D64D7D6838E2F56ACC1720MN2PR11MB3647namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SHVhaW1vIOKAkw0KDQpTb21lIHJlc3BvbnNlcyBpbmxpbmUuDQoNCkZyb206IExzciA8bHNyLWJv dW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBIdWFpbW8gQ2hlbg0KU2VudDogTW9uZGF5LCBN YXJjaCAwNCwgMjAxOSA4OjE2IFBNDQpUbzogVG9ueSBMaSA8dG9ueTFhdGhvbWVAZ21haWwuY29t Pg0KQ2M6IGxzckBpZXRmLm9yZzsgQ2hyaXN0aWFuIEhvcHBzIDxjaG9wcHNAY2hvcHBzLm9yZz47 IEFjZWUgTGluZGVtIChhY2VlKSA8YWNlZUBjaXNjby5jb20+DQpTdWJqZWN0OiBSZTogW0xzcl0g TW92aW5nIEZvcndhcmQgW1JlOiBGbG9vZGluZyBSZWR1Y3Rpb24gRHJhZnQgUmVkdXhdDQoNCkhp IFRvbnksDQoNCj5Gcm9tOiBUb255IExpIFttYWlsdG86dG9ueTFhdGhvbWVAZ21haWwuY29tXQ0K PlNlbnQ6IFRodXJzZGF5LCBGZWJydWFyeSAyMSwgMjAxOSAxMjozMiBBTQ0KPlRvOiBIdWFpbW8g Q2hlbiA8aHVhaW1vLmNoZW5AaHVhd2VpLmNvbTxtYWlsdG86aHVhaW1vLmNoZW5AaHVhd2VpLmNv bT4+DQo+Q2M6IFBldGVyIFBzZW5hayA8cHBzZW5ha0BjaXNjby5jb208bWFpbHRvOnBwc2VuYWtA Y2lzY28uY29tPj47IEFjZWUgTGluZGVtIChhY2VlKSA8YWNlZUBjaXNjby5jb208bWFpbHRvOmFj ZWVAY2lzY28uY29tPj47IENocmlzdGlhbiBIb3BwcyA+PGNob3Bwc0BjaG9wcHMub3JnPG1haWx0 bzpjaG9wcHNAY2hvcHBzLm9yZz4+OyBsc3JAaWV0Zi5vcmc8bWFpbHRvOmxzckBpZXRmLm9yZz4N Cj5TdWJqZWN0OiBSZTogW0xzcl0gTW92aW5nIEZvcndhcmQgW1JlOiBGbG9vZGluZyBSZWR1Y3Rp b24gRHJhZnQgUmVkdXhdDQo+DQo+DQo+SGkgSHVhaW1vLA0KPg0KPj5UaGUgd2F5IGluIHdoaWNo IHRoZSBmbG9vZGluZyB0b3BvbG9neSBjb252ZXJnZXMgaW4gdGhlIGNlbnRyYWxpemVkIG1vZGUv c29sdXRpb24gaXMgZGlmZmVyZW50DQo+PmZyb20gdGhhdCBpbiB0aGUgZGlzdHJpYnV0ZWQgbW9k ZS9zb2x1dGlvbi4gSW4gdGhlIGZvcm1lciwgYWZ0ZXIgcmVjZWl2aW5nIHRoZSBsaW5rIHN0YXRl cyBmb3IgdGhlIGZhaWx1cmVzLA0KPj50aGUgbGVhZGVyIGNvbXB1dGVzIGEgbmV3IGZsb29kaW5n IHRvcG9sb2d5IGFuZCBmbG9vZHMgaXQgdG8gZXZlcnkgb3RoZXIgbm9kZSwgd2hpY2ggcmVjZWl2 ZXMNCj4+YW5kIGluc3RhbGxzIHRoZSBuZXcgZmxvb2RpbmcgdG9wb2xvZ3kuIFRoZSB3b3JraW5n IGxvYWQgb24gZXZlcnkgbm9uIGxlYWRlciBub2RlIGlzIGxpZ2h0LiBJdCBoYXMgbW9yZQ0KPj5w cm9jZXNzaW5nIHBvd2VyIGZvciBhIHByb2NlZHVyZS9tZXRob2QgZm9yIGZhdWx0IHRvbGVyYW5j ZSB0byBmYWlsdXJlcy4NCj4+SG93ZXZlciwgaW4gdGhlIGxhdHRlciwgZXZlcnkgbm9kZSBjb21w dXRlcyBhbmQgaW5zdGFsbHMgYSBuZXcgZmxvb2RpbmcgdG9wb2xvZ3kgYWZ0ZXIgcmVjZWl2aW5n DQo+PnRoZSBsaW5rIHN0YXRlcyBmb3IgdGhlIGZhaWx1cmVzLiBJdCBoYXMgbGVzcyBwcm9jZXNz aW5nIHBvd2VyIGZvciBhIHByb2NlZHVyZS9tZXRob2QgZm9yIGZhdWx0IHRvbGVyYW5jZS4NCj4+ SXQgaXMgYmV0dGVyIHRvIGxldCBlYWNoIG9mIHRoZSB0d28gbW9kZXMgdXNlIGl0cyBvd24gcHJv Y2VkdXJlL21ldGhvZCBmb3IgZmF1bHQgdG9sZXJhbmNlIHRvIGZhaWx1cmVzLA0KPj53aGljaCBp cyBtb3JlIGFwcHJvcHJpYXRlIHRvIGl0Lg0KPg0KPkl04oCZcyB0cnVlIHRoYXQgYSBkaXN0cmli dXRlZCBzb2x1dGlvbiB3aWxsIGNhbGwgbW9yZSBvbiBhbiBhdmVyYWdlIG5vZGUgdGhhbiBhIGNl bnRyYWxpemVkDQo+c29sdXRpb24gd2lsbC4gSG93ZXZlciwgdGhhdCBpcyBub3QgdGhlIHN0ZWFk eSBzdGF0ZSBmb3IgZWl0aGVyLiBJbiB0aGUNCj5zdGVhZHkgc3RhdGUsIHRoZSBmbG9vZGluZyB0 b3BvbG9neSBoYXMgYmVlbiBjb21wdXRlZCBhbmQgaGFzIGJlZW4gcHV0IGluIHBsYWNlIGFscmVh ZHkuDQo+VGh1cywgdGhlIGltcGFjdCBvZiB0aGUgdG9wb2xvZ3kgY29tcHV0YXRpb24gYXQgdGhl IHRpbWUgb2YgdGhlDQo+dG9wb2xvZ3kgY2hhbmdlIGlzIG5pbC4NCj4NCj5JbiBhZGRpdGlvbiwg dGhlIGFtb3VudCBvZiB3b3JrIHRvIHRlbXBvcmFyaWx5IGFtZW5kIHRoZSBmbG9vZGluZyB0b3Bv bG9neSBzaG91bGQgYWxzbw0KPmJlIG1pbmltYWwsIGFuZCBieSB0aGF0LCBJIG1lYW4gTyhsb2cg bikuICBUaGUgZGVjaXNpb24gc2hvdWxkIG9ubHkNCj5iZSB3aGV0aGVyIG9yIG5vdCB0byB0ZW1w b3JhcmlseSBhZGQgYSBsaW5rIHRvIGZsb29kaW5nLCBhbmQgdGhlIG9ubHkgaW5mb3JtYXRpb24g dGhhdCBhIG5vZGUNCj5uZWVkcyB0byBkbyB0aGF0IGlzIHRvIGRldGVybWluZSBpZiB0aGUgbm9k ZSBpcyBhbHJlYWR5IG9uIHRoZQ0KPmZsb29kaW5nIHRvcG9sb2d5LiBUaGF0IHNob3VsZCBiZSBh IGxvb2t1cCBpbiBhIHRyZWUgdGhhdCByZXByZXNlbnRzIHRoZSBub2RlcyBvbiB0aGUgdG9wb2xv Z3ksDQo+YW5kIHRoYXQgbG9va3VwIHNob3VsZCBiZSBPKGxvZyBuKS4gSW4gb3RoZXIgd29yZHMs IGl04oCZcyBmYXN0DQo+YW5kIGVmZmljaWVudCBhbmQgbm90IGEgc2lnbmlmaWNhbnQgZHJhaW4g b24gcmVzb3VyY2VzLg0KPg0KDQpXaGVuIG11bHRpcGxlIGZhaWx1cmVzIGhhcHBlbiwgdGhlIGN1 cnJlbnQgZmxvb2RpbmcgdG9wb2xvZ3kgY2hhbmdlcywgdGhlIHByb2NlZHVyZSBmb3IgZmF1bHQg dG9sZXJhbmNlIHRvIGZhaWx1cmVzIGlzIHRyaWdnZXJlZCB0byBydW4sIGFuZCBhIG5ldyBmbG9v ZGluZyB0b3BvbG9neSBpcyB0byBiZSBjb21wdXRlZC4gV2UgbmVlZCB0byBoYXZlIGEgY29udmVy Z2VkIGZsb29kaW5nIHRvcG9sb2d5IGFzIHNvb24gYXMgcG9zc2libGUuDQpJbiB0aGUgZGlzdHJp YnV0ZWQgc29sdXRpb24vbW9kZSwgaWYgYSBwcm9jZWR1cmUgZm9yIGZhdWx0IHRvbGVyYW5jZSwg d2hpY2ggaXMgbm90IGFwcHJvcHJpYXRlIHRvIGl0LCBpcyB1c2VkLCB0aGVuIHdlIHdpbGwgaGF2 ZSBhIGNvbnZlcmdlZCBmbG9vZGluZyB0b3BvbG9neSBpbiBhIGxvbmdlciB0aW1lLg0KRm9yIGV4 YW1wbGUsIGFmdGVyIG11bHRpcGxlIGZhaWx1cmVzIG9jY3VyLCBvbmUgcHJvY2VkdXJlIChpbiBy b3VnaCBpZGVhKSBmb3IgZmF1bHQgdG9sZXJhbmNlIGluY2x1ZGVzOiAxKSBkZXRlcm1pbmUgd2hl dGhlciB0aGUgY3VycmVudCBmbG9vZGluZyB0b3BvbG9neSBzcGxpdHMsIDIpIGNvbXB1dGUgYmFj a3VwIHBhdGhzIHRvIGNvbm5lY3QgdGhlIHNwbGl0IGZsb29kaW5nIHRvcG9sb2d5LCAzKSBlbmFi bGUvcmVxdWVzdCB0aGUgdGVtcG9yYXJ5IGZsb29kaW5nIG9uIHRoZSBiYWNrdXAgcGF0aHMgdGhy b3VnaCBleHRlbnNpb25zIHRvIEhlbGxvIHByb3RvY29sLiBXZSBjYW4gc2VlIHRoYXQgdGhpcyBw cm9jZWR1cmUgZm9yIGZhdWx0IHRvbGVyYW5jZSB0YWtlcyBhIGxvbmdlciB0aW1lIHRoYW4gdGhl IGFsZ29yaXRobSBjb21wdXRlcyBhIG5ldyBmbG9vZGluZyB0b3BvbG9neS4gVGhpcyBwcm9jZWR1 cmUgd2lsbCBkZWxheSB0aGUgY29udmVyZ2VuY2Ugb2YgZmxvb2RpbmcgdG9wb2xvZ3ksIHdoaWNo IGlzIG5vdCBhcHByb3ByaWF0ZSB0byB0aGUgZGlzdHJpYnV0ZWQgc29sdXRpb24vbW9kZS4NClNv IGl0IGlzIGJldHRlciBmb3IgdGhlIGRpc3RyaWJ1dGVkIHNvbHV0aW9uL21vZGUgdG8gdXNlIGEg cHJvY2VkdXJlIGZvciBmYXVsdCB0b2xlcmFuY2UsIHdoaWNoIGlzIG1vcmUgYXBwcm9wcmlhdGUg dG8gaXQuDQoNCltMZXM6XSBHaXZlbiB0aGF0IHlvdSBkbyBub3QgZGVmaW5lIHdoYXQgeW91IHRo aW5rIHdlIHNob3VsZCBkbyBJIGNhbm5vdCBjb21tZW50IG9uIHdoYXRldmVyIGFsdGVybmF0aXZl IHlvdSBtaWdodCBoYXZlIGluIG1pbmQuDQoNCkkgY2FuIHNheSB0aGF0IHlvdXIgZGlzY3Vzc2lv biBkb2VzIG5vdCBhY2tub3dsZWRnZSB0aGF0IEJFRk9SRSBJIGNhbiBjb21wdXRlIGEgbmV3IGZs b29kaW5nIHRvcG9sb2d5IEkgaGF2ZSB0byBtYWtlIHN1cmUgSSBrbm93IHdoYXQgdGhlIHVwZGF0 ZWQgZnVsbCBuZXR3b3JrIHRvcG9sb2d5IGlzLiBUaGlzIGlzIHdoYXQgaXMgY29tcHJvbWlzZWQg d2hlbiB0aGUgb2xkIGZsb29kaW5nIHRvcG9sb2d5IGJlY29tZXMgcGFydGl0aW9uZWQuIFNvIHRo ZSBmaXJzdCBwcmlvcml0eSBoYXMgdG8gYmUgYWNxdWlyaW5nIHRoZSB1cGRhdGVkIHRvcG9sb2d5 Lg0KDQpJdCB3b3VsZCBiZSB1c2VmdWwgaWYgeW91IHJlcGxpZWQgdG8gdGhlIHRocmVhZCB0aGF0 IFRvbnkgc3RhcnRlZCBlYXJsaWVyIHRvZGF5IHdoZXJlIGhlIGFza3MgZm9yIGlucHV0IG9uIGhv dyBiZXN0IHRvIHVzZSB0ZW1wb3JhcnkgYWRkaXRpb25zIHRvIHRoZSBmbG9vZGluZyB0b3BvbG9n eS4NCg0KT25lIGV4dHJlbWUgKG15IHdvcmRzIOKAkyBub3QgVG9ueeKAmXMpIHdvdWxkIGJlIHRv IGVuYWJsZSBmbG9vZGluZyBvbiBhbGwgbGlua3MuIFRoaXMgY2xlYXJseSByaXNrcyBpbnRyb2R1 Y2luZyBhIGRlc3RhYmlsaXppbmcgZmxvb2Rpbmcgc3Rvcm0uDQoNClRoZSBvdGhlciBleHRyZW1l IHdvdWxkIGJlIHRvIGVuYWJsZSB0ZW1wb3JhcnkgZmxvb2Rpbmcgb24gYSDigJxtaW5pbWFsIHNl dCBvZiBsaW5rc+KAnS4gVGhpcyBjbGVhcmx5IHJpc2tzIGRlbGF5aW5nIGNvbnZlcmdlbmNlLg0K DQpJZiB0aGlzIHRvcGljIGludGVyZXN0cyB5b3UsIHBsZWFzZSByZXBseSB0byBUb2554oCZcyBu ZXcgdGhyZWFkICjigJxPcGVuIGlzc3VlcyB3aXRoIER5bmFtaWMgRmxvb2RpbmfigJ0pLg0KDQo+ PkluIHRoZSBjZW50cmFsaXplZCBzb2x1dGlvbi9tb2RlLCBzY2hlZHVsaW5nIGFuIGFsZ29yaXRo bSB0byBjb21wdXRlIGZsb29kaW5nIHRvcG9sb2d5IGhhcHBlbnMNCj4+b25seSBvbiB0aGUgbGVh ZGVyLCBhbmQgdGhlbiBvbiB0aGUgYmFja3VwIGxlYWRlciBhZnRlciB0aGUgbGVhZGVyIGZhaWxz LiBUaGUgcGFyYW1ldGVycyBmb3INCj4+c2NoZWR1bGluZyBvbiB0aGUgbGVhZGVyIG1heSBiZSBk aWZmZXJlbnQgZnJvbSB0aG9zZSBmb3Igc2NoZWR1bGluZyBvbiB0aGUgYmFja3VwIGxlYWRlci4N Cj4+SG93ZXZlciwgaW4gdGhlIGRpc3RyaWJ1dGVkIHNvbHV0aW9uL21vZGUsIHNjaGVkdWxpbmcg YW4gYWxnb3JpdGhtIHRvIGNvbXB1dGUgZmxvb2RpbmcgdG9wb2xvZ3kNCj4+b2NjdXJzIG9uIGV2 ZXJ5IG5vZGUuIFRoZSBwYXJhbWV0ZXJzIGZvciBzY2hlZHVsaW5nIG9uIGFsbCB0aGUgbm9kZXMg bmVlZCB0byBiZSB0aGUgc2FtZS4NCj4NCj4NCj5BY3R1YWxseSwgdGhhdOKAmXMgbm90IHRydWUu ICBBbiBpbXBsZW1lbnRhdGlvbiBpcyBmcmVlIHRvIGRvIGl0cyBvd24gaW50ZXJuYWwgc2NoZWR1 bGluZw0KPmhvd2V2ZXIgaXQgY2hvb3NlcywgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIGl0IGltcGxl bWVudHMgYQ0KPmRpc3RyaWJ1dGVkIG9yIGNlbnRyYWxpemVkIGltcGxlbWVudGF0aW9uLg0KPg0K Pg0KPj5UaGUgcHJvY2VkdXJlIGZvciBhY2hpZXZpbmcgdGhpcyBpcyBzcGVjaWZpYyB0byB0aGUg ZGlzdHJpYnV0ZWQgbW9kZS9zb2x1dGlvbi4NCj4NCj5Nb3JlIGFjY3VyYXRlbHksIGl0IGlzIHNw ZWNpZmljIHRvIGEgZ2l2ZW4gaW1wbGVtZW50YXRpb24uDQo+DQo+DQo+PklmIGV2ZXJ5IHBhcnRp Y3VsYXIgYWxnb3JpdGhtIGZvciBjb21wdXRpbmcgZmxvb2RpbmcgdG9wb2xvZ3kgaW4gdGhlIGRp c3RyaWJ1dGVkIHNvbHV0aW9uL21vZGUNCj4+ZGVzY3JpYmVzIGEgcHJvY2VkdXJlIGZvciBzY2hl ZHVsaW5nIGluIGRldGFpbHMgaXRzZWxmLCB0aGVyZSB3aWxsIGJlIGR1cGxpY2F0ZWQgZGVzY3Jp cHRpb25zIG9mDQo+PnRoZSBzYW1lIHByb2NlZHVyZSBpbiBtdWx0aXBsZSBhbGdvcml0aG1zLCBv bmUgb2Ygd2hpY2ggaXMgc2VsZWN0ZWQgdG8gY29tcHV0ZSBmbG9vZGluZw0KPj50b3BvbG9neSBv biBldmVyeSBub2RlLiBJdCBpcyBiZXR0ZXIgZm9yIHRoZSBzYW1lIHNjaGVkdWxpbmcgcHJvY2Vk dXJlIGZvciBtdWx0aXBsZSBhbGdvcml0aG1zDQo+PnRvIGJlIGRlc2NyaWJlZCBpbiBvbmUgZG9j dW1lbnQuDQo+DQo+DQo+QWN0dWFsbHksIHNpbmNlIHRoZSBJRVRGIHNob3VsZCBub3QgYmUgc3Bl Y2lmeWluZyB0aGUgZGV0YWlscyBvZiBzY2hlZHVsaW5nIGFzIGl0IGlzIGFuDQo+aW1wbGVtZW50 YXRpb24gZGV0YWlsLCBhcyB0aGV5IGRvIG5vdCBhZmZlY3QgdGhlIGJlaGF2aW9yIG9mIHRoZSBw cm90b2NvbCwgaXQgc2hvdWxkIG5vdCBiZQ0KPmRpc2N1c3NlZCBpbiBhbnkgZG9jdW1lbnRzLg0K DQpJbiBtdWx0aXBsZSB2ZW5kb3IgbmV0d29ya3MsIHVzaW5nIGRpZmZlcmVudCBpbXBsZW1lbnRh dGlvbnMgd2lsbCBjcmVhdGUgbW9yZSBtaWNybyByb3V0aW5nIGxvb3BzIGR1cmluZyB0aGUgY29u dmVyZ2VuY2UgcHJvY2VzcyBkdWUgdG8gZGlzY3JlcGFuY2llcyBvZiBwYXJhbWV0ZXJzL3RpbWVy cyBmb3Igc2NoZWR1bGluZyB0aGFuIHVzaW5nIGEgc2FtZSBpbXBsZW1lbnRhdGlvbi4gTW9yZSBt aWNybyByb3V0aW5nIGxvb3BzIHdpbGwgbGVhZCB0byBtb3JlIHRyYWZmaWMgbG9zZS4gU2Vydmlj ZSBwcm92aWRlcnMgYXJlIGFscmVhZHkgYXdhcmUgdG8gdXNlIHNpbWlsYXIgdGltZXJzICh2YWx1 ZXMgYW5kIGJlaGF2aW9yKSwgYnV0IHNvbWV0aW1lcyBpdCBpcyBub3QgcG9zc2libGUgZHVlIHRv IGxpbWl0YXRpb25zIG9mIGltcGxlbWVudGF0aW9ucy4NCkhlcmUgd2UgY29tZSB0byBhIHBvaW50 IHdoZXRoZXIgd2UgbmVlZCB0byBoYXZlIGEgc2FtZSBzY2hlZHVsaW5nIHByb2NlZHVyZSBmb3Ig YSBmbG9vZGluZyB0b3BvbG9neSBjb21wdXRhdGlvbiBhbGdvcml0aG0gdG8gYmUgaW1wbGVtZW50 ZWQgYnkgbXVsdGlwbGUgdmVuZG9ycy4gSWYgd2UgZG8gbm90IGhhdmUgYSBzYW1lIHNjaGVkdWxp bmcgcHJvY2VkdXJlLCB0aGVuIHNlcnZpY2UgcHJvdmlkZXJzIHdpbGwgaGF2ZSBkaWZmZXJlbnQg c2NoZWR1bGluZyBpbXBsZW1lbnRhdGlvbnMvcHJvY2VkdXJlcyBmcm9tIGRpZmZlcmVudCB2ZW5k b3JzLCB3aGljaCB3aWxsIGNyZWF0ZSBtb3JlIG1pY3JvIHJvdXRpbmcgbG9vcHMsIGxlYWRpbmcg dG8gbW9yZSB0cmFmZmljIGxvc2UuIElmIHdlIGhhdmUgYSBzYW1lIHNjaGVkdWxpbmcgcHJvY2Vk dXJlLCB0aGVuIHNlcnZpY2UgcHJvdmlkZXJzIHdpbGwgaGF2ZSB0aGUgc2FtZSBzY2hlZHVsaW5n IHByb2NlZHVyZSBmcm9tIGRpZmZlcmVudCB2ZW5kb3JzLCB3aGljaCB3aWxsIGNyZWF0ZSBsZXNz IG1pY3JvIHJvdXRpbmcgbG9vcHMuIFRodXMgd2Ugd2lsbCBoYXZlIGxlc3MgdHJhZmZpYyBsb3Nl Lg0KV2UgY2FuIHNlZSB0aGF0IHRoZXJlIGlzIGEgbmVlZCB0byBoYXZlIGEgc2FtZSBzY2hlZHVs aW5nIHByb2NlZHVyZS4NCg0KW0xlczpdIElmIHlvdXIgY29uY2VybiBpcyB0aGF0IHdlIGRvIG5v dCB3YW50IG9uZSBub2RlIHRvIGFwcGx5IGEgZGVsYXkgb2YgNTAgbXMgYW5kIGFub3RoZXIgbm9k ZSB0byBhcHBseSBhIGRlbGF5IG9mIDEwIHNlY29uZHMgSSB0aGluayB3ZSBjYW4gZWFzaWx5IGFn cmVlIG9uIHRoYXQuIEJ1dCB3ZSBoYXZlIG1hbnkgeWVhcnMgb2YgZXhwZXJpZW5jZSBpbiBjb25m aWd1cmluZyBjb25zaXN0ZW50IFNQRiBkZWxheSB0aW1lcnMgYW5kIEkgdGhpbmsgdGhhdCBpcyBh cHBsaWNhYmxlIGhlcmUgYXMgd2VsbC4gSSBkb27igJl0IHRoaW5rIHRoaXMgaXMgYSBwb2ludCBv ZiBjb25jZXJuIG9yIGNvbnRyb3ZlcnN5Lg0KDQogICBMZXMNCg0KQmVzdCBSZWdhcmRzLA0KSHVh aW1vDQoNCj5SZWdhcmRzLA0KPlRvbnkNCg0K --_000_MN2PR11MB36472B0D64D7D6838E2F56ACC1720MN2PR11MB3647namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlv cml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K cC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUt bmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0 OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252 ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9 DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29D aHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjox LjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNl Y3Rpb24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRl ZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8 bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48 IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2 bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkh1YWltbyDigJM8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlNvbWUgcmVzcG9uc2VzIGlubGlu ZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBp biAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiBMc3IgJmx0O2xzci1ib3VuY2VzQGlldGYub3JnJmd0Ow0KPGI+T24gQmVo YWxmIE9mIDwvYj5IdWFpbW8gQ2hlbjxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIE1hcmNoIDA0 LCAyMDE5IDg6MTYgUE08YnI+DQo8Yj5Ubzo8L2I+IFRvbnkgTGkgJmx0O3RvbnkxYXRob21lQGdt YWlsLmNvbSZndDs8YnI+DQo8Yj5DYzo8L2I+IGxzckBpZXRmLm9yZzsgQ2hyaXN0aWFuIEhvcHBz ICZsdDtjaG9wcHNAY2hvcHBzLm9yZyZndDs7IEFjZWUgTGluZGVtIChhY2VlKSAmbHQ7YWNlZUBj aXNjby5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbTHNyXSBNb3ZpbmcgRm9yd2Fy ZCBbUmU6IEZsb29kaW5nIFJlZHVjdGlvbiBEcmFmdCBSZWR1eF08bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6YmxhY2si PkhpIFRvbnksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0O0Zyb206PC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBUb255IExpIFs8YSBocmVmPSJtYWlsdG86dG9ueTFhdGhv bWVAZ21haWwuY29tIj5tYWlsdG86dG9ueTFhdGhvbWVAZ21haWwuY29tPC9hPl0NCjxicj4NCjxi PiZndDtTZW50OjwvYj4gVGh1cnNkYXksIEZlYnJ1YXJ5IDIxLCAyMDE5IDEyOjMyIEFNPGJyPg0K PGI+Jmd0O1RvOjwvYj4gSHVhaW1vIENoZW4gJmx0OzxhIGhyZWY9Im1haWx0bzpodWFpbW8uY2hl bkBodWF3ZWkuY29tIj5odWFpbW8uY2hlbkBodWF3ZWkuY29tPC9hPiZndDs8YnI+DQo8Yj4mZ3Q7 Q2M6PC9iPiBQZXRlciBQc2VuYWsgJmx0OzxhIGhyZWY9Im1haWx0bzpwcHNlbmFrQGNpc2NvLmNv bSI+cHBzZW5ha0BjaXNjby5jb208L2E+Jmd0OzsgQWNlZSBMaW5kZW0gKGFjZWUpICZsdDs8YSBo cmVmPSJtYWlsdG86YWNlZUBjaXNjby5jb20iPmFjZWVAY2lzY28uY29tPC9hPiZndDs7IENocmlz dGlhbiBIb3Bwcw0KPGI+Jmd0OzwvYj4mbHQ7PGEgaHJlZj0ibWFpbHRvOmNob3Bwc0BjaG9wcHMu b3JnIj5jaG9wcHNAY2hvcHBzLm9yZzwvYT4mZ3Q7OyA8YSBocmVmPSJtYWlsdG86bHNyQGlldGYu b3JnIj4NCmxzckBpZXRmLm9yZzwvYT48YnI+DQo8Yj4mZ3Q7U3ViamVjdDo8L2I+IFJlOiBbTHNy XSBNb3ZpbmcgRm9yd2FyZCBbUmU6IEZsb29kaW5nIFJlZHVjdGlvbiBEcmFmdCBSZWR1eF08bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiZndDs8L3NwYW4+PC9iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7PC9zcGFuPjwvYj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0Ozwvc3Bh bj48L2I+SGkgSHVhaW1vLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4mZ3Q7PC9zcGFuPjwvYj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZndDs8L3NwYW4+PC9i PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj5UaGUgd2F5IGluIHdoaWNoIHRoZSBmbG9vZGluZyB0b3BvbG9n eSBjb252ZXJnZXMgaW4gdGhlIGNlbnRyYWxpemVkIG1vZGUvc29sdXRpb24gaXMgZGlmZmVyZW50 PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4mZ3Q7Jmd0Ozwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPmZyb208c3BhbiBj bGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+dGhhdCBpbiB0aGUgZGlz dHJpYnV0ZWQgbW9kZS9zb2x1dGlvbi4gSW4NCiB0aGUgZm9ybWVyLCBhZnRlciByZWNlaXZpbmcg dGhlIGxpbmsgc3RhdGVzIGZvciB0aGUgZmFpbHVyZXMsPGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+Jmd0OyZndDs8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj50aGUgbGVhZGVy IGNvbXB1dGVzIGEgbmV3IGZsb29kaW5nIHRvcG9sb2d5IGFuZCBmbG9vZHMgaXQgdG8gZXZlcnkg b3RoZXIgbm9kZSwgd2hpY2ggcmVjZWl2ZXM8YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4mZ3Q7Jmd0Ozwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPmFuZCBpbnN0YWxscyB0aGUg bmV3IGZsb29kaW5nIHRvcG9sb2d5LiBUaGUgd29ya2luZyBsb2FkIG9uIGV2ZXJ5IG5vbiBsZWFk ZXIgbm9kZSBpcyBsaWdodC4gSXQgaGFzIG1vcmU8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0 OyZndDs8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5 OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5wcm9jZXNzaW5nIHBvd2VyIGZvciBh IHByb2NlZHVyZS9tZXRob2QgZm9yIGZhdWx0IHRvbGVyYW5jZSB0byBmYWlsdXJlcy48YnI+DQo8 L3NwYW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0Ozwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMt c2VyaWYiPkhvd2V2ZXIsIGluIHRoZSBsYXR0ZXIsIGV2ZXJ5IG5vZGUgY29tcHV0ZXMgYW5kIGlu c3RhbGxzIGEgbmV3IGZsb29kaW5nIHRvcG9sb2d5IGFmdGVyIHJlY2VpdmluZzxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8L3NwYW4+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0Ozwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPnRoZSBs aW5rIHN0YXRlcyBmb3IgdGhlIGZhaWx1cmVzLiBJdCBoYXMgbGVzcyBwcm9jZXNzaW5nIHBvd2Vy IGZvciBhIHByb2NlZHVyZS9tZXRob2QgZm9yIGZhdWx0IHRvbGVyYW5jZS48YnI+DQo8L3NwYW4+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0Ozwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYi Pkl0IGlzIGJldHRlciB0byBsZXQgZWFjaCBvZiB0aGUgdHdvIG1vZGVzIHVzZSBpdHMgb3duIHBy b2NlZHVyZS9tZXRob2QgZm9yIGZhdWx0IHRvbGVyYW5jZSB0byBmYWlsdXJlcyw8YnI+DQo8L3Nw YW4+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0Ozwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2Vy aWYiPndoaWNoIGlzIG1vcmUgYXBwcm9wcmlhdGUgdG8gaXQuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7PC9zcGFuPjwv Yj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+Jmd0Ozwvc3Bhbj48L2I+SXTigJlzIHRydWUgdGhhdCBhIGRpc3RyaWJ1dGVkIHNv bHV0aW9uIHdpbGwgY2FsbCBtb3JlIG9uIGFuIGF2ZXJhZ2Ugbm9kZSB0aGFuIGEgY2VudHJhbGl6 ZWQNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4mZ3Q7PC9zcGFuPjwvYj5zb2x1dGlvbiB3aWxsLiBIb3dldmVyLCB0aGF0IGlzIG5vdCB0 aGUgc3RlYWR5IHN0YXRlIGZvciBlaXRoZXIuIEluIHRoZSZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7PC9zcGFuPjwvYj5z dGVhZHkgc3RhdGUsIHRoZSBmbG9vZGluZyB0b3BvbG9neSBoYXMgYmVlbiBjb21wdXRlZCBhbmQg aGFzIGJlZW4gcHV0IGluIHBsYWNlIGFscmVhZHkuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0Ozwvc3Bhbj48L2I+VGh1cywgdGhl IGltcGFjdCBvZiB0aGUgdG9wb2xvZ3kgY29tcHV0YXRpb24gYXQgdGhlIHRpbWUgb2YgdGhlJm5i c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiZndDs8L3NwYW4+PC9iPnRvcG9sb2d5IGNoYW5nZSBpcyBuaWwuJm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs8L3Nw YW4+PC9iPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmIj4mZ3Q7PC9zcGFuPjwvYj5JbiBhZGRpdGlvbiwgdGhlIGFtb3VudCBvZiB3 b3JrIHRvIHRlbXBvcmFyaWx5IGFtZW5kIHRoZSBmbG9vZGluZyB0b3BvbG9neSBzaG91bGQgYWxz bw0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiZndDs8L3NwYW4+PC9iPmJlIG1pbmltYWwsIGFuZCBieSB0aGF0LCBJIG1lYW4gTyhsb2cg bikuICZuYnNwO1RoZSBkZWNpc2lvbiBzaG91bGQgb25seTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7PC9zcGFuPjwvYj5iZSB3aGV0 aGVyIG9yIG5vdCB0byB0ZW1wb3JhcmlseSBhZGQgYSBsaW5rIHRvIGZsb29kaW5nLCBhbmQgdGhl IG9ubHkgaW5mb3JtYXRpb24gdGhhdCBhIG5vZGUNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7PC9zcGFuPjwvYj5uZWVkcyB0byBk byB0aGF0IGlzIHRvIGRldGVybWluZSBpZiB0aGUgbm9kZSBpcyBhbHJlYWR5IG9uIHRoZTxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7 PC9zcGFuPjwvYj5mbG9vZGluZyB0b3BvbG9neS4gVGhhdCBzaG91bGQgYmUgYSBsb29rdXAgaW4g YSB0cmVlIHRoYXQgcmVwcmVzZW50cyB0aGUgbm9kZXMgb24gdGhlIHRvcG9sb2d5LA0KPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs8 L3NwYW4+PC9iPmFuZCB0aGF0IGxvb2t1cCBzaG91bGQgYmUgTyhsb2cgbikuIEluIG90aGVyIHdv cmRzLCBpdOKAmXMgZmFzdDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4mZ3Q7PC9zcGFuPjwvYj5hbmQgZWZmaWNpZW50IGFuZCBub3QgYSBz aWduaWZpY2FudCBkcmFpbiBvbiByZXNvdXJjZXMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPldoZW4gbXVsdGlwbGUgZmFpbHVy ZXMgaGFwcGVuLCB0aGUgY3VycmVudCBmbG9vZGluZyB0b3BvbG9neSBjaGFuZ2VzLCB0aGUgcHJv Y2VkdXJlIGZvciBmYXVsdCB0b2xlcmFuY2UgdG8gZmFpbHVyZXMgaXMgdHJpZ2dlcmVkIHRvIHJ1 biwgYW5kIGEgbmV3IGZsb29kaW5nIHRvcG9sb2d5IGlzIHRvIGJlDQogY29tcHV0ZWQuIFdlIG5l ZWQgdG8gaGF2ZSBhIGNvbnZlcmdlZCBmbG9vZGluZyB0b3BvbG9neSBhcyBzb29uIGFzIHBvc3Np YmxlLiZuYnNwOyA8bzpwPg0KPC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+SW4gdGhlIGRpc3RyaWJ1dGVkIHNvbHV0aW9uL21vZGUsIGlmIGEg cHJvY2VkdXJlIGZvciBmYXVsdCB0b2xlcmFuY2UsIHdoaWNoIGlzIG5vdCBhcHByb3ByaWF0ZSB0 byBpdCwgaXMgdXNlZCwgdGhlbiB3ZSB3aWxsIGhhdmUgYSBjb252ZXJnZWQgZmxvb2RpbmcgdG9w b2xvZ3kgaW4gYSBsb25nZXIgdGltZS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Rm9yIGV4YW1wbGUsIGFmdGVyIG11bHRpcGxl IGZhaWx1cmVzIG9jY3VyLCBvbmUgcHJvY2VkdXJlIChpbiByb3VnaCBpZGVhKSBmb3IgZmF1bHQg dG9sZXJhbmNlIGluY2x1ZGVzOiAxKSBkZXRlcm1pbmUgd2hldGhlciB0aGUgY3VycmVudCBmbG9v ZGluZyB0b3BvbG9neSBzcGxpdHMsIDIpIGNvbXB1dGUNCiBiYWNrdXAgcGF0aHMgdG8gY29ubmVj dCB0aGUgc3BsaXQgZmxvb2RpbmcgdG9wb2xvZ3ksIDMpIGVuYWJsZS9yZXF1ZXN0IHRoZSB0ZW1w b3JhcnkgZmxvb2Rpbmcgb24gdGhlIGJhY2t1cCBwYXRocyB0aHJvdWdoIGV4dGVuc2lvbnMgdG8g SGVsbG8gcHJvdG9jb2wuIFdlIGNhbiBzZWUgdGhhdCB0aGlzIHByb2NlZHVyZSBmb3IgZmF1bHQg dG9sZXJhbmNlIHRha2VzIGEgbG9uZ2VyIHRpbWUgdGhhbiB0aGUgYWxnb3JpdGhtIGNvbXB1dGVz IGEgbmV3DQogZmxvb2RpbmcgdG9wb2xvZ3kuIFRoaXMgcHJvY2VkdXJlIHdpbGwgZGVsYXkgdGhl IGNvbnZlcmdlbmNlIG9mIGZsb29kaW5nIHRvcG9sb2d5LCB3aGljaCBpcyBub3QgYXBwcm9wcmlh dGUgdG8gdGhlIGRpc3RyaWJ1dGVkIHNvbHV0aW9uL21vZGUuPGI+DQo8bzpwPjwvbzpwPjwvYj48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5TbyBpdCBp cyBiZXR0ZXIgZm9yIHRoZSBkaXN0cmlidXRlZCBzb2x1dGlvbi9tb2RlIHRvIHVzZSBhIHByb2Nl ZHVyZSBmb3IgZmF1bHQgdG9sZXJhbmNlLCB3aGljaCBpcyBtb3JlIGFwcHJvcHJpYXRlIHRvIGl0 LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+W0xlczpdIEdp dmVuIHRoYXQgeW91IGRvIG5vdCBkZWZpbmUgd2hhdCB5b3UgdGhpbmsgd2Ugc2hvdWxkIGRvIEkg Y2Fubm90IGNvbW1lbnQgb24gd2hhdGV2ZXIgYWx0ZXJuYXRpdmUgeW91IG1pZ2h0IGhhdmUgaW4g bWluZC48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj5JIGNhbiBzYXkgdGhhdCB5b3VyIGRpc2N1c3Npb24gZG9lcyBu b3QgYWNrbm93bGVkZ2UgdGhhdCBCRUZPUkUgSSBjYW4gY29tcHV0ZSBhIG5ldyBmbG9vZGluZyB0 b3BvbG9neSBJIGhhdmUgdG8gbWFrZSBzdXJlIEkga25vdyB3aGF0IHRoZSB1cGRhdGVkIGZ1bGwg bmV0d29yaw0KIHRvcG9sb2d5IGlzLiBUaGlzIGlzIHdoYXQgaXMgY29tcHJvbWlzZWQgd2hlbiB0 aGUgb2xkIGZsb29kaW5nIHRvcG9sb2d5IGJlY29tZXMgcGFydGl0aW9uZWQuIFNvIHRoZSBmaXJz dCBwcmlvcml0eSBoYXMgdG8gYmUgYWNxdWlyaW5nIHRoZSB1cGRhdGVkIHRvcG9sb2d5LjxvOnA+ PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48 L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPkl0IHdvdWxkIGJlIHVzZWZ1bCBpZiB5b3UgcmVwbGllZCB0byB0aGUgdGhyZWFk IHRoYXQgVG9ueSBzdGFydGVkIGVhcmxpZXIgdG9kYXkgd2hlcmUgaGUgYXNrcyBmb3IgaW5wdXQg b24gaG93IGJlc3QgdG8gdXNlIHRlbXBvcmFyeSBhZGRpdGlvbnMgdG8gdGhlIGZsb29kaW5nDQog dG9wb2xvZ3kuPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+T25lIGV4dHJlbWUgKG15IHdvcmRzIOKAkyBub3QgVG9u eeKAmXMpIHdvdWxkIGJlIHRvIGVuYWJsZSBmbG9vZGluZyBvbiBhbGwgbGlua3MuIFRoaXMgY2xl YXJseSByaXNrcyBpbnRyb2R1Y2luZyBhIGRlc3RhYmlsaXppbmcgZmxvb2Rpbmcgc3Rvcm0uPG86 cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9p PjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+VGhlIG90aGVyIGV4dHJlbWUgd291bGQgYmUgdG8gZW5hYmxlIHRlbXBvcmFy eSBmbG9vZGluZyBvbiBhIOKAnG1pbmltYWwgc2V0IG9mIGxpbmtz4oCdLiBUaGlzIGNsZWFybHkg cmlza3MgZGVsYXlpbmcgY29udmVyZ2VuY2UuPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SWYgdGhpcyB0b3BpYyBp bnRlcmVzdHMgeW91LCBwbGVhc2UgcmVwbHkgdG8gVG9ueeKAmXMgbmV3IHRocmVhZCAo4oCcT3Bl biBpc3N1ZXMgd2l0aCBEeW5hbWljIEZsb29kaW5n4oCdKS48bzpwPjwvbzpwPjwvc3Bhbj48L2k+ PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ SW4gdGhlIGNlbnRyYWxpemVkIHNvbHV0aW9uL21vZGUsIHNjaGVkdWxpbmcgYW4gYWxnb3JpdGht IHRvIGNvbXB1dGUgZmxvb2RpbmcgdG9wb2xvZ3kgaGFwcGVuczxzcGFuIGNsYXNzPSJhcHBsZS1j b252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48YnI+DQo8L3NwYW4+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj4mZ3Q7Jmd0Ozwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPm9ubHkgb24gdGhlIGxl YWRlciwgYW5kIHRoZW4gb24gdGhlIGJhY2t1cCBsZWFkZXIgYWZ0ZXIgdGhlIGxlYWRlciBmYWls cy4gVGhlIHBhcmFtZXRlcnMgZm9yPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PC9zcGFuPjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7PC9z cGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+c2NoZWR1bGluZyBvbiB0aGUgbGVhZGVyIG1heSBi ZSBkaWZmZXJlbnQgZnJvbSB0aG9zZSBmb3Igc2NoZWR1bGluZyBvbiB0aGUgYmFja3VwIGxlYWRl ci48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PGJyPg0K PC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZndDs8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5z LXNlcmlmIj5Ib3dldmVyLCBpbiB0aGUgZGlzdHJpYnV0ZWQgc29sdXRpb24vbW9kZSwgc2NoZWR1 bGluZyBhbiBhbGdvcml0aG0gdG8gY29tcHV0ZSBmbG9vZGluZyB0b3BvbG9neTxicj4NCjwvc3Bh bj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJp ZiI+b2NjdXJzIG9uIGV2ZXJ5IG5vZGUuIFRoZSBwYXJhbWV0ZXJzIGZvciBzY2hlZHVsaW5nIG9u IGFsbCB0aGUgbm9kZXMgbmVlZCB0byBiZSB0aGUgc2FtZS48c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7PC9zcGFuPjwvYj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ Jmd0Ozwvc3Bhbj48L2I+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs8L3NwYW4+PC9iPkFjdHVhbGx5LCB0aGF04oCZcyBu b3QgdHJ1ZS4gJm5ic3A7QW4gaW1wbGVtZW50YXRpb24gaXMgZnJlZSB0byBkbyBpdHMgb3duIGlu dGVybmFsIHNjaGVkdWxpbmcNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7PC9zcGFuPjwvYj5ob3dldmVyIGl0IGNob29zZXMsIHJl Z2FyZGxlc3Mgb2Ygd2hldGhlciBpdCBpbXBsZW1lbnRzIGE8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0Ozwvc3Bhbj48L2I+ZGlzdHJp YnV0ZWQgb3IgY2VudHJhbGl6ZWQgaW1wbGVtZW50YXRpb24uPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs8L3NwYW4+PC9iPjxicj4N CjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvYj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7PC9zcGFuPjwvYj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZiI+VGhlIHByb2NlZHVyZSBmb3IgYWNoaWV2aW5nIHRoaXMgaXMgc3Bl Y2lmaWMgdG8gdGhlIGRpc3RyaWJ1dGVkIG1vZGUvc29sdXRpb24uPC9zcGFuPjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7PC9zcGFu PjwvYj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+Jmd0Ozwvc3Bhbj48L2I+TW9yZSBhY2N1cmF0ZWx5LCBpdCBpcyBzcGVjaWZp YyB0byBhIGdpdmVuIGltcGxlbWVudGF0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7PC9zcGFuPjwvYj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0Ozwv c3Bhbj48L2I+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+SWYg ZXZlcnkgcGFydGljdWxhciBhbGdvcml0aG0gZm9yIGNvbXB1dGluZyBmbG9vZGluZyB0b3BvbG9n eSBpbiB0aGUgZGlzdHJpYnV0ZWQgc29sdXRpb24vbW9kZTxicj4NCjwvc3Bhbj48Yj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiZndDsmZ3Q7PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+ZGVzY3JpYmVz IGEgcHJvY2VkdXJlIGZvciBzY2hlZHVsaW5nIGluIGRldGFpbHMgaXRzZWxmLCB0aGVyZSB3aWxs IGJlIGR1cGxpY2F0ZWQgZGVzY3JpcHRpb25zIG9mPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4NCjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZn dDsmZ3Q7PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWls eTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+dGhlIHNhbWUgcHJvY2VkdXJlIGlu IG11bHRpcGxlIGFsZ29yaXRobXMsIG9uZSBvZiB3aGljaCBpcyBzZWxlY3RlZCB0byBjb21wdXRl IGZsb29kaW5nPGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZndDs8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZl dGljYSZxdW90OyxzYW5zLXNlcmlmIj50b3BvbG9neSBvbiBldmVyeSBub2RlLiBJdCBpcyBiZXR0 ZXIgZm9yIHRoZSBzYW1lIHNjaGVkdWxpbmcgcHJvY2VkdXJlIGZvciBtdWx0aXBsZSBhbGdvcml0 aG1zPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxicj4N Cjwvc3Bhbj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fu cy1zZXJpZiI+dG8gYmUgZGVzY3JpYmVkIGluIG9uZSBkb2N1bWVudC4gJm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4m Z3Q7PC9zcGFuPjwvYj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0Ozwvc3Bhbj48L2I+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs8L3NwYW4+PC9i PkFjdHVhbGx5LCBzaW5jZSB0aGUgSUVURiBzaG91bGQgbm90IGJlIHNwZWNpZnlpbmcgdGhlIGRl dGFpbHMgb2Ygc2NoZWR1bGluZyBhcyBpdCBpcyBhbg0KPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs8L3NwYW4+PC9iPmltcGxlbWVu dGF0aW9uIGRldGFpbCwgYXMgdGhleSBkbyBub3QgYWZmZWN0IHRoZSBiZWhhdmlvciBvZiB0aGUg cHJvdG9jb2wsIGl0IHNob3VsZCBub3QgYmU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0Ozwvc3Bhbj48L2I+ZGlzY3Vzc2VkIGluIGFu eSBkb2N1bWVudHMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIG11bHRpcGxlIHZlbmRvciBu ZXR3b3JrcywgdXNpbmcgZGlmZmVyZW50IGltcGxlbWVudGF0aW9ucyB3aWxsIGNyZWF0ZSBtb3Jl IG1pY3JvIHJvdXRpbmcgbG9vcHMgZHVyaW5nIHRoZSBjb252ZXJnZW5jZSBwcm9jZXNzIGR1ZSB0 byBkaXNjcmVwYW5jaWVzIG9mIHBhcmFtZXRlcnMvdGltZXJzIGZvciBzY2hlZHVsaW5nIHRoYW4g dXNpbmcgYSBzYW1lIGltcGxlbWVudGF0aW9uLiBNb3JlIG1pY3JvIHJvdXRpbmcNCiBsb29wcyB3 aWxsIGxlYWQgdG8gbW9yZSB0cmFmZmljIGxvc2UuIFNlcnZpY2UgcHJvdmlkZXJzIGFyZSBhbHJl YWR5IGF3YXJlIHRvIHVzZSBzaW1pbGFyIHRpbWVycyAodmFsdWVzIGFuZCBiZWhhdmlvciksIGJ1 dCBzb21ldGltZXMgaXQgaXMgbm90IHBvc3NpYmxlIGR1ZSB0byBsaW1pdGF0aW9ucyBvZiBpbXBs ZW1lbnRhdGlvbnMuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhlcmUg d2UgY29tZSB0byBhIHBvaW50IHdoZXRoZXIgd2UgbmVlZCB0byBoYXZlIGEgc2FtZSBzY2hlZHVs aW5nIHByb2NlZHVyZSBmb3IgYSBmbG9vZGluZyB0b3BvbG9neSBjb21wdXRhdGlvbiBhbGdvcml0 aG0gdG8gYmUgaW1wbGVtZW50ZWQgYnkgbXVsdGlwbGUgdmVuZG9ycy4gSWYgd2UgZG8gbm90IGhh dmUgYSBzYW1lIHNjaGVkdWxpbmcgcHJvY2VkdXJlLCB0aGVuIHNlcnZpY2UgcHJvdmlkZXJzIHdp bGwNCiBoYXZlIGRpZmZlcmVudCBzY2hlZHVsaW5nIGltcGxlbWVudGF0aW9ucy9wcm9jZWR1cmVz IGZyb20gZGlmZmVyZW50IHZlbmRvcnMsIHdoaWNoIHdpbGwgY3JlYXRlIG1vcmUgbWljcm8gcm91 dGluZyBsb29wcywgbGVhZGluZyB0byBtb3JlIHRyYWZmaWMgbG9zZS4gSWYgd2UgaGF2ZSBhIHNh bWUgc2NoZWR1bGluZyBwcm9jZWR1cmUsIHRoZW4gc2VydmljZSBwcm92aWRlcnMgd2lsbCBoYXZl IHRoZSBzYW1lIHNjaGVkdWxpbmcgcHJvY2VkdXJlIGZyb20NCiBkaWZmZXJlbnQgdmVuZG9ycywg d2hpY2ggd2lsbCBjcmVhdGUgbGVzcyBtaWNybyByb3V0aW5nIGxvb3BzLiBUaHVzIHdlIHdpbGwg aGF2ZSBsZXNzIHRyYWZmaWMgbG9zZS4NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+V2UgY2FuIHNlZSB0aGF0IHRoZXJlIGlzIGEgbmVlZCB0byBoYXZlIGEgc2FtZSBzY2hl ZHVsaW5nIHByb2NlZHVyZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ W0xlczpdIElmIHlvdXIgY29uY2VybiBpcyB0aGF0IHdlIGRvIG5vdCB3YW50IG9uZSBub2RlIHRv IGFwcGx5IGEgZGVsYXkgb2YgNTAgbXMgYW5kIGFub3RoZXIgbm9kZSB0byBhcHBseSBhIGRlbGF5 IG9mIDEwIHNlY29uZHMgSSB0aGluayB3ZSBjYW4gZWFzaWx5IGFncmVlDQogb24gdGhhdC4gQnV0 IHdlIGhhdmUgbWFueSB5ZWFycyBvZiBleHBlcmllbmNlIGluIGNvbmZpZ3VyaW5nIGNvbnNpc3Rl bnQgU1BGIGRlbGF5IHRpbWVycyBhbmQgSSB0aGluayB0aGF0IGlzIGFwcGxpY2FibGUgaGVyZSBh cyB3ZWxsLiBJIGRvbuKAmXQgdGhpbmsgdGhpcyBpcyBhIHBvaW50IG9mIGNvbmNlcm4gb3IgY29u dHJvdmVyc3kuPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7IExlczwvc3Bhbj48L2k+PC9iPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPkJlc3QgUmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkh1 YWltbzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs8L3Nw YW4+PC9iPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiZndDs8L3NwYW4+PC9iPlRvbnk8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv Ym9keT4NCjwvaHRtbD4NCg== --_000_MN2PR11MB36472B0D64D7D6838E2F56ACC1720MN2PR11MB3647namp_-- From nobody Mon Mar 4 23:38:26 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11D34130FB1 for ; Mon, 4 Mar 2019 23:38:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 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 dDRRGs_h9Enn for ; Mon, 4 Mar 2019 23:38:23 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 826A2124408 for ; Mon, 4 Mar 2019 23:38:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2714; q=dns/txt; s=iport; t=1551771502; x=1552981102; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=4F6cFwdIt/eR2sNzHBaQFLB+FBoUOXyllS+SzIuDr9U=; b=NrNVMzUQ4r5MfucenqiOodyEzs0HeanciK0P3r2uScG8H3Tn5Jgoa2TR h7dG8j8+yQrMeMcnXJqvIKjkxKfgjMifQE2+1TKkyj6xeK0dz/BpREn1N fLe7XIog9OmsZulZmPQXWYm0KIP3VSCy/F7h6dlyrCK9ydFwKDB4/4T9v 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAADeJX5c/xbLJq1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUwIBAQEBAQsBgneBAyeECIh5jHiYIYF7DRgLhEkChEk?= =?us-ascii?q?2Bw0BAQMBAQMBAwJtHAyFSgEBAQMBAQEhDwEFNhsLGAICJgICJzAHDAYCAQG?= =?us-ascii?q?DHgGBbQgPqFuBL4VEhGQFgQskAYRZhmWBQD+BEAEngj0ugx4BAYRrglcCpAQ?= =?us-ascii?q?Jkm4GGYp4iCqKZJJKgU4CL4FWMxoIGxU7gmyJPoFOhUA+AzCOSCqCIwEB?= X-IronPort-AV: E=Sophos;i="5.58,443,1544486400"; d="scan'208";a="10491704" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Mar 2019 07:38:20 +0000 Received: from [10.60.140.53] (ams-ppsenak-nitro4.cisco.com [10.60.140.53]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id x257cINt016574; Tue, 5 Mar 2019 07:38:19 GMT To: tony.li@tony.li, lsr@ietf.org References: From: Peter Psenak Message-ID: Date: Tue, 5 Mar 2019 08:38:18 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Outbound-SMTP-Client: 10.60.140.53, ams-ppsenak-nitro4.cisco.com X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Lsr] Open issues with Dynamic Flooding X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 07:38:25 -0000 Hi Tony, On 04/03/2019 18:54 , tony.li@tony.li wrote: > > Hello, > > There are still two issues that need to be discussed and I was hoping that we could make progress on the mailing list before Prague. > > 1) Temporary additions to the flooding topology > > There are several cases where we would like to make temporary additions to the flooding topology: repairing a partition of the flooding topology or adding a node to the base topology for the first time. We can: > > (a) Temporarily add all of the links that would appear to remedy the partition. This has the advantage that it is very likely to heal the partition and will do so in the minimal amount of convergence time. > > (b) For each node adjacent to the partition, add no more than a single link across the partition. If that does not repair the partition in a while (LSP propagation time + SPF time), then add another link. > Iterate as necessary. This has the advantage that it minimizes the risk of creating a cascade failure. I prefer (a) because of the faster convergence. Adding all links on a single node to the flooding topology is not going to cause issues to flooding IMHO. > > 2) Inclusion of pseduonodes in the System IDs TLV > > In the general case, a topology can include LANs. If a LAN is in parallel with a P2P link, the Area Leader cannot currently distinguish between the two links. This can be of importance if there are other > systems also on the LAN that should be using their LAN interface for flooding. > > We propose to change the System IDs TLV to include a pseudo-node ID as well as the system ID. It would also make sense to rename the TLV to be the “IS-IS Area Node IDs TLVâ€. > > Behaviorally, we should add a requirement that if the Area Leader includes a pseudonode in the flooding topology, then all systems with an adjacency on that LAN should use the LAN as part of the > flooding topology, whether or not they are explicitly listed as adjacent to the LAN in the Flooding Path TLV. given that the flooding on the LAN in both OSPF and ISIS is done as multicast, there is currently no way to enable flooding, either permanent or temporary, towards a subset of the neighbors on the LAN. So if the flooding is enabled on a LAN it is done towards all routers connected to the it. Given that all links between routers are p2p these days, I would vote for simplicity and make the LAN always part of the FT. thanks, Peter > > Thoughts? Comments? Flames? > > Regards, > Tony > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > From nobody Tue Mar 5 00:48:58 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEEE0127598; Tue, 5 Mar 2019 00:48:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (1024-bit key) header.d=alibaba-inc.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 3GkRGPJAZtBu; Tue, 5 Mar 2019 00:48:55 -0800 (PST) Received: from out0-157.mail.aliyun.com (out0-157.mail.aliyun.com [140.205.0.157]) (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 B15CA124B0C; Tue, 5 Mar 2019 00:48:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alibaba-inc.com; s=default; t=1551775728; h=Date:From:To:Message-ID:Subject:MIME-Version:Content-Type; bh=6sfu+CINPH7sVUHpKURb38z67jQ0qllnyErjAtQHG/g=; b=GyGMvJgaB6x0IWZN2Mv7QCWkRCVqe+qZysZresHeKT87Mua8+OQmWmyBPZgXEuh4mB9YFKcnTv3Th9busWVX+zU0S/21iQf5MZ3RGjhRdM9jCiUST2+6cD7O9DRLlfzIpONXKayoZd786IqOzp9bEwKz6+UI0AFHxzS3kURiUjY= X-Alimail-AntiSpam: AC=PASS; BC=-1|-1; BR=01201311R161e4; CH=green; DM=||false|; FP=0|-1|-1|-1|0|-1|-1|-1; HT=e02c03308; MF=xiaohu.xxh@alibaba-inc.com; NM=1; PH=DW; RN=3; SR=0; TI=W4_5478978_v5ForWebDing_0AC264FB_1551775320223_o7001c2512e; Received: from WS-web (xiaohu.xxh@alibaba-inc.com[W4_5478978_v5ForWebDing_0AC264FB_1551775320223_o7001c2512e]) by e01l10421.eu6 at Tue, 05 Mar 2019 16:48:46 +0800 Date: Tue, 05 Mar 2019 16:48:46 +0800 From: "=?UTF-8?B?5b6Q5bCP6JmOKOS5ieWFiCk=?=" To: "Lsr" , "tony.li" , "lsr" Reply-To: "=?UTF-8?B?5b6Q5bCP6JmOKOS5ieWFiCk=?=" Message-ID: <94f6103c-f465-4ba0-91cf-9db8844c26a1.xiaohu.xxh@alibaba-inc.com> X-Mailer: [Alimail-Mailagent][W4_5478978][v5ForWebDing][Safari] MIME-Version: 1.0 References: , x-aliyun-mail-creator: W4_5478978_v5ForWebDing_NjATW96aWxsYS81LjAgKE1hY2ludG9zaDsgSW50ZWwgTWFjIE9TIFggMTBfMTJfNikgQXBwbGVXZWJLaXQvNjA1LjEuMTUgKEtIVE1MLCBsaWtlIEdlY2tvKSBWZXJzaW9uLzEyLjAuMiBTYWZhcmkvNjA1LjEuMTU=XQ In-Reply-To: Content-Type: multipart/alternative; boundary="----=ALIBOUNDARY_16832_50c8d940_5c7e37ee_3ec08b" Archived-At: Subject: Re: [Lsr] =?utf-8?q?Open_issues_with_Dynamic_Flooding?= X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 08:48:57 -0000 ------=ALIBOUNDARY_16832_50c8d940_5c7e37ee_3ec08b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 CgoKPiBHaXZlbiB0aGF0IGFsbCBsaW5rcyBiZXR3ZWVuIHJvdXRlcnMgYXJlIHAycCB0aGVzZSBk YXlzLCBJIHdvdWxkIHZvdGUgCj4gZm9yIHNpbXBsaWNpdHkgYW5kIG1ha2UgdGhlIExBTiBhbHdh eXMgcGFydCBvZiB0aGUgRlQuCgpFdmVuIGFsbCBsaW5rcyBiZXR3ZWVuIHJvdXRlcnMgYXJlIFAy UCB0aGVzZSBkYXlzLCB0aGUgbmV0d29yayBtYW5hZ2VtZW50IExBTiBpZiBhdmFpbGFibGUgY291 bGQgYmUgbGV2ZXJhZ2VkIHRvIHJlYWxpemUgYW4gZWZmaWNpZW50IGxpbmstc3RhdGUgc3luY2hy b25pemF0aW9uIGFtb25nICB0aGVzZSByb3V0ZXJzLiBJbiBvdGhlciB3b3JkcywgdGhlIG1hbmFn ZW1lbnQgTEFOIGl0c2VsZiBpcyBub3cgdGhlIEZUIChzZWUgaHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXh1LWxzci1pc2lzLWZsb29kaW5nLXJlZHVjdGlvbi1pbi1tc2RjLTAxKS4K CkJlc3QgcmVnYXJkcywKWGlhb2h1Cgo= ------=ALIBOUNDARY_16832_50c8d940_5c7e37ee_3ec08b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBjbGFzcz0iX19hbGl5dW5fZW1haWxfYm9keV9ibG9jayI+PGRpdiAgc3R5bGU9ImxpbmUt aGVpZ2h0OjEuNztmb250LWZhbWlseTpUYWhvbWEsQXJpYWwsU1RIZWl0aSxTaW1TdW47Zm9udC1z aXplOjE0LjBweDtjb2xvcjojMDAwMDAwOyI+PGRpdiAgc3R5bGU9ImNsZWFyOmJvdGg7Ij48YnIg PjwvZGl2PjxkaXYgIHN0eWxlPSJtYXJnaW46LjBweCAuMHB4IC4wcHggMzAuMHB4O2ZvbnQtZmFt aWx5OlRhaG9tYSxBcmlhbCxTVEhlaXRpLFNpbVN1bjtmb250LXNpemU6MTQuMHB4O2NvbG9yOiMw MDAwMDA7Ij48YnIgPjxiciA+Jmd0OyBHaXZlbiZuYnNwO3RoYXQmbmJzcDthbGwmbmJzcDtsaW5r cyZuYnNwO2JldHdlZW4mbmJzcDtyb3V0ZXJzJm5ic3A7YXJlJm5ic3A7cDJwJm5ic3A7dGhlc2Um bmJzcDtkYXlzLCZuYnNwO0kmbmJzcDt3b3VsZCZuYnNwO3ZvdGUmbmJzcDs8YnIgPiZndDsgZm9y Jm5ic3A7c2ltcGxpY2l0eSZuYnNwO2FuZCZuYnNwO21ha2UmbmJzcDt0aGUmbmJzcDtMQU4mbmJz cDthbHdheXMmbmJzcDtwYXJ0Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtGVC48L2Rpdj48ZGl2ICBz dHlsZT0ibWFyZ2luOi4wcHggLjBweCAuMHB4IDMwLjBweDtmb250LWZhbWlseTpUYWhvbWEsQXJp YWwsU1RIZWl0aSxTaW1TdW47Zm9udC1zaXplOjE0LjBweDtjb2xvcjojMDAwMDAwOyI+PGJyID48 L2Rpdj48ZGl2ICBzdHlsZT0ibWFyZ2luOi4wcHggLjBweCAuMHB4IDMwLjBweDtmb250LWZhbWls eTpUYWhvbWEsQXJpYWwsU1RIZWl0aSxTaW1TdW47Zm9udC1zaXplOjE0LjBweDtjb2xvcjojMDAw MDAwOyI+RXZlbiBhbGwgbGlua3MgYmV0d2VlbiByb3V0ZXJzIGFyZSBQMlAgdGhlc2UgZGF5cywg dGhlIG5ldHdvcmsgbWFuYWdlbWVudCBMQU4gaWYgYXZhaWxhYmxlIGNvdWxkIGJlIGxldmVyYWdl ZCB0byByZWFsaXplIGFuIGVmZmljaWVudCBsaW5rLXN0YXRlIHN5bmNocm9uaXphdGlvbiBhbW9u ZyAmbmJzcDt0aGVzZSByb3V0ZXJzLiBJbiBvdGhlciB3b3JkcywgdGhlIG1hbmFnZW1lbnQgTEFO IGl0c2VsZiBpcyBub3cgdGhlIEZUIChzPHNwYW4gIHN0eWxlPSJmb250LXNpemU6MTQuMHB4OyI+ ZWUmbmJzcDs8L3NwYW4+PGEgIGhyZWY9Imh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFm dC14dS1sc3ItaXNpcy1mbG9vZGluZy1yZWR1Y3Rpb24taW4tbXNkYy0wMSIgdGFyZ2V0PSJfYmxh bmsiIHN0eWxlPSJmb250LXNpemU6MTQuMHB4OyI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LXh1LWxzci1pc2lzLWZsb29kaW5nLXJlZHVjdGlvbi1pbi1tc2RjLTAxPC9hPikuPC9k aXY+PGRpdiAgc3R5bGU9Im1hcmdpbjouMHB4IC4wcHggLjBweCAzMC4wcHg7Zm9udC1mYW1pbHk6 VGFob21hLEFyaWFsLFNUSGVpdGksU2ltU3VuO2ZvbnQtc2l6ZToxNC4wcHg7Y29sb3I6IzAwMDAw MDsiPjxiciA+PC9kaXY+PGRpdiAgc3R5bGU9Im1hcmdpbjouMHB4IC4wcHggLjBweCAzMC4wcHg7 Zm9udC1mYW1pbHk6VGFob21hLEFyaWFsLFNUSGVpdGksU2ltU3VuO2ZvbnQtc2l6ZToxNC4wcHg7 Y29sb3I6IzAwMDAwMDsiPkJlc3QgcmVnYXJkcyw8L2Rpdj48ZGl2ICBzdHlsZT0ibWFyZ2luOi4w cHggLjBweCAuMHB4IDMwLjBweDtmb250LWZhbWlseTpUYWhvbWEsQXJpYWwsU1RIZWl0aSxTaW1T dW47Zm9udC1zaXplOjE0LjBweDtjb2xvcjojMDAwMDAwOyI+WGlhb2h1PGJyID48YnIgPjwvZGl2 PjwvZGl2PjwvZGl2Pg== ------=ALIBOUNDARY_16832_50c8d940_5c7e37ee_3ec08b-- From nobody Tue Mar 5 01:27:54 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72F16131088; Tue, 5 Mar 2019 01:27:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.491 X-Spam-Level: X-Spam-Status: No, score=-14.491 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, L_8BIT_MISMATCH=0.01, RCVD_IN_DNSWL_HI=-5, 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 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 VgZ892-_ixW2; Tue, 5 Mar 2019 01:27:44 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23E99131073; Tue, 5 Mar 2019 01:27:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=808; q=dns/txt; s=iport; t=1551778065; x=1552987665; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=dqush3hH6m/e4x7XwRAz4UpMrLejUPJaxfP5q2lRJRQ=; b=D8Nio6s+8msYt0Fy9HpGEdDpD2caX0MDAddihOPzTdEDsqDwPaZHNPoG sEOoL0+YEBjAuVyrKhcB7RIptiI+PECH3eg5P+lAG1NivrgHgnt/2jwtQ ch+BRkbPYZPMQhvHxrbOyZT4rgVsklZq5aetBSZhf49PB0pZgb6MBeM37 Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAABKP35c/xbLJq1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUgMBAQEBAQsBgndxEieECIh5jFIlgzeUaoF7DRgNhEc?= =?us-ascii?q?ChEk1CA0BAQMBAQMBAwJtHAyFSgEBAQECAQEBIRU2GwkCGAICJgICJzAGAQw?= =?us-ascii?q?GAgEBgx4BgW0ID40Km2aBL4QzAoEPhGMFgQskAYs+gUA/gTgMgjEugx4BAQO?= =?us-ascii?q?EaIJXApExklUJh0OLKwYZinqILIplhVyMcYFJATWBVjMaCBsVO4JsiwyFQD4?= =?us-ascii?q?DMJEVAQE?= X-IronPort-AV: E=Sophos;i="5.58,443,1544486400"; d="scan'208";a="10549271" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Mar 2019 09:27:42 +0000 Received: from [10.147.24.27] ([10.147.24.27]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id x259Rfiw007647; Tue, 5 Mar 2019 09:27:41 GMT To: =?UTF-8?B?5b6Q5bCP6JmOKOS5ieWFiCk=?= , Lsr , "tony.li" , lsr References: <94f6103c-f465-4ba0-91cf-9db8844c26a1.xiaohu.xxh@alibaba-inc.com> From: Peter Psenak Message-ID: <7f0d25e8-2789-2276-49f8-1c296f9cd03e@cisco.com> Date: Tue, 5 Mar 2019 10:27:40 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <94f6103c-f465-4ba0-91cf-9db8844c26a1.xiaohu.xxh@alibaba-inc.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Outbound-SMTP-Client: 10.147.24.27, [10.147.24.27] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Lsr] Open issues with Dynamic Flooding X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 09:27:53 -0000 Xiaohu, On 05/03/2019 09:48 , å¾å°è™Ž(义先) wrote: > > > >> Given that all links between routers are p2p these days, I would vote >> for simplicity and make the LAN always part of the FT. > > Even all links between routers are P2P these days, the network > management LAN if available could be leveraged to realize an efficient > link-state synchronization among these routers. In other words, the > management LAN itself is now the FT > (see https://tools.ietf.org/html/draft-xu-lsr-isis-flooding-reduction-in-msdc-01). sure. What I proposed would not impact the above in any negative way. thanks, Peter > > Best regards, > Xiaohu > > > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > From nobody Tue Mar 5 07:28:44 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 472AD1275F3; Tue, 5 Mar 2019 07:28:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 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 vQTUIafI4h8i; Tue, 5 Mar 2019 07:28:32 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A15661200D8; Tue, 5 Mar 2019 07:28:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5593; q=dns/txt; s=iport; t=1551799713; x=1553009313; h=from:subject:to:references:cc:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=Bno35MmmWZJkN5/NeKZqlyvb3QqVZnTN/LMvldu9mmE=; b=jU6RfXINMP2SaUASKo7I1OyP/ux++NNUyDcUOIa51n9XVPaIJfXd3hsF NnDCGrBq3b1ZdsbBH1WmOHFGIsgn+Xu1Cx5dI8BGYjtvT36YC63CJdKMi vQcPsrB39Lw50nbSP1wBYjB1HidaahpQftfhqDbO6dtYQzcGx9N6hKl5K w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AFAAA2lX5c/xbLJq1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUgMBAQEBAQsBgndxEieNAYx4mCEUgWcNGAuEA0YChE0?= =?us-ascii?q?1CA0BAQMBAQMBAwJtHAyFSgEBAQMBAQE2NgsOAgsRBAEBAS4WESgIBg0GAgE?= =?us-ascii?q?Bgx4BgW0ID6tUhDMChXMFBYEqAYs+gUA/gRAogmuDHgEBA4EmBQESAUUGhTU?= =?us-ascii?q?CiXgchx6SVQmHQ4EaihEGGYF0hWSDIogtkEGMcYFJAzNlcTMaCBsVO4JsghY?= =?us-ascii?q?XiF+FQD4DMI5Xgj4BAQ?= X-IronPort-AV: E=Sophos;i="5.58,444,1544486400"; d="scan'208";a="10556778" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Mar 2019 15:28:29 +0000 Received: from [10.147.24.27] ([10.147.24.27]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id x25FSSJF012151; Tue, 5 Mar 2019 15:28:28 GMT From: Peter Psenak To: Alexander Vainshtein References: <20493a62-cf70-a182-900d-e55dd68f5149@cisco.com> Cc: "lsr@ietf.org" , "spring@ietf.org" , "draft-ietf-isis-segment-routing-extensions.all@ietf.org" Message-ID: Date: Tue, 5 Mar 2019 16:28:28 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Outbound-SMTP-Client: 10.147.24.27, [10.147.24.27] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Lsr] [spring] FlexAlgo and Global Adj-SIDs X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 15:28:36 -0000 Hi Sasha, On 02/03/2019 18:57 , Alexander Vainshtein wrote: > Peter, > Lots of thanks for a prompt and hivhly informative response. > > It seems that per-FlexAlgo Adj-SIDs can be useful even if they are local. > The relevant use case could be a protected local Adj-SID that is used in > a SR-TE LSP that has been set up with some constraints in mind. These > constraints would be preserved when the protected adjacency in question > is UP, but could be violated when it fails and the shortest path to the > node at the remote end of adjacency is used. yes, this is a possible use case. This would require a new Algo specific Adj-SID sub-TLV to be defined. This could be done. thanks, Peter > > Local protected Adj-SIDs for sure have bern implemented, so this looks > like a more relevant use case than global adjacencies to me. > > What do you think? > > Regards, and lots of thanks in advance, > > Thumb typed by Sasha Vainshtein > > ------------------------------------------------------------------------ > *From:* Peter Psenak > *Sent:* Thursday, February 28, 2019 9:56:49 PM > *To:* Alexander Vainshtein; > draft-ietf-isis-segment-routing-extensions@ietf.org > *Cc:* lsr@ietf.org; spring@ietf.org > *Subject:* Re: [spring] FlexAlgo and Global Adj-SIDs > > Hi Alexander, > > On 28/02/2019 19:19 , Alexander Vainshtein wrote: >> Dear colleagues, >> >> I have a question regarding global Adj-SIDs in >> draft-ietf-isis-segment-routing-extensions. >> >> >> >> Section 3.4 of RFC 8402 defines >> definition and handling of global Adj-SIDs. >> >> The relevant text is given below: >> >> >> >> >> >> Similarly, when using a global Adj-SID, a packet injected anywhere >> >> within the SR domain with a segment list {SNL}, where SNL is a global >> >> Adj-SID attached by node N to its adjacency over link L, will be >> >> forwarded along the shortest path to Nand then be switched by N, >> >> without any IP shortest-path consideration, towards link L. >> >> ... >> >> The use of global Adj-SID allows to reduce the size of the segment list >> >> When expressing a path at the cost of additional state (i.e., the global >> >> Adj-SID will be inserted by all routers within the area in their >> >> forwarding table). >> >> >> >> >> >> The definition of the Adjacency Segment Identifier Sub-TLV in Section >> 2.2.1 of the draft matches the behavior defined in RFC 8402, i.e., it >> allows advertisement of global Adj-SIDs. >> >> These advertisements can be associated with a specific IGP adjacency >> and, in multi-topology scenarios, a specific topology. But it is not >> associated with any specific algorithm since the default algorithm for >> reaching the advertising node is implicitly assumed in full alignment >> with RFC 8402. >> >> >> >> My question is about the situation in which multiple algorithms are >> supported by the routers in the SR domain, so that each node advertises >> a dedicated Node SID for each of these algorithm. >> >> In this scenario, the operator can set up a SR-TE LSP that meets >> specific constraints (incorporated in one of these algorithms, see IGP >> Flexible Algorithm >> draft) by >> using Node SIDs that have been advertised with the corresponding >> algorithm and local Adj-SIDs. However, global Adj-SIDs cannot be used >> (e.g., for reducing the label stack depth) in this situation. >> >> I wonder if the possibility to advertise global Adj-SID (that can be >> considered as replacing a combination of the Node SID of the advertising >> node and one of its local Adj-SIDs) as associated with a specific >> algorithm has ever been considered? > > to be honest, it has been not. > > The usage of the global Adj-SID has not been widely considered due to > the additional forwarding entries it requires on rest of the routers in > the area. Not sure if there are implementations of the global ADj-SID > out there. > > If you believe this is important, we can certainly addressed that in a > small draft. > > thanks, > Peter > > > > >> >> >> >> Regards, and lots of thanks in advance, >> >> Sasha >> >> >> >> Office: +972-39266302 >> >> Cell: +972-549266302 >> >> Email: Alexander.Vainshtein@ecitele.com >> >> >> >> >> ___________________________________________________________________________ >> >> This e-mail message is intended for the recipient only and contains >> information which is >> CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have >> received this >> transmission in error, please inform us by e-mail, phone or fax, and >> then delete the original >> and all copies thereof. >> ___________________________________________________________________________ >> >> >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring >> > > > ___________________________________________________________________________ > > This e-mail message is intended for the recipient only and contains > information which is > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have > received this > transmission in error, please inform us by e-mail, phone or fax, and > then delete the original > and all copies thereof. > ___________________________________________________________________________ From nobody Tue Mar 5 07:42:00 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D095812D4E9 for ; Tue, 5 Mar 2019 07:41:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, 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=juniper.net 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 uE6ugWEX53dJ for ; Tue, 5 Mar 2019 07:41:53 -0800 (PST) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 C5D4E129A87 for ; Tue, 5 Mar 2019 07:41:52 -0800 (PST) Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x25FYVoX019295; Tue, 5 Mar 2019 07:41:49 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=IDSCqGLVwcp1IXTwjIcYMGgAbnoxGwbNNGJ5z0Yl70A=; b=h8TbEBPA3/NjwXyUclQi76pHcHQixHQ2PI9HXgjnws4jIWzwzv5+NADhPB+d+rwP8G3Q wxBEn34KP5Twt2+XHyRQC1fYv+spjuGgevduklxg6LneILodqufis/CgBxGouRj9GipM esNCTqvol18n3Bz1BK7mtyEDEDr2k7xX0EzzD/18/DQ0PMWZqUgo30r9Qw/7mwve2BeL j25Pia3bEMPvx5wTPiCMJPjpGHSBhV79/AF2Dqs/mR1loGy2Y972ClQf1Ra8GgIVBNIW CzeS3PzYGOVXefdwueDTGjMoo7x1iIbPK7Y7gblQ7BGK/GjkFIwg+s8oaDuzo8LSEQvf 1g== Received: from nam01-bn3-obe.outbound.protection.outlook.com (mail-bn3nam01lp2058.outbound.protection.outlook.com [104.47.33.58]) by mx0a-00273201.pphosted.com with ESMTP id 2r1npggjdj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 05 Mar 2019 07:41:49 -0800 Received: from BYAPR05MB5029.namprd05.prod.outlook.com (20.177.230.211) by BYAPR05MB4182.namprd05.prod.outlook.com (52.135.200.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.14; Tue, 5 Mar 2019 15:41:46 +0000 Received: from BYAPR05MB5029.namprd05.prod.outlook.com ([fe80::b58f:10f1:a40b:abf7]) by BYAPR05MB5029.namprd05.prod.outlook.com ([fe80::b58f:10f1:a40b:abf7%4]) with mapi id 15.20.1686.016; Tue, 5 Mar 2019 15:41:46 +0000 From: John E Drake To: Peter Psenak , "tony.li@tony.li" , "lsr@ietf.org" Thread-Topic: [Lsr] Open issues with Dynamic Flooding Thread-Index: AQHU0rNaVvQ0QBVMlk2Xrz5VBQhbhaX8p2YAgACHA6A= Date: Tue, 5 Mar 2019 15:41:46 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.1.100.23 dlp-reaction: no-action x-originating-ip: [66.129.241.12] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a16bf495-50ae-433e-8d41-08d6a1811350 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB4182; x-ms-traffictypediagnostic: BYAPR05MB4182: x-ms-exchange-purlcount: 2 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtCWUFQUjA1TUI0MTgyOzIzOmdVVFFFNlNGYmg1TUhxdHlwL2NIYW9uNzFI?= =?utf-8?B?d3FudHpxeU9uWDRrbkJiMUVoMXdRR1FseDMvT1I3d09TRHI4OVBvRXhrM3d1?= =?utf-8?B?V3Z6N1B5K1VjdlVuVWR3eFljYzc2RmFwZ2NUMXduQURtQXV3KzFsMmxhTUFL?= =?utf-8?B?ay92RGFwTDVIb1BpNmtRVmFiMmdoRVhTbmMxSGRwY1dqN200WDRwSmpyTTdx?= =?utf-8?B?RVZkVElrOC9EcHU2MW9EVVRCNUpqSVVuV1NJNXVLNWhQTVhqM0JndXJkUGVs?= =?utf-8?B?dlRJMmJ4QjQ0U2RKOWVGR05CK1J5TDZzeGpyQzFMbXlXNkE0UExQS2xNb0pR?= =?utf-8?B?c0NqbUxvMDNDdGNlVmx6dGIzRFIwWXFsU2FSSTVWVkxtTDZmcm56c0hWTTd0?= =?utf-8?B?dkcvT2wyaVovT1paTGM5SVFuT0lKMWduT1MwdEJRWGZRK01ORk42N1BxZ1Fk?= =?utf-8?B?UE9jVSsycXRqcXQ4U2h3NjM2dmxSalc1ZVZVWS9reXhLQ0wvRUhNNUxuRW54?= =?utf-8?B?Q3Z0UTVyVXo0akdodjVoS1lBUElDd0M3VWwwVTdLM0JlNG9zdEIydXlWMmtW?= =?utf-8?B?eVM4WGwwNVpBcVAyTXNBRXhOSnRrOVlQaUtmQzhKTEJlN01GTFRZV0UyU1gw?= =?utf-8?B?M3FQMzVnSGcxWUE2N2hYZTV6dm5ZTlJKajhtQzZMQ1NzZUlBeXVzMjBlNXo5?= =?utf-8?B?YkxqODV6YlMzczZRNVo0NldxajV4bktOWUViYnM2WnhxVEZHK3VHV1FkYlo0?= =?utf-8?B?MzBBUmQwWGdabnY3T1VtOGhnTzkvVUNxMU1aVllsMWZ0RnU0LzlFSVFJWDVH?= =?utf-8?B?Y1JtVFJBR0krM3kzL2p6TjB6bzVnaDdiK0NVVHZRWTFRT0d3d1pveCthZ0JP?= =?utf-8?B?bWMreitRYmVwWVJXNDRNeC8vcVVELzlDWXlwc29iOWlwclFnbXlxeHNOdTdK?= =?utf-8?B?b2M2TWFmTHJoblNOa1RKcHFKaEFpamluVnZaSndUZStQM3h3QkxsTnEwejFO?= =?utf-8?B?WDBDYUlLVWtZUUlEbVQxQUVTQkthRzEvMVlKNjJOVm00eTZqVzFGS1UranRG?= =?utf-8?B?aGVvUUUxNCtVNFJnVGRha0c2b05OYnIrWURxNlB0ZnJlNXp6MmRMSlhWYnVL?= =?utf-8?B?VEdjNGEwUU1MQXFudDhOcU1JRHRKNDF3QVA1VFZXU1N3Unh6R3V6RkZVQ0ZT?= =?utf-8?B?SXFyODZMM24xV0lCb2t5YWRvUCtuSzVIK2xsUDBuclZIZGlBSzlkb0M0bkRH?= =?utf-8?B?Uk16T0FSMHhBSGFjTkQ4U1V2V0c1czJxdXYzZmVkRHF0ODlOZkZJaHFNQzNB?= =?utf-8?B?NmRNSzdaTlNDam8yZUV2cWtYb1NNTnJxcWNib015K0xTMnovc3dETmhMVzRw?= =?utf-8?B?SzI4R3l6SE1VQkFWbGUyQ0xvT1pvTm5MdExrdnRrMVNIbzJRaXJYbDhEQW1y?= =?utf-8?B?aHBKbFIzTk5MS2ZSaDdNWlU0TEZ3NXFXMU8wLzV5Nk9iMitCRkoyMmpqeHFR?= =?utf-8?B?OGNoUTJCdnY3MVhsU2VLQTZtTWdrTDEvNFBGRXllcWcvVzA2NzB6elhmc2xo?= =?utf-8?B?OXozQzh5aFhSS2o3UVBBejBmOUdRTGtuenp2SG85YXVBbitFMXdkd3JpQjR0?= =?utf-8?B?S2pRRVNsL2l1dGFQRUp4RU9HSUFNWmJzNXJWREZSb2tYdm9qTFRtZnRZVW9T?= =?utf-8?B?UVlPenpoczIweVorTjhocjF0dEJqK1dyZ2swM3l2amtDZTNxODU1ckVmNjJi?= =?utf-8?B?dWhnTHYySlRoTGdnUXNDWGdCYm85NDY4b2w5QjljMlBKM0J2WVF5Z2VwMWVO?= =?utf-8?Q?dSMRHaSlPsdNK?= x-microsoft-antispam-prvs: x-forefront-prvs: 0967749BC1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(136003)(396003)(376002)(366004)(39860400002)(346002)(189003)(199004)(13464003)(14454004)(33656002)(966005)(68736007)(478600001)(6506007)(3846002)(6116002)(53546011)(66066001)(229853002)(76176011)(99286004)(2501003)(7696005)(6436002)(97736004)(25786009)(6246003)(6306002)(55016002)(476003)(53936002)(446003)(9686003)(102836004)(105586002)(486006)(106356001)(8676002)(2906002)(305945005)(86362001)(71190400001)(71200400001)(26005)(81166006)(186003)(14444005)(8936002)(7736002)(316002)(2201001)(11346002)(110136005)(5660300002)(52536013)(81156014)(74316002)(19627235002)(256004); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB4182; H:BYAPR05MB5029.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: IhYnOr/4mUTct6g4Ap3JjEkn6/6oHrxK3p2M85URf1cHhoJPYIV9gW0XY+Yu53J8wzLy5bEHsQat4WASj4sepfOqJSeiTokJQ6cKG1NUvgCju+lwk07MU2KovQ71JbQ9ahxxKn78wbcIheRQ0mBEW23aF+C3hOhH3hoF2wHilcgwOCCgPJTB3YvJHdbPmHaFS3DLbRMoEN3ySbyZaP+lxI03c/bm8HCs730zx1yuFRJFjPSdqkQD7V5qKdRJFgwhmt+MifQSCqdXgCE1ATwwxZCa9K4iAu7Fw0+5D8LZOG9h7V6jnFf3VsDwfxvpepRiZm7KTxV+a3D1e54+5wr+OG+gBj6RRiIay2HsTdVXDynYM3k57vZS38TKFHyImHvpXo/ll6CMlTJ/aYO0VUDMm18NDZEuljTZBZ+AjMajjyo= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: a16bf495-50ae-433e-8d41-08d6a1811350 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2019 15:41:46.5102 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB4182 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-05_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903050103 Archived-At: Subject: Re: [Lsr] Open issues with Dynamic Flooding X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 15:41:58 -0000 SSBhZ3JlZSB3LyBQZXRlci4NCg0KWW91cnMgSXJyZXNwZWN0aXZlbHksDQoNCkpvaG4NCg0KPiAt LS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBMc3IgPGxzci1ib3VuY2VzQGlldGYu b3JnPiBPbiBCZWhhbGYgT2YgUGV0ZXIgUHNlbmFrDQo+IFNlbnQ6IFR1ZXNkYXksIE1hcmNoIDUs IDIwMTkgMjozOCBBTQ0KPiBUbzogdG9ueS5saUB0b255LmxpOyBsc3JAaWV0Zi5vcmcNCj4gU3Vi amVjdDogUmU6IFtMc3JdIE9wZW4gaXNzdWVzIHdpdGggRHluYW1pYyBGbG9vZGluZw0KPiANCj4g SGkgVG9ueSwNCj4gDQo+IE9uIDA0LzAzLzIwMTkgMTg6NTQgLCB0b255LmxpQHRvbnkubGkgd3Jv dGU6DQo+ID4NCj4gPiBIZWxsbywNCj4gPg0KPiA+IFRoZXJlIGFyZSBzdGlsbCB0d28gaXNzdWVz IHRoYXQgbmVlZCB0byBiZSBkaXNjdXNzZWQgYW5kIEkgd2FzIGhvcGluZyB0aGF0IHdlDQo+IGNv dWxkIG1ha2UgcHJvZ3Jlc3Mgb24gdGhlIG1haWxpbmcgbGlzdCBiZWZvcmUgUHJhZ3VlLg0KPiA+ DQo+ID4gMSkgVGVtcG9yYXJ5IGFkZGl0aW9ucyB0byB0aGUgZmxvb2RpbmcgdG9wb2xvZ3kNCj4g Pg0KPiA+ICAgICBUaGVyZSBhcmUgc2V2ZXJhbCBjYXNlcyB3aGVyZSB3ZSB3b3VsZCBsaWtlIHRv IG1ha2UgdGVtcG9yYXJ5IGFkZGl0aW9ucw0KPiB0byB0aGUgZmxvb2RpbmcgdG9wb2xvZ3k6IHJl cGFpcmluZyBhIHBhcnRpdGlvbiBvZiB0aGUgZmxvb2RpbmcgdG9wb2xvZ3kgb3INCj4gYWRkaW5n IGEgbm9kZSB0byB0aGUgYmFzZSB0b3BvbG9neSBmb3IgdGhlIGZpcnN0IHRpbWUuIFdlIGNhbjoN Cj4gPg0KPiA+ICAgICAoYSkgVGVtcG9yYXJpbHkgYWRkIGFsbCBvZiB0aGUgbGlua3MgdGhhdCB3 b3VsZCBhcHBlYXIgdG8gcmVtZWR5IHRoZQ0KPiBwYXJ0aXRpb24uIFRoaXMgaGFzIHRoZSBhZHZh bnRhZ2UgdGhhdCBpdCBpcyB2ZXJ5IGxpa2VseSB0byBoZWFsIHRoZSBwYXJ0aXRpb24gYW5kIHdp bGwNCj4gZG8gc28gaW4gdGhlIG1pbmltYWwgYW1vdW50IG9mIGNvbnZlcmdlbmNlIHRpbWUuDQo+ ID4NCj4gPiAgICAgKGIpIEZvciBlYWNoIG5vZGUgYWRqYWNlbnQgdG8gdGhlIHBhcnRpdGlvbiwg YWRkIG5vIG1vcmUgdGhhbiBhIHNpbmdsZSBsaW5rDQo+IGFjcm9zcyB0aGUgcGFydGl0aW9uLiAg SWYgdGhhdCBkb2VzIG5vdCByZXBhaXIgdGhlIHBhcnRpdGlvbiBpbiBhIHdoaWxlIChMU1ANCj4g cHJvcGFnYXRpb24gdGltZSArIFNQRiB0aW1lKSwgdGhlbiBhZGQgYW5vdGhlciBsaW5rLg0KPiA+ ICAgICAgICAgIEl0ZXJhdGUgYXMgbmVjZXNzYXJ5LiBUaGlzIGhhcyB0aGUgYWR2YW50YWdlIHRo YXQgaXQgbWluaW1pemVzIHRoZSByaXNrIG9mDQo+IGNyZWF0aW5nIGEgY2FzY2FkZSBmYWlsdXJl Lg0KPiANCj4gSSBwcmVmZXIgKGEpIGJlY2F1c2Ugb2YgdGhlIGZhc3RlciBjb252ZXJnZW5jZS4N Cj4gQWRkaW5nIGFsbCBsaW5rcyBvbiBhIHNpbmdsZSBub2RlIHRvIHRoZSBmbG9vZGluZyB0b3Bv bG9neSBpcyBub3QgZ29pbmcgdG8gY2F1c2UNCj4gaXNzdWVzIHRvIGZsb29kaW5nIElNSE8uDQo+ IA0KPiA+DQo+ID4gMikgSW5jbHVzaW9uIG9mIHBzZWR1b25vZGVzIGluIHRoZSBTeXN0ZW0gSURz IFRMVg0KPiA+DQo+ID4gICAgIEluIHRoZSBnZW5lcmFsIGNhc2UsIGEgdG9wb2xvZ3kgY2FuIGlu Y2x1ZGUgTEFOcy4gSWYgYSBMQU4gaXMgaW4gcGFyYWxsZWwgd2l0aCBhDQo+IFAyUCBsaW5rLCB0 aGUgQXJlYSBMZWFkZXIgY2Fubm90IGN1cnJlbnRseSBkaXN0aW5ndWlzaCBiZXR3ZWVuIHRoZSB0 d28gbGlua3MuDQo+IFRoaXMgY2FuIGJlIG9mIGltcG9ydGFuY2UgaWYgdGhlcmUgYXJlIG90aGVy DQo+ID4gICAgIHN5c3RlbXMgYWxzbyBvbiB0aGUgTEFOIHRoYXQgc2hvdWxkIGJlIHVzaW5nIHRo ZWlyIExBTiBpbnRlcmZhY2UgZm9yDQo+IGZsb29kaW5nLg0KPiA+DQo+ID4gICAgIFdlIHByb3Bv c2UgdG8gY2hhbmdlIHRoZSBTeXN0ZW0gSURzIFRMViB0byBpbmNsdWRlIGEgcHNldWRvLW5vZGUg SUQgYXMNCj4gd2VsbCBhcyB0aGUgc3lzdGVtIElELiAgSXQgd291bGQgYWxzbyBtYWtlIHNlbnNl IHRvIHJlbmFtZSB0aGUgVExWIHRvIGJlIHRoZQ0KPiDigJxJUy1JUyBBcmVhIE5vZGUgSURzIFRM VuKAnS4NCj4gPg0KPiA+ICAgICBCZWhhdmlvcmFsbHksIHdlIHNob3VsZCBhZGQgYSByZXF1aXJl bWVudCB0aGF0IGlmIHRoZSBBcmVhIExlYWRlciBpbmNsdWRlcyBhDQo+IHBzZXVkb25vZGUgaW4g dGhlIGZsb29kaW5nIHRvcG9sb2d5LCB0aGVuIGFsbCBzeXN0ZW1zIHdpdGggYW4gYWRqYWNlbmN5 IG9uIHRoYXQNCj4gTEFOIHNob3VsZCB1c2UgdGhlIExBTiBhcyBwYXJ0IG9mIHRoZQ0KPiA+ICAg ICBmbG9vZGluZyB0b3BvbG9neSwgd2hldGhlciBvciBub3QgdGhleSBhcmUgZXhwbGljaXRseSBs aXN0ZWQgYXMgYWRqYWNlbnQgdG8NCj4gdGhlIExBTiBpbiB0aGUgRmxvb2RpbmcgUGF0aCBUTFYu DQo+IA0KPiBnaXZlbiB0aGF0IHRoZSBmbG9vZGluZyBvbiB0aGUgTEFOIGluIGJvdGggT1NQRiBh bmQgSVNJUyBpcyBkb25lIGFzIG11bHRpY2FzdCwNCj4gdGhlcmUgaXMgY3VycmVudGx5IG5vIHdh eSB0byBlbmFibGUgZmxvb2RpbmcsIGVpdGhlciBwZXJtYW5lbnQgb3IgdGVtcG9yYXJ5LA0KPiB0 b3dhcmRzIGEgc3Vic2V0IG9mIHRoZSBuZWlnaGJvcnMgb24gdGhlIExBTi4gU28gaWYgdGhlIGZs b29kaW5nIGlzIGVuYWJsZWQgb24gYQ0KPiBMQU4gaXQgaXMgZG9uZSB0b3dhcmRzIGFsbCByb3V0 ZXJzIGNvbm5lY3RlZCB0byB0aGUgaXQuDQo+IA0KPiBHaXZlbiB0aGF0IGFsbCBsaW5rcyBiZXR3 ZWVuIHJvdXRlcnMgYXJlIHAycCB0aGVzZSBkYXlzLCBJIHdvdWxkIHZvdGUgZm9yDQo+IHNpbXBs aWNpdHkgYW5kIG1ha2UgdGhlIExBTiBhbHdheXMgcGFydCBvZiB0aGUgRlQuDQo+IA0KPiB0aGFu a3MsDQo+IFBldGVyDQo+IA0KPiANCj4gDQo+ID4NCj4gPiBUaG91Z2h0cz8gQ29tbWVudHM/IEZs YW1lcz8NCj4gPg0KPiA+IFJlZ2FyZHMsDQo+ID4gVG9ueQ0KPiA+DQo+ID4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBMc3IgbWFpbGluZyBsaXN0 DQo+ID4gTHNyQGlldGYub3JnDQo+ID4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29t L3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbA0KPiA+IG1hbl9saXN0aW5mb19s c3ImZD1Ed0lHYVEmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstDQo+IG5kYjN2b0RUWGNX em9DDQo+ID4gSSZyPUNSQjJ0SmlRZVBrMGNULWg1TEdoRVdILXNfeFhYdXAzSHp2QlNNUmo1VkUm bT0tDQo+IEU0MTdBTlJmZ0xDaUNnWGF3eGUNCj4gPiBqY0p5eE5YQ09IelZvQU1SQ1FFVDJxVSZz PUxSV21VNlJhMjNaemZpSkYtDQo+IHN6MFlGU1R2UVg1YlU1cWRRazVCS2RoQ1gwJg0KPiA+IGU9 DQo+ID4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IExzciBtYWlsaW5nIGxpc3QNCj4gTHNyQGlldGYub3JnDQo+IGh0dHBzOi8vdXJsZGVm ZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0NCj4gM0FfX3d3dy5pZXRmLm9yZ19t YWlsbWFuX2xpc3RpbmZvX2xzciZkPUR3SUdhUSZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwDQo+IFVq QlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9Q1JCMnRKaVFlUGswY1QtaDVMR2hFV0gtDQo+IHNfeFhY dXAzSHp2QlNNUmo1VkUmbT0tDQo+IEU0MTdBTlJmZ0xDaUNnWGF3eGVqY0p5eE5YQ09IelZvQU1S Q1FFVDJxVSZzPUxSV21VNlJhMjNaemZpSkYtDQo+IHN6MFlGU1R2UVg1YlU1cWRRazVCS2RoQ1gw JmU9DQo= From nobody Tue Mar 5 08:17:03 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1320D130E98 for ; Tue, 5 Mar 2019 08:17:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.018, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 ZSn_tPeCB7wj for ; Tue, 5 Mar 2019 08:16:59 -0800 (PST) Received: from mail-pf1-x431.google.com (mail-pf1-x431.google.com [IPv6:2607:f8b0:4864:20::431]) (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 680A4131100 for ; Tue, 5 Mar 2019 08:16:59 -0800 (PST) Received: by mail-pf1-x431.google.com with SMTP id i20so6061256pfo.6 for ; Tue, 05 Mar 2019 08:16:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=y5FTEpv/bXBjcgMlrbU5+vy/yUXdZWBrWe7RtElkhM4=; b=BXU+a/CXCmThLtFrOhLF85xi2INErOTcYbTJ0TljIHMlA41TtWSuBIEqm7Y4CBbPQn Tm/9e44qiRazm+CWol1jQxlF3rilFC8UErgPZIWG8hblk185zqHLXZbuUmHIIW6qom2W O2/oZ/7eCa5yw/Z6VVWutsIP9AVaigt3b1J3rcZpGBTBzcHtNHcDKfT6j0EuBE+5PjC3 GKy6HbU5Q/mcVz1VyXUzgL855GpCAhTD4C1Qpg8cfbfal66YnSf54x/YaipSbYx/0F6m p3wDDnZkNbmQ9+yjO9zMeQLsIir/sRVe7cpiq1IgYC8WHoeSLvYYO7RyxO912X/pD6cY xFEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=y5FTEpv/bXBjcgMlrbU5+vy/yUXdZWBrWe7RtElkhM4=; b=KEAAFl/zgj5yfyEPOsbZy6rBy23YkOxOohSFVedOlXnPcuraesy0xO+fSMY4tBlAds I1CKyg/ImH3L4pYuSjk3iy0ENy1g7S4ZyVa/ZkCpktwgBNVhXZOWEEutwB6zdD3nYWFz /T94ih28PKIxHsfC3M0VMzrW4k/JHhioyrJ9bXCSAk1mUWd0WC1OkRPVLOBAHMH3gqMj 1BoZxZ+9wpIxf5VjprduHYH8n+L/R4txf9YMD23K486yEM8svPkV2p2XJgto0jaDdsD7 PCiVBwRZmXuPZyagZiw/zsWPY87s+64xZNVQ28gL3g1R1fwS+sFYFvyeU4GoGknxLHtI 0VXA== X-Gm-Message-State: APjAAAWY1bViWw49c/eZnBOhvJm2LxG5RtXXDtenoD9Op8M6ivuxmwBa ujuvsKZlhsaqOYP9IAQHiUA= X-Google-Smtp-Source: APXvYqwZh2AcFHVp3j6j0YJS5CzkKCBl2KqOWhHA0d5LVWtE8kfZgqCANQb8CEoVzsy3Ra38Rda45A== X-Received: by 2002:a62:e082:: with SMTP id d2mr2660013pfm.240.1551802618413; Tue, 05 Mar 2019 08:16:58 -0800 (PST) Received: from [172.22.228.48] ([162.210.130.3]) by smtp.gmail.com with ESMTPSA id p78sm17207532pfa.84.2019.03.05.08.16.57 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Mar 2019 08:16:57 -0800 (PST) Sender: Tony Li Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: tony.li@tony.li In-Reply-To: Date: Tue, 5 Mar 2019 08:16:57 -0800 Cc: lsr@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Peter Psenak X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Lsr] Open issues with Dynamic Flooding X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 16:17:02 -0000 Peter, >> (a) Temporarily add all of the links that would appear to remedy = the partition. This has the advantage that it is very likely to heal the = partition and will do so in the minimal amount of convergence time. >=20 > I prefer (a) because of the faster convergence. > Adding all links on a single node to the flooding topology is not = going to cause issues to flooding IMHO. Could you (or John) please explain your rationale behind that? It seems = counter-intuitive. > given that the flooding on the LAN in both OSPF and ISIS is done as = multicast, there is currently no way to enable flooding, either = permanent or temporary, towards a subset of the neighbors on the LAN. So = if the flooding is enabled on a LAN it is done towards all routers = connected to the it. Agreed. > Given that all links between routers are p2p these days, I would vote = for simplicity and make the LAN always part of the FT. I=E2=80=99m not on board with this yet. Our simulations suggest that = this is not necessarily optimal. There are lots of topologies (e.g., = parallel LANs) where this blanket approach is suboptimal. Tony From nobody Tue Mar 5 08:27:29 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6657813119A for ; Tue, 5 Mar 2019 08:27:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 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 eLaKIHx61Fxk for ; Tue, 5 Mar 2019 08:27:25 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3424513118E for ; Tue, 5 Mar 2019 08:27:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1919; q=dns/txt; s=iport; t=1551803245; x=1553012845; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=EoSA3KzMwW1JT6kZvngL0+edH9Qii3tsNvNY98wbLkg=; b=T05j/Ymnk6E2hTrnSFxmxfAA6jzGNTypgRgqwweF69UkR7FAerwf/hQ9 Iad+PtWb9jgbH/8pltnujP/b3Mhm/OnsSDQn5FqHk2C91o+TMdtJUtyYv 9IAJuWZUpTc06OF9tBQnm9v3PNTq1krhICBGIW/LBmElTIUMPRqR5Ow9/ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AOAACoon5c/xbLJq1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVAEBAQEBAQsBg2gSJ4QIiHmMUyWaHA2EbAKETjcGDQE?= =?us-ascii?q?BAwEBAwEDAm0cDIVKAQEBAwEjDwEFQRALGAICJgICVxMGAgEBgx6BbgiqU4E?= =?us-ascii?q?vhUSEa4ELJAGLPoFAP4ERJwyCMS6EWnSCPYJXAopCmUUJkm4GGYF0hWSDIog?= =?us-ascii?q?tnTKBXSKBVjMaCBsVgyeJPocOPgMwjkgqgiMBAQ?= X-IronPort-AV: E=Sophos;i="5.58,444,1544486400"; d="scan'208";a="10502399" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Mar 2019 16:27:22 +0000 Received: from [10.147.24.27] ([10.147.24.27]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id x25GRMsI019728; Tue, 5 Mar 2019 16:27:22 GMT To: tony.li@tony.li References: Cc: lsr@ietf.org From: Peter Psenak Message-ID: Date: Tue, 5 Mar 2019 17:27:22 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Outbound-SMTP-Client: 10.147.24.27, [10.147.24.27] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Lsr] Open issues with Dynamic Flooding X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 16:27:28 -0000 Hi Tony, On 05/03/2019 17:16 , tony.li@tony.li wrote: > > Peter, > >>> (a) Temporarily add all of the links that would appear to remedy the partition. This has the advantage that it is very likely to heal the partition and will do so in the minimal amount of convergence time. >> >> I prefer (a) because of the faster convergence. >> Adding all links on a single node to the flooding topology is not going to cause issues to flooding IMHO. > > > Could you (or John) please explain your rationale behind that? It seems counter-intuitive. it's limited to the links on a single node. From all the practical purposes I don't expect single node to have thousands of adjacencies, at least not in the DC topologies for which the dynamic flooding is being primary invented. In the environments with large number of adjacencies (e.g. hub-and-spoke) it is likely that we would have to make all these links part of the flooding topology anyway, because the spoke is typically dual attached to two hubs only. And the incremental adjacency bringup is something that an implementation may already support. > > > >> given that the flooding on the LAN in both OSPF and ISIS is done as multicast, there is currently no way to enable flooding, either permanent or temporary, towards a subset of the neighbors on the LAN. So if the flooding is enabled on a LAN it is done towards all routers connected to the it. > > > Agreed. > > >> Given that all links between routers are p2p these days, I would vote for simplicity and make the LAN always part of the FT. > > > I’m not on board with this yet. Our simulations suggest that this is not necessarily optimal. There are lots of topologies (e.g., parallel LANs) where this blanket approach is suboptimal. the question is how much are true LANs used as transit links in today's networks. thanks, Peter > > Tony > > . > From nobody Tue Mar 5 08:28:51 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 83A8F1311A9; Tue, 5 Mar 2019 08:28:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.701 X-Spam-Level: X-Spam-Status: No, score=-1.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.onmicrosoft.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 W5hn70g5GC52; Tue, 5 Mar 2019 08:28:47 -0800 (PST) Received: from mail1.bemta26.messagelabs.com (mail1.bemta26.messagelabs.com [85.158.142.2]) (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 8DB411311B9; Tue, 5 Mar 2019 08:28:40 -0800 (PST) Received: from [85.158.142.103] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-2.bemta.az-a.eu-central-1.aws.symcld.net id 67/33-29523-6B3AE7C5; Tue, 05 Mar 2019 16:28:38 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WSe0hTURzHPbv3brf0xnVa/loWtEp6bWhaTaj or7CiEnqR+OhOr9tgTttmzQpRgwKrVUwkbb6mlqnhgyjJVSI9DbQsMrTMx3o4KSHFFCO6dyd7 /HP4nt/383ucw48m5O1SBc3brLzZxBmV0rlk1Kqp5apbldnx4aea/TV9JS5S88RTQ2laWs9IN Y+fz6CtZEzBTBMVU1U1LYmVxFEGkzbddpjS2xvzZBnecNvrlncoB3lX5qO5NMm6CBjpcsvEi5 y1S6DbcUmKL/0IvLfrJPloDi1lN0Nz3TupqIPZ5VDac44UIYK9i6DpXB8SjSB2HRRO/KAwFAl fO3tlWG+DwdwLvkKkkJxbfdrHMGwCfKm7gXA3hwTq2oZ80Byh2/V7Hb6iiF0A3zvqfXGCDYFe T5lPA8tClbuLwHo+jAz/pDCvhfcfKhCOL4XL/U4Z1ouhu+ysEKcFvQsevdqE5TK4+TlBHAHYY eEtH92/kdXgnjDiTAVUdE3IMDM9D15Un6ewYYT8hgES86EwNsuUSmGy3uv7LDmbDE+c4yTml0 Dt+UESQ88JuFTwhrqI1hT/8zSs10J56zcp1mvgasUoUez7r0B4WuQhyxFZizRas0Gnt6ZxBqM qIjxcFRERqVqnWr9RzR1XcWo+U5XMm6xmTjDV3DGL2pKVlmxMUZt4azMSdijliCS6BTVW69rR QlqinM/Y87Pj5fO06SlZes6iTzJnGnlLOwqlaSUwNpfgBZp5HW9LNRiFRZy1gQ5QBjNu0WYsG VyaxaDDVgeKpttcgyUEbW/6KJxFRZ9KCDlpSjfxihBmmbC7clZM0Gea/pSbXe1utFgRxCA/Pz 95QAZvTjNY//e9KIRGyiAmS2wbYDBZ/3T1CgNJhIHGX54QB7Jyfy1FDop5sG/L2B7PZE3nIVl hhXJvVHrz9iPXloblObX1BYWPNzku7jgY+yyAcr2vn3IvKnzLKHTOnY4NiYMP7ye1ahIfDlQe YIPb+u447f6hqZGZJ8P0/Vm228MNQ0Onv+5OTbjS0Qk1cfurH9SOHXUtWsmscHiOFrf0BB2Oy p6Mdg2MditJi56LWE2YLdwvtqEIm9UDAAA= X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-33.tower-228.messagelabs.com!1551803314!2971729!1 X-Originating-IP: [52.41.248.36] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.31.5; banners=ecitele.com,-,- X-VirusChecked: Checked Received: (qmail 30223 invoked from network); 5 Mar 2019 16:28:37 -0000 Received: from us-west-2a.mta.dlp.protect.symantec.com (HELO EUR03-AM5-obe.outbound.protection.outlook.com) (52.41.248.36) by server-33.tower-228.messagelabs.com with AES256-SHA256 encrypted SMTP; 5 Mar 2019 16:28:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=dqnrJYx8MaM7EbeQfQSx9fxFyXPDEMxtH45q/YLMLVs=; b=eh3/U/5u7osTLNnOAqhyrdwKj14Ut64youkxatQ84c/QAwH7aftWyVOlU0jiNU3CMSACcOH13dJYooi6ZdyMybEhgXq/J8q2JTJEEckR+016XMTxvvMlI3ozipgfGMGvcgRX8/Y4Ekcom8TVaBTDa0mMo8ZByK80oltCVLGEwFs= Received: from VI1PR03MB3839.eurprd03.prod.outlook.com (20.177.54.23) by VI1PR03MB4941.eurprd03.prod.outlook.com (20.178.15.216) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.19; Tue, 5 Mar 2019 16:28:32 +0000 Received: from VI1PR03MB3839.eurprd03.prod.outlook.com ([fe80::4531:64c5:83dc:4252]) by VI1PR03MB3839.eurprd03.prod.outlook.com ([fe80::4531:64c5:83dc:4252%2]) with mapi id 15.20.1665.020; Tue, 5 Mar 2019 16:28:32 +0000 From: Alexander Vainshtein To: Peter Psenak CC: "lsr@ietf.org" , "spring@ietf.org" , "draft-ietf-isis-segment-routing-extensions.all@ietf.org" Thread-Topic: [spring] FlexAlgo and Global Adj-SIDs Thread-Index: AdTPjdP9QRfJ5GzARfmqN1/BpEhW0gAEem2AAGBozJQAkaz8AAABfrsg Date: Tue, 5 Mar 2019 16:28:32 +0000 Message-ID: References: <20493a62-cf70-a182-900d-e55dd68f5149@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.241.1] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: ebeb42d8-5525-499a-a9e6-08d6a1879bc9 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7153060)(7193020); SRVR:VI1PR03MB4941; x-ms-traffictypediagnostic: VI1PR03MB4941: x-ms-exchange-purlcount: 3 x-microsoft-exchange-diagnostics: =?us-ascii?Q?1; VI1PR03MB4941; 23:27BcZxpctFvLGwm6YtFWPQM226QcJVkOcaSrylhEY?= =?us-ascii?Q?1RedPXcD1z7yzwEdNUU4IPl0ZmR54ab2hATW2BIUpsEzlkVi0EWdZMzQC46g?= =?us-ascii?Q?PNnt42eZnqXew+Q8nlZynuD3yaXh4ZCnil7FNNmdQErcohH/sB/3FIWjHkAH?= =?us-ascii?Q?0bHsIBAtYaCxE8j+IVlFl1CUDqIOAOmsXx4hdAYc53RMVzUZQnoUevISRMdS?= =?us-ascii?Q?vXkZsY4R9Oj21utnqVVBO3vkY7bJXQM8en+TDA76OpprlVzljd+iddoO5ugD?= =?us-ascii?Q?NnUk76ORCelOTMXkvhKXYYdzb6pTWfuSHYqhMByguQOVFQe2a8Fk9q+FbvtX?= =?us-ascii?Q?2UQjzxAcA4KF0wCNkwL0acrnzf+U9lC0l7NPZUtuCXHs/G+rwhRt0qKX8cBZ?= =?us-ascii?Q?RjtAz4LOqVBrekYbewj2Wyx/Ni5P318GIm/7V/4FzfQPXX0QmUal4Nn92xD6?= =?us-ascii?Q?fRkCU/E+HldM75r3d81Ti8kLahqoal8PaqQCVUG8eemzVPJHEGgUOzyV1mSE?= =?us-ascii?Q?pVAvUWYJ1yGN3U2c/h3KL1iXDeHE1/XKV7jzR2EP71uGnrRkIm40qHeKDZwQ?= =?us-ascii?Q?f8KY5TVnNOsXDP2tVmFtpf8Ae8bWB8y+HD4/WM4IUywlGWGLQVpkp7rAc5gD?= =?us-ascii?Q?gAgTNFabm2qGY1aEAKjh673V5f4KLJInPwvhjNCKb/KKCkOzgmuISjtR3vFV?= =?us-ascii?Q?gMFj0HPNmjG9X416tPqqvXHHBblLwtWP4hjJ8lWmvNgek0QlqLbxMiaQN+he?= =?us-ascii?Q?RYVnNJKx0SVAoNFPdckhzaHvvZ9LAkePjWmK6dat7XoavdrfXjXlsKP4wAxU?= =?us-ascii?Q?9+C7laYNdmUVRaA0jP6HeIVjfcSvJm2C1JpvLqQ2Uol1GlgKvzKtAkG1f8yi?= =?us-ascii?Q?Y9DM/c+95uh2UlJWzILHLp5AyfvNILlMyJijhywK/8L7dl/OhvDkmu+nH6ro?= =?us-ascii?Q?HvjSgF7qKoCiFK7SYQd872r+YYKx9wGs6ZPjTS6sMcxjK1ZwH1+c6IHRG9W/?= =?us-ascii?Q?ka3lQMlvrZJbH8b8pGjIpSi93vIhALhxeJCZDi1YuVnNRUKItbEH2fkaBxXH?= =?us-ascii?Q?Xno2/oGtGKZnuvcRYuJAN2c4GRuVM35HaGXgh7Q93EodXUtvjViC43bByLAC?= =?us-ascii?Q?WF4kLkAxE3OHXJgnfjoS5VQjL51+UBFQZu76wo9fa5dDxZoxX+Ulc1B+eNEu?= =?us-ascii?Q?Z3ISO54upQmPo9duqQexBGPvPhRaW4bXGDRXvIYNyxXyJTmohye/k63vkkwC?= =?us-ascii?Q?h+bEzTcGjL1ZGROjyzX3b2naCmthhLWx262dOrbXUEut6Z8qMKoYfzWdMhOG?= =?us-ascii?Q?KKYFhIB4VXzxKSQ2iG0FNLQzDHzWqTR3KCrv/ODT4AnQWai5L1bGVMsn/nm/?= =?us-ascii?Q?aMrRHOtIdo6QRNOXdmlLiiZxUCZcsiF4IuWbFTRGOin1EtBloTdmTrXzSK+F?= =?us-ascii?Q?v+t29jCYQ=3D=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 0967749BC1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(366004)(346002)(376002)(136003)(396003)(199004)(189003)(13464003)(54094003)(51874003)(86362001)(478600001)(5660300002)(66066001)(68736007)(6246003)(8676002)(33656002)(305945005)(7696005)(81166006)(76176011)(14454004)(6916009)(81156014)(102836004)(53546011)(99286004)(6506007)(25786009)(72206003)(186003)(966005)(4326008)(229853002)(52536013)(93886005)(105586002)(6116002)(106356001)(71200400001)(71190400001)(316002)(3846002)(476003)(74316002)(6436002)(5024004)(11346002)(2906002)(97736004)(54906003)(7736002)(14444005)(8936002)(53936002)(256004)(55016002)(6306002)(9686003)(486006)(26005)(446003); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR03MB4941; H:VI1PR03MB3839.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: cFsfKxCMgnslZ6GiBX6rjTq+9wkLsXKoGe/09LxVAv0NFwvFTsiXI1840zCFZwPuMkcUmQ+WSixWblPrrjn7qcERP/qJ2Aezy4ikupOSBuQNLxW79se7oUDaO5odr51Ysuoc3EV8DrgOcxvs+086IXE0n81exVGSjRg3tSYtYNIEBO16WjEU4JBofa6EwyPJWZ3+XfHtw+wzyf2c6tHzu2hlWVF7DUZEnOXYSZoRMKQC5fh1Kz03fdcMPpetUA2n+OLr6J/QRqg6o/eqV1eeQPJIVhA0FVtNz33bG4Jv+gOYh6lOCVnkWUBp0BmOdd3+T/Q/fRe4mnrZHaWOc7/emuXaELeDxVTl8+L87HS1jZUoY1wasATBPa34BEHqJKI1a1rf6u2PcbqKHGaA9p+lgW+fxEmSWJvhu/s7/42OUrU= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-Network-Message-Id: ebeb42d8-5525-499a-a9e6-08d6a1879bc9 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2019 16:28:32.5285 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB4941 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Lsr] [spring] FlexAlgo and Global Adj-SIDs X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 16:28:49 -0000 Peter, Lots of thanks for a prompt and very encouraging response. Do you think that the new Algo specific Adj-SID sub-TLV could be added to = the current IS-IS segment Routing Extensions draft, or should be handled i= n a small dedicated document? Regards, and lots of thanks in advance, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com -----Original Message----- From: Peter Psenak =20 Sent: Tuesday, March 5, 2019 5:28 PM To: Alexander Vainshtein Cc: lsr@ietf.org; spring@ietf.org; draft-ietf-isis-segment-routing-extensi= ons.all@ietf.org Subject: Re: [spring] FlexAlgo and Global Adj-SIDs Hi Sasha, On 02/03/2019 18:57 , Alexander Vainshtein wrote: > Peter, > Lots of thanks for a prompt and hivhly informative response. > > It seems that per-FlexAlgo Adj-SIDs can be useful even if they are local= . > The relevant use case could be a protected local Adj-SID that is used=20= > in a SR-TE LSP that has been set up with some=20constraints in mind.=20 > These constraints would be preserved when the protected adjacency in=20 > question is UP, but could be violated when it fails and the shortest=20 > path to the node at the remote end of adjacency is used. yes, this is a possible use case. This would require a new Algo specific A= dj-SID sub-TLV to be defined. This could be done. thanks, Peter > > Local protected Adj-SIDs for sure have bern implemented, so this looks=20= > like a more relevant use case than global adjacencies to me. > > What do you think? > > Regards, and lots of thanks in advance, > > Thumb typed by Sasha Vainshtein > > ---------------------------------------------------------------------- > -- > *From:* Peter Psenak > *Sent:* Thursday, February 28, 2019 9:56:49 PM > *To:* Alexander Vainshtein; > draft-ietf-isis-segment-routing-extensions@ietf.org > *Cc:* lsr@ietf.org; spring@ietf.org > *Subject:* Re: [spring] FlexAlgo and Global Adj-SIDs > > Hi Alexander, > > On 28/02/2019 19:19 , Alexander Vainshtein wrote: >> Dear colleagues, >> >> I have a question regarding global Adj-SIDs in=20 >> draft-ietf-isis-segment-routing-extensions. >> >> >> >> Section 3.4 of RFC 8402 =20 >> defines definition and handling of global Adj-SIDs. >> >> The relevant text is given below: >> >> >> >> >> >> Similarly, when using a global Adj-SID, a packet injected anywhere >> >> within the SR domain with a segment list {SNL}, where SNL is a=20 >> global >> >> Adj-SID attached by node N to its adjacency over link L, will be >> >> forwarded along the shortest path to Nand then be switched by N, >> >> without any IP shortest-path consideration, towards link L. >> >> ... >> >> The use of global Adj-SID allows to reduce the size of the segment=20= >> list >> >> When expressing a path at the cost of additional state (i.e., the=20= >> global >> >> Adj-SID will be inserted by all routers within the area in their >> >> forwarding table). >> >> >> >> >> >> The definition of the Adjacency Segment Identifier Sub-TLV in Section >> 2.2.1 of the draft matches the behavior defined in RFC 8402, i.e., it=20= >> allows advertisement of global Adj-SIDs. >> >> These advertisements can be associated with a specific IGP adjacency=20= >> and, in multi-topology scenarios, a specific topology. But it is not=20= >> associated with any specific algorithm since the default algorithm=20 >> for reaching the advertising node is implicitly assumed in full=20 >> alignment with RFC 8402. >> >> >> >> My question is about the situation in which multiple algorithms are=20 >> supported by the routers in the SR domain, so that each node=20 >> advertises a dedicated Node SID for each of these algorithm. >> >> In this scenario, the operator can set up a SR-TE LSP that meets=20 >> specific constraints (incorporated in one of these algorithms, see=20 >> IGP Flexible Algorithm=20 >> draft) by=20 >> using Node SIDs that have been advertised with the corresponding=20 >> algorithm and local Adj-SIDs. However, global Adj-SIDs cannot be used=20= >> (e.g., for reducing the label stack depth) in this situation. >> >> I wonder if the possibility to advertise global Adj-SID (that can be=20= >> considered as replacing a combination of the Node SID of the=20 >> advertising node and one of its local Adj-SIDs) as associated with a=20= >> specific algorithm has ever been considered? > > to be honest, it has been not. > > The usage of the global Adj-SID has not been widely considered due to=20= > the additional forwarding entries it requires on rest of the routers=20 > in the area. Not sure if there are implementations of the global=20 > ADj-SID out there. > > If you believe this is important, we can certainly addressed that in a=20= > small draft. > > thanks, > Peter > > > > >> >> >> >> Regards, and lots of thanks in advance, >> >> Sasha >> >> >> >> Office: +972-39266302 >> >> Cell: +972-549266302 >> >> Email: Alexander.Vainshtein@ecitele.com >> >> >> >> >> _____________________________________________________________________ >> ______ >> >> This e-mail message is intended for the recipient only and contains=20 >> information which is CONFIDENTIAL and which may be proprietary to ECI=20= >> Telecom. If you have received this transmission in error, please=20 >> inform us by e-mail, phone or fax, and then delete the original and=20 >> all copies thereof. >> _____________________________________________________________________ >> ______ >> >> >> _______________________________________________ >> spring mailing list >> spring@ietf.org >> https://www.ietf.org/mailman/listinfo/spring >> > > > ______________________________________________________________________ > _____ > > This e-mail message is intended for the recipient only and contains=20 > information which is CONFIDENTIAL and which may be proprietary to ECI=20= > Telecom. If you have received this transmission in error, please=20 > inform us by e-mail, phone or fax, and then delete the original and=20 > all copies thereof. > ______________________________________________________________________ > _____ __________________________________________________________________________= _ This e-mail message is intended for the recipient only and contains inform= ation which is=20 CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this=20 transmission in error, please inform us by e-mail, phone or fax, and then = delete the original=20 and all copies thereof. __________________________________________________________________________= _ From nobody Tue Mar 5 08:31:33 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03AB3129BBF; Tue, 5 Mar 2019 08:31:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 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 TpoI-SQto6ze; Tue, 5 Mar 2019 08:31:28 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C20F9128B36; Tue, 5 Mar 2019 08:31:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7245; q=dns/txt; s=iport; t=1551803488; x=1553013088; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=+KOOPhpPkMQr/+QbgcsVqkafxr8r3OZsmfW7GgG4JVs=; b=TIeOiH5s6qaCLWdjQbmEsptGRnnvr3MyORpcEuhNyk0u2DqF/PWiTGAn qish/3Oo9123mNyql2hE2BUYLccURCjapURr6wxPZIXz4YYqtSV2F01QR 1m9vqtiQrsXg7iWgcW7xCEgDNanEs+55SCRZM1iATcl3Nd/PeoR3uIC1r s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AOAAARpH5c/xbLJq1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVAEBAQEBAQsBgndxEieNAYx4mDWBZw0YC4QDRgKETjc?= =?us-ascii?q?GDQEBAwEBAwEDAm0cDIVKAQEBAwEBATY2CwUHAgILEQQBAQEuFhEoCAYNBgI?= =?us-ascii?q?BAYMeAYFtCA+sAIQzAoEPhGYFBYEqAYs+gUA/gRAogmuDHgEBA4EmBQESAUU?= =?us-ascii?q?GhTUCiXgZA4ceklUJh0OBGooRBhmBdIVkgyKILZBBjHGBXSJlcTMaCBsVO4J?= =?us-ascii?q?sghYXiF+FQD4DMI5Xgj4BAQ?= X-IronPort-AV: E=Sophos;i="5.58,444,1544486400"; d="scan'208";a="10561019" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Mar 2019 16:31:09 +0000 Received: from [10.147.24.27] ([10.147.24.27]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id x25GV9Hq014240; Tue, 5 Mar 2019 16:31:09 GMT To: Alexander Vainshtein References: <20493a62-cf70-a182-900d-e55dd68f5149@cisco.com> Cc: "lsr@ietf.org" , "spring@ietf.org" , "draft-ietf-isis-segment-routing-extensions.all@ietf.org" From: Peter Psenak Message-ID: <124b65c8-daf3-c1ce-c975-d5ee53846f41@cisco.com> Date: Tue, 5 Mar 2019 17:31:09 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Outbound-SMTP-Client: 10.147.24.27, [10.147.24.27] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Lsr] [spring] FlexAlgo and Global Adj-SIDs X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 16:31:31 -0000 Hi Sasha, On 05/03/2019 17:28 , Alexander Vainshtein wrote: > Peter, > Lots of thanks for a prompt and very encouraging response. > > Do you think that the new Algo specific Adj-SID sub-TLV could be added to the current IS-IS segment Routing Extensions draft, or should be handled in a small dedicated document? it would have to be a new draft, existing ISIS SR draft is on its way to become an RFC and we do not want to return it back to the WG due to this. thanks, Peter > > Regards, and lots of thanks in advance, > Sasha > > Office: +972-39266302 > Cell: +972-549266302 > Email: Alexander.Vainshtein@ecitele.com > > -----Original Message----- > From: Peter Psenak > Sent: Tuesday, March 5, 2019 5:28 PM > To: Alexander Vainshtein > Cc: lsr@ietf.org; spring@ietf.org; draft-ietf-isis-segment-routing-extensions.all@ietf.org > Subject: Re: [spring] FlexAlgo and Global Adj-SIDs > > Hi Sasha, > > On 02/03/2019 18:57 , Alexander Vainshtein wrote: >> Peter, >> Lots of thanks for a prompt and hivhly informative response. >> >> It seems that per-FlexAlgo Adj-SIDs can be useful even if they are local. >> The relevant use case could be a protected local Adj-SID that is used >> in a SR-TE LSP that has been set up with some constraints in mind. >> These constraints would be preserved when the protected adjacency in >> question is UP, but could be violated when it fails and the shortest >> path to the node at the remote end of adjacency is used. > > yes, this is a possible use case. This would require a new Algo specific Adj-SID sub-TLV to be defined. This could be done. > > thanks, > Peter > > > >> >> Local protected Adj-SIDs for sure have bern implemented, so this looks >> like a more relevant use case than global adjacencies to me. >> >> What do you think? >> >> Regards, and lots of thanks in advance, >> >> Thumb typed by Sasha Vainshtein >> >> ---------------------------------------------------------------------- >> -- >> *From:* Peter Psenak >> *Sent:* Thursday, February 28, 2019 9:56:49 PM >> *To:* Alexander Vainshtein; >> draft-ietf-isis-segment-routing-extensions@ietf.org >> *Cc:* lsr@ietf.org; spring@ietf.org >> *Subject:* Re: [spring] FlexAlgo and Global Adj-SIDs >> >> Hi Alexander, >> >> On 28/02/2019 19:19 , Alexander Vainshtein wrote: >>> Dear colleagues, >>> >>> I have a question regarding global Adj-SIDs in >>> draft-ietf-isis-segment-routing-extensions. >>> >>> >>> >>> Section 3.4 of RFC 8402 >>> defines definition and handling of global Adj-SIDs. >>> >>> The relevant text is given below: >>> >>> >>> >>> >>> >>> Similarly, when using a global Adj-SID, a packet injected anywhere >>> >>> within the SR domain with a segment list {SNL}, where SNL is a >>> global >>> >>> Adj-SID attached by node N to its adjacency over link L, will be >>> >>> forwarded along the shortest path to Nand then be switched by N, >>> >>> without any IP shortest-path consideration, towards link L. >>> >>> ... >>> >>> The use of global Adj-SID allows to reduce the size of the segment >>> list >>> >>> When expressing a path at the cost of additional state (i.e., the >>> global >>> >>> Adj-SID will be inserted by all routers within the area in their >>> >>> forwarding table). >>> >>> >>> >>> >>> >>> The definition of the Adjacency Segment Identifier Sub-TLV in Section >>> 2.2.1 of the draft matches the behavior defined in RFC 8402, i.e., it >>> allows advertisement of global Adj-SIDs. >>> >>> These advertisements can be associated with a specific IGP adjacency >>> and, in multi-topology scenarios, a specific topology. But it is not >>> associated with any specific algorithm since the default algorithm >>> for reaching the advertising node is implicitly assumed in full >>> alignment with RFC 8402. >>> >>> >>> >>> My question is about the situation in which multiple algorithms are >>> supported by the routers in the SR domain, so that each node >>> advertises a dedicated Node SID for each of these algorithm. >>> >>> In this scenario, the operator can set up a SR-TE LSP that meets >>> specific constraints (incorporated in one of these algorithms, see >>> IGP Flexible Algorithm >>> draft) by >>> using Node SIDs that have been advertised with the corresponding >>> algorithm and local Adj-SIDs. However, global Adj-SIDs cannot be used >>> (e.g., for reducing the label stack depth) in this situation. >>> >>> I wonder if the possibility to advertise global Adj-SID (that can be >>> considered as replacing a combination of the Node SID of the >>> advertising node and one of its local Adj-SIDs) as associated with a >>> specific algorithm has ever been considered? >> >> to be honest, it has been not. >> >> The usage of the global Adj-SID has not been widely considered due to >> the additional forwarding entries it requires on rest of the routers >> in the area. Not sure if there are implementations of the global >> ADj-SID out there. >> >> If you believe this is important, we can certainly addressed that in a >> small draft. >> >> thanks, >> Peter >> >> >> >> >>> >>> >>> >>> Regards, and lots of thanks in advance, >>> >>> Sasha >>> >>> >>> >>> Office: +972-39266302 >>> >>> Cell: +972-549266302 >>> >>> Email: Alexander.Vainshtein@ecitele.com >>> >>> >>> >>> >>> _____________________________________________________________________ >>> ______ >>> >>> This e-mail message is intended for the recipient only and contains >>> information which is CONFIDENTIAL and which may be proprietary to ECI >>> Telecom. If you have received this transmission in error, please >>> inform us by e-mail, phone or fax, and then delete the original and >>> all copies thereof. >>> _____________________________________________________________________ >>> ______ >>> >>> >>> _______________________________________________ >>> spring mailing list >>> spring@ietf.org >>> https://www.ietf.org/mailman/listinfo/spring >>> >> >> >> ______________________________________________________________________ >> _____ >> >> This e-mail message is intended for the recipient only and contains >> information which is CONFIDENTIAL and which may be proprietary to ECI >> Telecom. If you have received this transmission in error, please >> inform us by e-mail, phone or fax, and then delete the original and >> all copies thereof. >> ______________________________________________________________________ >> _____ > > ___________________________________________________________________________ > > This e-mail message is intended for the recipient only and contains information which is > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this > transmission in error, please inform us by e-mail, phone or fax, and then delete the original > and all copies thereof. > ___________________________________________________________________________ > . > From nobody Tue Mar 5 08:37:50 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41EB71200D8; Tue, 5 Mar 2019 08:37:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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=VPIdZG5r; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=VfjvBpHh 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 6-bC6J_NbuGv; Tue, 5 Mar 2019 08:37:39 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAF28128B36; Tue, 5 Mar 2019 08:37:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2023; q=dns/txt; s=iport; t=1551803849; x=1553013449; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=I2cGn5tdJHdxET8c9YsRtic6bbnSzJkDpbxPSsJBwiY=; b=VPIdZG5rqivvl1YNgy550DT91GZyT9553jrGaf1EEqRuzpqise0sZJxk 5eIO1vS9vrnP/iohrJYJi9AuOKCYH+JT8OsbF8UHS8vqgjoEOAo3nxF3M HNT8WIXNebdOihawOG5a0YSx91MjCoFxCBGG5JfyMsVbkd6vWzrFqbcn9 o=; IronPort-PHdr: =?us-ascii?q?9a23=3ASDKslR/iPKQFP/9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+8ZR7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfk0jgZdYBUER?= =?us-ascii?q?oMiMEYhQslVcGED1bxIeTlRyc7B89FElRi+iLzPA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAAAcpX5c/5NdJa1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgTwkLAOBXAQLJ4dPA4RQiwCCV5ghFIE?= =?us-ascii?q?QA1QLAQEshEAChCwiNAkNAQEDAQEDAQMCbRwMhUoBAQEEOgYBATcBCwICAgE?= =?us-ascii?q?IEQQBAQEeEBYcHQgBAQQBDQUIhHgDFQECn1MCihSCIIJ4AQEFhQYYggsIBYE?= =?us-ascii?q?qAYsnF4FAP4EQR4JMhE4BEgEhBR+DFYImihOZdgkCkwuTJ4plkiYCBAIEBQI?= =?us-ascii?q?NAQEFgUc4ZXFwFYMnggoMF4NLilNygSiNL4I+AQE?= X-IronPort-AV: E=Sophos;i="5.58,444,1544486400"; d="scan'208";a="529342613" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Mar 2019 16:37:27 +0000 Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id x25GbRH7018258 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 5 Mar 2019 16:37:27 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 5 Mar 2019 10:37:26 -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.1473.3; Tue, 5 Mar 2019 11:37:26 -0500 Received: from NAM01-SN1-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.1473.3 via Frontend Transport; Tue, 5 Mar 2019 11:37:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=WH1U9z36nYRWJtCSbYrGLDWtafnONUnkTbXQgR39gwU=; b=VfjvBpHhR+MNgtDgHQ9DawlLfKDVSydYPqzR0w2s9NkFhRBmHYh/UyeIU0UGe+56lPerB6yRUivefyT5UvVGA7fMQqENGHXtfisP/AQ5lD9TkjsDoDmmhOw5swunwddUJp7gKcOaJm5k/ydAoloYfAer4aMCZ0mBOXTCkgESpIE= Received: from BYAPR11MB3638.namprd11.prod.outlook.com (20.178.237.19) by BYAPR11MB2725.namprd11.prod.outlook.com (52.135.227.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.16; Tue, 5 Mar 2019 16:37:24 +0000 Received: from BYAPR11MB3638.namprd11.prod.outlook.com ([fe80::b414:f534:f20a:a26d]) by BYAPR11MB3638.namprd11.prod.outlook.com ([fe80::b414:f534:f20a:a26d%3]) with mapi id 15.20.1686.016; Tue, 5 Mar 2019 16:37:24 +0000 From: "Les Ginsberg (ginsberg)" To: Alexander Vainshtein , "Peter Psenak (ppsenak)" CC: "lsr@ietf.org" , "spring@ietf.org" , "draft-ietf-isis-segment-routing-extensions.all@ietf.org" Thread-Topic: [spring] FlexAlgo and Global Adj-SIDs Thread-Index: AdTPjdP9QRfJ5GzARfmqN1/BpEhW0gAEem2AAGBozJQAkaz8AAABfrsgAAC21FA= Date: Tue, 5 Mar 2019 16:37:24 +0000 Message-ID: References: <20493a62-cf70-a182-900d-e55dd68f5149@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ginsberg@cisco.com; x-originating-ip: [2001:420:30d:1320:a988:c680:96ce:e179] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 360332f1-7c8b-40d6-60f8-08d6a188d8c6 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BYAPR11MB2725; x-ms-traffictypediagnostic: BYAPR11MB2725: x-ld-processed: 5ae1af62-9505-4097-a69a-c1553ef7840e,ExtAddr x-microsoft-exchange-diagnostics: =?us-ascii?Q?1; BYAPR11MB2725; 23:DNdmWPw5uqZwhGEb354ubv59n2z7x/vPuNicJ+ebM?= =?us-ascii?Q?va1OosL+Q9eeWYmNhB7HwJrL9/wmwPidU9B7x53Bm/fG320fBLNdFez5hDem?= =?us-ascii?Q?5fx5IIbnytwfugivCT6O4OvUA0d4NCb7KYGmR2jcqjRClUtzzW2AbKSj9fY2?= =?us-ascii?Q?AdDsjEGTU0jF7RM707xm/8Iz5QQrWwme+tL5p6NR+rQ5pXttol8rRw6ze7J5?= =?us-ascii?Q?IH50vE6UBkW9lzZ0XBjXF4/QTtpyPEq4ZPXjsO6t0kA9wakfkFgebICOiO5b?= =?us-ascii?Q?tACqbWcQxtweytTNGqMz0WMO+Ys6MCxhnulEc6JMq38ZUpQESlCJFPxFxBVZ?= =?us-ascii?Q?2+nEhNQWLg3lEBk6xqd+42J76FFuuMmEiPPjV0Adpo+o+mh9tTdJaG61FXsC?= =?us-ascii?Q?Z7FSqPurIiV+uEIPWvFI8UyyOSpsYxHWdTFTYJy0UWRZA160a1bY7IOoy0yK?= =?us-ascii?Q?5ncVLB6LAw9MbnaA57hxoxpXhl0DnC3k6J2GoP66xAjldT/VZrPO6gFgJO1v?= =?us-ascii?Q?RBCy9OLKw83Kf7rh7NctI2cGT7lwsJKgrp7swZNaz7ZtA3F04Ntdhv6c83ND?= =?us-ascii?Q?9eJOJKBqNwJ3AdkTMxptP7U9ZFveCMujEHz04GEoIF64V31gyDmI3EwdUXuD?= =?us-ascii?Q?9LD9c4rQ4ZpdI5tFotiohCTqhrxaw1k0/8f4yGyfv5apMeGEgs6UbR+rn5ZG?= =?us-ascii?Q?VoKTSN5oodhU6GOcJt2cEIrPpfXK+w1ZnPB4vu7gDvKWa+woy0vHQHskG3rn?= =?us-ascii?Q?zhdxwlhigALiNpMWObI9yvg8xx3VRQuUESP8m9BPGLJNi3rWJmQyrpfTtY4y?= =?us-ascii?Q?dXsd989HwLpYnyNvUzbLL6mTRI3Oh6NdV0Tm/r9NeE1VrrfE4N1v2wc+ENfm?= =?us-ascii?Q?icbQcOAw4jkuowsNPmbQe7/dDz45gsSGAEJhjXlOiRroalBeCd2+admSGw7p?= =?us-ascii?Q?kr3CoYd9UvW/NuADXqdCJgRH6EnyuopyaGdVP46CujU/BXxMSaxzEhSzGReV?= =?us-ascii?Q?tQ8EDxyuf8p2OZbQQ5ZmEa1wcjllQiJ+rYVv6l/yEgyZRVIvpg72uvxcmE57?= =?us-ascii?Q?Yu9UTAOkY7X6AYjpboKQldj5Q6OTzjJ/ZwrWKHnJ6DNnnT5Z+aRAVtPYpUIV?= =?us-ascii?Q?ChEfbGCIXod5b/ydTcgklchlUZfcDnRVCG1uuh9bHo4F2d22v0AqgWMDeR8d?= =?us-ascii?Q?d89kNiUhbcYB+viTANQochse+WSh6faCE9GHeC2cIfL6KxOpn3UpE9VLj/w/?= =?us-ascii?Q?rbtpAduenpUXzr6ggUfQ6L9FRebKfi1duf+xEhY?= x-microsoft-antispam-prvs: x-forefront-prvs: 0967749BC1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(376002)(366004)(136003)(39860400002)(396003)(13464003)(199004)(189003)(51874003)(86362001)(71190400001)(71200400001)(106356001)(8936002)(55016002)(105586002)(186003)(33656002)(53936002)(11346002)(446003)(6436002)(97736004)(486006)(229853002)(99286004)(93886005)(52536013)(6246003)(14454004)(46003)(476003)(8676002)(81166006)(81156014)(6636002)(256004)(6506007)(110136005)(9686003)(5660300002)(53546011)(68736007)(54906003)(316002)(102836004)(74316002)(76176011)(4326008)(305945005)(7736002)(6116002)(2906002)(7696005)(25786009)(478600001); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB2725; H:BYAPR11MB3638.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: eHROPh4AFnvDdGcRmbVDaTxgCui7zFlHhgNrOpFrBo9ZZXZWXrQm4N7zCLxHSLv/KCAU9fegrK/fe1FToQs7cXW4L3ndLfldZJ9+yVVdav24B6ke38sjc37IrKQSa+GCF9ZGSz3Hd0FktdmyLjgYXmUeUn3V0+Tz66ihVxeow8wWSpIqlmrEivEaZ5NSvdcaHBjAcff1MtZHub7NoGAQTdDDeScuHiafKKoP6gbJPogqM/rt2otdsyNgcrKDYMEL8JHD1OJ11lykNt85RsHyFX7flJlJjgAMcDQDjcZ/FlmTah9HhuF5+LiiofsqAHpnvVRzYifk47qhyP5CP7saQeQHrhzUae1ewue1n0oliMqeLw6rFXufRjpcnZOiyzejicyCwJX/K75BGrmBgjUwDtoj0eGv4p6W6vMHlqaDzuo= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 360332f1-7c8b-40d6-60f8-08d6a188d8c6 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2019 16:37:24.2656 (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-Transport-CrossTenantHeadersStamped: BYAPR11MB2725 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.25, xch-rcd-015.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: Re: [Lsr] [spring] FlexAlgo and Global Adj-SIDs X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 16:37:41 -0000 Sasha - draft-ietf-isis-segment-routing-extensions is currently in AD review - and = the companion OSPF document has already been approved and is waiting for a = dependent draft to progress before publication as an RFC. It is too late to make significant changes. Further, while I agree with both your description and Peter's response, agr= eeing that this "could" be done is not equivalent to having consensus that = it "should" be done. I think a more complete consideration of the deployment cases and the usefu= lness of such an extension should be discussed by the WG before we decide t= hat we actually want to define such an extension. Les > -----Original Message----- > From: Alexander Vainshtein > Sent: Tuesday, March 05, 2019 8:29 AM > To: Peter Psenak (ppsenak) > Cc: lsr@ietf.org; spring@ietf.org; draft-ietf-isis-segment-routing- > extensions.all@ietf.org > Subject: RE: [spring] FlexAlgo and Global Adj-SIDs >=20 > Peter, > Lots of thanks for a prompt and very encouraging response. >=20 > Do you think that the new Algo specific Adj-SID sub-TLV could be added to > the current IS-IS segment Routing Extensions draft, or should be handled = in a > small dedicated document? >=20 > Regards, and lots of thanks in advance, > Sasha >=20 > Office: +972-39266302 > Cell: +972-549266302 > Email: Alexander.Vainshtein@ecitele.com >=20 > -----Original Message----- > From: Peter Psenak > Sent: Tuesday, March 5, 2019 5:28 PM > To: Alexander Vainshtein > Cc: lsr@ietf.org; spring@ietf.org; draft-ietf-isis-segment-routing- > extensions.all@ietf.org > Subject: Re: [spring] FlexAlgo and Global Adj-SIDs >=20 > Hi Sasha, >=20 > On 02/03/2019 18:57 , Alexander Vainshtein wrote: > > Peter, > > Lots of thanks for a prompt and hivhly informative response. > > > > It seems that per-FlexAlgo Adj-SIDs can be useful even if they are loca= l From nobody Tue Mar 5 08:42:42 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2A681312BC for ; Tue, 5 Mar 2019 08:42:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 OAFnUaURR3bG for ; Tue, 5 Mar 2019 08:42:37 -0800 (PST) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (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 23B4A131302 for ; Tue, 5 Mar 2019 08:42:37 -0800 (PST) Received: by mail-ed1-x529.google.com with SMTP id g19so7789539edp.2 for ; Tue, 05 Mar 2019 08:42:37 -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=vDgoCoOezd6SWZocvovmNCFMoRADKQ34uz1GSGf0RXI=; b=ot4I3ix1Jlq9ZHrqNAFxSef+sYf2tgzB4Du6BPyB3R266G7Y7cxLtQF7axKTMeSoNa aLl1BZI/KIiHsLSVtpwsqgWDQb9QchkhdXCR12WtjMw/o885OQqFDfvz/NmKAncwzlVK m2R+m9JGuFX+iqa0WwZu24//D6Oq6XEkWTELzMWKYvxd3/EdLLmOESVm6BAxMlW+gJ8A PiHcacgJDmCEF2R6yDmlmviP4SG1IqVoAJ2HjKCwONZ3V5bapfa352nhuAlyjdcdHJar YQGVAMp2cXfZQtUbpss7HfRiw7gxkD7Z94tTvld0G+gxjBjhePAbjYCBaDxGSi8G0ZWj g/Cg== 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=vDgoCoOezd6SWZocvovmNCFMoRADKQ34uz1GSGf0RXI=; b=WxbAKuGn1z3lcGczohX55G5+/SJ/wytVyp1aKiZ2IrNE68WFyUJD2DlvjwzyFMVDpV 13qFfRUAncsO6bZNkBsJsDH6vGJoiH8dLZJHbBHhZueLv0HNHpWXvSJ83NontnEeJn3o pB4v6LhvhZLodFM5Ca/pcNbGw6O+3t9ZVxiDyDQSq4K3yrZOrzOEykdh2o0/TpuW1VMe 1N2OlIOGh6spfTbpwWoDTmmYyIyc8JAsxmTU/tdTSh3tY+i/virKkbtfI0XOFZhYnL6R DCzgToxoKU2RB5z5nRnNYUcHYdoOTFoqOjWmAhJqVPiUv4QIq+aigP197vnsdi+QPgo/ gdKg== X-Gm-Message-State: APjAAAW1Mr6F+ZBPTmkl/gSZZYOBzHz6vkwzetiHZEnQAtjRNc5ElfOs Uc+T8Cus67FYoYeCiDHX+dWHDsXMa+nxIGobBRw= X-Google-Smtp-Source: APXvYqxhhu6u14CYYBLmVQWLKDrRiIHXpG+tr18KUOu5Kb3IubZp6d98gIIzeQymqrq5nNHRuQbwJtCiA2yRoJ/BOAM= X-Received: by 2002:a50:b8e2:: with SMTP id l89mr20578715ede.140.1551804155430; Tue, 05 Mar 2019 08:42:35 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Tony Przygienda Date: Tue, 5 Mar 2019 08:41:59 -0800 Message-ID: To: Peter Psenak Cc: Tony Li , lsr@ietf.org Content-Type: multipart/alternative; boundary="00000000000072099005835b8f8d" Archived-At: Subject: Re: [Lsr] Open issues with Dynamic Flooding X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 16:42:41 -0000 --00000000000072099005835b8f8d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable in practical terms +1 to Peter's take here ... Unless we're talking tons of failures simultaneously (which AFAI talked to folks are not that common but can sometimes happen in DCs BTW due to weird things) smaller scale failures with few links would cause potentially diffused "chaining" of convergence behavior rather than IGP-style fast healing (and on top of that I didn't see a lot of interest in formalizing a rigorous distributed algorithm which IMO would be necessary to ensure ultimate convergence when only one/subset of links is used). Slow convergence is obviously not a good thing unless we assume people will run FRR with its complexity in DC and/or no more than one link every fails which seems to me bending assumptions to whatever solution is available/preferred. To Tony's point though, on large scale failures enabling all links would cause heavy flood load, yes, but in a sense it's the "initial bootup" case anyway (especially in centralized case) since nodes need all topology to make informed correct decisions about what the FT should be if they don't rely on whatever the centralized instance thinks (which they won't be able to do given the FT from centralized instance will indicate lots links that are "gone" due to failure). As to p2p, I suggest to agree whether you use dense mesh (DC) case or sparse mesh (WAN) case or "every topology imaginable" since that drives lots design trade-offs. my 2.71828182 cents ;-) --- tony On Tue, Mar 5, 2019 at 8:27 AM Peter Psenak wrote: > Hi Tony, > > On 05/03/2019 17:16 , tony.li@tony.li wrote: > > > > Peter, > > > >>> (a) Temporarily add all of the links that would appear to remedy > the partition. This has the advantage that it is very likely to heal the > partition and will do so in the minimal amount of convergence time. > >> > >> I prefer (a) because of the faster convergence. > >> Adding all links on a single node to the flooding topology is not goin= g > to cause issues to flooding IMHO. > > > > > > Could you (or John) please explain your rationale behind that? It seems > counter-intuitive. > > it's limited to the links on a single node. From all the practical > purposes I don't expect single node to have thousands of adjacencies, at > least not in the DC topologies for which the dynamic flooding is being > primary invented. > > In the environments with large number of adjacencies (e.g. > hub-and-spoke) it is likely that we would have to make all these links > part of the flooding topology anyway, because the spoke is typically > dual attached to two hubs only. And the incremental adjacency bringup is > something that an implementation may already support. > > > > > > > > >> given that the flooding on the LAN in both OSPF and ISIS is done as > multicast, there is currently no way to enable flooding, either permanent > or temporary, towards a subset of the neighbors on the LAN. So if the > flooding is enabled on a LAN it is done towards all routers connected to > the it. > > > > > > Agreed. > > > > > >> Given that all links between routers are p2p these days, I would vote > for simplicity and make the LAN always part of the FT. > > > > > > I=E2=80=99m not on board with this yet. Our simulations suggest that t= his is > not necessarily optimal. There are lots of topologies (e.g., parallel > LANs) where this blanket approach is suboptimal. > > the question is how much are true LANs used as transit links in today's > networks. > > thanks, > Peter > > > > > Tony > > > > . > > > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > --00000000000072099005835b8f8d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
in practical terms +1 to Peter's take here ... Un= less we're talking tons of failures simultaneously (which AFAI talked t= o folks are not that common but can sometimes happen in DCs BTW due to weir= d things) smaller scale failures with few links would cause potentially dif= fused "chaining" of convergence behavior rather than IGP-style fa= st healing (and on top of that I didn't see a lot of interest in formal= izing a rigorous distributed algorithm which IMO would be necessary to ensu= re ultimate convergence when only one/subset of links is used). Slow conver= gence is obviously not a good thing unless we assume people will run FRR wi= th its complexity in DC and/or no more than one link every fails which seem= s to me bending assumptions to whatever solution is available/preferred. To= Tony's point though, on large scale failures enabling all links would = cause heavy flood load, yes, but in a sense it's the "initial boot= up" case anyway (especially in centralized case) since nodes need all = topology to make informed correct decisions about what the FT should be if = they don't rely on whatever the centralized instance thinks (which they= won't be able to do given the FT from centralized instance will indica= te lots links that are "gone" due to failure). As to p2p, I sugge= st to agree whether you use dense mesh (DC) case or sparse mesh (WAN) case = or "every topology imaginable" since that drives lots design trad= e-offs.

my 2.718= 28182 cents ;-)

--- tony

On Tue, Mar 5, 2019 at 8:27 AM Peter Psenak <ppsenak@cisco.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l= eft:1px solid rgb(204,204,204);padding-left:1ex">Hi Tony,

On 05/03/2019 17:16 , = tony.li@tony.li wrote:
>
> Peter,
>
>>>=C2=A0 =C2=A0 (a) Temporarily add all of the links that would a= ppear to remedy the partition. This has the advantage that it is very likel= y to heal the partition and will do so in the minimal amount of convergence= time.
>>
>> I prefer (a) because of the faster convergence.
>> Adding all links on a single node to the flooding topology is not = going to cause issues to flooding IMHO.
>
>
> Could you (or John) please explain your rationale behind that? It seem= s counter-intuitive.

it's limited to the links on a single node. From all the practical
purposes I don't expect single node to have thousands of adjacencies, a= t
least not in the DC topologies for which the dynamic flooding is being
primary invented.

In the environments with large number of adjacencies (e.g.
hub-and-spoke) it is likely that we would have to make all these links
part of the flooding topology anyway, because the spoke is typically
dual attached to two hubs only. And the incremental adjacency bringup is something that an implementation may already support.

>
>
>
>> given that the flooding on the LAN in both OSPF and ISIS is done a= s multicast, there is currently no way to enable flooding, either permanent= or temporary, towards a subset of the neighbors on the LAN. So if the floo= ding is enabled on a LAN it is done towards all routers connected to the it= .
>
>
> Agreed.
>
>
>> Given that all links between routers are p2p these days, I would v= ote for simplicity and make the LAN always part of the FT.
>
>
> I=E2=80=99m not on board with this yet.=C2=A0 Our simulations suggest = that this is not necessarily optimal.=C2=A0 There are lots of topologies (e= .g., parallel LANs) where this blanket approach is suboptimal.

the question is how much are true LANs used as transit links in today's=
networks.

thanks,
Peter

>
> Tony
>
> .
>

_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
--00000000000072099005835b8f8d-- From nobody Tue Mar 5 08:47:34 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36B731200D8 for ; Tue, 5 Mar 2019 08:47:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.018, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 jcV3MihUokW4 for ; Tue, 5 Mar 2019 08:47:18 -0800 (PST) Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (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 E7B9F12870E for ; Tue, 5 Mar 2019 08:47:17 -0800 (PST) Received: by mail-pg1-x52c.google.com with SMTP id h11so6019363pgl.0 for ; Tue, 05 Mar 2019 08:47:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=NeUgVAsn7yGdXitsPUeZrjHAyuPA2z8tL3NtrRoaP4E=; b=sbtgU80LtJUInuIoLBBPgPkgY9GELU+YHfF3ovE0W3YwOZAI5YeJ1ZmaO0LfrpGltq 3HWkDybNjWCHSxZe+BWwSVQoTAyTKmObdbyCUqJkPvgeu47MLHoOXExI2mnKFe4K/E0R vOH+P47uecaoKKdDN3hf7AEiCrTLuBIaFXEFOHKzb76x2xa0l/Luvd09sdiPcR9P2t2g YURm9AyNSujoYdSGdVqe7x3XCj//F/a/zIbRWQjwoBEdtGK3tWwciRipAN+QWjdGVCZI D30Avw7Yd40eZqOrxdCjCyT4JP6NFz4QOeWKwRtnOXBJEWsC/iJjvBDmYnOkSn7b5fz2 f8tQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=NeUgVAsn7yGdXitsPUeZrjHAyuPA2z8tL3NtrRoaP4E=; b=TBnOEkQiHhyDdAs90X0NBQusn4x/OBbpNSEIQpPM4JsJXNQX0yUf0isctyvwgkcJ2f lrZMd/9nR1r+ULx5FBJPjh5bWNR8KYTAMxuLewghHPCQfDHVjsAR6Y2fuJyrNos1kLf8 Cvhcuj76aIqG+1QVgww4/xf8agr+7PRO0hyI0f096llhwr9qL/adEmbAZM2hZJyov7D8 6oQ1/xE2bbJNV5ExZIkcW/LWsEkhYiK4jmiMKBLDxIMsvkAWXoPJUDfJenVVgb0rMPfn pdU4YhUFMh0/zi0tEyo9bZ5ZOozU2G4B9+5h9ovRYj8dvjiRv6YtCmYKXWfzZnL1M9Aq oDFQ== X-Gm-Message-State: APjAAAXY0JspO0rkKY4hm5iKfZnh8NnwiQ6Ayov1IaqrT2RlxN3XPmyu wrH/Jfc9y4p9hkhMSRdiRlg= X-Google-Smtp-Source: APXvYqw5MER9kJF5h1qr3q6XvD8Sqx0OdLmnDGhgaqsLO7Ne8+zzZ5A0nkbnIgW13M1HUc5Hc01kHw== X-Received: by 2002:a17:902:e01:: with SMTP id 1mr2182152plw.66.1551804437162; Tue, 05 Mar 2019 08:47:17 -0800 (PST) Received: from [172.22.228.48] ([162.210.130.3]) by smtp.gmail.com with ESMTPSA id f15sm14177501pfa.11.2019.03.05.08.47.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Mar 2019 08:47:16 -0800 (PST) Sender: Tony Li From: tony.li@tony.li Message-Id: <966E5756-8CEF-47F4-8564-E23D38F0743E@tony.li> Content-Type: multipart/alternative; boundary="Apple-Mail=_C0D3081B-E6F7-4477-AAD5-3F44E637B032" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Tue, 5 Mar 2019 08:47:15 -0800 In-Reply-To: Cc: lsr@ietf.org To: Peter Psenak References: X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Lsr] Open issues with Dynamic Flooding X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 16:47:20 -0000 --Apple-Mail=_C0D3081B-E6F7-4477-AAD5-3F44E637B032 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Peter, >>> Adding all links on a single node to the flooding topology is not = going to cause issues to flooding IMHO. >>=20 >>=20 >> Could you (or John) please explain your rationale behind that? It = seems counter-intuitive. >=20 > it's limited to the links on a single node. =46rom all the practical = purposes I don't expect single node to have thousands of adjacencies, at = least not in the DC topologies for which the dynamic flooding is being = primary invented. What if the node in question is one of the spines? Folks are building = systems that large=E2=80=A6 and it seems inevitable that port counts = will only grow. Toto, I don=E2=80=99t think that=E2=80=99s an AGS any = more=E2=80=A6. ;-) > In the environments with large number of adjacencies (e.g. = hub-and-spoke) it is likely that we would have to make all these links = part of the flooding topology anyway, because the spoke is typically = dual attached to two hubs only. And the incremental adjacency bringup is = something that an implementation may already support. LS topologies can have a very large number of adjacencies as well, = typically with multiple spines, so for a new spine, all of the of the = links may be unnecessary. >> Our simulations suggest that this is not necessarily optimal. There = are lots of topologies (e.g., parallel LANs) where this blanket approach = is suboptimal. >=20 > the question is how much are true LANs used as transit links in = today's networks. As Xiaohu suggested, the management plane would be an obvious = application. Interconnects also seem likely. Let=E2=80=99s set the algorithmic parts aside. Do you have an objection = to supporting them in the signaling? Tony --Apple-Mail=_C0D3081B-E6F7-4477-AAD5-3F44E637B032 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Hi Peter,

Adding all links on a = single node to the flooding topology is not going to cause issues to = flooding IMHO.


Could you (or John) please explain your rationale behind = that? It seems counter-intuitive.

it's limited to the links on a = single node. =46rom all the practical purposes I don't expect single = node to have thousands of adjacencies, at least not in the DC topologies = for which the dynamic flooding is being primary invented.


What if the node in question is one of the spines? =  Folks are building systems that large=E2=80=A6 and it seems = inevitable that port counts will only grow.  Toto, I don=E2=80=99t = think that=E2=80=99s an AGS any more=E2=80=A6. ;-)


In the = environments with large number of adjacencies (e.g. hub-and-spoke) it is = likely that we would have to make all these links part of the flooding = topology anyway, because the spoke is typically dual attached to two = hubs only. And the incremental adjacency bringup is something that an = implementation may already support.


LS topologies can have a = very large number of adjacencies as well, typically with multiple = spines, so for a new spine, all of the of the links may be = unnecessary.


Our simulations suggest that this is = not necessarily optimal.  There are lots of topologies (e.g., = parallel LANs) where this blanket approach is suboptimal.

the question is how much are true LANs used as transit links = in today's networks.


As = Xiaohu suggested, the management plane would be an obvious application. = Interconnects also seem likely.

Let=E2=80=99s set the algorithmic parts = aside.  Do you have an objection to supporting them in the = signaling?

Tony

= --Apple-Mail=_C0D3081B-E6F7-4477-AAD5-3F44E637B032-- From nobody Tue Mar 5 08:47:40 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5A313119B; Tue, 5 Mar 2019 08:47:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.7 X-Spam-Level: X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.onmicrosoft.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 FTFuCtNiBzlV; Tue, 5 Mar 2019 08:47:21 -0800 (PST) Received: from mail3.bemta25.messagelabs.com (mail3.bemta25.messagelabs.com [195.245.230.82]) (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 671FB12870E; Tue, 5 Mar 2019 08:47:20 -0800 (PST) Received: from [46.226.52.197] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-2.bemta.az-b.eu-west-1.aws.symcld.net id 7E/D6-14990-618AE7C5; Tue, 05 Mar 2019 16:47:18 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WSWUwTURSGuZ2ZdiSMXgvIoYjR4hKRKRRRa4y Jj0hi9MWYqKBTOrZN2kI6JWwRiQoqBFc0CCqCWA0aBdSI1g2icYkLm5pARFAUKYtRiIgg2Ong 9vaf8/3nnv/eXJpQ3pCraD7NwdttnEUt9yVjFn6fywaez9octdup0bWdLCd1VWPVCt2jrvOUr ta1R6572DCKVlGxhaPVVGxFxYhsnWwjZbbpk9K2UqbCoWoiuTko7WpjZjYa8c9DvjSJywmozu lHYqHEBTJ4evSiQiraEbwceOApptByvBJqLryR5yGaDsDRcKZ7keghcB+Cu40nvB5/T//Y0Bg l6gC8GAaetyokvQGu9eYrxFkSz4XGdwvENoPjYSDXRUq7rhNwKPuVXARTcAJMdFR5z0F4Bgw/ uSgTNYGDoLWr1KsBY6i49YKQdCD0vB+f9Ovh7YcyJPXnQFG7lA1wKDSV5iMxA+A1MNizQZJhc PVTvBgB8HsEDRO3JkfDoctdJZPAKANne55RErDA3YKfCml4JnweUkieHxQcdvd5dylxIjw6MU hK/llQWdBJSqYGAr7cLkHSZSLgtOur/CAKL/7nbsX/IEkvAmdZL1HsfbDp8Ph4F3kakZVIp7e bjSaHlTNbWG1UFKvVRrPa5UtZbcxiDZfB6jV8CpvKCw5Wq+FSBY2Qbk20GDQ23lGDPN/IkHz/ QC36eM5Yj4JpmTqQ2Z+XtVk5VZ9kSDdxgmmLPcXCC/VoJk2rgbE7PWy6nTfyadvMFs9f/I2B9 lMHMHUiZoRkziqYjRJ6glj6XnnnSUJJ2pJsvCqIMZ3zmLBoMqXY/hzx+0c3oVCVP4N8fHyUfs m83Wp2/M/dKIhGan/msrjKz2xz/Nnk9oSQeUIMNmeKIRzcX6TKRoUR2Hh9SYlh9IO6b0DXs35 +W+6+h/31IfHRp2quaEe2zpsd6gxwxjbvv9x0c1PWtLjKCpczYtel2MQd33LS21es8GVVkc8S Fro67tTV7D2y+n5cbV99SHqwobK7IcF+oCXD4Lu8rmjtSDhVNDEcFtb8I/LGgsxgRcuqsu0h4 687lu1Uk4KJ04YTdoH7BU1DTO/MAwAA X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-17.tower-285.messagelabs.com!1551804434!1980507!1 X-Originating-IP: [52.41.248.36] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.31.5; banners=ecitele.com,-,- X-VirusChecked: Checked Received: (qmail 1611 invoked from network); 5 Mar 2019 16:47:17 -0000 Received: from us-west-2a.mta.dlp.protect.symantec.com (HELO EUR04-DB3-obe.outbound.protection.outlook.com) (52.41.248.36) by server-17.tower-285.messagelabs.com with AES256-SHA256 encrypted SMTP; 5 Mar 2019 16:47:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=QZLDCLOE7lSIQH4UiHQX4c/P6suEZVfuyQCn366+HyY=; b=l8N8UwO0Gz6ZHSyBxlTFw9fwyaf3JBU3d0kAXvgiBSA8BLc4bOrQjIYTsX/khAAAXyFm/10AQaj0iTfVKHoaA6/LQ7bM+F8vi1feEq0hDO2y1Vrzxq35VH+nng5CyW3R1k8RPUdoLtnSaQWkVPbKhPXllmYBDLMRnivsXEya57I= Received: from VI1PR03MB3839.eurprd03.prod.outlook.com (20.177.54.23) by VI1PR03MB4973.eurprd03.prod.outlook.com (20.178.15.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.18; Tue, 5 Mar 2019 16:47:12 +0000 Received: from VI1PR03MB3839.eurprd03.prod.outlook.com ([fe80::4531:64c5:83dc:4252]) by VI1PR03MB3839.eurprd03.prod.outlook.com ([fe80::4531:64c5:83dc:4252%2]) with mapi id 15.20.1665.020; Tue, 5 Mar 2019 16:47:12 +0000 From: Alexander Vainshtein To: "Les Ginsberg (ginsberg)" CC: "lsr@ietf.org" , "spring@ietf.org" , "draft-ietf-isis-segment-routing-extensions.all@ietf.org" , "Peter Psenak (ppsenak)" Thread-Topic: [spring] FlexAlgo and Global Adj-SIDs Thread-Index: AdTPjdP9QRfJ5GzARfmqN1/BpEhW0gAEem2AAGBozJQAkaz8AAABfrsgAAC21FAAAD2n8A== Date: Tue, 5 Mar 2019 16:47:12 +0000 Message-ID: References: <20493a62-cf70-a182-900d-e55dd68f5149@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.234.241.1] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c5776827-2a09-4423-dfd7-08d6a18a375f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7153060)(7193020); SRVR:VI1PR03MB4973; x-ms-traffictypediagnostic: VI1PR03MB4973: x-microsoft-exchange-diagnostics: =?us-ascii?Q?1; VI1PR03MB4973; 23:ysZp3zojC/SJJ7cTzjY/WLexrGWJQWxleGQvQ1d2o?= =?us-ascii?Q?7eA4U73RU4SxW07VpLYDV3t/Ecrcg5r8LfQhUNJST4QVw5oFRJRrxUPONZ2e?= =?us-ascii?Q?VKh+P44pV1M/i7Z6mezQUeiAEnyxQvNdEcYRmytvQ8bndCzMtFrO36YMC3HD?= =?us-ascii?Q?vrmeMyKc89QxbfvUIhA4s9I+6UvA1j6BiF/kTpaiDVLdHZ1yIo2gk6s3gLxC?= =?us-ascii?Q?U/8sJyjAWz9UWOtirQ52Td4bHV0w7A4wkvN1qPh4f1/wRd23v5sGoaZoK4mU?= =?us-ascii?Q?nf7+ixPboGxroj9yw4xpE1KfbYnLOS9yL8+ty2b4rP2eRxq1IoauL5xtOxjg?= =?us-ascii?Q?G2cCoyf3/K+18UkvRVU0TbtyQSX/cYtKSuSuw7DKqStyRG8skBHm70tjN1YZ?= =?us-ascii?Q?bGWXdEWf5640HIICQupKRoC7gCauQKwDNs/9Lea+OYxgOGT3ajZ073/Q1PAr?= =?us-ascii?Q?cSQ9XRs9oGDeCd+EZGrDGYrgFHg5D2ErUgr2b73s07qM1pdLlIG8l+6BtaPn?= =?us-ascii?Q?Eg0aWaEbV4cZ5zgflun+T/dG23FDNjT0daIesrb69GtD26t0tLOlnYo8NUwv?= =?us-ascii?Q?BldD5Q6CV6ge7sLMbclo4PvMJclC6hyGUhTruq+/yrCPPfQMTJgOzRB3WEbk?= =?us-ascii?Q?RGw2UXCGVeg8fYm9sN+C9czBuTUrsR8+28iOTBWCesFbFxqRUBHpcwlZXyFP?= =?us-ascii?Q?S68g0qqfZwiwkxoxcjejIEA3juLoAmkoAdLvmqgIXgBj3N0Htfp8RJXhIRj5?= =?us-ascii?Q?hq7iHGHlf1pe+0/xmlCYyk3tDH99f88ZHKmnwFcA7GsrtLU2wpnGC/naiATz?= =?us-ascii?Q?6ls+OCdBQciurYXuove+GkOAg3kA/VqVcxpy6MM9+1NDj78KBfoM2Q0RsjjN?= =?us-ascii?Q?BAaie46RWDTLXcrvdxeQD0HjNxg9Kd+SptLbdN2lkt+GLH+gg+nF5HmqZyQV?= =?us-ascii?Q?iSUr9Fz0pLCncEZWYE/2KEehH3XNgkittsIfpyrS4R2g8TinmeghycwJ2+F3?= =?us-ascii?Q?Q5sRpTrP+/ynea1H0+DqlIliHUkPxHweEaqukhzI30w/m2XgHjJrhoorf8yx?= =?us-ascii?Q?hAbHohzTSQSLLQGQRh4UvaY9tcLdwRTkC1yEYE7iRs8tLJGzab7eM/CpicTV?= =?us-ascii?Q?1M5ZmehCYSqvECfHfuYlNdXD0Ti98xdRdMHn8cgqxD8Rbmx7dgCq8vT8XsY/?= =?us-ascii?Q?3cr1uue+QnMINbAFOHY4Kh849nUF2qjT9BKpaIQFl/EeBoQJ9GAtLyCQQ98o?= =?us-ascii?Q?5y5861ymGhYERPaKcX4oraaMWzIQ1kJojK+iwLkfryN5KN9YtBCtaguznfQK?= =?us-ascii?Q?EbuPkV7fI5uV8DpWBOiG3AEE8PORgVfakprgTllNmiJ?= x-microsoft-antispam-prvs: x-forefront-prvs: 0967749BC1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(136003)(39860400002)(346002)(366004)(396003)(51874003)(13464003)(199004)(189003)(68736007)(8676002)(81156014)(81166006)(106356001)(8936002)(97736004)(105586002)(9686003)(6916009)(53936002)(66066001)(2906002)(55016002)(6436002)(4326008)(305945005)(25786009)(6116002)(3846002)(7736002)(14444005)(256004)(74316002)(229853002)(446003)(54906003)(72206003)(186003)(86362001)(6506007)(53546011)(71190400001)(7696005)(6246003)(11346002)(99286004)(52536013)(476003)(76176011)(478600001)(93886005)(33656002)(102836004)(5660300002)(14454004)(71200400001)(26005)(486006)(316002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR03MB4973; H:VI1PR03MB3839.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 8nxQ9xAWNFiI3yX6312bKsiPRdnuoyFsOXmHgKfrgU4cGuLV3QN0h/1YRBzMv/IvgRWqgu1gdoBbmVthcq1hza60YQchrwolq9z3OYfIvtzt6smZtnqrFFYVJpEI28UYLksE4u7tgBYWuMlsrsgVEn/xoxs2BZ1r0JZTU/MkoG9UjQkn1Xe9EnqeBbcKmSaxhDo5ycIFRs+ePpMEXLQ2LXLjBQIZt+kj9uMmwswve38iAVOyxbVye227GRMohe92XYuq0fhvOELnOVvBKAzhYIcaB1AHvqnb9BJS5wOdVv+0qXu3oQFopPYGXqTYWPtC78EbUzH9MKUAyTt4p0NYFeW0RzEy0ba+pmX5VfYkf98hA+Hbh/jyRE3ytDYnnpr9yCuGOAaLqzBG23LA96WAUg4jPj1oG04HshwIra9N/4M= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-Network-Message-Id: c5776827-2a09-4423-dfd7-08d6a18a375f X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2019 16:47:12.5452 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR03MB4973 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Lsr] [spring] FlexAlgo and Global Adj-SIDs X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 16:47:29 -0000 Les, Lots of thanks for a prompt response. I fully understand that the current SR extension drafts are too far advanc= ed for any significant changes. I also understand that Algo-specific Adj-SIDs require an update to RFC 840= 2 because today it does not recognize any such entities. Therefore the discussion of use cases should probably start in the SPRING = WG while effective the result would be "just" new Sub-TLV in IS-IS and OSP= F with the actual work coming to the LSR WG.=20 Any ideas as to what would be the best way to start this kind of discussio= ns?=20 Regards, Sasha Office: +972-39266302 Cell: +972-549266302 Email: Alexander.Vainshtein@ecitele.com -----Original Message----- From: Les Ginsberg (ginsberg) =20 Sent: Tuesday, March 5, 2019 6:37 PM To: Alexander Vainshtein ; Peter Psenak = (ppsenak) Cc: lsr@ietf.org; spring@ietf.org; draft-ietf-isis-segment-routing-extensi= ons.all@ietf.org Subject: RE: [spring] FlexAlgo and Global Adj-SIDs Sasha - draft-ietf-isis-segment-routing-extensions is currently in AD review - and= the companion OSPF document has already been approved and is waiting for = a dependent draft to progress before publication as an RFC. It is too late to make significant changes. Further, while I agree with both your description and Peter's response, ag= reeing that this "could" be done is not equivalent to having consensus tha= t it "should" be done. I think a more complete consideration of the deployment cases and the usef= ulness of such an extension should be discussed by the WG before we decide= that we actually want to define such an extension. Les > -----Original Message----- > From: Alexander Vainshtein > Sent: Tuesday, March 05, 2019 8:29 AM > To: Peter Psenak (ppsenak) > Cc: lsr@ietf.org; spring@ietf.org; draft-ietf-isis-segment-routing-=20 > extensions.all@ietf.org > Subject: RE: [spring] FlexAlgo and Global Adj-SIDs >=20 > Peter, > Lots of thanks for a prompt and very encouraging response. >=20 > Do you think that the new Algo specific Adj-SID sub-TLV could be added=20= > to the current IS-IS segment Routing Extensions draft, or should be=20 > handled in a small dedicated document? >=20 > Regards, and lots of thanks in advance, Sasha >=20 > Office: +972-39266302 > Cell: +972-549266302 > Email: Alexander.Vainshtein@ecitele.com >=20 > -----Original Message----- > From: Peter Psenak > Sent: Tuesday, March 5, 2019 5:28 PM > To: Alexander Vainshtein > Cc: lsr@ietf.org; spring@ietf.org; draft-ietf-isis-segment-routing-=20 > extensions.all@ietf.org > Subject: Re: [spring] FlexAlgo and Global Adj-SIDs >=20 > Hi Sasha, >=20 > On 02/03/2019 18:57 , Alexander Vainshtein wrote: > > Peter, > > Lots of thanks for a prompt and hivhly informative response. > > > > It seems that per-FlexAlgo Adj-SIDs can be useful even if they are=20 > > local __________________________________________________________________________= _ This e-mail message=20is intended for the recipient only and contains info= rmation which is=20 CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this=20 transmission in error, please inform us by e-mail, phone or fax, and then = delete the original=20 and all copies thereof. __________________________________________________________________________= _ From nobody Tue Mar 5 11:12:58 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33CE11312BD for ; Tue, 5 Mar 2019 11:12:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=raszuk.net 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 vhGzsB0FBJcW for ; Tue, 5 Mar 2019 11:12:53 -0800 (PST) Received: from mail-qt1-x82a.google.com (mail-qt1-x82a.google.com [IPv6:2607:f8b0:4864:20::82a]) (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 3C6C413129C for ; Tue, 5 Mar 2019 11:12:53 -0800 (PST) Received: by mail-qt1-x82a.google.com with SMTP id w4so10129010qtc.1 for ; Tue, 05 Mar 2019 11:12:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bFEWNzTZCLEb1bJMHVIyE0Np4VOLcdk05/iyZ+49c8E=; b=Z5HpCqpeqWdIRxizypMGblfw8cdyu1dF2D/Ge2TEo+gbRMKdKHR6fWzdYqfYUcqyO3 aD9S++rkUB0OHFWj0M97La7TiPNW6OlHMyJSmdpgxhnmrG9aJAT0ellAkYmiTm+1o/o/ eCvXi5pE6LxymaU38z3CvKYQYacY9MKAOn1229LBZZaIavnMR+mjUW7pXIbjDMACxwoG OmHEstBBiAYw04aHkxSpcjQNe0M9dVFMDpTmwYdm0Tfqx4oV51q/IK6ZN5sYu794QpbR JLABpDMuL9oXqxi8HjhMNtLva+35ngNDfqzHu/S2a7GV7yGAbCCcaI3EpO0YpXCLfEmU H2ZQ== 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=bFEWNzTZCLEb1bJMHVIyE0Np4VOLcdk05/iyZ+49c8E=; b=rq9fcYwi945yXZ+RDeE7pPx1VXi/EcSxFOk/0DW6PS5wiDW4iOrlJYTFC4+wh8F34t IaLP+LzV6QJqeTNYEdwG5xp/MIPAU+wfXF6ui/I3qrr7jdCq6hxa3/TAbIJnWMJGCsNL c+QZBOMiM5JK8lYGLqnLCMTeXYWmyMV+5EPh1lLdtw6jCxTaFmxybnY5kST4iAXHANr3 QAELSu2SbjC9FZj5f6khOeGLtiW9qMDIBVrnhFW+I2F9sYabywNiOXY2ILyegQNl+VTC +t59JJQ8/Vaz6WZ6JBq7NNZa8yJSm4i3FHSC0W3wIGF9oiI2etqNwvZ2Xv9ZVvKvwb2b MokA== X-Gm-Message-State: APjAAAXYGen7T4tT0hfkIiXvsBqO3LpBFqyx9eJUYXDy8wpYGio+EPOQ TZyq0RoxueAn6U9kgXevLmO91qxPyLDAIIbBzCsdbA== X-Google-Smtp-Source: APXvYqwrI5AN55hgzpnvLyxfcdf3MrTPInzCfANKjm6roWWnvIoW3aYaEhRRFFRArFWoiBq1rJFDifYSkCddNgryDYw= X-Received: by 2002:a0c:95dd:: with SMTP id t29mr3300087qvt.174.1551813172128; Tue, 05 Mar 2019 11:12:52 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Robert Raszuk Date: Tue, 5 Mar 2019 20:12:41 +0100 Message-ID: To: Tony Przygienda Cc: Peter Psenak , lsr@ietf.org, Tony Li Content-Type: multipart/alternative; boundary="000000000000e2081d05835da883" Archived-At: Subject: Re: [Lsr] Open issues with Dynamic Flooding X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 19:12:57 -0000 --000000000000e2081d05835da883 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > Slow convergence is obviously not a good thing Could you please kindly elaborate why ? With tons of ECMP in DCs or with number of mechanism for very fast data plane repairs in WAN (well beyond FRR) IMHO any protocol *fast convergence* is no longer a necessity. Yet many folks still talk about it like the only possible rescue ... On Tue, Mar 5, 2019 at 5:42 PM Tony Przygienda wrote: > in practical terms +1 to Peter's take here ... Unless we're talking tons > of failures simultaneously (which AFAI talked to folks are not that commo= n > but can sometimes happen in DCs BTW due to weird things) smaller scale > failures with few links would cause potentially diffused "chaining" of > convergence behavior rather than IGP-style fast healing (and on top of th= at > I didn't see a lot of interest in formalizing a rigorous distributed > algorithm which IMO would be necessary to ensure ultimate convergence whe= n > only one/subset of links is used). Slow convergence is obviously not a go= od > thing unless we assume people will run FRR with its complexity in DC and/= or > no more than one link every fails which seems to me bending assumptions t= o > whatever solution is available/preferred. To Tony's point though, on larg= e > scale failures enabling all links would cause heavy flood load, yes, but = in > a sense it's the "initial bootup" case anyway (especially in centralized > case) since nodes need all topology to make informed correct decisions > about what the FT should be if they don't rely on whatever the centralize= d > instance thinks (which they won't be able to do given the FT from > centralized instance will indicate lots links that are "gone" due to > failure). As to p2p, I suggest to agree whether you use dense mesh (DC) > case or sparse mesh (WAN) case or "every topology imaginable" since that > drives lots design trade-offs. > > my 2.71828182 cents ;-) > > --- tony > > On Tue, Mar 5, 2019 at 8:27 AM Peter Psenak wrote: > >> Hi Tony, >> >> On 05/03/2019 17:16 , tony.li@tony.li wrote: >> > >> > Peter, >> > >> >>> (a) Temporarily add all of the links that would appear to remedy >> the partition. This has the advantage that it is very likely to heal the >> partition and will do so in the minimal amount of convergence time. >> >> >> >> I prefer (a) because of the faster convergence. >> >> Adding all links on a single node to the flooding topology is not >> going to cause issues to flooding IMHO. >> > >> > >> > Could you (or John) please explain your rationale behind that? It seem= s >> counter-intuitive. >> >> it's limited to the links on a single node. From all the practical >> purposes I don't expect single node to have thousands of adjacencies, at >> least not in the DC topologies for which the dynamic flooding is being >> primary invented. >> >> In the environments with large number of adjacencies (e.g. >> hub-and-spoke) it is likely that we would have to make all these links >> part of the flooding topology anyway, because the spoke is typically >> dual attached to two hubs only. And the incremental adjacency bringup is >> something that an implementation may already support. >> >> > >> > >> > >> >> given that the flooding on the LAN in both OSPF and ISIS is done as >> multicast, there is currently no way to enable flooding, either permanen= t >> or temporary, towards a subset of the neighbors on the LAN. So if the >> flooding is enabled on a LAN it is done towards all routers connected to >> the it.. >> > >> > >> > Agreed. >> > >> > >> >> Given that all links between routers are p2p these days, I would vote >> for simplicity and make the LAN always part of the FT. >> > >> > >> > I=E2=80=99m not on board with this yet. Our simulations suggest that = this is >> not necessarily optimal. There are lots of topologies (e..g., parallel >> LANs) where this blanket approach is suboptimal. >> >> the question is how much are true LANs used as transit links in today's >> networks. >> >> thanks, >> Peter >> >> > >> > Tony >> > >> > . >> > >> >> _______________________________________________ >> Lsr mailing list >> Lsr@ietf.org >> https://www.ietf.org/mailman/listinfo/lsr >> > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > --000000000000e2081d05835da883 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

> Slow convergence is obviously not a go= od thing

Could you please kindly elaborate why ?=C2=A0

With tons of ECMP in DCs or with number of mechanis= m for very fast data plane repairs in WAN (well beyond FRR) IMHO any protoc= ol *fast convergence* is no longer a necessity. Yet many folks still talk a= bout it like the only possible rescue ...=C2=A0

<= br>
On Tue,= Mar 5, 2019 at 5:42 PM Tony Przygienda <tonysietf@gmail.com> wrote:
in practical terms +1 to P= eter's take here ... Unless we're talking tons of failures simultan= eously (which AFAI talked to folks are not that common but can sometimes ha= ppen in DCs BTW due to weird things) smaller scale failures with few links = would cause potentially diffused "chaining" of convergence behavi= or rather than IGP-style fast healing (and on top of that I didn't see = a lot of interest in formalizing a rigorous distributed algorithm which IMO= would be necessary to ensure ultimate convergence when only one/subset of = links is used). Slow convergence is obviously not a good thing unless we as= sume people will run FRR with its complexity in DC and/or no more than one = link every fails which seems to me bending assumptions to whatever solution= is available/preferred. To Tony's point though, on large scale failure= s enabling all links would cause heavy flood load, yes, but in a sense it&#= 39;s the "initial bootup" case anyway (especially in centralized = case) since nodes need all topology to make informed correct decisions abou= t what the FT should be if they don't rely on whatever the centralized = instance thinks (which they won't be able to do given the FT from centr= alized instance will indicate lots links that are "gone" due to f= ailure). As to p2p, I suggest to agree whether you use dense mesh (DC) case= or sparse mesh (WAN) case or "every topology imaginable" since t= hat drives lots design trade-offs.

my 2.71828182 cents ;-)

--- tony

On Tue, Mar 5, 2019 at 8:27 AM Peter Psenak &= lt;ppsenak@cisco.com= > wrote:
= Hi Tony,

On 05/03/2019 17:16 , = tony.li@tony.li wrote:
>
> Peter,
>
>>>=C2=A0 =C2=A0 (a) Temporarily add all of the links that would a= ppear to remedy the partition. This has the advantage that it is very likel= y to heal the partition and will do so in the minimal amount of convergence= time.
>>
>> I prefer (a) because of the faster convergence.
>> Adding all links on a single node to the flooding topology is not = going to cause issues to flooding IMHO.
>
>
> Could you (or John) please explain your rationale behind that? It seem= s counter-intuitive.

it's limited to the links on a single node. From all the practical
purposes I don't expect single node to have thousands of adjacencies, a= t
least not in the DC topologies for which the dynamic flooding is being
primary invented.

In the environments with large number of adjacencies (e.g.
hub-and-spoke) it is likely that we would have to make all these links
part of the flooding topology anyway, because the spoke is typically
dual attached to two hubs only. And the incremental adjacency bringup is something that an implementation may already support.

>
>
>
>> given that the flooding on the LAN in both OSPF and ISIS is done a= s multicast, there is currently no way to enable flooding, either permanent= or temporary, towards a subset of the neighbors on the LAN. So if the floo= ding is enabled on a LAN it is done towards all routers connected to the it= ..
>
>
> Agreed.
>
>
>> Given that all links between routers are p2p these days, I would v= ote for simplicity and make the LAN always part of the FT.
>
>
> I=E2=80=99m not on board with this yet.=C2=A0 Our simulations suggest = that this is not necessarily optimal.=C2=A0 There are lots of topologies (e= ..g., parallel LANs) where this blanket approach is suboptimal.

the question is how much are true LANs used as transit links in today's=
networks.

thanks,
Peter

>
> Tony
>
> .
>

_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
--000000000000e2081d05835da883-- From nobody Tue Mar 5 11:36:34 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C4D3130DC9 for ; Tue, 5 Mar 2019 11:36:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.605 X-Spam-Level: * X-Spam-Status: No, score=1.605 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_IMAGE_ONLY_28=1.404, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SB_GIF_AND_NO_URIS=2.199, SPF_PASS=-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 2XcdlZZJsEJn for ; Tue, 5 Mar 2019 11:36:31 -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 3EEFC130DC4 for ; Tue, 5 Mar 2019 11:36:31 -0800 (PST) Received: by mail-ed1-x534.google.com with SMTP id 10so8219653eds.7 for ; Tue, 05 Mar 2019 11:36:31 -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=8YjnXeS8+kwYFtfwSdwCX+LP83S0VWhMZS2LfIMvWjo=; b=FPcHkjW32eFjp8UKES1a8cwHyNtTUiPPHEN67OLs9HMrO2DFE/e17AsYEcqvKO2X3a CwNZ+5oxcjU1J1L5o/8L0mbPmYxGJmWqxgzAB0Fxuga1ouYOLnJSC6Yw1wpO3+LY19TJ 0NTu8MBvG/3A/NXymfejyRhpaDILklCOiCyg5SAH8vGirHu9qVWjSW6bDE+Bq7D+A7vE K/ZJ8urDZmAzRbCBGLxiWC/Spbwf1nZ4z+ujARSIM/sdkhqv0G6DP8R7EVsgkVQnGcyq aiTmR7ULcXKCJbuQwYRGiwc66qSAn2g+mXgz4GPDpP0qXi4MUK5lhX5H7CgHIT33C7NN /dvg== 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=8YjnXeS8+kwYFtfwSdwCX+LP83S0VWhMZS2LfIMvWjo=; b=JRfymYhpmpY0sZcP3aHFNLYybYW0suRFISTVx1TWsrxOikU/58IaYfsU9NQProG3sg KFp5772D+70fq/2fWVeRc87+zvAoab3DlLni2RHiVHcZrfJGjIokpcWPpSOJXrRBCEOE TZsmJH1/qkAkxTjUQz9oxjbYppgmrzDQfzbWjtkUz/Y2BPZBMdRM3S7UgiOVmgZf9kZe dhyP9xnYk2pN2iOflG5TGmo02CvIuvhR0wc+kefkuhez6ofqcREpEWhTMllXFbM6WsSE c/mD5xJ7X3MIFReIGhWZIE6kJQqTrM1wYyZJy4x2HJMDnhaohyAnycB7yEVYvTXYlIVi +T/w== X-Gm-Message-State: APjAAAVvwxpDEN7RRVGT3DifN0QcAEjspXPhGxnJXflOwP9czE/0Ji4Y OC+A5aRn9uHZHcVr6DnRJD1TqVqwViKnT7gOfpM= X-Google-Smtp-Source: APXvYqy2KRZNzLy5tDL2CYpxVlphbFxztRlgxsgCS2tf0OPpoLinmA+loztYh03nAlLTaTnzz1KWQ5sC0I9IN2302ug= X-Received: by 2002:a50:d8ce:: with SMTP id y14mr20595991edj.101.1551814589736; Tue, 05 Mar 2019 11:36:29 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Tony Przygienda Date: Tue, 5 Mar 2019 11:35:53 -0800 Message-ID: To: Robert Raszuk Cc: Peter Psenak , lsr@ietf.org, Tony Li Content-Type: multipart/related; boundary="0000000000006154c705835dfd51" Archived-At: Subject: Re: [Lsr] Open issues with Dynamic Flooding X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 19:36:33 -0000 --0000000000006154c705835dfd51 Content-Type: multipart/alternative; boundary="0000000000006154c505835dfd50" --0000000000006154c505835dfd50 Content-Type: text/plain; charset="UTF-8" On Tue, Mar 5, 2019 at 11:12 AM Robert Raszuk wrote: > > > Slow convergence is obviously not a good thing > > Could you please kindly elaborate why ? > > With tons of ECMP in DCs or with number of mechanism for very fast data > plane repairs in WAN (well beyond FRR) IMHO any protocol *fast convergence* > is no longer a necessity. Yet many folks still talk about it like the only > possible rescue ... > > > Agree on FRR in WAN but it seems quite a complexity to drag that into DC fabrics (again, depeneding what topologies talk about) especially due to the effect I outline below. ECMP in DCs when used AFAIS is often caused by walking the 10G-50G curve where everybody has different economic sweet-spots AFAIS. Sometimes 100G. It's often LAG'ed (due to amount of control plane state AFAIU). LAG'ing generally creates interesting problems itself and I expect whole thing to settle somewhere with 20-50G to the server over either very short copper or multimode. I do not think it's a particularly cool architecture to suggest "LAG every link so it's 1:1 protected". Wide fanout is common & will get wider AFAIS. This is cool for failures in one direction but doesn't prevent you from blackholing on the "far end" until you get control plane reconvergence (or do FRR on a spine but honestly, how do you do that, bow-tieing over top of fabric or doing harmonica routing over multi-homed servers?) Then, slow convergence means that new stuff shows up slowly which is probably not very desirable and in case of failures that really need control plane rerouting causes longer duration blackholes as well. Both seem undesirable .. Not mentioning mobility even ... my [image: CodeCogsEqn(17).gif] cents ;-) --- tony --0000000000006154c505835dfd50 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, Mar 5, 2019 at 11:12 AM Rober= t Raszuk <robert@= raszuk.net> wrote:

> Slow convergence is obvious= ly not a good thing

Could you please kindly elaborate wh= y ?=C2=A0

With tons of ECMP in DCs or with number = of mechanism for very fast data plane repairs in WAN (well beyond FRR) IMHO= any protocol *fast convergence* is no longer a necessity. Yet many folks s= till talk about it like the only possible rescue ...=C2=A0



Agree on FRR in WAN but it s= eems quite a complexity to drag that into DC fabrics (again, depeneding wha= t topologies talk about) especially due to the effect I outline below.
=

ECMP in DCs when used AFAIS is often caused by w= alking the 10G-50G curve where everybody has different economic sweet-spots= AFAIS. Sometimes 100G.=20 It's often LAG'ed (due to amount of control plane state AFAIU). LAG= 'ing generally creates interesting problems itself and I expect whole t= hing to settle=20 somewhere with 20-50G to the server over either very short copper or=20 multimode. I do not think it's a particularly cool architecture to sugg= est "LAG every link so it's 1:1 protected".
Wide fanout is common & will get wider AFAIS. This is cool= for failures in one direction but doesn't prevent you from blackholing= on the "far end" until you get control plane reconvergence (or d= o FRR on a spine but honestly, how do you do that, bow-tieing over top of f= abric or doing harmonica routing over multi-homed servers?)
<= br>
Then, slow convergence means that new stuff shows up slowly w= hich is probably not very desirable and in case of failures that really nee= d control plane rerouting causes longer duration blackholes as well. Both s= eem undesirable .. Not mentioning mobility even ...

my

3D"Code==C2=A0=C2=A0 cents ;-)

--- tony


--0000000000006154c505835dfd50-- --0000000000006154c705835dfd51 Content-Type: image/gif; name="CodeCogsEqn(17).gif" Content-Disposition: inline; filename="CodeCogsEqn(17).gif" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: ii_jsw699y30 R0lGODlhfQAuALMAAP///wAAAMzMzERERIiIiGZmZpiYmNzc3O7u7nZ2djIyMiIiIqqqqlRUVBAQ ELq6uiH5BAEAAAAALAAAAAB9AC4AAAT+EMhJq70YnJG7/2AojmRlJEuprmzrHqkrz7QM13iuS4Vh ULedcFjqEQKHSZAoQgwezBkigDgkgLGox2oIQLWthOKyBHu8ZtbiWnkUAoRkOoOek6YMu6quD3Xl fSJ8gR4NAYQjg4gYDhyLIIqPQAFskh2RlgBdeZl0X50ThoBECD8tmAYIjwuHKgcEIwUVryEICQMB CgkCFQiyHQcNozpTjiQJDqYgBLwTyMoyD7AYAgMOTA+UKwvDHWMV3DjfGAwNTAkBnHfXftAACOw1 BOoWPUy43SDlIgPD+zgCzGEIR8RBqxINlDEgQKCUgQafAMQLZWphQx8QV0wEwJABg3j+DE48CCnM Ri6NchA8OBCg4jiJFhwkUcnS5YqDAAaYaiBwpQYHeRw0a8EgwC8SB+JBYZCFgLEyPyUsbWqMxAJV msYllMDpwcRqA8KKFTutAzp3IQgInFCgUoOyUNVSaBuqLIAAePPqxQngqoRkE2RWSLB2Bq6I/Nw5 +IRkArwKOiksntBYBTuWcgRsBKAAbQuDWEkgqSKB5QSmAD5tHJ3ENNcUiEOwE3DQaWrHlWOXmJJl xBRNEwyMo1u2H27gWdlesRsiYGBVB3Rp8qqplYB8JLIdPWZAXQJlAhI0DA7tO6fvE8KPJzFvwoME HoM1FFCAgQAG8HWXOOJ5h5MoL82eIYoZuxDxQH9aLLAZE9vl4AshAVSlRSlCpBIIbcyBoiEGXei3 YUgJjPQQdna8sSEGPiUV1FCIKBDgiVxJtSAi2qRHgAEZdkJYJyyx+I0PMHbWiQETPSBQNSdOIYeH cwywnVxRdUJdFxJcJ0kALBLwi2uZ0GcffgwwqYUCsjxUAZSawWhJZwj4RcEDjsCppiU+hEbBNzfO OWd4J+gpRAQAOw== --0000000000006154c705835dfd51-- From nobody Tue Mar 5 11:53:55 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0323D1277D2 for ; Tue, 5 Mar 2019 11:53:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=raszuk.net 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 KO4YYtPgrz87 for ; Tue, 5 Mar 2019 11:53:52 -0800 (PST) Received: from mail-qk1-x736.google.com (mail-qk1-x736.google.com [IPv6:2607:f8b0:4864:20::736]) (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 BE6F1126C15 for ; Tue, 5 Mar 2019 11:53:51 -0800 (PST) Received: by mail-qk1-x736.google.com with SMTP id f196so5443892qke.10 for ; Tue, 05 Mar 2019 11:53:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JvINW1Oq6bUzlNarUHcne5R7u+N1V6y+4fhaPg6NZWQ=; b=DY5T/8u+X6hj98WvXBSih6oA7SuRiCsTQ791iEv1r0a8aEW61qzTi/16zx71OO6/mS Gp/duNGTnPxiSwCdLyiBhSj68UiEu58wIXnJf4qUw8zkFULDK7/aAsdF6tOpBs9nOQP5 EmS9dvJZwQNjDlUvkq7+iPT04Ik4ZWj7pQht+4kcAdHqEcnK90LJBsFaUbhrwQ7/WWOd bZg11zRD2J+7WqWZ9oXQDWk9LDOl51H0zJGJ5TXY+G30soTNCgiwyOfKyO5owkT07j/f xQf8jI1ux6F1sBK7+KnAzO93/pT7kCyysTUjCRaayHNLv5T4WRSfTKqOwrOB526gSy9O xUHA== 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=JvINW1Oq6bUzlNarUHcne5R7u+N1V6y+4fhaPg6NZWQ=; b=Slbsoz1GU/FqESO31aJBC3M2xmvxgunCBVWOhb+9/62n5OX+j0MeTbj25mI4U1OPwg 9jP10uI4CR5bXz/PV9vyKmyxKwKVZmyJTGXwcyokqnlUlm+yJMsn7q4MFAmfeySXcvSD vBR9T8nkZBlnpuYlNNsnbQ2ZNo/tp7Mzgk6gR+Owy9JTM0IqXQVQB87wajvvuRNKfH2Z 7yBQq0FwwU1Jgq3s5RflxjXzCr1hrfuUE0q+Wkcu/6vInXr68/VcYlSx0n4+8hNqkDZ2 AaJpA8dOUj/8hzmFl2kRdChJ0Ygyv1gBti+wsmEfyTKbB459/4bq+nQYCGhRUG6jbRQ4 0XHA== X-Gm-Message-State: APjAAAXRHoL6Cp43X6ty0ig3047R6/ziMnBlZW4pnQroopWYk/0aHRDA 068VLjNUwhNIf0akRKnQbTGdzaIuFGdXtHvmCkkSzsGR X-Google-Smtp-Source: APXvYqwMj3BvZiui7TTDS12s2Aoa6SOfIUgj+1fSnGq2iXlweZCTJXV3dJTBTxT8CjlbucP3llwsvhy0iTveep6R/zE= X-Received: by 2002:a37:bc04:: with SMTP id m4mr2999497qkf.41.1551815630685; Tue, 05 Mar 2019 11:53:50 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Robert Raszuk Date: Tue, 5 Mar 2019 20:53:39 +0100 Message-ID: To: Tony Przygienda Cc: Peter Psenak , lsr@ietf.org, Tony Li Content-Type: multipart/related; boundary="0000000000006d20c805835e3b94" Archived-At: Subject: Re: [Lsr] Open issues with Dynamic Flooding X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 19:53:54 -0000 --0000000000006d20c805835e3b94 Content-Type: multipart/alternative; boundary="0000000000006d20c605835e3b93" --0000000000006d20c605835e3b93 Content-Type: text/plain; charset="UTF-8" Tony-P, I am not talking about LAGs but pure vanilla L3 ECMP paths in any DC. Any node will be receiving at least two copies of flooded topology (regardless in which direction you look up or down) so when one of the links is broken which is used for actual flooding or peer sending link state info goes down flooding graph can be repaired at its own pace while data plane is not impacted as there are many more L3 paths still available. That was my point. Thx, r. On Tue, Mar 5, 2019 at 8:36 PM Tony Przygienda wrote: > > > On Tue, Mar 5, 2019 at 11:12 AM Robert Raszuk wrote: > >> >> > Slow convergence is obviously not a good thing >> >> Could you please kindly elaborate why ? >> >> With tons of ECMP in DCs or with number of mechanism for very fast data >> plane repairs in WAN (well beyond FRR) IMHO any protocol *fast convergence* >> is no longer a necessity. Yet many folks still talk about it like the only >> possible rescue ... >> >> >> > Agree on FRR in WAN but it seems quite a complexity to drag that into DC > fabrics (again, depeneding what topologies talk about) especially due to > the effect I outline below. > > ECMP in DCs when used AFAIS is often caused by walking the 10G-50G curve > where everybody has different economic sweet-spots AFAIS. Sometimes 100G. > It's often LAG'ed (due to amount of control plane state AFAIU). LAG'ing > generally creates interesting problems itself and I expect whole thing to > settle somewhere with 20-50G to the server over either very short copper or > multimode. I do not think it's a particularly cool architecture to suggest > "LAG every link so it's 1:1 protected". > > Wide fanout is common & will get wider AFAIS. This is cool for failures in > one direction but doesn't prevent you from blackholing on the "far end" > until you get control plane reconvergence (or do FRR on a spine but > honestly, how do you do that, bow-tieing over top of fabric or doing > harmonica routing over multi-homed servers?) > > Then, slow convergence means that new stuff shows up slowly which is > probably not very desirable and in case of failures that really need > control plane rerouting causes longer duration blackholes as well. Both > seem undesirable .. Not mentioning mobility even ... > > my > > [image: CodeCogsEqn(17).gif] cents ;-) > > --- tony > > > --0000000000006d20c605835e3b93 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Tony-P,=C2=A0

I am not talking about LA= Gs but pure vanilla L3 ECMP paths in any DC.=C2=A0

Any node will be receiving at least two copies of flooded topology (regard= less in which direction you look up or down) so when one of the links is br= oken which is used for actual flooding or peer sending link state info goes= down flooding graph can be repaired at its own pace while data plane is no= t impacted as there are many more L3 paths still available.=C2=A0

That was my point.=C2=A0

Thx,
r.

On Tue, Mar 5, 2019 at 8:36 PM Tony Przygienda <tonysietf@gmail.com&g= t; wrote:


On Tue, Mar 5, 2019 at 11:12 AM Robert Rasz= uk <robert@raszuk= .net> wrote:

> Slow convergence is obviously not = a good thing

Could you please kindly elaborate why ?=C2= =A0

With tons of ECMP in DCs or with number of mec= hanism for very fast data plane repairs in WAN (well beyond FRR) IMHO any p= rotocol *fast convergence* is no longer a necessity. Yet many folks still t= alk about it like the only possible rescue ...=C2=A0



Agree on FRR in WAN but it seems q= uite a complexity to drag that into DC fabrics (again, depeneding what topo= logies talk about) especially due to the effect I outline below.
=

ECMP in DCs when used AFAIS is often caused by walking= the 10G-50G curve where everybody has different economic sweet-spots AFAIS= . Sometimes 100G.=20 It's often LAG'ed (due to amount of control plane state AFAIU). LAG= 'ing generally creates interesting problems itself and I expect whole t= hing to settle=20 somewhere with 20-50G to the server over either very short copper or=20 multimode. I do not think it's a particularly cool architecture to sugg= est "LAG every link so it's 1:1 protected".
Wide fanout is common & will get wider AFAIS. This is cool= for failures in one direction but doesn't prevent you from blackholing= on the "far end" until you get control plane reconvergence (or d= o FRR on a spine but honestly, how do you do that, bow-tieing over top of f= abric or doing harmonica routing over multi-homed servers?)
<= br>
Then, slow convergence means that new stuff shows up slowly w= hich is probably not very desirable and in case of failures that really nee= d control plane rerouting causes longer duration blackholes as well. Both s= eem undesirable .. Not mentioning mobility even ...

my

3D"Code==C2=A0=C2=A0 cents ;-)

--- tony


--0000000000006d20c605835e3b93-- --0000000000006d20c805835e3b94 Content-Type: image/gif; name="CodeCogsEqn(17).gif" Content-Disposition: inline; filename="CodeCogsEqn(17).gif" Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: ii_jsw699y30 R0lGODlhfQAuALMAAP///wAAAMzMzERERIiIiGZmZpiYmNzc3O7u7nZ2djIyMiIiIqqqqlRUVBAQ ELq6uiH5BAEAAAAALAAAAAB9AC4AAAT+EMhJq70YnJG7/2AojmRlJEuprmzrHqkrz7QM13iuS4Vh ULedcFjqEQKHSZAoQgwezBkigDgkgLGox2oIQLWthOKyBHu8ZtbiWnkUAoRkOoOek6YMu6quD3Xl fSJ8gR4NAYQjg4gYDhyLIIqPQAFskh2RlgBdeZl0X50ThoBECD8tmAYIjwuHKgcEIwUVryEICQMB CgkCFQiyHQcNozpTjiQJDqYgBLwTyMoyD7AYAgMOTA+UKwvDHWMV3DjfGAwNTAkBnHfXftAACOw1 BOoWPUy43SDlIgPD+zgCzGEIR8RBqxINlDEgQKCUgQafAMQLZWphQx8QV0wEwJABg3j+DE48CCnM Ri6NchA8OBCg4jiJFhwkUcnS5YqDAAaYaiBwpQYHeRw0a8EgwC8SB+JBYZCFgLEyPyUsbWqMxAJV msYllMDpwcRqA8KKFTutAzp3IQgInFCgUoOyUNVSaBuqLIAAePPqxQngqoRkE2RWSLB2Bq6I/Nw5 +IRkArwKOiksntBYBTuWcgRsBKAAbQuDWEkgqSKB5QSmAD5tHJ3ENNcUiEOwE3DQaWrHlWOXmJJl xBRNEwyMo1u2H27gWdlesRsiYGBVB3Rp8qqplYB8JLIdPWZAXQJlAhI0DA7tO6fvE8KPJzFvwoME HoM1FFCAgQAG8HWXOOJ5h5MoL82eIYoZuxDxQH9aLLAZE9vl4AshAVSlRSlCpBIIbcyBoiEGXei3 YUgJjPQQdna8sSEGPiUV1FCIKBDgiVxJtSAi2qRHgAEZdkJYJyyx+I0PMHbWiQETPSBQNSdOIYeH cwywnVxRdUJdFxJcJ0kALBLwi2uZ0GcffgwwqYUCsjxUAZSawWhJZwj4RcEDjsCppiU+hEbBNzfO OWd4J+gpRAQAOw== --0000000000006d20c805835e3b94-- From nobody Tue Mar 5 12:18:02 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01D04126F72 for ; Tue, 5 Mar 2019 12:18:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 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 OsK90v5_uidz for ; Tue, 5 Mar 2019 12:17:59 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27F74126C15 for ; Tue, 5 Mar 2019 12:17:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5730; q=dns/txt; s=iport; t=1551817079; x=1553026679; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=6btcMi/5IDq1wPB4C94Py86MJVpyk+P4mmYCjkfTxVA=; b=TUr5Gb0a6f6aun5l8uiumWy+tdFvfggC0DbBjhDvOn2vrqWExbK2Xd4J vRd2tAx21/6Z7IcQMq2g6kZz1fToIVjordY2A/fcBz94mYh3sSiFbL8Cw ftJp2wLOp/OMPVcthiOT7Hkb0+2JfBVAkLaI5bLegIYOr12RGadJ/i9Ch s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APAADQ2H5c/xbLJq1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVAEBAQEBAQsBgWWBEoEDJ4QIiHmMeHyIMpBuDRgLhEk?= =?us-ascii?q?ChE43Bg0BAQMBAQMBAwJtHAyFSgEBAQECAQEBIQ8BBTYLEAsYAgIjAwICIQY?= =?us-ascii?q?fEQYBDAYCAQEXgwcBgV0DDQgPqzSBL4VEgkENghkFgQskAYs+gUA/gREngjY?= =?us-ascii?q?HLoJXRwEBgTqDMYJXAopCjHiMGjMJjzeDNwYZgXSFZIMiiC2KZYcKi0OBXSK?= =?us-ascii?q?BVjMaCBsVO4Jsgy0BCYYHgU6FQD4DMI5IKoIjAQE?= X-IronPort-AV: E=Sophos;i="5.58,445,1544486400"; d="scan'208";a="10560876" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Mar 2019 20:17:56 +0000 Received: from [10.60.140.54] (ams-ppsenak-nitro5.cisco.com [10.60.140.54]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id x25KHtNY009107; Tue, 5 Mar 2019 20:17:56 GMT To: Robert Raszuk , Tony Przygienda References: Cc: lsr@ietf.org, Tony Li From: Peter Psenak Message-ID: <41bd7097-0d25-a2e0-843d-cb25fd13a84f@cisco.com> Date: Tue, 5 Mar 2019 21:17:55 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Outbound-SMTP-Client: 10.60.140.54, ams-ppsenak-nitro5.cisco.com X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [Lsr] Open issues with Dynamic Flooding X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 20:18:02 -0000 Robert, On 05/03/2019 20:12 , Robert Raszuk wrote: > >> Slow convergence is obviously not a good thing > > Could you please kindly elaborate why ? > > With tons of ECMP in DCs or with number of mechanism for very fast data > plane repairs in WAN (well beyond FRR) IMHO any protocol *fast > convergence* is no longer a necessity. Yet many folks still talk about > it like the only possible rescue ... we are talking about the control plane convergence, not data plane one. If the flooding topology is subset of the real topology, then at the flooding level you don't have all the ECMPs available - you only have two paths to reach any node. In such case it is possible that the flooding topology gets partitioned and you want to get out of that state quickly, as you may get out of sync with the the reality and eventually loose all the data plane ECMPs as a consequence. thanks, Peter > > > On Tue, Mar 5, 2019 at 5:42 PM Tony Przygienda > wrote: > > in practical terms +1 to Peter's take here ... Unless we're talking > tons of failures simultaneously (which AFAI talked to folks are not > that common but can sometimes happen in DCs BTW due to weird things) > smaller scale failures with few links would cause potentially > diffused "chaining" of convergence behavior rather than IGP-style > fast healing (and on top of that I didn't see a lot of interest in > formalizing a rigorous distributed algorithm which IMO would be > necessary to ensure ultimate convergence when only one/subset of > links is used). Slow convergence is obviously not a good thing > unless we assume people will run FRR with its complexity in DC > and/or no more than one link every fails which seems to me bending > assumptions to whatever solution is available/preferred. To Tony's > point though, on large scale failures enabling all links would cause > heavy flood load, yes, but in a sense it's the "initial bootup" case > anyway (especially in centralized case) since nodes need all > topology to make informed correct decisions about what the FT should > be if they don't rely on whatever the centralized instance thinks > (which they won't be able to do given the FT from centralized > instance will indicate lots links that are "gone" due to failure). > As to p2p, I suggest to agree whether you use dense mesh (DC) case > or sparse mesh (WAN) case or "every topology imaginable" since that > drives lots design trade-offs. > > my 2.71828182 cents ;-) > > --- tony > > On Tue, Mar 5, 2019 at 8:27 AM Peter Psenak > wrote: > > Hi Tony, > > On 05/03/2019 17:16 , tony.li@tony.li > wrote: > > > > Peter, > > > >>> (a) Temporarily add all of the links that would appear to > remedy the partition. This has the advantage that it is very > likely to heal the partition and will do so in the minimal > amount of convergence time. > >> > >> I prefer (a) because of the faster convergence. > >> Adding all links on a single node to the flooding topology is > not going to cause issues to flooding IMHO. > > > > > > Could you (or John) please explain your rationale behind that? > It seems counter-intuitive. > > it's limited to the links on a single node. From all the practical > purposes I don't expect single node to have thousands of > adjacencies, at > least not in the DC topologies for which the dynamic flooding is > being > primary invented. > > In the environments with large number of adjacencies (e.g. > hub-and-spoke) it is likely that we would have to make all these > links > part of the flooding topology anyway, because the spoke is > typically > dual attached to two hubs only. And the incremental adjacency > bringup is > something that an implementation may already support. > > > > > > > > >> given that the flooding on the LAN in both OSPF and ISIS is > done as multicast, there is currently no way to enable flooding, > either permanent or temporary, towards a subset of the neighbors > on the LAN. So if the flooding is enabled on a LAN it is done > towards all routers connected to the it.. > > > > > > Agreed. > > > > > >> Given that all links between routers are p2p these days, I > would vote for simplicity and make the LAN always part of the FT. > > > > > > I’m not on board with this yet. Our simulations suggest that > this is not necessarily optimal. There are lots of topologies > (e..g., parallel LANs) where this blanket approach is suboptimal. > > the question is how much are true LANs used as transit links in > today's > networks. > > thanks, > Peter > > > > > Tony > > > > . > > > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > From nobody Tue Mar 5 12:26:22 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76D1C129508 for ; Tue, 5 Mar 2019 12:26:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 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 ydU4PPnKOoRw for ; Tue, 5 Mar 2019 12:26:19 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AD6B130DEA for ; Tue, 5 Mar 2019 12:26:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2644; q=dns/txt; s=iport; t=1551817580; x=1553027180; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=wxTjwJZMn73S0TJA11SSWE9CTpabq1bwzkLuCKkikhc=; b=W/O7vTIV5cy+R7Wxlk0U3dxWhacRpjmQ5VK2AYdTGWzyr2bEsMlHH0Jp g9e99eCFP7Di8/hcMTmQtqPrDck11P3GUma4mY5OCzusRA/9iQPhhbw+H xItYQa6aMFfZGBIGf1Ibp9zVXWZVxiJtjD2hmEsmJkYPuQntlRT5E9JLl k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AOAAAq235c/xbLJq1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBVAEBAQEBAQsBgWCCGieECIh5jHiaHA2EbAKETjcGDQE?= =?us-ascii?q?BAwEBAwEDAm0cDIVKAQEBAQIBDhUPAQUtFBALGAICJgICVxMGAgEBgx6Bbgi?= =?us-ascii?q?rQ4EvhUSEbIELJAGLPoFAP4ERJ4I9LoRadII9glcCikKZRQmSbgYZgXSFZIM?= =?us-ascii?q?iiC2dMoFdIoFWMxoIGxWDJ4k+hw4+AzCOSCqCIwEB?= X-IronPort-AV: E=Sophos;i="5.58,445,1544486400"; d="scan'208";a="10561034" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Mar 2019 20:26:18 +0000 Received: from [10.60.140.54] (ams-ppsenak-nitro5.cisco.com [10.60.140.54]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id x25KQGmo001012; Tue, 5 Mar 2019 20:26:17 GMT To: tony.li@tony.li References: <966E5756-8CEF-47F4-8564-E23D38F0743E@tony.li> Cc: lsr@ietf.org From: Peter Psenak Message-ID: Date: Tue, 5 Mar 2019 21:26:16 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <966E5756-8CEF-47F4-8564-E23D38F0743E@tony.li> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Outbound-SMTP-Client: 10.60.140.54, ams-ppsenak-nitro5.cisco.com X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Lsr] Open issues with Dynamic Flooding X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 20:26:21 -0000 Hi Tony, On 05/03/2019 17:47 , tony.li@tony.li wrote: > > Hi Peter, > >>>> Adding all links on a single node to the flooding topology is not >>>> going to cause issues to flooding IMHO. >>> >>> >>> Could you (or John) please explain your rationale behind that? It >>> seems counter-intuitive. >> >> it's limited to the links on a single node. From all the practical >> purposes I don't expect single node to have thousands of adjacencies, >> at least not in the DC topologies for which the dynamic flooding is >> being primary invented. > > > What if the node in question is one of the spines? Folks are building > systems that large… and it seems inevitable that port counts will only > grow. Toto, I don’t think that’s an AGS any more…. ;-) > > >> In the environments with large number of adjacencies (e.g. >> hub-and-spoke) it is likely that we would have to make all these links >> part of the flooding topology anyway, because the spoke is typically >> dual attached to two hubs only. And the incremental adjacency bringup >> is something that an implementation may already support. > > > LS topologies can have a very large number of adjacencies as well, > typically with multiple spines, so for a new spine, all of the of the > links may be unnecessary. ok, we talked bout the balance before - adding one link at a time to the FT may result in slow recovery, while adding all link is claimed to be dangerous. What is the right number? I feel that the increment value can be something that the implementation can choose or even make configurable, so the user can decide based on the particular topology and scale. We are not going to find the magic value I'm afraid. > > >>> Our simulations suggest that this is not necessarily optimal. There >>> are lots of topologies (e.g., parallel LANs) where this blanket >>> approach is suboptimal. >> >> the question is how much are true LANs used as transit links in >> today's networks. > > > As Xiaohu suggested, the management plane would be an obvious > application. Interconnects also seem likely. I believe his case is completely orthogonal to this discussion as in his case there is a single giant LAN used for flooding and we all know we can not optimize flooding inside a LAN itself. > > Let’s set the algorithmic parts aside. Do you have an objection to > supporting them in the signaling? will get complicated, especially for OSPF/OSPFv3. Also temporary flooding operation on LAN is tricky and sub-optimal. I don't really believe it's worth the complexity. my 2c, Peter > > Tony > From nobody Tue Mar 5 12:48:01 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70EF81311B7 for ; Tue, 5 Mar 2019 12:47:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.88 X-Spam-Level: X-Spam-Status: No, score=-1.88 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.018, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 Et3qOC_71ECu for ; Tue, 5 Mar 2019 12:47:57 -0800 (PST) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (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 6B3671312AE for ; Tue, 5 Mar 2019 12:47:55 -0800 (PST) Received: by mail-pf1-x435.google.com with SMTP id n22so6608114pfa.3 for ; Tue, 05 Mar 2019 12:47:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=R8shvpbS1vp277lebcNi9u/3fmuee+vcOKwd57jxy6E=; b=fc6oYJrXQLCSYD2YWxiJl8Vnb9ZhaU6UcAcpKlhGRAvRfSNHYAUmVqSta7vv/Ofs8/ uH5HHY8QCq4TQLn/CllYDTuAztf403XPg4LYxQ3WDDdOLm8G8dqDbNlzwJ+zpDDM8C2o bONwCf+yy762au7MwbtZh+mUT0XTfEyMTlVkWwWsHKIaXyj5IzWZJb7dv30zO8idSaVV My9M77tSjqPwqNu8rbklXXOxGtw2j1N4kK8JuxLZw4SEnSqN6UIBNJpJ06dbNNFqnZYK 4RAs/udM8/ik6ZEoxk6vfT8uh4E7uZL5XTQpmRy6Lj0HcLZO2coUTozFCP7+3+oiAsXQ 0GWQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=R8shvpbS1vp277lebcNi9u/3fmuee+vcOKwd57jxy6E=; b=lZRyRK6MMJbNZWfH62r8Cp9D7qgx5E3S3hCvuapfFTWJ4pFnQKXl99W4Bwtr2DPdcb Zbr+LIAjXp6Dg13B/f6XcZ3c9EmTqil5TACNrGcQLr4mHRQodbJxmipohyJ4HgyFntib VN8JXN9f+hR70OgD6ZBrHcEg9ByxX2LcF0MVu46S8VUxydkQMyJ8jDRM9l0W0rFe7R2b RadWwU4nnHSkZdwCGJQVfXFdMUeIbOWtfpYCENMbwXFTUCD3VS6jRZcOt7dtHjKWCoIZ 08PC9tcZ7l36C8Bou/llxQoA2xVxosoXMWjuOyF2gHDlmg2svIoEebwc4SAFhfWdnx0N A0ug== X-Gm-Message-State: APjAAAVPf1eDtCTfepFWP8XO4sM4A3BTgHpE88s+8cGFw4TUNzI4nkbv xBid2VWzAS+gzv7rumEF6no= X-Google-Smtp-Source: APXvYqyYuGOdugg8nzht50QqQLdz3nUQ536+7QknjsLc481spDQF+0HHP2SUC+6q3meelDPLNgIfxg== X-Received: by 2002:a17:902:9f94:: with SMTP id g20mr3273177plq.0.1551818874804; Tue, 05 Mar 2019 12:47:54 -0800 (PST) Received: from [172.22.228.48] ([162.210.130.3]) by smtp.gmail.com with ESMTPSA id y6sm20188958pfy.87.2019.03.05.12.47.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Mar 2019 12:47:54 -0800 (PST) Sender: Tony Li From: tony.li@tony.li Message-Id: <7F522B6C-9D28-4533-8ABD-9F492D9AF26C@tony.li> Content-Type: multipart/alternative; boundary="Apple-Mail=_30BF76D6-CDE1-45BA-8CD1-DFF890268B5E" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Tue, 5 Mar 2019 12:47:53 -0800 In-Reply-To: Cc: lsr@ietf.org To: Peter Psenak References: <966E5756-8CEF-47F4-8564-E23D38F0743E@tony.li> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Lsr] Open issues with Dynamic Flooding X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 20:48:00 -0000 --Apple-Mail=_30BF76D6-CDE1-45BA-8CD1-DFF890268B5E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 >> LS topologies can have a very large number of adjacencies as well, >> typically with multiple spines, so for a new spine, all of the of the >> links may be unnecessary. >=20 > ok, we talked bout the balance before - adding one link at a time to = the FT may result in slow recovery, while adding all link is claimed to = be dangerous. What is the right number? I feel that the increment value = can be something that the implementation can choose or even make = configurable, so the user can decide based on the particular topology = and scale. We are not going to find the magic value I'm afraid. I agree that optimal is probably unknowable. The question then is what = do we say in the document? How about something about rate limiting? >> Let=E2=80=99s set the algorithmic parts aside. Do you have an = objection to >> supporting them in the signaling? >=20 > will get complicated, especially for OSPF/OSPFv3. I have great confidence in you. ;-) > Also temporary flooding operation on LAN is tricky and sub-optimal. I = don't really believe it's worth the complexity. Ok, I=E2=80=99m not following this. It seems like one system would = request flooding and the other nodes would comply. Where=E2=80=99s this = tricky? Tony --Apple-Mail=_30BF76D6-CDE1-45BA-8CD1-DFF890268B5E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
LS = topologies can have a very large number of adjacencies as well,
typically with multiple spines, so for a new spine, all of = the of the
links may be unnecessary.

ok, we talked bout the balance before - adding one link at a = time to the FT may result in slow recovery, while adding all link is = claimed to be dangerous. What is the right number? I feel that the = increment value can be something that the implementation can choose or = even make configurable, so the user can decide based on the particular = topology and scale. We are not going to find the magic value I'm = afraid.



I agree that optimal is = probably unknowable. The question then is what do we say in the = document?  How about something about rate limiting?


Let=E2=80= =99s set the algorithmic parts aside.  Do you have an objection = to
supporting them in the signaling?

will get complicated, especially for OSPF/OSPFv3. =


I have great confidence in you. ;-)


Also = temporary flooding operation on LAN is tricky and sub-optimal. I don't = really believe it's worth the complexity.


Ok, = I=E2=80=99m not following this.  It seems like one system would = request flooding and the other nodes would comply.  Where=E2=80=99s = this tricky?

Tony


= --Apple-Mail=_30BF76D6-CDE1-45BA-8CD1-DFF890268B5E-- From nobody Tue Mar 5 12:48:52 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA1C1312BD; Tue, 5 Mar 2019 12:48:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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=QKI3ofbT; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=EqdTsf9F 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 3Y14nPBBLyeS; Tue, 5 Mar 2019 12:48:48 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27939131294; Tue, 5 Mar 2019 12:48:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4738; q=dns/txt; s=iport; t=1551818928; x=1553028528; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=S0IU2yQiegLWXlpXq+Z5pI3Wqa7bI6FqPV4PtiPQ730=; b=QKI3ofbTG5vbqALakp0802SJ6s2+UOjN48sS25Bx8sfkTE4TvQRl0Tn/ mmUXrSKOvAvXk+iOrJGFuRBTxq3l9kpouiIR4tC0VT/IgBa8ExNWpp7+s GLGtdWB5S2LjUsUVYpFptoIb6kGA5mzUjKKq77/to6n5tisEvpyD7T7dx Q=; IronPort-PHdr: =?us-ascii?q?9a23=3Afi5I3h++8yWjvv9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+8ZR7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfk0jgZdYBUER?= =?us-ascii?q?oMiMEYhQslVcGED1bxIeTlRyc7B89FElRi+iLzPA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAAB0335c/5FdJa1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgTxQA4FcBAsnh08DhFCLAIJXmCEUgRA?= =?us-ascii?q?DVAsBASyEQAKELCI0CQ0BAQMBAQMBAwJtHAyFSgEBAQEDOgYBATcBCwICAgE?= =?us-ascii?q?IEQEDAQEBHhAWHBcGCAIEDgUIhHgDFQECoDECihSCIIJ4AQEFhQYYggsIBYE?= =?us-ascii?q?qAYsnF4FAP4EQR4JMhE4BEgEhBR8SgwOCJol6GTGZRQkCiFuKMIF0hWSLT4t?= =?us-ascii?q?3kRQCBAIEBQINAQEFgUc4ZXFwFYMnggoMF4NLilNygSiNL4I+AQE?= X-IronPort-AV: E=Sophos;i="5.58,445,1544486400"; d="scan'208";a="529617154" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Mar 2019 20:48:46 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id x25Kmk0E004897 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 5 Mar 2019 20:48:46 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 5 Mar 2019 14:48:45 -0600 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 5 Mar 2019 14:48:45 -0600 Received: from NAM04-CO1-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.1473.3 via Frontend Transport; Tue, 5 Mar 2019 15:48:45 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ueaezSH2cBUnJwaqir/YA6i2w5Ffq6DMM/Wq8jPz1ao=; b=EqdTsf9FXDpOG80UThN4dPz7YjFzmsepcB3I1jqwSJpNEbFDG5eLXI6Hj4VGWV+Bt2uEO5putb6dL3XXvetDtT3S6N89sUx22BUBFvBfFDjgSqW/o3g37u2jyMXJJjQ18r1dyAl6Ef66ji7xlEFFLiVtwArOaIkFXPrSSAXu46Q= Received: from BYAPR11MB3638.namprd11.prod.outlook.com (20.178.237.19) by BYAPR11MB2584.namprd11.prod.outlook.com (52.135.227.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.18; Tue, 5 Mar 2019 20:48:44 +0000 Received: from BYAPR11MB3638.namprd11.prod.outlook.com ([fe80::b414:f534:f20a:a26d]) by BYAPR11MB3638.namprd11.prod.outlook.com ([fe80::b414:f534:f20a:a26d%3]) with mapi id 15.20.1686.016; Tue, 5 Mar 2019 20:48:44 +0000 From: "Les Ginsberg (ginsberg)" To: Alexander Vainshtein CC: "lsr@ietf.org" , "spring@ietf.org" , "draft-ietf-isis-segment-routing-extensions.all@ietf.org" , "Peter Psenak (ppsenak)" Thread-Topic: [spring] FlexAlgo and Global Adj-SIDs Thread-Index: AdTPjdP9QRfJ5GzARfmqN1/BpEhW0gAEem2AAGBozJQAkaz8AAABfrsgAAC21FAAAD2n8AAIi81A Date: Tue, 5 Mar 2019 20:48:43 +0000 Message-ID: References: <20493a62-cf70-a182-900d-e55dd68f5149@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ginsberg@cisco.com; x-originating-ip: [2001:420:30d:1254:8012:e90b:7af9:9084] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 914201fe-4b8c-447d-dc0b-08d6a1abf4f0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BYAPR11MB2584; x-ms-traffictypediagnostic: BYAPR11MB2584: x-ld-processed: 5ae1af62-9505-4097-a69a-c1553ef7840e,ExtAddr x-microsoft-exchange-diagnostics: =?us-ascii?Q?1; BYAPR11MB2584; 23:kjl0WhpsKCRXFHWtagRsuokOeJE3DwhWSJtTCnejI?= =?us-ascii?Q?qz8+gQ2Cjoa+ghy56XO8fz3VxGW4O2rwAN5wR5E0jYf4BEeH6xlkr1SvM9HA?= =?us-ascii?Q?J0dKrkm1ZIG4o48s8u8HZaMcfw7XwApZzWXh8GSuNqEsZBVoaA8hQXEv0XiF?= =?us-ascii?Q?W9Dr39wDqNXUW54GmeDtvtX4AihHwrnfAJEXh7mRM44pDKrTAUIzSp9hzw7D?= =?us-ascii?Q?CAYvb7NPsbWilee1F7SF096kvG4yvzehqPt0KtpZO3Is1nGyk6mj7oePO5hc?= =?us-ascii?Q?pNcGm/iZyc7KjcaCiyU79e58wiMUb+/4AJIli6yTf8BfEmlHt8/F3EqQGx0S?= =?us-ascii?Q?+EDryEaTb3xcs+L5aRVqH0rBiCiyX+T8mjcl+/6ni5sdWgrTiZpxHHkDR0oy?= =?us-ascii?Q?X6cEz4vQizJQuuhe+OFsGF3IwqTRj8untR4PzDDhstFDU7cwT3L3e//JGGEh?= =?us-ascii?Q?XV6ALKhnn+1QDfshlmIIezsRID7gAsHYcIeW//N8u4npsTbPbvByOd3Wg+w9?= =?us-ascii?Q?R5Kb5p1tQD6XY+BdIMYGjfRgCUQSAlMpAouHwihR/B2ExY5ItYTUzZYwALYw?= =?us-ascii?Q?bDDjdpmujc/GtHr0HmxMKGGScsIet3Lt+2QUDiQGuXdIUxIFcPUGz7IIfSVP?= =?us-ascii?Q?KFEDgyDZN6SoCZbQaCRtg+jWI5sPYXPYzdIC9CnSU6KpIP/L3MoxULHRpaQx?= =?us-ascii?Q?mrm0niuLVAFaUN5k8v9fbkTcfbyHUy78ZU3Z9gV86wVLVD3wc81qcNGfSloA?= =?us-ascii?Q?Io46x0Y0Zd3MupCaALNm4ecbkzHWt0GFZQWH7knb/xlCmQGcGxNO/Byxbw9F?= =?us-ascii?Q?3t0elxTC9NISrMeGP0fbiq+bg5ERmTY9iog+PXQ1+CorPzh6Ft941DF8xjb7?= =?us-ascii?Q?8sbObUQMFWwjT7+Rw9j3tjw0ustHTzXLf6s7+ONk07hj0KXoTeD2HUSMJRZ3?= =?us-ascii?Q?fx7xlWYFqRM/S52qCL20Ogp/74yBdT6AVgqm7utXJPjn7a3PZyQCqb2fz5No?= =?us-ascii?Q?yiRKlGWmkwE19G7Tl4T+tnO7nIy+D5bhyiysapSBGSQHaqwI9/z39s5y5IHu?= =?us-ascii?Q?ma0sgSmyeRhbCpVxpHI/vS+a7k4p1NmLJOnm3z2HjDV37oXCeseB21OPGYUv?= =?us-ascii?Q?dwYNTuHjZFiARIrFUqQt+bx67nvlaILXpmyZesyp6sLuo7d+72kCSpUxNhHu?= =?us-ascii?Q?IFMhED8DVg0bwjWqXZhTINMdT3vcn6R6Tk+TSVnRx6pXY7E/EBYNjuk5ewu6?= =?us-ascii?Q?7ax9S61jsYsfg08V/aMgSgwIQ5o7T1dTl0EMPxXgCHUSOi/fRV5/NF51vMdD?= =?us-ascii?B?QT09?= x-microsoft-antispam-prvs: x-forefront-prvs: 0967749BC1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(39860400002)(376002)(136003)(366004)(13464003)(189003)(199004)(51874003)(486006)(107886003)(4326008)(6246003)(478600001)(476003)(256004)(14444005)(54906003)(25786009)(99286004)(316002)(68736007)(11346002)(7696005)(446003)(33656002)(6436002)(8936002)(106356001)(9686003)(6916009)(53936002)(55016002)(2906002)(186003)(46003)(53546011)(6506007)(102836004)(305945005)(7736002)(76176011)(81166006)(229853002)(74316002)(6116002)(105586002)(14454004)(81156014)(8676002)(71190400001)(71200400001)(86362001)(5660300002)(52536013)(97736004)(93886005); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB2584; H:BYAPR11MB3638.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: nuF58+2g6GEq5DEEqOCN5PVGjNmc5efnhRzBrfNzf/tX8LFuoG9IPggDPyoOFnJIG0t6lUCBD1cdrJNyjYoGS7bOUUYtNSQfebA+onEO5qGmoitYbbc0u+FQ9LtL1NwYz2TXnDcRl8klw/1m+YFPXUiNTqc5XIhqC5JCIjLFULWzeSqj/9SeuRElkiHH/xIfz4zMN15rXNPWQOIRY9fyUzeadqp3UqWZx+DBJrYfyfQzglZNnQ23dqNOQbphEIh3I1ZNcj2SVvpBcLExDZsV4Nd0PCwWMRR8sMWCeT6x1b/ff6Kr6CMz39j8GCXx1UouDayHwJ75Itexu7Z/SxxXTvcmzeiB/pRnQfiRRXnYXfwHfsaw4mpnZIDzSL1zmMuDQUlWzT9UhrfpWBXJblCu13fdx0/uNZAZsuGGUVejXxg= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 914201fe-4b8c-447d-dc0b-08d6a1abf4f0 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2019 20:48:43.8467 (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-Transport-CrossTenantHeadersStamped: BYAPR11MB2584 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: rcdn-core-9.cisco.com Archived-At: Subject: Re: [Lsr] [spring] FlexAlgo and Global Adj-SIDs X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 20:48:51 -0000 Sasha - Although you raise a valid issue, I am not feeling any urgency here i.e., a= lthough the local protected use case is valid I don't see it as operational= ly critical. However, that's just my opinion. If you want to pursue this I think you could raise the issue in either LSR = or SPRING (or both). The gap in the architecture documents is less important than coming to cons= ensus on the importance of the use case. If there is consensus to address = this then I think deciding what documents need updating will just follow lo= gically. Make sense to you? Les > -----Original Message----- > From: Alexander Vainshtein > Sent: Tuesday, March 05, 2019 8:47 AM > To: Les Ginsberg (ginsberg) > Cc: lsr@ietf.org; spring@ietf.org; draft-ietf-isis-segment-routing- > extensions.all@ietf.org; Peter Psenak (ppsenak) > Subject: RE: [spring] FlexAlgo and Global Adj-SIDs >=20 > Les, > Lots of thanks for a prompt response. >=20 > I fully understand that the current SR extension drafts are too far advan= ced > for any significant changes. >=20 > I also understand that Algo-specific Adj-SIDs require an update to RFC 84= 02 > because today it does not recognize any such entities. > Therefore the discussion of use cases should probably start in the SPRING > WG while effective the result would be "just" new Sub-TLV in IS-IS and OS= PF > with the actual work coming to the LSR WG. >=20 > Any ideas as to what would be the best way to start this kind of discussi= ons? >=20 > Regards, > Sasha >=20 > Office: +972-39266302 > Cell: +972-549266302 > Email: Alexander.Vainshtein@ecitele.com >=20 >=20 > -----Original Message----- > From: Les Ginsberg (ginsberg) > Sent: Tuesday, March 5, 2019 6:37 PM > To: Alexander Vainshtein ; Peter > Psenak (ppsenak) > Cc: lsr@ietf.org; spring@ietf.org; draft-ietf-isis-segment-routing- > extensions.all@ietf.org > Subject: RE: [spring] FlexAlgo and Global Adj-SIDs >=20 > Sasha - >=20 > draft-ietf-isis-segment-routing-extensions is currently in AD review - an= d the > companion OSPF document has already been approved and is waiting for a > dependent draft to progress before publication as an RFC. >=20 > It is too late to make significant changes. >=20 > Further, while I agree with both your description and Peter's response, > agreeing that this "could" be done is not equivalent to having consensus = that > it "should" be done. > I think a more complete consideration of the deployment cases and the > usefulness of such an extension should be discussed by the WG before we > decide that we actually want to define such an extension. >=20 > Les >=20 >=20 > > -----Original Message----- > > From: Alexander Vainshtein > > Sent: Tuesday, March 05, 2019 8:29 AM > > To: Peter Psenak (ppsenak) > > Cc: lsr@ietf.org; spring@ietf.org; draft-ietf-isis-segment-routing- > > extensions.all@ietf.org > > Subject: RE: [spring] FlexAlgo and Global Adj-SIDs > > > > Peter, > > Lots of thanks for a prompt and very encouraging response. > > > > Do you think that the new Algo specific Adj-SID sub-TLV could be added > > to the current IS-IS segment Routing Extensions draft, or should be > > handled in a small dedicated document? > > > > Regards, and lots of thanks in advance, Sasha > > > > Office: +972-39266302 > > Cell: +972-549266302 > > Email: Alexander.Vainshtein@ecitele.com > > > > -----Original Message----- > > From: Peter Psenak > > Sent: Tuesday, March 5, 2019 5:28 PM > > To: Alexander Vainshtein > > Cc: lsr@ietf.org; spring@ietf.org; draft-ietf-isis-segment-routing- > > extensions.all@ietf.org > > Subject: Re: [spring] FlexAlgo and Global Adj-SIDs > > > > Hi Sasha, > > > > On 02/03/2019 18:57 , Alexander Vainshtein wrote: > > > Peter, > > > Lots of thanks for a prompt and hivhly informative response. > > > > > > It seems that per-FlexAlgo Adj-SIDs can be useful even if they are > > > local >=20 > __________________________________________________________ > _________________ >=20 > This e-mail message is intended for the recipient only and contains > information which is > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have > received this > transmission in error, please inform us by e-mail, phone or fax, and then > delete the original > and all copies thereof. > __________________________________________________________ > _________________ From nobody Tue Mar 5 12:51:20 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 534B213137D for ; Tue, 5 Mar 2019 12:51:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=Dop+V6WF; dkim=pass (1024-bit key) header.d=ericsson.com header.b=kCwIhzj5 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 uWYP6_pj0gn0 for ; Tue, 5 Mar 2019 12:51:11 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 504851312F9 for ; Tue, 5 Mar 2019 12:51:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1551819068; x=1554411068; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=SVbYLTvdmnJrIbjxMJstNsAh5SEbZFJbFhofBDJY1hM=; b=Dop+V6WFe4/F36jUuqYqrj5/08E2qIer6DEJz5hHgVYvgeGprIu9IxNo25tLqncp N7wq8yTLN8Kh6RXTxBvl+kVC0oY0ule2swk4d6fqXXI138Gkj2dBTJc3TBi4Qcqc moAPuTdQxS5zMxQtKsILtxd41q0uB3FbwGCT0DPiF4w=; X-AuditID: c1b4fb3a-14fff7000000672c-35-5c7ee13c0a1c Received: from ESESSMB502.ericsson.se (Unknown_Domain [153.88.183.120]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id DF.9D.26412.C31EE7C5; Tue, 5 Mar 2019 21:51:08 +0100 (CET) Received: from ESESBMB502.ericsson.se (153.88.183.169) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 5 Mar 2019 21:51:08 +0100 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (153.88.183.157) by ESESBMB502.ericsson.se (153.88.183.169) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Tue, 5 Mar 2019 21:51:08 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=SVbYLTvdmnJrIbjxMJstNsAh5SEbZFJbFhofBDJY1hM=; b=kCwIhzj5ZYdIe8p8eCGdxDdEuxjxY3uCxVPaSKajTfPM2Qc3BqYvvpBIdeHilMd59QzGckJXvaalDBvLSzZIrHvKH6yxQkpDKhof9mDsdCkgT/J1bhZm+08Mn/3PHPDX1gO6qWuN5zftFlZQAqrqecBf9+CbK+0z3Ac4NudNPm8= Received: from BYAPR15MB3078.namprd15.prod.outlook.com (20.178.239.16) by BYAPR15MB3029.namprd15.prod.outlook.com (20.178.238.90) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.16; Tue, 5 Mar 2019 20:51:05 +0000 Received: from BYAPR15MB3078.namprd15.prod.outlook.com ([fe80::f149:ac42:91ed:98d]) by BYAPR15MB3078.namprd15.prod.outlook.com ([fe80::f149:ac42:91ed:98d%4]) with mapi id 15.20.1665.020; Tue, 5 Mar 2019 20:51:05 +0000 From: David Allan I To: "ppsenak@cisco.com" , "tony.li@tony.li" CC: "lsr@ietf.org" Thread-Topic: [Lsr] Open issues with Dynamic Flooding Thread-Index: AQHU0rNkTwZFDYjuJkyaA7EXxtPtc6X8p2UAgACQ6YCAAALpAIAABY6AgAA9MgCAAAV5IA== Date: Tue, 5 Mar 2019 20:51:05 +0000 Message-ID: References: <966E5756-8CEF-47F4-8564-E23D38F0743E@tony.li> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.i.allan@ericsson.com; x-originating-ip: [216.154.61.166] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fa909c10-f49f-4a7d-0ede-08d6a1ac497b x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BYAPR15MB3029; x-ms-traffictypediagnostic: BYAPR15MB3029: x-ms-exchange-purlcount: 1 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtCWUFQUjE1TUIzMDI5OzIzOnBaUFBwNXdZb0NaTk1Ud2R3WWRHc3dMMVdC?= =?utf-8?B?SU50eUJHMWlKNSs3N01qL3lQUk1GQm9xUXJVZ3J1ZDFPRjhJMHgvUzRESmlP?= =?utf-8?B?ZUdxSDl5UG9WS1lPMzF0OCtNWHBPdm00a1YrMXpMTE00TEYyWlhxanFlM0M2?= =?utf-8?B?U3FKWUQ1UGRyWUNTNmFLNzJHWG9EajlGY2pPWlhnMGx0cjZmWmdub213QjBE?= =?utf-8?B?N0tEY1NGSzc4MGtsZ3RWSklweFFIeGR1bFRmRm5SeFVqWUxZWk9qVnVvaUl4?= =?utf-8?B?ZGJRbDBWa3ZsMWhkZFdwREt0QXlWWW9zOVFxYjJnMkVja1U3QXF1WFJHbDNX?= =?utf-8?B?a0RVR09BOW54NWNXdTdXNnRGdEovRU5zc0RvNGxReDhsTzM2SGo4elltSk5u?= =?utf-8?B?c2lrWkVqMTRMZlU1SEhFWHAvU3h2ME01MmRRdVd5REpSaW8vQWpPelNjcUoy?= =?utf-8?B?R1BtN0NMQVVEL0dONjk2aFpxcUY2c044bERhT0JLbldRbkxaVnk0WlVoVzlt?= =?utf-8?B?aSttNGFodUFZMWVISXBsd01CRW9MdzZ3TlpORFNCekZKU3FIKzlpVTJLQ0ww?= =?utf-8?B?Ykw3Y3Z6VkZnK28yZnZPWDVDdnlzdkVvdlhHSXh3WlZCMzZtWG9RTnN5NjR2?= =?utf-8?B?azc0SVRrQTIrQ2VpODRNcFo5SExHUUk0R21mTU9vWTQzOUtDSWQwZHpMcXE1?= =?utf-8?B?c2YyMXRHUVBmYzlYNjNCdTBDQXZCUGtTdnlJSHFzR05sSGpRcjYrZnZBRisx?= =?utf-8?B?MlZkUS94NjNEQU43MVZjdk9INkZQNGRwNlh0QWhXd0hxWUVQMlQ4ODd2YmdL?= =?utf-8?B?dkpaVHlJV0RLajlaSFU0dWRrWHI0dExTKzJLYXlWQ1hGUHNKdWFuVmkzdkI4?= =?utf-8?B?N0NTditWRVBlUmNrSk15WThWWlhQMEREbTdwZnJKdmtKSlBaQ2xwR0ZES3FG?= =?utf-8?B?WXQxNFBnckxXSUJhOXl4Uk9jZkY5SHJJaFBhLzZhMElBZWQvQjdIb2RnUnB4?= =?utf-8?B?SGgwV0ZHQ2ZkbjJ0Q1JZL1hJaGJ3V3ovR1NBSUsyU1RHMU94Ym1Iek1HQTlZ?= =?utf-8?B?dGxRQXlXOWZLamozLzJQMGtNWWJIZWdNS0hoVmRyMDRqcVNxNTExaFhrVi9J?= =?utf-8?B?RWxZQWhJREcvd1JQdWVFSGhsVjRVNnhjMjBEOVp1WGRNVE1lSTBVbzhJaFE0?= =?utf-8?B?VWtUL3MrQVNtejBQc3VmKytBSWVmQmxpTUI2V0J1djRmSDZDUzBEWkxLSjln?= =?utf-8?B?WGNob2QrMHkwb1lZQy9CSXdVN3ZNL3l3UVZwM0JUYzVWamZIU1lxRzNLWWli?= =?utf-8?B?cEZqYTlKNXFXNjhwdE55S0N1YWtzVHBsZ2ZRUkcxRVk3NGdDZldhcmhpQm9q?= =?utf-8?B?WHNtdXM0QmxmdzZCZ2tBNXIxcG1MWVljWW93WnhSaTlydGcwV2pNamt3RXg5?= =?utf-8?B?UU9vNCtFUTJ5aU16aFlyRmdjWEQvbVJRcnViNzN6WkE0RUFZc3daVFUyaXhO?= =?utf-8?B?NW84ZzQ0b3pEYytoayt0RTVyOXdHUDhrcTVtei9Za3UrK1k0RnZFbEVlb3Bw?= =?utf-8?B?VGZybzEvaVZhaUg0bVJFM0ZIZnhWanozdk51SEhtWVdWallnSE1kSU9vT1Qz?= =?utf-8?B?UzlWdmJJYXlrMjVZRW5JcVQzWi9ZM2lZQU45QzVnaG1hc1ZFK0N1YnZUVnJu?= =?utf-8?B?N3BzU3dRT0Eyd0E2RkpHTWNVc01VcENVRVRkVlVuSTQrUC9ZYWNWeHVHRVRt?= =?utf-8?B?dEFNa2lCcjJMVDIvRVpGU1FrV3B4S1FCc2tpK2JhK2ltSHBjR0tGUjdycWZU?= =?utf-8?B?VnBQQVZmUmZVOE1LUXo4MlN5SHFCclpiNVowU3RFU1Jzb1NWaExHN3dZREtT?= =?utf-8?Q?ssYWZ1/Lbng=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 0967749BC1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(376002)(346002)(366004)(136003)(39860400002)(199004)(189003)(52314003)(13464003)(7736002)(305945005)(14454004)(186003)(33656002)(8936002)(68736007)(52536013)(11346002)(66066001)(446003)(478600001)(74316002)(6306002)(53936002)(4326008)(2501003)(5660300002)(86362001)(476003)(966005)(6246003)(97736004)(55016002)(9686003)(25786009)(81156014)(110136005)(81166006)(26005)(6116002)(102836004)(8676002)(3846002)(71190400001)(486006)(6436002)(71200400001)(229853002)(106356001)(105586002)(14444005)(5024004)(256004)(93886005)(316002)(2906002)(99286004)(6506007)(76176011)(7696005)(53546011); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR15MB3029; H:BYAPR15MB3078.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Ur0wA9QQE92E53k6YiWY4iguJUbIWULA4AaXLT7476Vfvos22j8HR4PZzw+AEjsYbi6S+KCeI+e9lwrBi76BuYSlI4yttBve5IvWfwV8uVOgYFxBRe3YNDGgELddLB8MKYTtp3NgaidYjhaQozjUmlDUlOjVY7WCjODW249lQuoJH3guWEcO/Dh16fYFv5UTNNDlk1I2UhTm4093WJ3fj0w6/GtUOm6iXCzefJtLpoeiudFuyOqbivPmAaEwif8Q6qbP1xEgabM0b7pJmEZaZ4tt6H6wzPdziK9mN8l/GVF0P9Y0bjv4D5hy9JdeKJhfuaainVyyocQKz2SuHlWf++p5x5FL5EQ5mC4DXbNfsyHvKu/xdjh62qtoCjUfBjszMuFse2COQVYLphKE/GHWfj0wBufbMIn8WDAEsMXrlnw= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: fa909c10-f49f-4a7d-0ede-08d6a1ac497b X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2019 20:51:05.6620 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB3029 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnleLIzCtJLcpLzFFi42KZGbG9QtfmYV2MweotMhYnnqxgtdixu53N 4n9HP5sDs8eU3xtZPZYs+cnkcXHfBaYA5igum5TUnMyy1CJ9uwSujMOzfjIVLFKvWLnhOlsD 4wK1LkZODgkBE4ml32eydjFycQgJHGGUuPXtGQuE85VR4uv9f8wQzmImibNnN7ODOCwCE5gl 3s77yQiRmcQk8fb5I6gB9xkl5q6awAIymU3AQGLP/y+MILaIQJDEgq0gRZwczAKKEkc2dTKD 2MJA21+0tzFB1JhKrFizgxXCDpNo2vcWLM4ioCJx4eIqoJkcHLwCMRJfV5pA7NrKJHH/Uhcb SA2ngK3E2x0LwfYyCohJfD+1hglil7jErSfzmSA+FZBYsuc8M4QtKvHy8T9WiPpYiUdHG9hA 5ksIKEnsPcMDUSIrcWl+NyOE7SuxYuJGcLhICNxklHi85gUrREJL4uXzz1C2lMSJi0dZIYou Ckk8WbUGKpEtMe3oFXaIBTIS77+wQ9R0sUn8XjiddQKj3iwkt84CKmMW0JRYv0t/FjS4pnQ/ ZAexeQUEJU7OfMKygJFlFaNocWpxcW66kZFealFmcnFxfp5eXmrJJkZgMjm45bfVDsaDzx0P MQpwMCrx8J64XxcjxJpYVlyZe4hRgoNZSYR3/l2gEG9KYmVValF+fFFpTmrxIUZpDhYlcd4/ QoIxQgLpiSWp2ampBalFMFkmDk6pBsZir+MJp+cd0o+dLly7kete5DTpKh2ZqGMTbX4lLV4t FnS4Ytrcw0InWau3dixwt9OezXnA+9yagzO0br6RNnv3s4c9TbXeWv9YoSXLKt3aP9v1w327 zd/X7/B4pCXtuT9gevSj5TuuPf1Stc02Z0ua3oPp77WEI3ZerFar1L8SPUMzLHXyhxtKLMUZ iYZazEXFiQDN3HbvIgMAAA== Archived-At: Subject: Re: [Lsr] Open issues with Dynamic Flooding X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 20:51:19 -0000 T0sgZ2VudHMsIHNhZGx5IEnigJltIGxvc2luZyB0aGUgcGxvdCBoZXJlLi4uLi4uDQoNCk15IHVu ZGVyc3RhbmRpbmcgb2YgdGhpcyB3aG9sZSBlbmRlYXZvciBpcyB0aGF0Og0KDQotIGV4Y2Vzc2l2 ZSBmbG9vZGluZyBzbG93cyBjb252ZXJnZW5jZQ0KLSBzbyB3ZSBhcmUgc2Vla2luZyB0byBkZWZp bmUgYSByZWR1Y2VkIGZsb29kaW5nIHRvcG9sb2d5DQotIGEgZmFpbHVyZSB0aGF0IGRvZXMgbm90 IGltcGFjdCBhbiBGVCBhZGphY2VuY3kgaXMgcHJvcGFnYXRlZCB0aHJvdWdob3V0IHRoZSB0b3Bv bG9neSBhbmQgdGhlIGVmZmVjdHMgb2YgZXhjZXNzaXZlIGZsb29kaW5nIGhhdmUgYmVlbiBlbGlt aW5hdGVkLi4uLiBncmVhdC4NCi0gYSBmYWlsdXJlIHRoYXQgZG9lcyBpbXBhY3QgdGhlIGZsb29k aW5nIHRvcG9sb2d5IHJlc3VsdHMgaW4gdGhlIHRvcG9sb2d5IHRyeWluZyB0byBtZW5kIGl0c2Vs ZiBhbmQgc2xvd2luZyBkb3duIGNvbnZlcmdlbmNlIHdoaWxlIGF0IGl0Li4uLi5wb3RlbnRpYWxs eSBieSBhIHNpZ25pZmljYW50IGFtb3VudA0KLSBBbmQgdGhlIGN1cnJlbnQgZGlzY3Vzc2lvbiBp cyBoZWFkZWQgaW4gdGhlIGRpcmVjdGlvbiBvZiB3aGF0IGlzIHRoZSByaWdodCBoZXVyaXN0aWMg dG8gZGVhbCB3aXRoIHRoaXMuLi4NCg0KRG8gSSBoYXZlIHRoaXMgcmlnaHQ/DQpKdXN0IGNoZWNr aW5nDQpEYXZlDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBMc3IgPGxzci1i b3VuY2VzQGlldGYub3JnPiBPbiBCZWhhbGYgT2YgUGV0ZXIgUHNlbmFrDQpTZW50OiBUdWVzZGF5 LCBNYXJjaCA1LCAyMDE5IDM6MjYgUE0NClRvOiB0b255LmxpQHRvbnkubGkNCkNjOiBsc3JAaWV0 Zi5vcmcNClN1YmplY3Q6IFJlOiBbTHNyXSBPcGVuIGlzc3VlcyB3aXRoIER5bmFtaWMgRmxvb2Rp bmcNCg0KSGkgVG9ueSwNCg0KT24gMDUvMDMvMjAxOSAxNzo0NyAsIHRvbnkubGlAdG9ueS5saSB3 cm90ZToNCj4NCj4gSGkgUGV0ZXIsDQo+DQo+Pj4+IEFkZGluZyBhbGwgbGlua3Mgb24gYSBzaW5n bGUgbm9kZSB0byB0aGUgZmxvb2RpbmcgdG9wb2xvZ3kgaXMgbm90DQo+Pj4+IGdvaW5nIHRvIGNh dXNlIGlzc3VlcyB0byBmbG9vZGluZyBJTUhPLg0KPj4+DQo+Pj4NCj4+PiBDb3VsZCB5b3UgKG9y IEpvaG4pIHBsZWFzZSBleHBsYWluIHlvdXIgcmF0aW9uYWxlIGJlaGluZCB0aGF0PyBJdA0KPj4+ IHNlZW1zIGNvdW50ZXItaW50dWl0aXZlLg0KPj4NCj4+IGl0J3MgbGltaXRlZCB0byB0aGUgbGlu a3Mgb24gYSBzaW5nbGUgbm9kZS4gRnJvbSBhbGwgdGhlIHByYWN0aWNhbA0KPj4gcHVycG9zZXMg SSBkb24ndCBleHBlY3Qgc2luZ2xlIG5vZGUgdG8gaGF2ZSB0aG91c2FuZHMgb2YgYWRqYWNlbmNp ZXMsDQo+PiBhdCBsZWFzdCBub3QgaW4gdGhlIERDIHRvcG9sb2dpZXMgZm9yIHdoaWNoIHRoZSBk eW5hbWljIGZsb29kaW5nIGlzDQo+PiBiZWluZyBwcmltYXJ5IGludmVudGVkLg0KPg0KPg0KPiBX aGF0IGlmIHRoZSBub2RlIGluIHF1ZXN0aW9uIGlzIG9uZSBvZiB0aGUgc3BpbmVzPyAgRm9sa3Mg YXJlIGJ1aWxkaW5nDQo+IHN5c3RlbXMgdGhhdCBsYXJnZeKApiBhbmQgaXQgc2VlbXMgaW5ldml0 YWJsZSB0aGF0IHBvcnQgY291bnRzIHdpbGwgb25seQ0KPiBncm93LiAgVG90bywgSSBkb27igJl0 IHRoaW5rIHRoYXTigJlzIGFuIEFHUyBhbnkgbW9yZeKApi4gOy0pDQo+DQo+DQo+PiBJbiB0aGUg ZW52aXJvbm1lbnRzIHdpdGggbGFyZ2UgbnVtYmVyIG9mIGFkamFjZW5jaWVzIChlLmcuDQo+PiBo dWItYW5kLXNwb2tlKSBpdCBpcyBsaWtlbHkgdGhhdCB3ZSB3b3VsZCBoYXZlIHRvIG1ha2UgYWxs IHRoZXNlDQo+PiBsaW5rcyBwYXJ0IG9mIHRoZSBmbG9vZGluZyB0b3BvbG9neSBhbnl3YXksIGJl Y2F1c2UgdGhlIHNwb2tlIGlzDQo+PiB0eXBpY2FsbHkgZHVhbCBhdHRhY2hlZCB0byB0d28gaHVi cyBvbmx5LiBBbmQgdGhlIGluY3JlbWVudGFsDQo+PiBhZGphY2VuY3kgYnJpbmd1cCBpcyBzb21l dGhpbmcgdGhhdCBhbiBpbXBsZW1lbnRhdGlvbiBtYXkgYWxyZWFkeSBzdXBwb3J0Lg0KPg0KPg0K PiBMUyB0b3BvbG9naWVzIGNhbiBoYXZlIGEgdmVyeSBsYXJnZSBudW1iZXIgb2YgYWRqYWNlbmNp ZXMgYXMgd2VsbCwNCj4gdHlwaWNhbGx5IHdpdGggbXVsdGlwbGUgc3BpbmVzLCBzbyBmb3IgYSBu ZXcgc3BpbmUsIGFsbCBvZiB0aGUgb2YgdGhlDQo+IGxpbmtzIG1heSBiZSB1bm5lY2Vzc2FyeS4N Cg0Kb2ssIHdlIHRhbGtlZCBib3V0IHRoZSBiYWxhbmNlIGJlZm9yZSAtIGFkZGluZyBvbmUgbGlu ayBhdCBhIHRpbWUgdG8gdGhlIEZUIG1heSByZXN1bHQgaW4gc2xvdyByZWNvdmVyeSwgd2hpbGUg YWRkaW5nIGFsbCBsaW5rIGlzIGNsYWltZWQgdG8gYmUgZGFuZ2Vyb3VzLiBXaGF0IGlzIHRoZSBy aWdodCBudW1iZXI/IEkgZmVlbCB0aGF0IHRoZSBpbmNyZW1lbnQgdmFsdWUgY2FuIGJlIHNvbWV0 aGluZyB0aGF0IHRoZSBpbXBsZW1lbnRhdGlvbiBjYW4gY2hvb3NlIG9yIGV2ZW4gbWFrZSBjb25m aWd1cmFibGUsIHNvIHRoZSB1c2VyIGNhbiBkZWNpZGUgYmFzZWQgb24gdGhlIHBhcnRpY3VsYXIg dG9wb2xvZ3kgYW5kIHNjYWxlLiBXZSBhcmUgbm90IGdvaW5nIHRvIGZpbmQgdGhlIG1hZ2ljIHZh bHVlIEknbSBhZnJhaWQuDQoNCj4NCj4NCj4+PiBPdXIgc2ltdWxhdGlvbnMgc3VnZ2VzdCB0aGF0 IHRoaXMgaXMgbm90IG5lY2Vzc2FyaWx5IG9wdGltYWwuICBUaGVyZQ0KPj4+IGFyZSBsb3RzIG9m IHRvcG9sb2dpZXMgKGUuZy4sIHBhcmFsbGVsIExBTnMpIHdoZXJlIHRoaXMgYmxhbmtldA0KPj4+ IGFwcHJvYWNoIGlzIHN1Ym9wdGltYWwuDQo+Pg0KPj4gdGhlIHF1ZXN0aW9uIGlzIGhvdyBtdWNo IGFyZSB0cnVlIExBTnMgdXNlZCBhcyB0cmFuc2l0IGxpbmtzIGluDQo+PiB0b2RheSdzIG5ldHdv cmtzLg0KPg0KPg0KPiBBcyBYaWFvaHUgc3VnZ2VzdGVkLCB0aGUgbWFuYWdlbWVudCBwbGFuZSB3 b3VsZCBiZSBhbiBvYnZpb3VzDQo+IGFwcGxpY2F0aW9uLiBJbnRlcmNvbm5lY3RzIGFsc28gc2Vl bSBsaWtlbHkuDQoNCkkgYmVsaWV2ZSBoaXMgY2FzZSBpcyBjb21wbGV0ZWx5IG9ydGhvZ29uYWwg dG8gdGhpcyBkaXNjdXNzaW9uIGFzIGluIGhpcyBjYXNlIHRoZXJlIGlzIGEgc2luZ2xlIGdpYW50 IExBTiB1c2VkIGZvciBmbG9vZGluZyBhbmQgd2UgYWxsIGtub3cgd2UgY2FuIG5vdCBvcHRpbWl6 ZSBmbG9vZGluZyBpbnNpZGUgYSBMQU4gaXRzZWxmLg0KDQo+DQo+IExldOKAmXMgc2V0IHRoZSBh bGdvcml0aG1pYyBwYXJ0cyBhc2lkZS4gIERvIHlvdSBoYXZlIGFuIG9iamVjdGlvbiB0bw0KPiBz dXBwb3J0aW5nIHRoZW0gaW4gdGhlIHNpZ25hbGluZz8NCg0Kd2lsbCBnZXQgY29tcGxpY2F0ZWQs IGVzcGVjaWFsbHkgZm9yIE9TUEYvT1NQRnYzLiBBbHNvIHRlbXBvcmFyeQ0KZmxvb2Rpbmcgb3Bl cmF0aW9uIG9uIExBTiBpcyB0cmlja3kgYW5kIHN1Yi1vcHRpbWFsLiBJIGRvbid0IHJlYWxseQ0K YmVsaWV2ZSBpdCdzIHdvcnRoIHRoZSBjb21wbGV4aXR5Lg0KDQpteSAyYywNClBldGVyDQoNCj4N Cj4gVG9ueQ0KPg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KTHNyIG1haWxpbmcgbGlzdA0KTHNyQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2xzcg0K From nobody Tue Mar 5 12:59:17 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D57513133B for ; Tue, 5 Mar 2019 12:59:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.018, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 6VdJAy0NHrxN for ; Tue, 5 Mar 2019 12:59:14 -0800 (PST) Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (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 3BBB11312F7 for ; Tue, 5 Mar 2019 12:59:14 -0800 (PST) Received: by mail-pf1-x42c.google.com with SMTP id h1so6623766pfo.7 for ; Tue, 05 Mar 2019 12:59:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1TDxqV2PJwjQuRxr8DLxZmPyffV2gWElNv5wHzud0so=; b=LOzJpcLfxVT0oa8g5DxyLb6vUtHUbih7DvDbDQcUKGjima436+XdxKCU6wN8UK8eZh 4x8Hxr4s97N9PCEw5F/aYEgf5ZQ4rmSBxL3wtRLv7PjvJzSWW5jAnc+3ewNY7cb0mV/a Trgb7+kGyTFlNDRzfEdwrsBrl3iqaj8SvFl4Cen2bbtigiZ4F7nlQOV+ZdgPLhxvfsYX YqHQ2/G7IGOjribVe5RxlLs1QAP8mftGBIthWgaHiydYk8SgJBZ0f0kXlxXwO53UV+Ol 6b6/0l/qmH1x4CqCFgbngmjo+pK53BHfoJjTj7mqpsopuzw0tD/WSEpx2W9cYJQmGr3J CDLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=1TDxqV2PJwjQuRxr8DLxZmPyffV2gWElNv5wHzud0so=; b=emknfvQLGNdCrw82I2m69DyLmvWvh4X3JjmBFUnIPn77J5R+k9sheXV4FBC3ccfj0G O/GhkBSShKwdh2T7icYKwJvYuGOHrDtZ0pSANVrJBJyrc+T/gxWFKEIuMMDXVStEImKz X/TNG8NjT5EPkno/GAtCICaOuhsJXfU2JUZW9vRc//4h+h8fjeiLx6hVkAEyqSSW9fOq XcFc3wbMCURG3asYRXAPBuK7zDW0iBNQo3fTid4Z5XjfysliGrMSI3u+D25j6ife1aYH TIZeC8Ey6CSwitMddec/580F0/V3vNeK0ca8DBdTRcRpNUZJ+FXa/VY8Gn0owTkJ3fV8 MTGQ== X-Gm-Message-State: APjAAAUR12ES8sueILLtA510bJPYvg/PIH9+n/I8ShEyoevmm7ZAc4aa hyeF6TUD3FRQWvQbsXpdvao= X-Google-Smtp-Source: APXvYqxo0dbEYRA7eimO7+Igi6lgmxCbQxXqgkdhGUlLqBFWxHgemoCFePpCXUlYzyxGoXOUWWta7Q== X-Received: by 2002:a62:1b92:: with SMTP id b140mr3783486pfb.159.1551819553564; Tue, 05 Mar 2019 12:59:13 -0800 (PST) Received: from [172.22.228.48] ([162.210.130.3]) by smtp.gmail.com with ESMTPSA id h87sm19293753pfj.20.2019.03.05.12.59.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Mar 2019 12:59:12 -0800 (PST) Sender: Tony Li Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: tony.li@tony.li In-Reply-To: Date: Tue, 5 Mar 2019 12:59:12 -0800 Cc: Peter Psenak , "lsr@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: References: <966E5756-8CEF-47F4-8564-E23D38F0743E@tony.li> To: David Allan I X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Lsr] Open issues with Dynamic Flooding X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 20:59:16 -0000 Hi Dave, > My understanding of this whole endeavor is that: >=20 > - excessive flooding slows convergence > - so we are seeking to define a reduced flooding topology > - a failure that does not impact an FT adjacency is propagated = throughout the topology and the effects of excessive flooding have been = eliminated.... great. > - a failure that does impact the flooding topology results in the = topology trying to mend itself and slowing down convergence while at = it.....potentially by a significant amount > - And the current discussion is headed in the direction of what is the = right heuristic to deal with this... >=20 > Do I have this right? Close. More specifically, if there is a multiple failure that partitions the = FT, how do we repair it? Fast or safe? Choose one.=20 Tony From nobody Tue Mar 5 13:01:10 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 91C8A128D0B for ; Tue, 5 Mar 2019 13:01:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=Ij+8V+8v; dkim=pass (1024-bit key) header.d=ericsson.com header.b=lsn349+p 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 6HXmt_5nT-aD for ; Tue, 5 Mar 2019 13:01:07 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (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 4CBB21288BD for ; Tue, 5 Mar 2019 13:01:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/relaxed; q=dns/txt; i=@ericsson.com; t=1551819665; x=1554411665; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=npKQJm/0V7LR8eamYh4yAfZOXWbWvGIFboO89AyQO44=; b=Ij+8V+8vaTRSGgaHj724InYPWilZKx3PEfEXtGHPJtQKvSCMk9aLYdoy4TnTgkQM dmNXORD4SW/phrRG3vjX7upgy6rY265YU8EtKoinFQStcbgrocdJP/reBTltNF55 jlXHbeU0/NPmgPIHx3g85R7Uy39E8uxAHdXU9MzOvGc=; X-AuditID: c1b4fb30-41b3a9e00000355c-69-5c7ee39165cc Received: from ESESSMB501.ericsson.se (Unknown_Domain [153.88.183.119]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id DB.B2.13660.193EE7C5; Tue, 5 Mar 2019 22:01:05 +0100 (CET) Received: from ESESSMR505.ericsson.se (153.88.183.127) by ESESSMB501.ericsson.se (153.88.183.189) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 5 Mar 2019 22:01:05 +0100 Received: from ESESSMB502.ericsson.se (153.88.183.163) by ESESSMR505.ericsson.se (153.88.183.127) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Tue, 5 Mar 2019 22:01:05 +0100 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (153.88.183.157) by ESESSMB502.ericsson.se (153.88.183.163) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3 via Frontend Transport; Tue, 5 Mar 2019 22:01:04 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=npKQJm/0V7LR8eamYh4yAfZOXWbWvGIFboO89AyQO44=; b=lsn349+pCbyC+yKm9e6XaQnFcP/hWFT9iKDFB29PuDQJmEoxFjCWWCyIKLcrab+9+jDZ4h51OKYGvyDvNxYg2pxBU0My58fzUlWz5mkh1WRVZo6/3Gx06JeEcOj+K7ytqzCZ2RBuVyWU7jmZcFhtC1gU1dPOOn7paYP8fW0hXCQ= Received: from BYAPR15MB3078.namprd15.prod.outlook.com (20.178.239.16) by BYAPR15MB3157.namprd15.prod.outlook.com (20.178.207.218) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.18; Tue, 5 Mar 2019 21:00:59 +0000 Received: from BYAPR15MB3078.namprd15.prod.outlook.com ([fe80::f149:ac42:91ed:98d]) by BYAPR15MB3078.namprd15.prod.outlook.com ([fe80::f149:ac42:91ed:98d%4]) with mapi id 15.20.1665.020; Tue, 5 Mar 2019 21:00:59 +0000 From: David Allan I To: "tony.li@tony.li" CC: "ppsenak@cisco.com" , "lsr@ietf.org" Thread-Topic: [Lsr] Open issues with Dynamic Flooding Thread-Index: AQHU0rNkTwZFDYjuJkyaA7EXxtPtc6X8p2UAgACQ6YCAAALpAIAABY6AgAA9MgCAAAV5IIAAA7oAgAAAZcA= Date: Tue, 5 Mar 2019 21:00:59 +0000 Message-ID: References: <966E5756-8CEF-47F4-8564-E23D38F0743E@tony.li> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=david.i.allan@ericsson.com; x-originating-ip: [216.154.61.166] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 2f2d573e-eb86-4897-f866-08d6a1adab7d x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:BYAPR15MB3157; x-ms-traffictypediagnostic: BYAPR15MB3157: x-microsoft-exchange-diagnostics: =?us-ascii?Q?1; BYAPR15MB3157; 23:md84w462pHvJJ06P2rCYh5VB3947g+2YY/MlQdUr7?= =?us-ascii?Q?6djTDEVxJlGYGDCKmmtAHtxzsJxFn3H+ZPQGDitLvnAsF5O736ZxFio9pTjG?= =?us-ascii?Q?7ZYZfgJIs2vk8QvajRV87YGR7lXwaxCkTu2NRxJpio4miM+1qzmR5pTZrmr/?= =?us-ascii?Q?D9dODp2h5aduoJJ6z2BiFHbDFba6mk3m9INA+iDi68CHurof7fdVvqFEaB1+?= =?us-ascii?Q?iRI/BVqw7vryv2jv9UGVwudN6pNpO0CVMlbKz+iSWzLjCNe6Jvfd86h3uM+G?= =?us-ascii?Q?lgheJYQSIDpSqVpz2+ACZ3/VhRg+6hgsfyt3Rh8C2nI8RUBw9GKxRrU0PCcG?= =?us-ascii?Q?p3COt98bOGnGZCtD+vF7IA304BopVhU2QbeAZQAyeU1CCPU4hVGSb94xepIL?= =?us-ascii?Q?QZuJas7tt8Lq9RmYPvU9VG2WL1ov75kNEGifnopT2rRpVuwgR7negMTAWkWx?= =?us-ascii?Q?pVLfug+S49IlxdpXVYP64o3DIEhypnO2WgJlttRDYDFxhMqsrA0MXn6WSbtL?= =?us-ascii?Q?sjYJp8RrUB69s5+zBEmCds5ntgJURNl/JrSaTsuK6tl0HrGboBI4T0S1A8GM?= =?us-ascii?Q?wz1hKq7pua7VFuQS/FXLDDW8/sU825mfqNCF1BUKPmok/YFPSNQVfr+kK/w9?= =?us-ascii?Q?EywH7ggINb5QT9fjAx7sm+vTI/D0+GZrRPi1czctgnGMkVUOAHAvEaoiQnJA?= =?us-ascii?Q?NIUaKr1witynpDrbTg1+TvFzckxz+EXv3Ass/q4bert7JPOonTXaJJsjYbTv?= =?us-ascii?Q?F2x3iJx/FwoxnUrJH18K+f/1+YT1q5W7n71kinzBn8/+gbscmD9APOgY+ZSy?= =?us-ascii?Q?ZeHKVUz60jb4dQeiHP+EBdO0MC5m3C/8KqfrJjh4iGGUjW7RZuTq5jHiKy5y?= =?us-ascii?Q?RWkKWPdkxFcXyoQanYXMVxi3+v3baifbQwx8RQOQuA8G5IHhivf8UZWjlT+l?= =?us-ascii?Q?a8R2VTcKLmVWx0yQlXkGU5Lp4QwSFSDocH7FFz3Dxze5LHj8yfxCElFA3g7m?= =?us-ascii?Q?S3nHV9s1xvgFi86riTc03+136bX68V6BT7wNasURbhq16qDdi5gv3/NG3cpN?= =?us-ascii?Q?+FgKFsCaNSlL7v/TLHEhupDmaW4Pqq2rYBm0ecvEQtsXeVgXM0kVBk71TMmj?= =?us-ascii?Q?aynxQKz4HsdoFWiZ1Qv2KX1kvApDIaa6YwkfwwjUQlKIWhiTHXiEURe3ExAS?= =?us-ascii?Q?875PLwafyOjU8maksLg64POE288S8BGMIva4EMHqgDFf6toPpLDfkKVQFLm7?= =?us-ascii?Q?D4VHvrwxd1LNQpMiGF0dMRv9PMRvzPIzjmMG3oRnFNdW9VCpTuSZTsIa2lwh?= =?us-ascii?Q?J4f4osyPZ5ZOgwuanimhpORFhyubuXLNkl7Y2silwgbnEIYDYDwPYPAgiOr1?= =?us-ascii?Q?EnLfBPX0JD1+/WT5tRjeWq0NG4=3D?= x-microsoft-antispam-prvs: x-forefront-prvs: 0967749BC1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(396003)(136003)(376002)(346002)(366004)(189003)(199004)(13464003)(5640700003)(6436002)(2906002)(53546011)(68736007)(7736002)(186003)(25786009)(2501003)(446003)(229853002)(5660300002)(55016002)(6506007)(6916009)(86362001)(99286004)(476003)(71190400001)(4326008)(33656002)(486006)(11346002)(305945005)(71200400001)(54906003)(8676002)(81166006)(105586002)(81156014)(93886005)(102836004)(3846002)(2351001)(6116002)(4744005)(8936002)(26005)(256004)(14444005)(316002)(106356001)(478600001)(52536013)(76176011)(53936002)(66066001)(14454004)(7696005)(97736004)(74316002)(9686003)(6246003); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR15MB3157; H:BYAPR15MB3078.namprd15.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:3; A:1; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: zRIkizfzB4SM7DFH6YFgwxVImlp5h8kw8JZYKFTyp/2TG+yTbWUC88S6w3nK0lsBmybCSOuFeIsPxImLfh0TnB5CVY/S4x3U7kJ0kGR0cWIGKe+g/Q8dBePbB2X0rxiL4mlgK/5bmSUzqETUY8eGp9mSsykjTuy8zScnkyUGYAcymD1BHogEWJlLtqxQh1fxjovU4mNlh/jhHQflx3JLfdiXIMZWZrmPIAzaurQhcEvdi55u0z/OOD+12QRbLI5lTnvUY7EqZqE1bmXciTKwGQ+WUaDTxD1L49N/MpEPVZgvK0kZvSO0iisAisLegKaXmNjfZ386cfdKpS5MmY4Qq+1L8cyGpJin6yhxHMMZ4QFa19dhn07qm2AzYBqQl8lVpLKybGiU17c2G/CjRiciOJc+AWRgPny2iCRfV4B4mew= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 2f2d573e-eb86-4897-f866-08d6a1adab7d X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Mar 2019 21:00:59.6766 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR15MB3157 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTcRTG/d8375bT69I8qAkNIzBbaiZSEQkRIhoFRSaTNdttDnXKri/Z h7G01CybZjG08gWXmU4oKZ1tmk2LSiEt0DRilIJKpFELMSvbdhf07XfO83DeODQuriNDabWm kNVqFLkSSkg0pPeV7Kib1clipi5C4ou5DjLRYq2kEterDNQBPPn62gMy2WRaxZInBsexI3iG cJ+SzVUXs9qd+08Jsw03rWTBLH32rrmP1CO9bzUS0MDEg9E8TVUjIS1mRhBca1qi3IKY+YHA 0pfOCy4un5wh+KANgy/9NcgdEEwtDisLyxiv1GMw2PoT5wMHgqH+t8hdjGJiwLbu9HAQsw3a HC2e7jiTAo/Kb2Bu3uiaZKGyAuM9u6HDbCF5zoL5jjEPE0wktN+vwt0sYmSwfP65t1k/Dsau Mo9JwOwFu7PGw4jZBCuvzBjfLARm5poxfm0GTLbXOM/BsDj7x+vPhE/P9K4L0K68BAbG/HjL ZnjTfBnxnAZD9WWeiwEzjeDd0gVvnSgwT17y5YVxf1g0DZK8kANt3e5t3EXDYdnp9VyhwPbY iWqRtPG/+XiOhhbrN4rn7dDe+hlv9CwdCC8b5ogWRHSiYI7lsvJUcXFSVqs+zXH5GqmGLexB rkd5+nAtxoIW55PsiKGRxE804dDJxKSimCvNsyOgcUmQqPmDKyVSKkrPsdp8ubYol+XsKIwm JCGiX+JAmZhRKQrZHJYtYLX/VIwWhOqR7kiGctgYmPE+IXyUcgRMIXnLwfwTW0MrrbaIY1fP xEcYBkqKjqYK7qUlxHJrOareCn919snDx6eCP/YqUywjh9TK0mhpV5F4l5zpHqqr2vPbxyD/ qmscrrlju91pHH1SssFHLdsynxkWqVpfhYkeYRLX8z3lVlNZanWSz3iAhOCyFbFRuJZT/AWY H28wJAMAAA== Archived-At: Subject: Re: [Lsr] Open issues with Dynamic Flooding X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 21:01:10 -0000 Got it, thx -----Original Message----- From: Tony Li On Behalf Of tony.li@tony.li Sent: Tuesday, March 5, 2019 3:59 PM To: David Allan I Cc: Peter Psenak ; lsr@ietf.org Subject: Re: [Lsr] Open issues with Dynamic Flooding Hi Dave, > My understanding of this whole endeavor is that: > > - excessive flooding slows convergence > - so we are seeking to define a reduced flooding topology > - a failure that does not impact an FT adjacency is propagated throughout= the topology and the effects of excessive flooding have been eliminated...= . great. > - a failure that does impact the flooding topology results in the topolog= y trying to mend itself and slowing down convergence while at it.....potent= ially by a significant amount > - And the current discussion is headed in the direction of what is the ri= ght heuristic to deal with this... > > Do I have this right? Close. More specifically, if there is a multiple failure that partitions the FT, h= ow do we repair it? Fast or safe? Choose one. Tony From nobody Tue Mar 5 13:06:59 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66336128D0B for ; Tue, 5 Mar 2019 13:06:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=raszuk.net 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 325Eho67Wx5E for ; Tue, 5 Mar 2019 13:06:53 -0800 (PST) Received: from mail-qk1-x72e.google.com (mail-qk1-x72e.google.com [IPv6:2607:f8b0:4864:20::72e]) (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 399B01288BD for ; Tue, 5 Mar 2019 13:06:53 -0800 (PST) Received: by mail-qk1-x72e.google.com with SMTP id a15so5581539qkc.1 for ; Tue, 05 Mar 2019 13:06:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=KCYP0/oWWvBSEeC7oH/E0Q493czllTOGjk1vurUX2Eg=; b=S1QzzqZ7E7N9TIbvqin3ibB4YB0ZbUeq+FZM1zrLN8/kfsq1JM1wblQri7860XJWeg 0V+Fck+GBB6uQTNZ5Lj4CPHZ7LF3KC7pX5lHxRsew3UDrorZcTXJh8GNs3ScpiVdt7a4 jZjYqIFhNGxvp89/GUd95VeWiSb2A0ZT/63d+YEhcID7zoln0KIKZE1YIaw5Rf+cVV39 z9KiUynA9RXJu0G+5D5Fpx89567lzFOIZUltPq94c+E34A0sEudIQllxm7lyNpYYyjeY 99r0DPnPsjgP17Toi7hZQJSUQLsdY2zk2MwsQ8oKrTth/8EKhTAfqgvYLgAba4kzFLHc LQ6A== 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=KCYP0/oWWvBSEeC7oH/E0Q493czllTOGjk1vurUX2Eg=; b=orHWZfUWQuIiM128UCuy7bzKyWZiXNDcS8r1npL6oX7T7ePXIWnpN/j7uMABb/7WOV wNSHIGMV3PpcUm9zaXnHK/d12HC/PpPrh15sn3QItaNKkMKovq0niHHwoo1MnvQnNQbu ++RaUmWGK116E9VY7Yi0XEwxDAlJtCdb24odNOzkiMyDjLpw0xjRGJMEZCc078+NDRaB 4fdfc9+PwEEh+VMOmdNdR44yudFVnzfvdUEuc9gaPzovhGAvQHbXecg12/eVN1bLODy/ dnlceMIlLWEZNbs+Vv9zOlWvvWZDe3Vz5LFPoGIGGUbzS9ytTHlutAzKXXxORcTdYGuZ hplw== X-Gm-Message-State: APjAAAUv2BfOEeT5fhtQU+v5QD9nBbBieLl6UKvYPFZkRlYaP79fa7g9 uiri7XzCrvWI8NSEwU2fZlwNT2lvVHOdhmLvkP8dhA== X-Google-Smtp-Source: APXvYqzF5UEIh+CNNyM6xxoYveuFURa0t8+HFNo2lGPecyd/HBiiv+OxUFLQQJJNn9jyf5vb9iK0umSDOPAypQxtB+w= X-Received: by 2002:a37:ef0a:: with SMTP id j10mr3340739qkk.336.1551820012034; Tue, 05 Mar 2019 13:06:52 -0800 (PST) MIME-Version: 1.0 References: <41bd7097-0d25-a2e0-843d-cb25fd13a84f@cisco.com> In-Reply-To: <41bd7097-0d25-a2e0-843d-cb25fd13a84f@cisco.com> From: Robert Raszuk Date: Tue, 5 Mar 2019 22:06:41 +0100 Message-ID: To: Peter Psenak Cc: Tony Przygienda , lsr@ietf.org, Tony Li Content-Type: multipart/alternative; boundary="00000000000092b23605835f408e" Archived-At: Subject: Re: [Lsr] Open issues with Dynamic Flooding X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 21:06:57 -0000 --00000000000092b23605835f408e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Peter, > you only have two paths to reach any node. Who says that you must be limited to two paths only ? Why not create a flooding graph such that flooding will happen over 4 paths as opposed to flooding over 16 or 32 today without optimization. And if you are worried that you loose *wisely selected* all 4 paths before you manage to distribute new flooding topology you can always flood over 6 :) Best, R. On Tue, Mar 5, 2019 at 9:17 PM Peter Psenak wrote: > Robert, > > On 05/03/2019 20:12 , Robert Raszuk wrote: > > > >> Slow convergence is obviously not a good thing > > > > Could you please kindly elaborate why ? > > > > With tons of ECMP in DCs or with number of mechanism for very fast data > > plane repairs in WAN (well beyond FRR) IMHO any protocol *fast > > convergence* is no longer a necessity. Yet many folks still talk about > > it like the only possible rescue ... > > we are talking about the control plane convergence, not data plane one. > If the flooding topology is subset of the real topology, then at the > flooding level you don't have all the ECMPs available - you only have > two paths to reach any node. In such case it is possible that the > flooding topology gets partitioned and you want to get out of that state > quickly, as you may get out of sync with the the reality and eventually > loose all the data plane ECMPs as a consequence. > > thanks, > Peter > > > > > > > On Tue, Mar 5, 2019 at 5:42 PM Tony Przygienda > > wrote: > > > > in practical terms +1 to Peter's take here ... Unless we're talking > > tons of failures simultaneously (which AFAI talked to folks are not > > that common but can sometimes happen in DCs BTW due to weird things= ) > > smaller scale failures with few links would cause potentially > > diffused "chaining" of convergence behavior rather than IGP-style > > fast healing (and on top of that I didn't see a lot of interest in > > formalizing a rigorous distributed algorithm which IMO would be > > necessary to ensure ultimate convergence when only one/subset of > > links is used). Slow convergence is obviously not a good thing > > unless we assume people will run FRR with its complexity in DC > > and/or no more than one link every fails which seems to me bending > > assumptions to whatever solution is available/preferred. To Tony's > > point though, on large scale failures enabling all links would caus= e > > heavy flood load, yes, but in a sense it's the "initial bootup" cas= e > > anyway (especially in centralized case) since nodes need all > > topology to make informed correct decisions about what the FT shoul= d > > be if they don't rely on whatever the centralized instance thinks > > (which they won't be able to do given the FT from centralized > > instance will indicate lots links that are "gone" due to failure). > > As to p2p, I suggest to agree whether you use dense mesh (DC) case > > or sparse mesh (WAN) case or "every topology imaginable" since that > > drives lots design trade-offs. > > > > my 2.71828182 cents ;-) > > > > --- tony > > > > On Tue, Mar 5, 2019 at 8:27 AM Peter Psenak > > wrote: > > > > Hi Tony, > > > > On 05/03/2019 17:16 , tony.li@tony.li > > wrote: > > > > > > Peter, > > > > > >>> (a) Temporarily add all of the links that would appear t= o > > remedy the partition. This has the advantage that it is very > > likely to heal the partition and will do so in the minimal > > amount of convergence time. > > >> > > >> I prefer (a) because of the faster convergence. > > >> Adding all links on a single node to the flooding topology i= s > > not going to cause issues to flooding IMHO. > > > > > > > > > Could you (or John) please explain your rationale behind that= ? > > It seems counter-intuitive. > > > > it's limited to the links on a single node. From all the > practical > > purposes I don't expect single node to have thousands of > > adjacencies, at > > least not in the DC topologies for which the dynamic flooding i= s > > being > > primary invented. > > > > In the environments with large number of adjacencies (e.g. > > hub-and-spoke) it is likely that we would have to make all thes= e > > links > > part of the flooding topology anyway, because the spoke is > > typically > > dual attached to two hubs only. And the incremental adjacency > > bringup is > > something that an implementation may already support. > > > > > > > > > > > > > >> given that the flooding on the LAN in both OSPF and ISIS is > > done as multicast, there is currently no way to enable flooding= , > > either permanent or temporary, towards a subset of the neighbor= s > > on the LAN. So if the flooding is enabled on a LAN it is done > > towards all routers connected to the it.. > > > > > > > > > Agreed. > > > > > > > > >> Given that all links between routers are p2p these days, I > > would vote for simplicity and make the LAN always part of the F= T. > > > > > > > > > I=E2=80=99m not on board with this yet. Our simulations sugg= est that > > this is not necessarily optimal. There are lots of topologies > > (e..g., parallel LANs) where this blanket approach is suboptima= l. > > > > the question is how much are true LANs used as transit links in > > today's > > networks. > > > > thanks, > > Peter > > > > > > > > Tony > > > > > > . > > > > > > > _______________________________________________ > > Lsr mailing list > > Lsr@ietf.org > > https://www.ietf.org/mailman/listinfo/lsr > > > > _______________________________________________ > > Lsr mailing list > > Lsr@ietf.org > > https://www.ietf.org/mailman/listinfo/lsr > > > > --00000000000092b23605835f408e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Peter,

> you only have=C2=A0two path= s to reach any node.=C2=A0=C2=A0

Who says that= you must be limited to two paths only ?=C2=A0

Why= not create a flooding graph such that flooding will happen over 4 paths as= opposed to flooding over 16 or 32 today without optimization.=C2=A0
<= div>
And if you are worried that you loose *wisely selected* = all 4 paths before you manage to distribute new flooding topology you can a= lways flood over 6 :)

Best,
R.







On Tue, Mar 5, 2019 at 9:17 PM Peter Psenak <ppsenak@cisco.com> wrote:
Robert,

On 05/03/2019 20:12 , Robert Raszuk wrote:
>
>> Slow convergence is obviously not a good thing
>
> Could you please kindly elaborate why ?
>
> With tons of ECMP in DCs or with number of mechanism for very fast dat= a
> plane repairs in WAN (well beyond FRR) IMHO any protocol *fast
> convergence* is no longer a necessity. Yet many folks still talk about=
> it like the only possible rescue ...

we are talking about the control plane convergence, not data plane one.
If the flooding topology is subset of the real topology, then at the
flooding level you don't have all the ECMPs available - you only have <= br> two paths to reach any node. In such case it is possible that the
flooding topology gets partitioned and you want to get out of that state quickly, as you may get out of sync with the the reality and eventually loose all the data plane ECMPs as a consequence.

thanks,
Peter

>
>
> On Tue, Mar 5, 2019 at 5:42 PM Tony Przygienda <tonysietf@gmail.com
> <mailto:to= nysietf@gmail.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0in practical terms +1 to Peter's take here ... = Unless we're talking
>=C2=A0 =C2=A0 =C2=A0tons of failures simultaneously (which AFAI talked = to folks are not
>=C2=A0 =C2=A0 =C2=A0that common but can sometimes happen in DCs BTW due= to weird things)
>=C2=A0 =C2=A0 =C2=A0smaller scale failures with few links would cause p= otentially
>=C2=A0 =C2=A0 =C2=A0diffused "chaining" of convergence behavi= or rather than IGP-style
>=C2=A0 =C2=A0 =C2=A0fast healing (and on top of that I didn't see a= lot of interest in
>=C2=A0 =C2=A0 =C2=A0formalizing a rigorous distributed algorithm which = IMO would be
>=C2=A0 =C2=A0 =C2=A0necessary to ensure ultimate convergence when only = one/subset of
>=C2=A0 =C2=A0 =C2=A0links is used). Slow convergence is obviously not a= good thing
>=C2=A0 =C2=A0 =C2=A0unless we assume people will run FRR with its compl= exity in DC
>=C2=A0 =C2=A0 =C2=A0and/or no more than one link every fails which seem= s to me bending
>=C2=A0 =C2=A0 =C2=A0assumptions to whatever solution is available/prefe= rred. To Tony's
>=C2=A0 =C2=A0 =C2=A0point though, on large scale failures enabling all = links would cause
>=C2=A0 =C2=A0 =C2=A0heavy flood load, yes, but in a sense it's the = "initial bootup" case
>=C2=A0 =C2=A0 =C2=A0anyway (especially in centralized case) since nodes= need all
>=C2=A0 =C2=A0 =C2=A0topology to make informed correct decisions about w= hat the FT should
>=C2=A0 =C2=A0 =C2=A0be if they don't rely on whatever the centraliz= ed instance thinks
>=C2=A0 =C2=A0 =C2=A0(which they won't be able to do given the FT fr= om centralized
>=C2=A0 =C2=A0 =C2=A0instance will indicate lots links that are "go= ne" due to failure).
>=C2=A0 =C2=A0 =C2=A0As to p2p, I suggest to agree whether you use dense= mesh (DC) case
>=C2=A0 =C2=A0 =C2=A0or sparse mesh (WAN) case or "every topology i= maginable" since that
>=C2=A0 =C2=A0 =C2=A0drives lots design trade-offs.
>
>=C2=A0 =C2=A0 =C2=A0my 2.71828182 cents ;-)
>
>=C2=A0 =C2=A0 =C2=A0--- tony
>
>=C2=A0 =C2=A0 =C2=A0On Tue, Mar 5, 2019 at 8:27 AM Peter Psenak <ppsenak@cisco.com >=C2=A0 =C2=A0 =C2=A0<mailto:ppsenak@cisco.com>> wrote:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Hi Tony,
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0On 05/03/2019 17:16 , tony.li@tony.li <mailto:tony.li@tony.li>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0wrote:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Peter,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>>=C2=A0 =C2=A0 (a) Tempora= rily add all of the links that would appear to
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0remedy the partition. This has the ad= vantage that it is very
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0likely to heal the partition and will= do so in the minimal
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0amount of convergence time.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> I prefer (a) because of the = faster convergence.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> Adding all links on a single= node to the flooding topology is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0not going to cause issues to flooding= IMHO.
>=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> Could you (or John) please expla= in your rationale behind that?
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0It seems counter-intuitive.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0it's limited to the links on a si= ngle node. From all the practical
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0purposes I don't expect single no= de to have thousands of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0adjacencies, at
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0least not in the DC topologies for wh= ich the dynamic flooding is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0being
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0primary invented.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0In the environments with large number= of adjacencies (e.g.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0hub-and-spoke) it is likely that we w= ould have to make all these
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0links
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0part of the flooding topology anyway,= because the spoke is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0typically
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0dual attached to two hubs only. And t= he incremental adjacency
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0bringup is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0something that an implementation may = already support.
>
>=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=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>> given that the flooding on t= he LAN in both OSPF and ISIS is
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0done as multicast, there is currently= no way to enable flooding,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0either permanent or temporary, toward= s a subset of the neighbors
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0on the LAN. So if the flooding is ena= bled on a LAN it is done
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0towards all routers connected to the = it..
>=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> Agreed.
>=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>> Given that all links between= routers are p2p these days, I
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0would vote for simplicity and make th= e LAN always part of the FT.
>=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> I=E2=80=99m not on board with th= is yet.=C2=A0 Our simulations suggest that
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0this is not necessarily optimal.=C2= =A0 There are lots of topologies
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(e..g., parallel LANs) where this bla= nket approach is suboptimal.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0the question is how much are true LAN= s used as transit links in
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0today's
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0networks.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0thanks,
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Peter
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0> Tony
>=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=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0_____________________________________= __________
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Lsr mailing list
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Lsr@ietf.org <mailto:Lsr@ietf.org>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/= mailman/listinfo/lsr
>
>=C2=A0 =C2=A0 =C2=A0_______________________________________________
>=C2=A0 =C2=A0 =C2=A0Lsr mailing list
>=C2=A0 =C2=A0 =C2=A0L= sr@ietf.org <mailto:Lsr@ietf.org>
>=C2=A0 =C2=A0 =C2=A0https://www.ietf.org/mailman/listin= fo/lsr
>

--00000000000092b23605835f408e-- From nobody Tue Mar 5 13:08:26 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC45E1288BD for ; Tue, 5 Mar 2019 13:08:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 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 brCj8winypRW for ; Tue, 5 Mar 2019 13:08:23 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9483E128D0B for ; Tue, 5 Mar 2019 13:08:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1534; q=dns/txt; s=iport; t=1551820102; x=1553029702; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=LfRCrszyzBkG3x0QGw0T48uszZBQ918k+gEgx1/m90M=; b=BEUbbt2MEKA4Q6v8AHTFGBZgKmNwGoBV/h+aS/agEe/u/LYRBm/1JJx5 wmtwOP9WRib0l1oHMWrRyQ92CEbecpCuEK7q3QU717B9/Vds/OOZ54gEa AQGRDPQv7bjJnxBWz6l3xO8h+sM4SkVBjQDY9PjZ8JsR8f1lKTRtmKSRZ 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAADJ5H5c/xbLJq1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUwIBAQEBAQsBg3onhAiIeYx4mCGBew2EbAKETjYHDQE?= =?us-ascii?q?BAwEBAwEDAm0cDIVKAQEBAQIBDhUPAQUtFBALGAICJgICVxMGAgEBgx6Bbgi?= =?us-ascii?q?rM4EvhUSEbIELJAGLPoFAP4E4gj0uhU6CPYJXAqQHCZJuBhmKeogtnTKBTgw?= =?us-ascii?q?lgVYzGggbFYMniT6HDj4DMI5IKoIjAQE?= X-IronPort-AV: E=Sophos;i="5.58,445,1544486400"; d="scan'208";a="10506263" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Mar 2019 21:08:20 +0000 Received: from [10.60.140.54] (ams-ppsenak-nitro5.cisco.com [10.60.140.54]) by aer-core-3.cisco.com (8.15.2/8.15.2) with ESMTP id x25L8Jm5016048; Tue, 5 Mar 2019 21:08:20 GMT To: tony.li@tony.li References: <966E5756-8CEF-47F4-8564-E23D38F0743E@tony.li> <7F522B6C-9D28-4533-8ABD-9F492D9AF26C@tony.li> Cc: lsr@ietf.org From: Peter Psenak Message-ID: Date: Tue, 5 Mar 2019 22:08:19 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <7F522B6C-9D28-4533-8ABD-9F492D9AF26C@tony.li> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Outbound-SMTP-Client: 10.60.140.54, ams-ppsenak-nitro5.cisco.com X-Outbound-Node: aer-core-3.cisco.com Archived-At: Subject: Re: [Lsr] Open issues with Dynamic Flooding X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 21:08:25 -0000 Hi Tony, On 05/03/2019 21:47 , tony.li@tony.li wrote: > >>> LS topologies can have a very large number of adjacencies as well, >>> typically with multiple spines, so for a new spine, all of the of the >>> links may be unnecessary. >> >> ok, we talked bout the balance before - adding one link at a time to >> the FT may result in slow recovery, while adding all link is claimed >> to be dangerous. What is the right number? I feel that the increment >> value can be something that the implementation can choose or even make >> configurable, so the user can decide based on the particular topology >> and scale. We are not going to find the magic value I'm afraid. > > > > I agree that optimal is probably unknowable. The question then is what > do we say in the document? How about something about rate limiting? yes, something of that nature, with possible config option. > > >>> Let’s set the algorithmic parts aside. Do you have an objection to >>> supporting them in the signaling? >> >> will get complicated, especially for OSPF/OSPFv3. > > > I have great confidence in you. ;-) > > >> Also temporary flooding operation on LAN is tricky and sub-optimal. I >> don't really believe it's worth the complexity. > > > Ok, I’m not following this. It seems like one system would request > flooding and the other nodes would comply. Where’s this tricky? the trick is that "all" nodes would comply, where we may only need one/subset to do... thanks, Peter > > Tony > > From nobody Tue Mar 5 13:10:22 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC40130E62 for ; Tue, 5 Mar 2019 13:10:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 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 QFQ6rHTZX52J for ; Tue, 5 Mar 2019 13:10:17 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAAE01288BD for ; Tue, 5 Mar 2019 13:10:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7694; q=dns/txt; s=iport; t=1551820217; x=1553029817; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=9NdfxXl1G8TajDMkDLLOoXCX3A7b/fwbvDBaczXeIzo=; b=AB8JA0XAVJuanOiU6MtUJau+OWl58p7VkXnfdV/6YHs7WD0JDzJL7MrO 2HbR/WPSxzsZ4rv7siiM6+bLleo2+wRUAJbAJuiOaWsUL4/UmGWBLnFVb j2MaQnoHQdugphN2PhPpYIdG3XlG1MFUpm8I8S0pl9QpVPCnNQm/72ZvQ Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAADJ5H5c/xbLJq1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUwIBAQEBAQsBgWWBEoEDJ4QIiHmMeHyIMo5zgXsNGAu?= =?us-ascii?q?ESQKETjYHDQEBAwEBAwEDAm0cDIVKAQEBAQIBAQEhDwEFNgsQCxgCAiMDAgI?= =?us-ascii?q?hBh8RBg0GAgEBF4MHAYFdAw0ID6skgS+FRIJBDYIZBYELJAGLPoFAP4ERJ4I?= =?us-ascii?q?2By6CV0cBAYE6AYMwglcCikKMeIwaMwmPN4M3BhmBdIVkgyKILZFvi0OBTgI?= =?us-ascii?q?vgVYzGggbFTuCbIMtAQyGBIFOhUA+AzCOSAElBIIjAQE?= X-IronPort-AV: E=Sophos;i="5.58,445,1544486400"; d="scan'208";a="10506290" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 05 Mar 2019 21:10:14 +0000 Received: from [10.60.140.54] (ams-ppsenak-nitro5.cisco.com [10.60.140.54]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id x25LADlc007131; Tue, 5 Mar 2019 21:10:14 GMT To: Robert Raszuk References: <41bd7097-0d25-a2e0-843d-cb25fd13a84f@cisco.com> Cc: Tony Przygienda , lsr@ietf.org, Tony Li From: Peter Psenak Message-ID: Date: Tue, 5 Mar 2019 22:10:13 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Outbound-SMTP-Client: 10.60.140.54, ams-ppsenak-nitro5.cisco.com X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Lsr] Open issues with Dynamic Flooding X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 21:10:20 -0000 Robert, On 05/03/2019 22:06 , Robert Raszuk wrote: > Peter, > >> you only have two paths to reach any node. > > Who says that you must be limited to two paths only ? > > Why not create a flooding graph such that flooding will happen over 4 > paths as opposed to flooding over 16 or 32 today without optimization. > > And if you are worried that you loose *wisely selected* all 4 paths > before you manage to distribute new flooding topology you can always > flood over 6 :) we want to limit the flooding to minimum, which is 2. thanks, Peter > > Best, > R. > > > > > > > > On Tue, Mar 5, 2019 at 9:17 PM Peter Psenak > wrote: > > Robert, > > On 05/03/2019 20:12 , Robert Raszuk wrote: > > > >> Slow convergence is obviously not a good thing > > > > Could you please kindly elaborate why ? > > > > With tons of ECMP in DCs or with number of mechanism for very fast > data > > plane repairs in WAN (well beyond FRR) IMHO any protocol *fast > > convergence* is no longer a necessity. Yet many folks still talk about > > it like the only possible rescue ... > > we are talking about the control plane convergence, not data plane one. > If the flooding topology is subset of the real topology, then at the > flooding level you don't have all the ECMPs available - you only have > two paths to reach any node. In such case it is possible that the > flooding topology gets partitioned and you want to get out of that > state > quickly, as you may get out of sync with the the reality and eventually > loose all the data plane ECMPs as a consequence. > > thanks, > Peter > > > > > > > On Tue, Mar 5, 2019 at 5:42 PM Tony Przygienda > > > >> wrote: > > > > in practical terms +1 to Peter's take here ... Unless we're > talking > > tons of failures simultaneously (which AFAI talked to folks > are not > > that common but can sometimes happen in DCs BTW due to weird > things) > > smaller scale failures with few links would cause potentially > > diffused "chaining" of convergence behavior rather than IGP-style > > fast healing (and on top of that I didn't see a lot of interest in > > formalizing a rigorous distributed algorithm which IMO would be > > necessary to ensure ultimate convergence when only one/subset of > > links is used). Slow convergence is obviously not a good thing > > unless we assume people will run FRR with its complexity in DC > > and/or no more than one link every fails which seems to me bending > > assumptions to whatever solution is available/preferred. To Tony's > > point though, on large scale failures enabling all links would > cause > > heavy flood load, yes, but in a sense it's the "initial > bootup" case > > anyway (especially in centralized case) since nodes need all > > topology to make informed correct decisions about what the FT > should > > be if they don't rely on whatever the centralized instance thinks > > (which they won't be able to do given the FT from centralized > > instance will indicate lots links that are "gone" due to failure). > > As to p2p, I suggest to agree whether you use dense mesh (DC) case > > or sparse mesh (WAN) case or "every topology imaginable" since > that > > drives lots design trade-offs. > > > > my 2.71828182 cents ;-) > > > > --- tony > > > > On Tue, Mar 5, 2019 at 8:27 AM Peter Psenak > > >> wrote: > > > > Hi Tony, > > > > On 05/03/2019 17:16 , tony.li@tony.li > > > > wrote: > > > > > > Peter, > > > > > >>> (a) Temporarily add all of the links that would > appear to > > remedy the partition. This has the advantage that it is very > > likely to heal the partition and will do so in the minimal > > amount of convergence time. > > >> > > >> I prefer (a) because of the faster convergence. > > >> Adding all links on a single node to the flooding > topology is > > not going to cause issues to flooding IMHO. > > > > > > > > > Could you (or John) please explain your rationale behind > that? > > It seems counter-intuitive. > > > > it's limited to the links on a single node. From all the > practical > > purposes I don't expect single node to have thousands of > > adjacencies, at > > least not in the DC topologies for which the dynamic > flooding is > > being > > primary invented. > > > > In the environments with large number of adjacencies (e.g. > > hub-and-spoke) it is likely that we would have to make all > these > > links > > part of the flooding topology anyway, because the spoke is > > typically > > dual attached to two hubs only. And the incremental adjacency > > bringup is > > something that an implementation may already support. > > > > > > > > > > > > > >> given that the flooding on the LAN in both OSPF and ISIS is > > done as multicast, there is currently no way to enable > flooding, > > either permanent or temporary, towards a subset of the > neighbors > > on the LAN. So if the flooding is enabled on a LAN it is done > > towards all routers connected to the it.. > > > > > > > > > Agreed. > > > > > > > > >> Given that all links between routers are p2p these days, I > > would vote for simplicity and make the LAN always part of > the FT. > > > > > > > > > I’m not on board with this yet. Our simulations suggest > that > > this is not necessarily optimal. There are lots of topologies > > (e..g., parallel LANs) where this blanket approach is > suboptimal. > > > > the question is how much are true LANs used as transit > links in > > today's > > networks. > > > > thanks, > > Peter > > > > > > > > Tony > > > > > > . > > > > > > > _______________________________________________ > > Lsr mailing list > > Lsr@ietf.org > > > https://www.ietf.org/mailman/listinfo/lsr > > > > _______________________________________________ > > Lsr mailing list > > Lsr@ietf.org > > > https://www.ietf.org/mailman/listinfo/lsr > > > From nobody Tue Mar 5 13:12:16 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9DEF1288BD for ; Tue, 5 Mar 2019 13:12:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net 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 ssmBY56Xaamo for ; Tue, 5 Mar 2019 13:12:13 -0800 (PST) Received: from mail-qt1-x836.google.com (mail-qt1-x836.google.com [IPv6:2607:f8b0:4864:20::836]) (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 1FC64124D68 for ; Tue, 5 Mar 2019 13:12:13 -0800 (PST) Received: by mail-qt1-x836.google.com with SMTP id z39so10518997qtz.0 for ; Tue, 05 Mar 2019 13:12:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=uxr4b+V7DVWDcLdcUGCq09O1yqFjOX8d2cZjGeRicjc=; b=RgNYrSSHAD490IVSIlA+M+qbSnYyA24SmivxU9mOJ01GVPiORcc9MmK0S65DftTjGA LG8raAslE/EWeht6VP234MRq7gD509leby0e0jqcrubZddpETo2Tsa/ttIzz/wybmRnS atuXN7TFcXmw17Ma2wmZqvXpJf5YKTuoBqRHZSz80QN4SRXS+k67A6OUpl/4cF6BRN/c 3hRV23T3FKz0FMfr7CwVybNr0PDSCPqiqgAk8abFgCb4HWJd6gixIUbFzLt5Tu84ndZ4 NzS4vIdsj1aYeZ586tCR9LxOQe7a4sFh0El/pHRP8kAd2FYgBqsXLsObHzEW+MgMpbrI xEbA== 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=uxr4b+V7DVWDcLdcUGCq09O1yqFjOX8d2cZjGeRicjc=; b=XsrtP9wqkysQRpTvwP2GEF0VY/d2HyCH/eo0YmjsL15PPiMW2aJQLML+GPU7R3aEzc cuDkyOjAWRduojQ8Wqb1ndm3c4/xWv6MVr1gmdE1CaRzL6+Jmh/3N6Rff7hNEUWaprEs ZaPRkKNMTD9pKVTVLN0ge/w1vez2NlFwG1V1hhNNY8zgOEWyHfYtO6jQ1suW6VA6uO4i tHsRtt40l/8rfGkUWsTYQ7WTD+kJY/h8knMh9lq0SqqqKOIzOEN6QVWYPnUf560VKmS+ zI4xkr0bLzgksQamqON1a40KSXvm0aUM6vkaPqyTt7llHHN2jH7wyOX+I9IxtAkgFN+k 0voA== X-Gm-Message-State: APjAAAXou4wXtFq+PrVAFek4tcbjrtVupNJ4rzqU420tY24kRx6gKh6X qv2z4rktLYKg3+kzwVpM22bSVspp7uzHWjhmKF8rXg== X-Google-Smtp-Source: APXvYqyUNgSDbmuxOF8PaVTxSD9sXILf/DfQgmcl6Y9SScB/Jx3mpvYwcDL6aC6oTYmlJimnGIEkVQNYb70n9NjVp/s= X-Received: by 2002:ac8:2ce4:: with SMTP id 33mr3129863qtx.6.1551820331921; Tue, 05 Mar 2019 13:12:11 -0800 (PST) MIME-Version: 1.0 References: <41bd7097-0d25-a2e0-843d-cb25fd13a84f@cisco.com> In-Reply-To: From: Robert Raszuk Date: Tue, 5 Mar 2019 22:12:01 +0100 Message-ID: To: Peter Psenak Cc: Tony Przygienda , lsr@ietf.org, Tony Li Content-Type: multipart/alternative; boundary="000000000000a3c63c05835f53b7" Archived-At: Subject: Re: [Lsr] Open issues with Dynamic Flooding X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 21:12:15 -0000 --000000000000a3c63c05835f53b7 Content-Type: text/plain; charset="UTF-8" > we want to limit the flooding to minimum, which is 2. > Is that really a common agreement in the WG ? I have a feeling think this is too restrictive for no valid technical reason. r. --000000000000a3c63c05835f53b7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

we want to limit the flooding= to minimum, which is 2.

Is that really= a common agreement in the WG ? I have a feeling think this is too restrict= ive for no valid technical reason.=C2=A0

r.
<= div>
=C2=A0
--000000000000a3c63c05835f53b7-- From nobody Tue Mar 5 13:23:38 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18A8A130E5F for ; Tue, 5 Mar 2019 13:23:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.018, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 lWW0_lSaiVmf for ; Tue, 5 Mar 2019 13:23:36 -0800 (PST) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0: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 6523D130DCB for ; Tue, 5 Mar 2019 13:23:36 -0800 (PST) Received: by mail-pg1-x531.google.com with SMTP id r124so6522935pgr.3 for ; Tue, 05 Mar 2019 13:23:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=3tOuko6NIrAkVNIBGwIOVnXBlcC3X0s99MMzswEZPIc=; b=cTsnOHCiRMfZjesNP/hpXknxaOmddSf+LKsytiPzS28Tux2tQaCvHbKrmIC6fF5+Rn GwzJJG/CH1esM/NuKETIKbPXWiZVyjbZsvxDq2HXc5zWGq+HwoYSQdc3iW7OSprJePdc n6eTQHznyW60/SmA9gi9DUzvg6mhsHdH+MxS3cTvtRjjDBp39iko0OECdRnWIA3Cvm+5 1WcjRR3rkAz+qgNz6KcwQgzXAs3yfQtUtyElAN4qKXwosfudXh7jVoSdUOl+FUqZujrJ 2tGGhclk3JcyUy2NRi4osdDd2dzy8T7TJH+S3rasqyn8wrL4lXUEMXgBxvhEpdEkMCxi c6rA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=3tOuko6NIrAkVNIBGwIOVnXBlcC3X0s99MMzswEZPIc=; b=hud21iDRS7oMy7immyRRoldCzynooSfr3LE3IfdmBLL2meHQ6+BgLncXR7OHM4VZbU IBBYU4aOkEG0AtaEK9b/ffg6DNlqMkjqLnOSgC8e8kf8Bw5oT9oQP8PoyGXlRSglwXxV qjKViku/Kr5kPmKadE1VLZ3Ek2tyaurqXyObzGs9sRAaDWIqWaEcuGzk5014hUFTTMQG 1Kb+aUq6BbFRrGkde+gvYKODfyQuyosBv+5JNllTXeEzCgffX7+tympxAtXmFG++SpQe v0/phTOWsWewcDn/ifm2cW3I5I/+pFp2qSs+atgvf0q15fh40U8ciQM4tPURlQ3yjZPT 0EhA== X-Gm-Message-State: APjAAAXinAbiU3zHkHMx4UPxrp7IfwD9dRLckS0hGO0joe1T8Ek4eFak D/HxnakFfjCaQp/Kkq0Spjk= X-Google-Smtp-Source: APXvYqwfahz37v524nT/2Txr/UZTcITTLUzT8SMOqa4FrXprujDCGVeZzpQG/a65m/VlQ8lykh1krQ== X-Received: by 2002:a65:568b:: with SMTP id v11mr3272610pgs.23.1551821015847; Tue, 05 Mar 2019 13:23:35 -0800 (PST) Received: from [172.22.228.48] ([162.210.130.3]) by smtp.gmail.com with ESMTPSA id s6sm19344309pgm.90.2019.03.05.13.23.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Mar 2019 13:23:35 -0800 (PST) Sender: Tony Li Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: tony.li@tony.li In-Reply-To: Date: Tue, 5 Mar 2019 13:23:34 -0800 Cc: Peter Psenak , Tony Przygienda , lsr@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <7B8B4AEA-AB49-43D6-8ACC-69A77F0332EA@tony.li> References: <41bd7097-0d25-a2e0-843d-cb25fd13a84f@cisco.com> To: Robert Raszuk X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Lsr] Open issues with Dynamic Flooding X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 21:23:38 -0000 > Is that really a common agreement in the WG ? I have a feeling think = this is too restrictive for no valid technical reason.=20 Well, it=E2=80=99s been the requirement that has been unchallenged since = we started this journey. The technical reason for this is clear: if too much flooding is hurting = you and we need bi-connectivity to protect against failures, then adding = more connectivity seems like it negates the benefits of the restricted = topology. I should note that for many topologies and for many nodes, being just = bi-connected will not be possible. In any interesting LS network, for = example, where # leaves >> # spines, the spines will still have many = active connections in the FT. While having leaves with 4 or 6 = connections is certainly possible, it seems inadvisable. Tony From nobody Tue Mar 5 13:31:27 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14DF213104F for ; Tue, 5 Mar 2019 13:31:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.881 X-Spam-Level: X-Spam-Status: No, score=-1.881 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.018, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 ksQtCY9wfsMH for ; Tue, 5 Mar 2019 13:31:24 -0800 (PST) Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (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 EEAC3130DEF for ; Tue, 5 Mar 2019 13:31:23 -0800 (PST) Received: by mail-pg1-x52b.google.com with SMTP id k11so5548438pgb.8 for ; Tue, 05 Mar 2019 13:31:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=W0EIweRcEM+7gDSRFsObDV8Joa1i2VxdsW/IgpYK7/M=; b=pv76RyK3RJnDg9w+PeMTxNzS9ZaLvp5C+Y4BsSXxo1Z97D8Sd51C2mWA1TJwiBLzMB zB6QceOh0qVz0RsH0regFJYb8u+xHU7YYTOyJ86Ohbp+zX6nUOd2qwH0WxyT3PGib0Dq BDvg7SjgtEYadGxJVIcL8oBjZDqSjmj+lixEgbFHbo8dWslQLwIdiuwvzT+8/pTWok2C QkyfI4tv7AWIf38PA9GZhsXPt/RhblJqwpp/XVRsoyjgiQcIWmmGUKxFBIPkC8Tg3uhx DCF3ZHig5+Asc+3qtbXe3dcrxVZ7pXuRa/JOOeXWT0Q7M1EQW1ftItN8VgNWnXQGcZ8L nOjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=W0EIweRcEM+7gDSRFsObDV8Joa1i2VxdsW/IgpYK7/M=; b=W/FKuLYhWmwpwCFeLflJ8/fTVWiDCwRS2b7CgEkEc+2fG1y4oWNDFPaeWVqzAwZnL+ WtocZnE+6BkGBICqBxhVCFjg/Kc6tsvS/ZDfMmjn0H/3OVt+dKJtJoLnKtdPsYC7T7xC 8m4djt7X3T0/Sr4WQ3a8LzXuufnF/iSfW7+2FmeD+f9UHy0nN6N5ImtMdBTdQDdElD1E hX9VNH/MSc1JsL6C/5fLPUK+gyoPvPLQbz37d0RqXQ3FvjOV6OQ6Kf9tR7EFivGkkxNP dpJfcskrs24kkSBea3Lmlw9cxqwq1qmUphe5FtRzMe/6vSZrlr/SEwchcRID10XhI9wU bqEQ== X-Gm-Message-State: APjAAAV0G6RmDEqtZqcCewOM29oRu80WE3gsVUk+hTq9KRCdhk2FRijn aHKS+TTC2L2k3gjnFBju+YI= X-Google-Smtp-Source: APXvYqwWLgXOzPT8HWF+AifUTnsPRuNl5TIpMfjJsQ8SguYczKwN+wAaLCDBaYY2+E0tw4BUFVS+ZQ== X-Received: by 2002:a17:902:e90b:: with SMTP id cs11mr3243385plb.197.1551821483446; Tue, 05 Mar 2019 13:31:23 -0800 (PST) Received: from [172.22.228.48] ([162.210.130.3]) by smtp.gmail.com with ESMTPSA id v8sm18497428pfm.174.2019.03.05.13.31.22 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 05 Mar 2019 13:31:22 -0800 (PST) Sender: Tony Li Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: tony.li@tony.li In-Reply-To: Date: Tue, 5 Mar 2019 13:31:22 -0800 Cc: lsr@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <2932F33A-1F9E-4C20-A233-E569D8935AE4@tony.li> References: <966E5756-8CEF-47F4-8564-E23D38F0743E@tony.li> <7F522B6C-9D28-4533-8ABD-9F492D9AF26C@tony.li> To: Peter Psenak X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Lsr] Open issues with Dynamic Flooding X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Mar 2019 21:31:26 -0000 >> I agree that optimal is probably unknowable. The question then is = what >> do we say in the document? How about something about rate limiting? >=20 > yes, something of that nature, with possible config option. Let me propose that we add something to sections 6.7.5, 6.7.9, and = 6.7.11 like: Addition of temporary flooding should be done with caution, as the = addition of excessive connectivity to the flooding topology may trigger = unwanted behavior. Routers SHOULD add temporary flooding in a rate = limited manner, if not configured otherwise. > the trick is that "all" nodes would comply, where we may only need = one/subset to do... This is the addition of one link, and in particular the onus is really = on the DIS to drive synchronization. Per your above arguments, I=E2=80=99= m comfortable with this. Tony From nobody Tue Mar 5 21:05:08 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C0D3130EB8; Tue, 5 Mar 2019 21:05:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 AxaebnSWsVMW; Tue, 5 Mar 2019 21:05:04 -0800 (PST) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 868B012D4EF; Tue, 5 Mar 2019 21:05:03 -0800 (PST) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 4C68AF5014D4A9A00B35; Wed, 6 Mar 2019 05:05:01 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 6 Mar 2019 05:05:00 +0000 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.96]) by SJCEML702-CHM.china.huawei.com ([169.254.4.10]) with mapi id 14.03.0415.000; Tue, 5 Mar 2019 21:04:54 -0800 From: Huaimo Chen To: Tony Li CC: Christian Hopps , "lsr@ietf.org" , "lsr-chairs@ietf.org" , "lsr-ads@ietf.org" Thread-Topic: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll. Thread-Index: AQHUwfc3rlPy0Ul4REi1Ut4/82BOw6XsOGoAgAJCW3CAAWolgIADTJLAgACmyQCAClTjYA== Date: Wed, 6 Mar 2019 05:04:54 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D463B66FE9@sjceml521-mbx.china.huawei.com> References: <5316A0AB3C851246A7CA5758973207D463B5858A@sjceml521-mbx.china.huawei.com> <420ed1b5-d849-99cc-bcb0-d159783e4de2@cisco.com> <5316A0AB3C851246A7CA5758973207D463B59041@sjceml521-mbx.china.huawei.com> <0B4DF2AC-8EE1-41CA-B357-98325067CA30@gmail.com> In-Reply-To: <0B4DF2AC-8EE1-41CA-B357-98325067CA30@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.189] Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D463B66FE9sjceml521mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll. X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 05:05:07 -0000 --_000_5316A0AB3C851246A7CA5758973207D463B66FE9sjceml521mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVG9ueSwNCg0KPiBGcm9tOiBUb255IExpIFttYWlsdG86dG9ueTFhdGhvbWVAZ21haWwuY29t XQ0KPiBTZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDI3LCAyMDE5IDI6MDcgQU0NCj4gVG86IEh1 YWltbyBDaGVuIDxodWFpbW8uY2hlbkBodWF3ZWkuY29tPg0KPiBDYzogUGV0ZXIgUHNlbmFrIDxw cHNlbmFrQGNpc2NvLmNvbT47IENocmlzdGlhbiBIb3BwcyA8Y2hvcHBzQGNob3Bwcy5vcmc+OyBs c3JAaWV0Zi5vcmc7DQo+IGxzci0gY2hhaXJzQGlldGYub3JnOyBsc3ItYWRzQGlldGYub3JnDQo+ IFN1YmplY3Q6IFJlOiBbTHNyXSBXRyBBZG9wdGlvbiBDYWxsIGZvciBkcmFmdC1saS1sc3ItZHlu YW1pYy1mbG9vZGluZy0wMiArIElQUiBwb2xsLg0KPg0KPg0KPiBIaSBIdWFpbW8sDQo+DQo+ID4g PiAxKSAgICAgICAgICAgVGhlcmUgaXMgbm8gY29uY3JldGUgcHJvY2VkdXJlL21ldGhvZCBmb3Ig ZmF1bHQgdG9sZXJhbmNlDQo+ID4gPiB0byBtdWx0aXBsZSBmYWlsdXJlcy4gV2hlbiBtdWx0aXBs ZSBmYWlsdXJlcyBoYXBwZW4gYW5kIHNwbGl0IHRoZQ0KPiA+PiAgZmxvb2RpbmcgdG9wb2xvZ3ks IHRoZSBjb252ZXJnZW5jZSB0aW1lIHdpbGwgYmUgaW5jcmVhc2VkDQo+ID4gPiBzaWduaWZpY2Fu dGx5IHdpdGhvdXQgZmF1bHQgdG9sZXJhbmNlLiBUaGUgbG9uZ2VyIHRoZSBjb252ZXJnZW5jZQ0K PiA+PiAgdGltZSwgdGhlIG1vcmUgdGhlIHRyYWZmaWMgbG9zZS4NCj4gPg0KPiA+IHRoZXJlIGlz IGEgc29sdXRpb24gZm9yIG11bHRpcGxlIGZhaWx1cmVzIC0gc2VlIHNlY3Rpb24gNi43LjExLg0K PiA+DQoNCj4gPiBTZWN0aW9uIDYuNy4xMSBqdXN0IGJyaWVmbHkgbWVudGlvbnMgdGhhdCB0aGUg ZWRnZXMgb2Ygc3BsaXQgcGFydHMgd2lsbCBkZXRlcm1pbmUNCj4gPiBhbmQgcmVwYWlyIHRoZSBz cGxpdCBhZnRlciB0aGUgc3BsaXQgb2YgdGhlIGZsb29kaW5nIHRvcG9sb2d5IGhhcHBlbnMuIEhv d2V2ZXIsDQo+ID4gdGhlcmUgaXMgbm90IGFueSBkZXRhaWxzIG9yIGRlc2NyaXB0aW9uIG9uIGhv dyB0byBkZXRlcm1pbmUgb3IgcmVwYWlyIHRoZSBzcGxpdC4NCj4gPiBUaGlzIGlzIG5vdCB1c2Vm dWwgZm9yIGltcGxlbWVudGVycy4NCg0KDQo+IEnigJltIHNvcnJ5IHRoYXQgeW91IGRvbuKAmXQg ZmluZCBpdCB1c2VmdWwuIERldGVybWluaW5nIHRoZSBzcGxpdCBpcyB0cml2aWFsOiB3aGVuIHlv dSByZWNlaXZlIGFuIElJSCwNCj4gaXQgaGFzIGEgc3lzdGVtIElEIG9mIHRoZSBhbm90aGVyIHN5 c3RlbSBpbiBpdC4gSWYgdGhhdCBvdGhlciBzeXN0ZW0gaXMgbm90IGN1cnJlbnRseSBwYXJ0IG9m IHRoZQ0KPiBmbG9vZGluZyB0b3BvbG9neSwgdGhlbiBpdCBpcyBxdWl0ZSBjbGVhciB0aGF0IGl0 IGlzIGRpc2Nvbm5lY3RlZCBmcm9tIHRoZSBmbG9vZGluZyB0b3BvbG9neS4NCj4gUmVwYWlyaW5n IHRoZSBzcGxpdCBpcyBkb25lIGJ5IGVuYWJsaW5nIHRlbXBvcmFyeSBmbG9vZGluZyBvbiB0aGUg bmV3IGxpbmsuDQoNCkZvciBhbiBhZGphY2VuY3kgYmV0d2VlbiB0d28gbm9kZXMgaXMgdXAsIHRo ZSBIZWxsbyBwYWNrZXRzIGV4Y2hhbmdlZCBiZXR3ZWVuIHRoZW0gd2lsbCBub3QgY2hhbmdlIG5v ZGUvc3lzdGVtIElEcyBpbiB0aGVtLg0KSG93IGRvIHlvdSBkZXRlcm1pbmUgdGhhdCBvdGhlciBz eXN0ZW0gaXMgbm90IGN1cnJlbnRseSBwYXJ0IG9mIHRoZSBmbG9vZGluZyB0b3BvbG9neT8NCg0K DQo+IFRoZXJlIGlzIGFuIGlzc3VlIGhlcmUgdGhhdCB3ZSBoYXZlIG5vdCB5ZXQgcmVzb2x2ZWQs IHdoaWNoIGlzIHRoZSByYXRlIHRoYXQgbmV3IGxpbmtzIHNob3VsZCBiZQ0KPiB0ZW1wb3Jhcmls eSBhZGRlZCB0byB0aGUgZmxvb2RpbmcgdG9wb2xvZ3kuICBTb21lIGJlbGlldmUgdGhhdCBhZGRp bmcgYW55IG5ldyBsaW5rIGlzIHRoZQ0KPiBjb3JyZWN0IHRoaW5nIHRvIGRvIGFzIGl0IG1pbmlt aXplcyB0aGUgcmVjb3ZlcnkgdGltZS4gT3RoZXJzIGZlZWwgdGhhdCBlbmFibGluZyB0b28gbWFu eSBsaW5rcw0KPiBjb3VsZCBjYXVzZSBhIGZsb29kaW5nIGNvbGxhcHNlLCBzbyBsaW5rIGFkZGl0 aW9uIHNob3VsZCBiZSBoaWdobHkgY29uc3RyYWluZWQuIFdlIGFyZSBzdGlsbA0KPiBkaXNjdXNz aW5nIHRoaXMgYW5kIGludml0ZSB0aGUgV0figJlzIG9waW5pb25zLg0KDQpUaGUgaXNzdWUgaXMg cmVzb2x2ZWQgYnkgdGhlIHNvbHV0aW9ucyBpbiBkcmFmdC1jYy1sc3ItZmxvb2RpbmctcmVkdWN0 aW9uLg0KT25lIHNvbHV0aW9uIGlzIGJlbG93LCB3aGVyZSB0aGUgZ2l2ZW4gZGlzdGFuY2UgY2Fu IGJlIGFkanVzdGVkL2NvbmZpZ3VyZWQuDQpJZiB3ZSB3YW50IGV2ZXJ5IG5vZGUgdG8gZmxvb2Qg b24gYWxsIGl0cyBsaW5rcywgd2UgbGV0IHRoZSBnaXZlbg0KZGlzdGFuY2UgdG8gYSBiaWcgbnVt YmVyLiBJZiB3ZSB3YW50IHRoZSBub2RlcyB3aXRoaW4gMiBob3BzIHRvIGEgZmFpbHVyZQ0KdG8g Zmxvb2Qgb24gYWxsIHRoZWlyIGxpbmtzLCB3ZSBzZXQgdGhlIGdpdmVuIGRpc3RhbmNlIHRvIDIu DQogICDigJxJbiBvbmUgd2F5LCB3aGVuIHR3byBvciBtb3JlIGZhaWx1cmVzIG9uIHRoZSBjdXJy ZW50IGZsb29kaW5nDQogICB0b3BvbG9neSBvY2N1ciBhbG1vc3QgaW4gdGhlIHNhbWUgdGltZSwg ZWFjaCBvZiB0aGUgbm9kZXMgd2l0aGluIGENCiAgIGdpdmVuIGRpc3RhbmNlIChzdWNoIGFzIDMg aG9wcykgdG8gYSBmYWlsdXJlIHBvaW50LCBmbG9vZHMgdGhlIGxpbmsNCiAgIHN0YXRlIChMUykg dGhhdCBpdCByZWNlaXZlcyB0byBhbGwgdGhlIGxpbmtzIChleGNlcHQgZm9yIHRoZSBvbmUgZnJv bQ0KICAgd2hpY2ggdGhlIExTIGlzIHJlY2VpdmVkKSB1bnRpbCBhIG5ldyBmbG9vZGluZyB0b3Bv bG9neSBpcyBidWlsdC7igJ0NCg0KQW5vdGhlciBzb2x1dGlvbiBpcyBqdXN0IGFkZGluZyBtaW5p bXVtIGxpbmtzIHRlbXBvcmFyaWx5IG9uIHRoZSBmbG9vZGluZw0KdG9wb2xvZ3kgdG8gcmVwYWly IHRoZSBzcGxpdCBmbG9vZGluZyB0b3BvbG9neSB1bnRpbCBhIG5ldyBmbG9vZGluZyB0b3BvbG9n eQ0KaXMgYnVpbHQuDQoNCj4gPiA+IDIpICAgICAgICAgICBUaGUgZXh0ZW5zaW9ucyB0byBIZWxs byBwcm90b2NvbHMgZm9yIGVuYWJsaW5nIOKAnHRlbXBvcmFyeQ0KPiA+IGZsb29kaW5n4oCdIG92 ZXIgYSBuZXcgbGluayBpcyBub3QgbmVlZGVkLg0KPiA+DQo+ID4gbm90IGlmIHlvdSBkbyBmbG9v ZGluZyBvbiBldmVyeSBsaW5rIHRoYXQgY29tZXMgdXAuIElmIHlvdSB3YW50IHRvIGJlIHNtYXJ0 ZXIsIHRoZW4geW91IG5lZWQgdG8NCj4gPiBzZWxlY3RpdmVseSBlbmFibGUgZmxvb2Rpbmcgb25s eSB1bmRlciBzcGVjaWZpYyBjb25kaXRpb25zIGFuZCB0aGF0IG11c3QgYmUgZG9uZSBmcm9tIGJv dGggc2lkZXMgb2YNCj4gPiB0aGUgbmV3IGxpbmsuDQoNCj4gPiBUaGVyZSBhcmUgb25seSBhIGxp bWl0ZWQgbnVtYmVyIG9mIGNvbmRpdGlvbnMgKG9yIGNhc2VzKS4gIEluIGVhY2ggY29uZGl0aW9u L2Nhc2UsIGl0IGlzDQo+ID4gZGV0ZXJtaW5pc3RpYyB3aGV0aGVyIHdlIG5lZWQgdG8gZW5hYmxl IOKAnHRlbXBvcmFyeSBmbG9vZGluZ+KAnSBmb3IgYSBuZXcgbGluayB3aGVuIGl0DQo+ID4gaXMg dXAuICBUaHVzIHRoZXJlIGlzIG5vIG5lZWQgZm9yIGFueSBleHRlbnNpb25zIHRvIEhlbGxvIHBy b3RvY29scyBmb3IgZW5hYmxpbmcNCj4gPiDigJx0ZW1wb3JhcnkgZmxvb2RpbmfigJ0gb24gYSBu ZXcgbGluay4NCg0KDQo+IFdlIGtub3cgb2Ygb25seSB0d28gY2FzZXM6ICgxKSB0aGUgbmVpZ2hi b3IgaXMgbm90IHBhcnQgb2YgdGhlIGZsb29kaW5nIHRvcG9sb2d5IGFuZCB3ZSBmZWVsDQo+IHRo YXQgd2UgY2FuIGFkZCBtb3JlIHRlbXBvcmFyeSBmbG9vZGluZy4gKDIpIFRoZSBuZWlnaGJvciBp cyBub3QgcGFydCBvZiB0aGUgZmxvb2RpbmcgdG9wb2xvZ3kNCj4gYW5kIHdlIGNhbm5vdCBhZGQg bW9yZSB0ZW1wb3JhcnkgZmxvb2RpbmcuDQoNCj4gT2J2aW91c2x5LCBpbiB0aGUgY2FzZSB3aGVy ZSB3ZSB3YW50IHRvIGFkZCB0ZW1wb3JhcnkgZmxvb2RpbmcsIHRoYXQgVExWIGlzIG5lZWRlZCBp biB0aGUgSUlILg0KDQoNCj4gPiBGb3IgZXhhbXBsZSwgc3VwcG9zZSB0aGF0IHdlIGhhdmUgYSBj dXJyZW50IGZsb29kaW5nIHRvcG9sb2d5IGNvbnRhaW5pbmcgYWxsIGxpdmUNCj4gPiBub2RlcyBp biBhbiBhcmVhLCB3aGVuIGEgbmV3IGxpbmsgY29tZXMgdXAsIHdlIG1heSBqdXN0IGhhdmUgdHdv IGNvbmRpdGlvbnMvY2FzZXMuDQo+ID4gT25lIGNvbmRpdGlvbi9jYXNlIGlzIHRoYXQgdGhlIG5l dyBsaW5rIGlzIGF0dGFjaGVkIHRvIGEgbmV3IG5vZGUgbm90IG9uIHRoZSBjdXJyZW50DQo+ID4g Zmxvb2RpbmcgdG9wb2xvZ3kuIEluIHRoaXMgY29uZGl0aW9uL2Nhc2UsIHRoZSBuZXcgbGluayBu ZWVkcyB0byBiZSBlbmFibGVkIGZvcg0KPiA+IOKAnHRlbXBvcmFyeSBmbG9vZGluZ+KAnSBhZnRl ciBpdCBpcyB1cC4NCg0KDQo+IEFncmVlZCwgd2hpY2ggaXMgd2h5IHdlIG5lZWQgdGhlIFRMVi4N Cg0KVGhlIGxpbmsgY2FuIGJlIGVuYWJsZWQgZm9yIOKAnHRlbXBvcmFyeSBmbG9vZGluZ+KAnSBi eSB0aGUgbm9kZSB3aXRob3V0IHVzaW5nIGFueSBUTFYgb3IgSGVsbG8gd2l0aCB0aGUgVExWLg0K DQo+ID5UaGUgb3RoZXIgY29uZGl0aW9uL2Nhc2UgaXMgdGhhdCB0aGUgbmV3IGxpbmsgaXMgYXR0 YWNoZWQgdG8gbm9kZXMgb24gdGhlIGN1cnJlbnQNCj4gPmZsb29kaW5nIHRvcG9sb2d5LiBJbiB0 aGlzIGNvbmRpdGlvbi9jYXNlLCB0aGVyZSBpcyBubyBuZWVkIHRvIGVuYWJsZSDigJx0ZW1wb3Jh cnkNCj4gPiBmbG9vZGluZ+KAnSBvbiB0aGUgbGluay4NCg0KDQo+QWdyZWVkLg0KDQo+Tm90ZSB0 aGF0IHRoZXJlIGFyZSBzb21lIGFkZGl0aW9uYWwgY29ybmVyIGNhc2VzLiAgU2luY2UgdGhlIHR3 byBuZWlnaGJvcnMgbWF5IG5vdCBoYXZlIHRoZQ0KPmV4YWN0IHNhbWUgaW5mb3JtYXRpb24sIG9u ZSBtYXkgY29uc2lkZXIgdGhlIG90aGVyIHRvIGJlIG9uIHRoZSBmbG9vZGluZyB0b3BvbG9neSB3 aGVuIGluIGZhY3QNCj4gaXQgaXMgbm90LiAgVGhpcyBtaWdodCBoYXBwZW4gaW4gdGhlIGNhc2Ug b2YgYSBub2RlIHJlYm9vdC4gVGhlIElJSCBUTFYgZ2l2ZXMgdXMgYW4gZXhwbGljaXQgd2F5DQo+ IG9mIHNpZ25hbGluZywgcmF0aGVyIHRoYW4gc2ltcGx5IGd1ZXNzaW5nIGFuZCBzb21ldGltZXMg Z2V0dGluZyBpdCB3cm9uZy4NCg0KVGhlIFRMViBpbiBIZWxsbyBwYWNrZXQganVzdCByZXF1ZXN0 cyBmb3IgYWRkaW5nIOKAnHRlbXBvcmFyeSBmbG9vZGluZ+KAnSBvbiB0aGUgbGluay4gVGhlIG90 aGVyIGluZm9ybWF0aW9uIGlzIGFjY2Vzc2VkIGJ5IHRoZSBub2RlIGxvY2FsbHkuIFRoZSBUTFYg aW4gSGVsbG8gcGFja2V0IGRvZXMgbm90IGhlbHAgZm9yIGNvcm5lciBjYXNlLiBJbiB0aGUgY2Fz ZSB3aGVyZSBhIG5vZGUgaXMgcmVib290ZWQsIGEgbmV3IGxpbmsgYXR0YWNoZWQgdG8gYSBuZXcg bm9kZSBtYXkgYXBwbHkuDQoNCg0KPj4gPiAzKSAgICAgICAgICAgVGhlIGV4dGVuc2lvbnMgdG8g SGVsbG8gcHJvdG9jb2xzIGZvciByZXF1ZXN0aW5nL3NpZ25hbGluZw0KPj4gPiDigJx0ZW1wb3Jh cnkgZmxvb2RpbmfigJ0gZm9yIGEgY29ubmVjdGlvbiBkb2VzIG5vdCB3b3JrLg0KPj4+DQo+Pj4g c29ycnksIGJ1dCBpZiB5b3Ugc2VlIGEgcHJvYmxlbSwgcGxlYXNlIHByb3ZpZGUgZGV0YWlscywg c2F5aW5nIGFib3ZlIGlzDQo+Pj4gc2ltcGx5IHVucHJvZHVjdGl2ZS4NCg0KPj4g4oCcVGhlIG5v ZGVzIOKApiB3aWxsIHRyeSB0byByZXBhaXIgdGhlIGZsb29kaW5nIHRvcG9sb2d5IGxvY2FsbHkg YnkgZW5hYmxpbmcNCj4+dGVtcG9yYXJ5IGZsb29kaW5nIHRvd2FyZHMgdGhlIG5vZGVzIHRoYXQg dGhleSBjb25zaWRlciBkaXNjb25uZWN0ZWQgZnJvbSB0aGUNCj4+Zmxvb2RpbmcgdG9wb2xvZ3kg Li4u4oCdDQoNCj4+VGhlIGFib3ZlIHF1b3RlZCB0ZXh0IGlzIGZyb20gZHJhZnQtbGktbHNyLWR5 bmFtaWMtZmxvb2RpbmctMDIsIHdoZXJlDQo+PiDigJxlbmFibGluZyB0ZW1wb3JhcnkgZmxvb2Rp bmcgdG93YXJkcyB0aGUgbm9kZXPigJ0gaXMgdG8gcmVxdWVzdC9zaWduYWwNCj4+IOKAnHRlbXBv cmFyeSBmbG9vZGluZ+KAnSBmb3IgYSBjb25uZWN0aW9uIHRvIGNvbm5lY3QgcGFydGl0aW9uZWQv ZGlzY29ubmVjdGVkDQo+PmZsb29kaW5nIHRvcG9sb2d5IGludG8gb25lIHRocm91Z2ggdGhlIGV4 dGVuc2lvbnMgdG8gSGVsbG8gcHJvdG9jb2xzIGRlc2NyaWJlZA0KPj5pbiBkcmFmdC1saS1sc3It ZHluYW1pYy1mbG9vZGluZy0wMi4gUmlnaHQ/DQoNCj4+VGhlIGV4dGVuc2lvbnMgdG8gSGVsbG8g cHJvdG9jb2xzIGZvciByZXF1ZXN0aW5nL3NpZ25hbGluZyDigJx0ZW1wb3JhcnkNCj4+Zmxvb2Rp bmfigJ0gZm9yIGEgY29ubmVjdGlvbiB0byBjb25uZWN0IHBhcnRpdGlvbmVkL2Rpc2Nvbm5lY3Rl ZCBmbG9vZGluZw0KPj50b3BvbG9neSBpbnRvIG9uZSBkb2VzIG5vdCB3b3JrIHNpbmNlIHRoZSBj b25uZWN0aW9uIG1heSBoYXZlIHR3byBvciBtb3JlDQo+PmhvcHMgYW5kIGEgSGVsbG8gcGFja2V0 IG1heSBnZXQgbG9zdC4NCg0KDQo+QWxsIGFkamFjZW5jaWVzIGFyZSBhIHNpbmdsZSBob3AgaW4g Ym90aCBJUy1JUyBhbmQgT1NQRi4gIFllcywgSGVsbG8gcGFja2V0cyBtYXkgYmUgbG9zdC4NCj5G b3J0dW5hdGVseSwgdGhleSBhcmUgcGVyaW9kaWNhbGx5IHRyYW5zbWl0dGVkLCB0aHVzIHRoZSBu ZXh0IHRyYW5zbWlzc2lvbiB3aWxsIGFsc28gY29udGFpbiB0aGUNCj4gVExWLiAgSWYgSUlI4oCZ cyBhcmUgZ2V0dGluZyBsb3N0IGF0IGEgc2lnbmlmaWNhbnQgcmF0ZSwgdGhlbiB0aGUgYWRqYWNl bmN5IHdpbGwgbm90IChhbmQgc2hvdWxkIG5vdCkNCj5jb21lIHVwLiAgVGh1cywgdGhlIHJlcXVl c3QgZm9yIHRlbXBvcmFyeSBmbG9vZGluZyB3aWxsIHByb3BhZ2F0ZSB0byB0aGUgbmVpZ2hib3Ig aW4gYWxsIGNhc2VzDQo+dGhhdCBtYXR0ZXIuDQoNCkl0IHRha2VzIHRvbyBsb25nIHdoZW4gSGVs bG8gcGFja2V0IGlzIGxvc3QuIFJlcGFpcmluZyBzcGxpdCBmbG9vZGluZyB0b3BvbG9neSBuZWVk cyB0byBiZSBmYXN0Lg0KDQo+Pkl0IGlzIG5vdCBjb252ZW5pZW50IGZvciBhIHVzZXIvb3BlcmF0 b3IgdG8gY29uZmlndXJlIG9uIGFuIGFyZWEgbGVhZGVyIHNpbmNlIHRoZQ0KPj5sZWFkZXIgaXMg ZHluYW1pY2FsbHkgc2VsZWN0ZWQuIEhvdyBkbyB5b3UgYWRkcmVzcyB0aGlzPw0KDQoNCj5ObyBj b25maWd1cmF0aW9uIGlzIHJlcXVpcmVkLiAgVGhlIGVsZWN0aW9uIGFsZ29yaXRobSBzZWxlY3Rz IHRoZSBhcmVhIGxlYWRlci4gIFRoZSBydWxlcyBhcmUgaW4NCj50aGUgZHJhZnQuICBBbiBpbXBs ZW1lbnRhdGlvbiBtYXkgaGF2ZSBhIGRlZmF1bHQgcHJpb3JpdHkgYW5kIGEgZGVmYXVsdCBhbGdv cml0aG0gc2V0dGluZywgc28gbm8NCj5jb25maWd1cmF0aW9uIGlzIG1hbmRhdG9yeS4gIElmIHRo ZSBvcGVyYXRvciBkZXNpcmVzIGEgc3BlY2lmaWMgbm9kZSB0byBiZWNvbWUgYXJlYSBsZWFkZXIs IHRoZW4NCj5jb25maWd1cmF0aW9uIG1heSBiZSByZXF1aXJlZCB0byBhZGp1c3QgdGhlIHByaW9y aXR5LiAgRldJVywgd2UgaGF2ZSB0aGlzIGFscmVhZHkgd29ya2luZyBpbg0KPm91ciBpbXBsZW1l bnRhdGlvbi4gIEl0IEp1c3QgV29ya3MuDQoNCkl0IGRvZXMgbm90IG1lYW4gdGhhdCBhIHVzZXIv b3BlcmF0b3IgY29uZmlndXJlcy9zZWxlY3QgYW4gYXJlYSBsZWFkZXIuIEl0IG1lYW5zIHRoYXQg YSB1c2VyL29wZXJhdG9yIGNvbmZpZ3VyZXMgb3RoZXIgdGhpbmdzIHN1Y2ggYXMgaW5kaWNhdGlu ZyBhbiBhbGdvcml0aG0gb3Igc2VsZWN0aW5nIHRoZSBjZW50cmFsaXplZCBtb2RlIG9uIHRoZSBh cmVhIGxlYWRlci4NCg0KPj5BZnRlciB0aGUgdXNlci9vcGVyYXRvciBkb2VzIHNvbWUgY29uZmln dXJhdGlvbnMgb24gdGhlIChkZXNpZ25hdGVkKSBsZWFkZXIsIHdpbGwgdGhlDQo+PmJhY2t1cCBs ZWFkZXIgdGFrZXMgb3ZlciB0aGUgY29uZmlndXJhdGlvbnMgYWZ0ZXIgdGhlIGRlc2lnbmF0ZWQg bGVhZGVyIGlzIGRvd24/DQoNCg0KPlRoZXJlIGlzIG5vIG5lZWQgZm9yIGEgYmFja3VwIGxlYWRl ci4gIElmIHRoZSBhcmVhIGxlYWRlciBpcyBwYXJ0aXRpb25lZCBmcm9tIHRoZSB0b3BvbG9neSwg dGhlbg0KPiBsZWFkZXIgZWxlY3Rpb24gaXMgcmVwZWF0ZWQsIHJlc3VsdGluZyBpbiBhIG5ldyBs ZWFkZXIuICBBZ2Fpbiwgbm8gY29uZmlndXJhdGlvbiBpcyByZXF1aXJlZC4NCg0KVGhlIGFib3Zl IGRvZXMgbm90IHRhbGsgYWJvdXQgdG9wb2xvZ3kgc3BsaXQsIGJ1dCBhYm91dCB0aGUgbGVhZGVy IGRvd24uIEFmdGVyIGEgdXNlci9vcGVyYXRvciBoYXMgY29uZmlndXJlZCBzb21lIHRoaW5ncyBv biB0aGUgbGVhZGVyLCBhbmQgdGhlIGxlYWRlciBoYXMgZ290IHRoZW0gYW5kIGRpc3RyaWJ1dGVk IHRoZW0gaW4gc29tZSBmb3JtLCBhbmQgdGhlbiBzb21lIHRpbWUgbGF0ZXIsIHRoZSBsZWFkZXIg Z29lcyBkb3duLCBhIG5ldyBsZWFkZXIgaXMgc2VsZWN0ZWQuIEluIHRoaXMgY2FzZSwgd2lsbCB0 aGUgbmV3IGxlYWRlciB0YWtlIGFuZCBtYWludGFpbiB0aGUgY29uZmlndXJhdGlvbnMgb3IgdGhl IGluZm9ybWF0aW9uIGRlcml2ZWQgZnJvbSB0aGUgY29uZmlndXJhdGlvbnMgZG9uZSBvbiB0aGUg b2xkIGxlYWRlci4NCg0KQmVzdCBSZWdhcmRzLA0KSHVhaW1vDQoNCj5Ub255DQoNCg== --_000_5316A0AB3C851246A7CA5758973207D463B66FE9sjceml521mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYubXNvbm9ybWFs MA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3AtYWx0OmF1dG87 DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJn aW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIixzZXJpZjt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUt bmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2Vy aWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYg Z3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0i MTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEi IC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xv cjpibGFjayI+SGkgVG9ueSw8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7IEZyb206PC9zcGFuPjwvYj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiBUb255IExpIFttYWlsdG86dG9ueTFhdGhvbWVAZ21haWwuY29tXQ0KPGJyPg0K Jmd0OyA8Yj5TZW50OjwvYj4gV2VkbmVzZGF5LCBGZWJydWFyeSAyNywgMjAxOSAyOjA3IEFNPGJy Pg0KJmd0OyA8Yj5Ubzo8L2I+IEh1YWltbyBDaGVuICZsdDtodWFpbW8uY2hlbkBodWF3ZWkuY29t Jmd0Ozxicj4NCiZndDsgPGI+Q2M6PC9iPiBQZXRlciBQc2VuYWsgJmx0O3Bwc2VuYWtAY2lzY28u Y29tJmd0OzsgQ2hyaXN0aWFuIEhvcHBzICZsdDtjaG9wcHNAY2hvcHBzLm9yZyZndDs7IGxzckBp ZXRmLm9yZzsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+Jmd0OyBsc3ItIGNoYWlyc0BpZXRmLm9yZzsgbHNyLWFkc0BpZXRmLm9y Zzxicj4NCiZndDsgPGI+U3ViamVjdDo8L2I+IFJlOiBbTHNyXSBXRyBBZG9wdGlvbiBDYWxsIGZv ciBkcmFmdC1saS1sc3ItZHluYW1pYy1mbG9vZGluZy0wMiAmIzQzOyBJUFIgcG9sbC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZn dDs8L3NwYW4+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiZndDs8L3NwYW4+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsNCjwvc3Bhbj5IaSBIdWFpbW8sPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs8L3Nw YW4+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OjUuMHB0O21hcmdpbi1yaWdodDouNWluO21hcmdpbi1ib3R0b206MGlu O21hcmdpbi1sZWZ0Oi41aW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Jmd0OyAmZ3Q7ICZndDsgMSkmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgVGhlcmUgaXMgbm8gY29uY3JldGUgcHJvY2VkdXJlL21l dGhvZCBmb3IgZmF1bHQgdG9sZXJhbmNlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0Oi41 aW47bWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWxlZnQ6LjVpbjttYXJnaW4tYm90dG9tOi4wMDAx cHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7ICZndDsgJmd0OyB0byBtdWx0aXBsZSBmYWlsdXJl cy4gV2hlbiBtdWx0aXBsZSBmYWlsdXJlcyBoYXBwZW4gYW5kIHNwbGl0IHRoZTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6MGluO21hcmdpbi1yaWdodDouNWluO21hcmdpbi1ib3R0b206MGluO21hcmdpbi1sZWZ0Oi41 aW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyAmZ3Q7Jmd0 OyZuYnNwOyBmbG9vZGluZyB0b3BvbG9neSwgdGhlIGNvbnZlcmdlbmNlIHRpbWUgd2lsbCBiZSBp bmNyZWFzZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6LjVpbjttYXJnaW4tYm90dG9t OjBpbjttYXJnaW4tbGVmdDouNWluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiZndDsgJmd0OyAmZ3Q7IHNpZ25pZmljYW50bHkgd2l0aG91dCBmYXVsdCB0b2xlcmFu Y2UuIFRoZSBsb25nZXIgdGhlIGNvbnZlcmdlbmNlPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJp Z2h0Oi41aW47bWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWxlZnQ6LjVpbjttYXJnaW4tYm90dG9t Oi4wMDAxcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7ICZndDsmZ3Q7Jm5ic3A7IHRpbWUsIHRo ZSBtb3JlIHRoZSB0cmFmZmljIGxvc2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0Oi41 aW47bWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWxlZnQ6LjVpbjttYXJnaW4tYm90dG9tOi4wMDAx cHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jm5ic3A7Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21h cmdpbi1yaWdodDouNWluO21hcmdpbi1ib3R0b206MGluO21hcmdpbi1sZWZ0Oi41aW47bWFyZ2lu LWJvdHRvbTouMDAwMXB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyAmZ3Q7IHRoZXJlIGlzIGEg c29sdXRpb24gZm9yIG11bHRpcGxlIGZhaWx1cmVzIC0gc2VlIHNlY3Rpb24gNi43LjExLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDouNWluO21hcmdpbi1ib3R0b206MGluO21hcmdpbi1s ZWZ0Oi41aW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyAm Z3Q7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0Oi41aW47bWFyZ2luLWJvdHRv bTowaW47bWFyZ2luLWxlZnQ6LjVpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6LjVpbjttYXJnaW4t Ym90dG9tOjUuMHB0O21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7ICZn dDsgU2VjdGlvbiA2LjcuMTE8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJz cDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPmp1c3QgYnJpZWZseSBtZW50aW9ucyB0aGF0IHRoZSBlZGdlcyBvZiBz cGxpdCBwYXJ0cyB3aWxsIGRldGVybWluZQ0KPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0Oi41aW47bWFyZ2luLWJvdHRvbTo1LjBwdDttYXJnaW4t bGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyAmZ3Q7IDwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5hbmQgcmVwYWly IHRoZSBzcGxpdCBhZnRlciB0aGUgc3BsaXQgb2YgdGhlIGZsb29kaW5nIHRvcG9sb2d5IGhhcHBl bnMuIEhvd2V2ZXIsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0Oi41aW47bWFyZ2luLWJv dHRvbTo1LjBwdDttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyAmZ3Q7 IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj50aGVyZSBpcyBub3QgYW55IGRldGFpbHMgb3IgZGVzY3JpcHRpb24gb24gaG93IHRv IGRldGVybWluZSBvciByZXBhaXIgdGhlIHNwbGl0Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2lu LXJpZ2h0Oi41aW47bWFyZ2luLWJvdHRvbTo1LjBwdDttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDss c2Fucy1zZXJpZiI+Jmd0OyAmZ3Q7IDwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5UaGlzIGlzIG5vdCB1c2VmdWwgZm9yIGltcGxl bWVudGVycy48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4mZ3Q7DQo8L3NwYW4+SeKAmW0gc29ycnkgdGhhdCB5b3UgZG9u4oCZdCBmaW5k IGl0IHVzZWZ1bC4gRGV0ZXJtaW5pbmcgdGhlIHNwbGl0IGlzIHRyaXZpYWw6IHdoZW4geW91IHJl Y2VpdmUgYW4gSUlILA0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiZndDsNCjwvc3Bhbj5pdCBoYXMgYSBzeXN0ZW0gSUQgb2YgdGhlIGFub3Ro ZXIgc3lzdGVtIGluIGl0LiBJZiB0aGF0IG90aGVyIHN5c3RlbSBpcyBub3QgY3VycmVudGx5IHBh cnQgb2YgdGhlDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+Jmd0Ow0KPC9zcGFuPmZsb29kaW5nIHRvcG9sb2d5LCB0aGVuIGl0IGlzIHF1aXRl IGNsZWFyIHRoYXQgaXQgaXMgZGlzY29ubmVjdGVkIGZyb20gdGhlIGZsb29kaW5nIHRvcG9sb2d5 LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4m Z3Q7DQo8L3NwYW4+UmVwYWlyaW5nIHRoZSBzcGxpdCBpcyBkb25lIGJ5IGVuYWJsaW5nIHRlbXBv cmFyeSBmbG9vZGluZyBvbiB0aGUgbmV3IGxpbmsuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkZv ciBhbiBhZGphY2VuY3kgYmV0d2VlbiB0d28gbm9kZXMgaXMgdXAsIHRoZSBIZWxsbyBwYWNrZXRz IGV4Y2hhbmdlZCBiZXR3ZWVuIHRoZW0gd2lsbCBub3QgY2hhbmdlIG5vZGUvc3lzdGVtIElEcyBp biB0aGVtLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ib3cgZG8geW91 IGRldGVybWluZSB0aGF0IG90aGVyIHN5c3RlbSBpcyBub3QgY3VycmVudGx5IHBhcnQgb2YgdGhl IGZsb29kaW5nIHRvcG9sb2d5PzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0Ow0KPC9z cGFuPlRoZXJlIGlzIGFuIGlzc3VlIGhlcmUgdGhhdCB3ZSBoYXZlIG5vdCB5ZXQgcmVzb2x2ZWQs IHdoaWNoIGlzIHRoZSByYXRlIHRoYXQgbmV3IGxpbmtzIHNob3VsZCBiZQ0KPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsNCjwvc3Bhbj50 ZW1wb3JhcmlseSBhZGRlZCB0byB0aGUgZmxvb2RpbmcgdG9wb2xvZ3kuICZuYnNwO1NvbWUgYmVs aWV2ZSB0aGF0IGFkZGluZyBhbnkgbmV3IGxpbmsgaXMgdGhlDQo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0Ow0KPC9zcGFuPmNvcnJlY3Qg dGhpbmcgdG8gZG8gYXMgaXQgbWluaW1pemVzIHRoZSByZWNvdmVyeSB0aW1lLiBPdGhlcnMgZmVl bCB0aGF0IGVuYWJsaW5nIHRvbyBtYW55IGxpbmtzDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0Ow0KPC9zcGFuPmNvdWxkIGNhdXNlIGEg Zmxvb2RpbmcgY29sbGFwc2UsIHNvIGxpbmsgYWRkaXRpb24gc2hvdWxkIGJlIGhpZ2hseSBjb25z dHJhaW5lZC4gV2UgYXJlIHN0aWxsDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0Ow0KPC9zcGFuPmRpc2N1c3NpbmcgdGhpcyBhbmQgaW52 aXRlIHRoZSBXR+KAmXMgb3BpbmlvbnMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBpc3N1 ZSBpcyByZXNvbHZlZCBieSB0aGUgc29sdXRpb25zIGluIGRyYWZ0LWNjLWxzci1mbG9vZGluZy1y ZWR1Y3Rpb24uDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uZSBzb2x1 dGlvbiBpcyBiZWxvdywgd2hlcmUgdGhlIGdpdmVuIGRpc3RhbmNlIGNhbiBiZSBhZGp1c3RlZC9j b25maWd1cmVkLg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB3ZSB3 YW50IGV2ZXJ5IG5vZGUgdG8gZmxvb2Qgb24gYWxsIGl0cyBsaW5rcywgd2UgbGV0IHRoZSBnaXZl bg0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5kaXN0YW5jZSB0byBhIGJp ZyBudW1iZXIuIElmIHdlIHdhbnQgdGhlIG5vZGVzIHdpdGhpbiAyIGhvcHMgdG8gYSBmYWlsdXJl DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRvIGZsb29kIG9uIGFsbCB0 aGVpciBsaW5rcywgd2Ugc2V0IHRoZSBnaXZlbiBkaXN0YW5jZSB0byAyLjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7IOKAnEluIG9uZSB3YXksIHdoZW4g dHdvIG9yIG1vcmUgZmFpbHVyZXMgb24gdGhlIGN1cnJlbnQgZmxvb2Rpbmc8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyB0b3BvbG9neSBvY2N1ciBhbG1v c3QgaW4gdGhlIHNhbWUgdGltZSwgZWFjaCBvZiB0aGUgbm9kZXMgd2l0aGluIGE8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyBnaXZlbiBkaXN0YW5jZSAo c3VjaCBhcyAzIGhvcHMpIHRvIGEgZmFpbHVyZSBwb2ludCwgZmxvb2RzIHRoZSBsaW5rPG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgc3RhdGUgKExTKSB0 aGF0IGl0IHJlY2VpdmVzIHRvIGFsbCB0aGUgbGlua3MgKGV4Y2VwdCBmb3IgdGhlIG9uZSBmcm9t PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsgd2hpY2gg dGhlIExTIGlzIHJlY2VpdmVkKSB1bnRpbCBhIG5ldyBmbG9vZGluZyB0b3BvbG9neSBpcyBidWls dC7igJ08bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW5vdGhlciBzb2x1dGlvbiBpcyBqdXN0IGFk ZGluZyBtaW5pbXVtIGxpbmtzIHRlbXBvcmFyaWx5IG9uIHRoZSBmbG9vZGluZzxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dG9wb2xvZ3kgdG8gcmVwYWlyIHRoZSBzcGxpdCBm bG9vZGluZyB0b3BvbG9neSB1bnRpbCBhIG5ldyBmbG9vZGluZyB0b3BvbG9neTxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+aXMgYnVpbHQuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6NS4wcHQ7bWFyZ2luLXJpZ2h0Oi41aW47bWFy Z2luLWJvdHRvbTowaW47bWFyZ2luLWxlZnQ6LjVpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPg0K PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj4mZ3Q7ICZndDsgJmd0OyAyKSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGUgZXh0ZW5zaW9ucyB0byBI ZWxsbyBwcm90b2NvbHMgZm9yIGVuYWJsaW5nIOKAnHRlbXBvcmFyeTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGlu O21hcmdpbi1yaWdodDouNWluO21hcmdpbi1ib3R0b206MGluO21hcmdpbi1sZWZ0Oi41aW47bWFy Z2luLWJvdHRvbTouMDAwMXB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyAmZ3Q7IGZsb29kaW5n 4oCdIG92ZXIgYSBuZXcgbGluayBpcyBub3QgbmVlZGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdp bi1yaWdodDouNWluO21hcmdpbi1ib3R0b206MGluO21hcmdpbi1sZWZ0Oi41aW47bWFyZ2luLWJv dHRvbTouMDAwMXB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyAmZ3Q7Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDowaW47bWFyZ2luLXJpZ2h0Oi41aW47bWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWxlZnQ6 LjVpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7ICZndDsg bm90IGlmIHlvdSBkbyBmbG9vZGluZyBvbiBldmVyeSBsaW5rIHRoYXQgY29tZXMgdXAuIElmIHlv dSB3YW50IHRvIGJlIHNtYXJ0ZXIsIHRoZW4geW91IG5lZWQgdG88bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjtt YXJnaW4tcmlnaHQ6LjVpbjttYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tbGVmdDouNWluO21hcmdp bi1ib3R0b206LjAwMDFwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgJmd0OyBzZWxlY3RpdmVs eSBlbmFibGUgZmxvb2Rpbmcgb25seSB1bmRlciBzcGVjaWZpYyBjb25kaXRpb25zIGFuZCB0aGF0 IG11c3QgYmUgZG9uZSBmcm9tIGJvdGggc2lkZXMgb2Y8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4t cmlnaHQ6LjVpbjttYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tbGVmdDouNWluO21hcmdpbi1ib3R0 b206LjAwMDFwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgJmd0OyB0aGUgbmV3IGxpbmsuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0Oi41aW47bWFyZ2luLWJvdHRvbTowaW47bWFyZ2lu LWxlZnQ6LjVpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mbmJz cDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6LjVpbjttYXJnaW4tYm90dG9tOjUuMHB0 O21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7ICZndDsgVGhlcmUgYXJl IG9ubHkgYSBsaW1pdGVkIG51bWJlciBvZiBjb25kaXRpb25zIChvciBjYXNlcykuJm5ic3A7IElu IGVhY2ggY29uZGl0aW9uL2Nhc2UsIGl0IGlzDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmln aHQ6LjVpbjttYXJnaW4tYm90dG9tOjUuMHB0O21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4mZ3Q7ICZndDsgZGV0ZXJtaW5pc3RpYyB3aGV0aGVyIHdlIG5lZWQgdG8gZW5hYmxl IOKAnHRlbXBvcmFyeSBmbG9vZGluZ+KAnSBmb3IgYSBuZXcgbGluayB3aGVuIGl0DQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6LjVpbjttYXJnaW4tYm90dG9tOjUuMHB0O21hcmdpbi1s ZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7ICZndDsgaXMgdXAuJm5ic3A7IFRodXMg dGhlcmUgaXMgbm8gbmVlZCBmb3IgYW55IGV4dGVuc2lvbnMgdG8gSGVsbG8gcHJvdG9jb2xzIGZv ciBlbmFibGluZw0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0Oi41aW47bWFyZ2luLWJv dHRvbTo1LjBwdDttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyAmZ3Q7 IOKAnHRlbXBvcmFyeSBmbG9vZGluZ+KAnSBvbiBhIG5ldyBsaW5rLjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsNCjwvc3Bhbj5XZSBrbm93IG9mIG9ubHkgdHdvIGNhc2Vz OiAoMSkgdGhlIG5laWdoYm9yIGlzIG5vdCBwYXJ0IG9mIHRoZSBmbG9vZGluZyB0b3BvbG9neSBh bmQgd2UgZmVlbA0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiZndDsNCjwvc3Bhbj50aGF0IHdlIGNhbiBhZGQgbW9yZSB0ZW1wb3JhcnkgZmxv b2RpbmcuICgyKSBUaGUgbmVpZ2hib3IgaXMgbm90IHBhcnQgb2YgdGhlIGZsb29kaW5nIHRvcG9s b2d5DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Jmd0Ow0KPC9zcGFuPmFuZCB3ZSBjYW5ub3QgYWRkIG1vcmUgdGVtcG9yYXJ5IGZsb29kaW5n LjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsNCjwvc3Bhbj5P YnZpb3VzbHksIGluIHRoZSBjYXNlIHdoZXJlIHdlIHdhbnQgdG8gYWRkIHRlbXBvcmFyeSBmbG9v ZGluZywgdGhhdCBUTFYgaXMgbmVlZGVkIGluIHRoZSBJSUguPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDo1LjBwdDttYXJnaW4tcmln aHQ6LjVpbjttYXJnaW4tYm90dG9tOjUuMHB0O21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4mZ3Q7ICZndDsgRm9yIGV4YW1wbGUsIHN1cHBvc2UgdGhhdCB3ZSBoYXZlIGEgY3Vy cmVudCBmbG9vZGluZyB0b3BvbG9neSBjb250YWluaW5nIGFsbCBsaXZlDQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OjUuMHB0O21hcmdpbi1yaWdodDouNWluO21hcmdpbi1ib3R0b206NS4wcHQ7bWFyZ2luLWxlZnQ6 LjVpbiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgJmd0OyBub2RlcyBpbiBhbiBhcmVhLCB3aGVu IGEgbmV3IGxpbmsgY29tZXMgdXAsIHdlIG1heSBqdXN0IGhhdmUgdHdvIGNvbmRpdGlvbnMvY2Fz ZXMuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OjUuMHB0O21hcmdpbi1yaWdodDouNWluO21hcmdpbi1ib3R0b206 NS4wcHQ7bWFyZ2luLWxlZnQ6LjVpbiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsgJmd0OyBPbmUg Y29uZGl0aW9uL2Nhc2UgaXMgdGhhdCB0aGUgbmV3IGxpbmsgaXMgYXR0YWNoZWQgdG8gYSBuZXcg bm9kZSBub3Qgb24gdGhlIGN1cnJlbnQNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6NS4wcHQ7bWFyZ2luLXJpZ2h0 Oi41aW47bWFyZ2luLWJvdHRvbTo1LjBwdDttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+Jmd0OyAmZ3Q7IGZsb29kaW5nIHRvcG9sb2d5LiBJbiB0aGlzIGNvbmRpdGlvbi9jYXNl LCB0aGUgbmV3IGxpbmsgbmVlZHMgdG8gYmUgZW5hYmxlZCBmb3INCjxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6NS4w cHQ7bWFyZ2luLXJpZ2h0Oi41aW47bWFyZ2luLWJvdHRvbTo1LjBwdDttYXJnaW4tbGVmdDouNWlu Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyAmZ3Q7IOKAnHRlbXBvcmFyeSBmbG9vZGluZ+KAnSBh ZnRlciBpdCBpcyB1cC4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IEFncmVlZCwgd2hpY2ggaXMg d2h5IHdlIG5lZWQgdGhlIFRMVi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIGxpbmsgY2Fu IGJlIGVuYWJsZWQgZm9yIOKAnHRlbXBvcmFyeSBmbG9vZGluZ+KAnSBieSB0aGUgbm9kZSB3aXRo b3V0IHVzaW5nIGFueSBUTFYgb3IgSGVsbG8gd2l0aCB0aGUgVExWLjxicj4NCjxicj4NCjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDo1LjBwdDttYXJnaW4tcmlnaHQ6LjVpbjttYXJnaW4tYm90dG9tOjUuMHB0O21hcmdpbi1sZWZ0 Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7ICZndDtUaGUgb3RoZXIgY29uZGl0aW9uL2Nh c2UgaXMgdGhhdCB0aGUgbmV3IGxpbmsgaXMgYXR0YWNoZWQgdG8gbm9kZXMgb24gdGhlIGN1cnJl bnQNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6NS4wcHQ7bWFyZ2luLXJpZ2h0Oi41aW47bWFyZ2luLWJvdHRvbTo1 LjBwdDttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyAmZ3Q7Zmxvb2Rp bmcgdG9wb2xvZ3kuIEluIHRoaXMgY29uZGl0aW9uL2Nhc2UsIHRoZXJlIGlzIG5vIG5lZWQgdG8g ZW5hYmxlIOKAnHRlbXBvcmFyeTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6NS4wcHQ7bWFyZ2luLXJpZ2h0Oi41aW47 bWFyZ2luLWJvdHRvbTo1LjBwdDttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ Jmd0OyAmZ3Q7IGZsb29kaW5n4oCdIG9uIHRoZSBsaW5rLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7 QWdyZWVkLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Tm90ZSB0aGF0IHRoZXJlIGFyZSBz b21lIGFkZGl0aW9uYWwgY29ybmVyIGNhc2VzLiAmbmJzcDtTaW5jZSB0aGUgdHdvIG5laWdoYm9y cyBtYXkgbm90IGhhdmUgdGhlDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZndDtleGFjdCBzYW1lIGluZm9ybWF0aW9uLCBvbmUgbWF5IGNvbnNpZGVyIHRoZSBvdGhlciB0 byBiZSBvbiB0aGUgZmxvb2RpbmcgdG9wb2xvZ3kgd2hlbiBpbiBmYWN0DQo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0Ow0KPC9zcGFuPml0 IGlzIG5vdC4gJm5ic3A7VGhpcyBtaWdodCBoYXBwZW4gaW4gdGhlIGNhc2Ugb2YgYSBub2RlIHJl Ym9vdC4gVGhlIElJSCBUTFYgZ2l2ZXMgdXMgYW4gZXhwbGljaXQgd2F5DQo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0Ow0KPC9zcGFuPm9m IHNpZ25hbGluZywgcmF0aGVyIHRoYW4gc2ltcGx5IGd1ZXNzaW5nIGFuZCBzb21ldGltZXMgZ2V0 dGluZyBpdCB3cm9uZy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhlIFRMViBpbiBIZWxsbyBw YWNrZXQganVzdCByZXF1ZXN0cyBmb3IgYWRkaW5nIOKAnHRlbXBvcmFyeSBmbG9vZGluZ+KAnSBv biB0aGUgbGluay4gVGhlIG90aGVyIGluZm9ybWF0aW9uIGlzIGFjY2Vzc2VkIGJ5IHRoZSBub2Rl IGxvY2FsbHkuIFRoZSBUTFYgaW4gSGVsbG8gcGFja2V0IGRvZXMgbm90IGhlbHAgZm9yIGNvcm5l ciBjYXNlLiBJbiB0aGUgY2FzZSB3aGVyZSBhIG5vZGUgaXMgcmVib290ZWQsIGEgbmV3DQogbGlu ayBhdHRhY2hlZCB0byBhIG5ldyBub2RlIG1heSBhcHBseS48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNv LW1hcmdpbi10b3AtYWx0OjUuMHB0O21hcmdpbi1yaWdodDouNWluO21hcmdpbi1ib3R0b206MGlu O21hcmdpbi1sZWZ0Oi41aW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Jmd0OyZndDsgJmd0OyAzKSZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBUaGUgZXh0ZW5zaW9ucyB0byBIZWxsbyBwcm90b2NvbHMg Zm9yIHJlcXVlc3Rpbmcvc2lnbmFsaW5nPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0Oi41 aW47bWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWxlZnQ6LjVpbjttYXJnaW4tYm90dG9tOi4wMDAx cHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyAmZ3Q7IOKAnHRlbXBvcmFyeSBmbG9vZGlu Z+KAnSBmb3IgYSBjb25uZWN0aW9uIGRvZXMgbm90IHdvcmsuPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFy Z2luLXJpZ2h0Oi41aW47bWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWxlZnQ6LjVpbjttYXJnaW4t Ym90dG9tOi4wMDAxcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyZndDsmbmJzcDs8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6LjVpbjttYXJnaW4tYm90dG9tOjBpbjttYXJnaW4t bGVmdDouNWluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsm Z3Q7Jmd0OyBzb3JyeSwgYnV0IGlmIHlvdSBzZWUgYSBwcm9ibGVtLCBwbGVhc2UgcHJvdmlkZSBk ZXRhaWxzLCBzYXlpbmcgYWJvdmUgaXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6LjVp bjttYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tbGVmdDouNWluO21hcmdpbi1ib3R0b206LjAwMDFw dCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7Jmd0OyBzaW1wbHkgdW5wcm9kdWN0aXZlLjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDouNWluO21hcmdpbi1ib3R0b206MGluO21hcmdp bi1sZWZ0Oi41aW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jm5i c3A7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0Oi41aW47bWFyZ2luLWJvdHRvbTowaW47 bWFyZ2luLWxlZnQ6LjVpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPg0KPHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij4mZ3Q7Jmd0Ozwvc3Bhbj4g4oCcVGhlIG5vZGVzIOKApiB3aWxsIHRyeSB0byByZXBhaXIgdGhl IGZsb29kaW5nIHRvcG9sb2d5IGxvY2FsbHkgYnkgZW5hYmxpbmcNCjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2lu LXJpZ2h0Oi41aW47bWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWxlZnQ6LjVpbjttYXJnaW4tYm90 dG9tOi4wMDAxcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0Ozwvc3Bhbj50ZW1wb3Jhcnkg Zmxvb2RpbmcgdG93YXJkcyB0aGUgbm9kZXMgdGhhdCB0aGV5IGNvbnNpZGVyIGRpc2Nvbm5lY3Rl ZCBmcm9tIHRoZQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6LjVpbjttYXJnaW4tYm90dG9tOjBp bjttYXJnaW4tbGVmdDouNWluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiZndDsmZ3Q7PC9zcGFuPmZsb29kaW5nIHRvcG9sb2d5IC4uLuKAnTxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0Oi41aW47bWFyZ2luLWJvdHRvbTowaW47 bWFyZ2luLWxlZnQ6LjVpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPg0KJm5ic3A7PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6LjVpbjttYXJnaW4tYm90dG9t OjUuMHB0O21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0Ozwvc3Bh bj5UaGUgYWJvdmUgcXVvdGVkIHRleHQgaXMgZnJvbSBkcmFmdC1saS1sc3ItZHluYW1pYy1mbG9v ZGluZy0wMiwgd2hlcmUNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0Oi41aW47bWFyZ2luLWJvdHRv bTo1LjBwdDttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZndDs8L3Nw YW4+IOKAnGVuYWJsaW5nIHRlbXBvcmFyeSBmbG9vZGluZyB0b3dhcmRzIHRoZSBub2Rlc+KAnSBp cyB0byByZXF1ZXN0L3NpZ25hbA0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6LjVpbjttYXJnaW4t Ym90dG9tOjUuMHB0O21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0 Ozwvc3Bhbj4g4oCcdGVtcG9yYXJ5IGZsb29kaW5n4oCdIGZvciBhIGNvbm5lY3Rpb24gdG8gY29u bmVjdCBwYXJ0aXRpb25lZC9kaXNjb25uZWN0ZWQNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0Oi41 aW47bWFyZ2luLWJvdHRvbTo1LjBwdDttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp ZiI+Jmd0OyZndDs8L3NwYW4+Zmxvb2RpbmcgdG9wb2xvZ3kgaW50byBvbmUgdGhyb3VnaCB0aGUg ZXh0ZW5zaW9ucyB0byBIZWxsbyBwcm90b2NvbHMgZGVzY3JpYmVkDQo8bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdp bi1yaWdodDouNWluO21hcmdpbi1ib3R0b206NS4wcHQ7bWFyZ2luLWxlZnQ6LjVpbiI+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiZndDsmZ3Q7PC9zcGFuPmluPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRl ZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ZHJhZnQtbGktbHNyLWR5bmFt aWMtZmxvb2RpbmctMDI8L3NwYW4+LiBSaWdodD88c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6NS4wcHQ7bWFyZ2luLXJpZ2h0Oi41aW47bWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWxlZnQ6 LjVpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPg0KJm5ic3A7PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6LjVpbjttYXJnaW4tYm90dG9tOjUuMHB0O21hcmdp bi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0Ozwvc3Bhbj5UaGUgZXh0ZW5z aW9ucyB0byBIZWxsbyBwcm90b2NvbHMgZm9yIHJlcXVlc3Rpbmcvc2lnbmFsaW5nIOKAnHRlbXBv cmFyeQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h cmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6LjVpbjttYXJnaW4tYm90dG9tOjUuMHB0O21h cmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0Ozwvc3Bhbj5mbG9vZGlu Z+KAnSBmb3IgYSBjb25uZWN0aW9uIHRvIGNvbm5lY3QgcGFydGl0aW9uZWQvZGlzY29ubmVjdGVk IGZsb29kaW5nDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDouNWluO21hcmdpbi1ib3R0b206NS4w cHQ7bWFyZ2luLWxlZnQ6LjVpbiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7PC9zcGFuPnRv cG9sb2d5IGludG8gb25lIGRvZXMgbm90IHdvcmsgc2luY2UgdGhlIGNvbm5lY3Rpb24gbWF5IGhh dmUgdHdvIG9yIG1vcmUNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5 bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0Oi41aW47bWFyZ2luLWJvdHRv bTo1LjBwdDttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZndDs8L3Nw YW4+aG9wcyBhbmQgYSBIZWxsbyBwYWNrZXQgbWF5IGdldCBsb3N0LjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+ PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0Ozwvc3Bhbj5BbGwgYWRqYWNl bmNpZXMgYXJlIGEgc2luZ2xlIGhvcCBpbiBib3RoIElTLUlTIGFuZCBPU1BGLiAmbmJzcDtZZXMs IEhlbGxvIHBhY2tldHMgbWF5IGJlIGxvc3QuDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0Ozwvc3Bhbj5Gb3J0dW5hdGVseSwgdGhleSBh cmUgcGVyaW9kaWNhbGx5IHRyYW5zbWl0dGVkLCB0aHVzIHRoZSBuZXh0IHRyYW5zbWlzc2lvbiB3 aWxsIGFsc28gY29udGFpbiB0aGU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+Jmd0Ozwvc3Bhbj4gVExWLiAmbmJzcDtJZiBJSUjigJlzIGFyZSBn ZXR0aW5nIGxvc3QgYXQgYSBzaWduaWZpY2FudCByYXRlLCB0aGVuIHRoZSBhZGphY2VuY3kgd2ls bCBub3QgKGFuZCBzaG91bGQgbm90KQ0KPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxp YnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs8L3NwYW4+Y29tZSB1cC4gJm5ic3A7VGh1cywgdGhl IHJlcXVlc3QgZm9yIHRlbXBvcmFyeSBmbG9vZGluZyB3aWxsIHByb3BhZ2F0ZSB0byB0aGUgbmVp Z2hib3IgaW4gYWxsIGNhc2VzDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZiI+Jmd0Ozwvc3Bhbj50aGF0IG1hdHRlci48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SXQgdGFrZXMgdG9vIGxvbmcgd2hlbiBIZWxsbyBwYWNrZXQgaXMgbG9zdC4gUmVw YWlyaW5nIHNwbGl0IGZsb29kaW5nIHRvcG9sb2d5IG5lZWRzIHRvIGJlIGZhc3QuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6NS4wcHQ7bWFyZ2luLXJp Z2h0Oi41aW47bWFyZ2luLWJvdHRvbTo1LjBwdDttYXJnaW4tbGVmdDouNWluIj4NCjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+Jmd0OyZndDtJdCBpcyBub3QgY29udmVuaWVudCBmb3IgYSB1c2VyL29wZXJhdG9y IHRvIGNvbmZpZ3VyZSBvbiBhbiBhcmVhIGxlYWRlciBzaW5jZSB0aGUNCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 NS4wcHQ7bWFyZ2luLXJpZ2h0Oi41aW47bWFyZ2luLWJvdHRvbTo1LjBwdDttYXJnaW4tbGVmdDou NWluIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZndDtsZWFkZXIgaXMgZHluYW1pY2FsbHkgc2Vs ZWN0ZWQuIEhvdyBkbyB5b3UgYWRkcmVzcyB0aGlzPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7Tm8g Y29uZmlndXJhdGlvbiBpcyByZXF1aXJlZC4gJm5ic3A7VGhlIGVsZWN0aW9uIGFsZ29yaXRobSBz ZWxlY3RzIHRoZSBhcmVhIGxlYWRlci4gJm5ic3A7VGhlIHJ1bGVzIGFyZSBpbg0KPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7dGhlIGRyYWZ0LiAmbmJzcDtBbiBpbXBs ZW1lbnRhdGlvbiBtYXkgaGF2ZSBhIGRlZmF1bHQgcHJpb3JpdHkgYW5kIGEgZGVmYXVsdCBhbGdv cml0aG0gc2V0dGluZywgc28gbm8NCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jmd0O2NvbmZpZ3VyYXRpb24gaXMgbWFuZGF0b3J5LiAmbmJzcDtJZiB0aGUgb3BlcmF0b3Ig ZGVzaXJlcyBhIHNwZWNpZmljIG5vZGUgdG8gYmVjb21lIGFyZWEgbGVhZGVyLCB0aGVuDQo8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDtjb25maWd1cmF0aW9uIG1heSBi ZSByZXF1aXJlZCB0byBhZGp1c3QgdGhlIHByaW9yaXR5LiAmbmJzcDtGV0lXLCB3ZSBoYXZlIHRo aXMgYWxyZWFkeSB3b3JraW5nIGluDQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZndDtvdXIgaW1wbGVtZW50YXRpb24uICZuYnNwO0l0IEp1c3QgV29ya3MuPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkl0IGRvZXMgbm90IG1lYW4gdGhhdCBhIHVzZXIvb3BlcmF0b3IgY29u ZmlndXJlcy9zZWxlY3QgYW4gYXJlYSBsZWFkZXIuIEl0IG1lYW5zIHRoYXQgYSB1c2VyL29wZXJh dG9yIGNvbmZpZ3VyZXMgb3RoZXIgdGhpbmdzIHN1Y2ggYXMgaW5kaWNhdGluZyBhbiBhbGdvcml0 aG0gb3Igc2VsZWN0aW5nIHRoZSBjZW50cmFsaXplZCBtb2RlIG9uIHRoZSBhcmVhIGxlYWRlci4m bmJzcDsNCjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0 OjUuMHB0O21hcmdpbi1yaWdodDouNWluO21hcmdpbi1ib3R0b206NS4wcHQ7bWFyZ2luLWxlZnQ6 LjVpbiI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7QWZ0ZXIgdGhlIHVzZXIvb3BlcmF0b3Ig ZG9lcyBzb21lIGNvbmZpZ3VyYXRpb25zIG9uIHRoZSAoZGVzaWduYXRlZCkgbGVhZGVyLCB3aWxs IHRoZQ0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDo1LjBwdDttYXJnaW4tcmlnaHQ6LjVpbjttYXJnaW4tYm90dG9t OjUuMHB0O21hcmdpbi1sZWZ0Oi41aW4iPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0O2JhY2t1 cCBsZWFkZXIgdGFrZXMgb3ZlciB0aGUgY29uZmlndXJhdGlvbnMgYWZ0ZXIgdGhlIGRlc2lnbmF0 ZWQgbGVhZGVyIGlzIGRvd24/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDtUaGVyZSBpcyBubyBuZWVk IGZvciBhIGJhY2t1cCBsZWFkZXIuICZuYnNwO0lmIHRoZSBhcmVhIGxlYWRlciBpcyBwYXJ0aXRp b25lZCBmcm9tIHRoZSB0b3BvbG9neSwgdGhlbjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jmd0OyBsZWFkZXIgZWxlY3Rpb24gaXMgcmVwZWF0ZWQsIHJlc3VsdGluZyBpbiBh IG5ldyBsZWFkZXIuICZuYnNwO0FnYWluLCBubyBjb25maWd1cmF0aW9uIGlzIHJlcXVpcmVkLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgYWJvdmUgZG9lcyBub3QgdGFsayBhYm91dCB0b3Bv bG9neSBzcGxpdCwgYnV0IGFib3V0IHRoZSBsZWFkZXIgZG93bi4gQWZ0ZXIgYSB1c2VyL29wZXJh dG9yIGhhcyBjb25maWd1cmVkIHNvbWUgdGhpbmdzIG9uIHRoZSBsZWFkZXIsIGFuZCB0aGUgbGVh ZGVyIGhhcyBnb3QgdGhlbSBhbmQgZGlzdHJpYnV0ZWQgdGhlbSBpbiBzb21lIGZvcm0sIGFuZCB0 aGVuIHNvbWUgdGltZSBsYXRlciwgdGhlIGxlYWRlcg0KIGdvZXMgZG93biwgYSBuZXcgbGVhZGVy IGlzIHNlbGVjdGVkLiBJbiB0aGlzIGNhc2UsIHdpbGwgdGhlIG5ldyBsZWFkZXIgdGFrZSBhbmQg bWFpbnRhaW4gdGhlIGNvbmZpZ3VyYXRpb25zIG9yIHRoZSBpbmZvcm1hdGlvbiBkZXJpdmVkIGZy b20gdGhlIGNvbmZpZ3VyYXRpb25zIGRvbmUgb24gdGhlIG9sZCBsZWFkZXIuPG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkJlc3QgUmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPkh1YWltbzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7VG9ueTxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_5316A0AB3C851246A7CA5758973207D463B66FE9sjceml521mbxchi_-- From nobody Tue Mar 5 22:01:48 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6BA58130EC2; Tue, 5 Mar 2019 22:01:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=eci365.onmicrosoft.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 q_w38ownDA67; Tue, 5 Mar 2019 22:01:44 -0800 (PST) Received: from mail1.bemta26.messagelabs.com (mail1.bemta26.messagelabs.com [85.158.142.5]) (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 738BC12D4EF; Tue, 5 Mar 2019 22:01:43 -0800 (PST) Received: from [85.158.142.101] (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256 bits)) by server-5.bemta.az-a.eu-central-1.aws.symcld.net id 49/D1-12121-4426F7C5; Wed, 06 Mar 2019 06:01:40 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA1WTa0hTYRjH9+6cs53MU2/T8kk0dEWUa8NLwQw Kg6K+BIHdKC3P3NENtqNtk6w+aGUNF11MV82MyixSi1IiRIVKiiyjTLPLSnLMbqssEqo5u5yz o12+vPze5/9/3vf/HN5DE6qAIpbmih2cjWctakUEOT8xI1u71FCSlVz2DvTPT9SS+sujTUp95 +B5St/S5lTob3eHUAa1oirURK2oqwvKV8k3UGbeUFCcQ5lCXUmFQ4biYEsfUYo8a1wogiZxLQ GlwYBS3KhwhRyODXwd27xA0HnkGHKhCbQCL4Lmxn6FC9F0NE6FM280oofAHxBce1ijFD1RQv3 r2fKwPxqnwdB9r1LiXLhx0U2KTOJZ8H3kSZgZnA0jzgFCusxLwqfH3YQoTMCb4GGlWy4ywtPg 290LYSZwDHgHT4YZMIa69geExFPhnf8nJfkN8PLVaSTVE2H0XP0Yx0PPyX1jvBKaqnqV4jCAZ 8KVt9liBsB+BAd+dCokTxLs639MSUKIgVdXO0hJsECX34mk5ji4uCtd8gQp8JUPhydWCRN31g yP+WdAw34fKZm6CWh+2h5uJjAPZR1wCM2t/me26r9KdfgbTYE7nkFSssyDU21fFBJr4Nzp98Q 437vul/9bP4WUDSjdYDPnmxxW1mzRpiQna1NS0rRp2tT56Tp2u5bVcUXaXI532FhB1bFb7Tr7 NmuuxajjOUczEt6acQsRbEF+Z34Hmk7L1VOZLLokSzXJUGDcZmLtps22Igtn70BxNK0GRsMK2 hQbl88V55ktwoMdl4GOVEczmhxBZuyFrNVuzpekuyidvl7rO0HQV16+FtZWcVWRfAHPxcYwHr EBiw2mIv7PceO/QA+Kj41ikEwmU0UWcjar2fG/HkAxNFJHMbPFVJFm3vHn1oAQSC4EGu7dIQZ ysH+l2FJ0a/SzZ4HM4Ur+MZE52HTn2a/lQ2afbFm98fD63MnlCT7T0gt9uwd27z+bt7d2T0bj 2kBZ/L1fxzdWBF1UplF2wz2Nu9+36GaJyy3XHbCu/rhz1qoN/bKqowsbvY8qK2s0T/OWX8ouW Udm+ud4WhdXJMQ5R267E0MGTcQS7/bUBSNdatJuYlOSCJud/Q2k0sIh/QMAAA== X-Env-Sender: Alexander.Vainshtein@ecitele.com X-Msg-Ref: server-18.tower-226.messagelabs.com!1551852096!2600473!1 X-Originating-IP: [52.33.64.93] X-SYMC-ESS-Client-Auth: mailfrom-relay-check=pass X-StarScan-Received: X-StarScan-Version: 9.31.5; banners=ecitele.com,-,- X-VirusChecked: Checked Received: (qmail 27674 invoked from network); 6 Mar 2019 06:01:39 -0000 Received: from us-west-2b.mta.dlp.protect.symantec.com (HELO EUR04-VI1-obe.outbound.protection.outlook.com) (52.33.64.93) by server-18.tower-226.messagelabs.com with AES256-SHA256 encrypted SMTP; 6 Mar 2019 06:01:39 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ECI365.onmicrosoft.com; s=selector1-ecitele-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9uaGBuejrTpY90g21OLgqlzkVQwd//AH+CvI0mhIAe0=; b=KUHRyWA2PNLAvjKHex5FKIOMyMzpKHO4ynO1T/vCyN6z44j5TC2hLlT29yT0QjCS3DumMEckyBpBtZ1rZ0CBLa+X+hlx2Ed4CroibIizPsZeUXSfioSiC/ibGMWvqJQom2xilbQb0vEx32wPI7U2a5cEkfDoofA+cN6NLXTW1JE= Received: from AM0PR03MB3828.eurprd03.prod.outlook.com (52.135.146.159) by AM0PR03MB4129.eurprd03.prod.outlook.com (52.135.147.159) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.19; Wed, 6 Mar 2019 06:01:35 +0000 Received: from AM0PR03MB3828.eurprd03.prod.outlook.com ([fe80::cd69:f7a:ee65:6435]) by AM0PR03MB3828.eurprd03.prod.outlook.com ([fe80::cd69:f7a:ee65:6435%6]) with mapi id 15.20.1686.018; Wed, 6 Mar 2019 06:01:35 +0000 From: Alexander Vainshtein To: "Les Ginsberg (ginsberg)" CC: "lsr@ietf.org" , "spring@ietf.org" , "draft-ietf-isis-segment-routing-extensions.all@ietf.org" , "Peter Psenak (ppsenak)" Thread-Topic: [spring] FlexAlgo and Global Adj-SIDs Thread-Index: AdTPjdP9QRfJ5GzARfmqN1/BpEhW0gAEem2AAGBozJQAkaz8AAABfrsgAAC21FAAAD2n8AAIi81AABN/SDY= Date: Wed, 6 Mar 2019 06:01:35 +0000 Message-ID: References: <20493a62-cf70-a182-900d-e55dd68f5149@cisco.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [40.67.248.218] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f527b016-9a89-42b8-7d0e-08d6a1f930a8 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7153060)(7193020); SRVR:AM0PR03MB4129; x-ms-traffictypediagnostic: AM0PR03MB4129: x-microsoft-exchange-diagnostics: =?us-ascii?Q?1; AM0PR03MB4129; 23:M7s1X9svn54kXz2Cuhf6Yj1hDOPNtbvtxfs6RBWFu?= =?us-ascii?Q?/hPDsCcvIRs+33Gk+jnKLownnez51396Ni8QX6R32jdvYq6b84LiYP2XXBek?= =?us-ascii?Q?D3Vd1Ps2+2DxW60r9GyjtgX7nE2Ws8ATuSLDXUS7gGVYui7UDNEDufij3KIg?= =?us-ascii?Q?efXhjzawM1W8bu5k5wjxU0pSestUp6J/n27LbBrI211K0aCBQo7bM61HsYRW?= =?us-ascii?Q?6hdELQHTN3GFaN9Ve9HN25T4DF3m5RCuRltaO0tqRHUG1RGdxHbLDPPtN27e?= =?us-ascii?Q?opSA01HOakv1LvoTz8w7MQCavLgq5uLV8VJ5UGQI28CaJTGHlYGkSmEdU+yj?= =?us-ascii?Q?+uG9rfymwpJafHLe3+qp8N6dWZot+olHPf5DWVS1osc8WRDNiFTqgl4NdKRU?= =?us-ascii?Q?GlMf5XEjghBqy9uPwSavmFlPSlv31RPTfi0t0VleKKHY9+RXkuLjfhtE68WS?= =?us-ascii?Q?U3FWlpyV+uRxXnyEMJECYyytK+zSl01bcNf95VyAtoo9Fie6tpIJPlLuTyb8?= =?us-ascii?Q?Oheram2h1l7Yb2cR+hj018HI+xBaY4/LQ5QqXbm9Oc1o/C5NsyW990hWhelT?= =?us-ascii?Q?mCpmrHhxn1QRk5XADdlwRjeIAnLVLrooxhsGC5+i18uEI6z2+AzNzIcoTWIa?= =?us-ascii?Q?HLhZvE0KCHi05VBrJRlrTxDI4fVGuEORfMO07JPv1ZUL4BGu3vd9R60ZdwiM?= =?us-ascii?Q?iwaxuxG/1pMEfHBKM92ZZkmWGVH+1hSEKrlD7Ibrjq9ZAIelxzxx9sXAOndi?= =?us-ascii?Q?BAl8BZaCzn8CBcmamJCBmA57r+FrR20Cal32HBFu0BrnKqUlPZVgEzZHEEAz?= =?us-ascii?Q?btbcGeeDZv4hDm+yKOUmU2r/Q9WIV6tCoiorNg6dYujDxKOgLX9/bh1HmFeY?= =?us-ascii?Q?g23g6/wIo1vBSnKOtQPHPdvsKzWNuJ9vWUhegt1GnCcDroPKEVlBSyyqeDTE?= =?us-ascii?Q?+d/lkK0bRhU49sKS1PZxgmkDDSRXbE5DzHchkJcbdo/FxzkEawqPLBpFaBIO?= =?us-ascii?Q?6NDYwm43NAqNLxzWRqLBndWQTik481btSjEWKnunfdpL+R4WBw5rsIetTOIa?= =?us-ascii?Q?guZMT2RxmJLmLjoU1OAeMk2opPxrLPa8x/Yy9uGScQZevn8M+gNX2kLLRAVS?= =?us-ascii?Q?ycrDsC+/c8fyjVzmGKbz6KrvOABVjlG62JmZZtAs/0fvfNwd2HeaS8uXZl+q?= =?us-ascii?Q?Uzh8jv2zkKoZifiqkdPHIzdcFuEEw6uYcw0n6AxHuuPfV604RdIrYTuappmd?= =?us-ascii?Q?hO03Jv0yChPVS/EdzMcLeVzaOwYPw0Gm8vKK5TszIqXlSH1XdjsPZr0iXdEA?= =?us-ascii?Q?rSPYQmvXD4pGogjYzc0QyeK1u9O1ocURTB3CkrZm7Ja?= x-microsoft-antispam-prvs: x-forefront-prvs: 0968D37274 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(396003)(136003)(39860400002)(366004)(199004)(189003)(13464003)(51874003)(486006)(71190400001)(55016002)(74316002)(476003)(6246003)(71200400001)(6436002)(53936002)(7736002)(229853002)(446003)(93886005)(105586002)(106356001)(52536013)(76176011)(8676002)(9686003)(11346002)(81166006)(54896002)(86362001)(6116002)(97736004)(256004)(14444005)(2906002)(3846002)(81156014)(33656002)(25786009)(4326008)(66066001)(72206003)(478600001)(186003)(6916009)(26005)(54906003)(68736007)(6506007)(99286004)(102836004)(7696005)(53546011)(14454004)(316002)(8936002)(5660300002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR03MB4129; H:AM0PR03MB3828.eurprd03.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: ecitele.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: XrF2vZ2rI7S/D0b196QSnWiARUi64lA5ifvgMcOYxOoqj3ZxsXgIoBeyLMtljqLJau+wc7dxMtP6eL7Mn6cOP1QWppRaWEsl4cgU3UNosDkTmu7wz1T6KETWBCLUUGuV0LRrJd6QvOifKurMz4bZoUoo59G76OwxUFJHicY/KdQJiq+A2A36lr1uzniwOyX//QQpUFEqYKUkidojXY5/jfbND081gPiesZUh2RfVRkmhYSObudZAGxVTrZH31IQRgW41PDLls0XgIvbbdaEsltsZq4DJ4xqE9Dvand/tzIJRvVid1vlP5oaGWRSNxdPfIq71q7suYCNNhhIdStqpDZTxsbE7LsZ6nRzbx2N8ATsYIetDMpToG5b/1zyl+W6mYtugsICQ/bFFzyDxBjTIX5mQnDFCLjLczS+07oBs0x4= Content-Type: multipart/alternative; boundary="_000_AM0PR03MB38287626F8B5567DA01B82879D730AM0PR03MB3828eurp_" MIME-Version: 1.0 X-OriginatorOrg: ecitele.com X-MS-Exchange-CrossTenant-Network-Message-Id: f527b016-9a89-42b8-7d0e-08d6a1f930a8 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Mar 2019 06:01:35.3850 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2c514a61-08de-4519-b4c0-921fef62c42a X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR03MB4129 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Lsr] [spring] FlexAlgo and Global Adj-SIDs X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 06:01:48 -0000 --_000_AM0PR03MB38287626F8B5567DA01B82879D730AM0PR03MB3828eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Les, Lots of thanks, makes sense to me. Thumb typed by Sasha Vainshtein ________________________________ From: Les Ginsberg (ginsberg) Sent: Tuesday, March 5, 2019 10:48:43 PM To: Alexander Vainshtein Cc: lsr@ietf.org; spring@ietf.org; draft-ietf-isis-segment-routing-extensi= ons.all@ietf.org; Peter Psenak (ppsenak) Subject: RE: [spring] FlexAlgo and Global Adj-SIDs Sasha - Although you raise a valid issue, I am not feeling any urgency here i.e., = although the local protected use case is valid I don't see it as operation= ally critical. However, that's just my opinion. If you want to pursue this I think you could raise the issue in either LSR= or SPRING (or both). The gap in the architecture documents is less important than coming to con= sensus on the importance of the use case. If there is consensus to addres= s this then I think deciding what documents need updating will just follow= logically. Make sense to you? Les > -----Original Message----- > From: Alexander Vainshtein > Sent: Tuesday, March 05, 2019 8:47 AM > To: Les Ginsberg (ginsberg) > Cc: lsr@ietf.org; spring@ietf.org; draft-ietf-isis-segment-routing- > extensions.all@ietf.org; Peter Psenak (ppsenak) > Subject: RE: [spring] FlexAlgo and Global Adj-SIDs > > Les, > Lots of thanks for a prompt response. > > I fully understand that the current SR extension drafts are too far adva= nced > for any significant changes. > > I also understand that Algo-specific Adj-SIDs require an update to RFC 8= 402 > because today it does not recognize any such entities. > Therefore the discussion of use cases should probably start in the SPRIN= G > WG while effective the result would be "just" new Sub-TLV in IS-IS and O= SPF > with the actual work coming to the LSR WG. > > Any ideas as to what would be the best way to start this kind of discuss= ions? > > Regards, > Sasha > > Office: +972-39266302 > Cell: +972-549266302 > Email: Alexander.Vainshtein@ecitele.com > > > -----Original Message----- > From: Les Ginsberg (ginsberg) > Sent: Tuesday, March 5, 2019 6:37 PM > To: Alexander Vainshtein ; Peter > Psenak (ppsenak) > Cc: lsr@ietf.org; spring@ietf.org; draft-ietf-isis-segment-routing- > extensions.all@ietf.org > Subject: RE: [spring] FlexAlgo and Global Adj-SIDs > > Sasha - > > draft-ietf-isis-segment-routing-extensions is currently in AD review - a= nd the > companion OSPF document has already been approved and is waiting for a > dependent draft to progress before publication as an RFC. > > It is too late to make significant changes. > > Further, while I agree with both your description and Peter's response, > agreeing that this "could" be done is not equivalent to having consensus= that > it "should" be done. > I think a more complete consideration of the deployment cases and the > usefulness of such an extension should be discussed by the WG before we > decide that we actually want to define such an extension. > > Les > > > > -----Original Message----- > > From: Alexander Vainshtein > > Sent: Tuesday, March 05, 2019 8:29 AM > > To: Peter Psenak (ppsenak) > > Cc: lsr@ietf.org; spring@ietf.org; draft-ietf-isis-segment-routing- > > extensions.all@ietf.org > > Subject: RE: [spring] FlexAlgo and Global Adj-SIDs > > > > Peter, > > Lots of thanks for a prompt and very encouraging response. > > > > Do you think that the new Algo specific Adj-SID sub-TLV could be added= > > to the current IS-IS segment Routing Extensions draft, or should be > > handled in a small dedicated document? > > > > Regards, and lots of thanks in advance, Sasha > > > > Office: +972-39266302 > > Cell: +972-549266302 > > Email: Alexander.Vainshtein@ecitele.com > > > > -----Original Message----- > > From: Peter Psenak > > Sent: Tuesday, March 5, 2019 5:28 PM > > To: Alexander Vainshtein > > Cc: lsr@ietf.org; spring@ietf.org; draft-ietf-isis-segment-routing- > > extensions.all@ietf.org > > Subject: Re: [spring] FlexAlgo and Global Adj-SIDs > > > > Hi Sasha, > > > > On 02/03/2019 18:57 , Alexander Vainshtein wrote: > > > Peter, > > > Lots of thanks for a prompt and hivhly informative response. > > > > > > It seems that per-FlexAlgo Adj-SIDs can be useful even if they are > > > local > > __________________________________________________________ > _________________ > > This e-mail message is intended for the recipient only and contains > information which is > CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have > received this > transmission in error, please inform us by e-mail, phone or fax, and the= n > delete the original > and all copies thereof. > __________________________________________________________ > _________________ __________________________________________________________________________= _ This e-mail message is intended for the recipient only and contains inform= ation which is=20 CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this=20 transmission in error, please inform us by e-mail, phone or fax, and then = delete the original=20 and all copies thereof. __________________________________________________________________________= _ --_000_AM0PR03MB38287626F8B5567DA01B82879D730AM0PR03MB3828eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Les,
Lots of thanks, makes sense to me.

Thumb typed by Sasha Vainshtein

From: Les Ginsberg (gin= sberg) <ginsberg@cisco.com>
Sent: Tuesday, March 5, 2019 10:48:43 PM
To: Alexander Vainshtein
Cc: lsr@ietf.org; spring@ietf.org; draft-ietf-isis-segment-routing-= extensions.all@ietf.org; Peter Psenak (ppsenak)
Subject: RE: [spring] FlexAlgo and Global Adj-SIDs
 
Sasha -

Although you raise a valid issue, I am not feeling any urgency here i.e., = although the local protected use case is valid I don't see it as operation= ally critical.
However, that's just my opinion.

If you want to pursue this I think you could raise the issue in either LSR= or SPRING (or both).
The gap in the architecture documents is less important than coming to con= sensus on the importance of the use case.  If there is consensus to a= ddress this then I think deciding what documents need updating will just f= ollow logically.

Make sense to you?

   Les


> -----Original Message-----
> From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com> > Sent: Tuesday, March 05, 2019 8:47 AM
> To: Les Ginsberg (ginsberg) <ginsberg@cisco.com>
> Cc: lsr@ietf.org; spring@ietf.org; draft-ietf-isis-segment-routing- > extensions.all@ietf.org; Peter Psenak (ppsenak) <ppsenak@cisco.com= >
> Subject: RE: [spring] FlexAlgo and Global Adj-SIDs
>
> Les,
> Lots of thanks for a prompt response.
>
> I fully understand that the current SR extension drafts are too far a= dvanced
> for any significant changes.
>
> I also understand that Algo-specific Adj-SIDs require an update to RF= C 8402
> because today it does not recognize any such entities.
> Therefore the discussion of use cases should probably start in the SP= RING
> WG while effective the result would be "just" new Sub-TLV i= n IS-IS and OSPF
> with the actual work coming to the LSR WG.
>
> Any ideas as to what would be the best way to start this kind of disc= ussions?
>
> Regards,
> Sasha
>
> Office: +972-39266302
> Cell:      +972-549266302
> Email:   Alexander.Vainshtein@ecitele.com
>
>
> -----Original Message-----
> From: Les Ginsberg (ginsberg) <ginsberg@cisco.com>
> Sent: Tuesday, March 5, 2019 6:37 PM
> To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>; Pe= ter
> Psenak (ppsenak) <ppsenak@cisco.com>
> Cc: lsr@ietf.org; spring@ietf.org; draft-ietf-isis-segment-routing- > extensions.all@ietf.org
> Subject: RE: [spring] FlexAlgo and Global Adj-SIDs
>
> Sasha -
>
> draft-ietf-isis-segment-routing-extensions is currently in AD review = - and the
> companion OSPF document has already been approved and is waiting for = a
> dependent draft to progress before publication as an RFC.
>
> It is too late to make significant changes.
>
> Further, while I agree with both your description and Peter's respons= e,
> agreeing that this "could" be done is not equivalent to hav= ing consensus that
> it "should" be done.
> I think a more complete consideration of the deployment cases and the=
> usefulness of such an extension should be discussed by the WG before = we
> decide that we actually want to define such an extension.
>
>   Les
>
>
> > -----Original Message-----
> > From: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com&= gt;
> > Sent: Tuesday, March 05, 2019 8:29 AM
> > To: Peter Psenak (ppsenak) <ppsenak@cisco.com>
> > Cc: lsr@ietf.org; spring@ietf.org; draft-ietf-isis-segment-routi= ng-
> > extensions.all@ietf.org
> > Subject: RE: [spring] FlexAlgo and Global Adj-SIDs
> >
> > Peter,
> > Lots of thanks for a prompt and very encouraging response.
> >
> > Do you think that the new Algo specific Adj-SID sub-TLV could be= added
> > to the current IS-IS segment Routing Extensions draft, or should= be
> > handled in a small dedicated document?
> >
> > Regards, and lots of thanks in advance, Sasha
> >
> > Office: +972-39266302
> > Cell:      +972-549266302
> > Email:   Alexander.Vainshtein@ecitele.com
> >
> > -----Original Message-----
> > From: Peter Psenak <ppsenak@cisco.com>
> > Sent: Tuesday, March 5, 2019 5:28 PM
> > To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>= ;
> > Cc: lsr@ietf.org; spring@ietf.org; draft-ietf-isis-segment-routi= ng-
> > extensions.all@ietf.org
> > Subject: Re: [spring] FlexAlgo and Global Adj-SIDs
> >
> > Hi Sasha,
> >
> > On 02/03/2019 18:57 , Alexander Vainshtein wrote:
> > > Peter,
> > > Lots of thanks for a prompt and hivhly informative response= .
> > >
> > > It seems that per-FlexAlgo Adj-SIDs can be useful even if t= hey are
> > > local
>
> __________________________________________________________
> _________________
>
> This e-mail message is intended for the recipient only and contains > information which is
> CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have=
> received this
> transmission in error, please inform us by e-mail, phone or fax, and = then
> delete the original
> and all copies thereof.
> __________________________________________________________
> _________________
__________________________________________________________________________= _

This e-mail message is intended for the recipient only and contains inform= ation which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have rece= ived this
transmission in error, please inform us by e-mail, phone or fax, and then = delete the original
and all copies thereof.
__________________________________________________________________________= _
--_000_AM0PR03MB38287626F8B5567DA01B82879D730AM0PR03MB3828eurp_-- From nobody Wed Mar 6 05:29:12 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7873F124184; Wed, 6 Mar 2019 05:28:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 xuLJ3XrR6vSS; Wed, 6 Mar 2019 05:28:57 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id E79DA12797D; Wed, 6 Mar 2019 05:28:56 -0800 (PST) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 2E4A960503; Wed, 6 Mar 2019 08:28:55 -0500 (EST) From: Christian Hopps Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_9945E594-4130-433A-A120-623C1A1F447D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Wed, 6 Mar 2019 08:28:54 -0500 In-Reply-To: <5316A0AB3C851246A7CA5758973207D463B66FE9@sjceml521-mbx.china.huawei.com> Cc: Christian Hopps , Tony Li , "lsr@ietf.org" , "lsr-chairs@ietf.org" , "lsr-ads@ietf.org" To: Huaimo Chen References: <5316A0AB3C851246A7CA5758973207D463B5858A@sjceml521-mbx.china.huawei.com> <420ed1b5-d849-99cc-bcb0-d159783e4de2@cisco.com> <5316A0AB3C851246A7CA5758973207D463B59041@sjceml521-mbx.china.huawei.com> <0B4DF2AC-8EE1-41CA-B357-98325067CA30@gmail.com> <5316A0AB3C851246A7CA5758973207D463B66FE9@sjceml521-mbx.china.huawei.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll. X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 13:29:11 -0000 --Apple-Mail=_9945E594-4130-433A-A120-623C1A1F447D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Let's use new email threads for suggested changes. One thread per = suggested change/problem to keep things easier to follow. Thanks, Chris. --Apple-Mail=_9945E594-4130-433A-A120-623C1A1F447D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAlx/yxYACgkQLh2DDte4 MCWD/w/+NAyKmf9AvPFIr4xrIAskpc7NB88YA3R8EeV8CjoPQo9eBxMBQETv1JOP JDa7QliGuetyV9+ZQxs0SbZcZv1theKQOmXEyu67IFzEmKczh36BQfzyY6Mo7j6Y Ykte/UHJ0IEhvd1lTWG+8+KSfG2sgSX503ECONHmsTZ0BwSfdQWYCTUN46M4hrHT VRiODKOQlipH5pQxWDmHFQ4sME/v1rtqLwYuU7ZPcE/V2ul1X95g8czk1nkxUScJ p8LdA5F/SgK1OHHv/jUSXTfJAZ/XTSTLUu8D4nt807kRhOYGLbudBo1O4N4XTRaQ 7Ak3U6UbtqJ0pJgFPJ5loLn0Px2Y9leeX1t7rOE2Q1+JeZgMFM15rn0aM5XYrHn7 gZedFkpA6rTlrkRwD5NqOl3Mgl+BMGFIp7+mEf28ldTjVGRAzdB0UdHD8fw7pIgA 9v1Ho45o0PDc6wprRWiV6YvY/YmvNAXs/Ank7WCpKNFWcr5mu0I2dgiby+7LDgpG o/J8SuFz51K+V6SMoy6W8gJRWJZz2+9RqpPo8K/7oREQsQiim4oJnZnH+6ceaW6D 8D0OkdRAlRMY+bEa+8ie5OrJ0Px2A5a/SV7CNdGhKc4m1kSW0h+ZY0AwPF+3jofZ +u2eotJ0p7V+Uu5844oeff2+sUUn9n/ZkRAO7scxazAJWFzJj0s= =OWNb -----END PGP SIGNATURE----- --Apple-Mail=_9945E594-4130-433A-A120-623C1A1F447D-- From nobody Wed Mar 6 05:48:31 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3302C124B19 for ; Wed, 6 Mar 2019 05:48:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0 X-Spam-Level: X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_NONE=-0.0001] 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 FA7q96dFmpaJ for ; Wed, 6 Mar 2019 05:48:25 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id BBF2412423B for ; Wed, 6 Mar 2019 05:48:23 -0800 (PST) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 33073604D0; Wed, 6 Mar 2019 08:48:22 -0500 (EST) From: Christian Hopps Content-Type: multipart/signed; boundary="Apple-Mail=_1FE1845C-128A-417C-93F0-EC22EEB0CCE9"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-Id: <43D99E72-6BA4-4B95-84EC-E7D497D607D7@chopps.org> Date: Wed, 6 Mar 2019 08:48:21 -0500 Cc: Christian Hopps To: lsr@ietf.org X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: [Lsr] Configuration of LSR routers in WRT dynamic flooding X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 13:48:30 -0000 --Apple-Mail=_1FE1845C-128A-417C-93F0-EC22EEB0CCE9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Huaimo wrote: > > Tony wrote: > > > >There is no need for a backup leader. If the area leader is = partitioned from the topology, then > > leader election is repeated, resulting in a new leader. Again, no = configuration is required. >=20 > The above does not talk about topology split, but about the leader = down. After a user/operator has configured some things on the leader, = and the leader has got them and distributed them in some form, and then = some time later, the leader goes down, a new leader is selected. In this = case, will the new leader take and maintain the configurations or the = information derived from the configurations done on the old leader.I Operators configure their routers using their management systems. When = an operator chooses a distributed algorithm they SHOULD configure that = choice consistently in their network if they don't expect changes based = on leader election. This is something that can be stated in the document = if it must be. Yes, misconfiguration is possible due to NMS bugs, in which case it may = be reasonable for the LSR protocol to detect and signal this = misconfiguration. We do not want to build a bunch of complexity into LSR protocols to = treat misconfigurations as the normal state of things, as it is not. Thanks, Chris. > Best Regards, > Huaimo >=20 --Apple-Mail=_1FE1845C-128A-417C-93F0-EC22EEB0CCE9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAlx/z6UACgkQLh2DDte4 MCUJSRAAnpt86m0XY/XcSqfywnwrLD76/T3OyZnm49CPHLsmFKXEPliLBrn1swtf OfB/4dErjSOoEVz6TfoJbVbYQOfmP+MtWnFhuiezKnihY9yWDCFbu2hGmBCjIo+7 KzgpgHVd/a4YlK7L8XQ6LyQHW6gdb7Mg0s/R4q7q4sZkdznDpesP9dHojWt1liNW jQ6XYfX8/CLCa0ucBUyaAsHWZSg/iRYlPH1UnAn5LpSxeDaGcm2xwd0PmhYMFRu+ tbdZS9MD4Pp5sPPGdYiHx4DghP8r2YTWN7gljRMffCDZSVpjlqjeP4298PDrV6uh iSXJwbw9iUxEYCrgjjYH078hvcyb3oewdgj4vxTdYA7rdITgozR7gDrzEcbe8wx+ CeUN0cCm5YlqWp6pDlH9eIzAgHvM3tKAMPBAx6syojXCt4iFJ/LxPhifn2DL8K9k aQv9GW2pB3MgOzbA2A3Idzl4JrzNRk+LIUy14xQJbM9fS+Ot6YgkstFHkxR6xg8q FPRyRnv1EoNo0egHm/jeP2SaXUVmine44LOb2jm+7GeTQ8+RfP2MDQ+4Te3+4DLv CLt5yGPMHlYQwl1oYovxX9vLhqvLrNFEjUkfue4sEF2iihIBLaIgdvL8sDvAigkt 01uzOJ4OEKKbTPKBRe8PAzKNBUnhDHpcf36g4EW567u8iuBteIg= =scMs -----END PGP SIGNATURE----- --Apple-Mail=_1FE1845C-128A-417C-93F0-EC22EEB0CCE9-- From nobody Wed Mar 6 07:45:23 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6524C127287; Wed, 6 Mar 2019 07:45:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.251 X-Spam-Level: X-Spam-Status: No, score=0.251 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 AMAU-hrn_c7b; Wed, 6 Mar 2019 07:45:20 -0800 (PST) Received: from mail-pg1-x543.google.com (mail-pg1-x543.google.com [IPv6:2607:f8b0:4864:20::543]) (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 91D981275E9; Wed, 6 Mar 2019 07:45:20 -0800 (PST) Received: by mail-pg1-x543.google.com with SMTP id q206so8720978pgq.4; Wed, 06 Mar 2019 07:45:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=BXVoNd45aPd3TQsO8lrcLz3PoewuRnjmLValVebYtbU=; b=FWgkEI9TqF2lZlJoSe/vWtyr42bmVKCABslPEDZ31nAIs4F+Jdc1RxB1YX8GASX7m5 CW9HZ16ydHFsTfHLsSE3zNddNVDM5GD10x6YPec1qlTmfglpZo2paGWGwZJwDQijzDpT cYQcVElQO0gQq7plr6WLoS7bKLgstcyyBSs/u068mil87XnOm+0azGe+W5RfKFfXAHRq AcH9Aa3w7jts7hi4IVdCUUbc84G1NvJomYEHBbOkeTEM4ieYo3cQXFer/xHARQRtYAQd yogsu8uHAfehm5rIqNLN9LiGX4YL404avSVrZ1RWya85UgTEjeqrm9GHqzRuyxGm382h TH5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=BXVoNd45aPd3TQsO8lrcLz3PoewuRnjmLValVebYtbU=; b=d6OOEEgcM4OW4C9uvSYp9MxP1xPy0a47VHW1WiailfkzBkkoGfOKoWpJx7le7VehnH TuY02Z/hMCr6fusPON73M8pF+jzq7SGasn/SOezJv1cjEEKGgcx9xYY75cZ7CJ4mORvN iYvN+PdT3mf7CVLbWBglMWMmi4l/XLhvhCCfGnBlk8VOe9XuYT/1LHe+eSSa3/NlKxaI hQ2T2fj3BM4jfsqKR8NL720sskbzNF7PsMJp/vt5ELmslSA/AA/8DPcod795SA4Lz0JT J2U1o2FaqbjZrXkRTMoZ9dHYF1lO1q3l5w1ujDCJemnHx63v//ScWNMJDfif97ais6Mi HDOg== X-Gm-Message-State: APjAAAVgCvF2xGwMALoOfdPAHjyum045V1kxqyfv8aSMTvafJQjMzthB xfJ3rL97MhTGzcfCKfGJK90= X-Google-Smtp-Source: APXvYqwTtE9S8piPJt/nYuJWG1y6spjbPTYqRmrcCkSMDabnTeV4/HqLHsOvXFyHg+2ATHmCPRqOvA== X-Received: by 2002:a17:902:9a01:: with SMTP id v1mr2028562plp.34.1551887119941; Wed, 06 Mar 2019 07:45:19 -0800 (PST) Received: from [10.95.95.229] ([162.210.129.5]) by smtp.gmail.com with ESMTPSA id z6sm3949945pgo.31.2019.03.06.07.45.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Mar 2019 07:45:19 -0800 (PST) Sender: Tony Li From: tony.li@tony.li Message-Id: <78A866F4-9AF0-481A-9DEC-B04DE72AFDA3@tony.li> Content-Type: multipart/alternative; boundary="Apple-Mail=_973A248E-27A6-45B5-B1A2-2C13D0E632DD" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Wed, 6 Mar 2019 07:45:17 -0800 In-Reply-To: <5316A0AB3C851246A7CA5758973207D463B66FE9@sjceml521-mbx.china.huawei.com> Cc: Christian Hopps , "lsr@ietf.org" , "lsr-chairs@ietf.org" , "lsr-ads@ietf.org" To: Huaimo Chen References: <5316A0AB3C851246A7CA5758973207D463B5858A@sjceml521-mbx.china.huawei.com> <420ed1b5-d849-99cc-bcb0-d159783e4de2@cisco.com> <5316A0AB3C851246A7CA5758973207D463B59041@sjceml521-mbx.china.huawei.com> <0B4DF2AC-8EE1-41CA-B357-98325067CA30@gmail.com> <5316A0AB3C851246A7CA5758973207D463B66FE9@sjceml521-mbx.china.huawei.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: [Lsr] Multiple failures in Dynamic Flooding X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 15:45:23 -0000 --Apple-Mail=_973A248E-27A6-45B5-B1A2-2C13D0E632DD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Huaimo, > > I=E2=80=99m sorry that you don=E2=80=99t find it useful. Determining = the split is trivial: when you receive an IIH, > > it has a system ID of the another system in it. If that other system = is not currently part of the > > flooding topology, then it is quite clear that it is disconnected = from the flooding topology. > > Repairing the split is done by enabling temporary flooding on the = new link. > =20 > For an adjacency between two nodes is up, the Hello packets exchanged = between them will not change node/system IDs in them. > How do you determine that other system is not currently part of the = flooding topology? The IIH includes the system ID. See ISO 10589 v2, section 9.7, field = =E2=80=9Csource Id=E2=80=9D. The local system will have a copy of the flooding topology and can easily see if the neighbor was = present as of the last FT computation. If not, then it should be added (modulo rate limiting). The local system can also examine it=E2=80=99= s own LSDB. If there is no LSP for the neighbor, then it would seem highly likely that there is a disconnect and the neighbor should again = be added (modulo rate limiting). We are not requiring it, but a system could also do a more extensive = computation and compare the links between itself and the neighbor by tracing the path in the FT and then confirming that each link is up = in the LSDB. > > There is an issue here that we have not yet resolved, which is the = rate that new links should be > > temporarily added to the flooding topology. Some believe that = adding any new link is the > > correct thing to do as it minimizes the recovery time. Others feel = that enabling too many links > > could cause a flooding collapse, so link addition should be highly = constrained. We are still > > discussing this and invite the WG=E2=80=99s opinions. > =20 > The issue is resolved by the solutions in = draft-cc-lsr-flooding-reduction. > One solution is below, where the given distance can be = adjusted/configured. > If we want every node to flood on all its links, we let the given > distance to a big number. If we want the nodes within 2 hops to a = failure > to flood on all their links, we set the given distance to 2. > =E2=80=9CIn one way, when two or more failures on the current = flooding > topology occur almost in the same time, each of the nodes within a > given distance (such as 3 hops) to a failure point, floods the link > state (LS) that it receives to all the links (except for the one = from > which the LS is received) until a new flooding topology is = built.=E2=80=9D As we have discussed, this is not a solution. In fact, this is more = dangerous than anything else that has been proposed and seems highly likely to trigger a cascade failure. You are enabling full = flooding for many nodes. In dense topologies, even a radius of 3 is very high. For example, in a LS topology, a radius of = 3 is sufficient to enable full flooding throughout the entire topology. If that were stable, we would not need Dynamic Flooding = at all. > Another solution is just adding minimum links temporarily on the = flooding > topology to repair the split flooding topology until a new flooding = topology > is built. Agreed. Which links constitute the minimum? In a general topology, = with arbitrary failures that are not distributed globally, how do we make a distributed decision about which links to enable? This = is the problem that we are trying to solve. And we have no oracle to tell us The Right Answer. > The link can be enabled for =E2=80=9Ctemporary flooding=E2=80=9D by = the node without using any TLV or Hello with the TLV. There are cases where it is far easier for the neighbor to realize that = it is disconnected than for the local system to realize that the neighbor is disconnected. Thus, it is easier to allow one = system to request temporary addition.=20 > The TLV in Hello packet just requests for adding =E2=80=9Ctemporary = flooding=E2=80=9D on the link. The other information is accessed by the = node locally. The TLV in Hello packet does not help for corner case. In = the case where a node is rebooted, a new link attached to a new node may = apply. If the node that rebooted has 1000 interfaces, which interfaces should = be temporarily added? Adding all of them is likely to trigger a cascade = failure. The TLV allows us to signal which ones should be enabled. > >All adjacencies are a single hop in both IS-IS and OSPF. Yes, Hello = packets may be lost. > >Fortunately, they are periodically transmitted, thus the next = transmission will also contain the > > TLV. If IIH=E2=80=99s are getting lost at a significant rate, then = the adjacency will not (and should not) > >come up. Thus, the request for temporary flooding will propagate to = the neighbor in all cases > >that matter. > =20 > It takes too long when Hello packet is lost. Repairing split flooding = topology needs to be fast. Fortunately, lost hello packets are a relatively rare occurrence. While = repairing the flooding topology needs to be done expediently, attempting = to do so and triggering a cascade failure of the network is = counter-productive. Given this alternative, a bit of extra delay when = adding a new system to the network, or trying to recover from multiple = failures seems wise. Rushing and making things worse does not. The = first priority must remain network stability. >=20 > It does not mean that a user/operator configures/select an area = leader. It means that a user/operator configures other things such as = indicating an algorithm or selecting the centralized mode on the area = leader.=20 In an implementation, centralized mode and algorithm selection can be = the defaults. In fact, in our implementation, the only required = configuration is to enable dynamic flooding. Everything else is = automatic. Regards, Tony --Apple-Mail=_973A248E-27A6-45B5-B1A2-2C13D0E632DD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Hi Huaimo,


> I=E2=80=99m sorry = that you don=E2=80=99t find it useful. Determining the split is trivial: = when you receive an IIH,
> it has a system ID = of the another system in it. If that other system is not currently part = of the
> flooding topology, = then it is quite clear that it is disconnected from the flooding = topology.
> Repairing the split = is done by enabling temporary flooding on the new link.
 
For an adjacency between two nodes is up, the Hello = packets exchanged between them will not change node/system IDs in = them.
How do you determine that other system is not currently part = of the flooding topology?


The IIH includes the = system ID.  See ISO 10589 v2, section 9.7, field =E2=80=9Csource = Id=E2=80=9D.  The local system will have
a copy of the = flooding topology and can easily see if the neighbor was present as of = the last FT computation.  If not, then it should be
added = (modulo rate limiting). The local system can also examine it=E2=80=99s = own LSDB.  If there is no LSP for the neighbor, then it would = seem
highly likely that there is a disconnect and the neighbor = should again be added (modulo rate limiting).

We are not requiring it, but a system could also = do a more extensive computation and compare the links between itself and = the neighbor
by tracing the path in the FT and then confirming = that each link is up in the LSDB.


> There is an issue = here that we have not yet resolved, which is the rate that new links = should be
> temporarily added to = the flooding topology.  Some believe that adding any new link is = the
> correct thing to do = as it minimizes the recovery time. Others feel that enabling too many = links
> could cause a = flooding collapse, so link addition should be highly constrained. We are = still
> discussing this and = invite the WG=E2=80=99s opinions.
 
The issue is resolved by the solutions in = draft-cc-lsr-flooding-reduction.
One solution is below, = where the given distance can be adjusted/configured.
If we want every node to flood on all its links, we let the = given
distance to a big number. If we want the nodes within 2 hops = to a failure
to flood on all their links, we set the given = distance to 2.
   =E2=80=9CIn one way, when two or more = failures on the current flooding
   topology = occur almost in the same time, each of the nodes within a
   given distance (such as 3 hops) to a failure = point, floods the link
   state (LS) that it receives = to all the links (except for the one from
   which the = LS is received) until a new flooding topology is = built.=E2=80=9D

As we have discussed, this is not a solution. In = fact, this is more dangerous than anything else that has been proposed = and
seems highly likely to trigger a cascade failure. You are = enabling full flooding for many nodes.  In dense topologies, = even
a radius of 3 is very high.  For example, in a LS = topology, a radius of 3 is sufficient to enable full flooding throughout = the
entire topology. If that were stable, we would not need = Dynamic Flooding at all.


Another solution is just adding minimum links = temporarily on the flooding
topology to repair the = split flooding topology until a new flooding topology
is built.


Agreed.  Which = links constitute the minimum?  In a general topology, with = arbitrary failures that are not distributed globally,
how do = we make a distributed decision about which links to enable? This is the = problem that we are trying to solve. And
we have no oracle to = tell us The Right Answer.


The link can be = enabled for =E2=80=9Ctemporary flooding=E2=80=9D by the node without = using any TLV or Hello with the = TLV.


There are cases where it is far easier for the = neighbor to realize that it is disconnected than for the local system to = realize
that the neighbor is disconnected.  Thus, it is = easier to allow one system to request temporary = addition. 


The TLV in Hello packet just = requests for adding =E2=80=9Ctemporary flooding=E2=80=9D on the link. = The other information is accessed by the node locally. The TLV in Hello = packet does not help for corner case. In the case where a node is = rebooted, a new link attached to a new node may = apply.


If the node that rebooted has 1000 interfaces, = which interfaces should be temporarily added?  Adding all of them = is likely to trigger a cascade failure.  The TLV allows us to = signal which ones should be enabled.


>All adjacencies are a single hop in both IS-IS and = OSPF.  Yes, Hello packets may be lost.
>Fortunately, they are periodically = transmitted, thus the next transmission will also contain the
> TLV.  If IIH=E2=80=99s = are getting lost at a significant rate, then the adjacency will not (and = should not)
>come up.  Thus, the request for = temporary flooding will propagate to the neighbor in all cases
>that matter.
 
It takes too long when Hello packet is lost. = Repairing split flooding topology needs to be = fast.


Fortunately, lost hello packets are a relatively = rare occurrence.  While repairing the flooding topology needs to be = done expediently, attempting to do so and triggering a cascade failure = of the network is counter-productive. Given this alternative, a bit of = extra delay when adding a new system to the network, or trying to = recover from multiple failures seems wise. Rushing and making things = worse does not.  The first
priority must remain network = stability.



It does not mean that a user/operator configures/select an = area leader. It means that a user/operator configures other things such = as indicating an algorithm or selecting the centralized mode on the area = leader. 


In an implementation, centralized mode and = algorithm selection can be the defaults.  In fact, in our = implementation, the only required configuration is to enable dynamic = flooding. Everything else is automatic.


Regards,
Tony

= --Apple-Mail=_973A248E-27A6-45B5-B1A2-2C13D0E632DD-- From nobody Wed Mar 6 10:29:57 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57D3213120D; Wed, 6 Mar 2019 10:29:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=BWJoB2Yc; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=mrzLALcU 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 IoVuBoaWoFOS; Wed, 6 Mar 2019 10:29:53 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C397E13103C; Wed, 6 Mar 2019 10:29:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7266; q=dns/txt; s=iport; t=1551896993; x=1553106593; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=nUCBASnBCu768Q+oCSKXXvfUrK1EASO0U80dQF2Ai6w=; b=BWJoB2YcmEVZND5i8sAy29GFgf/643uYBIhQuA2Gqa1RtX8inN5XgDlq zDv0FMxI5LRA/hroMzXWbxD2r9PIR+Ah6AiX3YKXrB1sAyDsQzZL3HgLB 6+Q57OEBVfFUjoU8Hc8XEiFb/ZlUuk8qyHhmvrnASjaHaqEc8FNTyUNbb E=; IronPort-PHdr: =?us-ascii?q?9a23=3AAscWThBJpZhgS1Ns2323UyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qs03kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuI//sdCY3BstqX15+9Hb9Ok9QS47z?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ANAADQEIBc/5xdJa1kGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBUQYBAQELAYENLyknA2h0BAsnhAiDRwOEUIsBlQeFc4EkA1QKAQE?= =?us-ascii?q?BLIRAAheEGiI0CQ0BAQMBAQMBAwJtHAyFSwYjChMBATcBDwIBCEICAgIwJQI?= =?us-ascii?q?EAQ0NgxuBEUwDFQECoE0CihRxgS+CeAEBBYR/GIILCIEvAYRZhk8XgUA/gVe?= =?us-ascii?q?CHi6FA4MIMYImjEeEBpNECQKTF5Mvim+SMQIEAgQFAg0BAQWBRziBVnAVgye?= =?us-ascii?q?CCoEjAQeCQ4pTcoEoih8qgiMBAQ?= X-IronPort-AV: E=Sophos;i="5.58,448,1544486400"; d="scan'208,217";a="533705704" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Mar 2019 18:29:50 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x26ITowT019574 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 6 Mar 2019 18:29:50 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 6 Mar 2019 12:29:50 -0600 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 6 Mar 2019 12:29:49 -0600 Received: from NAM01-BY2-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.1473.3 via Frontend Transport; Wed, 6 Mar 2019 13:29:49 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=nUCBASnBCu768Q+oCSKXXvfUrK1EASO0U80dQF2Ai6w=; b=mrzLALcUSNl/Xxg2ELf8DPLoHxMhDYi8kqHL55Viay5dWgc/mqCm7FCMaIyReS+RRDjsNMkmsTj6akCcOoH87DCrdb+VtLs9Wvyk0CM1b1AghH3x0fstty6BAKxH+EGP/4JR0v5DWuMYco71EhenbPYlMKHJjUXYiVg+T9C5AMo= Received: from BYAPR11MB3638.namprd11.prod.outlook.com (20.178.237.19) by BYAPR11MB2888.namprd11.prod.outlook.com (20.177.225.88) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.19; Wed, 6 Mar 2019 18:29:47 +0000 Received: from BYAPR11MB3638.namprd11.prod.outlook.com ([fe80::b414:f534:f20a:a26d]) by BYAPR11MB3638.namprd11.prod.outlook.com ([fe80::b414:f534:f20a:a26d%3]) with mapi id 15.20.1686.016; Wed, 6 Mar 2019 18:29:47 +0000 From: "Les Ginsberg (ginsberg)" To: "tony.li@tony.li" , Huaimo Chen CC: "lsr@ietf.org" , "lsr-ads@ietf.org" , Christian Hopps , "lsr-chairs@ietf.org" Thread-Topic: [Lsr] Multiple failures in Dynamic Flooding Thread-Index: AQHU1DO0xw6ZW2WTWUCDw73GtE+zJKX+68pA Date: Wed, 6 Mar 2019 18:29:47 +0000 Message-ID: References: <5316A0AB3C851246A7CA5758973207D463B5858A@sjceml521-mbx.china.huawei.com> <420ed1b5-d849-99cc-bcb0-d159783e4de2@cisco.com> <5316A0AB3C851246A7CA5758973207D463B59041@sjceml521-mbx.china.huawei.com> <0B4DF2AC-8EE1-41CA-B357-98325067CA30@gmail.com> <5316A0AB3C851246A7CA5758973207D463B66FE9@sjceml521-mbx.china.huawei.com> <78A866F4-9AF0-481A-9DEC-B04DE72AFDA3@tony.li> In-Reply-To: <78A866F4-9AF0-481A-9DEC-B04DE72AFDA3@tony.li> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ginsberg@cisco.com; x-originating-ip: [2001:420:c0c8:1007::680] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6a257bb1-a149-4cba-2678-08d6a261b658 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BYAPR11MB2888; x-ms-traffictypediagnostic: BYAPR11MB2888: x-microsoft-exchange-diagnostics: =?utf-8?B?MTtCWUFQUjExTUIyODg4OzIzOm8zSG8vckZiejFNalU5YitsQS9XQUVraHJB?= =?utf-8?B?aTc2M1g0b3pFVyt2NUsxK3JlbmdGUlpkVFJjV0ovTzAvRi9mdUwxM3h0TVZD?= =?utf-8?B?ZlRwRjNydEJDMkdBaUxCOUNGM29SWTFnVFRPaXFXeTlmRnB4YVJibEpYODVs?= =?utf-8?B?TWZoMWRjbFc5bjJPN0JNaFJnWkJndVFxR1RHQnBIK1hqcEF0TkdYQk1abTJz?= =?utf-8?B?VDNydlpkbm1rRkc3VnptdVBJMXYwVkVJVWZQWCs4SDVuSElCOHhLQm5RZWRU?= =?utf-8?B?RDlxWnhQdEJoZVo0ZG5nN2NRdjZWN2k5bitwcGw2dmVCdGZ2Q2hyT0tUd05l?= =?utf-8?B?TGx4d2JlRTl5bHUwdkFMRmxOSmkzRTFLRVdFY1BYMlVvYVErRFM0citpQUIw?= =?utf-8?B?cjRvL1JNamNvMDJON2JUV1NVTDZNcUx3VURWSEFnT1h4dFNuakk4dTZoTDMw?= =?utf-8?B?d0RYWTVheDMrTXNwNjhUTno1Mk1GQ0twdlVERk9OMTUydHRRby83Z1dGTjVm?= =?utf-8?B?aXVhT2k0dTB2NEUwZzk2YzdaVWJqcUJlcHNyTDg5djRRcVV2TWZESU4zdUY5?= =?utf-8?B?MGYrMHZCK1IvSko3NXBuamtxWjZZU3RwS0hlbWRZVGREZXNRSW84bE1xb0Jj?= =?utf-8?B?bmVqSmZQM3lWa1I1WlpXOEpBVjNhaUdkbGVITnU2VTVGbEVYSHhsS1dTd3Zm?= =?utf-8?B?S2QrZWtUWk5KdlB1dnZtRjFib2hvUGNIck9jNlVsa1QxaHJweDZ1dUk3aWk5?= =?utf-8?B?cXNnV0xEYThjSjJ3WGNyNFFXc1AvTjQrc09DVUFFeDRqK1RhSy9FTHN5K3pk?= =?utf-8?B?SFI0dnhvVG1DT09QQm9vRVlMWjU2M05SN0pEYmF1UE05aXFwWWd6NktNYTMy?= =?utf-8?B?S05xdnluT2p5ZzJJcllVeUR3SFY5bk9TejN5Wk1VcndCZjAxYVpKc0hXSXRl?= =?utf-8?B?OVFhNWVac3dtWjJLWm92bmxDVWJQd2cyMjBEaVoyZDd4Tjd4OTNSRzBEdC9Z?= =?utf-8?B?TDY0MCtJK0JvSVE0SVVYc3NyZk9LVDZaVUhJV0xvWVpxbWI2ZTM2QnQwblYy?= =?utf-8?B?Vi8vNWVMVUw5LzAwMzV5Nm5hT2dFeG11NTh2VjcydFFtdHV4d3IweTJKZTdB?= =?utf-8?B?TVp0Y2t5R1NwbXRNUUZRNGFSSjFGaTVVejNOa3U1VFdFSkl3Q1c5cjRKanpj?= =?utf-8?B?S3RwKzVuSnJRSk9XTzRiMG9XUmFmMy9GWkpidnNNRkpMQnc0OVVDcnN4N3pO?= =?utf-8?B?VGE0WVgwaUF0ZDdFdmc5V3NqQm1IeFlvWHdRT3NXdXNDUEZ4b09vWnVvdXQx?= =?utf-8?B?bU1Idlg3T2xYMCtObHZMZjBmM1FLWUZ4WTJldEdtTnZWUEVXWVE0UEU1cFJx?= =?utf-8?B?UmgzYXB5VGx5bERrMGZDWjJ1SVpXVlZOTjhRL3diY2J5Q2paeXYrTnJSenpt?= =?utf-8?B?SzR2WWFEdFJ1L3ZsQUpVYUxZUUswTG9teGZtY3Vyb09LNTlyOHJHKzUwRE5V?= =?utf-8?B?ZkxZSlVRTkw3WXMvRDZnQWJON2ZHclZna1l3bWIwVEtMSFhvOEE2L0FhVHE0?= =?utf-8?B?YStteVprbXFIY0ZDUHc0eVJ4Q213OFY2OHo5Y1VuYzNETC9vK0IwS3l2M0lq?= =?utf-8?B?M003MUFad3IrVTBwbytXZUVWZHpRZE5zd2plRkE3dmV1anRSU3JHVDI3UDQv?= =?utf-8?B?Mk1Fa0JteE1zZUdNeWlmK1lzUXE1MDVvaHBwWER2UlByc1loY0ZGc1ZqK3Vo?= =?utf-8?B?OXRHa2V3N1krRU9wc2UvZz09?= x-microsoft-antispam-prvs: x-forefront-prvs: 0968D37274 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(346002)(136003)(39860400002)(366004)(396003)(199004)(189003)(81166006)(4744005)(5660300002)(8936002)(14454004)(7696005)(790700001)(476003)(6116002)(105586002)(11346002)(110136005)(446003)(478600001)(54906003)(14444005)(93886005)(2906002)(106356001)(256004)(486006)(71200400001)(46003)(86362001)(25786009)(71190400001)(102836004)(316002)(186003)(97736004)(55016002)(2501003)(6506007)(229853002)(81156014)(9686003)(6246003)(54896002)(52536013)(7736002)(53936002)(74316002)(6436002)(33656002)(99286004)(76176011)(68736007)(8676002)(4326008)(6306002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB2888; H:BYAPR11MB3638.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: vecXnUaj8sHopHMQDdF0i0R5v2e1z+fq6wsavG7+BekFWZbbu4r99PzuIeOA5EV/X7IqsbMiXDQ41QFJ9wLB1LjvgcQ2NCU4RCacy53/2PL6oz/eEdAlkxFSpWGqUpFaOBfK6grMvVt6agMfzB5nRPdpi5+zgtjxAl3vSsQlvZSOi4gioVQtH1Yw+m/Ou32sWGrNO/ZmpobXBY3z408i/Jb6PLsPsZb0SX4jBLd4KVmpFpjf8eOsdFcKgshmRPmu5uw90s/VNqaMXhE/+fdycyo/0iJiafVJK/haH7E3HsoxJIxzNmxm1xmdbutLz6Ng61GJBzKVHsqigYkr4W8+UWrf0idzmtedrMmCLmjXsiMDsmpf09X4Tetydgt6B5g0KI+IQofDm/cs8yp8bEl0vqW2f/4bCr5orzar/Exi/+c= Content-Type: multipart/alternative; boundary="_000_BYAPR11MB36389C97FEB934EEC932A81EC1730BYAPR11MB3638namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 6a257bb1-a149-4cba-2678-08d6a261b658 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Mar 2019 18:29:47.2400 (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-Transport-CrossTenantHeadersStamped: BYAPR11MB2888 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.16, xch-aln-006.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [Lsr] Multiple failures in Dynamic Flooding X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Mar 2019 18:29:55 -0000 --_000_BYAPR11MB36389C97FEB934EEC932A81EC1730BYAPR11MB3638namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpJdCB0YWtlcyB0b28gbG9uZyB3aGVuIEhlbGxvIHBhY2tldCBpcyBsb3N0LiBSZXBhaXJpbmcg c3BsaXQgZmxvb2RpbmcgdG9wb2xvZ3kgbmVlZHMgdG8gYmUgZmFzdC4NCg0KDQpGb3J0dW5hdGVs eSwgbG9zdCBoZWxsbyBwYWNrZXRzIGFyZSBhIHJlbGF0aXZlbHkgcmFyZSBvY2N1cnJlbmNlLiAg V2hpbGUgcmVwYWlyaW5nIHRoZSBmbG9vZGluZyB0b3BvbG9neSBuZWVkcyB0byBiZSBkb25lIGV4 cGVkaWVudGx5LCBhdHRlbXB0aW5nIHRvIGRvIHNvIGFuZCB0cmlnZ2VyaW5nIGEgY2FzY2FkZSBm YWlsdXJlIG9mIHRoZSBuZXR3b3JrIGlzIGNvdW50ZXItcHJvZHVjdGl2ZS4gR2l2ZW4gdGhpcyBh bHRlcm5hdGl2ZSwgYSBiaXQgb2YgZXh0cmEgZGVsYXkgd2hlbiBhZGRpbmcgYSBuZXcgc3lzdGVt IHRvIHRoZSBuZXR3b3JrLCBvciB0cnlpbmcgdG8gcmVjb3ZlciBmcm9tIG11bHRpcGxlIGZhaWx1 cmVzIHNlZW1zIHdpc2UuIFJ1c2hpbmcgYW5kIG1ha2luZyB0aGluZ3Mgd29yc2UgZG9lcyBub3Qu ICBUaGUgZmlyc3QNCnByaW9yaXR5IG11c3QgcmVtYWluIG5ldHdvcmsgc3RhYmlsaXR5Lg0KDQoN Cg0KW0xlczpdIEp1c3QgdG8gcHV0IHRoaXMgbWlub3IgaXNzdWUgdG8gcmVzdOKApg0KSXQgd291 bGQgYWxzbyBiZSBwb3NzaWJsZSBmb3IgdGhlIG5vZGUgbWFraW5nIHRoZSB0ZW1wb3JhcnkgZmxv b2RpbmcgcmVxdWVzdCB0byBzZW5kIGhlbGxvcyBhdCBhIGZhc3RlciByYXRlIChzYXkgb25jZSBh IHNlY29uZCByYXRoZXIgdGhhbiBvbmNlIGV2ZXJ5IDEwIHNlY29uZHMpIHVudGlsIGl0IHNlZXMg dGhhdCB0aGUgbmVpZ2hib3IgaXMgc2VuZGluZyBMU1AvU05QIHVwZGF0ZXMuDQpUaGlzIGp1c3Qg aXNu4oCZdCBhIHNpZ25pZmljYW50IGlzc3VlLg0KDQogICBMZXMNCg0KDQo= --_000_BYAPR11MB36389C97FEB934EEC932A81EC1730BYAPR11MB3638namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uYXBwbGUtY29udmVy dGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFu LkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZh bWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZh dWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0K QHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAx LjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24x O30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRz IHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1h cCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRp Zl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4m bmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JdCB0YWtl cyB0b28gbG9uZyB3aGVuIEhlbGxvIHBhY2tldCBpcyBsb3N0LiBSZXBhaXJpbmcgc3BsaXQgZmxv b2RpbmcgdG9wb2xvZ3kgbmVlZHMgdG8gYmUgZmFzdC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Gb3J0dW5hdGVseSwgbG9zdCBoZWxsbyBw YWNrZXRzIGFyZSBhIHJlbGF0aXZlbHkgcmFyZSBvY2N1cnJlbmNlLiAmbmJzcDtXaGlsZSByZXBh aXJpbmcgdGhlIGZsb29kaW5nIHRvcG9sb2d5IG5lZWRzIHRvIGJlIGRvbmUgZXhwZWRpZW50bHks IGF0dGVtcHRpbmcgdG8gZG8gc28gYW5kIHRyaWdnZXJpbmcgYSBjYXNjYWRlIGZhaWx1cmUgb2Yg dGhlIG5ldHdvcmsgaXMgY291bnRlci1wcm9kdWN0aXZlLiBHaXZlbiB0aGlzDQogYWx0ZXJuYXRp dmUsIGEgYml0IG9mIGV4dHJhIGRlbGF5IHdoZW4gYWRkaW5nIGEgbmV3IHN5c3RlbSB0byB0aGUg bmV0d29yaywgb3IgdHJ5aW5nIHRvIHJlY292ZXIgZnJvbSBtdWx0aXBsZSBmYWlsdXJlcyBzZWVt cyB3aXNlLiBSdXNoaW5nIGFuZCBtYWtpbmcgdGhpbmdzIHdvcnNlIGRvZXMgbm90LiAmbmJzcDtU aGUgZmlyc3Q8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPnByaW9yaXR5IG11c3QgcmVtYWluIG5ldHdvcmsgc3RhYmlsaXR5LjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPltMZXM6XSBKdXN0IHRvIHB1dCB0aGlzIG1pbm9yIGlzc3VlIHRvIHJlc3TigKY8bzpw PjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JdCB3b3VsZCBhbHNvIGJlIHBvc3NpYmxlIGZv ciB0aGUgbm9kZSBtYWtpbmcgdGhlIHRlbXBvcmFyeSBmbG9vZGluZyByZXF1ZXN0IHRvIHNlbmQg aGVsbG9zIGF0IGEgZmFzdGVyIHJhdGUgKHNheSBvbmNlIGEgc2Vjb25kIHJhdGhlciB0aGFuIG9u Y2UgZXZlcnkgMTANCiBzZWNvbmRzKSB1bnRpbCBpdCBzZWVzIHRoYXQgdGhlIG5laWdoYm9yIGlz IHNlbmRpbmcgTFNQL1NOUCB1cGRhdGVzLjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PlRoaXMganVzdCBpc27igJl0IGEgc2lnbmlmaWNhbnQgaXNzdWUuPG86cD48L286cD48L3NwYW4+ PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7Jm5ic3A7IExlczxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BYAPR11MB36389C97FEB934EEC932A81EC1730BYAPR11MB3638namp_-- From nobody Wed Mar 6 19:47:20 2019 Return-Path: X-Original-To: lsr@ietf.org Delivered-To: lsr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 86294130DF6; Wed, 6 Mar 2019 19:47:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lsr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lsr@ietf.org Message-ID: <155193043045.13773.12362890575197811183@ietfa.amsl.com> Date: Wed, 06 Mar 2019 19:47:10 -0800 Archived-At: Subject: [Lsr] I-D Action: draft-ietf-ospf-sr-yang-06.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 03:47:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Link State Routing WG of the IETF. Title : YANG Data Model for OSPF SR (Segment Routing) Protocol Authors : Derek Yeung Yingzhen Qu Jeffrey Zhang Ing-Wher Chen Acee Lindem Filename : draft-ietf-ospf-sr-yang-06.txt Pages : 25 Date : 2019-03-06 Abstract: This document defines a YANG data model that can be used to configure and manage OSPF Segment Routing. The model is based on YANG 1.1 as defined in RFC 7950 and conforms to the Network Management Datastore Architecture (NDMA) as described in RFC 8342. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ospf-sr-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ospf-sr-yang-06 https://datatracker.ietf.org/doc/html/draft-ietf-ospf-sr-yang-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-sr-yang-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Mar 6 23:13:04 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72AA0130E64; Wed, 6 Mar 2019 23:13:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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=EC0qixHv; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=L823FoO/ 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 OYlWCSSMcXDR; Wed, 6 Mar 2019 23:12:59 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76FAE129532; Wed, 6 Mar 2019 23:12:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2776; q=dns/txt; s=iport; t=1551942779; x=1553152379; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=zNrRnaYW9jSq1ZywPyhxQHoV4jpfyorjUfkmyTa1P80=; b=EC0qixHvHua6Pp4TvS9+/MVyI+Q3P+opCBu0Qel3HXrcs7LiWjvbG6JV H2w1Htxqu1tHEGWZbjhvRBICqHT5gv1J7O8yPzzF6afu2UMNs3Rt/tvzg hGTIxo6Pq+9nxFneIEgUvCGEUgkToq1A4Sgb6JDaYTMV891l1TWaiiMSV 4=; IronPort-PHdr: =?us-ascii?q?9a23=3AkCJgphw1lhuUZGLXCy+N+z0EezQntrPoPwUc9p?= =?us-ascii?q?sgjfdUf7+++4j5YR2N/u1j2VnOW4iTq+lJjebbqejBYSQB+t7A1RJKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZuGBFHyKuLCZC0hF8MEX1hgrDm2?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ANAAA2w4Bc/5RdJa1kGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBUQYBAQELAYE8UANodAQLJ4QJg0cDhFCLAYJXmCOBJANUCwEBJQe?= =?us-ascii?q?EQAIXhBsiNAkNAQEDAQEHAQMCbRwBC4VKAQEBBCMRDAEBNQIBCwQCAQgRBAE?= =?us-ascii?q?BAwImAgICMBUGAQEFAwIEDgUIgxuBXQMVAQIMn0gCihRxgS+CeAEBBYE0Ag5?= =?us-ascii?q?BgwAYggsIgQskAYRZhk8XgUA/gRBHgkyDHgEBAgEBgV8kgmQxgiaMSIQkkyc?= =?us-ascii?q?JAodKi1GBdliFDotWinCFX4xXAgQCBAUCDQEBBYFHOIFWcBUagw0JggGDboU?= =?us-ascii?q?UhT9yAYEnjGkBAQ?= X-IronPort-AV: E=Sophos;i="5.58,450,1544486400"; d="scan'208";a="520509981" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Mar 2019 07:12:58 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id x277CwEc011874 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 Mar 2019 07:12:58 GMT Received: from xhs-rcd-003.cisco.com (173.37.227.248) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 7 Mar 2019 01:12:57 -0600 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 7 Mar 2019 01:12:57 -0600 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.1473.3 via Frontend Transport; Thu, 7 Mar 2019 01:12:56 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=zNrRnaYW9jSq1ZywPyhxQHoV4jpfyorjUfkmyTa1P80=; b=L823FoO/AATb1U1nB5lBifFJOj9UaX5XHzZtr+A2FDOs5QSjpYJ69FDFp0Q4DDikR77V38At/3EvaCmnhg19aqPwjYSdCs7F80ACAx9dFfQP/tpex5FRhsp5872l7xy5lp6phkWTzXpXi5ZhKfW57AmCdDYPKIIVhJG0+I+IbuU= Received: from SN6PR11MB2845.namprd11.prod.outlook.com (52.135.93.24) by SN6PR11MB2544.namprd11.prod.outlook.com (52.135.90.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.19; Thu, 7 Mar 2019 07:12:55 +0000 Received: from SN6PR11MB2845.namprd11.prod.outlook.com ([fe80::117:6d33:4c0a:a1b3]) by SN6PR11MB2845.namprd11.prod.outlook.com ([fe80::117:6d33:4c0a:a1b3%3]) with mapi id 15.20.1686.018; Thu, 7 Mar 2019 07:12:55 +0000 From: "Ketan Talaulikar (ketant)" To: "lsr@ietf.org" CC: "rtg-bfd@ietf.org" Thread-Topic: New Version Notification for draft-ketant-lsr-ospf-bfd-strict-mode-00.txt Thread-Index: AQHU0rhpLl0dtsmMoUOhqgxpizBSpqX/w8WA Date: Thu, 7 Mar 2019 07:12:55 +0000 Message-ID: References: <155172422932.5160.17457672863936228363.idtracker@ietfa.amsl.com> In-Reply-To: <155172422932.5160.17457672863936228363.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ketant@cisco.com; x-originating-ip: [2001:420:c0e0:1007::4e6] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: d42dbc51-45e3-4501-314d-08d6a2cc525a x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:SN6PR11MB2544; x-ms-traffictypediagnostic: SN6PR11MB2544: x-ms-exchange-purlcount: 4 x-microsoft-exchange-diagnostics: =?utf-8?B?MTtTTjZQUjExTUIyNTQ0OzIzOjUwUFR6YW9EeWM1V0JrZS9UR0RwZjFEbk5z?= =?utf-8?B?U1pRRm0vYXNyM3B5QTVJelVadHYwcFJWczdib2VvM3I0c0NINkZqd1BCcXpO?= =?utf-8?B?azdPMFo5TmxkclVtaVk5SGgra01PQVhzWmJrZnM0OUxsQVFydGNVM1VKU3Vs?= =?utf-8?B?WDBuZ3Z4c3EvbTcxN2FiYkU0N3lHSStZcnNoQjBlZHBpeStuU1lWV3hMVzA3?= =?utf-8?B?OGhrYXJyTGQvRXNMNVVMQXpvc3pkNXR5VzV3bllSNkdQSUgrcThybERRN3VW?= =?utf-8?B?UU1QdDN5T0JSVlNjUWVUalJST2EvSzhONkg0RkZWdURDcFBRck00OWlNWDU4?= =?utf-8?B?M1pZV1l3NUl4YytUYjBWbmR0NmVFbmlMNGJ2RXhqNTBRbUhWSklFbytxRVor?= =?utf-8?B?aWVrNTFJYUR6amhRYlAzV2tTa0tqUGxkaDI3YjVqVzlCaDd3cWttV0laTmhI?= =?utf-8?B?QmdtbHhUVlRkVnRjeDFPNStxZFVoMU02aGgvQTRmbjloSG9sZHBTYTVSVHBz?= =?utf-8?B?NzAra2ZTUUw5bWtWTmIwcEptbzhpTUVPNWhYQzFsN2s2N2JBMWRkNVdxQzY3?= =?utf-8?B?dHdRbTM4dnVna2Z6NkRVQ0oxbmlwR1FYNEtTMVR3MjkydjV1dHplbS9QVGlw?= =?utf-8?B?QUp3aytJM01uZjIxMnhXZ1BXdnl2RWNwUWt2UXZBL2Yrc2p2cGYyZGN0cmNq?= =?utf-8?B?ekxoK2lSbWttWFdQQVhwVmNtOG0weGNGV1djclcvd1JCUVZqbGlxbFdZY3Z6?= =?utf-8?B?bTJvMkszaGdya3dqOTd1cjI5UzU5TDRSMURnWFB1ZWExc1pOWkNZdDErRld3?= =?utf-8?B?UUxXdk5LZjJ0T3FuRGcrc3hsczd5UEVDblMybVBlQk1WU0J1cmRoTmJmT1dG?= =?utf-8?B?SHViRTFpdWUrdENnNC9ZYTU4VGFpZmdlQ2ZKSit3RmRpZGM3WlhuR1ZkMUZv?= =?utf-8?B?R2xqaVRaWTlXMEFDNmFXR2hsakFoR3ozZGxUMHlsNXBFVDFoa3NCanpGNmpo?= =?utf-8?B?M2o0dHEvZUh0M0lEZ2d6aGl3VVROY0xEZHJqRFNhMGZuWEQzZHRCVFhUeUtv?= =?utf-8?B?eGR3UTlDM0hzZ1V3YXBmeFZFSDE0QWtHTy94TFovRjJ3MGpNNEh0VGdVSXF5?= =?utf-8?B?eVZNdnJBS0hFZ0duVUlVbzdoVTJzc1M5RjdNZ2dMdW1rMU1DbzZ1d2JwSk0w?= =?utf-8?B?b1Jxd25BdXAvcVpMZ2ZwUDh6T29xTm4rbC9ReGxxQmJCbWRSV2JuMld6bU80?= =?utf-8?B?c3g2NUFqZWcxdjcreGIvOERWdUxNeEpVS1oycUw2cDFqUWIyVVpSb1hjbGlP?= =?utf-8?B?K2pRZk1qVWlOdUlPVjBDSXU2cEFZVFV2TVdPWWgzM0IzUDhaNnJoa3FpYkpw?= =?utf-8?B?b0RIRTVjQXVuVW1tYWp6aStOZW1RSG9XREF0OUJXdnZZenYveHA2SWZwMGhZ?= =?utf-8?B?K0VKbjdiQ3RaMkhVS0M3dVJtbC8rcVkxekJuU2g0N0tvQ3V2ZUx6MTNrTkJX?= =?utf-8?B?SXo3UW1OVklrbGdCenhLRzA5VEJzelJHR3lrc0QzYStaL0tRN1paZDNBNHJX?= =?utf-8?B?dVlDcmk2N1hLajUwc2pwY2NXQmJYTDhMS3p0WEZsSHM2M1VMQ3JRZE0zNnZN?= =?utf-8?B?eEttUERHQUZORUloSi9HS05FTy9sU2IzSUIvMndkMC9udEE5UE1KUTYzRmVq?= =?utf-8?B?akdYUDFSRVZReUYyU1NiMjRsTDFkQTUwZDFndHgrZUpVeXZaY2FZR0J1YUVH?= =?utf-8?B?VmVscVBncFJZd1dmQXEyTUc2K041YW9LbDk1UnVhcWFzOFloYlQ1MEk5SjNF?= =?utf-8?B?TkE1WUllUm13ZXI2ZHg5N2ZOVWpMcTlsS2FLUEZmM0E0MkRxMzd1QXg3Sk5R?= =?utf-8?B?aDZvTlY3OGpBQk5aaVpsdFo1VGVyWE16T3ByaWRTQVppZTcyYU1nZlNLVlox?= =?utf-8?B?MTF4cmxoOWdRPT0=?= x-microsoft-antispam-prvs: x-forefront-prvs: 096943F07A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(396003)(366004)(39860400002)(346002)(136003)(189003)(53754006)(199004)(13464003)(6436002)(446003)(966005)(2906002)(5640700003)(55016002)(97736004)(476003)(2473003)(33656002)(316002)(14454004)(25786009)(2501003)(9686003)(6306002)(11346002)(256004)(14444005)(53936002)(186003)(68736007)(15650500001)(6506007)(71190400001)(52536013)(5660300002)(7696005)(450100002)(8936002)(305945005)(6916009)(46003)(86362001)(81156014)(478600001)(71200400001)(76176011)(53546011)(81166006)(229853002)(7736002)(8676002)(102836004)(99286004)(486006)(1730700003)(105586002)(6116002)(2351001)(106356001)(4326008)(74316002)(66574012); DIR:OUT; SFP:1101; SCL:1; SRVR:SN6PR11MB2544; H:SN6PR11MB2845.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: ku8OIi6rEH3tc1DF/NF3+RQb1kHGKlt625P2gQ5xZAKJvQGYFngrVbgU+LlkNfMx8HBmKLRvJ45a/2pLLvnSWuR4CmdEjIJmg9d/rB1Xf7MmmXgbIQFNz0ATS/DGAq8QNZ7a8ERTBDKJtPeLwl4m1MNaY0PjF3VGpnb6S0SV1Rh8XGc7+oiQZ24jrHqVNfI7UzQNs4ZEWYjY3laqrP1CV7YFfe7aowUqnmRAaYkfV++rIeU9FmvvGbyz17EcnSBFw19S8zoWp57itrfJDzJr7pAB7kX3WfPMgwiCMGXQRcPb8PiNIaWPb8PtKaY4Xfsw9RrmAjxnrlJnSrgWvsHK5Ryp9GJKdl/QhcI2ZbgTl4qVtb2Jct/AShKle5ysfIJMG5HLpUB1jLek3U4LjUhs7CndNBf1ry2tAWfgeNYhmYI= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: d42dbc51-45e3-4501-314d-08d6a2cc525a X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Mar 2019 07:12:55.7253 (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-Transport-CrossTenantHeadersStamped: SN6PR11MB2544 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.24, xch-aln-014.cisco.com X-Outbound-Node: rcdn-core-12.cisco.com Archived-At: Subject: [Lsr] FW: New Version Notification for draft-ketant-lsr-ospf-bfd-strict-mode-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 07:13:02 -0000 SGVsbG8gQWxsLA0KDQpXZSd2ZSBwb3N0ZWQgYSBkcmFmdCBmb3IgQkZEIG9wZXJhdGlvbnMgZm9y IE9TUEYuIFdvdWxkIGFwcHJlY2lhdGUgcmV2aWV3IGFuZCBmZWVkYmFjayBmcm9tIHRoZSBMU1Ig YW5kIEJGRCBXR3MuDQoNCnJmYzYyMTMgYWRkcmVzc2VzIHNpbWlsYXIgcHJvYmxlbSBmb3IgSVMt SVMuDQoNClRoYW5rcywNCktldGFuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9t OiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgPGludGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4gDQpT ZW50OiAwNSBNYXJjaCAyMDE5IDAwOjAwDQpUbzogUGV0ZXIgUHNlbmFrIChwcHNlbmFrKSA8cHBz ZW5ha0BjaXNjby5jb20+OyBLZXRhbiBUYWxhdWxpa2FyIChrZXRhbnQpIDxrZXRhbnRAY2lzY28u Y29tPg0KU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1rZXRhbnQt bHNyLW9zcGYtYmZkLXN0cmljdC1tb2RlLTAwLnR4dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1E LCBkcmFmdC1rZXRhbnQtbHNyLW9zcGYtYmZkLXN0cmljdC1tb2RlLTAwLnR4dA0KaGFzIGJlZW4g c3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBLZXRhbiBUYWxhdWxpa2FyIGFuZCBwb3N0ZWQgdG8g dGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJCWRyYWZ0LWtldGFudC1sc3Itb3NwZi1iZmQt c3RyaWN0LW1vZGUNClJldmlzaW9uOgkwMA0KVGl0bGU6CQlPU1BGIEJGRCBTdHJpY3QtTW9kZQ0K RG9jdW1lbnQgZGF0ZToJMjAxOS0wMy0wNA0KR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24N ClBhZ2VzOgkJNw0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC1rZXRhbnQtbHNyLW9zcGYtYmZkLXN0cmljdC1tb2RlLTAwLnR4dA0KU3Rh dHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWtldGFu dC1sc3Itb3NwZi1iZmQtc3RyaWN0LW1vZGUvDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWtldGFudC1sc3Itb3NwZi1iZmQtc3RyaWN0LW1vZGUtMDAN Ckh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2Ry YWZ0LWtldGFudC1sc3Itb3NwZi1iZmQtc3RyaWN0LW1vZGUNCg0KDQpBYnN0cmFjdDoNCiAgIFRo aXMgZG9jdW1lbnQgc3BlY2lmaWVzIHRoZSBleHRlbnNpb25zIHRvIE9TUEYgdGhhdCBlbmFibGVz IGEgcm91dGVyDQogICBhbmQgaXRzIG5laWdoYm9yIHRvIHNpZ25hbCB0aGVpciBpbnRlbnRpb24g dG8gdXNlIEJpZGlyZWN0aW9uYWwNCiAgIEZvcndhcmRpbmcgRGV0ZWN0aW9uIChCRkQpIGZvciB0 aGVpciBhZGphY2VuY3kgdXNpbmcgbGluay1sb2NhbA0KICAgYWR2ZXJ0aXNlbWVudCBiZXR3ZWVu IHRoZW0uICBUaGUgc2lnbmFsaW5nIG9mIHRoaXMgQkZEIGVuYWJsZW1lbnQsDQogICBhbGxvd3Mg dGhlIHJvdXRlciB0byBibG9jayBhbmQgbm90IGFsbG93IHRoZSBlc3RhYmxpc2htZW50IG9mDQog ICBhZGphY2VuY3kgd2l0aCBpdHMgbmVpZ2hib3Igcm91dGVyIHVudGlsIGEgQkZEIHNlc3Npb24g aXMNCiAgIHN1Y2Nlc3NmdWxseSBlc3RhYmxpc2hlZCBiZXR3ZWVuIHRoZW0uICBUaGUgZG9jdW1l bnQgZGVzY3JpYmVzIHRoaXMNCiAgICJzdHJpY3QtbW9kZSIgb2YgQkZEIGVzdGFibGlzaG1lbnQg YXMgYSBwcmVyZXF1aXNpdGUgdG8gT1NQRg0KICAgYWRqYWNlbmN5IGZvcm1hdGlvbi4NCg0KDQog ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFr ZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0 aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYu b3JnLg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQo= From nobody Thu Mar 7 00:16:56 2019 Return-Path: X-Original-To: lsr@ietf.org Delivered-To: lsr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 09EF2130ED0; Thu, 7 Mar 2019 00:16:49 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lsr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lsr@ietf.org Message-ID: <155194660899.16015.14805787259987949002@ietfa.amsl.com> Date: Thu, 07 Mar 2019 00:16:49 -0800 Archived-At: Subject: [Lsr] I-D Action: draft-ietf-ospf-sr-yang-07.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 08:16:49 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Link State Routing WG of the IETF. Title : YANG Data Model for OSPF SR (Segment Routing) Protocol Authors : Derek Yeung Yingzhen Qu Jeffrey Zhang Ing-Wher Chen Acee Lindem Filename : draft-ietf-ospf-sr-yang-07.txt Pages : 25 Date : 2019-03-07 Abstract: This document defines a YANG data model that can be used to configure and manage OSPF Segment Routing. The model is based on YANG 1.1 as defined in RFC 7950 and conforms to the Network Management Datastore Architecture (NDMA) as described in RFC 8342. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ospf-sr-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-ospf-sr-yang-07 https://datatracker.ietf.org/doc/html/draft-ietf-ospf-sr-yang-07 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ospf-sr-yang-07 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 Thu Mar 7 02:59:49 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13A6A13131B for ; Thu, 7 Mar 2019 02:59:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.899 X-Spam-Level: X-Spam-Status: No, score=-2.899 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=tecnico.ulisboa.pt 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 JCJmVw5HHeb3 for ; Thu, 7 Mar 2019 02:59:45 -0800 (PST) Received: from smtp1.tecnico.ulisboa.pt (smtp1.tecnico.ulisboa.pt [193.136.128.21]) (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 C69A4130F67 for ; Thu, 7 Mar 2019 02:59:43 -0800 (PST) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp1.tecnico.ulisboa.pt (Postfix) with ESMTP id 202116344800 for ; Thu, 7 Mar 2019 10:59:41 +0000 (WET) X-Virus-Scanned: by amavisd-new-2.10.1 (20141025) (Debian) at tecnico.ulisboa.pt Received: from smtp1.tecnico.ulisboa.pt ([127.0.0.1]) by localhost (smtp1.tecnico.ulisboa.pt [127.0.0.1]) (amavisd-new, port 10025) with LMTP id Bijbtq9WmiiS for ; Thu, 7 Mar 2019 10:59:38 +0000 (WET) Received: from mail3.ist.utl.pt (mail1.ist.utl.pt [193.136.128.10]) by smtp1.tecnico.ulisboa.pt (Postfix) with ESMTP id B2A0A6344803 for ; Thu, 7 Mar 2019 10:59:38 +0000 (WET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=tecnico.ulisboa.pt; s=mail; t=1551956378; bh=J4VDmY6JSW7ojO2QpKrqX8V1+iMuhrlmqrZqrsBvvXo=; h=From:To:Subject:Date; b=ZRCErc248wkt/d5dJe52ixmhNCXOV6MBAibrd+ooDUyw3BMvrMC1Gl77NMQogah+8 ul8B8XULH9V3QyviOaAgdxbfiyVHJSYY3Kg8UcWSDw245nl3MNCxkzauTQuuL+0eny tyC09xtGeFTvZR11rFzu5EuLrxoYKkvKQ+ZEp1QA= Received: from DESKTOP5DMHTT4 (unknown [193.136.221.211]) (Authenticated sender: ist126537) by mail3.ist.utl.pt (Postfix) with ESMTPSA id A09DC804946C for ; Thu, 7 Mar 2019 10:59:38 +0000 (WET) From: To: Date: Thu, 7 Mar 2019 10:59:38 -0000 Message-ID: <004101d4d4d4$db983e50$92c8baf0$@tecnico.ulisboa.pt> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0042_01D4D4D4.DB988C70" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AdTU1GVyWYcK1jL6RMmeGX80O/iepQ== Archived-At: Subject: [Lsr] book on OSPF and IS-IS X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 10:59:48 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0042_01D4D4D4.DB988C70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear all, Sorry to slightly disrupt the flow of discussions. I would like to raise your attention to my recent book on OSPF and IS-IS: https://www.crcpress.com/OSPF-and-IS-IS-From-Link-State-Routing-Principles-t o-Technologies/Valadas/p/book/9781138504554. The book presents a unified view on OSPF and IS-IS, by addressing the principles of LSR, which I believe is very much within the spirit of this group. Best regards. Rui Valadas ------=_NextPart_000_0042_01D4D4D4.DB988C70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear all,

 

Sorry to = slightly disrupt the flow of discussions.

 

I would like = to raise your attention to my recent book on OSPF and IS-IS: https://www.crcpr= ess.com/OSPF-and-IS-IS-From-Link-State-Routing-Principles-to-Technologies= /Valadas/p/book/9781138504554.

 

The book = presents a unified view on OSPF and IS-IS, by addressing the principles = of LSR, which I believe is very much within the spirit of this = group.

 

Best regards.

 

Rui = Valadas

------=_NextPart_000_0042_01D4D4D4.DB988C70-- From nobody Thu Mar 7 03:01:17 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69F8A130F67 for ; Thu, 7 Mar 2019 03:01:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net 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 MTiLMUJJwuHo for ; Thu, 7 Mar 2019 03:01:08 -0800 (PST) Received: from mail-qt1-x82d.google.com (mail-qt1-x82d.google.com [IPv6:2607:f8b0:4864:20::82d]) (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 75E3C13131B for ; Thu, 7 Mar 2019 03:01:08 -0800 (PST) Received: by mail-qt1-x82d.google.com with SMTP id a48so16512760qtb.4 for ; Thu, 07 Mar 2019 03:01:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:from:date:message-id:subject:to; bh=u1hhN2TgddDp/ywDasHLCoBFYutp4Xw2x4n6R1KRNaY=; b=b5+i/DrkG2taLb6zCChZEhvrVwdRa0727ond7553zBIjowob4HFEBBtwxdJMb96ReT mpRIi73pp09z++paE0hcKuccBPMTAOI99qqWTMN1BtaRRIiIOdft9tDIocQaQxmZe5ic 9/+F/3QL89JstVH9z8ntZZHDzjN6LziwGJkoFvF6YjryYll3HByxaixvNPTP4F1xOsiS ePpHYvWtqGhrApRUfJxjlyv1OWQ3hFGQhQokEIsjYO9cKqpkJxPykBo+4S04OCo7VAnZ MIKC10x69cxWFAU3xYv/rwUiDmAXue08RxYzHoRwbIHSv/to2YQnUtiBZumtymnVfCJV 5Xyg== 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; bh=u1hhN2TgddDp/ywDasHLCoBFYutp4Xw2x4n6R1KRNaY=; b=sWXyice4so0QRaI4hLh7KYEh8M9G0jfcj7eUTLUg6jFXHIE0vobz6fNK0Tgd05++mZ B3SDaLhsMAAQYKAWgtIibbqkcpNxeL/u8NgDC8dHHDrAgRotS1d4R889xU0ZPTg2Llt8 ovcXq7Uyqzk5qc1QKGkCPSN/XRvBZG/xx1BKS9hHnXhnO+iLYuMabzc/oaesf4juHLfe wHLYQaoPTjcHiNLRX3rdnoQ5CCurbsETc/e6+9PjEr+cgAnTRutmz8l6y3j+WsVq0V3w wlSDcqhBzLXrK1wHsGHMgWzzQOg7StzlGxyKckvuam3YGfHagdt6hSmrHQz8862yxn6m ubIQ== X-Gm-Message-State: APjAAAXRcN+bA6hDccqFu86jwfndM3c00ZFsZbbkLacdGjNaiFh3I45e q/IHg/CyK412+v0k0HK2YN7ojlXEC7KLylWdc7g2XaluliU= X-Google-Smtp-Source: APXvYqxuRuRiq1pHlpVyi85WQlAIkYo+jCnx2wK/asxQjhfRpSKXbMMCYBrZW58D2QcfdmvwXIdorsJhdnDO89TEclM= X-Received: by 2002:a0c:99e2:: with SMTP id y34mr10249542qve.18.1551956467191; Thu, 07 Mar 2019 03:01:07 -0800 (PST) MIME-Version: 1.0 From: Robert Raszuk Date: Thu, 7 Mar 2019 12:00:57 +0100 Message-ID: To: lsr@ietf.org Content-Type: multipart/alternative; boundary="000000000000ef245d05837f0515" Archived-At: Subject: [Lsr] Clarification on co-existance of dynamic flooding aware and not aware nodes X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 11:01:15 -0000 --000000000000ef245d05837f0515 Content-Type: text/plain; charset="UTF-8" Hi, My reading of draft-ietf-lsr-dynamic-flooding indicates that said document in number of places rather assumes that entire topology (entire instance) supports dynamic flooding (perhaps other then bootstrap phase). Let's observe that there can be lots of L3 TORs only dual attached to access routers which will not benefit at all to be part of the game. Moreover those TORs may be from different vendors and could support link state protocols without any dynamic flooding extensions. So the question is if the proposal considers a case where only part of the fabric in single topology, single area/level, single LSDB etc. is aware about dynamic flooding protocol extensions ? Let's also observe that In any deployment such state when some nodes are enabled and some not for dynamic flooding can happen during migrating phase or operator's errors which one would assumed must be handled correctly by the protocol. Many thx, R. --000000000000ef245d05837f0515 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

My reading of draf= t-ietf-lsr-dynamic-flooding indicates that said document in number of place= s rather assumes that entire topology (entire instance) supports dynamic fl= ooding (perhaps other then bootstrap phase).=C2=A0

Let's observe that there can be lots of L3 TORs only dual attached to = access routers which will not benefit at all to be part of the game. Moreov= er those TORs may be from different vendors and could support link state pr= otocols without any dynamic flooding extensions.=C2=A0

=
So the question is if the proposal considers a case where only part of= the fabric in single topology, single area/level, single LSDB etc. is awar= e about dynamic flooding protocol extensions ?=C2=A0

Let's also observe that In any deployment such state when some nodes= are enabled and some not for dynamic flooding can happen during migrating = phase or operator's errors which one would assumed must be handled corr= ectly by the protocol.=C2=A0

Many thx,
R= .
--000000000000ef245d05837f0515-- From nobody Thu Mar 7 03:11:38 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F41A131312 for ; Thu, 7 Mar 2019 03:11:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 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 qV9HyjX-YcCZ for ; Thu, 7 Mar 2019 03:11:35 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B579130F67 for ; Thu, 7 Mar 2019 03:11:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1576; q=dns/txt; s=iport; t=1551957094; x=1553166694; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=mB5Dlsay46me6vBEbjcmd4kuJCS2NJltGfUXRX3nynI=; b=Con9pb2/FS141AWy0OATjT088fP/dcc9V48dozuneU1SZVrrw+S7r61v KQXbWFAjy3NVsjFKg+4Bj92J16o+n+OSmpMeSDIhciSNAjHgXVnjSf0xF 7PhFtqJ46jHeITIc5rSvl4s72ywmJIANqvRvQCx7NHeVkniM5ofQh5pfR 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJAABL+4Bc/xbLJq1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUgQBAQEBCwEBgnZxEieNAowyJZgjFIFnDRgLhEkChFc1CA0?= =?us-ascii?q?BAQMBAQcBAwJtHAxCAQ4BhHgBAQEBAgEBATY2GwsYFRknMAYBDAYCAQGDHgG?= =?us-ascii?q?BbQgPq3iFRIRjBYEvAYtCgUA/gREnDIIxLoMeAQGBHIEEhSICihWHIpJeCZJ?= =?us-ascii?q?/BhmLAIg1inGSX4FJATWBVjMaCBsVO4JsghYXE4hMhUA+AzCCIYtwAQE?= X-IronPort-AV: E=Sophos;i="5.58,451,1544486400"; d="scan'208";a="10598936" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 07 Mar 2019 11:11:32 +0000 Received: from [10.147.24.27] ([10.147.24.27]) by aer-core-4.cisco.com (8.15.2/8.15.2) with ESMTP id x27BBWJo018373; Thu, 7 Mar 2019 11:11:32 GMT To: Robert Raszuk , lsr@ietf.org References: From: Peter Psenak Message-ID: Date: Thu, 7 Mar 2019 12:11:31 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Outbound-SMTP-Client: 10.147.24.27, [10.147.24.27] X-Outbound-Node: aer-core-4.cisco.com Archived-At: Subject: Re: [Lsr] Clarification on co-existance of dynamic flooding aware and not aware nodes X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 11:11:37 -0000 Hi Robert, On 07/03/2019 12:00 , Robert Raszuk wrote: > Hi, > > My reading of draft-ietf-lsr-dynamic-flooding indicates that said > document in number of places rather assumes that entire topology (entire > instance) supports dynamic flooding (perhaps other then bootstrap phase). > > Let's observe that there can be lots of L3 TORs only dual attached to > access routers which will not benefit at all to be part of the game. > Moreover those TORs may be from different vendors and could support link > state protocols without any dynamic flooding extensions. > > So the question is if the proposal considers a case where only part of > the fabric in single topology, single area/level, single LSDB etc. is > aware about dynamic flooding protocol extensions ? sure, see section 5.1.2. If the node does not participate in dynamic flooding, it will use standard flooding mechanism. This means that the flooding may be less optimal, but nothing would break. If you wan to be extra smart, your algorithm can even take the node participation into account and compute the flooding topology with that in mind. thanks, Peter > > Let's also observe that In any deployment such state when some nodes are > enabled and some not for dynamic flooding can happen during migrating > phase or operator's errors which one would assumed must be handled > correctly by the protocol. > > Many thx, > R.. > > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > From nobody Thu Mar 7 03:17:13 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF23613131B for ; Thu, 7 Mar 2019 03:17:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=raszuk.net 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 PnCenP4zWmSZ for ; Thu, 7 Mar 2019 03:17:10 -0800 (PST) Received: from mail-qk1-x732.google.com (mail-qk1-x732.google.com [IPv6:2607:f8b0:4864:20::732]) (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 1CA82130F67 for ; Thu, 7 Mar 2019 03:17:10 -0800 (PST) Received: by mail-qk1-x732.google.com with SMTP id m9so8736729qkl.4 for ; Thu, 07 Mar 2019 03:17:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iM8QHox1tpgRf/jq/d4L02UqfT2y0sZ7KIL6Pr1fGtQ=; b=aV6WLmVPxN7BpYx21InhP3sJp+V3AKYgKr4mU2CeD3NXM9PgL8jGreoAXJf8JDWZ79 w8RUK6qUxx9Ml7J10lL9v1olfDwQM3ZvMsQ4bSuVPByMqDmcUBPmahadd3Qh4BbEg53L Qju7Pol/B8DVPWOFPCPUJ26eTOQfnsHMu2xAOXGE4e9iIWdyiVq7GA6z4MsN7OiEwcxU Pm6zCXgYuohpYhr26BV22jz/8SQx16o1MN/PFmVX2RbftSsXXo/pB25AFiPnRxRzt9qN /umhk+3bdhZPWYFUWXKK8ycxzsF8nVwNrU+d4v5YE0JzGx+vfzJZ2hZjl1khjWvKZp0Q JUNw== 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=iM8QHox1tpgRf/jq/d4L02UqfT2y0sZ7KIL6Pr1fGtQ=; b=TD0KqzqbqL27E/2z6eQEkTfGRbSVfKJ6xobdTjAf1C3n3qT+4/V9jtkKMdTbFR+nAY j4fqR12W81kpMUUq1kSvA4eY7RC5JZPCWsRRWtxZAAlWJMDGn9nCZeZTyKNYriR/b1i2 kF+WyRseJbMgX+u2LXfn/pbK1IOTUnlXhxGTDjjiXZ2HhMb6kD2Fsp6bX+HW7SD+VJ0z skwdMoh6CUHfeRLFNJLMyOS1hnj6KJjBjHLwmJZ4zs2nkHUl4vuilIokrgmxFByDNuKN sSDS66V6TBFvh/V014x9zvytbyFypA55DUDUy9oay8flGuNnp69LoVJL0khi589rCcye 2ScQ== X-Gm-Message-State: APjAAAUWG4H3NVPH4VI1wavsN00R3SYmbL/rrGyvylLW3qjXhA+Oxtb5 CBnOd0GJfkYoLZgqNy9AwwkXLha9XjsEAtvTWvfMsw== X-Google-Smtp-Source: APXvYqyb1eIreLjejmIIagpsY9ji1RwVoEiTBb6za2sb5fhVJY5TCKSLnveTzc4Ju0yN6fFsd2Bj4YX8Xy8589TMkWI= X-Received: by 2002:a37:d8c:: with SMTP id 134mr3421369qkn.336.1551957429201; Thu, 07 Mar 2019 03:17:09 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Robert Raszuk Date: Thu, 7 Mar 2019 12:16:59 +0100 Message-ID: To: Peter Psenak Cc: lsr@ietf.org Content-Type: multipart/alternative; boundary="0000000000004642d905837f3f7c" Archived-At: Subject: Re: [Lsr] Clarification on co-existance of dynamic flooding aware and not aware nodes X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 11:17:13 -0000 --0000000000004642d905837f3f7c Content-Type: text/plain; charset="UTF-8" Hey Peter, Yes I was not so much asking from the perspective of the node which does not support it. I was more curious if his directly adj neighbor will be smart enough to treat such node rigth. And precisely to that point I have tried to indicate that if this is by design there is no point of including those 100s of TORs in constructing and distributing flooding graph. But spec seems quite silent on such deployment model hence the post. Thx, R. On Thu, Mar 7, 2019 at 12:11 PM Peter Psenak wrote: > Hi Robert, > > On 07/03/2019 12:00 , Robert Raszuk wrote: > > Hi, > > > > My reading of draft-ietf-lsr-dynamic-flooding indicates that said > > document in number of places rather assumes that entire topology (entire > > instance) supports dynamic flooding (perhaps other then bootstrap phase). > > > > Let's observe that there can be lots of L3 TORs only dual attached to > > access routers which will not benefit at all to be part of the game. > > Moreover those TORs may be from different vendors and could support link > > state protocols without any dynamic flooding extensions. > > > > So the question is if the proposal considers a case where only part of > > the fabric in single topology, single area/level, single LSDB etc. is > > aware about dynamic flooding protocol extensions ? > > sure, see section 5.1.2. > > If the node does not participate in dynamic flooding, it will use > standard flooding mechanism. This means that the flooding may be less > optimal, but nothing would break. > > If you wan to be extra smart, your algorithm can even take the node > participation into account and compute the flooding topology with that > in mind. > > thanks, > Peter > > > > > > Let's also observe that In any deployment such state when some nodes are > > enabled and some not for dynamic flooding can happen during migrating > > phase or operator's errors which one would assumed must be handled > > correctly by the protocol. > > > > Many thx, > > R.. > > > > > > _______________________________________________ > > Lsr mailing list > > Lsr@ietf.org > > https://www.ietf.org/mailman/listinfo/lsr > > > > --0000000000004642d905837f3f7c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hey Peter,

Yes I was not so much asking= from the perspective of the node which does not support it. I was more cur= ious if his directly adj neighbor will be smart enough to treat such node r= igth.=C2=A0

And precisely to that point I have tri= ed to indicate that if this is by design there is no point of including tho= se 100s of TORs in constructing and distributing flooding graph.=C2=A0

But spec seems quite silent on such deployment model h= ence the post.=C2=A0

Thx,
R.
<= br>

On Thu, Mar 7, 2019 at 12:11 PM Peter Psenak <ppsenak@cisco.com> wrote:
Hi Robert,

On 07/03/2019 12:00 , Robert Raszuk wrote:
> Hi,
>
> My reading of draft-ietf-lsr-dynamic-flooding indicates that said
> document in number of places rather assumes that entire topology (enti= re
> instance) supports dynamic flooding (perhaps other then bootstrap phas= e).
>
> Let's observe that there can be lots of L3 TORs only dual attached= to
> access routers which will not benefit at all to be part of the game. > Moreover those TORs may be from different vendors and could support li= nk
> state protocols without any dynamic flooding extensions.
>
> So the question is if the proposal considers a case where only part of=
> the fabric in single topology, single area/level, single LSDB etc. is<= br> > aware about dynamic flooding protocol extensions ?

sure, see section 5.1.2.

If the node does not participate in dynamic flooding, it will use
standard flooding mechanism. This means that the flooding may be less
optimal, but nothing would break.

If you wan to be extra smart, your algorithm can even take the node
participation into account and compute the flooding topology with that
in mind.

thanks,
Peter


>
> Let's also observe that In any deployment such state when some nod= es are
> enabled and some not for dynamic flooding can happen during migrating<= br> > phase or operator's errors which one would assumed must be handled=
> correctly by the protocol.
>
> Many thx,
> R..
>
>
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>

--0000000000004642d905837f3f7c-- From nobody Thu Mar 7 03:44:28 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D02A131301 for ; Thu, 7 Mar 2019 03:44:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 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 IBcMPqtq18aE for ; Thu, 7 Mar 2019 03:44:24 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B72A5130F67 for ; Thu, 7 Mar 2019 03:44:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2792; q=dns/txt; s=iport; t=1551959064; x=1553168664; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=KqXweqhIau7HAXLu3CBTcrQvgowxhnw34MjUROWkfTw=; b=iCaiyeH1q7dVYwTBzfvh7ZW0w4wHnXX1u9KVqmEp3O0PkZiwERCzbhoI D62AK0NYoR7jmgvBP/Dma8dB5ePLivndbY2bPBuqwM+ylt86iwLmUF5nd wIAw94bD9ZgmJv/ZIglq6daBS1fw478NXEKwsFdRmTBAKr4PDRICxAGQs c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AJAAARA4Fc/xbLJq1jGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUgQBAQEBCwEBgnZxEieECYh5jDIlmCMUgWcNGAuESQKEVzU?= =?us-ascii?q?IDQEBAwEBBwEDAm0cDEIBDgGEeAEBAQECAQEBIRU2CxALGAICERIDAgInHxE?= =?us-ascii?q?GDQYCAQGDHgGBbQgPqkOBL4VEhGMFgQskAYtCgUA/gREnDIIxLoMeAQGBHIE?= =?us-ascii?q?EgkuCVwKKFYcikl4Jkn8GGYsAiDWdUIFJAjSBVjMaCBsVO4JsghYXE4hMhUA?= =?us-ascii?q?+AzCCIYtwAQE?= X-IronPort-AV: E=Sophos;i="5.58,451,1544486400"; d="scan'208";a="10598606" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Mar 2019 11:44:22 +0000 Received: from [10.147.24.27] ([10.147.24.27]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id x27BiKxj030384; Thu, 7 Mar 2019 11:44:21 GMT To: Robert Raszuk References: Cc: lsr@ietf.org From: Peter Psenak Message-ID: <6c56082f-9518-8eb8-b4b4-f5e189190162@cisco.com> Date: Thu, 7 Mar 2019 12:44:20 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Outbound-SMTP-Client: 10.147.24.27, [10.147.24.27] X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Lsr] Clarification on co-existance of dynamic flooding aware and not aware nodes X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 11:44:26 -0000 Robert, On 07/03/2019 12:16 , Robert Raszuk wrote: > Hey Peter, > > Yes I was not so much asking from the perspective of the node which does > not support it. I was more curious if his directly adj neighbor will be > smart enough to treat such node rigth. > > And precisely to that point I have tried to indicate that if this is by > design there is no point of including those 100s of TORs in constructing > and distributing flooding graph. Spec says: "In incremental deployments, understanding which nodes support Dynamic Flooding can be used to optimize the flooding topology." Given that the spec does not define any algorithm, not much can be said on top of that. thanks, Peter > > But spec seems quite silent on such deployment model hence the post. > > Thx, > R. > > > On Thu, Mar 7, 2019 at 12:11 PM Peter Psenak > wrote: > > Hi Robert, > > On 07/03/2019 12:00 , Robert Raszuk wrote: > > Hi, > > > > My reading of draft-ietf-lsr-dynamic-flooding indicates that said > > document in number of places rather assumes that entire topology > (entire > > instance) supports dynamic flooding (perhaps other then bootstrap > phase). > > > > Let's observe that there can be lots of L3 TORs only dual attached to > > access routers which will not benefit at all to be part of the game. > > Moreover those TORs may be from different vendors and could > support link > > state protocols without any dynamic flooding extensions. > > > > So the question is if the proposal considers a case where only part of > > the fabric in single topology, single area/level, single LSDB etc. is > > aware about dynamic flooding protocol extensions ? > > sure, see section 5.1.2. > > If the node does not participate in dynamic flooding, it will use > standard flooding mechanism. This means that the flooding may be less > optimal, but nothing would break. > > If you wan to be extra smart, your algorithm can even take the node > participation into account and compute the flooding topology with that > in mind. > > thanks, > Peter > > > > > > Let's also observe that In any deployment such state when some > nodes are > > enabled and some not for dynamic flooding can happen during migrating > > phase or operator's errors which one would assumed must be handled > > correctly by the protocol. > > > > Many thx, > > R.. > > > > > > _______________________________________________ > > Lsr mailing list > > Lsr@ietf.org > > https://www.ietf.org/mailman/listinfo/lsr > > > From nobody Thu Mar 7 07:09:47 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 945ED12788F for ; Thu, 7 Mar 2019 07:09:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 1pYnt3qLrEDS for ; Thu, 7 Mar 2019 07:09:38 -0800 (PST) Received: from mail-pg1-x52c.google.com (mail-pg1-x52c.google.com [IPv6:2607:f8b0:4864:20::52c]) (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 59A81124B19 for ; Thu, 7 Mar 2019 07:09:38 -0800 (PST) Received: by mail-pg1-x52c.google.com with SMTP id m2so11475882pgl.5 for ; Thu, 07 Mar 2019 07:09:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=3ycCxDm3/+yjpS1F4mEI0Es0/yzixfUKIi/4duKdeUA=; b=Nfu3Gr4HNTxrCpHBR0dCtLSwRh+cZxdVO7MYzEBsH6G9rLYkkfdGxtIUU063PoEkh+ C4kYqTOaTh9MhUddsCKdsy3WPL6/Qqy3nskVv6oTqiFNErXxpe6qguHzQWffiggB0f0X 9WEBn+sOO6yRpzsRD+/8WygooLCA7JokfpVOhKM9ghzKkCiMgsAIgQFlz0R9OQRFXHd8 +g9AEQZ9i96wt9htv//9jhVgPYgB+xSBFitxs6sYS8o7XiusZ4cOpHScs8ZkyZ9HXQMf UAY+BJWWiTf20gQa4jROTMfWwv5ctamdscSUf23RgU3n9o2OTYe8DZyUy9kiEFdHUsug YuAw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=3ycCxDm3/+yjpS1F4mEI0Es0/yzixfUKIi/4duKdeUA=; b=YBRJsUTY/p3PEqel85wkD8laWAlK66CDfxQXH08c2Nu3jPm+bHJ8DYpCVh0o0T6aeq G0zrTrVGI5BekuUq+glyJFNmqS2TIvNJs2q0EzWJOz+T/zFIaXTr5QHtoYYRaZVNueRM VvDJ87SNrJBVe700NXA4N8H2aIWbeMo/Qhwtg55JB9jfI7MrZiTUID8HfRSNM/H+yykA MRkHz0jcTNU1/y4etpKpVpZLic+kgVtoRL6DrfGLXd1XCA4V29froVLvTspmlK9BfknZ HNkLz8FAOBw+nTFLsUVYSZibBsnSK4IgT1ADRynk8eWJA1mET3Vht/2XuCMuQfTxJ9D1 yfsw== X-Gm-Message-State: APjAAAWrOBPO4n2Dk2lFvmUQY8grYd+ebok30yqOBKx/A5vZQFFyiSh6 1Ysx4bR+KjQXhKCv5/0r2JY2MXkK X-Google-Smtp-Source: APXvYqxtYVm8lyAwKmbi0xrAcwlz3McAvSX65k9N97mKFWBDq9gPZp8YbYWtWcTPITQaoWolpFEzcw== X-Received: by 2002:a63:6f09:: with SMTP id k9mr642102pgc.326.1551971377532; Thu, 07 Mar 2019 07:09:37 -0800 (PST) Received: from [192.168.1.5] (c-73-158-115-137.hsd1.ca.comcast.net. [73.158.115.137]) by smtp.gmail.com with ESMTPSA id v22sm13007148pfa.49.2019.03.07.07.09.35 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Mar 2019 07:09:36 -0800 (PST) Sender: Tony Li From: tony.li@tony.li Message-Id: <6AF967DC-E66A-4B89-9193-D9789E627E86@tony.li> Content-Type: multipart/alternative; boundary="Apple-Mail=_C6678CD6-C2B9-4164-9EE8-943D8A7C0B05" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 7 Mar 2019 07:09:35 -0800 In-Reply-To: Cc: Peter Psenak , lsr@ietf.org To: Robert Raszuk References: X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Lsr] Clarification on co-existance of dynamic flooding aware and not aware nodes X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 15:09:40 -0000 --Apple-Mail=_C6678CD6-C2B9-4164-9EE8-943D8A7C0B05 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 7, 2019, at 3:16 AM, Robert Raszuk wrote: >=20 > And precisely to that point I have tried to indicate that if this is = by design there is no point of including those 100s of TORs in = constructing and distributing flooding graph.=20 And to the point of the algorithm, including those 100s of TORs in = constructing the graph is absolutely necessary. In the case where the = TOR=E2=80=99s have a pair of upstream nodes, you want both of those = upstream interfaces enabled for flooding. The upstream nodes do need to = be told this. Tony --Apple-Mail=_C6678CD6-C2B9-4164-9EE8-943D8A7C0B05 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Mar 7, 2019, at 3:16 AM, Robert Raszuk <robert@raszuk.net> = wrote:

And precisely to that point I = have tried to indicate that if this is by design there is no point of = including those 100s of TORs in constructing and distributing flooding = graph. 


And to the point of the = algorithm, including those 100s of TORs in constructing the graph is = absolutely necessary.  In the case where the TOR=E2=80=99s have a = pair of upstream nodes, you want both of those upstream interfaces = enabled for flooding. The upstream nodes do need to be told = this.

Tony

= --Apple-Mail=_C6678CD6-C2B9-4164-9EE8-943D8A7C0B05-- From nobody Thu Mar 7 07:28:20 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A3F112798F for ; Thu, 7 Mar 2019 07:28:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=raszuk.net 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 k4p4I4_pgF5T for ; Thu, 7 Mar 2019 07:28:16 -0800 (PST) Received: from mail-qk1-x743.google.com (mail-qk1-x743.google.com [IPv6:2607:f8b0:4864:20::743]) (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 7B0DC1279A5 for ; Thu, 7 Mar 2019 07:28:15 -0800 (PST) Received: by mail-qk1-x743.google.com with SMTP id z3so2045885qkf.5 for ; Thu, 07 Mar 2019 07:28:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4eIAawulPnUnm7hEBW8EsEGr7mSJ/VBlN9Qt/Wi6Vm8=; b=GKbGUTgR29E6EmlXZ9slQZ6SmvGgfcUaIYFakmBmCcbW4X2VE+W+tAu96JOwpkI7Zt NQTflB4Uhk8d0PDKi4iWxvu/PM40/YuBWyh3fTMceV6Qstlqu+snzq+A1N5F4sz5wR8j F58QF2gVvub6SmY7OG8Ijy6uCK3/pcb1vA/NSLrZ2MG62jsXk5inSaX12HAiflU08zcP 2DxqtMCB3L2jZdEKTqRnJVcOJTtdVkrv7pk92V2hPalXnc4NH3dMG/eyz8gRUxASzK2V 1x2FXHyz4Pm6WDLqmxywCUqL6G1SgmRJ14ticx5lciRYvvL5rHEPazpkYxHKOs4huZI4 tiaQ== 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=4eIAawulPnUnm7hEBW8EsEGr7mSJ/VBlN9Qt/Wi6Vm8=; b=hLCmloYKe4YXOMO/CTY2cAJCTAUBKEPtFBR791FGDel8nB/cy04VGboKMgw+mDCu9V 0aWGC99ctzZ15ebrXgbuuqdXW7zIspe2PtKiUoxWc50LTOEH+2rAEcnyqY+ae/xtXM4w 0vxjEkjZL4pC0fgBjIyFlf1flF+s5Q6pHSRbkhB1jnJLh+PeaDsVj2DnrTDmIN04Bhvv 9fy7lTeAfdWPV+eN4EmoufmO5k5M8Ekzm9ztG1I62yH7/fT8wAKDkjOkpFcYS6XZCPue sKGWjEbAc970F/wWwjqXCkRF0knJnd/7Ke+rmnONS0Tt/DJrBgfyAuaVk47AIrfxQT6C AUpA== X-Gm-Message-State: APjAAAU9GHS9t/nUkgOZ8DlPWD71IAPj1pcvuQ9kZZyLulxUBENxHgs9 PZKuigjpFUsSKYhRHxlc5WrfErzlNi+JLJR0SYnh6g== X-Google-Smtp-Source: APXvYqy9x9nroIhOabza8ig2XLyf8StFsghcpkcjw72QtiTJ8W3NTTfRUTW/FUgzz7bnvAB/nj5JIsR4IASu2kNgc18= X-Received: by 2002:a37:59c7:: with SMTP id n190mr576913qkb.142.1551972494549; Thu, 07 Mar 2019 07:28:14 -0800 (PST) MIME-Version: 1.0 References: <6AF967DC-E66A-4B89-9193-D9789E627E86@tony.li> In-Reply-To: <6AF967DC-E66A-4B89-9193-D9789E627E86@tony.li> From: Robert Raszuk Date: Thu, 7 Mar 2019 16:28:00 +0100 Message-ID: To: Tony Li Cc: Peter Psenak , lsr@ietf.org Content-Type: multipart/alternative; boundary="0000000000003d3ac5058382c1e2" Archived-At: Subject: Re: [Lsr] Clarification on co-existance of dynamic flooding aware and not aware nodes X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 15:28:19 -0000 --0000000000003d3ac5058382c1e2 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable > The upstream nodes do need to be told this. Well unless they know by design to always flood when peer is not dynamic flooding capable. Yes today this seems to be consider transient and rather an exception (example bootstraping or incremental deployment). My main point was should this be also a valid and legal deployment model ? The draft is actually on one hand says the above and on the other indicates that dynamic flooding could be enabled and run only on part of the area: Flooding that is initiated by nodes that support Dynamic Flooding will remain within the flooding topology until it reaches a legacy node, which will resume legacy flooding. See TORs are one case .. but there are ideas to run dynamic protocols to the hosts too. I have heard there was even a volunteer to write ISIS-lite to be used on hosts :) However If you mandate that all of the members must be included in the flooding graph the leaders may get a little bit busy from time to time. Of course one option is to just split those into separate areas or levels, but keeping it at single one could be considered attractive. Robert. On Thu, Mar 7, 2019 at 4:09 PM wrote: > > > On Mar 7, 2019, at 3:16 AM, Robert Raszuk wrote: > > And precisely to that point I have tried to indicate that if this is by > design there is no point of including those 100s of TORs in constructing > and distributing flooding graph. > > > > And to the point of the algorithm, including those 100s of TORs in > constructing the graph is absolutely necessary. In the case where the > TOR=E2=80=99s have a pair of upstream nodes, you want both of those upstr= eam > interfaces enabled for flooding. The upstream nodes do need to be told th= is. > > Tony > > --0000000000003d3ac5058382c1e2 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

> The upstream nodes do need to be told = this.=C2=A0

Well unless they know by design to always fl= ood when peer is not dynamic flooding capable.=C2=A0

Yes today this seems to be consider transient and rather an exception (e= xample bootstraping or incremental deployment). My main point was should th= is be also a valid and legal deployment model ? The draft is actually on on= e hand says the above and on the other indicates that dynamic flooding coul= d be enabled and run only on part of the area:

   Flooding that is initiated b=
y nodes that support Dynamic Flooding
   will remain within the flooding topology until it reaches a legacy
   node, which will resume legacy flooding.

See TO= Rs are one case .. but there are ideas to run dynamic protocols to the host= s too. I have heard there was even a volunteer to write ISIS-lite to be use= d on hosts :)

However If you mandate that all of t= he members must be included in the flooding graph the leaders may get a lit= tle bit busy from time to time.

Of course one opti= on is to just split those into separate areas or levels, but keeping it at = single one could be considered attractive.

Robert.=

On Thu, Mar 7, 2019 at 4:09 PM <tony.li@tony.li> wrote:


On Mar 7, 2019, at 3:16 AM, Robert Raszuk <robert@raszuk.net&= gt; wrote:

And precisely = to that point I have tried to indicate that if this is by design there is n= o point of including those 100s of TORs in constructing and distributing fl= ooding graph.=C2=A0


= And to the point of the algorithm, including those 100s of TORs in construc= ting the graph is absolutely necessary.=C2=A0 In the case where the TOR=E2= =80=99s have a pair of upstream nodes, you want both of those upstream inte= rfaces enabled for flooding. The upstream nodes do need to be told this.

Tony

--0000000000003d3ac5058382c1e2-- From nobody Thu Mar 7 07:46:52 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78524131433 for ; Thu, 7 Mar 2019 07:46:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 qMXe395lGNy7 for ; Thu, 7 Mar 2019 07:46:49 -0800 (PST) Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) (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 540C913140F for ; Thu, 7 Mar 2019 07:46:44 -0800 (PST) Received: by mail-pg1-x52b.google.com with SMTP id h11so11577608pgl.0 for ; Thu, 07 Mar 2019 07:46:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=NHrZl+c9SsyWO2ROAdcOag56lKeoZRBfg1xqm0RUaZE=; b=GdK5jmoTexNQQRcWvmo0HbFemqWDf39ex+OTTXrTO/4mNOWumNqkZ45yRQwaw1H/3G BagcGfLoXYsgGVcojJHxrEbEz8IIOTN33EfHXczn8Ifg6lTMftWs6Dtwy+kJPh87P2bS bC2SGT9Oz0cpI6XmKlbTyn1JaX5Pw9wPoKSyPpLt4XqjVGSpFHjCNaooqCZoI4lmQk1r dzuEGHk+vL5RNUi7k1c5gtaQRMZb5S6hLYHmLxgU4U9HqahjF7y6e9Rv6clNi8JIfbcu 7KfljGpXaEsJmKPwzBS3OLFbpofnLA7voaVeXvEMeOxXpZBzdM+USlkYn3IinC47gBhp L2jw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=NHrZl+c9SsyWO2ROAdcOag56lKeoZRBfg1xqm0RUaZE=; b=Yxqq0yEp0Fkvu+3QrMogFFBRu4Qs1rwOs2qoVyBJToBjGkOibiuGZpGV02SaBXyEZB ZvIrlY99he6rzUuUMgt8whs++j+pw3duG2nC9leplmsRWZkRv06KufU1kuDt+UximqwD 1aS/1GeYtoz1WhVlSkkQsWlt+I/+LFDxxFLnAIgasZPhXecWvyypvgwj9DOqQtBgrXUS r1KuFeTFrwIG5H/8ieP752OFakjumUcEjQp06jq2XZ7F01zzFz8z0OIdQz3f3IdFZAjH LCSvyink3LRUboeM44XqjmJESAXR/d4IIaD/fhamna+XqVhwjpYONPRxrdUy9ihb6trk 2J5Q== X-Gm-Message-State: APjAAAVnqqug9ItTl4hCc890Csq2ByMbmbP0dxexuxfFo0WadY85mWx4 j774S6/0x5qbc4/w693VPMA= X-Google-Smtp-Source: APXvYqwXiT2YgwMDx5FhlhuTSHzHK6vYQt4lcIe+E+gd7+TIb994VIHZ8ywELMmyywtbJrnsblOLVg== X-Received: by 2002:a63:ec48:: with SMTP id r8mr12051823pgj.50.1551973603683; Thu, 07 Mar 2019 07:46:43 -0800 (PST) Received: from [10.95.80.104] ([162.210.129.5]) by smtp.gmail.com with ESMTPSA id y22sm6765434pfn.136.2019.03.07.07.46.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Mar 2019 07:46:42 -0800 (PST) Sender: Tony Li From: tony.li@tony.li Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_3461AE31-C095-4F50-A209-2D4247B3ED9D" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 7 Mar 2019 07:46:41 -0800 In-Reply-To: Cc: Peter Psenak , lsr@ietf.org To: Robert Raszuk References: <6AF967DC-E66A-4B89-9193-D9789E627E86@tony.li> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Lsr] Clarification on co-existance of dynamic flooding aware and not aware nodes X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 15:46:51 -0000 --Apple-Mail=_3461AE31-C095-4F50-A209-2D4247B3ED9D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > Well unless they know by design to always flood when peer is not = dynamic flooding capable.=20 That would be an extremely detailed piece of corner case coding. ;-) >=20 > Yes today this seems to be consider transient and rather an exception = (example bootstraping or incremental deployment). My main point was = should this be also a valid and legal deployment model ? Yes, certainly. > The draft is actually on one hand says the above and on the other = indicates that dynamic flooding could be enabled and run only on part of = the area: >=20 > Flooding that is initiated by nodes that support Dynamic Flooding > will remain within the flooding topology until it reaches a legacy > node, which will resume legacy flooding. I don=E2=80=99t see that this is contradictory. Rather it is endorsing = it. > See TORs are one case .. but there are ideas to run dynamic protocols = to the hosts too. I have heard there was even a volunteer to write = ISIS-lite to be used on hosts :) I would=E2=80=A6. discourage that concept. > However If you mandate that all of the members must be included in the = flooding graph the leaders may get a little bit busy from time to time. The leader will be busy regardless. Recognizing that something is a = legacy node and special-casing it is not a significant win. The cost = comes in exploring the topology. Handling two link nodes is pretty much = the same, regardless of whether it=E2=80=99s a legacy node or not. > Of course one option is to just split those into separate areas or = levels, but keeping it at single one could be considered attractive. Splitting it would cause massive confusion, so I agree with keeping it = to a single area. Tony --Apple-Mail=_3461AE31-C095-4F50-A209-2D4247B3ED9D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Well unless they know by design to always flood when peer is = not dynamic flooding capable. 

That would be an extremely detailed piece of = corner case coding. ;-)

Yes today this seems to be consider = transient and rather an exception (example bootstraping or incremental = deployment). My main point was should this be also a valid and legal = deployment model ?


Yes, = certainly.


The draft is = actually on one hand says the above and on the other indicates that = dynamic flooding could be enabled and run only on part of the = area:

   Flooding that is initiated =
by nodes that support Dynamic Flooding
   will remain within the flooding topology until it reaches a legacy
   node, which will resume legacy =
flooding.

I don=E2=80=99t see that this is contradictory. =  Rather it is endorsing it.


See TORs are one case .. but there are ideas = to run dynamic protocols to the hosts too. I have heard there was even a = volunteer to write ISIS-lite to be used on hosts = :)


I would=E2=80=A6. discourage that = concept.


However If you mandate that all of the members must be = included in the flooding graph the leaders may get a little bit busy = from time to time.


The leader will be busy = regardless.  Recognizing that something is a legacy node and = special-casing it is not a significant win. The cost comes in exploring = the topology.  Handling two link nodes is pretty much the same, = regardless of whether it=E2=80=99s a legacy node or not.


Of course one option is to just = split those into separate areas or levels, but keeping it at single one = could be considered attractive.


Splitting it would cause = massive confusion, so I agree with keeping it to a single = area.

Tony


= --Apple-Mail=_3461AE31-C095-4F50-A209-2D4247B3ED9D-- From nobody Thu Mar 7 09:16:34 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0935812D4E6 for ; Thu, 7 Mar 2019 09:16:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 wJgGpfanuUIi for ; Thu, 7 Mar 2019 09:16:31 -0800 (PST) Received: from mail-pf1-x444.google.com (mail-pf1-x444.google.com [IPv6:2607:f8b0:4864:20::444]) (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 6EA7A12D550 for ; Thu, 7 Mar 2019 09:16:27 -0800 (PST) Received: by mail-pf1-x444.google.com with SMTP id j5so11928691pfa.2 for ; Thu, 07 Mar 2019 09:16:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=Cm30U5os3fjp56A1bLEfiUhBVIH6pBqmxJMcnYh7pbk=; b=g2WfMKzPcGjTKLQiYHK1cRIj6jiUZa4I7yDPgWwbp7thuzTkRUMErep8wlxfzd2jkR 7CL4EuAZNMQO89i14tP71ZB3NS2pNZ53VJpiMFZi0E6fE3VxGqhk38mckOfahlNSvour kF+AZnya+4j+Li6Hw7+WKbYf223oNtjP/d2C+BJVH4ZbcYDbQSt3OCmPPtt5O3xCHX/2 X4A+i7WBMPu0ph46DdhsW5gsYQFRKqlbd4gaeKLkdqP3+Hj9vZn9DlNRZ7CA3NN9aMLl z2Edd7OSenFVbxplDWOUMcGe1vvq5aig0yDffVr9naosZ7+IgdoOB8DjTeLaRZUWM9gX ircQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=Cm30U5os3fjp56A1bLEfiUhBVIH6pBqmxJMcnYh7pbk=; b=jBmhNwoRIZBe5533tw4f1GrnTdKUyGbmdBwSLOcUpvY1PS26znDEawAWuYiCL+fRGQ g5ON1x6/qP5HgjMaa8degyX676Ff4wz4awM7SVo0G++mJGb0/nXCZed/qYTCYAfWERLe N7AUjdzygELFq6FXAW3VwCky1uQB3X2JaXQ5UulvgYiJRjGHR5TPJT0IWk1ATnYmYdW5 p6XnzWO8R/dP38gPWI/91VbmwTTrEAqDtZjSI5SXBztCvFm3lZ5RMCe/OZEW1PHEfJFW OrN65IJIZnSuaJGZUCm7UhhwlAzJwE8cBtdzon8/o48O7O+23MDqtruzxui1LuvoL/1H MO6A== X-Gm-Message-State: APjAAAXRqcABo7YTfj744H8VIu/5+qA9dx4r1PYG0kVySaTDa98sQi0x N31l4ha8im5Jy0U+BsjAq2I= X-Google-Smtp-Source: APXvYqyDk/biDITsHho80vzvYi/LXtSQIl2YotWWYpTGDZX6XxAeyo0eNc+nkm8tAPpe/dPlFHygjA== X-Received: by 2002:a63:160d:: with SMTP id w13mr12134967pgl.85.1551978986898; Thu, 07 Mar 2019 09:16:26 -0800 (PST) Received: from [10.95.80.104] ([162.210.129.5]) by smtp.gmail.com with ESMTPSA id l64sm6972373pga.87.2019.03.07.09.16.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Mar 2019 09:16:25 -0800 (PST) Sender: Tony Li From: tony.li@tony.li Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_70F1F16A-98A1-48C0-920B-E3E0886C4D9A" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 7 Mar 2019 09:16:24 -0800 In-Reply-To: <2932F33A-1F9E-4C20-A233-E569D8935AE4@tony.li> Cc: Peter Psenak , lsr@ietf.org To: Tony Li References: <966E5756-8CEF-47F4-8564-E23D38F0743E@tony.li> <7F522B6C-9D28-4533-8ABD-9F492D9AF26C@tony.li> <2932F33A-1F9E-4C20-A233-E569D8935AE4@tony.li> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Lsr] Open issues with Dynamic Flooding X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 17:16:32 -0000 --Apple-Mail=_70F1F16A-98A1-48C0-920B-E3E0886C4D9A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 5, 2019, at 1:31 PM, tony.li@tony.li wrote: >=20 > Let me propose that we add something to sections 6.7.5, 6.7.9, and = 6.7.11 like: >=20 > Addition of temporary flooding should be done with caution, as the = addition of excessive connectivity to the flooding topology may trigger = unwanted behavior. Routers SHOULD add temporary flooding in a rate = limited manner, if not configured otherwise. Hi, I haven=E2=80=99t heard any feedback on this. Can we please adopt this? The draft cutoff is Monday, March 11. Could we please incorporate this = change and the addition of the pseudonode identifier by then? Tony --Apple-Mail=_70F1F16A-98A1-48C0-920B-E3E0886C4D9A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Mar 5, 2019, at 1:31 PM, tony.li@tony.li wrote:

Let me propose that we add = something to sections 6.7.5, 6.7.9, and 6.7.11 like:

Addition of temporary flooding = should be done with caution, as the addition of excessive connectivity = to the flooding topology may trigger unwanted behavior. Routers SHOULD = add temporary flooding in a rate limited manner, if not configured = otherwise.


Hi,

I haven=E2=80=99t heard = any feedback on this.  Can we please adopt this?

The draft cutoff is = Monday, March 11.  Could we please incorporate this change and the = addition of the pseudonode identifier by then?

Tony

= --Apple-Mail=_70F1F16A-98A1-48C0-920B-E3E0886C4D9A-- From nobody Thu Mar 7 09:50:41 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59FF512796C for ; Thu, 7 Mar 2019 09:50:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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=Fbkn0OKM; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=VAoVtYve 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 HFAPnC45FJbA for ; Thu, 7 Mar 2019 09:50:36 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32BAF127968 for ; Thu, 7 Mar 2019 09:50:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15676; q=dns/txt; s=iport; t=1551981036; x=1553190636; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=EJ6Iipe2QZRwF5jasMxnHZ/yPogU3xJKyp/tkYXwK4s=; b=Fbkn0OKMRVoEsnWk6QOAcD78zqzFs2xoGVe5ZDojtA01G/4Sf1cYXsp0 3DSLsceiwmTu4reA/3nHJ1zncNRPOcCAo92RpG2eYfvx7vb61d/nlRWMt xGohJy7/AS/233NP1UPApDUJuDaOKPbe1u7u5gdyZZluEowq7rlR4uKdw 4=; IronPort-PHdr: =?us-ascii?q?9a23=3AgB/juR/NZMm4iP9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+8ZR7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfk0jgZdYBUER?= =?us-ascii?q?oMiMEYhQslVcGED1bxIeTlRyc7B89FElRi+iLzPA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ALAABdWYFc/5RdJa1aChoBAQEBAQI?= =?us-ascii?q?BAQEBBwIBAQEBgVMDAQEBAQsBgQ0vUANodAQLJ4QJg0cDjy+CV5IwhXOBJAN?= =?us-ascii?q?UCwEBLIRAAheEHiI2Bw0BAQMBAQcBAwJtHAELhUoBAQEEIwoTAQE3AQ8CAQg?= =?us-ascii?q?RBAEBKAMCAgIwFAkIAgQOBQiDG4ERTAMVAQKgLgKKFHGBL4J4AQEFhH8Yggs?= =?us-ascii?q?IgS8BixwPF4FAP4FXgh4uhFYEKTSCVDGCJoxJhAaTSAkCkxyBeIVmi1eKcZI?= =?us-ascii?q?4AgQCBAUCDQEBBYFOAy4ogS5wFYMnggqDboNGhw1ygSiKCyqCIwEB?= X-IronPort-AV: E=Sophos;i="5.58,451,1544486400"; d="scan'208,217";a="534550404" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Mar 2019 17:50:21 +0000 Received: from xch-rcd-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id x27HoLR7009464 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 Mar 2019 17:50:21 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 7 Mar 2019 11:50:20 -0600 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 7 Mar 2019 12:50:18 -0500 Received: from NAM02-SN1-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.1473.3 via Frontend Transport; Thu, 7 Mar 2019 11:50:18 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=EJ6Iipe2QZRwF5jasMxnHZ/yPogU3xJKyp/tkYXwK4s=; b=VAoVtYveDnuVr26dezNGHo/YUTLWeolroZ0YjifElD5sc7VBbXV8r+6Eg3BPFleCfN6OlrzHaQEMDeld6vD8fjlMBh1FjAdIQ3RwPgcgUr+vGE+JY4Pi90clF8lMceX9aYTKXvREet/lB/2+nlk5BxbWTA99Us1ORO853Pnee1I= Received: from BYAPR11MB3638.namprd11.prod.outlook.com (20.178.237.19) by BYAPR11MB2789.namprd11.prod.outlook.com (52.135.228.19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1665.19; Thu, 7 Mar 2019 17:50:17 +0000 Received: from BYAPR11MB3638.namprd11.prod.outlook.com ([fe80::b414:f534:f20a:a26d]) by BYAPR11MB3638.namprd11.prod.outlook.com ([fe80::b414:f534:f20a:a26d%3]) with mapi id 15.20.1686.016; Thu, 7 Mar 2019 17:50:17 +0000 From: "Les Ginsberg (ginsberg)" To: "tony.li@tony.li" CC: "lsr@ietf.org" , "Peter Psenak (ppsenak)" Thread-Topic: [Lsr] Open issues with Dynamic Flooding Thread-Index: AQHU0rNloYabtT6NFku+G8W9bkhmEKX8p2UAgACQ6YCAAALpAIAABY6AgAA9MgCAAAYKgIAABbWAgAAGcQCAAt1tAIAABduQ Date: Thu, 7 Mar 2019 17:50:17 +0000 Message-ID: References: <966E5756-8CEF-47F4-8564-E23D38F0743E@tony.li> <7F522B6C-9D28-4533-8ABD-9F492D9AF26C@tony.li> <2932F33A-1F9E-4C20-A233-E569D8935AE4@tony.li> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ginsberg@cisco.com; x-originating-ip: [2001:420:30d:1320:68bd:e582:7215:61f8] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b5aafb2a-1f1e-44ae-28d2-08d6a3255c12 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:BYAPR11MB2789; x-ms-traffictypediagnostic: BYAPR11MB2789: x-ld-processed: 5ae1af62-9505-4097-a69a-c1553ef7840e,ExtAddr x-microsoft-exchange-diagnostics: =?utf-8?B?MTtCWUFQUjExTUIyNzg5OzIzOk5UUlFOamhvZGpmcEFneG9lTVU1OUJscFdM?= =?utf-8?B?TmxmRWlOZTRuKzBJZHd4UU90VUcrdlRNVml3NVZkaVdjdmltM0Z1RGc4ZklO?= =?utf-8?B?L0Y3bHI0SUxIZ2FTUDlWTEUzTnlUL2QrTk5nUEEreDJHNjFCbWV1a3hSMEFm?= =?utf-8?B?MXdDSWJpbjZiSWVkNzh4MlR3c0FrYXMyQ2hRVGg1eHkwbHVIMXdqZk5tRkdZ?= =?utf-8?B?VU01Tkt2YnFRR0t4ZklxR3djaU8vbFdYeEhDaXlUaXZTNWFac2paS2VWeU5C?= =?utf-8?B?Kzc4eU1IckdGdXNUQXEyQS8rdnFYdi9TNnVlVzdFS1Q2MGg3VXB1VXV2dzVZ?= =?utf-8?B?RjlJeUtubUxTbytkZGozck1tdnQ3K0NFQ3huOU5JclpkbGg2L0EvQW5NMUlv?= =?utf-8?B?WU85QmxiVGVWeUlURjN3Um9XckR5YVdEZDZYb08xbXNTTFJqSmZYK2FCM3Vv?= =?utf-8?B?QVF4cjRicFhhbzhua1pmRytLQW84cFJ2Z3RYSnhNRnRXdUNNWE1oY3JEd0d5?= =?utf-8?B?b0YwZmt3QTdoTUhiOVIvdFNSQ1dUYWxUQjcrWHc5cCs5eE5OUTgvMkljL1Mz?= =?utf-8?B?c0Fvb0dnRU9SV2FzR0l5dkdwTVlkZzlzZ202TUFycmJNNGZUamQvZ1VReHVF?= =?utf-8?B?V080MkRUL1hOaHNJS3JtU0RKU2IrMlF1dGZQQi9DZ214SWxMRWdqYW0yaEg1?= =?utf-8?B?Uno4ajFGeG5ReU1aOXNZT2NuUUlWUnVFYW9XczNPUjl0N3Q2enYyM3I1Y05W?= =?utf-8?B?eWplbnkrWWx2eG1LTFY4a01EeDdoc2JYSjlzRVVkREdOS0ZXKytOdHQ5RTZB?= =?utf-8?B?NVRCa0l1ejFyb0lpWnF0YVVTVHR0MGRMYkgwMEwwaDJiajAxNE5YTmtBemxB?= =?utf-8?B?RmVBNkx4SW9la3RPcXVkdjdrL0psdmt2MlVkQkFPL1krU0tpZG1jQkNuVTNp?= =?utf-8?B?S0pqTWcyamdMUUVsOGlKZ2hUOThXMkdVeE1zaGtHakFuYjJwYy9rbjZVUkE2?= =?utf-8?B?SG5JQU4veWQ2cUwzcWljNjdSR3pIMWR4bnA4OHFJTm5VUSs2Lzl5cVN5N2hC?= =?utf-8?B?YUN5eDNWVUVvRzIraHBSb05MODZzMGljVFRRN292OGxleTl5bjZCSFZENkVs?= =?utf-8?B?cGpCWDVSazRmMmJ0c3ROK0ZZSG9DMkM0NFYzNWF5b2lrYnVPdzFoakFNa3I1?= =?utf-8?B?RDlMSk1jRzVzMFZ1QjdaRnBpc2t3MU5vRmFtWHNTZWJrYXpBMDhTcHFEQnMx?= =?utf-8?B?cU9FQXQ1dExTUUNFd29XbVJxZHhSUnMwcEIzbWc2eWxzQ0U3TmE0b0VlOWNM?= =?utf-8?B?OUVobWswdXFiNnpEdDdtNnRrTDh3d3Y0NXFPSE5SK1I2V3dVRHN5QUUwUFNS?= =?utf-8?B?bmNCRXloSzV2ZWpZNVp0bCtyS3ZYZnE1cHBqZE1qOFEvVjhMWEdwamtuRXpu?= =?utf-8?B?VVVhRFUyZGpHTHJYRDZYSTB4WDlTbEFVYUNqdHBYT0NMd3puUXFKSW5oK3lp?= =?utf-8?B?TWlwbFU3MWdkUXVkaVRrSndjQ3Z0QUNvV2xlREtmYWx0cGxra0VOV0RhRnJq?= =?utf-8?B?aDUwQm9sRzFWMmt4VlBFd1JYcVJqS0ZEV0lkZTB1ckZ1ZmRqakhJUlVaT21a?= =?utf-8?B?dWZ5SHJhT2FJa2ZrMmJhcmt2UVk3SWxMU1JjdWZudnhJdWo4YVFQM1FRbU9o?= =?utf-8?B?NmtYb3hqOWJVVTZwbzUwUWduYkdyaTJXcC9id3NOVENxTmVoMHgyUXl6Mm9L?= =?utf-8?B?RWxDRXIvdE1PV0RiMDRjZHJhcXoyZHp6RzdoKzZ0dGVwWlAwQlJmTTRxbHp0?= =?utf-8?B?ckF1ejR3THZxL0V2ZmloVFdHOFRxYnNVNUgzdlV6dlBHcW1vck5PT1gxN2Fw?= =?utf-8?Q?OvFtUJfosKMdaajHWUjF8+FmPjNCJv0P?= x-microsoft-antispam-prvs: x-forefront-prvs: 096943F07A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(376002)(366004)(39860400002)(136003)(346002)(199004)(189003)(2906002)(46003)(6116002)(790700001)(33656002)(54906003)(486006)(11346002)(446003)(74316002)(476003)(6506007)(8676002)(53546011)(102836004)(8936002)(6916009)(76176011)(81156014)(81166006)(99286004)(71200400001)(71190400001)(229853002)(7696005)(186003)(106356001)(105586002)(2501003)(14444005)(256004)(97736004)(52536013)(4326008)(316002)(6246003)(68736007)(53936002)(107886003)(7736002)(2351001)(5660300002)(86362001)(66574012)(14454004)(5640700003)(55016002)(6306002)(6436002)(54896002)(9686003)(478600001)(25786009)(236005)(93886005); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB2789; H:BYAPR11MB3638.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: ZHpjPF/uPndZ7WmSa/0BBZ6p0Khyg4agKgy4GYi/G8kTMIMYnz12VKagt1OggaDYIzNUHLnkl0CLeDjkXaxh0ZtcarZXZNt8B5AALEY77rBoD+EnU6NyxwFyw91KEm5m5/gsaJKxAcwzdAkuH+MrRi9dYtVGJotscVx3A29dSN6ANByd6CvipLbK040mYlzC6Q6y6k7CMN95oezwsJUzqECdgQZN6VoOXlyxOm+RqvFbHc+GFRH89usu8nlHrEMNlsjIaqW3lpQscMiuE4De+tvaQH/b6bUH1I820mEU9svbNNdT9pWTNJUIIvDfc4OR0zz25GAoWYI95zuVl28ju+jNMPBFQuO9VA+8naW5CP2DC1XbhTaQ9lpBlU1tZPSuzBW7u7PecW9/SYjtuehcfTJlYHfXd3SByySLTT5/Blk= Content-Type: multipart/alternative; boundary="_000_BYAPR11MB3638D584975FF64B348D6705C14C0BYAPR11MB3638namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: b5aafb2a-1f1e-44ae-28d2-08d6a3255c12 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Mar 2019 17:50:17.2364 (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-Transport-CrossTenantHeadersStamped: BYAPR11MB2789 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.21, xch-rcd-011.cisco.com X-Outbound-Node: rcdn-core-12.cisco.com Archived-At: Subject: Re: [Lsr] Open issues with Dynamic Flooding X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 17:50:39 -0000 --_000_BYAPR11MB3638D584975FF64B348D6705C14C0BYAPR11MB3638namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VG9ueSAtDQoNCkZyb206IExzciA8bHNyLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiB0 b255LmxpQHRvbnkubGkNClNlbnQ6IFRodXJzZGF5LCBNYXJjaCAwNywgMjAxOSA5OjE2IEFNDQpU bzogVG9ueSBMaSA8dG9ueS5saUB0b255LmxpPg0KQ2M6IGxzckBpZXRmLm9yZzsgUGV0ZXIgUHNl bmFrIChwcHNlbmFrKSA8cHBzZW5ha0BjaXNjby5jb20+DQpTdWJqZWN0OiBSZTogW0xzcl0gT3Bl biBpc3N1ZXMgd2l0aCBEeW5hbWljIEZsb29kaW5nDQoNCg0KDQoNCk9uIE1hciA1LCAyMDE5LCBh dCAxOjMxIFBNLCB0b255LmxpQHRvbnkubGk8bWFpbHRvOnRvbnkubGlAdG9ueS5saT4gd3JvdGU6 DQoNCkxldCBtZSBwcm9wb3NlIHRoYXQgd2UgYWRkIHNvbWV0aGluZyB0byBzZWN0aW9ucyA2Ljcu NSwgNi43LjksIGFuZCA2LjcuMTEgbGlrZToNCg0KQWRkaXRpb24gb2YgdGVtcG9yYXJ5IGZsb29k aW5nIHNob3VsZCBiZSBkb25lIHdpdGggY2F1dGlvbiwgYXMgdGhlIGFkZGl0aW9uIG9mIGV4Y2Vz c2l2ZSBjb25uZWN0aXZpdHkgdG8gdGhlIGZsb29kaW5nIHRvcG9sb2d5IG1heSB0cmlnZ2VyIHVu d2FudGVkIGJlaGF2aW9yLiBSb3V0ZXJzIFNIT1VMRCBhZGQgdGVtcG9yYXJ5IGZsb29kaW5nIGlu IGEgcmF0ZSBsaW1pdGVkIG1hbm5lciwgaWYgbm90IGNvbmZpZ3VyZWQgb3RoZXJ3aXNlLg0KDQpb TGVzOl0gVGhlIGZpcnN0IHNlbnRlbmNlIGlzIE9LIHdpdGggbWUuIFRoZSBzZWNvbmQgb25lIEkg dGhpbmsgZ29lcyBiZXlvbmQgYW55dGhpbmcgb24gd2hpY2ggd2UgY2FuIGNsYWltIGNvbnNlbnN1 cy4NCldoZXRoZXIgYWRkaW5nIHRoZSBmaXJzdCBzZW50ZW5jZSBhbG9uZSBpcyB3b3J0aCBhIG5l dyByZXZpc2lvbiBJIHRoaW5rIGlzIHF1ZXN0aW9uYWJsZSDigJMgYnV0IEkgY2VydGFpbmx5IHdv dWxkIG5vdCBvcHBvc2UgaXQuDQoNClJlZ2FyZGluZyBMQU5zLCB0aGUgZW5jb2RpbmcgZm9yIE9T UEYgaXMgbW9yZSBwcm9ibGVtYXRpYyDigJMgYmFzaWNhbGx5IHdlIG5lZWQgdG8gaWRlbnRpZnkg dGhlIHZhbHVlIGFzIGEgcm91dGVyIGlkIG9yIGEgbmV0d29yayBMU0EgaWQgKG9yIHNvbWV0aGlu ZyBsaWtlIHRoYXQpLg0KU28sIGNvbW1pdHRpbmcgdG8gdGhpcyB3aXRob3V0IGNvbnNlbnN1cyBo YXMgYSBkb3duc2lkZSB0aGF0IHdlIG1pZ2h0IGxpdmUgdG8gcmVncmV0Lg0KDQpJIGFtIGluIGFn cmVlbWVudCB3aXRoIFBldGVy4oCZcyBwb3NpdGlvbi4gTEFOcyBpbnRyb2R1Y2UgYWRkaXRpb25h bCBjb21wbGV4aXR5IGFuZCBpdCBpcyBub3QgY2xlYXIgdGhhdCBpbmNsdWRpbmcgdGhhdCBzdXBw b3J0IGlzIGEgcmVhbCBiZW5lZml0IGluIHRoZSB0b3BvbG9naWVzIGluIHdoaWNoIHdlIGV4cGVj dCB0aGUgZmxvb2Rpbmcgb3B0aW1pemF0aW9ucyB0byBiZSB1c2VkLg0KSSBrbm93IHlvdSBiZWxp ZXZlIHJlYWwgZGVwbG95bWVudHMgbWF5IG5lZWQgdGhpcyBzdXBwb3J0IOKAkyBidXQgd2hhdCBJ IGRvbuKAmXQga25vdyBpcyB3aGV0aGVyIHdlIGhhdmUgaGFyZCBldmlkZW5jZSB0byBzdXBwb3J0 IHRoYXQgcG9zaXRpb24uDQoNCkkgYW0gYWxzbyB3b25kZXJpbmcgd2hldGhlciB0aGUgZm9sbG93 aW5nIHNlcnZlcyB1cyBiZXR0ZXI6DQoNCmEpV2Uga2VlcCBMQU5zIGFsd2F5cyBlbmFibGVkIGZv ciBmbG9vZGluZw0KYilUaGUgYWxnb3JpdGhtcyBjb25zaWRlciB0aGlzIGFuZCBhcmUgYmlhc2Vk IHRvd2FyZHMgdXNpbmcgTEFOcyB3aGVuIHBvc3NpYmxlIGFzIHRoaXMgaXMgYSBjaGVhcGVyIHdh eSB0byBlbmFibGUgZmxvb2RpbmcgdG8gbXVsdGlwbGUgbm9kZXMgdGhhbiBtYW55IFAyUCBpbnRl cmZhY2VzLg0KDQpJTiB0aGlzIHdheSB3ZSBrZWVwIHRoZSBzaW1wbGljaXR5IG9mIG5vdCBoYXZp bmcgdG8gZGVmaW5lIExBTiBiZWhhdmlvci9lbmNvZGluZywgeWV0IHJlYXAgYmVuZWZpdHMgaW4g dG9wb2xvZ2llcyB3aGVyZSBMQU5zIGhhdmUgYSBzaWduaWZpY2FudCBwcmVzZW5jZS4NCg0KTGV0 IG1lIGtub3cgd2hhdCBwcm9ibGVtcyB5b3Ugc2VlIHdpdGggdGhpcyBhcHByb2FjaC4NCg0KICAg TGVzDQoNCg0KSGksDQoNCkkgaGF2ZW7igJl0IGhlYXJkIGFueSBmZWVkYmFjayBvbiB0aGlzLiAg Q2FuIHdlIHBsZWFzZSBhZG9wdCB0aGlzPw0KDQpUaGUgZHJhZnQgY3V0b2ZmIGlzIE1vbmRheSwg TWFyY2ggMTEuICBDb3VsZCB3ZSBwbGVhc2UgaW5jb3Jwb3JhdGUgdGhpcyBjaGFuZ2UgYW5kIHRo ZSBhZGRpdGlvbiBvZiB0aGUgcHNldWRvbm9kZSBpZGVudGlmaWVyIGJ5IHRoZW4/DQoNClRvbnkN Cg0K --_000_BYAPR11MB3638D584975FF64B348D6705C14C0BYAPR11MB3638namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1z b25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1l Om1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGlu Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNw YW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Ub255IC08bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxk aXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNFMUUxRTEgMS4w cHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPkZyb206PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiBMc3IgJmx0 O2xzci1ib3VuY2VzQGlldGYub3JnJmd0Ow0KPGI+T24gQmVoYWxmIE9mIDwvYj50b255LmxpQHRv bnkubGk8YnI+DQo8Yj5TZW50OjwvYj4gVGh1cnNkYXksIE1hcmNoIDA3LCAyMDE5IDk6MTYgQU08 YnI+DQo8Yj5Ubzo8L2I+IFRvbnkgTGkgJmx0O3RvbnkubGlAdG9ueS5saSZndDs8YnI+DQo8Yj5D Yzo8L2I+IGxzckBpZXRmLm9yZzsgUGV0ZXIgUHNlbmFrIChwcHNlbmFrKSAmbHQ7cHBzZW5ha0Bj aXNjby5jb20mZ3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbTHNyXSBPcGVuIGlzc3VlcyB3 aXRoIER5bmFtaWMgRmxvb2Rpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPk9uIE1hciA1LCAyMDE5LCBhdCAxOjMxIFBNLCA8YSBocmVmPSJtYWlsdG86dG9ueS5s aUB0b255LmxpIj4NCnRvbnkubGlAdG9ueS5saTwvYT4gd3JvdGU6PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQt ZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5MZXQgbWUgcHJvcG9zZSB0 aGF0IHdlIGFkZCBzb21ldGhpbmcgdG8gc2VjdGlvbnMgNi43LjUsIDYuNy45LCBhbmQgNi43LjEx IGxpa2U6PGJyPg0KPGJyPg0KQWRkaXRpb24gb2YgdGVtcG9yYXJ5IGZsb29kaW5nIHNob3VsZCBi ZSBkb25lIHdpdGggY2F1dGlvbiwgYXMgdGhlIGFkZGl0aW9uIG9mIGV4Y2Vzc2l2ZSBjb25uZWN0 aXZpdHkgdG8gdGhlIGZsb29kaW5nIHRvcG9sb2d5IG1heSB0cmlnZ2VyIHVud2FudGVkIGJlaGF2 aW9yLiBSb3V0ZXJzIFNIT1VMRCBhZGQgdGVtcG9yYXJ5IGZsb29kaW5nIGluIGEgcmF0ZSBsaW1p dGVkIG1hbm5lciwgaWYgbm90IGNvbmZpZ3VyZWQgb3RoZXJ3aXNlLjwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5 N0QiPltMZXM6XSBUaGUgZmlyc3Qgc2VudGVuY2UgaXMgT0sgd2l0aCBtZS4gVGhlIHNlY29uZCBv bmUgSSB0aGluayBnb2VzIGJleW9uZCBhbnl0aGluZyBvbiB3aGljaCB3ZSBjYW4gY2xhaW0gY29u c2Vuc3VzLjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPldoZXRoZXIgYWRkaW5nIHRo ZSBmaXJzdCBzZW50ZW5jZSBhbG9uZSBpcyB3b3J0aCBhIG5ldyByZXZpc2lvbiBJIHRoaW5rIGlz IHF1ZXN0aW9uYWJsZSDigJMgYnV0IEkgY2VydGFpbmx5IHdvdWxkIG5vdCBvcHBvc2UgaXQuPG86 cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9p PjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+UmVnYXJkaW5nIExBTnMsIHRoZSBlbmNvZGluZyBmb3IgT1NQRiBpcyBtb3Jl IHByb2JsZW1hdGljIOKAkyBiYXNpY2FsbHkgd2UgbmVlZCB0byBpZGVudGlmeSB0aGUgdmFsdWUg YXMgYSByb3V0ZXIgaWQgb3IgYSBuZXR3b3JrIExTQSBpZCAob3Igc29tZXRoaW5nIGxpa2UNCiB0 aGF0KS48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5TbywgY29tbWl0dGluZyB0byB0 aGlzIHdpdGhvdXQgY29uc2Vuc3VzIGhhcyBhIGRvd25zaWRlIHRoYXQgd2UgbWlnaHQgbGl2ZSB0 byByZWdyZXQuPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBhbSBpbiBhZ3JlZW1lbnQgd2l0aCBQZXRlcuKAmXMg cG9zaXRpb24uIExBTnMgaW50cm9kdWNlIGFkZGl0aW9uYWwgY29tcGxleGl0eSBhbmQgaXQgaXMg bm90IGNsZWFyIHRoYXQgaW5jbHVkaW5nIHRoYXQgc3VwcG9ydCBpcyBhIHJlYWwgYmVuZWZpdCBp biB0aGUgdG9wb2xvZ2llcw0KIGluIHdoaWNoIHdlIGV4cGVjdCB0aGUgZmxvb2Rpbmcgb3B0aW1p emF0aW9ucyB0byBiZSB1c2VkLjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkga25v dyB5b3UgYmVsaWV2ZSByZWFsIGRlcGxveW1lbnRzIG1heSBuZWVkIHRoaXMgc3VwcG9ydCDigJMg YnV0IHdoYXQgSSBkb27igJl0IGtub3cgaXMgd2hldGhlciB3ZSBoYXZlIGhhcmQgZXZpZGVuY2Ug dG8gc3VwcG9ydCB0aGF0IHBvc2l0aW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0Qi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkkgYW0gYWxzbyB3b25kZXJp bmcgd2hldGhlciB0aGUgZm9sbG93aW5nIHNlcnZlcyB1cyBiZXR0ZXI6PG86cD48L286cD48L3Nw YW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ YSlXZSBrZWVwIExBTnMgYWx3YXlzIGVuYWJsZWQgZm9yIGZsb29kaW5nPG86cD48L286cD48L3Nw YW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+YilUaGUgYWxnb3JpdGhtcyBjb25zaWRlciB0aGlzIGFuZCBhcmUg Ymlhc2VkIHRvd2FyZHMgdXNpbmcgTEFOcyB3aGVuIHBvc3NpYmxlIGFzIHRoaXMgaXMgYSBjaGVh cGVyIHdheSB0byBlbmFibGUgZmxvb2RpbmcgdG8gbXVsdGlwbGUgbm9kZXMgdGhhbiBtYW55IFAy UA0KIGludGVyZmFjZXMuPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SU4gdGhpcyB3YXkgd2Uga2VlcCB0aGUgc2lt cGxpY2l0eSBvZiBub3QgaGF2aW5nIHRvIGRlZmluZSBMQU4gYmVoYXZpb3IvZW5jb2RpbmcsIHll dCByZWFwIGJlbmVmaXRzIGluIHRvcG9sb2dpZXMgd2hlcmUgTEFOcyBoYXZlIGEgc2lnbmlmaWNh bnQgcHJlc2VuY2UuPG86cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48Yj48aT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+TGV0IG1lIGtub3cgd2hhdCBwcm9ibGVtcyB5b3Ug c2VlIHdpdGggdGhpcyBhcHByb2FjaC48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgTGVzPG86 cD48L286cD48L3NwYW4+PC9pPjwvYj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SGksPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgaGF2ZW7igJl0IGhlYXJkIGFueSBmZWVkYmFj ayBvbiB0aGlzLiAmbmJzcDtDYW4gd2UgcGxlYXNlIGFkb3B0IHRoaXM/PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBkcmFmdCBjdXRvZmYg aXMgTW9uZGF5LCBNYXJjaCAxMS4gJm5ic3A7Q291bGQgd2UgcGxlYXNlIGluY29ycG9yYXRlIHRo aXMgY2hhbmdlIGFuZCB0aGUgYWRkaXRpb24gb2YgdGhlIHBzZXVkb25vZGUgaWRlbnRpZmllciBi eSB0aGVuPzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5Ub255PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_BYAPR11MB3638D584975FF64B348D6705C14C0BYAPR11MB3638namp_-- From nobody Thu Mar 7 11:20:48 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E1786128678 for ; Thu, 7 Mar 2019 11:20:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 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 WClgD0eo51lD for ; Thu, 7 Mar 2019 11:20:44 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 675F4130EDD for ; Thu, 7 Mar 2019 11:20:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=922; q=dns/txt; s=iport; t=1551986442; x=1553196042; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=AxuKBb9lhED/44CZDnkDjLCHwvziA7YEbrESUgrp55s=; b=SYDnK8pf+JzruTyTF+8EFmUYjxE7kHhU9ilxqmZ4CwfuJF6nMWwo6lBj XZvRZaVeAO0bRTrhFLbqHiCgvr5Bn3pViTuZNxEW7o67XOE8XMRKT68mH KWoCmyODFrUu2OH5s5HkELpzhm4e/jeqBDBjUSnao05UONcn1t5vfGRup 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AKAAC+boFc/xbLJq1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUwMBAQEBCwGDaBInhAmIeYwqLZgjgXsNhGwChFc2Bw0BAQM?= =?us-ascii?q?BAQcBAwJtHAyFSgEBAQMBIw8BBUEQCxgCAiMDAgJGERMGAgEBgx6BbgirXYE?= =?us-ascii?q?vhUSEYoELJAGLQoFAP4E4gj0uhFp0gj2CVwKkFQmSfwYZgXiFZoMiiDWdUIF?= =?us-ascii?q?ODiOBVjMaCBsVgyeJPocOPgMwizMqgiMBAQ?= X-IronPort-AV: E=Sophos;i="5.58,451,1544486400"; d="scan'208";a="10606141" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Mar 2019 19:20:28 +0000 Received: from [10.60.140.54] (ams-ppsenak-nitro5.cisco.com [10.60.140.54]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id x27JKReM005568; Thu, 7 Mar 2019 19:20:28 GMT To: tony.li@tony.li References: <966E5756-8CEF-47F4-8564-E23D38F0743E@tony.li> <7F522B6C-9D28-4533-8ABD-9F492D9AF26C@tony.li> <2932F33A-1F9E-4C20-A233-E569D8935AE4@tony.li> Cc: lsr@ietf.org From: Peter Psenak Message-ID: <884f0f45-813f-93f0-a63e-f510e5f01ab1@cisco.com> Date: Thu, 7 Mar 2019 20:20:27 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Outbound-SMTP-Client: 10.60.140.54, ams-ppsenak-nitro5.cisco.com X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Lsr] Open issues with Dynamic Flooding X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 19:20:46 -0000 On 07/03/2019 18:16 , tony.li@tony.li wrote: > > >> On Mar 5, 2019, at 1:31 PM, tony.li@tony.li >> wrote: >> >> Let me propose that we add something to sections 6.7.5, 6.7.9, and >> 6.7.11 like: >> >> Addition of temporary flooding should be done with caution, as the >> addition of excessive connectivity to the flooding topology may >> trigger unwanted behavior. Routers SHOULD add temporary flooding in a >> rate limited manner, if not configured otherwise. > > > Hi, > > I haven’t heard any feedback on this. Can we please adopt this? > > The draft cutoff is Monday, March 11. Could we please incorporate this > change and the addition of the pseudonode identifier by then? I don't think there is an agreement on the LAN side. Rate limiting we can add, but we can do that after March 11, I don't see a need to do it before. thanks, Peter > > Tony > From nobody Thu Mar 7 12:12:50 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4936B126C87 for ; Thu, 7 Mar 2019 12:12:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.233 X-Spam-Level: X-Spam-Status: No, score=-1.233 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=1.468, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-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=juniper.net 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 W0mfge4K2mN0 for ; Thu, 7 Mar 2019 12:12:46 -0800 (PST) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 73260129B88 for ; Thu, 7 Mar 2019 12:12:46 -0800 (PST) Received: from pps.filterd (m0108158.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x27K5B9W030021; Thu, 7 Mar 2019 12:12:43 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=5uhBRT4+ll5ikhGfLJs8fVy22+S1Z5AYCMFEBHob6Lg=; b=MZMCVGPewJ5UYXt4mfAmomUzVYqcJP5GCYzR5giadd0JXeGwpfA0hWr4TA0uX4RYrHv0 0yoITiVeUDoHPNk5gY2K1lsIV4ifYo5oN5AI387NKPL7Dh8sq4nPQ9iCt7i3Lu9xBOkq R2XWyDs29agHLdLB4zqOkY9hjAZQ9SbcoSfVAt8bGeO82hMirOk73FKn1qLkzm+QwYBZ Tva7ERF8PkGCTinqxdmPctgkq879YjkzUcDTbO6IoFXgwzQXbiIR7uKZcvjTGsgC2ybx 1QL9Y0Jj48l1dX0Jc1+6IPQQRRQhHKS1raqWeJwz1XL/1CmqOIy/H0v8Wn+I4ZAWTkvY Eg== Received: from nam02-cy1-obe.outbound.protection.outlook.com (mail-cys01nam02lp2055.outbound.protection.outlook.com [104.47.37.55]) by mx0a-00273201.pphosted.com with ESMTP id 2r36nc0f8v-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 07 Mar 2019 12:12:43 -0800 Received: from BYAPR05MB5029.namprd05.prod.outlook.com (20.177.230.211) by BYAPR05MB5943.namprd05.prod.outlook.com (20.178.51.12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.8; Thu, 7 Mar 2019 20:12:41 +0000 Received: from BYAPR05MB5029.namprd05.prod.outlook.com ([fe80::b58f:10f1:a40b:abf7]) by BYAPR05MB5029.namprd05.prod.outlook.com ([fe80::b58f:10f1:a40b:abf7%4]) with mapi id 15.20.1686.016; Thu, 7 Mar 2019 20:12:41 +0000 From: John E Drake To: Peter Psenak , "tony.li@tony.li" CC: "lsr@ietf.org" Thread-Topic: [Lsr] Open issues with Dynamic Flooding Thread-Index: AQHU0rNaVvQ0QBVMlk2Xrz5VBQhbhaX8p2YAgACQ6ICAAALpAIAABY6AgAA9MgCAAAYKgIAABbWAgAAGcQCAAt1tAIAAIqmAgAAOY8A= Date: Thu, 7 Mar 2019 20:12:41 +0000 Message-ID: References: <966E5756-8CEF-47F4-8564-E23D38F0743E@tony.li> <7F522B6C-9D28-4533-8ABD-9F492D9AF26C@tony.li> <2932F33A-1F9E-4C20-A233-E569D8935AE4@tony.li> <884f0f45-813f-93f0-a63e-f510e5f01ab1@cisco.com> In-Reply-To: <884f0f45-813f-93f0-a63e-f510e5f01ab1@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 11.1.100.23 dlp-reaction: no-action x-originating-ip: [66.129.241.12] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: efb75636-36ed-4c1c-d514-08d6a339409f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(4618075)(2017052603328)(7153060)(7193020); SRVR:BYAPR05MB5943; x-ms-traffictypediagnostic: BYAPR05MB5943: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 096943F07A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(136003)(376002)(346002)(396003)(39860400002)(199004)(189003)(13464003)(106356001)(256004)(186003)(81166006)(53936002)(26005)(71190400001)(71200400001)(76176011)(9686003)(68736007)(102836004)(316002)(3846002)(7736002)(305945005)(7696005)(6506007)(53546011)(93886005)(55016002)(81156014)(97736004)(105586002)(86362001)(2501003)(66066001)(14444005)(486006)(19627235002)(4326008)(229853002)(99286004)(476003)(14454004)(33656002)(6306002)(6436002)(11346002)(8936002)(74316002)(2906002)(6246003)(8676002)(52536013)(6116002)(5660300002)(446003)(966005)(25786009)(110136005)(478600001); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB5943; H:BYAPR05MB5029.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: pQWTWbX4fdaP3yn3nYerROu6+OyMSVoS9Zmx5fHdyT7V6ORj5eJwSNZshsQX5U/E/B3kBhCbuuElvrc+Ks/GXBWLjoJBvJXGuSZs4b+fXTvflxzoCO3mhkkDFsegFB4+Gn4K4xWaKGWwEBk92toM8Px60uxZPSBGL5MfnEGdzF2hDHq3r1SuYFokWrZbyNcoyA5c4MrKn7g02SZWejGmDct8xKthdU1Rm8Ie9slriNhMPJtOyXvkUHMYQ9j36ctBKyX08mwIi3lTCHA212fpy5X12Em9yXE5yeup6G9q/UB1az7EB43ogSxtf3/CzFRfco13uhX80mYXh372h3x0xYwi/wIePy2/X9rR3xnbaS6C6mzvMbGjb8csX42rj3e/kYPH7z6RpdygP5e5kjP8gP/VNDLQNjkflbOfTZ9yD5o= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: efb75636-36ed-4c1c-d514-08d6a339409f X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Mar 2019 20:12:41.1183 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB5943 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-07_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903070135 Archived-At: Subject: Re: [Lsr] Open issues with Dynamic Flooding X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 20:12:48 -0000 SGksDQoNCldoYXQgZG9lcyAncmF0ZSBsaW1pdCcgbWVhbiBpbiB0aGlzIGNvbnRleHQ/DQoNCllv dXJzIElycmVzcGVjdGl2ZWx5LA0KDQpKb2huDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gRnJvbTogTHNyIDxsc3ItYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIFBldGVy IFBzZW5haw0KPiBTZW50OiBUaHVyc2RheSwgTWFyY2ggNywgMjAxOSAyOjIwIFBNDQo+IFRvOiB0 b255LmxpQHRvbnkubGkNCj4gQ2M6IGxzckBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW0xzcl0g T3BlbiBpc3N1ZXMgd2l0aCBEeW5hbWljIEZsb29kaW5nDQo+IA0KPiBPbiAwNy8wMy8yMDE5IDE4 OjE2ICwgdG9ueS5saUB0b255LmxpIHdyb3RlOg0KPiA+DQo+ID4NCj4gPj4gT24gTWFyIDUsIDIw MTksIGF0IDE6MzEgUE0sIHRvbnkubGlAdG9ueS5saSA8bWFpbHRvOnRvbnkubGlAdG9ueS5saT4N Cj4gPj4gd3JvdGU6DQo+ID4+DQo+ID4+IExldCBtZSBwcm9wb3NlIHRoYXQgd2UgYWRkIHNvbWV0 aGluZyB0byBzZWN0aW9ucyA2LjcuNSwgNi43LjksIGFuZA0KPiA+PiA2LjcuMTEgbGlrZToNCj4g Pj4NCj4gPj4gQWRkaXRpb24gb2YgdGVtcG9yYXJ5IGZsb29kaW5nIHNob3VsZCBiZSBkb25lIHdp dGggY2F1dGlvbiwgYXMgdGhlDQo+ID4+IGFkZGl0aW9uIG9mIGV4Y2Vzc2l2ZSBjb25uZWN0aXZp dHkgdG8gdGhlIGZsb29kaW5nIHRvcG9sb2d5IG1heQ0KPiA+PiB0cmlnZ2VyIHVud2FudGVkIGJl aGF2aW9yLiBSb3V0ZXJzIFNIT1VMRCBhZGQgdGVtcG9yYXJ5IGZsb29kaW5nIGluIGENCj4gPj4g cmF0ZSBsaW1pdGVkIG1hbm5lciwgaWYgbm90IGNvbmZpZ3VyZWQgb3RoZXJ3aXNlLg0KPiA+DQo+ ID4NCj4gPiBIaSwNCj4gPg0KPiA+IEkgaGF2ZW7igJl0IGhlYXJkIGFueSBmZWVkYmFjayBvbiB0 aGlzLiAgQ2FuIHdlIHBsZWFzZSBhZG9wdCB0aGlzPw0KPiA+DQo+ID4gVGhlIGRyYWZ0IGN1dG9m ZiBpcyBNb25kYXksIE1hcmNoIDExLiAgQ291bGQgd2UgcGxlYXNlIGluY29ycG9yYXRlDQo+ID4g dGhpcyBjaGFuZ2UgYW5kIHRoZSBhZGRpdGlvbiBvZiB0aGUgcHNldWRvbm9kZSBpZGVudGlmaWVy IGJ5IHRoZW4/DQo+IA0KPiBJIGRvbid0IHRoaW5rIHRoZXJlIGlzIGFuIGFncmVlbWVudCBvbiB0 aGUgTEFOIHNpZGUuDQo+IA0KPiBSYXRlIGxpbWl0aW5nIHdlIGNhbiBhZGQsIGJ1dCB3ZSBjYW4g ZG8gdGhhdCBhZnRlciBNYXJjaCAxMSwgSSBkb24ndCBzZWUgYSBuZWVkDQo+IHRvIGRvIGl0IGJl Zm9yZS4NCj4gDQo+IHRoYW5rcywNCj4gUGV0ZXINCj4gDQo+IA0KPiA+DQo+ID4gVG9ueQ0KPiA+ DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBMc3IgbWFpbGluZyBsaXN0DQo+IExzckBpZXRmLm9yZw0KPiBodHRwczovL3VybGRlZmVuc2Uu cHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtDQo+IDNBX193d3cuaWV0Zi5vcmdfbWFpbG1h bl9saXN0aW5mb19sc3ImZD1Ed0lHYVEmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMA0KPiBVakJYZU1L LW5kYjN2b0RUWGNXem9DSSZyPUNSQjJ0SmlRZVBrMGNULWg1TEdoRVdILQ0KPiBzX3hYWHVwM0h6 dkJTTVJqNVZFJm09OGJaSFltbU1FUmllM0FaeHNZcnZVSF9maHY5SnlUSWtpdmxZMXdpekttcw0K PiAmcz1aUngzSTlhSDU2cS1VbWNZX3RVa091SUF4akdERU1nRV9xZU1QbWVrU2drJmU9DQo= From nobody Thu Mar 7 12:35:48 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 353E0126C87 for ; Thu, 7 Mar 2019 12:35:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 NObxZZOYdBwx for ; Thu, 7 Mar 2019 12:35:45 -0800 (PST) Received: from mail-pf1-x42d.google.com (mail-pf1-x42d.google.com [IPv6:2607:f8b0:4864:20::42d]) (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 B98D91224E8 for ; Thu, 7 Mar 2019 12:35:45 -0800 (PST) Received: by mail-pf1-x42d.google.com with SMTP id d25so12334998pfn.8 for ; Thu, 07 Mar 2019 12:35:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=dcYvAQ/gz58LeyXxkjbNjNIgmUfQissnAn9M5MEH8DE=; b=V1kBvU/972G63pAnzpL/ckrJY7He9J+hm4H3bQOS3YqA1urF0SvWg7lEcc2z2MqYN+ 3gxYfXDN4KMAkeGuybePDuiaI2nd09Dr4CB3ezp9v6izbn7xZN6v4WZObLriI4tS3oTv 3ETwrTqr6EGkZ2BMGNfPmb/vq5dSyS84QBYYNp04Z3TIu/pU/bod9WN/6SMxW4sn4FfT AU9V+a4GnTAGMuLgOzbLwm92m7PIvTAjw7i1glK9KJHSrOqeZEIxfrlOg7hSkOk7OJ+n Jou9TuxVeBKUHefTb7CrRteuTDLGQ1Q3ejPBgS+L17DsCtJvlbTTv88JhI5+32AzUMKy 9d2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=dcYvAQ/gz58LeyXxkjbNjNIgmUfQissnAn9M5MEH8DE=; b=WwFTX3g1pV1YQpcWh/Y9Jc4DSoKPz4+kBeObgab7WwA/YOD8jMhoI6mWN1c6B2KMZl dPtMqurh7gu3gBt0Xq0JVCBVugE5Dux8xMVQOuYrlYLDq1LSFQwGXePxUllQw5yfGQdo 5aNXvExkhFk3kAdTtUKJWymAmpSd3VBDEp1rCfJx5OlxK5FbldVBpN2RIDEsK3vQI+dW 2tAHpEHfP8uW+6xKBDkHOr3Y4WNvqR7Z876yICAl3JehoMDONM+ostVY1Yk7PIP9rFQh Edg8FVQDh2B8h9CacfP5q8W4Fnh7w2zKpummanrR9UVbXHW1vxL0RD72VRtJty8o1Y0+ bJ3g== X-Gm-Message-State: APjAAAXr9xE1WDngGkml/kRwDyPDOhLx8dsTpzKYUBn61rN0Fr+OQQtQ pjLvR8DYcmI34prP1LyA4qs= X-Google-Smtp-Source: APXvYqyjzzIqsv3UaCGJlmbGzFtDs3y14cVl1Kl6zvHdt2wyA10ehR9GuHQg8c3kD2hUKGryQz2BBA== X-Received: by 2002:a62:1346:: with SMTP id b67mr15040971pfj.195.1551990944880; Thu, 07 Mar 2019 12:35:44 -0800 (PST) Received: from [172.22.228.48] ([162.210.130.3]) by smtp.gmail.com with ESMTPSA id e21sm13345923pfh.45.2019.03.07.12.35.43 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Mar 2019 12:35:43 -0800 (PST) Sender: Tony Li From: tony.li@tony.li Message-Id: <4E38AE25-74AD-4DB5-BAA2-0A2CDC5D366B@tony.li> Content-Type: multipart/alternative; boundary="Apple-Mail=_BF320035-A1C0-4DEE-A775-28E9228FE914" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 7 Mar 2019 12:35:41 -0800 In-Reply-To: Cc: "lsr@ietf.org" , Peter Psenak To: Les Ginsberg References: <966E5756-8CEF-47F4-8564-E23D38F0743E@tony.li> <7F522B6C-9D28-4533-8ABD-9F492D9AF26C@tony.li> <2932F33A-1F9E-4C20-A233-E569D8935AE4@tony.li> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Lsr] Open issues with Dynamic Flooding X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 20:35:47 -0000 --Apple-Mail=_BF320035-A1C0-4DEE-A775-28E9228FE914 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Les, > Let me propose that we add something to sections 6.7.5, 6.7.9, and = 6.7.11 like: >=20 > Addition of temporary flooding should be done with caution, as the = addition of excessive connectivity to the flooding topology may trigger = unwanted behavior. Routers SHOULD add temporary flooding in a rate = limited manner, if not configured otherwise. > =20 > [Les:] The first sentence is OK with me. Great! > The second one I think goes beyond anything on which we can claim = consensus. Ok, thank you for saying so. Silence is assent, so what should it say? > Whether adding the first sentence alone is worth a new revision I = think is questionable =E2=80=93 but I certainly would not oppose it. The cost of a new revision is trivial, given that the system is = automated. > Regarding LANs, the encoding for OSPF is more problematic =E2=80=93 = basically we need to identify the value as a router id or a network LSA = id (or something like that). > So, committing to this without consensus has a downside that we might = live to regret. > =20 > I am in agreement with Peter=E2=80=99s position. LANs introduce = additional complexity and it is not clear that including that support is = a real benefit in the topologies in which we expect the flooding = optimizations to be used. > I know you believe real deployments may need this support =E2=80=93 = but what I don=E2=80=99t know is whether we have hard evidence to = support that position. > =20 > I am also wondering whether the following serves us better: > =20 > a)We keep LANs always enabled for flooding > b)The algorithms consider this and are biased towards using LANs when = possible as this is a cheaper way to enable flooding to multiple nodes = than many P2P interfaces. > =20 > IN this way we keep the simplicity of not having to define LAN = behavior/encoding, yet reap benefits in topologies where LANs have a = significant presence. > =20 > Let me know what problems you see with this approach. Again, there are lots of cases where having LANs enabled is sub-optimal. = Parallel LANs, for example. Yes, LANs MAY be a useful way of covering the topology, but without = algorithm specifics, it=E2=80=99s difficult to discuss. In the = simulation work that we=E2=80=99ve done, it=E2=80=99s pretty much a = wash. Sometimes it=E2=80=99s helpful, sometimes it=E2=80=99s redundant. = It very much depends on the topology. You can imagine a LS network where ALL links are still in LAN mode. By = your rules, that completely disabled dynamic flooding. I don=E2=80=99t = think that=E2=80=99s tractable. Not being able to describe the flooding topology precisely is a = significant hindrance and is going to cause misbehavior one way or = another. Suppose that we have nodes A, B, and C. Suppose that AB is a = P2P link and {A, B, C} is a LAN. Now suppose that the topology requests = path AB. What do A and B do? If the LAN was intended, then C is = included. How does C know that? =20 So, I don=E2=80=99t think LANs on all of the time works. And then we = need to be able to specify what=E2=80=99s going on, so that means naming = LANs somehow. Tony --Apple-Mail=_BF320035-A1C0-4DEE-A775-28E9228FE914 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Les,

Let me propose that we = add something to sections 6.7.5, 6.7.9, and 6.7.11 like:
Addition of temporary flooding should be done with caution, = as the addition of excessive connectivity to the flooding topology may = trigger unwanted behavior. Routers SHOULD add temporary flooding in a = rate limited manner, if not configured otherwise.
 
[Les:] The first sentence is OK with me. =


Great!


The second one = I think goes beyond anything on which we can claim = consensus.


Ok, thank you for saying so. =  Silence is assent, so what should it say?


Whether adding the first sentence alone is worth a new = revision I think is questionable =E2=80=93 but I certainly would not = oppose it.


The cost of a new = revision is trivial, given that the system is automated.


 Regarding LANs, the encoding for OSPF is more problematic =E2=80= =93 basically we need to identify the value as a router id or a network = LSA id (or something like that).
So, committing to this without consensus = has a downside that we might live to regret.
 
I am in agreement with = Peter=E2=80=99s position. LANs introduce additional complexity and it is = not clear that including that support is a real benefit in the = topologies in which we expect the flooding optimizations to be used.
I know you believe real deployments may need this support =E2=80= =93 but what I don=E2=80=99t know is whether we have hard evidence to = support that position.
 
I am also wondering whether the following serves us = better:
 
a)We keep LANs always enabled for flooding
b)The algorithms consider this and are biased towards using = LANs when possible as this is a cheaper way to enable flooding to = multiple nodes than many P2P interfaces.
 
IN this way we keep the = simplicity of not having to define LAN behavior/encoding, yet reap = benefits in topologies where LANs have a significant presence.
 
Let me know what = problems you see with this approach.


Again, there are lots of = cases where having LANs enabled is sub-optimal.  Parallel LANs, for = example.

Yes, LANs MAY be a useful = way of covering the topology, but without algorithm specifics, it=E2=80=99= s difficult to discuss.  In the simulation work that we=E2=80=99ve = done, it=E2=80=99s pretty much a wash. Sometimes it=E2=80=99s helpful, = sometimes it=E2=80=99s redundant. It very much depends on the = topology.

You can imagine a LS = network where ALL links are still in LAN mode.  By your rules, that = completely disabled dynamic flooding.  I don=E2=80=99t think = that=E2=80=99s tractable.

Not being = able to describe the flooding topology precisely is a significant = hindrance and is going to cause misbehavior one way or another. =  Suppose that we have nodes A, B, and C.  Suppose that AB is a = P2P link and {A, B, C} is a LAN.  Now suppose that the topology = requests path AB.  What do A and B do?  If the LAN was = intended, then C is included.  How does C know that? =  

So, I don=E2=80=99t think = LANs on all of the time works.  And then we need to be able to = specify what=E2=80=99s going on, so that means naming LANs = somehow.

Tony


= --Apple-Mail=_BF320035-A1C0-4DEE-A775-28E9228FE914-- From nobody Thu Mar 7 13:03:07 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2427112E036 for ; Thu, 7 Mar 2019 13:03:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 VRr0-o1WyBsX for ; Thu, 7 Mar 2019 13:03:04 -0800 (PST) Received: from mail-pf1-x42c.google.com (mail-pf1-x42c.google.com [IPv6:2607:f8b0:4864:20::42c]) (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 B7735128701 for ; Thu, 7 Mar 2019 13:03:04 -0800 (PST) Received: by mail-pf1-x42c.google.com with SMTP id v21so12384771pfm.12 for ; Thu, 07 Mar 2019 13:03:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=8kEgW45A9dEAYyczP6LKcM0jd4kAlKnCmLgzP8Z4+kU=; b=jb5B35vyeWWAmJzh9MOX7oXmK7N3ZMk4QTiHF82S2dpP60i9kezxiMbVM/DtkNvrNe tNFni3hpZpZzyL2orGEh4T9G+OfB4E37txKsE9f7y8ixUvRbYY9V6mehTzgJGr8e3j1R Y73S19vfAZl1oUdkkoKAHXvioKraAFWuVU7BAovEJ6hFCiTq6Uo+cLPAZUkCrjhjT6Wk 5zu2VaJwchSYcCZX31TpAwKKmzuDegljpECxhG3h1j3vxsxnR87P5DpaVyL6UOD7OZLF 86ZMMuEZdvHD7xXGABgP76CzZDFbg3vHcrOD3IoNLT/V3KMUaTlHeITaUxnuQvIx/tXv MBRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=8kEgW45A9dEAYyczP6LKcM0jd4kAlKnCmLgzP8Z4+kU=; b=O+647PMdsc7K74u8jpUzvcl4gp3a04phdGBNFdNRCEMXoJ/OPOVkTqrUR2xwtPAD2y yznzILCKyp0udrhasq25XTXyt55r9JzPYUulA0JgjAm9OUZQUK7JyWmrQFigSsZs3uKX n9bwOpgSSNPxgmLJNZxZL9/JetbmFJkyCIRAFZWvS5RK0h4WBoo/ydPwr6qfzeCF6KaL l/YzPeJw4YHcebA7J5LqiKz0RfVsdKKBDd8PuHcCpzyvTj1irqT+FwkQUYTgh4Zc4uCi N5ij8IuconRQhiuzGO2AAlEspZsd9ns3JmomLFZPUyLDNbZVLZuz0ZVH+a60HOsTO5Ue 3f9w== X-Gm-Message-State: APjAAAXqKifBklqi9EkcFsT90rWhh7K45PsTROPXTsJNACIaXNdanFiR 5e5qPCwAlPkmDxcVYxxi+Ds= X-Google-Smtp-Source: APXvYqziUg+RQKo+cFYzDeZ7lkb06tB0GM9wFxqPechZMijAwfINyVKkdLBXNARfpkrn2AlhIohp0w== X-Received: by 2002:a17:902:40d:: with SMTP id 13mr14144188ple.276.1551992584265; Thu, 07 Mar 2019 13:03:04 -0800 (PST) Received: from [172.22.228.48] ([162.210.130.3]) by smtp.gmail.com with ESMTPSA id b8sm8509009pfi.129.2019.03.07.13.03.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Mar 2019 13:03:03 -0800 (PST) Sender: Tony Li From: tony.li@tony.li Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_C01AEDD8-79D5-4AB6-8BCA-C52BD9F57CDB" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Thu, 7 Mar 2019 13:03:01 -0800 In-Reply-To: Cc: Peter Psenak , "lsr@ietf.org" To: John E Drake References: <966E5756-8CEF-47F4-8564-E23D38F0743E@tony.li> <7F522B6C-9D28-4533-8ABD-9F492D9AF26C@tony.li> <2932F33A-1F9E-4C20-A233-E569D8935AE4@tony.li> <884f0f45-813f-93f0-a63e-f510e5f01ab1@cisco.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Lsr] Open issues with Dynamic Flooding X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 21:03:06 -0000 --Apple-Mail=_C01AEDD8-79D5-4AB6-8BCA-C52BD9F57CDB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > What does 'rate limit' mean in this context? It means that implementations get to decide how quickly they make = temporary additions to the flooding topology. T --Apple-Mail=_C01AEDD8-79D5-4AB6-8BCA-C52BD9F57CDB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii

What does = 'rate limit' mean in this context?


It means = that implementations get to decide how quickly they make temporary = additions to the flooding topology.

T

= --Apple-Mail=_C01AEDD8-79D5-4AB6-8BCA-C52BD9F57CDB-- From nobody Thu Mar 7 13:51:48 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98A261311B8 for ; Thu, 7 Mar 2019 13:51:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=fzPT/OJb; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=lpRhKfAy 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 QR9-FIwN0GRk for ; Thu, 7 Mar 2019 13:51:45 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B45101311A7 for ; Thu, 7 Mar 2019 13:51:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10264; q=dns/txt; s=iport; t=1551995504; x=1553205104; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=7RIVMpCpNh5t5O//Grg8lF4Ikmntfs3PvqXhN+rygNo=; b=fzPT/OJb5Ndu7xtsmM+9L7OZRP74ujEd2h97G+YjANI2tMaBaDNZhX2L eI9C/99sr9EEToXIiZf9fgbjqjFzg2M/anr0sRigARUieaJXi3OqUq5Ci WDmLZu0In2mp+LdrcRJqi8YPbWORq3L5d7BffIkTduD6IkEuzGabwW0p8 4=; IronPort-PHdr: =?us-ascii?q?9a23=3AsB2srRAnXDt5+r5AcdzhUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qs03kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuI//sdCY3BstqX15+9Hb9Ok9QS47z?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AoAAAbkoFc/5pdJa1kHAEBAQQBAQc?= =?us-ascii?q?EAQGBUQcBAQsBgQ0vUANodAQLJ4QJg0cDhFCKY5UHhXOBJANUCgEBASyEQAI?= =?us-ascii?q?XhB4iNAkNAQEDAQEHAQMCbRwBC4VLBiMKEwEBNwEPAgEIQgICAjAlAgQODYM?= =?us-ascii?q?bgRFMAxUBAqA8AooUcYEvgngBAQWEfBiCCwiBLwGLKxeBQD+BV4IeLoRaKYM?= =?us-ascii?q?IMYImjEmEBpNICQKTHJM1inGSOAIEAgQFAg0BAQWBRziBVnAVgyeCCoNuilN?= =?us-ascii?q?ygSiKCSqCIwEB?= X-IronPort-AV: E=Sophos;i="5.58,453,1544486400"; d="scan'208,217";a="531610024" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Mar 2019 21:51:43 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x27Lpgwo026315 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 7 Mar 2019 21:51:43 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.1473.3; Thu, 7 Mar 2019 15:51:42 -0600 Received: from xhs-rtp-002.cisco.com (64.101.210.229) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Thu, 7 Mar 2019 15:51:41 -0600 Received: from NAM04-BN3-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.1473.3 via Frontend Transport; Thu, 7 Mar 2019 16:51:41 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=7RIVMpCpNh5t5O//Grg8lF4Ikmntfs3PvqXhN+rygNo=; b=lpRhKfAyMC0aZbkrAhxiI4Tr1YxpBNmQ/v59GvVtiwcTGcNaQP+swhDnF+J/x1FcJdCvVjRL25BBsTNhJIGFF5VS28MNhnQGSBJalI15SJGUoMST4g2Pnrc3YbZBY95SiufNdZVfUJJ8VT+yGxZH7wHI8Roaf9upet0mR0Z+CXQ= Received: from BYAPR11MB3638.namprd11.prod.outlook.com (20.178.237.19) by BYAPR11MB3479.namprd11.prod.outlook.com (20.177.187.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.18; Thu, 7 Mar 2019 21:51:40 +0000 Received: from BYAPR11MB3638.namprd11.prod.outlook.com ([fe80::b414:f534:f20a:a26d]) by BYAPR11MB3638.namprd11.prod.outlook.com ([fe80::b414:f534:f20a:a26d%3]) with mapi id 15.20.1686.016; Thu, 7 Mar 2019 21:51:40 +0000 From: "Les Ginsberg (ginsberg)" To: "tony.li@tony.li" CC: "lsr@ietf.org" , "Peter Psenak (ppsenak)" Thread-Topic: [Lsr] Open issues with Dynamic Flooding Thread-Index: AQHU0rNloYabtT6NFku+G8W9bkhmEKX8p2UAgACQ6YCAAALpAIAABY6AgAA9MgCAAAYKgIAABbWAgAAGcQCAAt1tAIAABduQgAAx04CAABNcsA== Date: Thu, 7 Mar 2019 21:51:40 +0000 Message-ID: References: <966E5756-8CEF-47F4-8564-E23D38F0743E@tony.li> <7F522B6C-9D28-4533-8ABD-9F492D9AF26C@tony.li> <2932F33A-1F9E-4C20-A233-E569D8935AE4@tony.li> <4E38AE25-74AD-4DB5-BAA2-0A2CDC5D366B@tony.li> In-Reply-To: <4E38AE25-74AD-4DB5-BAA2-0A2CDC5D366B@tony.li> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ginsberg@cisco.com; x-originating-ip: [2001:420:30d:1254:8012:e90b:7af9:9084] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f580e480-2f85-43f3-abde-08d6a34714a4 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BYAPR11MB3479; x-ms-traffictypediagnostic: BYAPR11MB3479: x-ld-processed: 5ae1af62-9505-4097-a69a-c1553ef7840e,ExtAddr x-microsoft-exchange-diagnostics: =?utf-8?B?MTtCWUFQUjExTUIzNDc5OzIzOmx3QlpydFkvLzRIdHJUcGVHVklsTmJ3bGFG?= =?utf-8?B?cnRxWFdoZzBVN0k1dE1QdjdadXd5aDhqaWgzbDR4dzVKZUFCYXhzRnNoR2pO?= =?utf-8?B?WjNCOXlnMU5hVEZTS0ExYVk0RjJ0RUgwWlBTY3U0QjQ4RGhMV1AxSFFaRUhC?= =?utf-8?B?Q1QxekpncGtaSW1RYTFTUWIwMGdsZzZVK1p2eVFXOWlSQzFlUWVrUnJZTDYz?= =?utf-8?B?ZEpIRFZRT2F5T1crQmVZOFU0VVVhRVVna3JObmpXbzNmNExGN2lRZEc4UEtp?= =?utf-8?B?d3l2U0U2YlJZaHg4dWVxOER6YVRhQ1AyVmJ6dS81WWk5dWFBUElFSnppcm5o?= =?utf-8?B?cnMwb2gvY2QzUnZjL3pvWktnMWxBUERzZVBCc0krdTBaeTNSRWN1ZUQzd2pt?= =?utf-8?B?aVYvdWMzNEF5ZkJEaU9QNHdBT2tMOHRDb1JMa09CbHBZUkZTSkJ5aUtEQ2l5?= =?utf-8?B?WE5mVzJTVnZyMTQ0YnhCdWEzSnh3YUdLUEQ1dzM1eG9zZVVUczJ2TVBMKzBq?= =?utf-8?B?aWRyczh3ZW13MWFmejU5OHgrT0ZaNURSc1JkWWJqcTdnaVpzazk1UHo5eDJN?= =?utf-8?B?ZTc3VGlvdHlyc21hN3g2SUQ5cFdMcDBFRlpBVTI5K1R4U1I4TW9RU0pMZ0o5?= =?utf-8?B?Q2pyZDVhMEdsNmhoOGdWSDVuLzErblRlYUp6akNBNkx3Rk1Fc1N3eHlNZFly?= =?utf-8?B?R0FadW9ldlZSVlY3NXZmWTVYVEVyY2lBVkZ1UGI3WWhFNDBDbnBLZmgyWFM5?= =?utf-8?B?eXBtRDIvcXU1ZUJCMmVpZ09TaUlIeGh4bkpSZ2VPenN6R2djU0RZdHJtcEZw?= =?utf-8?B?RHhTbG9NNlkzd0RoR3BOTDE5c1lOYlhwbURHWEZnYjZPM1dEdVFYVE5hanUr?= =?utf-8?B?b0ZSWWhkMUw1SnNMKzlhZ1VSZm5RYTN2UHhlR0xGYUNXclpqL2tpVy92bzNB?= =?utf-8?B?ZGlrUWxOazJwbTlqNWZlQkoya21rYmRNQTRoak91ZHM2NVZJaTE2U2p1aDVi?= =?utf-8?B?cVAxNEJTMFByQmk3N0lJcVhCUnNTQlZ4aFF5MTJ5SkJZUFNXZWpwbjNMbDZw?= =?utf-8?B?UEJ5ZHg1Z0ZGRW9UOXFpSGFjNHNyd081SThLNUJnS2toeG5ocndCNTgzbzFu?= =?utf-8?B?UVUzRzBURXpDTS8ySWhqVUVGRnZZayt2M3NmMUl4dy9kaEhWUmN5a0NQVW5x?= =?utf-8?B?U0toZTNSb2pCT0V3YTNTODRJMm1iYlBGZEZiSzI3YW9jMUNDMXROLzE4ZU5k?= =?utf-8?B?Sm4rWkZQbmttM0JzanRFQWVqNjlGamYweGtuYmtySVBLYXZBenI1ZE9ETlhB?= =?utf-8?B?YzE4RytXMGwzcVdDamhtbVBuQVZRVFJOY3U0THFsUDVsaVdlN1NrdmpTc2lN?= =?utf-8?B?RDQ3S2d1WUxITTAvZlA3ZjVaTlhHN1VUczVpclJpYThGcitBK3FtVEE1eU5r?= =?utf-8?B?WGY1UW50Mmt3TGVUcEphdzBRM3MvR3hSVzFXYm9OY0ZGeFJWVDRYU1hBcGpk?= =?utf-8?B?Zzl0aEgvcmdzdkZUYVRCenR2NXBucUU0eTFjOVpaN3ZTeUpvNHRRZEV3Vzg3?= =?utf-8?B?TUhYcDlCY0lSUnJ2Z0tNbWEwMDVIcjBqUFkwOGlVc21GSHBMRWhpOWhONTF4?= =?utf-8?B?dFNpVlQwcGczblBNQUE3M1BTRmxFR3hNWDB2dFZITCs0Z3doTWNXVXFHU2tx?= =?utf-8?B?akxWUzNKYWZpSEk0MW9aTDY0Q3NtcGJwQjluYnFwZXFmWmZvdUR4QStuYnZk?= =?utf-8?B?N3NuR1NoNDJCYW5lcjFqK054RW44MlhIRWRUWnF2ejVGaVZWZFZqMGdFVWlK?= =?utf-8?Q?UhRO7pW7CMCg+?= x-microsoft-antispam-prvs: x-forefront-prvs: 096943F07A x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(136003)(376002)(346002)(39860400002)(189003)(199004)(2351001)(54896002)(97736004)(106356001)(6436002)(33656002)(316002)(5640700003)(229853002)(2501003)(14444005)(55016002)(81156014)(8676002)(8936002)(6306002)(256004)(9686003)(86362001)(4326008)(102836004)(7736002)(186003)(81166006)(105586002)(54906003)(6506007)(74316002)(71190400001)(71200400001)(14454004)(6916009)(25786009)(2906002)(76176011)(7696005)(107886003)(486006)(790700001)(68736007)(93886005)(478600001)(99286004)(6116002)(53936002)(5660300002)(52536013)(46003)(6246003)(446003)(11346002)(476003); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3479; H:BYAPR11MB3638.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: hC/J6J5oIDZVBCxJW4umK8T+yZ/P//qaCb2ZwFL3qVD/FBmhWmcMmy5DSPnzseoZ86UjLUStzxjbe0oCJ6k5B1Tw7HsV2LOEumZBQMHASHrN5Gv4Rg+liI/Cm/zMR6jo9xrG624K4akY8AdrL5m7cJgawNsf6qutOnWFF6YX+VZLZpQ4hVhJvFtJY82EFqzZWAdGQijrRnzoqmK+2kExyGro3miy/zSRBSRpnWCPiPnm4wdTemK6/Ri0Q8i65NdBh9PcPwnR9Et6UGOTzLFBc1DojIuqOR/a2AhTGNGp+4Fq7RmklX97seEEXGbPFWbtHB0DE/Jn3hoPsXH+kPTH+OJHIrir/42PZCso8UqHubqsp5COf5RiclmUPBEVwgg9SjQ64F9v8AKtck6yhz4ZVUc4xGmXzxyV5uGcCwApNx0= Content-Type: multipart/alternative; boundary="_000_BYAPR11MB36384ECC24C6984BC708183FC14C0BYAPR11MB3638namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: f580e480-2f85-43f3-abde-08d6a34714a4 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Mar 2019 21:51:40.2184 (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-Transport-CrossTenantHeadersStamped: BYAPR11MB3479 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: Subject: Re: [Lsr] Open issues with Dynamic Flooding X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 21:51:47 -0000 --_000_BYAPR11MB36384ECC24C6984BC708183FC14C0BYAPR11MB3638namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VG9ueSAtDQoNCg0KTGV0IG1lIHByb3Bvc2UgdGhhdCB3ZSBhZGQgc29tZXRoaW5nIHRvIHNlY3Rp b25zIDYuNy41LCA2LjcuOSwgYW5kIDYuNy4xMSBsaWtlOg0KDQpBZGRpdGlvbiBvZiB0ZW1wb3Jh cnkgZmxvb2Rpbmcgc2hvdWxkIGJlIGRvbmUgd2l0aCBjYXV0aW9uLCBhcyB0aGUgYWRkaXRpb24g b2YgZXhjZXNzaXZlIGNvbm5lY3Rpdml0eSB0byB0aGUgZmxvb2RpbmcgdG9wb2xvZ3kgbWF5IHRy aWdnZXIgdW53YW50ZWQgYmVoYXZpb3IuIFJvdXRlcnMgU0hPVUxEIGFkZCB0ZW1wb3JhcnkgZmxv b2RpbmcgaW4gYSByYXRlIGxpbWl0ZWQgbWFubmVyLCBpZiBub3QgY29uZmlndXJlZCBvdGhlcndp c2UuDQoNClRoZSBzZWNvbmQgb25lIEkgdGhpbmsgZ29lcyBiZXlvbmQgYW55dGhpbmcgb24gd2hp Y2ggd2UgY2FuIGNsYWltIGNvbnNlbnN1cy4NCg0KDQpPaywgdGhhbmsgeW91IGZvciBzYXlpbmcg c28uICBTaWxlbmNlIGlzIGFzc2VudCwgc28gd2hhdCBzaG91bGQgaXQgc2F5Pw0KDQpbTGVzMjpd IEkgYW0gbm90IHByZXBhcmVkIHRvIHNheSBhdCB0aGUgbW9tZW50IOKAkyB3aGljaCBpcyB3aHkg SSB3YXMgc3VnZ2VzdGluZyBpdOKAmXMgdG9vIHNvb24gdG8gYWRkIHRoaXMuDQoNCg0KTm90IGJl aW5nIGFibGUgdG8gZGVzY3JpYmUgdGhlIGZsb29kaW5nIHRvcG9sb2d5IHByZWNpc2VseSBpcyBh IHNpZ25pZmljYW50IGhpbmRyYW5jZSBhbmQgaXMgZ29pbmcgdG8gY2F1c2UgbWlzYmVoYXZpb3Ig b25lIHdheSBvciBhbm90aGVyLiAgU3VwcG9zZSB0aGF0IHdlIGhhdmUgbm9kZXMgQSwgQiwgYW5k IEMuICBTdXBwb3NlIHRoYXQgQUIgaXMgYSBQMlAgbGluayBhbmQge0EsIEIsIEN9IGlzIGEgTEFO LiAgTm93IHN1cHBvc2UgdGhhdCB0aGUgdG9wb2xvZ3kgcmVxdWVzdHMgcGF0aCBBQi4gIFdoYXQg ZG8gQSBhbmQgQiBkbz8gIElmIHRoZSBMQU4gd2FzIGludGVuZGVkLCB0aGVuIEMgaXMgaW5jbHVk ZWQuICBIb3cgZG9lcyBDIGtub3cgdGhhdD8NCg0KW0xlczI6XSBTaW5jZSBvdXIgY3VycmVudCBl bmNvZGluZyBkb2VzIG5vdCBzdXBwb3J0IExBTnMsIEFCIGNhbiBvbmx5IG1lYW4gUDJQIOKAkyBt ZWFuaW5nIHRoZSBub24tcHJlc2VudCBwc2V1ZG8tbm9kZSBJRCBpcyBhc3N1bWVkIHRvIGJlIDAu DQpOb2RlcyB3b3VsZCBuZWVkIHRvIHVuZGVyc3RhbmQgdGhhdCByZWFjaGFibGUgTEFOcyAoYXMg YWR2ZXJ0aXNlZCBpbiBwc2V1ZG8tbm9kZSBMU1BzIGFuZCB0aGUgcHNldWRvLW5vZGUgbmVpZ2hi b3JzIGFkdmVydGlzZWQgaW4gbm9uLXBzZXVkby1ub2RlIExTUHMpIGFyZSBhbHdheXMgcGFydCBv ZiB0aGUgZmxvb2RpbmcgdG9wb2xvZ3kuDQoNCiAgICBMZXMNCg== --_000_BYAPR11MB36384ECC24C6984BC708183FC14C0BYAPR11MB3638namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAz IDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAx NSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFs LCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90 dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3 IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0K YTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0 eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1z b25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1l Om1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGlu Ow0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250 LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNw YW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERl ZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9 DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGlu IDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlv bjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVs dHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0t W2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlk bWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2Vu ZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJw dXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Ub255IC08bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y ZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDQuMHB0Ij4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0K PGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl OjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+TGV0 IG1lIHByb3Bvc2UgdGhhdCB3ZSBhZGQgc29tZXRoaW5nIHRvIHNlY3Rpb25zIDYuNy41LCA2Ljcu OSwgYW5kIDYuNy4xMSBsaWtlOjxicj4NCjxicj4NCkFkZGl0aW9uIG9mIHRlbXBvcmFyeSBmbG9v ZGluZyBzaG91bGQgYmUgZG9uZSB3aXRoIGNhdXRpb24sIGFzIHRoZSBhZGRpdGlvbiBvZiBleGNl c3NpdmUgY29ubmVjdGl2aXR5IHRvIHRoZSBmbG9vZGluZyB0b3BvbG9neSBtYXkgdHJpZ2dlciB1 bndhbnRlZCBiZWhhdmlvci4gUm91dGVycyBTSE9VTEQgYWRkIHRlbXBvcmFyeSBmbG9vZGluZyBp biBhIHJhdGUgbGltaXRlZCBtYW5uZXIsIGlmIG5vdCBjb25maWd1cmVkIG90aGVyd2lzZS48L3Nw YW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMxRjQ5N0Qi PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv YmxvY2txdW90ZT4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpu b25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBw dCI+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPlRoZSBzZWNvbmQgb25lIEkgdGhpbmsgZ29lcyBiZXlvbmQgYW55dGhpbmcg b24gd2hpY2ggd2UgY2FuIGNsYWltIGNvbnNlbnN1cy48L3NwYW4+PC9pPjwvYj48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5PaywgdGhhbmsgeW91IGZvciBzYXlpbmcgc28uICZuYnNwO1NpbGVuY2Ug aXMgYXNzZW50LCBzbyB3aGF0IHNob3VsZCBpdCBzYXk/PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PGk+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPltMZXMyOl0gSSBhbSBub3QgcHJlcGFyZWQg dG8gc2F5IGF0IHRoZSBtb21lbnQg4oCTIHdoaWNoIGlzIHdoeSBJIHdhcyBzdWdnZXN0aW5nIGl0 4oCZcyB0b28gc29vbiB0byBhZGQgdGhpcy48L3NwYW4+PC9pPjwvYj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Ob3QgYmVpbmcgYWJsZSB0byBkZXNjcmliZSB0aGUg Zmxvb2RpbmcgdG9wb2xvZ3kgcHJlY2lzZWx5IGlzIGEgc2lnbmlmaWNhbnQgaGluZHJhbmNlIGFu ZCBpcyBnb2luZyB0byBjYXVzZSBtaXNiZWhhdmlvciBvbmUgd2F5IG9yIGFub3RoZXIuICZuYnNw O1N1cHBvc2UgdGhhdCB3ZSBoYXZlIG5vZGVzIEEsIEIsIGFuZCBDLiAmbmJzcDtTdXBwb3NlIHRo YXQgQUIgaXMgYSBQMlAgbGluayBhbmQge0EsIEIsIEN9IGlzIGEgTEFOLg0KICZuYnNwO05vdyBz dXBwb3NlIHRoYXQgdGhlIHRvcG9sb2d5IHJlcXVlc3RzIHBhdGggQUIuICZuYnNwO1doYXQgZG8g QSBhbmQgQiBkbz8gJm5ic3A7SWYgdGhlIExBTiB3YXMgaW50ZW5kZWQsIHRoZW4gQyBpcyBpbmNs dWRlZC4gJm5ic3A7SG93IGRvZXMgQyBrbm93IHRoYXQ/ICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bTGVzMjpdIFNpbmNlIG91ciBj dXJyZW50IGVuY29kaW5nIGRvZXMgbm90IHN1cHBvcnQgTEFOcywgQUIgY2FuIG9ubHkgbWVhbiBQ MlAg4oCTIG1lYW5pbmcgdGhlIG5vbi1wcmVzZW50IHBzZXVkby1ub2RlIElEIGlzIGFzc3VtZWQg dG8gYmUgMC48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5Ob2RlcyB3b3VsZCBuZWVk IHRvIHVuZGVyc3RhbmQgdGhhdCByZWFjaGFibGUgTEFOcyAoYXMgYWR2ZXJ0aXNlZCBpbiBwc2V1 ZG8tbm9kZSBMU1BzIGFuZCB0aGUgcHNldWRvLW5vZGUgbmVpZ2hib3JzIGFkdmVydGlzZWQgaW4g bm9uLXBzZXVkby1ub2RlIExTUHMpDQogYXJlIGFsd2F5cyBwYXJ0IG9mIHRoZSBmbG9vZGluZyB0 b3BvbG9neS48bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxpPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsmbmJzcDsgTGVzPG86cD48L286cD48 L3NwYW4+PC9pPjwvYj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9k eT4NCjwvaHRtbD4NCg== --_000_BYAPR11MB36384ECC24C6984BC708183FC14C0BYAPR11MB3638namp_-- From nobody Thu Mar 7 18:37:53 2019 Return-Path: X-Original-To: lsr@ietf.org Delivered-To: lsr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 444BC12AF79; Thu, 7 Mar 2019 18:37:52 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lsr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lsr@ietf.org Message-ID: <155201267223.5419.13285476509262180235@ietfa.amsl.com> Date: Thu, 07 Mar 2019 18:37:52 -0800 Archived-At: Subject: [Lsr] I-D Action: draft-ietf-isis-yang-isis-cfg-35.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 02:37:52 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Link State Routing WG of the IETF. Title : YANG Data Model for IS-IS Protocol Authors : Stephane Litkowski Derek Yeung Acee Lindem Jeffrey Zhang Ladislav Lhotka Filename : draft-ietf-isis-yang-isis-cfg-35.txt Pages : 111 Date : 2019-03-07 Abstract: This document defines a YANG data model that can be used to configure and manage IS-IS protocol on network elements. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-isis-yang-isis-cfg/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-isis-yang-isis-cfg-35 https://datatracker.ietf.org/doc/html/draft-ietf-isis-yang-isis-cfg-35 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-isis-yang-isis-cfg-35 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 Mar 8 04:22:11 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B347D12865D for ; Fri, 8 Mar 2019 04:22:09 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 b4SBEuOJLvy8 for ; Fri, 8 Mar 2019 04:22:07 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id D985A1279A1 for ; Fri, 8 Mar 2019 04:22:07 -0800 (PST) Received: from tops.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPS id 360F660521; Fri, 8 Mar 2019 07:22:07 -0500 (EST) User-agent: mu4e 1.1.0; emacs 26.1 From: Christian Hopps To: lsr@ietf.org Cc: Robert Raszuk , Peter Psenak , Tony Li Date: Fri, 08 Mar 2019 07:22:06 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: [Lsr] IS-IS lite (an aside).. X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 12:22:10 -0000 --=-=-= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable tony.li@tony.li writes: >Robert Raszuk writes: >> >> See TORs are one case .. but there are ideas to run dynamic protocols to= the hosts too. I have heard there was even a volunteer to write ISIS-lite = to be used on hosts :) > > I would=E2=80=A6. discourage that concept. Perhaps Robert is referring to when homenet was considering using IS-IS ins= tead of a brand new protocol (babel) for use in the homenet. The proposed s= olution for very simple devices (e.g. thermostats or anything w/o much ram = etc) was to use the overload bit. This wasn't just for hosts though, but fo= r very small devices that could still serve as simple router for a network = behind them. https://www.ietf.org/archive/id/draft-mrw-homenet-rtg-comparison-02.txt Christian Franke coded up "tinyisis" in 1500 lines of C code. :) https://git-us.netdef.org/projects/OSR/repos/tinyisis/browse/tinyisis.c Thanks, Chris. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAlyCXm4ACgkQLh2DDte4 MCXlwBAAhC0aqVT/auhbkCi+vUrtmE/vRPfRutb8Xcd4mf5+4WLNCZpM3CP0309a axi49RK4ebtj6o9YhReQmocVA+dcJqMkw+Cq0A4nmAUgNs1VPmjT0n0CIG+56A0O kInu2orxSaVGJUCwttUxZ7OS5aK4nf4ZYKTbgT0QznXk/xR/F1DKB9xZNw8hao41 JfzTwqoafrtiP7BYGUxRR+aPkfSBdgkr8/f+g+2/xSb2BmV+qYKBYgd85KGRKVR0 fFW+LY0F/M12ONeqT2YRSM/lQV6cvnvRRVvOVkm1hY3H+kYkG4Kk1KRGlQZCv1Vx Ict3AzXnaDSc2pTrJ+Ne2xGKu+oDpH7Aajj4Cf2SmwAJ6TDDYPSsHWjWL2E9UCNC cbW53wzobS7dzrRSmLMpATGihKWjI2Rn0GFaYB2MNB0rXLvVOaGEsyrPHLIMtNRj T9DTga5ksMCRNKLJI0SpmAjiFx7159JRJczhnxgqf4FuJIIrHeKrksgXKFEY7RpH CjsRb2VSwhWhmQTOf3m4vmKe5VoPUo8OUGEdX7MwGF8nIDJl3qqozifOxocv981n J9Nmho8oBEsfP2Z5x6ymBqt+FWg8smN46e4Y+N+9AAMd9TTU0n5aCXChuoPTnSUG Ez/IogmDFGAr01fE6SUoxyVXN9Uq6Gal/JaBkRyUxpUni4qVCy8= =olwP -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Mar 8 04:29:53 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2369127980 for ; Fri, 8 Mar 2019 04:29:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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=gb8FtzRG; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Unrc9dUM 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 PGgtzDAvuK0H for ; Fri, 8 Mar 2019 04:29:45 -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 44C831276D0 for ; Fri, 8 Mar 2019 04:29:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1882; q=dns/txt; s=iport; t=1552048185; x=1553257785; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=OaJcGYF7RWUbd4621nLIuIFMDDbNlegxdyy7tM+H6mU=; b=gb8FtzRGBdJl3r07X5Yn6xXOlxFItYTZvtBS+pHjKry0CzpAwL+6nWHr k77cIP+JvAAytA9w6fCtEc3YaBVWV7FJE07rKvI1V74YfggsH7pUQIPR0 +mJYPEYTH7sGu4vKHh+ehPyYy2MFieRF2tH/6i+7SG51prikbpWAaEuRn 0=; IronPort-PHdr: =?us-ascii?q?9a23=3AoUaTKxFbGpledN1SklGGOZ1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4w0Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBjyJ/PnRyc7B89FElRi+iLzPA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAAC+X4Jc/5ldJa1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgTxQA2h0BAsnCoN/g0cDhFCKY5p9gSQ?= =?us-ascii?q?DVAsBASMJg3pGAheEHiI0CQ0BAQMBAQcBAwJtHAyFSwYjEQwBATcBDwIBCA4?= =?us-ascii?q?MAiYCAgIwFRACBAENBRuDBwGBXQMVAQIMnm8CigQQcYEvgngBAQWFBBiCCwM?= =?us-ascii?q?FgQskAYsrF4F/gRAoH4JMgx4ChGsxgiaMS5dVCQKHTYs6GZM4ineFY4xeAgQ?= =?us-ascii?q?CBAUCDQEBBYFHOIFWcBVlAYJBggqDboNGgU6FP3IBgSeNUQGBHgEB?= X-IronPort-AV: E=Sophos;i="5.58,455,1544486400"; d="scan'208";a="243752371" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Mar 2019 12:29:44 +0000 Received: from XCH-RCD-016.cisco.com (xch-rcd-016.cisco.com [173.37.102.26]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x28CTiIF012672 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 8 Mar 2019 12:29:44 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-RCD-016.cisco.com (173.37.102.26) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 8 Mar 2019 06:29:43 -0600 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 8 Mar 2019 07:29:42 -0500 Received: from NAM05-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.1473.3 via Frontend Transport; Fri, 8 Mar 2019 06:29:42 -0600 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=OaJcGYF7RWUbd4621nLIuIFMDDbNlegxdyy7tM+H6mU=; b=Unrc9dUMkDWtrNpOnqLy/AY1Ykerk9xcX4p0Fn+fItlpJfC97g+rYAdzsi0PICxW1J4C3XG381nLJlV+2QlSVyhRIF9g2kWlWKgtLFFniQ7b3+FSZTVNNg26OZWIudOfhozqUbiF0A8u5mLglB2dhBsNlyBa50DZJ7d0eDPcYgY= Received: from BN8PR11MB3683.namprd11.prod.outlook.com (20.178.220.74) by BN8PR11MB3620.namprd11.prod.outlook.com (20.178.219.87) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.18; Fri, 8 Mar 2019 12:29:41 +0000 Received: from BN8PR11MB3683.namprd11.prod.outlook.com ([fe80::c62:f0b7:72a0:e853]) by BN8PR11MB3683.namprd11.prod.outlook.com ([fe80::c62:f0b7:72a0:e853%4]) with mapi id 15.20.1686.018; Fri, 8 Mar 2019 12:29:41 +0000 From: "Acee Lindem (acee)" To: Christian Hopps , "lsr@ietf.org" CC: Tony Li , Robert Raszuk , "Peter Psenak (ppsenak)" Thread-Topic: [Lsr] IS-IS lite (an aside).. Thread-Index: AQHU1amkJWJ0bz9x80uHuTu3rZTKwaYBVg4A Date: Fri, 8 Mar 2019 12:29:40 +0000 Message-ID: <2F0FB596-D717-4D8C-B01A-55CBEE3B7B06@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=acee@cisco.com; x-originating-ip: [173.38.117.94] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6a87251e-1f83-4b34-f4fb-08d6a3c1bcc5 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:BN8PR11MB3620; x-ms-traffictypediagnostic: BN8PR11MB3620: x-ms-exchange-purlcount: 2 x-ld-processed: 5ae1af62-9505-4097-a69a-c1553ef7840e,ExtAddr x-microsoft-exchange-diagnostics: =?utf-8?B?MTtCTjhQUjExTUIzNjIwOzIzOkVuWWFrTjdqNVNYcG5McnpWTE5GVWx3bEhV?= =?utf-8?B?blY3dmRnY1M4QjY1V3NoUzhVeVBnbHBsRXBJc0Z3amtyVWZLTWhmTXFJeWg2?= =?utf-8?B?UnlHZUkycVcwaGxtdmdtMnl3ZXdHT2NUQVVWTTFMcDdtTFN1TWhXM29ELzg3?= =?utf-8?B?enh4MlV3MjB6OHpkYlRQRDV2TlpvdFRCREpTL0RrVGJVb0NkelE4VWF4SmJ4?= =?utf-8?B?d3Q2VUI4a2czNWJKSTcxRC8reENQNkFnL3YyMFhFcXhqK1BJSTVyV1NNVzMv?= =?utf-8?B?STBZeHpQa0NkbVdydFI4WUJxZTZyQUlXaTUwaTBtdTBWa1ZkUWNhQStqZjdY?= =?utf-8?B?MkJZWG5iWk5NNWxBYndrVm5IdjFCdVJmcjAwT2lOREQrUjE4ZWZaVVpnK1ll?= =?utf-8?B?OTB6VlB6WGlvUytQelNFeVBLZ1FWd29kZ053UzFVb0dUNW90ZXdhSFUwbzhs?= =?utf-8?B?ZWZDS1RETUIyMGR1TklBSEpHay9FN0YvQzlXUW00NERsM0F4UkNmWTRlOVo5?= =?utf-8?B?QnNVNnAyYU1vNGJxa3BFUmliUjhaWW1GNldCOTREb0ptblpuSXB5WFBiRVFY?= =?utf-8?B?ZVNWK3RVMkFsd0RTNjNtYUxSTmgrR0ZYT29YS0FxS3M1U09NSEZneHpaQ0pT?= =?utf-8?B?dGVFbzRoMlhJakdEQjNPZE9HN2YvK3d0bTQrTkVCUjNERHZZOXZKbHU4bTVD?= =?utf-8?B?U3VGWHJGRlhmWWlNZFpKU21Vd2RrSXNLVzE0MENpWGhmQXRRb01NM1JuR3Jo?= =?utf-8?B?L3d1ZjErWXcrcnNTMGlISis2K1RPOFZJOFBVWmFHZG53cFhVZ2xnVjg3RHlt?= =?utf-8?B?M3ZCdlE4cEhDSnYzajdwNnRGMGhqQjEwTEJYRk5kVEErYUpjb3dGcW1OaW9G?= =?utf-8?B?WWFkZjFGL2lPTlZ5MTRWUHZ4RnloZHh3LytkOTFaeWg0d1V4QTNpS0FlbWNv?= =?utf-8?B?L2huN3cwOFQzMXM0QkhkK1kyVVdLeTZxQ3UwMVpFWHRTTmtVNzROcCs5ODRX?= =?utf-8?B?U2I3UnQweFVReXNQenpCQzZRYXVmUmlzS29kalRTYUJTSWhob2JFS2ZhS0Rn?= =?utf-8?B?LytQQUQzOGF2MUZYZWhTZFUrUi9oejVJcjU4Z3c4OElZN3hScWxSRkFvTkhF?= =?utf-8?B?YlpCYmlUZU1xRlpTSExVeTNwS1hHdzh5NEtadUVHTjhoVnZFdjZaeTROTFVD?= =?utf-8?B?YzdRc1E5bGZub1J6em5uaUQ0aHhIRjBLQm1qSGVsNThKVHY3UlplcUkydS9Y?= =?utf-8?B?QnYrQ1pSWHUvMFgrVkEraXBveGFaYUZrdTVkVFhsdVk2QlVYdzNkbnhHcStZ?= =?utf-8?B?UGhRY2RSS1VnU1BBSll0UmNWQ1g4NUQ5UzRGZmVZRVdlS256OHY0ZCtLUFVY?= =?utf-8?B?anIwSGxOV0JCV2ROc05DVDdYSjJ4TERSOXJEdUkyMUd4QUpmWmVGM25zZVBI?= =?utf-8?B?ZjNHOForZnpib3ZTL1dyZUJJeDNiSE5yM0dxcUNIbE5wSTRvRUJTMlBzak8y?= =?utf-8?B?dlY4bHNmT3lQOE1ldGpoZU1Dc09rb3JkK0JXMWRNK00xOTN0WW5pWGFnaTJ4?= =?utf-8?B?SFlpUzk0LzJpQ1pXbmx2SHZFbnJRMk5hbjVBTUd6WGRxWHBRMDlxQ0hjNUNs?= =?utf-8?B?MXFQTFp6RE1aYjVjTzBmUFZSZ2dVcWgwcGhmQyswMXkrZnB4TTZXVkVTeTg4?= =?utf-8?B?MjNJa3FNRXZxQ0JQOWhjNEswT1I2aURPVE1pd0dnbjVvcUI3TWZEcTdMOEJz?= =?utf-8?B?dzR2Nm5PUitHbFplT05qb3ZJcXQrMUQ4Q1Q5dTdhajk0aXpTbUkrY29MYXBy?= =?utf-8?Q?XQvnjjB0lqOOu?= x-microsoft-antispam-prvs: x-forefront-prvs: 0970508454 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(346002)(396003)(376002)(136003)(199004)(189003)(6486002)(229853002)(6436002)(6306002)(36756003)(6512007)(106356001)(4326008)(105586002)(66574012)(76176011)(256004)(66066001)(6506007)(97736004)(86362001)(83716004)(2501003)(26005)(25786009)(5660300002)(102836004)(53936002)(8676002)(81156014)(6246003)(305945005)(81166006)(8936002)(110136005)(11346002)(99286004)(7736002)(14454004)(71200400001)(478600001)(33656002)(186003)(68736007)(3846002)(6116002)(966005)(71190400001)(316002)(54906003)(82746002)(107886003)(486006)(2616005)(446003)(2906002)(476003); DIR:OUT; SFP:1101; SCL:1; SRVR:BN8PR11MB3620; H:BN8PR11MB3683.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 22rIZ38QPAH3vDAh9CjwPw5+QI9bcPcgPZvjelABwMVXZ/bz8UVocnLS2Mq5zColwVMAUU/MOMW3wKD6GJofiwGs6XnYI+Q7CDphCTVsu1Mtf8mXnkjBiOKmAG/TuP+TmR11G7gA9hV9MNTMu25po7ODfQFrqVgpbIs5yQnDcVoQNRIoQlQF6Jo9R9gkxLLOpwvwGVkMyc5J1UKSvqZrR3O3Xa9TMhitbmXk1pnzi1OfVvmOHpsinm2Vzos2XHSeetsfVSdYbvljMVUy4y0N07rwHoiDBmDcnbN2gNgCgGXAflOdqWTUsKhb99o73BCR84Zk3mGd7cmkIRvawA7MjA3KGfUSwDNew2/gchic0QeUJnhPM1IhqO9aQdrNThd+oGGAAMEGid9Ka2Y2biNL9y6ofmRzJ2Tam8Oenvm25n4= Content-Type: text/plain; charset="utf-8" Content-ID: <06E32E107B4C684FB7A0A3AC77D41D64@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 6a87251e-1f83-4b34-f4fb-08d6a3c1bcc5 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Mar 2019 12:29:40.8607 (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-Transport-CrossTenantHeadersStamped: BN8PR11MB3620 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.26, xch-rcd-016.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: Re: [Lsr] IS-IS lite (an aside).. X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 12:29:52 -0000 DQoNCu+7v09uIDMvOC8xOSwgNzoyMiBBTSwgIkxzciBvbiBiZWhhbGYgb2YgQ2hyaXN0aWFuIEhv cHBzIiA8bHNyLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIGNob3Bwc0BjaG9wcHMub3Jn PiB3cm90ZToNCg0KICAgIA0KICAgIHRvbnkubGlAdG9ueS5saSB3cml0ZXM6DQogICAgPlJvYmVy dCBSYXN6dWsgPHJvYmVydEByYXN6dWsubmV0PiB3cml0ZXM6DQogICAgPj4NCiAgICA+PiBTZWUg VE9ScyBhcmUgb25lIGNhc2UgLi4gYnV0IHRoZXJlIGFyZSBpZGVhcyB0byBydW4gZHluYW1pYyBw cm90b2NvbHMgdG8gdGhlIGhvc3RzIHRvby4gSSBoYXZlIGhlYXJkIHRoZXJlIHdhcyBldmVuIGEg dm9sdW50ZWVyIHRvIHdyaXRlIElTSVMtbGl0ZSB0byBiZSB1c2VkIG9uIGhvc3RzIDopDQogICAg Pg0KICAgID4gSSB3b3VsZOKApi4gZGlzY291cmFnZSB0aGF0IGNvbmNlcHQuDQogICAgDQogICAg UGVyaGFwcyBSb2JlcnQgaXMgcmVmZXJyaW5nIHRvIHdoZW4gaG9tZW5ldCB3YXMgY29uc2lkZXJp bmcgdXNpbmcgSVMtSVMgaW5zdGVhZCBvZiBhIGJyYW5kIG5ldyBwcm90b2NvbCAoYmFiZWwpIGZv ciB1c2UgaW4gdGhlIGhvbWVuZXQuIFRoZSBwcm9wb3NlZCBzb2x1dGlvbiBmb3IgdmVyeSBzaW1w bGUgZGV2aWNlcyAoZS5nLiB0aGVybW9zdGF0cyBvciBhbnl0aGluZyB3L28gbXVjaCByYW0gZXRj KSB3YXMgdG8gdXNlIHRoZSBvdmVybG9hZCBiaXQuIFRoaXMgd2Fzbid0IGp1c3QgZm9yIGhvc3Rz IHRob3VnaCwgYnV0IGZvciB2ZXJ5IHNtYWxsIGRldmljZXMgdGhhdCBjb3VsZCBzdGlsbCBzZXJ2 ZSBhcyBzaW1wbGUgcm91dGVyIGZvciBhIG5ldHdvcmsgYmVoaW5kIHRoZW0uDQogICAgDQogICAg ICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2FyY2hpdmUvaWQvZHJhZnQtbXJ3LWhvbWVuZXQtcnRn LWNvbXBhcmlzb24tMDIudHh0DQogICAgDQogICAgQ2hyaXN0aWFuIEZyYW5rZSBjb2RlZCB1cCAi dGlueWlzaXMiIGluIDE1MDAgbGluZXMgb2YgQyBjb2RlLiA6KQ0KICAgIA0KICAgICAgICBodHRw czovL2dpdC11cy5uZXRkZWYub3JnL3Byb2plY3RzL09TUi9yZXBvcy90aW55aXNpcy9icm93c2Uv dGlueWlzaXMuYw0KDQpXZSBoYXZlICIgSVMtSVMgUm91dGluZyBmb3IgU3BpbmUtTGVhZiBUb3Bv bG9neSIgdG8gYWRkcmVzcyByZXNvdXJjZXMgb24gYSBUT1Igd2hpbGUgc3RpbGwgaGF2aW5nIG11 bHRpcGxlIG5vcnRoYm91bmQgbGlua3MuIEF0IGxlYXN0IGluIHRoZSBjb250ZXh0IG9mIGZsb29k aW5nIHJlZHVjdGlvbiwgSSBkb27igJl0IHRoaW5rIHdlIG5lZWQgYW55dGhpbmcgSVMtSVMgbGl0 ZS4gDQoNClRoYW5rcywNCkFjZWUNCg0KICAgIA0KICAgIFRoYW5rcywNCiAgICBDaHJpcy4NCiAg ICANCg0K From nobody Fri Mar 8 05:28:50 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D547D1279B0 for ; Fri, 8 Mar 2019 05:28:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 oo2VSXrtD2c3 for ; Fri, 8 Mar 2019 05:28:46 -0800 (PST) Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (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 8D271127598 for ; Fri, 8 Mar 2019 05:28:46 -0800 (PST) Received: by mail-pf1-x430.google.com with SMTP id q17so14171122pfh.10 for ; Fri, 08 Mar 2019 05:28:46 -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=dKpNxKu23bSMPEdjeZkE++D5DW5llQGsPvH3SQQitSQ=; b=IBEbf9Kthqa0HkQL1zQWBytYcLG3XzYh/dcKWAp9fQ4/0MITH7LMUdKoOSxGYyD3zV jSdaDKg9d7mu5veuOTsS1lP9/Ewk4xluNGnwb2vm1TCJDmAIdD0qO0TcJxmE+ad+gCur 4kRVSUZF9P8GCr26EO5256IQNRIWxnfb5eJvd5pQnZ9bntj4QWaT+HwfH+XSQ61svHiQ vQG4+1vB9o3yWYcRVRAvnh8GXiXR6C44A1E1iMJYwgcM7soOHJdGnK6G/x6oK67NFmwD ByUxWU+3Oy1hm3yemAeGtPaQwWUi8B82P54f3dVof+ZLYXcRTe2fCMxleEQFQ7aX4ac5 Y+Ig== 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=dKpNxKu23bSMPEdjeZkE++D5DW5llQGsPvH3SQQitSQ=; b=msSxKYUrnMY1BquwhQNQW9k8X8kMyW0KB/3vfoWsBzzRdkYhXwQ1yBY15iYLlkkqth nHy9VBhWYcypsshfNBn+cvwP8+kU+HRdOTsoT+0qqZI/VUM/GVqWctUthRY3f71mMhR5 HEFkXiPzf630YHKpQiAHuMoCd2ES99WVlJNP3HS5F2A/fohQ4DG0HmWOeIcLBxWZdthP MrTJQ9l8Ys7qC0gWBdgM7USNIowFAonZxc7TkUROgOgPhiiFaAZM3Ih01OrsOWziJeMI /LKZ+7lJ6e8Cff1bJlJtPU1WAbjhJVUsFREu55c226g73wIMZVACFhXEXh2LNlkvNLNi Iciw== X-Gm-Message-State: APjAAAU/zkmQ6d/hc0XKvAtVG/tTnsxTny4bOr70sdWY/+PFruzgf9ot kv0ZEYKykGAiJbIcb6dILNg8+FF5bUnI9EITQf8= X-Google-Smtp-Source: APXvYqwT/HizbcNfOPUWHbSNJ6m/8yH0dE4rxRsUAuhctFNQSci1gXlFpMJfWNeNiXsX9Q2nH3JmJKY62JeC90/LIqg= X-Received: by 2002:a63:8048:: with SMTP id j69mr16534309pgd.432.1552051725479; Fri, 08 Mar 2019 05:28:45 -0800 (PST) MIME-Version: 1.0 References: <2F0FB596-D717-4D8C-B01A-55CBEE3B7B06@cisco.com> In-Reply-To: <2F0FB596-D717-4D8C-B01A-55CBEE3B7B06@cisco.com> From: Robert Raszuk Date: Fri, 8 Mar 2019 14:28:30 +0100 Message-ID: To: "Acee Lindem (acee)" Cc: Christian Hopps , "lsr@ietf.org" , Tony Li , "Peter Psenak (ppsenak)" Content-Type: multipart/alternative; boundary="000000000000c536350583953375" Archived-At: Subject: Re: [Lsr] IS-IS lite (an aside).. X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 13:28:49 -0000 --000000000000c536350583953375 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Well I was actually not talking about homenet efforts, but any small/mid size compute clusters. See today it is very common for hosts to participate in dynamic routing - simply due to a fact that VMs or PODs want to be dynamically IP reachable when they are created by orchestration. Moreover it is not that uncommon to see flat routing requirement too in today's DC deployments. Systems folks just do not like the additional protocol layers :) So what options do we have - well BGP between TOR and compute seems to be the only option. Then in fabric there is link state or oversold BGP. Then in the former case you have to redistribute BGP to your underlay and if have requirement to separate reachability then at best you need to map communities to ISIS tags at redistribution. Of course for multi-tenancy there is zoo of other hierarchical options. That just brings an observation that if we are spending some effort to get link state operate lighter in densely meshed environments perhaps it does make sense to make it work end to end too. Not that hosts need to know entire topology so they can be happily treated as stubs, but still single protocol operation is a big OPEX advantage. r. On Fri, Mar 8, 2019 at 1:30 PM Acee Lindem (acee) wrote: > > > =EF=BB=BFOn 3/8/19, 7:22 AM, "Lsr on behalf of Christian Hopps" < > lsr-bounces@ietf.org on behalf of chopps@chopps.org> wrote: > > > tony.li@tony.li writes: > >Robert Raszuk writes: > >> > >> See TORs are one case .. but there are ideas to run dynamic > protocols to the hosts too. I have heard there was even a volunteer to > write ISIS-lite to be used on hosts :) > > > > I would=E2=80=A6. discourage that concept. > > Perhaps Robert is referring to when homenet was considering using > IS-IS instead of a brand new protocol (babel) for use in the homenet. The > proposed solution for very simple devices (e.g. thermostats or anything w= /o > much ram etc) was to use the overload bit. This wasn't just for hosts > though, but for very small devices that could still serve as simple route= r > for a network behind them. > > > https://www.ietf.org/archive/id/draft-mrw-homenet-rtg-comparison-02.txt > > Christian Franke coded up "tinyisis" in 1500 lines of C code. :) > > > https://git-us.netdef.org/projects/OSR/repos/tinyisis/browse/tinyisis.c > > We have " IS-IS Routing for Spine-Leaf Topology" to address resources on = a > TOR while still having multiple northbound links. At least in the context > of flooding reduction, I don=E2=80=99t think we need anything IS-IS lite. > > Thanks, > Acee > > > Thanks, > Chris. > > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > --000000000000c536350583953375 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Well I was= actually not talking about homenet efforts, but any small/mid size compute= clusters.=C2=A0

See t= oday it is very common for hosts to participate in dynamic routing - simply= due to a fact that VMs or PODs want to be dynamically IP reachable when th= ey are created by orchestration.=C2=A0

Moreover it is not that uncommon to see flat routing requi= rement too in today's DC deployments. Systems folks just do not like th= e additional protocol layers :)=C2=A0

So what options do we have - well BGP between TOR and compu= te seems to be the only option. Then in fabric there is link state or overs= old BGP.=C2=A0

Then in= the former case you have to redistribute BGP to your underlay and if have = requirement to separate reachability then at best you need to map communiti= es to ISIS tags at redistribution. Of course for multi-tenancy there is zoo= of other hierarchical options.=C2=A0

That just brings an observation that if we are spending som= e effort to get link state operate lighter in densely meshed environments p= erhaps it does make=C2=A0sense to make it work end to end too. Not that hos= ts need to know entire topology so they can be happily treated as stubs, bu= t still single protocol operation is a big OPEX advantage.=C2=A0

r.

On Fri, Mar 8, 2019 at 1= :30 PM Acee Lindem (acee) <acee@cisco.= com> wrote:


=EF=BB=BFOn 3/8/19, 7:22 AM, "Lsr on behalf of Christian Hopps" &= lt;lsr-bounces@ie= tf.org on behalf of chopps@chopps.org> wrote:


=C2=A0 =C2=A0 tony.li@= tony.li writes:
=C2=A0 =C2=A0 >Robert Raszuk <robert@raszuk.net> writes:
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> See TORs are one case .. but there are ideas to run = dynamic protocols to the hosts too. I have heard there was even a volunteer= to write ISIS-lite to be used on hosts :)
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > I would=E2=80=A6. discourage that concept.

=C2=A0 =C2=A0 Perhaps Robert is referring to when homenet was considering u= sing IS-IS instead of a brand new protocol (babel) for use in the homenet. = The proposed solution for very simple devices (e.g. thermostats or anything= w/o much ram etc) was to use the overload bit. This wasn't just for ho= sts though, but for very small devices that could still serve as simple rou= ter for a network behind them.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 h= ttps://www.ietf.org/archive/id/draft-mrw-homenet-rtg-comparison-02.txt<= br>
=C2=A0 =C2=A0 Christian Franke coded up "tinyisis" in 1500 lines = of C code. :)

=C2=A0 =C2=A0 =C2=A0 =C2=A0 h= ttps://git-us.netdef.org/projects/OSR/repos/tinyisis/browse/tinyisis.c<= br>
We have " IS-IS Routing for Spine-Leaf Topology" to address resou= rces on a TOR while still having multiple northbound links. At least in the= context of flooding reduction, I don=E2=80=99t think we need anything IS-I= S lite.

Thanks,
Acee


=C2=A0 =C2=A0 Thanks,
=C2=A0 =C2=A0 Chris.


_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
--000000000000c536350583953375-- From nobody Fri Mar 8 05:36:38 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9489E127980 for ; Fri, 8 Mar 2019 05:36:36 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 TJbpydNCEnqL for ; Fri, 8 Mar 2019 05:36:34 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 64A74127598 for ; Fri, 8 Mar 2019 05:36:34 -0800 (PST) Received: from tops.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPS id ED1FE604D0; Fri, 8 Mar 2019 08:36:31 -0500 (EST) References: <2F0FB596-D717-4D8C-B01A-55CBEE3B7B06@cisco.com> User-agent: mu4e 1.1.0; emacs 26.1 From: Christian Hopps To: lsr@ietf.org Cc: Christian Hopps , Tony Li , Robert Raszuk , "Peter Psenak \(ppsenak\)" In-reply-to: <2F0FB596-D717-4D8C-B01A-55CBEE3B7B06@cisco.com> Date: Fri, 08 Mar 2019 08:36:31 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [Lsr] IS-IS lite (an aside).. X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 13:36:37 -0000 --=-=-= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable FWIW, this use of IS-IS was not adopted by homenet, which is why we now hav= e babel wg. Thanks, Chris. Acee Lindem (acee) writes: > =EF=BB=BFOn 3/8/19, 7:22 AM, "Lsr on behalf of Christian Hopps" wrote: > > > tony.li@tony.li writes: > >Robert Raszuk writes: > >> > >> See TORs are one case .. but there are ideas to run dynamic protoc= ols to the hosts too. I have heard there was even a volunteer to write ISIS= -lite to be used on hosts :) > > > > I would=E2=80=A6. discourage that concept. > > Perhaps Robert is referring to when homenet was considering using IS-= IS instead of a brand new protocol (babel) for use in the homenet. The prop= osed solution for very simple devices (e.g. thermostats or anything w/o muc= h ram etc) was to use the overload bit. This wasn't just for hosts though, = but for very small devices that could still serve as simple router for a ne= twork behind them. > > https://www.ietf.org/archive/id/draft-mrw-homenet-rtg-comparison-= 02.txt > > Christian Franke coded up "tinyisis" in 1500 lines of C code. :) > > https://git-us.netdef.org/projects/OSR/repos/tinyisis/browse/tiny= isis.c > > We have " IS-IS Routing for Spine-Leaf Topology" to address resources on = a TOR while still having multiple northbound links. At least in the context= of flooding reduction, I don=E2=80=99t think we need anything IS-IS lite. > > Thanks, > Acee > > > Thanks, > Chris. > > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAlyCb98ACgkQLh2DDte4 MCXaqxAAkiIdT4GX6UfmpM1hGA5S3a8/cNqep/DURCA8NzWuXS2XHtnQrCOIfmRr js2u9IFWBYSzZa2z+NVBREkvRW7ILBbpz5LMHjZJhJ/fIepVXWYJTov9h24JirEr ekcXJvv2eKEH9f6MDJ550ZDtBUMEk1XP0GotEVvJRHx+VygiI5JSxOE3CnNatD3m NezwV5Ys7k9bc19+Op0Uhc0Bsg8xjYKpZ+wjdAMj4h2O1rcUMopYjj2kDzUGYjW7 uIQ1PzbOxNaQEP+mYZNpNdeTFUrdOUDmg9aaz0lPe4pEt63y2FgrqWBje5rWwwoH Bik3ZaUpW2Qr/rpRd/ZuTkN5guwwNhgYOa0JNorERSdVj7i18sMLFLjOr6iY64LI qIFGy1US4+r/aYNdtVMWX5178dTBt8cXjy7ICA76NVnqxyDKWy24dQyPNE51KSGo b9Q+vhIIoB1KxlN7uL2WQOzkox3e+O3qSJthzO8o1fp5HwpgHQsImcyTqzk/HOVu MJSBkyS3RRmB4bNHbqkwbUdxyEp5ZB7RDy70ohfXDMGRpHHyrmmUNNV8rzpQeHJs Vy17iYoXiJoPAwnCPMYoyhZRHGQI3WEgyXEdm57G7iBFpzpVEV+M/RXRmOf4H3CZ K8toD3+LmCWqmotNS4A+3djiiRsFpIPHhRzAZKXwUigNDW0pwxQ= =MB86 -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Mar 8 09:22:45 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65D391312AF for ; Fri, 8 Mar 2019 09:22:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 tzlCT7clc3ni for ; Fri, 8 Mar 2019 09:22:41 -0800 (PST) Received: from mail-ed1-x541.google.com (mail-ed1-x541.google.com [IPv6:2a00:1450:4864:20::541]) (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 5605013140C for ; Fri, 8 Mar 2019 09:22:29 -0800 (PST) Received: by mail-ed1-x541.google.com with SMTP id f19so16991568eds.12 for ; Fri, 08 Mar 2019 09:22:29 -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=TRjBWcQ1x3ucnPUkHE4KocuH+bqsbSxx/PPPHy8QrHs=; b=Vlm7TZlSLWTgimRicJ0uIgnfax1Vmq7MFSfkzYZZTik8ALIsCX+9vKG+mcdxM/UHm+ sKU3kB01Pf6BMUkfvdTRSKe4EamdFfsVp3colehePqujhq2btomeOaS+rCDzUrliHCvE kvd6ZEO14pMkxEPDxNQcL9iVPScTNFLwwVQZ/f8wk5fHKUMetIpGGw1/X/B26mQy2I7J cQNjJRZKxgR8r4HEzz11tnpf6etszZGr2tWZgYUB3j90w61Y9sCqwK6hLTA73YfgrhIL gbUvzCxmYKGlUBg4Kp4y5H4Bk6ERGFMpkrj8PCGwZMZtIA6h3jIFogYp3UeqO9GuqUp4 xrcg== 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=TRjBWcQ1x3ucnPUkHE4KocuH+bqsbSxx/PPPHy8QrHs=; b=LxbuZ9savZnwijXawU1SdTgNmDUOsuUYWG2z/xh2vPrdC/kUmVNdSAd0uUqr3taw9E nEeinSBLkgUApHxojX0rvVC7/zrmEBoN+ykvkWpp/jUbUWMUmGkOY/lhxhCclPV44Ugd vTytG8L4ekN7rpMgItXPJGuxWH8b16zP3Kt17ns/qW/85Z4Q0OwFCaK+wf2Fzx2wxP5m eZ7nhQ/gxkk2yHtYCMhX1WhPIqpKi7Ex6/PwV47V9Fy80k7ySoLs6J+y12FiYJCmSU5d vI28MvY3Ojk0j0szL97vDv+wncEdf3iaAomPXZaHiF/IEsddiyGWOAXYbOO1M+pe1Ri/ q/sg== X-Gm-Message-State: APjAAAVGOsimbQU/hrdq1QM01LobEFdWctpUlHPruBlgOtcFB2++7v7G 8fnlMS7HOI5Dd+xMQ8LWZuVXqCn8iUe2135DSy8= X-Google-Smtp-Source: APXvYqy3YtkpLJ0KXBV6mbUXI+dOE0D4HIsFi1YS182Wb0fIcZr9xsVYOKp6eUtN3/RBqQOCfrSrRzi/nR7faawweNE= X-Received: by 2002:a50:ad13:: with SMTP id y19mr33455056edc.86.1552065747715; Fri, 08 Mar 2019 09:22:27 -0800 (PST) MIME-Version: 1.0 References: <2F0FB596-D717-4D8C-B01A-55CBEE3B7B06@cisco.com> In-Reply-To: From: Tony Przygienda Date: Fri, 8 Mar 2019 09:21:51 -0800 Message-ID: To: Christian Hopps Cc: lsr@ietf.org, Robert Raszuk , Tony Li , "Peter Psenak (ppsenak)" Content-Type: multipart/alternative; boundary="0000000000008f8b6505839877fa" Archived-At: Subject: Re: [Lsr] IS-IS lite (an aside).. X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 17:22:45 -0000 --0000000000008f8b6505839877fa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Somewhat Apple & Kiwi comparisons all over the place here a bit IMO. Assuming we seem to be talking about ROTH in IP fabrics mainly ... a) Babel was solving wireless mesh problem, extremely different from wired fabrics and Babel as solution was IMO fully justified and superior to suggested ISIS stuff (simplicity, convergence @ high link failure rates, use of inherent wireless broadcast and so on, inherent, simple source-routing possible) to anything else based on e.g. Battle-Mesh comparisons. RPL could probably have done the job as well but no'one seemed to have looked there ;-) MANET did a decent job as well but a link-state will be always much "fatter" for "simple" stuff than DV (observe I'm talking RIP variety, not the differential update path vector like BGP), just nature of even basic flooding and LSDB maintainance code unless you want to skip retransmissions, CSNPs and all the other good stuff ... And BTW, almost anything can be written in 1000 lines of code if you cut enough corners, make the lines long enough and hard-code wire formats in byte arrays but those things are not really what I'd call "reasonable solutions" often ;-) You can even make an art out of it if you look @ https://www.ioccc.org/ . I digress as usual ... b) getting default route into the host and host address out has a million possiblities, even DHCP hacks will do ;-) The fun starts when servers multi-home and when the first links fail and hosts start to blackhole merrily or when hosts start to seriously move things around or bring tons addresses up/down for e.g. service scaling ... Yes, in a somewhat limited fashion Naiming's & Les's ISIS bolts can deal with the issue @ cost of high configuration necessity (I give Naiming that he seemed to have been the first to start thinking about the issues and tinker around ;-), scale limitations (which can be somewhat dealt with by using RFC7356 but is that 'old-ISIS' anymore even?) and very interesting behavior if you happen to be less than super-human and miswire your fabric here and there ;-) c) if you think through more problems involved in this deeper and want to properly tackle them long-term you problably know by now what the real answer is I pursuit ;-) --- tony On Fri, Mar 8, 2019 at 5:36 AM Christian Hopps wrote: > > FWIW, this use of IS-IS was not adopted by homenet, which is why we now > have babel wg. > > Thanks, > Chris. > > Acee Lindem (acee) writes: > > > =EF=BB=BFOn 3/8/19, 7:22 AM, "Lsr on behalf of Christian Hopps" < > lsr-bounces@ietf.org on behalf of chopps@chopps.org> wrote: > > > > > > tony.li@tony.li writes: > > >Robert Raszuk writes: > > >> > > >> See TORs are one case .. but there are ideas to run dynamic > protocols to the hosts too. I have heard there was even a volunteer to > write ISIS-lite to be used on hosts :) > > > > > > I would=E2=80=A6. discourage that concept. > > > > Perhaps Robert is referring to when homenet was considering using > IS-IS instead of a brand new protocol (babel) for use in the homenet. The > proposed solution for very simple devices (e.g. thermostats or anything w= /o > much ram etc) was to use the overload bit. This wasn't just for hosts > though, but for very small devices that could still serve as simple route= r > for a network behind them. > > > > > https://www.ietf.org/archive/id/draft-mrw-homenet-rtg-comparison-02.txt > > > > Christian Franke coded up "tinyisis" in 1500 lines of C code. :) > > > > > https://git-us.netdef.org/projects/OSR/repos/tinyisis/browse/tinyisis.c > > > > We have " IS-IS Routing for Spine-Leaf Topology" to address resources o= n > a TOR while still having multiple northbound links. At least in the conte= xt > of flooding reduction, I don=E2=80=99t think we need anything IS-IS lite. > > > > Thanks, > > Acee > > > > > > Thanks, > > Chris. > > > > > > _______________________________________________ > > Lsr mailing list > > Lsr@ietf.org > > https://www.ietf.org/mailman/listinfo/lsr > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > --0000000000008f8b6505839877fa Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Somewhat Apple & Kiwi comparison= s all over the place here a bit IMO. Assuming we seem to be talking about R= OTH in IP fabrics mainly ...

a) Babel was sol= ving wireless mesh problem, extremely different from wired fabrics and Babe= l as solution was IMO fully justified and superior to suggested ISIS stuff = (simplicity, convergence @ high link failure rates, use of inherent wireles= s broadcast and so on, inherent, simple source-routing possible) to anythin= g else based on e.g. Battle-Mesh comparisons. RPL could probably have done = the job as well but no'one seemed to have looked there ;-) MANET did a = decent job as well but a link-state will be always much "fatter" = for "simple" stuff than DV (observe I'm talking RIP variety, = not the differential update path vector like BGP), just nature of even basi= c flooding and LSDB maintainance code unless you want to skip retransmissio= ns, CSNPs and all the other good stuff=C2=A0 ... And BTW, almost anything c= an be written in 1000 lines of code if you cut enough corners, make the lin= es long enough and hard-code wire formats in byte arrays but those things a= re not really what I'd call "reasonable solutions" often ;-) = You can even make an art out of it if you look @ https://www.ioccc.org/ . I digress as usual ...
b) getting default route into the host and host address out has a million = possiblities, even DHCP hacks will do ;-) The fun starts when servers multi= -home and when the first links fail and hosts start to blackhole merrily or= when hosts start to seriously move things around or bring tons addresses u= p/down for e.g. service scaling ... Yes, in a somewhat limited fashion Naim= ing's & Les's ISIS bolts can deal with the issue @ cost of high= configuration necessity (I give Naiming that he seemed to have been the fi= rst to start thinking about the issues and tinker around ;-), scale limitat= ions (which can be somewhat dealt with by using RFC7356 but is that 'ol= d-ISIS' anymore even?) and very interesting behavior if you happen to b= e less than super-human and miswire your fabric here and there ;-)
c) if you think through more problems involved in this deeper and wa= nt to properly tackle them long-term you problably know by now what the rea= l answer is I pursuit ;-)

--- tony
=

On Fri, Mar 8, 2019 at 5:36 AM Christian Hopps <chopps@chopps.org> wrote:

FWIW, this use of IS-IS was not adopted by homenet, which is why we now hav= e babel wg.

Thanks,
Chris.

Acee Lindem (acee) <= acee@cisco.com> writes:

> =EF=BB=BFOn 3/8/19, 7:22 AM, "Lsr on behalf of Christian Hopps&qu= ot; <lsr-bounc= es@ietf.org on behalf of chopps@chopps.org> wrote:
>
>
>=C2=A0 =C2=A0 =C2=A0tony.li@tony.li writes:
>=C2=A0 =C2=A0 =C2=A0>Robert Raszuk <robert@raszuk.net> writes:
>=C2=A0 =C2=A0 =C2=A0>>
>=C2=A0 =C2=A0 =C2=A0>> See TORs are one case .. but there are ide= as to run dynamic protocols to the hosts too. I have heard there was even a= volunteer to write ISIS-lite to be used on hosts :)
>=C2=A0 =C2=A0 =C2=A0>
>=C2=A0 =C2=A0 =C2=A0> I would=E2=80=A6. discourage that concept.
>
>=C2=A0 =C2=A0 =C2=A0Perhaps Robert is referring to when homenet was con= sidering using IS-IS instead of a brand new protocol (babel) for use in the= homenet. The proposed solution for very simple devices (e.g. thermostats o= r anything w/o much ram etc) was to use the overload bit. This wasn't j= ust for hosts though, but for very small devices that could still serve as = simple router for a network behind them.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/archive/id/draft-mrw-homenet-rtg-comparison-0= 2.txt
>
>=C2=A0 =C2=A0 =C2=A0Christian Franke coded up "tinyisis" in 1= 500 lines of C code. :)
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://git-us.netdef.org/projects/OSR/repos/tinyisis/browse/tinyi= sis.c
>
> We have " IS-IS Routing for Spine-Leaf Topology" to address = resources on a TOR while still having multiple northbound links. At least i= n the context of flooding reduction, I don=E2=80=99t think we need anything= IS-IS lite.
>
> Thanks,
> Acee
>
>
>=C2=A0 =C2=A0 =C2=A0Thanks,
>=C2=A0 =C2=A0 =C2=A0Chris.
>
>
> _______________________________________________
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr

_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
--0000000000008f8b6505839877fa-- From nobody Fri Mar 8 11:00:15 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 804AE130F67 for ; Fri, 8 Mar 2019 11:00:13 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 AWZWRbrpyIPQ for ; Fri, 8 Mar 2019 11:00:10 -0800 (PST) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 8D75112AF7E for ; Fri, 8 Mar 2019 11:00:10 -0800 (PST) Received: from tops.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPS id 5DE5360510; Fri, 8 Mar 2019 14:00:09 -0500 (EST) References: <2F0FB596-D717-4D8C-B01A-55CBEE3B7B06@cisco.com> User-agent: mu4e 1.1.0; emacs 26.1 From: Christian Hopps To: Tony Przygienda Cc: Christian Hopps , lsr@ietf.org, Robert Raszuk , Tony Li , "Peter Psenak \(ppsenak\)" In-reply-to: Date: Fri, 08 Mar 2019 14:00:08 -0500 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [Lsr] IS-IS lite (an aside).. X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 19:00:13 -0000 --=-=-= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable I think my email is being taken way too seriously. Please note it was "an a= side" Also I feel the need to defend Christian's code here. Did you check the cod= e prior to the comments? I don't see a lot of obfuscation, in fact I see co= de for printing data for user consumption (e.g., id2str, etc), DIS election= , and it even includes jittered timers, which must means it's at least half= -way serious, right?. :) For a proof-of-concept project, I'd say good job. Thanks, Chris. Tony Przygienda writes: > Somewhat Apple & Kiwi comparisons all over the place here a bit IMO. > Assuming we seem to be talking about ROTH in IP fabrics mainly ... > > a) Babel was solving wireless mesh problem, extremely different from wired > fabrics and Babel as solution was IMO fully justified and superior to > suggested ISIS stuff (simplicity, convergence @ high link failure rates, > use of inherent wireless broadcast and so on, inherent, simple > source-routing possible) to anything else based on e.g. Battle-Mesh > comparisons. RPL could probably have done the job as well but no'one seem= ed > to have looked there ;-) MANET did a decent job as well but a link-state > will be always much "fatter" for "simple" stuff than DV (observe I'm > talking RIP variety, not the differential update path vector like BGP), > just nature of even basic flooding and LSDB maintainance code unless you > want to skip retransmissions, CSNPs and all the other good stuff ... And > BTW, almost anything can be written in 1000 lines of code if you cut enou= gh > corners, make the lines long enough and hard-code wire formats in byte > arrays but those things are not really what I'd call "reasonable solution= s" > often ;-) You can even make an art out of it if you look @ > https://www.ioccc.org/ . I digress as usual ... > b) getting default route into the host and host address out has a million > possiblities, even DHCP hacks will do ;-) The fun starts when servers > multi-home and when the first links fail and hosts start to blackhole > merrily or when hosts start to seriously move things around or bring tons > addresses up/down for e.g. service scaling ... Yes, in a somewhat limited > fashion Naiming's & Les's ISIS bolts can deal with the issue @ cost of hi= gh > configuration necessity (I give Naiming that he seemed to have been the > first to start thinking about the issues and tinker around ;-), scale > limitations (which can be somewhat dealt with by using RFC7356 but is that > 'old-ISIS' anymore even?) and very interesting behavior if you happen to = be > less than super-human and miswire your fabric here and there ;-) > c) if you think through more problems involved in this deeper and want to > properly tackle them long-term you problably know by now what the real > answer is I pursuit ;-) > > --- tony > > On Fri, Mar 8, 2019 at 5:36 AM Christian Hopps wrote: > >> >> FWIW, this use of IS-IS was not adopted by homenet, which is why we now >> have babel wg. >> >> Thanks, >> Chris. >> >> Acee Lindem (acee) writes: >> >> > =EF=BB=BFOn 3/8/19, 7:22 AM, "Lsr on behalf of Christian Hopps" < >> lsr-bounces@ietf.org on behalf of chopps@chopps.org> wrote: >> > >> > >> > tony.li@tony.li writes: >> > >Robert Raszuk writes: >> > >> >> > >> See TORs are one case .. but there are ideas to run dynamic >> protocols to the hosts too. I have heard there was even a volunteer to >> write ISIS-lite to be used on hosts :) >> > > >> > > I would=E2=80=A6. discourage that concept. >> > >> > Perhaps Robert is referring to when homenet was considering using >> IS-IS instead of a brand new protocol (babel) for use in the homenet. The >> proposed solution for very simple devices (e.g. thermostats or anything = w/o >> much ram etc) was to use the overload bit. This wasn't just for hosts >> though, but for very small devices that could still serve as simple rout= er >> for a network behind them. >> > >> > >> https://www.ietf.org/archive/id/draft-mrw-homenet-rtg-comparison-02.txt >> > >> > Christian Franke coded up "tinyisis" in 1500 lines of C code. :) >> > >> > >> https://git-us.netdef.org/projects/OSR/repos/tinyisis/browse/tinyisis.c >> > >> > We have " IS-IS Routing for Spine-Leaf Topology" to address resources = on >> a TOR while still having multiple northbound links. At least in the cont= ext >> of flooding reduction, I don=E2=80=99t think we need anything IS-IS lite. >> > >> > Thanks, >> > Acee >> > >> > >> > Thanks, >> > Chris. >> > >> > >> > _______________________________________________ >> > Lsr mailing list >> > Lsr@ietf.org >> > https://www.ietf.org/mailman/listinfo/lsr >> >> _______________________________________________ >> Lsr mailing list >> Lsr@ietf.org >> https://www.ietf.org/mailman/listinfo/lsr >> --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAlyCu7gACgkQLh2DDte4 MCXOkA//eWa9HE0FQJwUhOUZbT7mUQeqc1MyFwuUP+Dugrjv2q2llReMzKCqidc3 RFWlA9SbWCzNmnlOEoxJrf/VwztqpyPEPLqPxseW5O3yCWw8wsnevzd0VE2XWsp6 WAaXF6NuJPJ59BFUHoHoONAq0JOxrAO2Y6QFToK0a8qBwm+OhSgy3Znguw1YLl1+ 1Ix6P5USmdO1hrGrvKGQ4hTNzGKhh23NTzM9hi++TJXoJBFiav5UPciUN8ALHqqM ROAPR8SgtwhK2ieA61+GLrZPs8x2emvxlhgEOqOpHwz7AawObF6IfVAI4uYHgu1F GzceNwZfjvXXifcu7mTnxayCSKst2uruF4ACcf7m48FSTpZo/UE18btzatuQSUM+ Cl1zsnqpeoTBfbjGKaL2CIfIsP5kBUowQRHCkUQ3DbmHnaxyvFsxwhBHOju+8Jjo n0HKiwUWc0Te/zgKIqAX5jAxeIlzRH+Rm+wiswIbzR9FM/nUWou97lVt9V8ZOouN agQKDUDzM2SZCSGWB3rI8zUHv8QJcq0YsUDc5CNCRSN2d+wsKRm59fHbd6KEL8ko xOj0ywSNHxnSUwrOxaip4CXlhhGEkqR5YIk3OMaRoo56ZEYP/UuukckK8NHytDXH oZC0anfSGPjNIBfc7AtLpS//N4IKGU7kSuP1afjKv08Zd8mF/Mg= =sq1b -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Mar 8 13:23:18 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD69126DFA for ; Fri, 8 Mar 2019 13:23:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 uVudGHPWIaJU for ; Fri, 8 Mar 2019 13:23:15 -0800 (PST) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (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 B4847124408 for ; Fri, 8 Mar 2019 13:23:14 -0800 (PST) Received: by mail-ed1-x52d.google.com with SMTP id h58so17503173edb.5 for ; Fri, 08 Mar 2019 13:23:14 -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=xyNG9eepjK2r1yAPZPCu7e6hYEp9DVjgNYwIW26HSf4=; b=YuYXjeCeFmAWDugYvfj3WjU6eARrvkE/ubqD22L89tX9aetkFVRyopcUug+3hHrYHq XpOfQVc5sd+Sv8DCrWDIOl0u8A/cUc+bcvlGdIR7LwMd/91oi6yuWjRe2mDPOsvZkxzg yAH1CEnREIh8MDSC5YlHTv7BDAfNLJf4WRkCFb/FGNk16UB1ZTPdhTCpOWGy5sGbs69n TP0/CBv5rj9K/qj1WXDkpNhCXPrJS/LimjaM/2bkRpTf4KHsT/Vgs3FO3pQjWolvf2NQ zVrIEPod6uwgg3ZQldJwMx/tzFOd5uPXkLk58QF8bSqZ0G3HhWO3Kh/0vUPzvUXyaKOb CiDA== 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=xyNG9eepjK2r1yAPZPCu7e6hYEp9DVjgNYwIW26HSf4=; b=T+9oiWeACOIYioOPDkKvriNljVGJTibirjqk/i61YJqvSgUgIE9T9+JyqDe8mTrP9j bjZKRWBtcIj5RoWarwH89waw6vhG1NyAZvKFos/ca4gC/DPohrMY4khof/Rw5DtFItTW ApKGA8ydW38opVsteXypnOmKhZmXwbiTIwddjzFvVSuyOawq+wykP2mwtWt0F3JyoZLI SHmXGCECzFiFkay6kyUpggGHbV8pz1Swp/guOp8UH6HoPky0qREhbu0xmUu9OUZJNlf2 3J/0iPD8noynn3bM1HQlDI+fvuj5AqJcF0j6+ZjJGb2h7Iq70+6P4AdLoxpwatZAY+qI 9htQ== X-Gm-Message-State: APjAAAW74HWL8EelvQuvcCW+Rv+WTNDowhw6WqZN6VkxPlSzZ2CUIpDj mtq863YCoegWwcmE9TPVkCJEPdA4gxnS82/AkgE= X-Google-Smtp-Source: APXvYqy9BpolC2Ad4YvU/5mtDZSGoZiRVP3hkaZgdRm5Du0NqgSWrzS1OyDEfaQ5Z8GMJzAHefVSo9hv/aBkbfRVdeU= X-Received: by 2002:a50:d8ce:: with SMTP id y14mr33896635edj.101.1552080193196; Fri, 08 Mar 2019 13:23:13 -0800 (PST) MIME-Version: 1.0 References: <2F0FB596-D717-4D8C-B01A-55CBEE3B7B06@cisco.com> In-Reply-To: From: Tony Przygienda Date: Fri, 8 Mar 2019 13:22:33 -0800 Message-ID: To: Christian Hopps Cc: lsr@ietf.org, Robert Raszuk , Tony Li , "Peter Psenak (ppsenak)" Content-Type: multipart/alternative; boundary="00000000000094167a05839bd48a" Archived-At: Subject: Re: [Lsr] IS-IS lite (an aside).. X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 21:23:17 -0000 --00000000000094167a05839bd48a Content-Type: text/plain; charset="UTF-8" On Fri, Mar 8, 2019 at 11:00 AM Christian Hopps wrote: > > I think my email is being taken way too seriously. Please note it was "an > aside" > > Also I feel the need to defend Christian's code here. Did you check the > code prior to the comments? I don't see a lot of obfuscation, in fact I see > code for printing data for user consumption (e.g., id2str, etc), DIS > election, and it even includes jittered timers, which must means it's at > least half-way serious, right?. :) > > For a proof-of-concept project, I'd say good job. > > ack, you made me curious and I looked @ it. Yeah, I admit it's readable, quite clean code albeit AFAIS e'thing (obviously) massively hardcoded, one fragment, no CSNP, no PSNP processing or sending (and how does that work I was wondering or is he leaving the neighbor retransmitting forever ?) Even with that 1.5KLOC is very small ... interesting datapoint in itself and sorry if I was bit flipant, mea culpa ... --- t --00000000000094167a05839bd48a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Fri, Mar 8, 2019 at 11:00 AM Chris= tian Hopps <chopps@chopps.org&g= t; wrote:

I think my email is being taken way too seriously. Please note it was "= ;an aside"

Also I feel the need to defend Christian's code here. Did you check the= code prior to the comments? I don't see a lot of obfuscation, in fact = I see code for printing data for user consumption (e.g., id2str, etc), DIS = election, and it even includes jittered timers, which must means it's a= t least half-way serious, right?. :)

For a proof-of-concept project, I'd say good job.


ack, you made me curious and I lo= oked @ it. Yeah, I admit it's=20 readable, quite clean code albeit AFAIS e'thing (obviously) massively= =20 hardcoded, one fragment, no CSNP, no PSNP processing or sending (and how does that work I was wondering or is he leaving the neighbor=20 retransmitting forever ?) Even with that 1.5KLOC is very small ...

interesting datapoint in itself and sorry if I was bi= t flipant, mea culpa ...

--- t
=C2= =A0
--00000000000094167a05839bd48a-- From nobody Fri Mar 8 15:30:14 2019 Return-Path: X-Original-To: lsr@ietf.org Delivered-To: lsr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E543126DFA; Fri, 8 Mar 2019 15:30:07 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lsr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lsr@ietf.org Message-ID: <155208780718.3173.11177482943741667773@ietfa.amsl.com> Date: Fri, 08 Mar 2019 15:30:07 -0800 Archived-At: Subject: [Lsr] I-D Action: draft-ietf-lsr-isis-spine-leaf-ext-01.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Mar 2019 23:30:07 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Link State Routing WG of the IETF. Title : IS-IS Routing for Spine-Leaf Topology Authors : Naiming Shen Les Ginsberg Sanjay Thyamagundalu Filename : draft-ietf-lsr-isis-spine-leaf-ext-01.txt Pages : 17 Date : 2019-03-08 Abstract: This document describes a mechanism for routers and switches in a Spine-Leaf type topology to have non-reciprocal Intermediate System to Intermediate System (IS-IS) routing relationships between the leafs and spines. The leaf nodes do not need to have the topology information of other nodes and exact prefixes in the network. This extension also has application in the Internet of Things (IoT). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-spine-leaf-ext/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lsr-isis-spine-leaf-ext-01 https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-spine-leaf-ext-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-isis-spine-leaf-ext-01 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 Sun Mar 10 04:39:43 2019 Return-Path: X-Original-To: lsr@ietf.org Delivered-To: lsr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DE201200ED; Sun, 10 Mar 2019 04:39:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lsr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.93.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lsr@ietf.org Message-ID: <155221797546.31098.10643511115077120069@ietfa.amsl.com> Date: Sun, 10 Mar 2019 04:39:35 -0700 Archived-At: Subject: [Lsr] I-D Action: draft-ietf-isis-sr-yang-05.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2019 11:39:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Link State Routing WG of the IETF. Title : YANG Data Model for IS-IS Segment Routing Authors : Stephane Litkowski Yinghzen Qu Pushpasis Sarkar Ing-Wher Chen Jeff Tantsura Filename : draft-ietf-isis-sr-yang-05.txt Pages : 24 Date : 2019-03-10 Abstract: This document defines a YANG data model that can be used to configure and manage IS-IS Segment Routing. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-isis-sr-yang/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-isis-sr-yang-05 https://datatracker.ietf.org/doc/html/draft-ietf-isis-sr-yang-05 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-isis-sr-yang-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 Sun Mar 10 09:09:58 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F17CA1277DE for ; Sun, 10 Mar 2019 09:09:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net 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 ohlPbTxZWHZ6 for ; Sun, 10 Mar 2019 09:09:55 -0700 (PDT) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 67BE3126D00 for ; Sun, 10 Mar 2019 09:09:55 -0700 (PDT) Received: by mail-qk1-x72d.google.com with SMTP id m9so1354852qkl.4 for ; Sun, 10 Mar 2019 09:09:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:from:date:message-id:subject:to:cc; bh=avxzzV/JhH0x+FEzCVgo2gkG+m+LWbGWyuen1q0FExM=; b=Gf44Q1Lugf/i48hU4TcrkP35xmZKqcdPkFNFKhcE/QDABROdo+FWfc4Ayt4LGITCjz 5xdcLG+X5enBCVtg/WAWDSW0P+/s0qUPvDKExQTE3y4xV+l/BTxfVcQX2KNiFXo8G0Vk SkaygC8sXZMpA1WghwgfnmxK74A3qw2apmEGA+Rh1oZDbZWpmJi8jEQ+E37CX9BJsvxJ iDu/T9sCfxO4vLnoJIeX29n6Y72iha9ODbFvnd1PtPy/i2SjJwDmhQiRDJegaRqa4aNG MQ/VDtSXxkaG7mVcWztHm3fb7yQA3xVPzHXOYQyHNMd4QF/7MeFV3MWlyoCSCXyWkrgf 4hxw== 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=avxzzV/JhH0x+FEzCVgo2gkG+m+LWbGWyuen1q0FExM=; b=B7KxP6nidENC8o6x8AqU4DLMGqB/KTFp38U0n4XaxUhOrw+Or32qTa4xEPqS+uSmGF TN3V2WTaiIfjasSIS8pEStEinADwv+hFEjsFUeX3f1d9BgHrNMbMp7Xz+r0YWNjC6SsL uVKV6O1lvjYr6d2IlOOWK6gUVrT4/OVxwpboMTv/adkz2jkgVWK4S6yRxSYTwPZI2bCx APGWOh8bbPV9/dy4MMhhZuhNwCXmStwqZrv3LnQ0T97BX3I8FFMzhJZsVK23A+XkYo8B Mz9Y36QHs1qcATi8hggmfbMqLVdEt74lq5pB4t9gxEQuNyINbBaR2M/AO/XZnTqfCjpw +b1A== X-Gm-Message-State: APjAAAUHxkH1gu5b0NqU7CuvxWs5EqV/MhvicaJ2p4CpaDmz1EIgqAby YeFJd5LcI+Lo35mebsPyF0hkMwVjbjw/XaOtqU1wyQ== X-Google-Smtp-Source: APXvYqwX7+GYAXlDfEgLrjfUBkjX9o0qqwuADcawATnYtpzWPEA7KLT1FkSAF3l00UuyZmRd6Ubyv5gl8weqXeCSGds= X-Received: by 2002:a37:d8c:: with SMTP id 134mr15599702qkn.336.1552234194516; Sun, 10 Mar 2019 09:09:54 -0700 (PDT) MIME-Version: 1.0 From: Robert Raszuk Date: Sun, 10 Mar 2019 17:09:44 +0100 Message-ID: To: "Ketan Talaulikar (ketant)" Cc: "idr@ietf. org" , lsr@ietf.org Content-Type: multipart/alternative; boundary="000000000000c5d29d0583bfaf34" Archived-At: Subject: [Lsr] draft-ketant-idr-bgp-ls-bgp-only-fabric X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Mar 2019 16:09:57 -0000 --000000000000c5d29d0583bfaf34 Content-Type: text/plain; charset="UTF-8" Hi Ketan, I have read your proposal of defining topology flooding in BGP with interest. It seems like a pretty brilliant twist to take pieces defined in other documents with their original intention for sending IGP information (LSDB or TED) over BGP extension and now use all of those without IGP at all :). But I have just one question here perhaps to the WG or ADs. Almost all normative references used in this draft clearly state that they were defined for carrying information present in ISIS & OSPF protocols as rather a courtesy of transporting them over TCP with BGP envelope between network and controller. Can we now just "reuse" verbatim all of those defined codepoints as well as redefine use of BGP-LS SAFI as a new link state p2p network topology transport just like that ? At min I would like to see some analysis included in this draft of running native link state protocol possibly with dynamic flooding optimization vs running BGP as the only routing protocol with using BGP as topology discovery transport before we proceed further on this document. Kind regards, Robert. --000000000000c5d29d0583bfaf34 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Ketan,

I have read = your proposal of defining topology flooding in BGP with interest.=C2=A0

It seems like a pretty brilliant twist to take pieces= defined in other documents with their original intention for sending IGP i= nformation (LSDB or TED) over BGP extension and now use all of those withou= t IGP at all :).=C2=A0

But I have just one questio= n here perhaps to the WG or ADs.=C2=A0

Almost all = normative references used in this draft clearly state that they were define= d for carrying information present in ISIS & OSPF protocols as rather a= courtesy of transporting them over TCP with BGP envelope between network a= nd controller.=C2=A0

Can we now just "reuse&q= uot; verbatim all of those defined codepoints as well as redefine use of BG= P-LS SAFI as a new link state p2p network topology transport just like that= ?=C2=A0

At min I would like to see some analysis = included in this draft of running native link state protocol possibly with = dynamic flooding optimization vs running BGP as the only routing protocol w= ith using BGP as topology discovery transport before we proceed further on = this document.=C2=A0

Kind regards,
Rober= t.

--000000000000c5d29d0583bfaf34-- From nobody Mon Mar 11 03:12:03 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B255B130F3E; Mon, 11 Mar 2019 03:11:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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=YQJiQ85V; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ixB8Oiqb 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 wiS302p7Sqhr; Mon, 11 Mar 2019 03:11:51 -0700 (PDT) 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 4A8B8130F3C; Mon, 11 Mar 2019 03:11:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12110; q=dns/txt; s=iport; t=1552299111; x=1553508711; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=Du36xVwe4JY4y0gjhglIJ4R+Ny+UJqmZhvQ8bCgrHII=; b=YQJiQ85VlWReuBridc4P6ZSfxDpL6PBcQk5CQCM9Banf7/g+dXdtDOxO jV7w2bT3Szg1o7pB0E2SwoG2DvJ2qfduJS+RFIqaTIDFMw04xaqxH5Zsp cG/O9gziyISiYqc9MPCFYNIWomF7ZT+cIiD2tEDUhDcpNBaCKOOM995b9 Q=; IronPort-PHdr: =?us-ascii?q?9a23=3A1ecS3RVCfBemiAuA/mcu+Hkk9MnV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSANSJ8OpK3uzRta2oGXcN55qMqjgjSNRNTF?= =?us-ascii?q?dE7KdehAk8GIiAAEz/IuTtank5EdhLUkNN9HCgOk8TE8H7NBXf?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAACbM4Zc/4gNJK1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBDS8kLANodAQLJ4QJg0cDhFCKZIJXkjOFc4E?= =?us-ascii?q?kA1QLAQEshEACF4QjIjQJDQEBAwEBBwEDAm0cDIVKAQEBBCMKEwEBNwEPAgE?= =?us-ascii?q?IEQQBASsCAgIwHQgCBA4FCIMbgRFMAxUBAqQbAooUcYEvgngBAQWEehiCDAi?= =?us-ascii?q?BLwGLLBeBQD+BEUaCTIUDgwgxgiaMTYQIhyqMJQkCkyOBeYVmg0mGVoE8nT8?= =?us-ascii?q?CBAIEBQIOAQEFgUc4gVZwFYMnggoMF4NLilNygSiPFAEB?= X-IronPort-AV: E=Sophos;i="5.58,467,1544486400"; d="scan'208,217";a="243877739" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Mar 2019 10:11:50 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPS id x2BABoGE015859 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 11 Mar 2019 10:11:50 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 11 Mar 2019 05:11:49 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 11 Mar 2019 05:11:48 -0500 Received: from NAM04-BN3-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.1473.3 via Frontend Transport; Mon, 11 Mar 2019 06:11:48 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Du36xVwe4JY4y0gjhglIJ4R+Ny+UJqmZhvQ8bCgrHII=; b=ixB8OiqbTPWUbPFgMf3UmwBVhRpMKXf97jwl2iZ3PJ9DBgL079OJAOhoB/O7YgH9I0mvrsQW/uBpSpKqoMgdoAzEymIoCQkyV6MJE2pIITsRfQvyAKuOtYdyfHisfmdS4WXV77WhVLCVaWHGE+WroVNL3O3UmOCkGR5o2QuTLjs= Received: from SN6PR11MB2845.namprd11.prod.outlook.com (52.135.93.24) by SN6PR11MB2960.namprd11.prod.outlook.com (52.135.124.93) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.21; Mon, 11 Mar 2019 10:11:47 +0000 Received: from SN6PR11MB2845.namprd11.prod.outlook.com ([fe80::117:6d33:4c0a:a1b3]) by SN6PR11MB2845.namprd11.prod.outlook.com ([fe80::117:6d33:4c0a:a1b3%3]) with mapi id 15.20.1686.021; Mon, 11 Mar 2019 10:11:47 +0000 From: "Ketan Talaulikar (ketant)" To: Robert Raszuk CC: "idr@ietf. org" , "lsr@ietf.org" Thread-Topic: draft-ketant-idr-bgp-ls-bgp-only-fabric Thread-Index: AQHU11u2Esy9S6n3LkKjkXKzoMZcmKYGM+Dw Date: Mon, 11 Mar 2019 10:11:47 +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: spf=none (sender IP is ) smtp.mailfrom=ketant@cisco.com; x-originating-ip: [2001:420:c0e0:1002::d9] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: fc854fcd-7fb1-4d27-4d18-08d6a609f8d8 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:SN6PR11MB2960; x-ms-traffictypediagnostic: SN6PR11MB2960: x-microsoft-exchange-diagnostics: =?utf-8?B?MTtTTjZQUjExTUIyOTYwOzIzOjlwSnBmMnB3ZXRsd2l1N2E4eVhxTEZKd3No?= =?utf-8?B?d3g2dzB2TThvaTVYNFNDcXZDY2cwcXlWOUxWQ2tmTmFxYlRoc29maDhlbXBN?= =?utf-8?B?dlpTMzFxYWpHVlpINFlnZENjN3Bwak1Rc1RBYzlTWU5SVG1Bek9KcHB2L2JH?= =?utf-8?B?UzdVSHVSRjNHdHc3RGtqSG5zL1NhR1Q1U29JZXpRblkxSlNSc2E4d3NueHFO?= =?utf-8?B?dVpvbktQWFFMSC9Kdm0ramtSb1FhRFp0azRUOFdtSUZTenpQRjdudjRHTUxN?= =?utf-8?B?STRhQmhWdHdTUnEvOUFvNUM1Zm9aSEY3c2JKcU9XL2R0NjdKMEZkd3dhODFr?= =?utf-8?B?QVIwVVAzK1dQVk11VnhXVnpxUVNVNnI3Vk9leEYxb1NQS3ZlcTMxOVpnM2FV?= =?utf-8?B?cTVvb0UxUjdKWTFHMjBFUGo1anN1VThOZVUyYVNISmVlLzdVR3p6U1ZSRDRR?= =?utf-8?B?Z2k2WG52dW9Rdis2c0ZEV1cyK2w2ZGpmZnJjczd0Wk5vMi9OMmRPQVB0OGZV?= =?utf-8?B?U3hFdU1HdmNhYm5NWm40RjhRaTVlL1RHUTd6Y2tDeld2NU04NkdNOWpDbWIr?= =?utf-8?B?VnQ4YUJYaXM5MFZIWWpNeXdnMGZ5SWtNeW53SjhIU09BTXdieXVodnhtNmRh?= =?utf-8?B?TDAyZ093WFdSODAzcHVyUUVYQ0dhbjhoNlVIT2UrNThOQi9MMTg0SU1CMEY3?= =?utf-8?B?VEgzZC9iQmJOcmcrL2FhTzlENFpGeE1nR09ONVkrVzlBNEVQWjNyUWk1Z243?= =?utf-8?B?S2VUci94M3BZUXRuTzdsS293UndzQWtvM2cyVjdEZlhLRDNBblJnMUh2YXp4?= =?utf-8?B?ZmVyMEM0YnBGcS81eHVyeVJZR3V0dWxqNE5HZkN0UFgvM2VTNUlkVi9rT0JW?= =?utf-8?B?YUZZS09nSWJEN2xYWmtrUS9jaXA0WVI3ZnUvdWpxYnREWkg4SjNaK0pQZlls?= =?utf-8?B?MGFNUTh6UUNMdUgzdnZtQkFwTWlRQnk2bkJVeFRodkswL0cxcGZwb2R0K2Rv?= =?utf-8?B?eHlRTWNTclhmN0k4MCtEcS85cTZyVWtjYnF3TVMwc0ptRVAzWFhFM1hsSjFy?= =?utf-8?B?NnZIaDNEckJEQkFkZ1Y1M3ZFbVlpbFFtTWppWWtRQjBpWXhqQ2FiL1NEc1Nt?= =?utf-8?B?ZUZWa3NqcG11cnd2REI0aEVQV09USEViWWQvYlNURlFjeGQ1bHpnYitNd0k3?= =?utf-8?B?U21jTDRlT2sxdFoycXJITWtkUk95ZVg3THFOL0p3TmUxNVNNNENCUHpuQ2VW?= =?utf-8?B?cUpiQURhSG9nWTN1ZHpteG5MWjBxWmJLbk5MYzBjRkZQV1ZnRUUySVNtaHU3?= =?utf-8?B?NUgyT0dhUEFuTDBDZHBTN1Z2Vzc5NW1rQmdYUG9CZDlXaWNsTGJ3VWQ3VlhW?= =?utf-8?B?ODBUMDc2UnFFcS9sNTRqcmNXYkxpQ2cyeTNlcHU2SnkxSzg4dTNDam9CaHFq?= =?utf-8?B?b3h0U3lmS2tVL1JtYjVQemgyc1UxbG9ONVg2VUk1Q2czUjBFZzQ5dXhOQUtk?= =?utf-8?B?RGFhWDZKcHNxMkVFcVg2ZU9JNDVISW1aSldHeHEzSmVsbC82Yjk5OFA5ZGtO?= =?utf-8?B?V3hTQ3NPclNJYlBYQnVZTFBMZk5BbXQ4c2J5SXJKai9POTYxTzljUlVDQkZ5?= =?utf-8?B?Z2pUakdQS3RUREtBSmtVUHkyUzhaZWFsNkNOSEp6NVQ3LzJLallyRDVnR0JX?= =?utf-8?B?MGtsajBmditCbkRNZFkwcW0vazVLZGVpQ3JlOVk3ekVLNFYvUHd3TEhuTUdV?= =?utf-8?B?RDhqb08yMFZPcE1XUjRJZz09?= x-microsoft-antispam-prvs: x-forefront-prvs: 09730BD177 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(396003)(136003)(346002)(366004)(39860400002)(199004)(189003)(71190400001)(71200400001)(33656002)(9326002)(9686003)(316002)(229853002)(53936002)(25786009)(6246003)(476003)(4326008)(52536013)(5660300002)(46003)(68736007)(66574012)(14454004)(11346002)(446003)(2906002)(54906003)(561944003)(55016002)(6306002)(54896002)(6436002)(8936002)(256004)(7696005)(6506007)(53546011)(99286004)(76176011)(478600001)(86362001)(102836004)(186003)(6916009)(105586002)(81156014)(81166006)(106356001)(790700001)(6116002)(8676002)(486006)(7736002)(74316002)(97736004); DIR:OUT; SFP:1101; SCL:1; SRVR:SN6PR11MB2960; H:SN6PR11MB2845.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 8yMibDEYsYn4lfI6Dq/Ffc4o82An2oRHYsQ7f8uRm4IMchSgnkjcu+MNwe7EXd5mGRSaTEWoiogJin1Cum5V2h+JGKS1hsvPb8+PjwkqIEYqc8b4Eh9Tx2F5vk8fc1PAhLqMZoDxAPPhlLyusVKjDMi3AVjTaZzgJFnQzQaJ/oB0/tLq6EQKkWTJqmaMiPDihE2kIP9wPW2k9zMwthygCJQ+A2sckMyDsjHYMYubKH1uguQPi4fqY8uAJHsSZ8gY3rQ25dc5HAxjUq8kKak7jj+/Ai2Tt8yUPODsVswKFu/MISBQSXCDlVYTyJ4htCObxdG5p5wxkEolRhK2dVi0d1yahtZVz4IHSED4tN1YQOYNRy306tdUkqsnJNsZ+82UJGPwmT0UayfoCt5fVNf8DZkPb2EzqPpqd/86zUdrMm0= Content-Type: multipart/alternative; boundary="_000_SN6PR11MB28455D5C90231EA6DC2D9239C1480SN6PR11MB2845namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: fc854fcd-7fb1-4d27-4d18-08d6a609f8d8 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2019 10:11:47.8134 (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-Transport-CrossTenantHeadersStamped: SN6PR11MB2960 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.17, xch-rcd-007.cisco.com X-Outbound-Node: alln-core-3.cisco.com Archived-At: Subject: Re: [Lsr] draft-ketant-idr-bgp-ls-bgp-only-fabric X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 10:11:55 -0000 --_000_SN6PR11MB28455D5C90231EA6DC2D9239C1480SN6PR11MB2845namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUm9iZXJ0LA0KDQpQbGVhc2UgY2hlY2sgaW5saW5lIGJlbG93Lg0KDQpGcm9tOiBSb2JlcnQg UmFzenVrIDxyb2JlcnRAcmFzenVrLm5ldD4NClNlbnQ6IDEwIE1hcmNoIDIwMTkgMjE6NDANClRv OiBLZXRhbiBUYWxhdWxpa2FyIChrZXRhbnQpIDxrZXRhbnRAY2lzY28uY29tPg0KQ2M6IGlkckBp ZXRmLiBvcmcgPGlkckBpZXRmLm9yZz47IGxzckBpZXRmLm9yZw0KU3ViamVjdDogZHJhZnQta2V0 YW50LWlkci1iZ3AtbHMtYmdwLW9ubHktZmFicmljDQoNCkhpIEtldGFuLA0KDQpJIGhhdmUgcmVh ZCB5b3VyIHByb3Bvc2FsIG9mIGRlZmluaW5nIHRvcG9sb2d5IGZsb29kaW5nIGluIEJHUCB3aXRo IGludGVyZXN0Lg0KDQpJdCBzZWVtcyBsaWtlIGEgcHJldHR5IGJyaWxsaWFudCB0d2lzdCB0byB0 YWtlIHBpZWNlcyBkZWZpbmVkIGluIG90aGVyIGRvY3VtZW50cyB3aXRoIHRoZWlyIG9yaWdpbmFs IGludGVudGlvbiBmb3Igc2VuZGluZyBJR1AgaW5mb3JtYXRpb24gKExTREIgb3IgVEVEKSBvdmVy IEJHUCBleHRlbnNpb24gYW5kIG5vdyB1c2UgYWxsIG9mIHRob3NlIHdpdGhvdXQgSUdQIGF0IGFs bCA6KS4NCltLVF0gUkZDNzc1MiBkaWQgYWx3YXlzIGhhdmUg4oCcZGlyZWN04oCdIGFuZCDigJxz dGF0aWPigJ0gcHJvdG9jb2xzIOKAkyBzbyBpdCB3YXMgbm90IGp1c3QgSUdQcy4gV2UgZXh0ZW5k ZWQgdG8gaW5jbHVkZSBCR1AgcHJvdG9jb2wgZm9yIGRlc2NyaWJpbmcgUGVlcmluZyB0b3BvbG9n eSBmb3IgdGhlIEVQRSB1c2UtY2FzZSB3aXRoIGRyYWZ0LWlldGYtaWRyLWJncGxzLXNlZ21lbnQt cm91dGluZy1lcGUNCg0KQnV0IEkgaGF2ZSBqdXN0IG9uZSBxdWVzdGlvbiBoZXJlIHBlcmhhcHMg dG8gdGhlIFdHIG9yIEFEcy4NCg0KQWxtb3N0IGFsbCBub3JtYXRpdmUgcmVmZXJlbmNlcyB1c2Vk IGluIHRoaXMgZHJhZnQgY2xlYXJseSBzdGF0ZSB0aGF0IHRoZXkgd2VyZSBkZWZpbmVkIGZvciBj YXJyeWluZyBpbmZvcm1hdGlvbiBwcmVzZW50IGluIElTSVMgJiBPU1BGIHByb3RvY29scyBhcyBy YXRoZXIgYSBjb3VydGVzeSBvZiB0cmFuc3BvcnRpbmcgdGhlbSBvdmVyIFRDUCB3aXRoIEJHUCBl bnZlbG9wZSBiZXR3ZWVuIG5ldHdvcmsgYW5kIGNvbnRyb2xsZXIuDQoNCkNhbiB3ZSBub3cganVz dCAicmV1c2UiIHZlcmJhdGltIGFsbCBvZiB0aG9zZSBkZWZpbmVkIGNvZGVwb2ludHMgYXMgd2Vs bCBhcyByZWRlZmluZSB1c2Ugb2YgQkdQLUxTIFNBRkkgYXMgYSBuZXcgbGluayBzdGF0ZSBwMnAg bmV0d29yayB0b3BvbG9neSB0cmFuc3BvcnQganVzdCBsaWtlIHRoYXQgPw0KW0tUXSBUaGUgQkdQ LUxTIFNBRkkgaXMgc3RpbGwgdXNlZCB0byByZXBvcnQgbGluay1zdGF0ZSBpbmZvcm1hdGlvbi4g VGhpcyBkcmFmdCBkZXNjcmliZXMgaG93IGl0IGNhbiBiZSBkb25lIGV2ZW4gd2hlbiBubyBJR1Ag aXMgcnVubmluZyBhbmQgd2UgYXJlIGluc3RlYWQgcnVubmluZyBCR1AgcHJvdG9jb2wgKGluIFJG Qzc5MzggaG9wLWJ5LWhvcCByb3V0aW5nIGRlc2lnbikuIEVhY2ggcm91dGVyIGhlcmUgaXMgc2V0 dGluZyB1cCBhIEJHUC1MUyBzZXNzaW9uIHdpdGggYSBjb250cm9sbGVyIG9yIGEgY2VudHJhbGl6 ZWQgQkdQIHNwZWFrZXIgdG8gcmVwb3J0IHRoZSByb3V0ZXLigJlzIG93biBub2RlIHByb3BlcnRp ZXMsIGxpbmtzLCBwcmVmaXhlcywgZXRjLiBUaGUgb2JqZWN0aXZlIGlzIGJ1aWxkIGEgbGluay1z dGF0ZSB0b3BvbG9neSBhdCB0aGUgY29udHJvbGxlciBmb3Igc3BlY2lmaWMgdXNlLWNhc2VzIGxp a2UgdG9wb2xvZ3kgZGlzY292ZXJpbmcgYW5kIFRFIHdpdGggU1IgYXMgZGVzY3JpYmVkIGluIFNl YyA2IG9mIHRoZSBkcmFmdC4NCg0KQXQgbWluIEkgd291bGQgbGlrZSB0byBzZWUgc29tZSBhbmFs eXNpcyBpbmNsdWRlZCBpbiB0aGlzIGRyYWZ0IG9mIHJ1bm5pbmcgbmF0aXZlIGxpbmsgc3RhdGUg cHJvdG9jb2wgcG9zc2libHkgd2l0aCBkeW5hbWljIGZsb29kaW5nIG9wdGltaXphdGlvbiB2cyBy dW5uaW5nIEJHUCBhcyB0aGUgb25seSByb3V0aW5nIHByb3RvY29sIHdpdGggdXNpbmcgQkdQIGFz IHRvcG9sb2d5IGRpc2NvdmVyeSB0cmFuc3BvcnQgYmVmb3JlIHdlIHByb2NlZWQgZnVydGhlciBv biB0aGlzIGRvY3VtZW50Lg0KW0tUXSBJIGFtIG5vdCBzdXJlIEkgc2VlIHRoZSBjb250cmFzdCBo ZXJlLiBQZXJzb25hbGx5LCBJIHN1cHBvcnQgdGhlIGR5bmFtaWMgZmxvb2Rpbmcgb3B0aW1pemF0 aW9uIHdvcmsgaW4gTFNSLiBUaGVyZSBhcmUgYWxyZWFkeSBEQyBuZXR3b3JrcyBkZXBsb3llZCB3 aXRoIFJGQzc5MzggZGVzaWduLiBBbGwgdGhpcyBkcmFmdCBpcyBpbnRyb2R1Y2luZyBpcyB0b3Bv bG9neSBkaXNjb3ZlcnkgYW5kIG90aGVyIHVzZS1jYXNlcyBpbiB0aGUgbGF0dGVyLg0KDQpUaGFu a3MsDQpLZXRhbg0KDQpLaW5kIHJlZ2FyZHMsDQpSb2JlcnQuDQoNCg== --_000_SN6PR11MB28455D5C90231EA6DC2D9239C1480SN6PR11MB2845namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5t c29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBjbTsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowY207DQoJZm9udC1zaXplOjExLjBwdDsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOA0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlm Ow0KCW1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjYxMi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0 O30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48 IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNw aWRtYXg9IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCjxvOnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBk YXRhPSIxIiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0K PGJvZHkgbGFuZz0iRU4tSU4iIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYg Y2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPkhpIFJvYmVydCw8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+UGxlYXNlIGNoZWNr IGlubGluZSBiZWxvdy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIGxhbmc9IkVOLVVT Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiPiBSb2JlcnQgUmFzenVrICZsdDty b2JlcnRAcmFzenVrLm5ldCZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiAxMCBNYXJjaCAyMDE5IDIx OjQwPGJyPg0KPGI+VG86PC9iPiBLZXRhbiBUYWxhdWxpa2FyIChrZXRhbnQpICZsdDtrZXRhbnRA Y2lzY28uY29tJmd0Ozxicj4NCjxiPkNjOjwvYj4gaWRyQGlldGYuIG9yZyAmbHQ7aWRyQGlldGYu b3JnJmd0OzsgbHNyQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IGRyYWZ0LWtldGFudC1p ZHItYmdwLWxzLWJncC1vbmx5LWZhYnJpYzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5IaSBLZXRhbiw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPkkgaGF2ZSByZWFkIHlvdXIgcHJvcG9zYWwgb2YgZGVmaW5pbmcgdG9wb2xv Z3kgZmxvb2RpbmcgaW4gQkdQIHdpdGggaW50ZXJlc3QuJm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkl0IHNlZW1zIGxpa2UgYSBwcmV0 dHkgYnJpbGxpYW50IHR3aXN0IHRvIHRha2UgcGllY2VzIGRlZmluZWQgaW4gb3RoZXIgZG9jdW1l bnRzIHdpdGggdGhlaXIgb3JpZ2luYWwgaW50ZW50aW9uIGZvciBzZW5kaW5nIElHUCBpbmZvcm1h dGlvbiAoTFNEQiBvciBURUQpIG92ZXIgQkdQIGV4dGVuc2lvbiBhbmQgbm93IHVzZSBhbGwgb2Yg dGhvc2Ugd2l0aG91dCBJR1AgYXQgYWxsIDopLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PGk+W0tUXSBSRkM3NzUyIGRpZCBhbHdheXMgaGF2ZSDigJxkaXJl Y3TigJ0gYW5kIOKAnHN0YXRpY+KAnSBwcm90b2NvbHMg4oCTIHNvIGl0IHdhcyBub3QganVzdCBJ R1BzLiBXZSBleHRlbmRlZCB0byBpbmNsdWRlIEJHUCBwcm90b2NvbCBmb3IgZGVzY3JpYmluZyBQ ZWVyaW5nIHRvcG9sb2d5IGZvciB0aGUgRVBFIHVzZS1jYXNlIHdpdGggZHJhZnQtaWV0Zi1pZHIt YmdwbHMtc2VnbWVudC1yb3V0aW5nLWVwZTwvaT48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJ1dCBJIGhhdmUganVzdCBvbmUgcXVlc3Rp b24gaGVyZSBwZXJoYXBzIHRvIHRoZSBXRyBvciBBRHMuJm5ic3A7PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsbW9zdCBhbGwgbm9ybWF0aXZl IHJlZmVyZW5jZXMgdXNlZCBpbiB0aGlzIGRyYWZ0IGNsZWFybHkgc3RhdGUgdGhhdCB0aGV5IHdl cmUgZGVmaW5lZCBmb3IgY2FycnlpbmcgaW5mb3JtYXRpb24gcHJlc2VudCBpbiBJU0lTICZhbXA7 IE9TUEYgcHJvdG9jb2xzIGFzIHJhdGhlciBhIGNvdXJ0ZXN5IG9mIHRyYW5zcG9ydGluZyB0aGVt IG92ZXIgVENQIHdpdGggQkdQIGVudmVsb3BlIGJldHdlZW4gbmV0d29yayBhbmQgY29udHJvbGxl ci4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+Q2FuIHdlIG5vdyBqdXN0ICZxdW90O3JldXNlJnF1b3Q7IHZlcmJhdGltIGFsbCBvZiB0 aG9zZSBkZWZpbmVkIGNvZGVwb2ludHMgYXMgd2VsbCBhcyByZWRlZmluZSB1c2Ugb2YgQkdQLUxT IFNBRkkgYXMgYSBuZXcgbGluayBzdGF0ZSBwMnAgbmV0d29yayB0b3BvbG9neSB0cmFuc3BvcnQg anVzdCBsaWtlIHRoYXQgPyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PGk+W0tUXSBUaGUgQkdQLUxTIFNBRkkgaXMgc3RpbGwgdXNlZCB0byByZXBvcnQgbGlu ay1zdGF0ZSBpbmZvcm1hdGlvbi4gVGhpcyBkcmFmdCBkZXNjcmliZXMgaG93IGl0IGNhbiBiZSBk b25lIGV2ZW4gd2hlbiBubyBJR1AgaXMgcnVubmluZyBhbmQgd2UgYXJlIGluc3RlYWQgcnVubmlu ZyBCR1AgcHJvdG9jb2wgKGluIFJGQzc5MzggaG9wLWJ5LWhvcCByb3V0aW5nIGRlc2lnbikuIEVh Y2ggcm91dGVyIGhlcmUNCiBpcyBzZXR0aW5nIHVwIGEgQkdQLUxTIHNlc3Npb24gd2l0aCBhIGNv bnRyb2xsZXIgb3IgYSBjZW50cmFsaXplZCBCR1Agc3BlYWtlciB0byByZXBvcnQgdGhlIHJvdXRl cuKAmXMgb3duIG5vZGUgcHJvcGVydGllcywgbGlua3MsIHByZWZpeGVzLCBldGMuIFRoZSBvYmpl Y3RpdmUgaXMgYnVpbGQgYSBsaW5rLXN0YXRlIHRvcG9sb2d5IGF0IHRoZSBjb250cm9sbGVyIGZv ciBzcGVjaWZpYyB1c2UtY2FzZXMgbGlrZSB0b3BvbG9neSBkaXNjb3ZlcmluZw0KIGFuZCBURSB3 aXRoIFNSIGFzIGRlc2NyaWJlZCBpbiBTZWMgNiBvZiB0aGUgZHJhZnQuPC9pPjwvYj48bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXQgbWluIEkg d291bGQgbGlrZSB0byBzZWUgc29tZSBhbmFseXNpcyBpbmNsdWRlZCBpbiB0aGlzIGRyYWZ0IG9m IHJ1bm5pbmcgbmF0aXZlIGxpbmsgc3RhdGUgcHJvdG9jb2wgcG9zc2libHkgd2l0aCBkeW5hbWlj IGZsb29kaW5nIG9wdGltaXphdGlvbiB2cyBydW5uaW5nIEJHUCBhcyB0aGUgb25seSByb3V0aW5n IHByb3RvY29sIHdpdGggdXNpbmcgQkdQIGFzIHRvcG9sb2d5IGRpc2NvdmVyeSB0cmFuc3BvcnQN CiBiZWZvcmUgd2UgcHJvY2VlZCBmdXJ0aGVyIG9uIHRoaXMgZG9jdW1lbnQuJm5ic3A7PG86cD48 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48aT5bS1RdIEkgYW0gbm90IHN1cmUg SSBzZWUgdGhlIGNvbnRyYXN0IGhlcmUuIFBlcnNvbmFsbHksIEkgc3VwcG9ydCB0aGUgZHluYW1p YyBmbG9vZGluZyBvcHRpbWl6YXRpb24gd29yayBpbiBMU1IuIFRoZXJlIGFyZSBhbHJlYWR5IERD IG5ldHdvcmtzIGRlcGxveWVkIHdpdGggUkZDNzkzOCBkZXNpZ24uIEFsbCB0aGlzIGRyYWZ0IGlz IGludHJvZHVjaW5nIGlzIHRvcG9sb2d5IGRpc2NvdmVyeSBhbmQgb3RoZXINCiB1c2UtY2FzZXMg aW4gdGhlIGxhdHRlci48bzpwPjwvbzpwPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PGk+PG86cD4mbmJzcDs8L286cD48L2k+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxiPjxpPlRoYW5rcyw8bzpwPjwvbzpwPjwvaT48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGI+PGk+S2V0YW48L2k+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5LaW5kIHJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Sb2JlcnQuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_SN6PR11MB28455D5C90231EA6DC2D9239C1480SN6PR11MB2845namp_-- From nobody Mon Mar 11 10:11:07 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE5741277D8; Mon, 11 Mar 2019 10:08:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 7jJAEgyuhkDn; Mon, 11 Mar 2019 10:08:19 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6A54124BF6; Mon, 11 Mar 2019 10:08:18 -0700 (PDT) Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 5C206EEBF51D268E55EE; Mon, 11 Mar 2019 17:08:16 +0000 (GMT) Received: from lhreml703-chm.china.huawei.com (10.201.108.52) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.408.0; Mon, 11 Mar 2019 17:08:16 +0000 Received: from lhreml703-chm.china.huawei.com (10.201.108.52) by lhreml703-chm.china.huawei.com (10.201.108.52) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1591.10; Mon, 11 Mar 2019 17:08:15 +0000 Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml703-chm.china.huawei.com (10.201.108.52) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA_P256) id 15.1.1591.10 via Frontend Transport; Mon, 11 Mar 2019 17:08:15 +0000 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.179]) by SJCEML703-CHM.china.huawei.com ([169.254.5.104]) with mapi id 14.03.0415.000; Mon, 11 Mar 2019 10:08:09 -0700 From: Huaimo Chen To: "tony.li@tony.li" CC: "lsr@ietf.org" , "lsr-chairs@ietf.org" , "lsr-ads@ietf.org" Thread-Topic: Multiple failures in Dynamic Flooding Thread-Index: AQHU1DOh90IUANMeGEWHdn8fMqQEB6YGlyHw Date: Mon, 11 Mar 2019 17:08:09 +0000 Message-ID: <5316A0AB3C851246A7CA5758973207D463B76FDD@sjceml521-mbx.china.huawei.com> References: <5316A0AB3C851246A7CA5758973207D463B5858A@sjceml521-mbx.china.huawei.com> <420ed1b5-d849-99cc-bcb0-d159783e4de2@cisco.com> <5316A0AB3C851246A7CA5758973207D463B59041@sjceml521-mbx.china.huawei.com> <0B4DF2AC-8EE1-41CA-B357-98325067CA30@gmail.com> <5316A0AB3C851246A7CA5758973207D463B66FE9@sjceml521-mbx.china.huawei.com> <78A866F4-9AF0-481A-9DEC-B04DE72AFDA3@tony.li> In-Reply-To: <78A866F4-9AF0-481A-9DEC-B04DE72AFDA3@tony.li> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.164] Content-Type: multipart/alternative; boundary="_000_5316A0AB3C851246A7CA5758973207D463B76FDDsjceml521mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Lsr] Multiple failures in Dynamic Flooding X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 17:08:22 -0000 --_000_5316A0AB3C851246A7CA5758973207D463B76FDDsjceml521mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVG9ueSwNCg0KICAgIEluIHN1bW1hcnkgZm9yIG11bHRpcGxlIGZhaWx1cmVzLCB0d28gaXNz dWVzIGJlbG93IGluIGRyYWZ0LWxpLWxzci1keW5hbXlpYy1mbG9vZGluZyBhcmUgZGlzY3Vzc2Vk Og0KDQoxKSAgICAgIGhvdyB0byBkZXRlcm1pbmUgdGhlIGN1cnJlbnQgZmxvb2RpbmcgdG9wb2xv Z3kgaXMgc3BsaXQ7IGFuZA0KDQoyKSAgICAgIGhvdyB0byByZXBhaXIvY29ubmVjdCB0aGUgZmxv b2RpbmcgdG9wb2xvZ3kgc3BsaXQuDQpGb3IgdGhlIGZpcnN0IGlzc3VlLCB0aGUgZGlzY3Vzc2lv bnMgYXJlIHN0aWxsIGdvaW5nIG9uLg0KRm9yIHRoZSBzZWNvbmQgaXNzdWUsIHJlcGFpcmluZy9j b25uZWN0aW5nIHRoZSBmbG9vZGluZyB0b3BvbG9neSBzcGxpdCB0aHJvdWdoIEhlbGxvIHByb3Rv Y29sIGV4dGVuc2lvbnMgZG9lcyBub3Qgd29yay4gIFdoZW4gYSDigJxiYWNrdXAgcGF0aOKAnS9j b25uZWN0aW9uIG9mIG11bHRpcGxlIGhvcHMgaXMgbmVlZGVkIHRvIGNvbm5lY3QvcmVwYWlyIHRo ZSBmbG9vZGluZyB0b3BvbG9neSBzcGxpdCwgSGVsbG8gY2FuIG5vdCBnbyBiZXlvbmQgb25lIGhv cCwgdGh1cyBjYW4gbm90IHJlcGFpciB0aGUgZmxvb2RpbmcgdG9wb2xvZ3kgc3BsaXQgaW4gdGhp cyBjYXNlLg0KDQo+RnJvbTogVG9ueSBMaSBbbWFpbHRvOnRvbnkxYXRob21lQGdtYWlsLmNvbV0g T24gQmVoYWxmIE9mIHRvbnkubGlAdG9ueS5saQ0KPlNlbnQ6IFdlZG5lc2RheSwgTWFyY2ggNiwg MjAxOSAxMDo0NSBBTQ0KPlRvOiBIdWFpbW8gQ2hlbiA8aHVhaW1vLmNoZW5AaHVhd2VpLmNvbT4N Cj5DYzogQ2hyaXN0aWFuIEhvcHBzIDxjaG9wcHNAY2hvcHBzLm9yZz47IGxzckBpZXRmLm9yZzsg bHNyLWNoYWlyc0BpZXRmLm9yZzsgbHNyLWFkc0BpZXRmLm9yZw0KPlN1YmplY3Q6IE11bHRpcGxl IGZhaWx1cmVzIGluIER5bmFtaWMgRmxvb2RpbmcNCj4NCj5IaSBIdWFpbW8sDQo+DQo+Pj4gSeKA mW0gc29ycnkgdGhhdCB5b3UgZG9u4oCZdCBmaW5kIGl0IHVzZWZ1bC4gRGV0ZXJtaW5pbmcgdGhl IHNwbGl0IGlzIHRyaXZpYWw6IHdoZW4geW91IHJlY2VpdmUgYW4gSUlILA0KPj4+IGl0IGhhcyBh IHN5c3RlbSBJRCBvZiB0aGUgYW5vdGhlciBzeXN0ZW0gaW4gaXQuIElmIHRoYXQgb3RoZXIgc3lz dGVtIGlzIG5vdCBjdXJyZW50bHkgcGFydCBvZiB0aGUNCj4+PiBmbG9vZGluZyB0b3BvbG9neSwg dGhlbiBpdCBpcyBxdWl0ZSBjbGVhciB0aGF0IGl0IGlzIGRpc2Nvbm5lY3RlZCBmcm9tIHRoZSBm bG9vZGluZyB0b3BvbG9neS4NCj4+PiBSZXBhaXJpbmcgdGhlIHNwbGl0IGlzIGRvbmUgYnkgZW5h YmxpbmcgdGVtcG9yYXJ5IGZsb29kaW5nIG9uIHRoZSBuZXcgbGluay4NCg0KPj5Gb3IgYW4gYWRq YWNlbmN5IGJldHdlZW4gdHdvIG5vZGVzIGlzIHVwLCB0aGUgSGVsbG8gcGFja2V0cyBleGNoYW5n ZWQgYmV0d2VlbiB0aGVtIHdpbGwgbm90IGNoYW5nZSBub2RlL3N5c3RlbSBJRHMgaW4gdGhlbS4N Cj4+SG93IGRvIHlvdSBkZXRlcm1pbmUgdGhhdCBvdGhlciBzeXN0ZW0gaXMgbm90IGN1cnJlbnRs eSBwYXJ0IG9mIHRoZSBmbG9vZGluZyB0b3BvbG9neT8NCg0KPlRoZSBJSUggaW5jbHVkZXMgdGhl IHN5c3RlbSBJRC4gIFNlZSBJU08gMTA1ODkgdjIsIHNlY3Rpb24gOS43LCBmaWVsZCDigJxzb3Vy Y2UgSWTigJ0uICBUaGUgbG9jYWwgc3lzdGVtIHdpbGwgaGF2ZQ0KPmEgY29weSBvZiB0aGUgZmxv b2RpbmcgdG9wb2xvZ3kgYW5kIGNhbiBlYXNpbHkgc2VlIGlmIHRoZSBuZWlnaGJvciB3YXMgcHJl c2VudCBhcyBvZiB0aGUgbGFzdCBGVCBjb21wdXRhdGlvbi4gIElmIG5vdCwgdGhlbiBpdCBzaG91 bGQgYmUNCj5hZGRlZCAobW9kdWxvIHJhdGUgbGltaXRpbmcpLiBUaGUgbG9jYWwgc3lzdGVtIGNh biBhbHNvIGV4YW1pbmUgaXTigJlzIG93biBMU0RCLiAgSWYgdGhlcmUgaXMgbm8gTFNQIGZvciB0 aGUgbmVpZ2hib3IsIHRoZW4gaXQgd291bGQgc2VlbQ0KPmhpZ2hseSBsaWtlbHkgdGhhdCB0aGVy ZSBpcyBhIGRpc2Nvbm5lY3QgYW5kIHRoZSBuZWlnaGJvciBzaG91bGQgYWdhaW4gYmUgYWRkZWQg KG1vZHVsbyByYXRlIGxpbWl0aW5nKS4NCg0KPldlIGFyZSBub3QgcmVxdWlyaW5nIGl0LCBidXQg YSBzeXN0ZW0gY291bGQgYWxzbyBkbyBhIG1vcmUgZXh0ZW5zaXZlIGNvbXB1dGF0aW9uIGFuZCBj b21wYXJlIHRoZSBsaW5rcyBiZXR3ZWVuIGl0c2VsZiBhbmQgdGhlIG5laWdoYm9yDQo+YnkgdHJh Y2luZyB0aGUgcGF0aCBpbiB0aGUgRlQgYW5kIHRoZW4gY29uZmlybWluZyB0aGF0IGVhY2ggbGlu ayBpcyB1cCBpbiB0aGUgTFNEQi4NCg0KSXQgbm9ybWFsbHkgdGFrZXMgYSBsb25nIHRpbWUgc3Vj aCBhcyBtb3JlIHRoYW4gdGVuIG1pbnV0ZXMgdG8gYWdlIG91dCBhbmQgcmVtb3ZlIGFuIExTUC9M U0EgZm9yIHRoZSBuZWlnaGJvciBmcm9tIHRoZSBMU0RCIGV2ZW4gdGhvdWdoIHRoZSBuZWlnaGJv ciBpcyBkaXNjb25uZWN0ZWQgcGh5c2ljYWxseS4NCkhvdyBjYW4geW91IGRlY2lkZSBxdWlja2x5 IGluIHRlbnMgb2YgbWlsbGlzZWNvbmRzIHRoYXQgdGhlIGZsb29kaW5nIHRvcG9sb2d5IGlzIGRp c2Nvbm5lY3RlZD8NCg0KPj4+IFRoZXJlIGlzIGFuIGlzc3VlIGhlcmUgdGhhdCB3ZSBoYXZlIG5v dCB5ZXQgcmVzb2x2ZWQsIHdoaWNoIGlzIHRoZSByYXRlIHRoYXQgbmV3IGxpbmtzIHNob3VsZCBi ZQ0KPj4+IHRlbXBvcmFyaWx5IGFkZGVkIHRvIHRoZSBmbG9vZGluZyB0b3BvbG9neS4gIFNvbWUg YmVsaWV2ZSB0aGF0IGFkZGluZyBhbnkgbmV3IGxpbmsgaXMgdGhlDQo+Pj4gY29ycmVjdCB0aGlu ZyB0byBkbyBhcyBpdCBtaW5pbWl6ZXMgdGhlIHJlY292ZXJ5IHRpbWUuIE90aGVycyBmZWVsIHRo YXQgZW5hYmxpbmcgdG9vIG1hbnkgbGlua3MNCj4+PiBjb3VsZCBjYXVzZSBhIGZsb29kaW5nIGNv bGxhcHNlLCBzbyBsaW5rIGFkZGl0aW9uIHNob3VsZCBiZSBoaWdobHkgY29uc3RyYWluZWQuIFdl IGFyZSBzdGlsbA0KPj4+IGRpc2N1c3NpbmcgdGhpcyBhbmQgaW52aXRlIHRoZSBXR+KAmXMgb3Bp bmlvbnMuDQoNCj4+VGhlIGlzc3VlIGlzIHJlc29sdmVkIGJ5IHRoZSBzb2x1dGlvbnMgaW4gZHJh ZnQtY2MtbHNyLWZsb29kaW5nLXJlZHVjdGlvbi4NCk9uZSBzb2x1dGlvbiBpcyBiZWxvdywgd2hl cmUgdGhlIGdpdmVuIGRpc3RhbmNlIGNhbiBiZSBhZGp1c3RlZC9jb25maWd1cmVkLg0KSWYgd2Ug d2FudCBldmVyeSBub2RlIHRvIGZsb29kIG9uIGFsbCBpdHMgbGlua3MsIHdlIGxldCB0aGUgZ2l2 ZW4NCj4+ZGlzdGFuY2UgdG8gYSBiaWcgbnVtYmVyLiBJZiB3ZSB3YW50IHRoZSBub2RlcyB3aXRo aW4gMiBob3BzIHRvIGEgZmFpbHVyZQ0KPj50byBmbG9vZCBvbiBhbGwgdGhlaXIgbGlua3MsIHdl IHNldCB0aGUgZ2l2ZW4gZGlzdGFuY2UgdG8gMi4NCiAgIOKAnEluIG9uZSB3YXksIHdoZW4gdHdv IG9yIG1vcmUgZmFpbHVyZXMgb24gdGhlIGN1cnJlbnQgZmxvb2RpbmcNCiAgPiA+dG9wb2xvZ3kg b2NjdXIgYWxtb3N0IGluIHRoZSBzYW1lIHRpbWUsIGVhY2ggb2YgdGhlIG5vZGVzIHdpdGhpbiBh DQogID4gPmdpdmVuIGRpc3RhbmNlIChzdWNoIGFzIDMgaG9wcykgdG8gYSBmYWlsdXJlIHBvaW50 LCBmbG9vZHMgdGhlIGxpbmsNCiAgPiA+c3RhdGUgKExTKSB0aGF0IGl0IHJlY2VpdmVzIHRvIGFs bCB0aGUgbGlua3MgKGV4Y2VwdCBmb3IgdGhlIG9uZSBmcm9tDQogICB3aGljaCB0aGUgTFMgaXMg cmVjZWl2ZWQpIHVudGlsIGEgbmV3IGZsb29kaW5nIHRvcG9sb2d5IGlzIGJ1aWx0LuKAnQ0KDQoN Cj5BcyB3ZSBoYXZlIGRpc2N1c3NlZCwgdGhpcyBpcyBub3QgYSBzb2x1dGlvbi4gSW4gZmFjdCwg dGhpcyBpcyBtb3JlIGRhbmdlcm91cyB0aGFuIGFueXRoaW5nIGVsc2UgdGhhdCBoYXMgYmVlbiBw cm9wb3NlZCBhbmQNCj5zZWVtcyBoaWdobHkgbGlrZWx5IHRvIHRyaWdnZXIgYSBjYXNjYWRlIGZh aWx1cmUuIFlvdSBhcmUgZW5hYmxpbmcgZnVsbCBmbG9vZGluZyBmb3IgbWFueSBub2Rlcy4gIElu IGRlbnNlIHRvcG9sb2dpZXMsIGV2ZW4NCj5hIHJhZGl1cyBvZiAzIGlzIHZlcnkgaGlnaC4gIEZv ciBleGFtcGxlLCBpbiBhIExTIHRvcG9sb2d5LCBhIHJhZGl1cyBvZiAzIGlzIHN1ZmZpY2llbnQg dG8gZW5hYmxlIGZ1bGwgZmxvb2RpbmcgdGhyb3VnaG91dCB0aGUNCj5lbnRpcmUgdG9wb2xvZ3ku IElmIHRoYXQgd2VyZSBzdGFibGUsIHdlIHdvdWxkIG5vdCBuZWVkIER5bmFtaWMgRmxvb2Rpbmcg YXQgYWxsLg0KDQpUaGlzIGZ1bGwgZmxvb2RpbmcgaXMgZW5hYmxlZCBvbmx5IGZvciBhIHZlcnkg c2hvcnQgdGltZS4NCkhvdyBkbyB5b3UgZ2V0IHRoYXQgdGhpcyBpcyBtb3JlIGRhbmdlcm91cyB0 aGFuIGFueXRoaW5nIGVsc2UgYW5kIHNlZW1zIGhpZ2hseSBsaWtlbHkgdG8gdHJpZ2dlciBhIGNh c2NhZGUgZmFpbHVyZT8gQ2FuIHlvdSBnaXZlIHNvbWUgZXhwbGFuYXRpb25zIGluIGRldGFpbHM/ DQoNCj4+QW5vdGhlciBzb2x1dGlvbiBpcyBqdXN0IGFkZGluZyBtaW5pbXVtIGxpbmtzIHRlbXBv cmFyaWx5IG9uIHRoZSBmbG9vZGluZw0KPj50b3BvbG9neSB0byByZXBhaXIgdGhlIHNwbGl0IGZs b29kaW5nIHRvcG9sb2d5IHVudGlsIGEgbmV3IGZsb29kaW5nIHRvcG9sb2d5DQo+PmlzIGJ1aWx0 Lg0KDQo+QWdyZWVkLiAgV2hpY2ggbGlua3MgY29uc3RpdHV0ZSB0aGUgbWluaW11bT8gIEluIGEg Z2VuZXJhbCB0b3BvbG9neSwgd2l0aCBhcmJpdHJhcnkgZmFpbHVyZXMgdGhhdCBhcmUgbm90IGRp c3RyaWJ1dGVkIGdsb2JhbGx5LA0KPmhvdyBkbyB3ZSBtYWtlIGEgZGlzdHJpYnV0ZWQgZGVjaXNp b24gYWJvdXQgd2hpY2ggbGlua3MgdG8gZW5hYmxlPyBUaGlzIGlzIHRoZSBwcm9ibGVtIHRoYXQg d2UgYXJlIHRyeWluZyB0byBzb2x2ZS4gQW5kDQo+d2UgaGF2ZSBubyBvcmFjbGUgdG8gdGVsbCB1 cyBUaGUgUmlnaHQgQW5zd2VyLg0KDQpXZSBjYW4gZGlzY3VzcyB0aGlzIGFmdGVyIHRoZSBmaXJz dCBtZXRob2QgaXMgZGlzY3Vzc2VkLg0KDQpCZXN0IFJlZ2FyZHMsDQpIdWFpbW8NCg0KPlJlZ2Fy ZHMsDQo+VG9ueQ0K --_000_5316A0AB3C851246A7CA5758973207D463B76FDDsjceml521mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkRlbmdYaWFuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAx IDE7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUg NSAyIDIgMiA0IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IlxARGVuZ1hpYW4i Ow0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5r DQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3Jh dGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJ e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5Nc29MaXN0UGFyYWdyYXBoLCBk aXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbWFyZ2luLXRv cDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4t bGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCgltc28tYWRkLXNwYWNlOmF1dG87 DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJp Zjt9DQpwLk1zb0xpc3RQYXJhZ3JhcGhDeFNwRmlyc3QsIGxpLk1zb0xpc3RQYXJhZ3JhcGhDeFNw Rmlyc3QsIGRpdi5Nc29MaXN0UGFyYWdyYXBoQ3hTcEZpcnN0DQoJe21zby1zdHlsZS1wcmlvcml0 eTozNDsNCgltc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltYXJnaW4tdG9wOjBpbjsNCglt YXJnaW4tcmlnaHQ6MGluOw0KCW1hcmdpbi1ib3R0b206MGluOw0KCW1hcmdpbi1sZWZ0Oi41aW47 DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCW1zby1hZGQtc3BhY2U6YXV0bzsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnAuTXNv TGlzdFBhcmFncmFwaEN4U3BNaWRkbGUsIGxpLk1zb0xpc3RQYXJhZ3JhcGhDeFNwTWlkZGxlLCBk aXYuTXNvTGlzdFBhcmFncmFwaEN4U3BNaWRkbGUNCgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0K CW1zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1y aWdodDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJn aW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLWFkZC1zcGFjZTphdXRvOw0KCWZvbnQtc2l6ZToxMi4w cHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KcC5Nc29MaXN0UGFy YWdyYXBoQ3hTcExhc3QsIGxpLk1zb0xpc3RQYXJhZ3JhcGhDeFNwTGFzdCwgZGl2Lk1zb0xpc3RQ YXJhZ3JhcGhDeFNwTGFzdA0KCXttc28tc3R5bGUtcHJpb3JpdHk6MzQ7DQoJbXNvLXN0eWxlLXR5 cGU6ZXhwb3J0LW9ubHk7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCglt YXJnaW4tYm90dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCgltc28tYWRkLXNwYWNlOmF1dG87DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1h bDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNw YWNlDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWls U3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJ e21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2Ug V29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAx LjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi8q IExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1saXN0LWlkOjcyMTA1MjI5MjsN Cgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTUyMTA2ODY4 IDY3Njk4NzA1IDY3Njk4NzEzIDY3Njk4NzE1IDY3Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1IDY3 Njk4NzAzIDY3Njk4NzEzIDY3Njk4NzE1O30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwt dGV4dDoiJTFcKSI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDIN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YWxwaGEtbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6cm9t YW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotOS4wcHQ7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJ e21zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmFscGhhLWxvd2VyOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxp c3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OnJvbWFuLWxvd2VyOw0KCW1z by1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7 DQoJdGV4dC1pbmRlbnQ6LTkuMHB0O30NCkBsaXN0IGwwOmxldmVsNw0KCXttc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDph bHBoYS1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0IGwwOmxldmVsOQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOnJpZ2h0Ow0KCXRleHQtaW5kZW50 Oi05LjBwdDt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQp1bA0KCXttYXJnaW4tYm90dG9t OjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZh dWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwh LS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86 aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFb ZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxp bms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMDA3MEMwIj5IaSBUb255LDwvc3Bhbj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzAwNzBDMCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcwQzAiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMDA3MEMwIj4mbmJzcDsmbmJzcDsmbmJzcDsgSW4gc3VtbWFyeSBmb3IgbXVsdGlwbGUg ZmFpbHVyZXMsIHR3byBpc3N1ZXMgYmVsb3cgaW4gZHJhZnQtbGktbHNyLWR5bmFteWljLWZsb29k aW5nIGFyZSBkaXNjdXNzZWQ6DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv TGlzdFBhcmFncmFwaEN4U3BGaXJzdCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlz dDpsMCBsZXZlbDEgbGZvMSI+DQo8IVtpZiAhc3VwcG9ydExpc3RzXT48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzAwNzBDMCI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+MSk8c3BhbiBzdHls ZT0iZm9udDo3LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMDA3MEMwIj5ob3cgdG8gZGV0ZXJtaW5lIHRoZSBjdXJyZW50IGZsb29k aW5nIHRvcG9sb2d5IGlzIHNwbGl0OyBhbmQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTGlzdFBhcmFncmFwaEN4U3BMYXN0IiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4yNWluO21z by1saXN0OmwwIGxldmVsMSBsZm8xIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNdPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMDA3MEMwIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj4yKTxzcGFu IHN0eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtlbmRpZl0+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcwQzAiPmhvdyB0byByZXBhaXIvY29ubmVjdCB0aGUgZmxv b2RpbmcgdG9wb2xvZ3kgc3BsaXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcwQzAiPkZvciB0aGUgZmlyc3QgaXNz dWUsIHRoZSBkaXNjdXNzaW9ucyBhcmUgc3RpbGwgZ29pbmcgb24uPG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7 Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMwMDcwQzAi PkZvciB0aGUgc2Vjb25kIGlzc3VlLCByZXBhaXJpbmcvY29ubmVjdGluZyB0aGUgZmxvb2Rpbmcg dG9wb2xvZ3kgc3BsaXQgdGhyb3VnaCBIZWxsbyBwcm90b2NvbCBleHRlbnNpb25zIGRvZXMgbm90 IHdvcmsuJm5ic3A7IFdoZW4gYSDigJxiYWNrdXAgcGF0aOKAnS9jb25uZWN0aW9uIG9mIG11bHRp cGxlDQogaG9wcyBpcyBuZWVkZWQgdG8gY29ubmVjdC9yZXBhaXIgdGhlIGZsb29kaW5nIHRvcG9s b2d5IHNwbGl0LCBIZWxsbyBjYW4gbm90IGdvIGJleW9uZCBvbmUgaG9wLCB0aHVzIGNhbiBub3Qg cmVwYWlyIHRoZSBmbG9vZGluZyB0b3BvbG9neSBzcGxpdCBpbiB0aGlzIGNhc2UuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OzxiPkZyb206PC9iPiBUb255IExpIFttYWlsdG86dG9u eTFhdGhvbWVAZ21haWwuY29tXQ0KPGI+T24gQmVoYWxmIE9mIDwvYj50b255LmxpQHRvbnkubGk8 YnI+DQomZ3Q7PGI+U2VudDo8L2I+IFdlZG5lc2RheSwgTWFyY2ggNiwgMjAxOSAxMDo0NSBBTTxi cj4NCiZndDs8Yj5Ubzo8L2I+IEh1YWltbyBDaGVuICZsdDtodWFpbW8uY2hlbkBodWF3ZWkuY29t Jmd0Ozxicj4NCiZndDs8Yj5DYzo8L2I+IENocmlzdGlhbiBIb3BwcyAmbHQ7Y2hvcHBzQGNob3Bw cy5vcmcmZ3Q7OyBsc3JAaWV0Zi5vcmc7IGxzci1jaGFpcnNAaWV0Zi5vcmc7IGxzci1hZHNAaWV0 Zi5vcmc8YnI+DQomZ3Q7PGI+U3ViamVjdDo8L2I+IE11bHRpcGxlIGZhaWx1cmVzIGluIER5bmFt aWMgRmxvb2Rpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiZndDs8L3NwYW4+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs8L3NwYW4+SGkgSHVhaW1vLDxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7PC9z cGFuPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDo1LjBwdDttYXJnaW4tcmlnaHQ6LjVpbjttYXJnaW4tYm90dG9tOjBp bjttYXJnaW4tbGVmdDouNWluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+DQo8c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPiZndDsmZ3Q7Jmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw Ozwvc3Bhbj48L3NwYW4+SeKAmW0gc29ycnkgdGhhdCB5b3UgZG9u4oCZdCBmaW5kIGl0IHVzZWZ1 bC4gRGV0ZXJtaW5pbmcgdGhlIHNwbGl0IGlzIHRyaXZpYWw6IHdoZW4geW91IHJlY2VpdmUgYW4g SUlILDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0Oi41aW47bWFyZ2luLWJvdHRvbTowaW47bWFyZ2lu LWxlZnQ6LjVpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7 Jmd0OyZndDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+ PC9zcGFuPml0IGhhcyBhIHN5c3RlbSBJRCBvZiB0aGUgYW5vdGhlciBzeXN0ZW0gaW4gaXQuIElm IHRoYXQgb3RoZXIgc3lzdGVtIGlzIG5vdCBjdXJyZW50bHkgcGFydCBvZiB0aGU8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGlu O21hcmdpbi1yaWdodDouNWluO21hcmdpbi1ib3R0b206MGluO21hcmdpbi1sZWZ0Oi41aW47bWFy Z2luLWJvdHRvbTouMDAwMXB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQt ZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZndDsmZ3Q7PHNwYW4g Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj5mbG9vZGlu ZyB0b3BvbG9neSwgdGhlbiBpdCBpcyBxdWl0ZSBjbGVhciB0aGF0IGl0IGlzIGRpc2Nvbm5lY3Rl ZCBmcm9tIHRoZSBmbG9vZGluZyB0b3BvbG9neS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDouNWlu O21hcmdpbi1ib3R0b206MGluO21hcmdpbi1sZWZ0Oi41aW47bWFyZ2luLWJvdHRvbTouMDAwMXB0 Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZndDsmZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj5SZXBhaXJpbmcgdGhlIHNwbGl0IGlzIGRv bmUgYnkgZW5hYmxpbmcgdGVtcG9yYXJ5IGZsb29kaW5nIG9uIHRoZSBuZXcgbGluay48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 MGluO21hcmdpbi1yaWdodDouNWluO21hcmdpbi1ib3R0b206MGluO21hcmdpbi1sZWZ0Oi41aW47 bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij4NCiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0Oi41 aW47bWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWxlZnQ6LjVpbjttYXJnaW4tYm90dG9tOi4wMDAx cHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0Ozwvc3Bhbj5Gb3IgYW4gYWRqYWNlbmN5IGJl dHdlZW4gdHdvIG5vZGVzIGlzIHVwLCB0aGUgSGVsbG8gcGFja2V0cyBleGNoYW5nZWQgYmV0d2Vl biB0aGVtIHdpbGwgbm90IGNoYW5nZSBub2RlL3N5c3RlbSBJRHMgaW4gdGhlbS48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGlu O21hcmdpbi1yaWdodDouNWluO21hcmdpbi1ib3R0b206NS4wcHQ7bWFyZ2luLWxlZnQ6LjVpbiI+ DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7PC9zcGFuPkhvdyBkbyB5b3UgZGV0ZXJtaW5lIHRo YXQgb3RoZXIgc3lzdGVtIGlzIG5vdCBjdXJyZW50bHkgcGFydCBvZiB0aGUgZmxvb2RpbmcgdG9w b2xvZ3k/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0Ozwvc3Bh bj5UaGUgSUlIIGluY2x1ZGVzIHRoZSBzeXN0ZW0gSUQuICZuYnNwO1NlZSBJU08gMTA1ODkgdjIs IHNlY3Rpb24gOS43LCBmaWVsZCDigJxzb3VyY2UgSWTigJ0uICZuYnNwO1RoZSBsb2NhbCBzeXN0 ZW0gd2lsbCBoYXZlPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWYiPiZndDs8L3NwYW4+YSBjb3B5IG9mIHRoZSBmbG9vZGluZyB0b3BvbG9neSBhbmQg Y2FuIGVhc2lseSBzZWUgaWYgdGhlIG5laWdoYm9yIHdhcyBwcmVzZW50IGFzIG9mIHRoZSBsYXN0 IEZUIGNvbXB1dGF0aW9uLiAmbmJzcDtJZiBub3QsIHRoZW4gaXQgc2hvdWxkIGJlPG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs8L3NwYW4+ YWRkZWQgKG1vZHVsbyByYXRlIGxpbWl0aW5nKS4gVGhlIGxvY2FsIHN5c3RlbSBjYW4gYWxzbyBl eGFtaW5lIGl04oCZcyBvd24gTFNEQi4gJm5ic3A7SWYgdGhlcmUgaXMgbm8gTFNQIGZvciB0aGUg bmVpZ2hib3IsIHRoZW4gaXQgd291bGQgc2VlbTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7PC9zcGFuPmhpZ2hseSBsaWtlbHkgdGhhdCB0 aGVyZSBpcyBhIGRpc2Nvbm5lY3QgYW5kIHRoZSBuZWlnaGJvciBzaG91bGQgYWdhaW4gYmUgYWRk ZWQgKG1vZHVsbyByYXRlIGxpbWl0aW5nKS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4mZ3Q7PC9zcGFuPldlIGFyZSBub3QgcmVxdWlyaW5nIGl0LCBidXQgYSBzeXN0 ZW0gY291bGQgYWxzbyBkbyBhIG1vcmUgZXh0ZW5zaXZlIGNvbXB1dGF0aW9uIGFuZCBjb21wYXJl IHRoZSBsaW5rcyBiZXR3ZWVuIGl0c2VsZiBhbmQgdGhlIG5laWdoYm9yPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs8L3NwYW4+YnkgdHJh Y2luZyB0aGUgcGF0aCBpbiB0aGUgRlQgYW5kIHRoZW4gY29uZmlybWluZyB0aGF0IGVhY2ggbGlu ayBpcyB1cCBpbiB0aGUgTFNEQi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMwMDcwQzAiPkl0IG5vcm1hbGx5IHRha2VzIGEgbG9uZyB0aW1lIHN1Y2ggYXMgbW9y ZSB0aGFuIHRlbiBtaW51dGVzIHRvIGFnZSBvdXQgYW5kIHJlbW92ZSBhbiBMU1AvTFNBIGZvciB0 aGUgbmVpZ2hib3IgZnJvbSB0aGUgTFNEQiBldmVuIHRob3VnaCB0aGUgbmVpZ2hib3IgaXMgZGlz Y29ubmVjdGVkIHBoeXNpY2FsbHkuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwNzBDMCI+SG93IGNhbiB5b3UgZGVjaWRl IHF1aWNrbHkgaW4gdGVucyBvZiBtaWxsaXNlY29uZHMgdGhhdCB0aGUgZmxvb2RpbmcgdG9wb2xv Z3kgaXMgZGlzY29ubmVjdGVkPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1tYXJnaW4tdG9wLWFsdDo1LjBwdDttYXJnaW4tcmlnaHQ6LjVpbjttYXJnaW4tYm90dG9t OjBpbjttYXJnaW4tbGVmdDouNWluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+DQo8c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWYiPiZndDsmZ3Q7Jmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZu YnNwOzwvc3Bhbj48L3NwYW4+VGhlcmUgaXMgYW4gaXNzdWUgaGVyZSB0aGF0IHdlIGhhdmUgbm90 IHlldCByZXNvbHZlZCwgd2hpY2ggaXMgdGhlIHJhdGUgdGhhdCBuZXcgbGlua3Mgc2hvdWxkIGJl PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10 b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6LjVpbjttYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tbGVm dDouNWluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7 Jmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3Nw YW4+dGVtcG9yYXJpbHkgYWRkZWQgdG8gdGhlIGZsb29kaW5nIHRvcG9sb2d5LiAmbmJzcDtTb21l IGJlbGlldmUgdGhhdCBhZGRpbmcgYW55IG5ldyBsaW5rIGlzIHRoZTxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2lu LXJpZ2h0Oi41aW47bWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWxlZnQ6LjVpbjttYXJnaW4tYm90 dG9tOi4wMDAxcHQiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7Jmd0OyZndDs8c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPmNvcnJlY3QgdGhpbmcg dG8gZG8gYXMgaXQgbWluaW1pemVzIHRoZSByZWNvdmVyeSB0aW1lLiBPdGhlcnMgZmVlbCB0aGF0 IGVuYWJsaW5nIHRvbyBtYW55IGxpbmtzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6LjVpbjttYXJn aW4tYm90dG9tOjBpbjttYXJnaW4tbGVmdDouNWluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+DQo8 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7Jmd0OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt c3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+Y291bGQgY2F1c2UgYSBmbG9vZGluZyBjb2xsYXBz ZSwgc28gbGluayBhZGRpdGlvbiBzaG91bGQgYmUgaGlnaGx5IGNvbnN0cmFpbmVkLiBXZSBhcmUg c3RpbGw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDouNWluO21hcmdpbi1ib3R0b206MGluO21hcmdp bi1sZWZ0Oi41aW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0 OyZndDsmZ3Q7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu Pjwvc3Bhbj5kaXNjdXNzaW5nIHRoaXMgYW5kIGludml0ZSB0aGUgV0figJlzIG9waW5pb25zLjxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9w LWFsdDowaW47bWFyZ2luLXJpZ2h0Oi41aW47bWFyZ2luLWJvdHRvbTowaW47bWFyZ2luLWxlZnQ6 LjVpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPg0KJm5ic3A7PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmln aHQ6LjVpbjttYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tbGVmdDouNWluO21hcmdpbi1ib3R0b206 LjAwMDFwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7PC9zcGFuPlRoZSBpc3N1ZSBpcyBy ZXNvbHZlZCBieSB0aGUgc29sdXRpb25zIGluIGRyYWZ0LWNjLWxzci1mbG9vZGluZy1yZWR1Y3Rp b24uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6LjVpbjttYXJnaW4tYm90dG9tOjBpbjttYXJnaW4t bGVmdDouNWluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+DQpPbmUgc29sdXRpb24gaXMgYmVsb3cs IHdoZXJlIHRoZSBnaXZlbiBkaXN0YW5jZSBjYW4gYmUgYWRqdXN0ZWQvY29uZmlndXJlZC48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1h bHQ6MGluO21hcmdpbi1yaWdodDouNWluO21hcmdpbi1ib3R0b206MGluO21hcmdpbi1sZWZ0Oi41 aW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij4NCklmIHdlIHdhbnQgZXZlcnkgbm9kZSB0byBmbG9v ZCBvbiBhbGwgaXRzIGxpbmtzLCB3ZSBsZXQgdGhlIGdpdmVuPG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmln aHQ6LjVpbjttYXJnaW4tYm90dG9tOjBpbjttYXJnaW4tbGVmdDouNWluO21hcmdpbi1ib3R0b206 LjAwMDFwdCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVv dDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDsmZ3Q7PC9zcGFuPmRpc3RhbmNlIHRvIGEg YmlnIG51bWJlci4gSWYgd2Ugd2FudCB0aGUgbm9kZXMgd2l0aGluIDIgaG9wcyB0byBhIGZhaWx1 cmU8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2lu LXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDouNWluO21hcmdpbi1ib3R0b206MGluO21hcmdpbi1s ZWZ0Oi41aW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0OyZn dDs8L3NwYW4+dG8gZmxvb2Qgb24gYWxsIHRoZWlyIGxpbmtzLCB3ZSBzZXQgdGhlIGdpdmVuIGRp c3RhbmNlIHRvIDIuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6LjVpbjttYXJnaW4tYm90dG9tOjBp bjttYXJnaW4tbGVmdDouNWluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+DQombmJzcDsmbmJzcDsg 4oCcSW4gb25lIHdheSwgd2hlbiB0d28gb3IgbW9yZSBmYWlsdXJlcyBvbiB0aGUgY3VycmVudCBm bG9vZGluZzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0Oi41aW47bWFyZ2luLWJvdHRvbTowaW47bWFy Z2luLWxlZnQ6LjVpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPg0KJm5ic3A7Jm5ic3A7PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmIj4mZ3Q7PC9zcGFuPiA8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPg0KJmd0Ozwvc3Bhbj50b3Bv bG9neSBvY2N1ciBhbG1vc3QgaW4gdGhlIHNhbWUgdGltZSwgZWFjaCBvZiB0aGUgbm9kZXMgd2l0 aGluIGE8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDouNWluO21hcmdpbi1ib3R0b206MGluO21hcmdp bi1sZWZ0Oi41aW47bWFyZ2luLWJvdHRvbTouMDAwMXB0Ij4NCiZuYnNwOyZuYnNwOzxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+Jmd0Ozwvc3Bhbj4gPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4NCiZndDs8L3NwYW4+Z2l2ZW4g ZGlzdGFuY2UgKHN1Y2ggYXMgMyBob3BzKSB0byBhIGZhaWx1cmUgcG9pbnQsIGZsb29kcyB0aGUg bGluazxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0Oi41aW47bWFyZ2luLWJvdHRvbTowaW47bWFyZ2lu LWxlZnQ6LjVpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPg0KJm5ic3A7Jm5ic3A7PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmIj4mZ3Q7PC9zcGFuPiA8c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZh bWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPg0KJmd0Ozwvc3Bhbj5zdGF0ZSAo TFMpIHRoYXQgaXQgcmVjZWl2ZXMgdG8gYWxsIHRoZSBsaW5rcyAoZXhjZXB0IGZvciB0aGUgb25l IGZyb208bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy Z2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDouNWluO21hcmdpbi1ib3R0b206NS4wcHQ7bWFy Z2luLWxlZnQ6LjVpbiI+DQombmJzcDsmbmJzcDsgd2hpY2ggdGhlIExTIGlzIHJlY2VpdmVkKSB1 bnRpbCBhIG5ldyBmbG9vZGluZyB0b3BvbG9neSBpcyBidWlsdC7igJ08bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWYiPiZndDs8L3NwYW4+QXMgd2UgaGF2ZSBkaXNjdXNzZWQsIHRoaXMgaXMgbm90 IGEgc29sdXRpb24uIEluIGZhY3QsIHRoaXMgaXMgbW9yZSBkYW5nZXJvdXMgdGhhbiBhbnl0aGlu ZyBlbHNlIHRoYXQgaGFzIGJlZW4gcHJvcG9zZWQgYW5kPG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPiZndDs8L3NwYW4+c2VlbXMgaGlnaGx5IGxp a2VseSB0byB0cmlnZ2VyIGEgY2FzY2FkZSBmYWlsdXJlLiBZb3UgYXJlIGVuYWJsaW5nIGZ1bGwg Zmxvb2RpbmcgZm9yIG1hbnkgbm9kZXMuICZuYnNwO0luIGRlbnNlIHRvcG9sb2dpZXMsIGV2ZW48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Jmd0 Ozwvc3Bhbj5hIHJhZGl1cyBvZiAzIGlzIHZlcnkgaGlnaC4gJm5ic3A7Rm9yIGV4YW1wbGUsIGlu IGEgTFMgdG9wb2xvZ3ksIGEgcmFkaXVzIG9mIDMgaXMgc3VmZmljaWVudCB0byBlbmFibGUgZnVs bCBmbG9vZGluZyB0aHJvdWdob3V0IHRoZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmIj4mZ3Q7PC9zcGFuPmVudGlyZSB0b3BvbG9neS4gSWYgdGhh dCB3ZXJlIHN0YWJsZSwgd2Ugd291bGQgbm90IG5lZWQgRHluYW1pYyBGbG9vZGluZyBhdCBhbGwu PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj5UaGlz IGZ1bGwgZmxvb2RpbmcgaXMgZW5hYmxlZCBvbmx5IGZvciBhIHZlcnkgc2hvcnQgdGltZS4NCjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJj b2xvcjojMDA3MEMwIj5Ib3cgZG8geW91IGdldCB0aGF0IHRoaXMgaXMgbW9yZSBkYW5nZXJvdXMg dGhhbiBhbnl0aGluZyBlbHNlIGFuZCBzZWVtcyBoaWdobHkgbGlrZWx5IHRvIHRyaWdnZXIgYSBj YXNjYWRlIGZhaWx1cmU/IENhbiB5b3UgZ2l2ZSBzb21lIGV4cGxhbmF0aW9ucyBpbiBkZXRhaWxz Pzxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6NS4wcHQ7bWFyZ2luLXJpZ2h0Oi41aW47bWFyZ2lu LWJvdHRvbTowaW47bWFyZ2luLWxlZnQ6LjVpbjttYXJnaW4tYm90dG9tOi4wMDAxcHQiPg0KJmd0 OyZndDtBbm90aGVyIHNvbHV0aW9uIGlzIGp1c3QgYWRkaW5nIG1pbmltdW0gbGlua3MgdGVtcG9y YXJpbHkgb24gdGhlIGZsb29kaW5nPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6LjVpbjttYXJnaW4t Ym90dG9tOjBpbjttYXJnaW4tbGVmdDouNWluO21hcmdpbi1ib3R0b206LjAwMDFwdCI+DQomZ3Q7 Jmd0O3RvcG9sb2d5IHRvIHJlcGFpciB0aGUgc3BsaXQgZmxvb2RpbmcgdG9wb2xvZ3kgdW50aWwg YSBuZXcgZmxvb2RpbmcgdG9wb2xvZ3k8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDouNWluO21hcmdp bi1ib3R0b206NS4wcHQ7bWFyZ2luLWxlZnQ6LjVpbiI+DQomZ3Q7Jmd0O2lzIGJ1aWx0LjxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7QWdyZWVkLiAmbmJzcDtXaGljaCBsaW5rcyBjb25zdGl0 dXRlIHRoZSBtaW5pbXVtPyAmbmJzcDtJbiBhIGdlbmVyYWwgdG9wb2xvZ3ksIHdpdGggYXJiaXRy YXJ5IGZhaWx1cmVzIHRoYXQgYXJlIG5vdCBkaXN0cmlidXRlZCBnbG9iYWxseSw8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDtob3cgZG8gd2UgbWFrZSBhIGRpc3RyaWJ1 dGVkIGRlY2lzaW9uIGFib3V0IHdoaWNoIGxpbmtzIHRvIGVuYWJsZT8gVGhpcyBpcyB0aGUgcHJv YmxlbSB0aGF0IHdlIGFyZSB0cnlpbmcgdG8gc29sdmUuIEFuZDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+Jmd0O3dlIGhhdmUgbm8gb3JhY2xlIHRvIHRlbGwgdXMgVGhlIFJp Z2h0IEFuc3dlci48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMw MDcwQzAiPldlIGNhbiBkaXNjdXNzIHRoaXMgYWZ0ZXIgdGhlIGZpcnN0IG1ldGhvZCBpcyBkaXNj dXNzZWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMwMDcwQzAiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDA3MEMwIj5CZXN0IFJlZ2FyZHMs PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImNvbG9yOiMwMDcwQzAiPkh1YWltbzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0 O1JlZ2FyZHMsPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7VG9ueTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_5316A0AB3C851246A7CA5758973207D463B76FDDsjceml521mbxchi_-- From nobody Mon Mar 11 10:21:39 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D673131135; Mon, 11 Mar 2019 10:21:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 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 VujJWYeoP3jO; Mon, 11 Mar 2019 10:21:31 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA3421311B5; Mon, 11 Mar 2019 10:21:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6203; q=dns/txt; s=iport; t=1552324890; x=1553534490; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=vfMbx/2Rt0VUD4X+mZa67iEPMylEwgeAOYWHmyfibcQ=; b=NAPEdyGOVAElT5jTG56bQpH6zAxSzzsLRGOjiMvjshQ24mQsHOUXSY/B 4/mLSQLagfbVEn//Z8CS7Xp2MFQ1KEkKFM3/SL//JBdaUr3GSWRfJ6lV1 Ax9Hd0FA+cWh7OItk9Ub2bIWrq6wWKxBjEf51H1s1huKJUU3QKuYthy4a Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAACPmIZc/xbLJq1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUwIBAQEBAQsBgWAFgRJxEieNAow0LYkxjnWBew0YC4R?= =?us-ascii?q?JAoRcNgcNAQEDAQEHAQMCbRwMhUoBAQEBAgEBATABBTYLEAsRBAEBAScHIQY?= =?us-ascii?q?fCQgGAQwGAgEBF4MHAYFdAw0ID7FMhUWCQA2CGgWBLwGEW4ZogUA/gREngj0?= =?us-ascii?q?ugldHAQGBHYYlA4oIjUGLeyozCY9OgzgGGYsCiDiKeIcWi1mBTQExgVYzGgg?= =?us-ascii?q?bFTuCbIMtAQmHVYVAPgMwjXMHI4IjAQE?= X-IronPort-AV: E=Sophos;i="5.58,468,1544486400"; d="scan'208";a="10619850" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Mar 2019 17:21:27 +0000 Received: from [10.60.140.54] (ams-ppsenak-nitro5.cisco.com [10.60.140.54]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id x2BHLPYp017417; Mon, 11 Mar 2019 17:21:26 GMT To: Huaimo Chen , "tony.li@tony.li" References: <5316A0AB3C851246A7CA5758973207D463B5858A@sjceml521-mbx.china.huawei.com> <420ed1b5-d849-99cc-bcb0-d159783e4de2@cisco.com> <5316A0AB3C851246A7CA5758973207D463B59041@sjceml521-mbx.china.huawei.com> <0B4DF2AC-8EE1-41CA-B357-98325067CA30@gmail.com> <5316A0AB3C851246A7CA5758973207D463B66FE9@sjceml521-mbx.china.huawei.com> <78A866F4-9AF0-481A-9DEC-B04DE72AFDA3@tony.li> <5316A0AB3C851246A7CA5758973207D463B76FDD@sjceml521-mbx.china.huawei.com> Cc: "lsr@ietf.org" , "lsr-ads@ietf.org" , "lsr-chairs@ietf.org" From: Peter Psenak Message-ID: Date: Mon, 11 Mar 2019 18:21:25 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <5316A0AB3C851246A7CA5758973207D463B76FDD@sjceml521-mbx.china.huawei.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Outbound-SMTP-Client: 10.60.140.54, ams-ppsenak-nitro5.cisco.com X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Lsr] Multiple failures in Dynamic Flooding X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 17:21:38 -0000 Hi Huaimo, On 11/03/2019 18:08 , Huaimo Chen wrote: > Hi Tony, > > > > In summary for multiple failures, two issues below in > draft-li-lsr-dynamyic-flooding are discussed: > > 1) how to determine the current flooding topology is split; and there is no need to do that. The recovery mechanism will repair the split topology if there is a way to do that. > > 2) how to repair/connect the flooding topology split. 6.7.11. Recovery from Multiple Failures "The nodes that remain active on the edges of the flooding topology partitions will recognize this and will try to repair the flooding topology locally by enabling temporary flooding towards the nodes that they consider disconnected from the flooding topology until a new flooding topology becomes connected again." > > For the first issue, the discussions are still going on. > > For the second issue, repairing/connecting the flooding topology split > through Hello protocol extensions does not work. When a “backup > path”/connection of multiple hops is needed to connect/repair the > flooding topology split, Hello can not go beyond one hop, thus can not > repair the flooding topology split in this case. there is no need to send anything multi-hop. thanks, Peter > > > >>*From:* Tony Li [mailto:tony1athome@gmail.com] *On Behalf Of > *tony.li@tony.li >>*Sent:* Wednesday, March 6, 2019 10:45 AM >>*To:* Huaimo Chen >>*Cc:* Christian Hopps ; lsr@ietf.org; > lsr-chairs@ietf.org; lsr-ads@ietf.org >>*Subject:* Multiple failures in Dynamic Flooding > >> > >>Hi Huaimo, > >> > >>>> I’m sorry that you don’t find it useful. Determining the split is > trivial: when you receive an IIH, > >>>> it has a system ID of the another system in it. If that other system is > not currently part of the > >>>> flooding topology, then it is quite clear that it is disconnected from > the flooding topology. > >>>> Repairing the split is done by enabling temporary flooding on the new link. > > > >>>For an adjacency between two nodes is up, the Hello packets exchanged > between them will not change node/system IDs in them. > >>>How do you determine that other system is not currently part of the > flooding topology? > > > >>The IIH includes the system ID. See ISO 10589 v2, section 9.7, field > “source Id”. The local system will have > >>a copy of the flooding topology and can easily see if the neighbor was > present as of the last FT computation. If not, then it should be > >>added (modulo rate limiting). The local system can also examine it’s own > LSDB. If there is no LSP for the neighbor, then it would seem > >>highly likely that there is a disconnect and the neighbor should again > be added (modulo rate limiting). > > > >>We are not requiring it, but a system could also do a more extensive > computation and compare the links between itself and the neighbor > >>by tracing the path in the FT and then confirming that each link is up > in the LSDB. > > > > It normally takes a long time such as more than ten minutes to age out > and remove an LSP/LSA for the neighbor from the LSDB even though the > neighbor is disconnected physically. > > How can you decide quickly in tens of milliseconds that the flooding > topology is disconnected? > > > >>>> There is an issue here that we have not yet resolved, which is the rate > that new links should be > >>>> temporarily added to the flooding topology. Some believe that adding > any new link is the > >>>> correct thing to do as it minimizes the recovery time. Others feel that > enabling too many links > >>>> could cause a flooding collapse, so link addition should be highly > constrained. We are still > >>>> discussing this and invite the WG’s opinions. > > > >>>The issue is resolved by the solutions in draft-cc-lsr-flooding-reduction. > > One solution is below, where the given distance can be adjusted/configured. > > If we want every node to flood on all its links, we let the given > >>>distance to a big number. If we want the nodes within 2 hops to a failure > >>>to flood on all their links, we set the given distance to 2. > > “In one way, when two or more failures on the current flooding > > > >topology occur almost in the same time, each of the nodes within a > > > >given distance (such as 3 hops) to a failure point, floods the link > > > >state (LS) that it receives to all the links (except for the one from > > which the LS is received) until a new flooding topology is built.” > > > > > >>As we have discussed, this is not a solution. In fact, this is more > dangerous than anything else that has been proposed and > >>seems highly likely to trigger a cascade failure. You are enabling full > flooding for many nodes. In dense topologies, even > >>a radius of 3 is very high. For example, in a LS topology, a radius of > 3 is sufficient to enable full flooding throughout the > >>entire topology. If that were stable, we would not need Dynamic Flooding > at all. > > > > This full flooding is enabled only for a very short time. > > How do you get that this is more dangerous than anything else and seems > highly likely to trigger a cascade failure? Can you give some > explanations in details? > >>>Another solution is just adding minimum links temporarily on the flooding > >>>topology to repair the split flooding topology until a new flooding > topology > >>>is built. > > > >>Agreed. Which links constitute the minimum? In a general topology, > with arbitrary failures that are not distributed globally, > >>how do we make a distributed decision about which links to enable? This > is the problem that we are trying to solve. And > >>we have no oracle to tell us The Right Answer. > > > > We can discuss this after the first method is discussed. > > > > Best Regards, > > Huaimo > > > >>Regards, > >>Tony > > > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > From nobody Mon Mar 11 10:41:14 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 993DA131142; Mon, 11 Mar 2019 10:41:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.649 X-Spam-Level: X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 dXJ8Lzc21rhs; Mon, 11 Mar 2019 10:41:10 -0700 (PDT) Received: from mail-pf1-x443.google.com (mail-pf1-x443.google.com [IPv6:2607:f8b0:4864:20::443]) (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 7C01713104A; Mon, 11 Mar 2019 10:41:10 -0700 (PDT) Received: by mail-pf1-x443.google.com with SMTP id n125so4213476pfn.5; Mon, 11 Mar 2019 10:41:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=KVMFxKmrwfz/qh2dQTUccEKKwSSIe4JsPQ9cpSa380o=; b=VTLnDCskg8TUbA9phsrS4kjHbblxxUXqZlDrEq2/EPOEFLE+6wjDYIvXWwqQSMf3b2 5qObkOcZy0EZEfwum/b0SKteKf+/6HFCwOT2ZidpVavK6sVmp/6fdMJgW6axKFN6v9jo /s4Hq2pF6K2t/w6fhG1TZNEfYLnSvi4ucOg8NFjym1BXlCbS3B77tQJtN0SiyBgt4v/2 SKAVU/5Op1l7RVxZwhv8N1fEJivooeyMolNeMxbKbiYJBmGcPEkmi7KfJ59RCyeL5iEI 1P2nQvn/XhWsHDqihjLLrfYAK6B4LoAN673KE4tyIO3V0MfWsALBtx5w5yEGYlYBhDkG 3IZg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=KVMFxKmrwfz/qh2dQTUccEKKwSSIe4JsPQ9cpSa380o=; b=DYjhKddZG7PEq/F+6DezTIP7BkxxpjKmZ+D5NI5b7krOlC0wBIsfoBP0h82FFnrKQU +5Jdwv2C3tYQWKsW7RWc8czG/WHVrMng4vYT1wdp/HwKyxsuj3cineyHWGC12eBBNciT fAP0uOg2QWc2QFo73zse5Nd2E3BuVcZepsk213/TyoA1JWBQfDKDLOz6AqVe0RlOG+OF +QHLuXC4gpGTT1wCb8qZl+E8q6LhmHI4685HckdOBqH7Lnsth4Wx8S/P37fGT/rnr64t tNkByW2sO3TJnAt1IA5sOGz9MD9FcOPmLNlCo3OrDkIalauF6XIyvshjO7s+CSRTX0IM 6epQ== X-Gm-Message-State: APjAAAWI3sW2nR/1jlGdAIQi6r8cdZi+IS75BWi0wxokVpV4OPA0//0Y 9xSMME1JE69n9jyklVT9pIk= X-Google-Smtp-Source: APXvYqwxvXw0OWRVY2mJlKwtlvLr2Ndchz/42eIgl8OKajGRnBe6Y0hv2PnapPjNWDeagiNoxmgHqw== X-Received: by 2002:a62:5c87:: with SMTP id q129mr33596019pfb.180.1552326070018; Mon, 11 Mar 2019 10:41:10 -0700 (PDT) Received: from [172.22.228.48] ([162.210.130.3]) by smtp.gmail.com with ESMTPSA id e9sm22227180pfh.42.2019.03.11.10.41.09 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Mar 2019 10:41:09 -0700 (PDT) Sender: Tony Li From: tony.li@tony.li Message-Id: <10A1CA48-0D09-44FF-95ED-8D52FB867B8B@tony.li> Content-Type: multipart/alternative; boundary="Apple-Mail=_AB2D3636-C782-4119-92FA-EA69EA66D72B" Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Mon, 11 Mar 2019 10:41:08 -0700 In-Reply-To: <5316A0AB3C851246A7CA5758973207D463B76FDD@sjceml521-mbx.china.huawei.com> Cc: "lsr@ietf.org" , "lsr-chairs@ietf.org" , "lsr-ads@ietf.org" To: Huaimo Chen References: <5316A0AB3C851246A7CA5758973207D463B5858A@sjceml521-mbx.china.huawei.com> <420ed1b5-d849-99cc-bcb0-d159783e4de2@cisco.com> <5316A0AB3C851246A7CA5758973207D463B59041@sjceml521-mbx.china.huawei.com> <0B4DF2AC-8EE1-41CA-B357-98325067CA30@gmail.com> <5316A0AB3C851246A7CA5758973207D463B66FE9@sjceml521-mbx.china.huawei.com> <78A866F4-9AF0-481A-9DEC-B04DE72AFDA3@tony.li> <5316A0AB3C851246A7CA5758973207D463B76FDD@sjceml521-mbx.china.huawei.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Lsr] Multiple failures in Dynamic Flooding X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 17:41:13 -0000 --Apple-Mail=_AB2D3636-C782-4119-92FA-EA69EA66D72B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi Huaimo, > In summary for multiple failures, two issues below in = draft-li-lsr-dynamyic-flooding are discussed: > 1) how to determine the current flooding topology is split; and > 2) how to repair/connect the flooding topology split. > For the first issue, the discussions are still going on. > For the second issue, repairing/connecting the flooding topology split = through Hello protocol extensions does not work. When a =E2=80=9Cbackup = path=E2=80=9D/connection of multiple hops is needed to connect/repair = the flooding topology split, Hello can not go beyond one hop, thus can = not repair the flooding topology split in this case. You do not try to repair things remotely, they are always repaired = locally. If there are multiple failures in the flooding topology and it = is partitioned, then it follows that there are multiple remaining = connected components of the flooding topology. Nodes that are adjacent = to the failures will update their LSPs and flood them throughout their = connected component. Each component will see at least two link failures = if there is a partition of the FT and each node in the component can = detect that the FT has partitioned. Each node is then capable of = enabling temporary flooding on one or more links that will traverse the = partition, thereby restoring a functioning FT. The Area Leader then = recomputes and redistributes the revised FT. To put it yet another way, repair is fully distributed. You should like = that. :-) > >We are not requiring it, but a system could also do a more extensive = computation and compare the links between itself and the neighbor > >by tracing the path in the FT and then confirming that each link is = up in the LSDB. > =20 > It normally takes a long time such as more than ten minutes to age out = and remove an LSP/LSA for the neighbor from the LSDB even though the = neighbor is disconnected physically. > How can you decide quickly in tens of milliseconds that the flooding = topology is disconnected? You do not wait for LSP/LSA removal. You look for link changes in the = LSPs that you do get, or local link changes. > >As we have discussed, this is not a solution. In fact, this is more = dangerous than anything else that has been proposed and > >seems highly likely to trigger a cascade failure. You are enabling = full flooding for many nodes. In dense topologies, even > >a radius of 3 is very high. For example, in a LS topology, a radius = of 3 is sufficient to enable full flooding throughout the > >entire topology. If that were stable, we would not need Dynamic = Flooding at all. > =20 > This full flooding is enabled only for a very short time. All it takes is enabling it at sufficient density to create a cascade = failure. Milliseconds are sufficient for a collapse. > How do you get that this is more dangerous than anything else and = seems highly likely to trigger a cascade failure? Can you give some = explanations in details? Again, we do not have absolute metrics on what triggers a cascade = failure today. We have several data points of several different = implementations at different points in time. We know that in the early = =E2=80=9890s, a full mesh of 20 neighbors running L1L2 was sufficient. = Obviously things have changed somewhat, but even more modern = implementations have had problems. This is why the MSDC went to BGP. As a result, we need to be very conservative about what flooding we = temporarily enable. We do not want to walk anywhere near the cliff, as = the cascade failure is fatal to the network. Tony --Apple-Mail=_AB2D3636-C782-4119-92FA-EA69EA66D72B Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

Hi Huaimo,



    In summary for multiple = failures, two issues below in draft-li-lsr-dynamyic-flooding are = discussed:
1)      how to determine the current flooding = topology is split; and
2)      how to repair/connect the flooding = topology split.
For= the first issue, the discussions are still going on.
For the second issue, = repairing/connecting the flooding topology split through Hello protocol = extensions does not work.  When a =E2=80=9Cbackup = path=E2=80=9D/connection of multiple hops is needed to connect/repair = the flooding topology split, Hello can not go beyond one hop, thus can = not repair the flooding topology split in this = case.


You do not try to repair = things remotely, they are always repaired locally.  If there are = multiple failures in the flooding topology and it is partitioned, then = it follows that there are multiple remaining connected components of the = flooding topology.  Nodes that are adjacent to the failures will = update their LSPs and flood them throughout their connected component. =  Each component will see at least two link failures if there is a = partition of the FT and each node in the component can detect that the = FT has partitioned.  Each node is then capable of enabling = temporary flooding on one or more links that will traverse the = partition, thereby restoring a functioning FT.  The Area Leader = then recomputes and redistributes the revised FT.

To put it yet another way, repair is fully = distributed.  You should like that.  :-)


>We = are not requiring it, but a system could also do a more extensive = computation and compare the links between itself and the = neighbor
>by tracing the path in the FT and = then confirming that each link is up in the LSDB.
 
It = normally takes a long time such as more than ten minutes to age out and = remove an LSP/LSA for the neighbor from the LSDB even though the = neighbor is disconnected physically.
How can = you decide quickly in tens of milliseconds that the flooding topology is = disconnected?


You do not wait for = LSP/LSA removal.  You look for link changes in the LSPs that you do = get, or local link changes.


>As we have discussed, this is not a solution. In fact, this = is more dangerous than anything else that has been proposed = and
>seems highly likely to trigger a = cascade failure. You are enabling full flooding for many nodes.  In = dense topologies, even
>a radius of 3 = is very high.  For example, in a LS topology, a radius of 3 is = sufficient to enable full flooding throughout the
>entire topology. If that were stable, = we would not need Dynamic Flooding at all.
 
This full = flooding is enabled only for a very short = time.


All it takes is enabling it at sufficient density = to create a cascade failure.  Milliseconds are sufficient for a = collapse.


How do = you get that this is more dangerous than anything else and seems highly = likely to trigger a cascade failure? Can you give some explanations in = details?


Again, we do not have = absolute metrics on what triggers a cascade failure today.  We have = several data points of several different implementations at different = points in time.  We know that in the early =E2=80=9890s, a full = mesh of 20 neighbors running L1L2 was sufficient.  Obviously things = have changed somewhat, but even more modern implementations have had = problems.  This is why the MSDC went to BGP.

As a result, we need to be very conservative about = what flooding we temporarily enable.  We do not want to walk = anywhere near the cliff, as the cascade failure is fatal to the = network.

Tony


= --Apple-Mail=_AB2D3636-C782-4119-92FA-EA69EA66D72B-- From nobody Mon Mar 11 14:28:18 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2672F1200D7 for ; Mon, 11 Mar 2019 14:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=raszuk.net 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 pd-1Q7bMtIIV for ; Mon, 11 Mar 2019 14:28:15 -0700 (PDT) Received: from mail-qt1-x82e.google.com (mail-qt1-x82e.google.com [IPv6:2607:f8b0:4864:20::82e]) (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 3A28B1224E8 for ; Mon, 11 Mar 2019 14:28:15 -0700 (PDT) Received: by mail-qt1-x82e.google.com with SMTP id v10so267967qtp.8 for ; Mon, 11 Mar 2019 14:28:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:from:date:message-id:subject:to; bh=2XiXg1VaDeKsJv6nHIX1Rd4a6koJzfMDFM+Drg+eAAA=; b=RRZtmse9FIXmf8jhHrPVbB9qxI+biez1GpAfZnkH80FOTqixqdTuyOHCnC0e1i9eTY S+ZHtZz3BgZ4rtle5ALWByu3/O+6EQXLMfFPdjqMd8E6M1BEhgSSwPg644BOCv8GRX4b KN9HE86cA0my0mw1OCh3bT+U4Wp3k7Bsjiauc9nHWF9L0AC/v1fBV+9lF0A57oJPc3bX AJLY8ATPoRPnGwt8WuAuypjs/g8+r/1ufLvRjCOgCZh57zigj+gzCehpmVm+mDLxz7LF fLDIQcXvDB80ysRPW3burWBjXLF1NJ4n7zdrXgt+qFmlzG9xEM7ZLKp9zozuzOvBBu4W dN2g== 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; bh=2XiXg1VaDeKsJv6nHIX1Rd4a6koJzfMDFM+Drg+eAAA=; b=FtaDu0Qoycu0zIgbbm6fUTnRk6t859TAhndoTiqLGF9fSlZcTAC+86a9fzuTlJ8ZMK fbg9bf6IDw6L18g8H3IAfRrrauRrp1Q4/6+9EHeDlfI25qV4+mzazp9OxbtYjLtgynSk Clq879u9uFs+3MLUgvucy63KnjAmyWbRd9mYyfif0YCji9WYN0Y/lb5R+Cuv2/ESZcPn MxkQgoG8mYkEuf4USaDo5lFdQdwg9teRZqzR3yG3qXZpXNxlRqHuxKUSgFKEvV1DLPog 4ZtZsBI2PNmUpI1h8j+IwcjeLx0mwo3dMwtjCxiJvyJOSrMMgPVnxL8Y5vt6iC3BlSY0 BPVw== X-Gm-Message-State: APjAAAVcfvOniNZ+JxFzZmAb1GuZSe5e3RMhvr/LKWfdGsJeaIbx7rjD 253GEseKx+OWas6lAhyV5nArJENLiVPQ+U/gCUMBy/xMMD0= X-Google-Smtp-Source: APXvYqxIJHKYne1wV44rhNTM2peCn3/gsLxqUmqNDcT2/gqSJ/qbzakBy+kJG8iExKJ15ePo8lpdWNdSdJo2LaQxKTg= X-Received: by 2002:ac8:6894:: with SMTP id m20mr26775960qtq.277.1552339693953; Mon, 11 Mar 2019 14:28:13 -0700 (PDT) MIME-Version: 1.0 From: Robert Raszuk Date: Mon, 11 Mar 2019 22:28:04 +0100 Message-ID: To: lsr@ietf.org Content-Type: multipart/alternative; boundary="0000000000000779150583d84095" Archived-At: Subject: [Lsr] Temporary addition of links to flooding topology in dynamic flooding X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Mar 2019 21:28:17 -0000 --0000000000000779150583d84095 Content-Type: text/plain; charset="UTF-8" Hi, As of now at the event of failure of any of the FT enabled link additional links are being added in more or less random fashion by nodes directly connected to the failed links. In the event of 100s of links on such nodes and advisable rate limiting addition of those links it seems that repair of FT may take some time. In order to reduce such time interval better then random addition of remaining links seems recommended. How about we hint participating nodes to execute purely in control plane of FT an LFA algorithm for possible future event of active link failure and use results of the LFA computation to prioritize links which will be first temporary additions upon active flooding links failures ? Such optimization is local and optional and does not require any changes to proposed protocol signalling. *Therefor how about just one sentence addition to section 6.7.1 of draft-ietf-lsr-dynamic-flooding:* *Temporary additions of links to flooding topology could be more educated if given node runs a pure control plane LFA ahead of any FT failure on active FT links completely detached from potential LFA runs for data plane topology. * Kind regards, R. --0000000000000779150583d84095 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

As of now at the e= vent of failure of any of the FT enabled link additional links are being ad= ded in more or less random fashion by nodes directly connected to the faile= d links.=C2=A0

In the event of 100s of links on su= ch nodes and advisable rate limiting addition of those links it seems that = repair of FT may take some time.=C2=A0

In order to= reduce such time interval better then random addition of remaining links s= eems recommended. How about we hint participating nodes to execute purely i= n control plane of FT an LFA algorithm for possible future event of active = link failure and use results of the LFA computation to prioritize links whi= ch will be first temporary additions upon active flooding links failures ?= =C2=A0

Such optimization is local and op= tional and does not require any changes to proposed protocol signalling.=C2= =A0

Therefor how about just on= e sentence addition to section 6.7.1 of=C2=A0draft-ietf-lsr-dynamic-floodin= g:

Temporary additions of links to flooding= topology could be more educated if given node runs a pure control plane LF= A ahead of any FT failure on active FT links completely detached from poten= tial LFA runs for data plane topology.=C2=A0

=
Kind regards,
R.

--0000000000000779150583d84095-- From nobody Mon Mar 11 21:28:19 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D0FC7130E83 for ; Mon, 11 Mar 2019 21:28:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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=NIIavYzL; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=DQ47oisj 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 voiWRrzsbsxm for ; Mon, 11 Mar 2019 21:28:14 -0700 (PDT) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C028A130E6F for ; Mon, 11 Mar 2019 21:28:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19328; q=dns/txt; s=iport; t=1552364893; x=1553574493; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=5dFF6QLEEkR9cCHMWzUonFtCSBMXzBn1H9LJIUSSXGg=; b=NIIavYzLJFN/wTX1+B1OPNs6dM+6kp6syd8g7fpXM4gVk7ES/ZFcBPLX /Ta5w4xU9nM1eN1PoTWwRtfvJj4s/gAb2YUksB1adPaZoadhVGNaZizp9 ilsYyyApQMKMDT6DCUM7A/7lq7HU+L26RIrxXeZ2NrT+7gjO6aU7myCRk U=; IronPort-PHdr: =?us-ascii?q?9a23=3APUq48hSvav7vVrOj5OMAk2/va9psv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESXBNfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5g640NmhA4RsuMCEn1NvnvOiM7Gt9IWUVq13q6KkNSXs35Yg6arw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BZAADRNIdc/5NdJa1kHAEBAQQBAQc?= =?us-ascii?q?EAQGBUwUBAQsBgQ0vJAUnA2h0BAsnhAqDRwOPPUqCDZI1hXWBJANUCwEBLIR?= =?us-ascii?q?AAheEIyI2Bw0BAQMBAQkBAwJtHAyFSgEBAQQjChMBATgPAgEIEQQBAR4NAgI?= =?us-ascii?q?CMB0IAgQBEgiCT0yBEUwDFQECpTcCihRxgS+CeAEBBYUaGIIMCIEvAYssF4F?= =?us-ascii?q?AP4FXgh4uhQODCDGCJooXgjqECIIBkVIJAotOh1qTO4p5kk4CBAIEBQIOAQE?= =?us-ascii?q?FgU4KJyiBLnAVO4JsggqBIwEEgkaKU3KBKIxOKoIjAQE?= X-IronPort-AV: E=Sophos;i="5.58,469,1544486400"; d="scan'208,217";a="242965412" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Mar 2019 04:28:12 +0000 Received: from XCH-ALN-020.cisco.com (xch-aln-020.cisco.com [173.36.7.30]) by rcdn-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id x2C4SChV013193 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 12 Mar 2019 04:28:12 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-020.cisco.com (173.36.7.30) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 11 Mar 2019 23:28:11 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 11 Mar 2019 23:28:11 -0500 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 12 Mar 2019 00:28:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=5dFF6QLEEkR9cCHMWzUonFtCSBMXzBn1H9LJIUSSXGg=; b=DQ47oisjeoB4ZKfpR+hrsK0IMlXoVT79mx25pia3oVapcfCUV58jxODshYaVyZjg607hXrtxy58lvTPeQ9ukP3YA/SbC19fj9a4/22LdnFHb9ARtZFHsNjgrkLAasF+vszoJ4Nj8GTUL1nxn8C5iBLmPD8VuQpcSD3b9N61RsJw= Received: from BYAPR11MB3638.namprd11.prod.outlook.com (20.178.237.19) by BYAPR11MB3669.namprd11.prod.outlook.com (20.178.237.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1686.18; Tue, 12 Mar 2019 04:28:09 +0000 Received: from BYAPR11MB3638.namprd11.prod.outlook.com ([fe80::b414:f534:f20a:a26d]) by BYAPR11MB3638.namprd11.prod.outlook.com ([fe80::b414:f534:f20a:a26d%3]) with mapi id 15.20.1686.021; Tue, 12 Mar 2019 04:28:09 +0000 From: "Les Ginsberg (ginsberg)" To: Robert Raszuk , "lsr@ietf.org" Thread-Topic: [Lsr] Temporary addition of links to flooding topology in dynamic flooding Thread-Index: AQHU2FFk2gptIB0Z+EmsBAKlm+uXmKYHXhhw Date: Tue, 12 Mar 2019 04:28:09 +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: spf=none (sender IP is ) smtp.mailfrom=ginsberg@cisco.com; x-originating-ip: [2001:420:c0c8:1002::181] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c30c4430-1ddb-4c5a-85d1-08d6a6a321f5 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BYAPR11MB3669; x-ms-traffictypediagnostic: BYAPR11MB3669: x-microsoft-exchange-diagnostics: =?utf-8?B?MTtCWUFQUjExTUIzNjY5OzIzOmZZN3Nud1FHNlpJUWlTR3Q0Z3dkc1lNVm52?= =?utf-8?B?Ri9jaldmY1RtZkpHdTJYT3cyU1B1WnZscXdYaFJndzlmTzBtTWpxK2RqL2kw?= =?utf-8?B?ZXhBall2YWNlNDhvZktrcm5Kb2NiM29SbDFyUExnQmFDTHlmWGJHMnYxeFJV?= =?utf-8?B?OUlJaSsvWFB3a01tRVd6S2svNm11QTBWa2Y3VnhIT21sZ3IyRVN1NjQybDZP?= =?utf-8?B?OGVPTUJkTi9wT0lWRTFoeXdhSXpOTHJoQmthaTBmSlRSLzhKWjNRMTluN0th?= =?utf-8?B?RGtGRlZlMXhEZEN3ZVU4MFVEREt0T0hnejFrSVZDaUZWblJRTHo4UkZRWUFw?= =?utf-8?B?OHBCdGkwS0hOZ2tIN0orUGJJNlVuejk5aW9ZaWVJTVRCT3VLWmMvMVFzVVI2?= =?utf-8?B?L2lmT3NWU1VQWmZqY0tHODVzQWhHWXJ6VS83Sm5nY2hjUmZNUFF5ZG5rZjlm?= =?utf-8?B?VWR1TFlBMU5PaTl2UVJ6TTJJSXBWRnU3MXVXTGdFRytxbXVmb0x0Q1VZOTZ6?= =?utf-8?B?endNTWthNng5SE9Ickl5YlJuM3JMNEw1dmNEYjlPTzVvRlN0NTVlMHVZZEcz?= =?utf-8?B?dUtlN3hhUjUzYjVnMHR4bGNaR01vM1Z0YktLWVZrbVFGc2FjNDBCNWtiMG9D?= =?utf-8?B?b3YwUFRtdUVkdHljbHg2TXVJazEvTmFLUHFsMkFXRUR6Y3FtdFFDOERPWjhx?= =?utf-8?B?TVdTdmY0aHMwZ2ZRaFo4S0kwcDNyQ3o0UDU0WE1vRms4eVdNWlVnWUhDREc2?= =?utf-8?B?czlOcUU3VlYrWkRiakdBUTRmcFpaTlYvZjlCR2RHaitwUktzNnM3bkxsc0xH?= =?utf-8?B?bzBmaFB1Wm0vU1plT1FhRmVOczBCOGdVQTM2emp0cVU0K3JJak9BZXdwZGlS?= =?utf-8?B?anpoMEFXZ3E0M2w0RmhDVXZXb1hEMnlwS0VQTWFKdXlmUGxETU1zbTdqTDhy?= =?utf-8?B?S1RJWnJuZzYwQmFlNDRDU0lrdHgrUWtmRmRwMlplaWt2VEdhSXNIOVR0VUNh?= =?utf-8?B?YUMxU1hGS2FYLzNXVlI5YUlWR0J1ZWV3aDV4M3hEaVBMRVA0MlpSa2xsbWdt?= =?utf-8?B?N3hydUQ1VUF1SHpDd1ZBcU8rVEo2NEt5aTNUQVdpUndmMkw5WXY1U1UwVXNk?= =?utf-8?B?QjYraTNjeVB0TmFRZ0xBbGh3djAxVkZmdUZvUE5USmtOeDlsSDgwRlNaQ2Mv?= =?utf-8?B?RVpiTWI4R2YrcnlEUHFCcjlHblJmaXg4cml1ZGVDSW5mOW1QZmxLNTRlR21M?= =?utf-8?B?cFQrbnphTnFUSjdiUDkrU25WcDFFT3NCRFZ2QmdtN0R4Tnd0YUZVM3VURzlr?= =?utf-8?B?VUg5RzVRUVc3dCs2dFVKL1NOQ3pTMnpXZ3Vha1RQL2ZnSnorUkNXL1M1eVpQ?= =?utf-8?B?aTZlSkxaQ1hpTmdzb0VRSmdOWklrZXRSNGVtaFl1elZOZER2OVNuRkhRb0tC?= =?utf-8?B?VktSTnplRFduY3FoaEFaOTIyN2puWlZuYXJNc3BZUm9nMjJmdG5zbGFPZDYw?= =?utf-8?B?ZVlGSFJOUjBmNDlLbTZKRlN3enU5OVV3ZWxVVUEvSHdCTUJZdU9KZ2Y1SE5Q?= =?utf-8?B?eEkxbkNvU1VpeDZZemQ1WE5yaklSUnpWZS94bjM5Wjl5dEZkNy9nNC9XWkVG?= =?utf-8?B?L2E0NVVwd1NLd0hNRXNlUmg4K0txeXo1K0diWll5eHJlcWVXTHE1U2RRPT0=?= x-microsoft-antispam-prvs: x-forefront-prvs: 09749A275C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(376002)(366004)(396003)(346002)(39860400002)(199004)(189003)(7696005)(46003)(2906002)(486006)(71200400001)(99286004)(6506007)(97736004)(76176011)(186003)(8676002)(74316002)(790700001)(256004)(86362001)(106356001)(81166006)(6116002)(11346002)(14444005)(8936002)(71190400001)(81156014)(7736002)(229853002)(446003)(52536013)(5660300002)(6306002)(6246003)(6436002)(33656002)(54896002)(53936002)(9686003)(68736007)(2501003)(476003)(478600001)(105586002)(102836004)(25786009)(53546011)(110136005)(316002)(55016002)(14454004); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3669; H:BYAPR11MB3638.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: xi/UvrqENSbbxiCEw/QLDyf6MSxtDTWLG//zrHMUW4kxQt3vpD0lScFqv+9KFw/BSYoo+lCrZOKashc7T5pOBW3T+kldmEyHi2jhPFf+MHVgCwIHRraBAWoTSJCeyx2Gi9hgltDxL/I8NHGxkn0+vjURWbpxYr5EnS03Czj4PtJjHKnPrhtslgGHWkf33BcktRdB+9ku5yVAdZCIYAutioMPPF+1xw2u27kzz39VDBAIWk9bScyIjsz0bgM8l9nt0iJ45Z8txHrd/VmdunSlSD4BNSIEiLGYSzA1wJdfypCDoCSQQST6vGnYUnni1e9r08xPXfrtRwKryLa00kj8jWUsaR0TMgxlVij+C/Jw3DjkTAUZyBZTcW+LH5i92VjNW0ZJWzipbpQkUh9gzP5d4c5xMdE31AqNulnyBU0US8E= Content-Type: multipart/alternative; boundary="_000_BYAPR11MB36388B5D52641053E327A084C1490BYAPR11MB3638namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c30c4430-1ddb-4c5a-85d1-08d6a6a321f5 X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Mar 2019 04:28:09.6650 (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-Transport-CrossTenantHeadersStamped: BYAPR11MB3669 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.30, xch-aln-020.cisco.com X-Outbound-Node: rcdn-core-11.cisco.com Archived-At: Subject: Re: [Lsr] Temporary addition of links to flooding topology in dynamic flooding X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 04:28:17 -0000 --_000_BYAPR11MB36388B5D52641053E327A084C1490BYAPR11MB3638namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Um9iZXJ0IOKAkw0KDQpJIGRvbuKAmXQgdGhpbmsgdGhlIHdvcmQg4oCccmFuZG9t4oCdIGlzIGFw cGxpY2FibGUuDQoNClNlY3Rpb24gNi43LjExIHN0YXRlcyAoZW1waGFzaXMgYWRkZWQpOg0KDQri gJxJbiB0aGUgdW5saWtlbHkgZXZlbnQgb2YgbXVsdGlwbGUgZmFpbHVyZXMgb24gdGhlIGZsb29k aW5nIHRvcG9sb2d5LA0KICAgaXQgbWF5IGJlY29tZSBwYXJ0aXRpb25lZC4gIFRoZSBub2RlcyB0 aGF0IHJlbWFpbiBhY3RpdmUgb24gdGhlIGVkZ2VzDQogICBvZiB0aGUgZmxvb2RpbmcgdG9wb2xv Z3kgcGFydGl0aW9ucyB3aWxsIHJlY29nbml6ZSB0aGlzIGFuZCB3aWxsIHRyeQ0KICAgdG8gcmVw YWlyIHRoZSBmbG9vZGluZyB0b3BvbG9neSBsb2NhbGx5IGJ5IGVuYWJsaW5nIHRlbXBvcmFyeQ0K ICAgZmxvb2RpbmcgdG93YXJkcyB0aGUgbm9kZXMgdGhhdCB0aGV5IGNvbnNpZGVyIGRpc2Nvbm5l Y3RlZCBmcm9tIHRoZQ0KICAgZmxvb2RpbmcgdG9wb2xvZ3kgdW50aWwgYSBuZXcgZmxvb2Rpbmcg dG9wb2xvZ3kgYmVjb21lcyBjb25uZWN0ZWQNCiAgIGFnYWluLuKAnQ0KDQpUaGlzIGlzbuKAmXQg YSBjYXNlIG9mIGV2ZXJ5IG5vZGUgaW4gdGhlIG5ldHdvcmsgdHJ5aW5nIHRvIGRlY2lkZSBob3cg dG8gcmVwYWlyIHRoZSBwYXJ0aXRpb24uIEl0IGlzIG9ubHkgdGhlIG5vZGVzIGF0IHRoZSBlZGdl KHMpIG9mIHRoZSBwYXJ0aXRpb24gZG9pbmcgc28uIEkgZG8gbm90IHNlZSB0aGlzIGFzIOKAnHJh bmRvbeKAnS4NCg0KV2hhdCBpcyBiZWluZyBkZWJhdGVkIG9uIHRoZSBsaXN0IGlzIG5vdCByZWxh dGVkIHRvIHJhbmRvbW5lc3Mg4oCTIGl0IGlzIHRoZSBkZWdyZWUgb2YgdGVtcG9yYXJ5IGZsb29k aW5nIGFsb25nIHRoZSBjb250aW51dW0gZnJvbSDigJxtaW5pbWFs4oCdIChvbmUgYWRkaXRpb25h bCBlZGdlKSB0byDigJxtYXhpbWFs4oCdIChhbGwgZWRnZXMgdG8gbm9kZXMgd2hpY2ggYXJlIHNl ZW4gYXMgY3VycmVudGx5IGRpc2Nvbm5lY3RlZCkuIFRoZSBmb3JtZXIgcmlza3MgbG9uZ2VyIGNv bnZlcmdlbmNlIOKAkyB0aGUgbGF0dGVyIHJpc2tzIHRlbXBvcmFyeSBmbG9vZGluZyBzdG9ybXMu IEJ1dCBuZWl0aGVyIGFwcHJvYWNoIGlzIHJhbmRvbS4gT25jZSB0aGUgZmFpbHVyZXMgYXJlIGtu b3duLCB0aGUgc2V0IG9mIGNhbmRpZGF0ZXMgaXMgcHJlZGljdGFibGUuDQoNClRoZSBjb25jZXB0 IG9mIExGQSBhbHNvIGlzbuKAmXQgYXBwbGljYWJsZSBoZXJlLiAgTEZBIChpZiB3ZSB1c2UgdGhl IHRlcm0gaW4gdGhpcyBjYXNlIHRvIG1lYW4gYSBwcmVjYWxjdWxhdGVkIHNldCBvZiB0ZW1wb3Jh cnkgZmxvb2RpbmcgZWRnZXMpIGlzIHVzZWZ1bCB3aGVuIGl0IGNhbiBiZSBwcmVpbnN0YWxsZWQg aW4gdGhlIGZvcndhcmRpbmcgcGxhbmUsIGFsbG93aW5nIGEgbm9kZSB0byBlbGltaW5hdGUgd2Fp dGluZyBmb3IgY29udHJvbCBwbGFuZSBpbnRlcnZlbnRpb24gd2hlbiBhIGxvY2FsIGZhaWx1cmUg aXMgZGV0ZWN0ZWQuDQpCdXQgTFNQL0xTQSBmbG9vZGluZyBpcyBhbHdheXMgZG9uZSBieSB0aGUg Y29udHJvbCBwbGFuZSDigJMgc28gaGF2aW5nIGEgcHJlY2FsY3VsYXRlZCBMRkEgd291bGRu4oCZ dCBwcm9kdWNlIGEgZmFzdGVyIHJlc3BvbnNlIHRpbWUuIElmIHlvdSBhcmUgZ29pbmcgdG8gc3Vn Z2VzdCB0aGF0IHRoZSBjYWxjdWxhdGlvbiByZXF1aXJlZCB0byBkZXRlcm1pbmUgYSBmbG9vZGlu ZyB0b3BvbG9neSBwYXJ0aXRpb24gaXMgaXRzZWxmIGNvc3RseSBJIHRoaW5rIHRoaXMgaXMgbm90 IHN1cHBvcnRlZCBieSBjdXJyZW50IFNQRiBjYWxjdWxhdGlvbiB0aW1lcy4gSW4gYWRkaXRpb24s IGdpdmVuIHRlbXBvcmFyeSBmbG9vZGluZyBpcyBub3JtYWxseSBvbmx5IHJlcXVpcmVkIGluIHRo ZSBldmVudCBvZiBtdWx0aXBsZSBmYWlsdXJlcywgdGhlIGNvbWJpbmF0aW9ucyByZXF1aXJlZCB0 byBiZSBzdXBwb3J0ZWQgaW4gb3JkZXIgdG8gaGF2ZSBhIHVzZWZ1bCBzZXQgb2YgcHJlLWNhbGN1 bGF0ZWQgdGVtcG9yYXJ5IGZsb29kaW5nIGVkZ2VzIGJlY29tZXMgcXVpdGUgbGFyZ2Ug4oCTIHdo aWNoIG1ha2VzIHN1Y2ggYW4gYXBwcm9hY2ggaW1wcmFjdGljYWwuDQoNCiAgIExlcw0KDQoNCkZy b206IExzciA8bHNyLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiBSb2JlcnQgUmFzenVr DQpTZW50OiBNb25kYXksIE1hcmNoIDExLCAyMDE5IDI6MjggUE0NClRvOiBsc3JAaWV0Zi5vcmcN ClN1YmplY3Q6IFtMc3JdIFRlbXBvcmFyeSBhZGRpdGlvbiBvZiBsaW5rcyB0byBmbG9vZGluZyB0 b3BvbG9neSBpbiBkeW5hbWljIGZsb29kaW5nDQoNCkhpLA0KDQpBcyBvZiBub3cgYXQgdGhlIGV2 ZW50IG9mIGZhaWx1cmUgb2YgYW55IG9mIHRoZSBGVCBlbmFibGVkIGxpbmsgYWRkaXRpb25hbCBs aW5rcyBhcmUgYmVpbmcgYWRkZWQgaW4gbW9yZSBvciBsZXNzIHJhbmRvbSBmYXNoaW9uIGJ5IG5v ZGVzIGRpcmVjdGx5IGNvbm5lY3RlZCB0byB0aGUgZmFpbGVkIGxpbmtzLg0KDQpJbiB0aGUgZXZl bnQgb2YgMTAwcyBvZiBsaW5rcyBvbiBzdWNoIG5vZGVzIGFuZCBhZHZpc2FibGUgcmF0ZSBsaW1p dGluZyBhZGRpdGlvbiBvZiB0aG9zZSBsaW5rcyBpdCBzZWVtcyB0aGF0IHJlcGFpciBvZiBGVCBt YXkgdGFrZSBzb21lIHRpbWUuDQoNCkluIG9yZGVyIHRvIHJlZHVjZSBzdWNoIHRpbWUgaW50ZXJ2 YWwgYmV0dGVyIHRoZW4gcmFuZG9tIGFkZGl0aW9uIG9mIHJlbWFpbmluZyBsaW5rcyBzZWVtcyBy ZWNvbW1lbmRlZC4gSG93IGFib3V0IHdlIGhpbnQgcGFydGljaXBhdGluZyBub2RlcyB0byBleGVj dXRlIHB1cmVseSBpbiBjb250cm9sIHBsYW5lIG9mIEZUIGFuIExGQSBhbGdvcml0aG0gZm9yIHBv c3NpYmxlIGZ1dHVyZSBldmVudCBvZiBhY3RpdmUgbGluayBmYWlsdXJlIGFuZCB1c2UgcmVzdWx0 cyBvZiB0aGUgTEZBIGNvbXB1dGF0aW9uIHRvIHByaW9yaXRpemUgbGlua3Mgd2hpY2ggd2lsbCBi ZSBmaXJzdCB0ZW1wb3JhcnkgYWRkaXRpb25zIHVwb24gYWN0aXZlIGZsb29kaW5nIGxpbmtzIGZh aWx1cmVzID8NCg0KU3VjaCBvcHRpbWl6YXRpb24gaXMgbG9jYWwgYW5kIG9wdGlvbmFsIGFuZCBk b2VzIG5vdCByZXF1aXJlIGFueSBjaGFuZ2VzIHRvIHByb3Bvc2VkIHByb3RvY29sIHNpZ25hbGxp bmcuDQoNClRoZXJlZm9yIGhvdyBhYm91dCBqdXN0IG9uZSBzZW50ZW5jZSBhZGRpdGlvbiB0byBz ZWN0aW9uIDYuNy4xIG9mIGRyYWZ0LWlldGYtbHNyLWR5bmFtaWMtZmxvb2Rpbmc6DQoNClRlbXBv cmFyeSBhZGRpdGlvbnMgb2YgbGlua3MgdG8gZmxvb2RpbmcgdG9wb2xvZ3kgY291bGQgYmUgbW9y ZSBlZHVjYXRlZCBpZiBnaXZlbiBub2RlIHJ1bnMgYSBwdXJlIGNvbnRyb2wgcGxhbmUgTEZBIGFo ZWFkIG9mIGFueSBGVCBmYWlsdXJlIG9uIGFjdGl2ZSBGVCBsaW5rcyBjb21wbGV0ZWx5IGRldGFj aGVkIGZyb20gcG90ZW50aWFsIExGQSBydW5zIGZvciBkYXRhIHBsYW5lIHRvcG9sb2d5Lg0KDQpL aW5kIHJlZ2FyZHMsDQpSLg0KDQo= --_000_BYAPR11MB36388B5D52641053E327A084C1490BYAPR11MB3638namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1z b25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCglt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4t Ym90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4uRW1haWxTdHlsZTE4 DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1 bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEt LVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzpp ZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtl bmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Um9iZXJ0IOKAkzxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBkb27igJl0IHRoaW5rIHRoZSB3b3JkIOKA nHJhbmRvbeKAnSBpcyBhcHBsaWNhYmxlLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzFGNDk3RCI+U2VjdGlvbiA2LjcuMTEgc3RhdGVzIChlbXBoYXNpcyBhZGRlZCk6PG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2Nv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj7igJxJbiB0aGUgdW5saWtlbHkg ZXZlbnQgb2YgbXVsdGlwbGUgZmFpbHVyZXMgb24gdGhlIGZsb29kaW5nIHRvcG9sb2d5LDxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgaXQgbWF5IGJlY29tZSBwYXJ0aXRpb25lZC4mbmJz cDsNCjxiPlRoZSBub2RlcyB0aGF0IHJlbWFpbiBhY3RpdmUgb24gdGhlIGVkZ2VzPG86cD48L286 cD48L2I+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgb2YgdGhlIGZsb29kaW5nIHRvcG9sb2d5IHBh cnRpdGlvbnM8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4gd2lsbCBy ZWNvZ25pemUgdGhpcyBhbmQgd2lsbA0KIHRyeTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJz cDsgdG8gcmVwYWlyIHRoZSBmbG9vZGluZyB0b3BvbG9neSBsb2NhbGx5IGJ5DQo8Yj5lbmFibGlu ZyB0ZW1wb3Jhcnk8bzpwPjwvbzpwPjwvYj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2Fs aWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBmbG9vZGlu ZyB0b3dhcmRzIHRoZSBub2RlcyB0aGF0IHRoZXkgY29uc2lkZXIgZGlzY29ubmVjdGVkIGZyb20g dGhlPG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDsmbmJzcDsgZmxvb2RpbmcgdG9wb2xv Z3k8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4gdW50aWwgYSBuZXcg Zmxvb2RpbmcgdG9wb2xvZ3kgYmVjb21lcyBjb25uZWN0ZWQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7Jm5ic3A7IGFnYWluLuKAnTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nh bGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+VGhpcyBpc27igJl0IGEgY2FzZSBvZiBldmVyeSBub2RlIGluIHRoZSBuZXR3b3JrIHRy eWluZyB0byBkZWNpZGUgaG93IHRvIHJlcGFpciB0aGUgcGFydGl0aW9uLiBJdCBpcyBvbmx5IHRo ZSBub2RlcyBhdCB0aGUgZWRnZShzKSBvZiB0aGUgcGFydGl0aW9uIGRvaW5nIHNvLiBJDQogZG8g bm90IHNlZSB0aGlzIGFzIOKAnHJhbmRvbeKAnS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPldoYXQgaXMgYmVpbmcgZGViYXRlZCBvbiB0aGUgbGlzdCBpcyBub3Qg cmVsYXRlZCB0byByYW5kb21uZXNzIOKAkyBpdCBpcyB0aGUgZGVncmVlIG9mIHRlbXBvcmFyeSBm bG9vZGluZyBhbG9uZyB0aGUgY29udGludXVtIGZyb20g4oCcbWluaW1hbOKAnSAob25lIGFkZGl0 aW9uYWwgZWRnZSkNCiB0byDigJxtYXhpbWFs4oCdIChhbGwgZWRnZXMgdG8gbm9kZXMgd2hpY2gg YXJlIHNlZW4gYXMgY3VycmVudGx5IGRpc2Nvbm5lY3RlZCkuIFRoZSBmb3JtZXIgcmlza3MgbG9u Z2VyIGNvbnZlcmdlbmNlIOKAkyB0aGUgbGF0dGVyIHJpc2tzIHRlbXBvcmFyeSBmbG9vZGluZyBz dG9ybXMuIEJ1dCBuZWl0aGVyIGFwcHJvYWNoIGlzIHJhbmRvbS4gT25jZSB0aGUgZmFpbHVyZXMg YXJlIGtub3duLCB0aGUgc2V0IG9mIGNhbmRpZGF0ZXMgaXMgcHJlZGljdGFibGUuPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5UaGUgY29uY2VwdCBvZiBMRkEgYWxz byBpc27igJl0IGFwcGxpY2FibGUgaGVyZS4gJm5ic3A7TEZBIChpZiB3ZSB1c2UgdGhlIHRlcm0g aW4gdGhpcyBjYXNlIHRvIG1lYW4gYSBwcmVjYWxjdWxhdGVkIHNldCBvZiB0ZW1wb3JhcnkgZmxv b2RpbmcgZWRnZXMpIGlzIHVzZWZ1bCB3aGVuIGl0DQogY2FuIGJlIHByZWluc3RhbGxlZCBpbiB0 aGUgZm9yd2FyZGluZyBwbGFuZSwgYWxsb3dpbmcgYSBub2RlIHRvIGVsaW1pbmF0ZSB3YWl0aW5n IGZvciBjb250cm9sIHBsYW5lIGludGVydmVudGlvbiB3aGVuIGEgbG9jYWwgZmFpbHVyZSBpcyBk ZXRlY3RlZC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QnV0IExTUC9MU0EgZmxvb2RpbmcgaXMgYWx3YXlz IGRvbmUgYnkgdGhlIGNvbnRyb2wgcGxhbmUg4oCTIHNvIGhhdmluZyBhIHByZWNhbGN1bGF0ZWQg TEZBIHdvdWxkbuKAmXQgcHJvZHVjZSBhIGZhc3RlciByZXNwb25zZSB0aW1lLiBJZiB5b3UgYXJl IGdvaW5nIHRvIHN1Z2dlc3QNCiB0aGF0IHRoZSBjYWxjdWxhdGlvbiByZXF1aXJlZCB0byBkZXRl cm1pbmUgYSBmbG9vZGluZyB0b3BvbG9neSBwYXJ0aXRpb24gaXMgaXRzZWxmIGNvc3RseSBJIHRo aW5rIHRoaXMgaXMgbm90IHN1cHBvcnRlZCBieSBjdXJyZW50IFNQRiBjYWxjdWxhdGlvbiB0aW1l cy4gSW4gYWRkaXRpb24sIGdpdmVuIHRlbXBvcmFyeSBmbG9vZGluZyBpcyBub3JtYWxseSBvbmx5 IHJlcXVpcmVkIGluIHRoZSBldmVudCBvZiBtdWx0aXBsZSBmYWlsdXJlcywgdGhlDQogY29tYmlu YXRpb25zIHJlcXVpcmVkIHRvIGJlIHN1cHBvcnRlZCBpbiBvcmRlciB0byBoYXZlIGEgdXNlZnVs IHNldCBvZiBwcmUtY2FsY3VsYXRlZCB0ZW1wb3JhcnkgZmxvb2RpbmcgZWRnZXMgYmVjb21lcyBx dWl0ZSBsYXJnZSDigJMgd2hpY2ggbWFrZXMgc3VjaCBhbiBhcHByb2FjaCBpbXByYWN0aWNhbC48 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBM ZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv bGlkIGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gTHNyICZsdDtsc3ItYm91bmNl c0BpZXRmLm9yZyZndDsNCjxiPk9uIEJlaGFsZiBPZiA8L2I+Um9iZXJ0IFJhc3p1azxicj4NCjxi PlNlbnQ6PC9iPiBNb25kYXksIE1hcmNoIDExLCAyMDE5IDI6MjggUE08YnI+DQo8Yj5Ubzo8L2I+ IGxzckBpZXRmLm9yZzxicj4NCjxiPlN1YmplY3Q6PC9iPiBbTHNyXSBUZW1wb3JhcnkgYWRkaXRp b24gb2YgbGlua3MgdG8gZmxvb2RpbmcgdG9wb2xvZ3kgaW4gZHluYW1pYyBmbG9vZGluZzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ SGksPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BcyBvZiBu b3cgYXQgdGhlIGV2ZW50IG9mIGZhaWx1cmUgb2YgYW55IG9mIHRoZSBGVCBlbmFibGVkIGxpbmsg YWRkaXRpb25hbCBsaW5rcyBhcmUgYmVpbmcgYWRkZWQgaW4gbW9yZSBvciBsZXNzIHJhbmRvbSBm YXNoaW9uIGJ5IG5vZGVzIGRpcmVjdGx5IGNvbm5lY3RlZCB0byB0aGUgZmFpbGVkIGxpbmtzLiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5JbiB0aGUgZXZlbnQgb2YgMTAwcyBvZiBsaW5rcyBvbiBzdWNoIG5vZGVzIGFuZCBhZHZpc2Fi bGUgcmF0ZSBsaW1pdGluZyBhZGRpdGlvbiBvZiB0aG9zZSBsaW5rcyBpdCBzZWVtcyB0aGF0IHJl cGFpciBvZiBGVCBtYXkgdGFrZSBzb21lIHRpbWUuJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkluIG9yZGVyIHRvIHJlZHVjZSBzdWNo IHRpbWUgaW50ZXJ2YWwgYmV0dGVyIHRoZW4gcmFuZG9tIGFkZGl0aW9uIG9mIHJlbWFpbmluZyBs aW5rcyBzZWVtcyByZWNvbW1lbmRlZC4gSG93IGFib3V0IHdlIGhpbnQgcGFydGljaXBhdGluZyBu b2RlcyB0byBleGVjdXRlIHB1cmVseSBpbiBjb250cm9sIHBsYW5lIG9mIEZUIGFuIExGQSBhbGdv cml0aG0gZm9yIHBvc3NpYmxlIGZ1dHVyZSBldmVudCBvZiBhY3RpdmUNCiBsaW5rIGZhaWx1cmUg YW5kIHVzZSByZXN1bHRzIG9mIHRoZSBMRkEgY29tcHV0YXRpb24gdG8gcHJpb3JpdGl6ZSBsaW5r cyB3aGljaCB3aWxsIGJlIGZpcnN0IHRlbXBvcmFyeSBhZGRpdGlvbnMgdXBvbiBhY3RpdmUgZmxv b2RpbmcgbGlua3MgZmFpbHVyZXMgPyZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN1Y2ggb3B0aW1pemF0aW9u IGlzIGxvY2FsIGFuZCBvcHRpb25hbCBhbmQgZG9lcyBub3QgcmVxdWlyZSBhbnkgY2hhbmdlcyB0 byBwcm9wb3NlZCBwcm90b2NvbCBzaWduYWxsaW5nLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi Pjx1PlRoZXJlZm9yIGhvdyBhYm91dCBqdXN0IG9uZSBzZW50ZW5jZSBhZGRpdGlvbiB0byBzZWN0 aW9uIDYuNy4xIG9mJm5ic3A7ZHJhZnQtaWV0Zi1sc3ItZHluYW1pYy1mbG9vZGluZzo8L3U+PG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxpPlRl bXBvcmFyeSBhZGRpdGlvbnMgb2YgbGlua3MgdG8gZmxvb2RpbmcgdG9wb2xvZ3kgY291bGQgYmUg bW9yZSBlZHVjYXRlZCBpZiBnaXZlbiBub2RlIHJ1bnMgYSBwdXJlIGNvbnRyb2wgcGxhbmUgTEZB IGFoZWFkIG9mIGFueSBGVCBmYWlsdXJlIG9uIGFjdGl2ZSBGVCBsaW5rcyBjb21wbGV0ZWx5IGRl dGFjaGVkIGZyb20gcG90ZW50aWFsIExGQSBydW5zIGZvciBkYXRhIHBsYW5lIHRvcG9sb2d5LiZu YnNwOzwvaT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5LaW5kIHJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_BYAPR11MB36388B5D52641053E327A084C1490BYAPR11MB3638namp_-- From nobody Mon Mar 11 22:36:04 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 180D2130ECE for ; Mon, 11 Mar 2019 22:36:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 Q-ZQHmJzMkWU for ; Mon, 11 Mar 2019 22:36:00 -0700 (PDT) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (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 5A28C12008F for ; Mon, 11 Mar 2019 22:36:00 -0700 (PDT) Received: by mail-pf1-x435.google.com with SMTP id s23so968041pfe.13 for ; Mon, 11 Mar 2019 22:36:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZrtMMkiYWjBAOSOHYqUKMB6AdaSjNQAsnMaiws62haM=; b=qrZqNTJNnv6gbebEvp7OP2K2oO1OMOISwcBg3OxfbTNEp0BVFgAFwT1GWpDDKiAWgo UBtdAEvuZbHTxtUgofi58HLbGYpEXVBf1DeuYgYcMN88GU5fVZcJL3WeU0fwUVxYOqBd GAUiiGDaWmnATPQDI1T/MFHeCNiwRZPkT2xZLjav95CyiinEixJ/tmiCRcZx2w82i+QV 69XTPdygBuy1MBVRNZO1tW173aSgNdXHPITjFaoM4nmKRGzL6Eb8Im/CRNA0ifQQDy8w ZQukClTrPKrwzUUGPCcejnVWE/0cUmzkRt22wFnPzMQWxqE4wHd5cOBdInxpHm6bCZaQ Uj6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ZrtMMkiYWjBAOSOHYqUKMB6AdaSjNQAsnMaiws62haM=; b=t+1znyXAzKKxNZ9HT+EI3AigYK1oPrzYKMIGyqB3Udg/wkcqC4q9kWIDbHsIwYBsdr CQTV1UoVprCBwvtIOZjUYE8zkP4FdE6ED1JY9wsvBW45PHkL27ZjIk7xtceVlSVGoEuF pv7f6BxC8rnwgEvwUFWEQllNOSOzE5FhtxSFLEbZxc29mX/CU9uIcRgkOzcVy9in21og CUvaRVIr/sWbrPEyYYskqd+u8b1LfZZmwekTPukT+XhjpkhiuR9dX3uvgirbBV+4TqCo 1ZOUyuw0nFtIZ+R3+fIwLGV+fobpBrrv0WnVJvmuv8FHnEgKm2g+SXa9diHr1yb38ZfE Qssg== X-Gm-Message-State: APjAAAWTW5ndt2NM0bdmWwTjVtUVvUQQhwm5AL1WsIwPnt3EA0ScNDuV qvjeDa6JQV3cGiEjjA2GUTrJL+qPIBo= X-Google-Smtp-Source: APXvYqx+ryQN+dnWgaaeo5XSsMnoprTsUjzGM3uWUGPx154bhv1cizYSO6d+afhkydhJFeOkkc5gbg== X-Received: by 2002:a63:ed0b:: with SMTP id d11mr33188318pgi.435.1552368959279; Mon, 11 Mar 2019 22:35:59 -0700 (PDT) Received: from [192.168.1.10] (c-73-189-13-44.hsd1.ca.comcast.net. [73.189.13.44]) by smtp.gmail.com with ESMTPSA id 63sm11014917pfy.110.2019.03.11.22.35.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 11 Mar 2019 22:35:58 -0700 (PDT) Content-Type: multipart/alternative; boundary=Apple-Mail-C80DBD70-EF75-4FC2-9F66-FDD481F63083 Mime-Version: 1.0 (1.0) From: Jeff Tantsura X-Mailer: iPhone Mail (16D57) In-Reply-To: Date: Mon, 11 Mar 2019 22:35:57 -0700 Cc: Robert Raszuk , "lsr@ietf.org" Content-Transfer-Encoding: 7bit Message-Id: <0FA6B05A-D487-4EAB-AB6E-038B1E7E25C5@gmail.com> References: To: "Les Ginsberg (ginsberg)" Archived-At: Subject: Re: [Lsr] Temporary addition of links to flooding topology in dynamic flooding X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 05:36:03 -0000 --Apple-Mail-C80DBD70-EF75-4FC2-9F66-FDD481F63083 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1 Les. In general - in ECMP cases LFA is meaningless (any ECMP member is loop-free p= er definition) so commonly used technology is fast-rehash, where in case of f= ailure all the flows that would use the link in question are rehashed over o= ther links in the bundle and that is done in HW. Regards, Jeff > On Mar 11, 2019, at 21:28, Les Ginsberg (ginsberg) wr= ote: >=20 > Robert =E2=80=93 > =20 > I don=E2=80=99t think the word =E2=80=9Crandom=E2=80=9D is applicable. > =20 > Section 6.7.11 states (emphasis added): > =20 > =E2=80=9CIn the unlikely event of multiple failures on the flooding topolo= gy, > it may become partitioned. The nodes that remain active on the edges > of the flooding topology partitions will recognize this and will try > to repair the flooding topology locally by enabling temporary > flooding towards the nodes that they consider disconnected from the > flooding topology until a new flooding topology becomes connected > again.=E2=80=9D > =20 > This isn=E2=80=99t a case of every node in the network trying to decide ho= w to repair the partition. It is only the nodes at the edge(s) of the partit= ion doing so. I do not see this as =E2=80=9Crandom=E2=80=9D. > =20 > What is being debated on the list is not related to randomness =E2=80=93 i= t is the degree of temporary flooding along the continuum from =E2=80=9Cmini= mal=E2=80=9D (one additional edge) to =E2=80=9Cmaximal=E2=80=9D (all edges t= o nodes which are seen as currently disconnected). The former risks longer c= onvergence =E2=80=93 the latter risks temporary flooding storms. But neither= approach is random. Once the failures are known, the set of candidates is p= redictable. > =20 > The concept of LFA also isn=E2=80=99t applicable here. LFA (if we use the= term in this case to mean a precalculated set of temporary flooding edges) i= s useful when it can be preinstalled in the forwarding plane, allowing a nod= e to eliminate waiting for control plane intervention when a local failure i= s detected. > But LSP/LSA flooding is always done by the control plane =E2=80=93 so havi= ng a precalculated LFA wouldn=E2=80=99t produce a faster response time. If y= ou are going to suggest that the calculation required to determine a floodin= g topology partition is itself costly I think this is not supported by curre= nt SPF calculation times. In addition, given temporary flooding is normally o= nly required in the event of multiple failures, the combinations required to= be supported in order to have a useful set of pre-calculated temporary floo= ding edges becomes quite large =E2=80=93 which makes such an approach imprac= tical. > =20 > Les > =20 > =20 > From: Lsr On Behalf Of Robert Raszuk > Sent: Monday, March 11, 2019 2:28 PM > To: lsr@ietf.org > Subject: [Lsr] Temporary addition of links to flooding topology in dynamic= flooding > =20 > Hi, > =20 > As of now at the event of failure of any of the FT enabled link additional= links are being added in more or less random fashion by nodes directly conn= ected to the failed links.=20 > =20 > In the event of 100s of links on such nodes and advisable rate limiting ad= dition of those links it seems that repair of FT may take some time.=20 > =20 > In order to reduce such time interval better then random addition of remai= ning links seems recommended. How about we hint participating nodes to execu= te purely in control plane of FT an LFA algorithm for possible future event o= f active link failure and use results of the LFA computation to prioritize l= inks which will be first temporary additions upon active flooding links fail= ures ?=20 > =20 > Such optimization is local and optional and does not require any changes t= o proposed protocol signalling.=20 > =20 > Therefor how about just one sentence addition to section 6.7.1 of draft-ie= tf-lsr-dynamic-flooding: > =20 > Temporary additions of links to flooding topology could be more educated i= f given node runs a pure control plane LFA ahead of any FT failure on active= FT links completely detached from potential LFA runs for data plane topolog= y.=20 > =20 > Kind regards, > R. > =20 > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr --Apple-Mail-C80DBD70-EF75-4FC2-9F66-FDD481F63083 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable +1 Les.

In general - in E= CMP cases LFA is meaningless (any ECMP member is loop-free per definition) s= o commonly used technology is fast-rehash, where in case of failure all the f= lows that would use the link in question are rehashed over other links in th= e bundle and that is done in HW.

Regards,
Jeff

On Mar 11, 2= 019, at 21:28, Les Ginsberg (ginsberg) <ginsberg@cisco.com> wrote:

Robert =E2=80=93

 

I don=E2=80=99t think the word =E2=80=9C= random=E2=80=9D is applicable.

 

Section 6.7.11 states (emphasis added):=

 

=E2=80=9CIn the unlikely event of multi= ple failures on the flooding topology,

   it may become partitioned.=   The nodes that remain active on the edges

   of the flooding topolog= y partitions will recognize this and will try

   to repair the flooding top= ology locally by enabling temporary

   flooding towards the no= des that they consider disconnected from the

   flooding topology until a new flooding topology becomes connected

   again.=E2=80=9D=

 

This isn=E2=80=99t a case of every node= in the network trying to decide how to repair the partition. It is only the= nodes at the edge(s) of the partition doing so. I do not see this as =E2=80=9Crandom=E2=80=9D.

 

What is being debated on the list is no= t related to randomness =E2=80=93 it is the degree of temporary flooding alo= ng the continuum from =E2=80=9Cminimal=E2=80=9D (one additional edge) to =E2=80=9Cmaximal=E2=80=9D (all edges to nodes which are seen as currentl= y disconnected). The former risks longer convergence =E2=80=93 the latter ri= sks temporary flooding storms. But neither approach is random. Once the fail= ures are known, the set of candidates is predictable.

 

The concept of LFA also isn=E2=80=99t a= pplicable here.  LFA (if we use the term in this case to mean a precalc= ulated set of temporary flooding edges) is useful when it can be preinstalled in the forwarding plane, allowing a node to eliminate w= aiting for control plane intervention when a local failure is detected.=

But LSP/LSA flooding is always done by t= he control plane =E2=80=93 so having a precalculated LFA wouldn=E2=80=99t pr= oduce a faster response time. If you are going to suggest that the calculation required to determine a flooding topology partition is= itself costly I think this is not supported by current SPF calculation time= s. In addition, given temporary flooding is normally only required in the ev= ent of multiple failures, the combinations required to be supported in order to have a useful set of pre-= calculated temporary flooding edges becomes quite large =E2=80=93 which make= s such an approach impractical.

 

   Les

 

 

From: Lsr <lsr-bounces@ietf.org> On Behalf Of Robert Raszuk
Sent: Monday, March 11, 2019 2:28 PM
To: lsr@ietf.org
Subject: [Lsr] Temporary addition of links to flooding topology in dy= namic flooding

 

Hi,

 

As of now at the event of failure of any of the FT en= abled link additional links are being added in more or less random fashion b= y nodes directly connected to the failed links. 

 

In the event of 100s of links on such nodes and advis= able rate limiting addition of those links it seems that repair of FT may ta= ke some time. 

 

In order to reduce such time interval better then ran= dom addition of remaining links seems recommended. How about we hint partici= pating nodes to execute purely in control plane of FT an LFA algorithm for p= ossible future event of active link failure and use results of the LFA computation to prioritize links whi= ch will be first temporary additions upon active flooding links failures ?&n= bsp;

 

Such optimization is local and optional and does not r= equire any changes to proposed protocol signalling. 

 

Therefor how about just one sentence addition to s= ection 6.7.1 of draft-ietf-lsr-dynamic-flooding:

 

Temporary additions of links to flooding topology c= ould be more educated if given node runs a pure control plane LFA ahead of a= ny FT failure on active FT links completely detached from potential LFA runs= for data plane topology. 

 

Kind regards,

R.

 

________= _______________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org= /mailman/listinfo/lsr
= --Apple-Mail-C80DBD70-EF75-4FC2-9F66-FDD481F63083-- From nobody Mon Mar 11 23:45:27 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C88E8130EFC for ; Mon, 11 Mar 2019 23:45:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 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 qz5OfquRrDsO for ; Mon, 11 Mar 2019 23:45:23 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A69D6130EE7 for ; Mon, 11 Mar 2019 23:45:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2471; q=dns/txt; s=iport; t=1552373122; x=1553582722; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=DIEh9vKgbgmDKFnGMoDtxKq/Q7GZZH7z9embNKGvQWU=; b=QyVQeiww4eXU6RJJgMOalK8duZx3EZmZkpFb5Cumoiz6CnJ0YHyP36md PD1hC/F5cwmjCBJsLbZwHs/zy0KW9RtuSj3v6pJ2h2pg1BLt7tojbmkmb 0pG/fyEWI6A8wsG0bRulPUBpPKPVknVOg9g05QA9G3tWCfEm9sPT0UWoq M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAACfVIdc/xbLJq1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBZYESUCESJ4wkX4xlmCqBew0YC4RJAoRcNAk?= =?us-ascii?q?NAQEDAQEJAQMCbRwMhUoBAQEDAQEBNjYbCxguJzAGAQwGAgEBglNLAYFtCA+?= =?us-ascii?q?xOoVFhHsFgS8Bi0OBQD+BESeCPS6DHgEBh0IDihSHLIEXkVIJi1CHOwYZiwG?= =?us-ascii?q?IOop5knaBRziBVjMaCBsVO4JsiwyFQD4DMI12KoIjAQE?= X-IronPort-AV: E=Sophos;i="5.58,470,1544486400"; d="scan'208";a="10685391" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Mar 2019 06:45:20 +0000 Received: from [10.60.140.53] (ams-ppsenak-nitro4.cisco.com [10.60.140.53]) by aer-core-2.cisco.com (8.15.2/8.15.2) with ESMTP id x2C6jKE4008107; Tue, 12 Mar 2019 06:45:20 GMT To: Robert Raszuk , lsr@ietf.org References: From: Peter Psenak Message-ID: Date: Tue, 12 Mar 2019 07:45:18 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Outbound-SMTP-Client: 10.60.140.53, ams-ppsenak-nitro4.cisco.com X-Outbound-Node: aer-core-2.cisco.com Archived-At: Subject: Re: [Lsr] Temporary addition of links to flooding topology in dynamic flooding X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 06:45:26 -0000 Hi Robert, On 11/03/2019 22:28 , Robert Raszuk wrote: > Hi, > > As of now at the event of failure of any of the FT enabled link > additional links are being added in more or less random fashion by nodes > directly connected to the failed links. above statement is incorrect. It is absolutely NOT TRUE that "at the event of failure of any of the FT enabled link additional links are being added". Temporary additions of the links to the FT has its strict rules: 6.7.5. Failures of Link On the Flooding Topology "If the failed local link represented the only connection to the flooding topology on the node where the link failed, the node MUST enable temporary flooding on a subset of its local links." 6.7.9. Treatment of Disconnected Adjacent Nodes Every time there is a change in the flooding topology a node MUST check if there are any adjacent nodes that are disconnected from the current flooding topology. Temporary flooding MUST be enabled towards a subset of the disconnected nodes. So we are only performing temporary flooding if either we or one of our neighbors got isolated from the FT, which given the bi-connectivity of the FT itself is an unlikely event. thanks, Peter > > In the event of 100s of links on such nodes and advisable rate limiting > addition of those links it seems that repair of FT may take some time. > > In order to reduce such time interval better then random addition of > remaining links seems recommended. How about we hint participating nodes > to execute purely in control plane of FT an LFA algorithm for possible > future event of active link failure and use results of the LFA > computation to prioritize links which will be first temporary additions > upon active flooding links failures ? > > Such optimization is local and optional and does not require any changes > to proposed protocol signalling. > > _Therefor how about just one sentence addition to section 6.7.1 > of draft-ietf-lsr-dynamic-flooding:_ > > /Temporary additions of links to flooding topology could be more > educated if given node runs a pure control plane LFA ahead of any FT > failure on active FT links completely detached from potential LFA runs > for data plane topology. / > > Kind regards, > R. > / > / > > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > From nobody Tue Mar 12 02:42:48 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA704131000 for ; Tue, 12 Mar 2019 02:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=raszuk.net 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 EjE-bb6yJwzu for ; Tue, 12 Mar 2019 02:42:39 -0700 (PDT) Received: from mail-qk1-x72d.google.com (mail-qk1-x72d.google.com [IPv6:2607:f8b0:4864:20::72d]) (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 53AF9130F0F for ; Tue, 12 Mar 2019 02:42:39 -0700 (PDT) Received: by mail-qk1-x72d.google.com with SMTP id i5so975348qkd.13 for ; Tue, 12 Mar 2019 02:42:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=raszuk.net; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=j+OiwG7Oc1Ae+hVb3zZbh25r6Uc2thQRHQd4VOUpgvw=; b=Ag4qwHU0yEDWfdfadzRrEFe0EMWMIq+fwfZBpGngR1VCYMRrqJx56vV4zzPWxLSvQf 2yBI0r1ZuC7pmVat+9bIHToUwG+MNma5bim7a6jRrPIAI7kBOcn7M1GfkrCNtg3vLZQU lF41odztBpmGh+toPiDvla635FQHL131IBpli88acHFQjgIJpwoQpLLk/ZfifrUgWbSs I3PJdTwBlEeA8NwG73s/j3YDqDJZWoUHs683YncKSxroWXa1aVQmktLp5ZOqlbeIftPI z1DQxXWqyGItVtMMXjxPnPnA4J7UwQ1YkSfWiYTiS/ks8ObTXp/QqAQVQumLajGAw6Ms cN9g== 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=j+OiwG7Oc1Ae+hVb3zZbh25r6Uc2thQRHQd4VOUpgvw=; b=TqxzlChAUZvkry6977artQ7LbtRRRVVYmKRFc+U8DbW2lqKe2151nstUSf0+vHhHvy gnuGwnkebShtYUCw+KZ7zdQLKi/vO/dlnwfG+UFv+OoJconLMoLr2aQP1ePtydvDBBxm FmQveNRjGf7qOKyrCeC6tGhSsZSoQTon9I7hN65kE5buEpRNPhRCgmwlrXK/wDDvbyyo nRo+8KaCM7mq1M9zGRvjcjBl9HHWfaJVlGeP8zLKx7/mtT9BaLTCBtJXAauYeAk3rMn6 Jc4qcMM9vw4+YbZm8YbsMXcgc68+fxrIaOi7TIjR22ewEEumdWF87qXhIP6Vwur5rs/8 fr1g== X-Gm-Message-State: APjAAAXuaq3YpEWprmzxYPbFvoZo+BEAkNCM50KjOQhO0+5WDLYAe//e h+RLRXv2Q6hc5WwOZWK6Zq20/um04pxYF33U3sV7gw== X-Google-Smtp-Source: APXvYqx5W2uuIrx3riCU/5p/A4O5yqWoApnkwHyGBQMsTjSPmos20qZCYpbaHj1RMVyIO1FwXLOW2Pc6WYTitXbzKwo= X-Received: by 2002:a37:6082:: with SMTP id u124mr15939198qkb.189.1552383758327; Tue, 12 Mar 2019 02:42:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Robert Raszuk Date: Tue, 12 Mar 2019 10:42:28 +0100 Message-ID: To: Peter Psenak , Jeff Tantsura , "Les Ginsberg (ginsberg)" Cc: lsr@ietf.org Content-Type: multipart/alternative; boundary="0000000000007878c70583e28231" Archived-At: Subject: Re: [Lsr] Temporary addition of links to flooding topology in dynamic flooding X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 09:42:47 -0000 --0000000000007878c70583e28231 Content-Type: text/plain; charset="UTF-8" Jeff & Les, The suggested use of "LFA" was completely unrelated to ECMP or to data plane. I realize that some people may just think of LFA in its original meaning :). It was just a hint how an edge node can determine which links are "towards" the disconnected nodes and which of his local links would be going in the opposite direction just by running SPF virtually putting as initial node your adjacent FT nodes. No more no less. Per section 6.7.9 it seems that implementation is already mandated ot find such links towards the disconnected part of the network, but it does not seems to indicate how. Maybe it is just a matter of local smart implementation. Peter, If I am reading your reply and section 6.7.5 it seems to indicate that you would not start adding any link to FT as long as you have at least one there still being alive. You just advertise new LSA/LSP over still active flooding link indicating change in topology and sit and wait till you get a new FT ? Well perhaps wrong, but my understanding was that if you have two active FT links you start adding new ones (and request your peer over that link to do so too) just after you loose one as a temporary patch till you get a new graph. So what happens when you loose one link and you do not get a new FT for time t. How long do you wait ? Many thx, R. On Tue, Mar 12, 2019 at 7:45 AM Peter Psenak wrote: > Hi Robert, > > On 11/03/2019 22:28 , Robert Raszuk wrote: > > Hi, > > > > As of now at the event of failure of any of the FT enabled link > > additional links are being added in more or less random fashion by nodes > > directly connected to the failed links. > > above statement is incorrect. It is absolutely NOT TRUE that "at the > event of failure of any of the FT enabled link additional links are > being added". > > Temporary additions of the links to the FT has its strict rules: > > 6.7.5. Failures of Link On the Flooding Topology > > "If the failed local link represented the only connection to the > flooding topology on the node where the link failed, the node MUST > enable temporary flooding on a subset of its local links." > > 6.7.9. Treatment of Disconnected Adjacent Nodes > > Every time there is a change in the flooding topology a node MUST > check if there are any adjacent nodes that are disconnected from the > current flooding topology. Temporary flooding MUST be enabled > towards a subset of the disconnected nodes. > > > So we are only performing temporary flooding if either we or one of our > neighbors got isolated from the FT, which given the bi-connectivity of > the FT itself is an unlikely event. > > thanks, > Peter > > > > > In the event of 100s of links on such nodes and advisable rate limiting > > addition of those links it seems that repair of FT may take some time. > > > > In order to reduce such time interval better then random addition of > > remaining links seems recommended. How about we hint participating nodes > > to execute purely in control plane of FT an LFA algorithm for possible > > future event of active link failure and use results of the LFA > > computation to prioritize links which will be first temporary additions > > upon active flooding links failures ? > > > > Such optimization is local and optional and does not require any changes > > to proposed protocol signalling. > > > > _Therefor how about just one sentence addition to section 6.7.1 > > of draft-ietf-lsr-dynamic-flooding:_ > > > > /Temporary additions of links to flooding topology could be more > > educated if given node runs a pure control plane LFA ahead of any FT > > failure on active FT links completely detached from potential LFA runs > > for data plane topology. / > > > > Kind regards, > > R. > > / > > / > > > > > > _______________________________________________ > > Lsr mailing list > > Lsr@ietf.org > > https://www.ietf.org/mailman/listinfo/lsr > > > > --0000000000007878c70583e28231 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Jeff & Les,

The suggested use of &q= uot;LFA" was completely unrelated to ECMP or to data plane. I realize = that some people may just think of LFA in its original meaning :).=C2=A0

It was just a hint how an edge node can determine wh= ich links are "towards" the disconnected nodes and which of his l= ocal links would be going in the opposite direction just by running SPF vir= tually putting as initial node your adjacent FT nodes. No more no less.=C2= =A0

Per section 6.7.9 it seems that implementation= is already mandated ot find such links towards the disconnected part of th= e network, but it does not seems to indicate how. Maybe it is just a matter= of local smart implementation.=C2=A0

Peter,
=

If I am reading your reply and section 6.7.5 it seems t= o indicate that you would not start adding any link to FT as long as you ha= ve at least one there still being alive. You just advertise new LSA/LSP ove= r still active flooding link indicating change in topology and sit and wait= till you get a new FT ?

Well perhaps wrong, but m= y understanding was that if you have two active FT links you start adding n= ew ones (and request your peer over that link to do so too) just after you = loose one as a temporary patch till you get a new graph.

So what happens when you loose one link and you do not get a new FT = for time t. How long do you wait ?=C2=A0

Many thx,=
R.



On Tue, Mar 12, 2019 at 7:= 45 AM Peter Psenak <ppsenak@cisco.c= om> wrote:
Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>

--0000000000007878c70583e28231-- From nobody Tue Mar 12 04:09:51 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3079B127968 for ; Tue, 12 Mar 2019 04:09:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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 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 frBNwasgSZd5 for ; Tue, 12 Mar 2019 04:09:48 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB883126E5C for ; Tue, 12 Mar 2019 04:09:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4765; q=dns/txt; s=iport; t=1552388988; x=1553598588; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=f1PP6lOL7QmJ5wn5msivAIFh52oq4WZ/Yn6DdHaGZNg=; b=Ie3+RiW5CJFhDB3PpMWlKV1k/IIyz5ZEO6kaSeODd3ebJimjm5ca361C /NUqMtNzwLR/EgxLB1Y5AX5OMLiuMsqAARCiIUSznzs2XcoF1PMfXmADY pyWxrSNY1YOaftNrhW6dt1LREw5Ck1ej06nD2smcqmJPHMjtJJbTadRNz 8=; X-IronPort-AV: E=Sophos;i="5.58,471,1544486400"; d="scan'208";a="10691281" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 12 Mar 2019 11:09:46 +0000 Received: from [10.147.24.38] ([10.147.24.38]) by aer-core-1.cisco.com (8.15.2/8.15.2) with ESMTP id x2CB9jO9003284; Tue, 12 Mar 2019 11:09:45 GMT To: Robert Raszuk , Jeff Tantsura , "Les Ginsberg (ginsberg)" References: Cc: lsr@ietf.org From: Peter Psenak Message-ID: <0e8b3753-7263-900d-7d6c-e103c25b5689@cisco.com> Date: Tue, 12 Mar 2019 12:09:45 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Outbound-SMTP-Client: 10.147.24.38, [10.147.24.38] X-Outbound-Node: aer-core-1.cisco.com Archived-At: Subject: Re: [Lsr] Temporary addition of links to flooding topology in dynamic flooding X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Mar 2019 11:09:50 -0000 Robert, On 12/03/2019 10:42 , Robert Raszuk wrote: > Jeff & Les, > > The suggested use of "LFA" was completely unrelated to ECMP or to data > plane. I realize that some people may just think of LFA in its original > meaning :). > > It was just a hint how an edge node can determine which links are > "towards" the disconnected nodes and which of his local links would be > going in the opposite direction just by running SPF virtually putting as > initial node your adjacent FT nodes. No more no less. > > Per section 6.7.9 it seems that implementation is already mandated ot > find such links towards the disconnected part of the network, but it > does not seems to indicate how. Maybe it is just a matter of local smart > implementation. > > Peter, > > If I am reading your reply and section 6.7.5 it seems to indicate that > you would not start adding any link to FT as long as you have at least > one there still being alive. You just advertise new LSA/LSP over still > active flooding link indicating change in topology and sit and wait till > you get a new FT ? > > Well perhaps wrong, but my understanding was that if you have two active > FT links you start adding new ones (and request your peer over that link > to do so too) just after you loose one as a temporary patch till you get > a new graph. > > So what happens when you loose one link and you do not get a new FT for > time t. How long do you wait ? when the local link that is on FT is lost, the FT is recalculated, either locally, or centrally and flooded. That should provide bi-connectivity again, if available. Temporary flooding is only triggered when node itself or its neighbor becomes isolated. thanks, Peter > > Many thx, > R. > > > > On Tue, Mar 12, 2019 at 7:45 AM Peter Psenak > wrote: > > Hi Robert, > > On 11/03/2019 22:28 , Robert Raszuk wrote: > > Hi, > > > > As of now at the event of failure of any of the FT enabled link > > additional links are being added in more or less random fashion by > nodes > > directly connected to the failed links. > > above statement is incorrect. It is absolutely NOT TRUE that "at the > event of failure of any of the FT enabled link additional links are > being added". > > Temporary additions of the links to the FT has its strict rules: > > 6.7.5. Failures of Link On the Flooding Topology > > "If the failed local link represented the only connection to the > flooding topology on the node where the link failed, the node MUST > enable temporary flooding on a subset of its local links." > > 6.7.9. Treatment of Disconnected Adjacent Nodes > > Every time there is a change in the flooding topology a node MUST > check if there are any adjacent nodes that are disconnected from the > current flooding topology. Temporary flooding MUST be enabled > towards a subset of the disconnected nodes. > > > So we are only performing temporary flooding if either we or one of our > neighbors got isolated from the FT, which given the bi-connectivity of > the FT itself is an unlikely event. > > thanks, > Peter > > > > > In the event of 100s of links on such nodes and advisable rate > limiting > > addition of those links it seems that repair of FT may take some time. > > > > In order to reduce such time interval better then random addition of > > remaining links seems recommended. How about we hint participating > nodes > > to execute purely in control plane of FT an LFA algorithm for possible > > future event of active link failure and use results of the LFA > > computation to prioritize links which will be first temporary > additions > > upon active flooding links failures ? > > > > Such optimization is local and optional and does not require any > changes > > to proposed protocol signalling. > > > > _Therefor how about just one sentence addition to section 6.7.1 > > of draft-ietf-lsr-dynamic-flooding:_ > > > > /Temporary additions of links to flooding topology could be more > > educated if given node runs a pure control plane LFA ahead of any FT > > failure on active FT links completely detached from potential LFA runs > > for data plane topology. / > > > > Kind regards, > > R. > > / > > / > > > > > > _______________________________________________ > > Lsr mailing list > > Lsr@ietf.org > > https://www.ietf.org/mailman/listinfo/lsr > > > From nobody Fri Mar 15 16:07:51 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9068131320; Fri, 15 Mar 2019 16:07:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_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 9CnXenPPlSqM; Fri, 15 Mar 2019 16:07:33 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6080013130B; Fri, 15 Mar 2019 16:07:33 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 67AF9B826AF; Fri, 15 Mar 2019 16:07:28 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Cc: rfc-editor@rfc-editor.org, drafts-update-ref@iana.org, lsr@ietf.org Content-type: text/plain; charset=UTF-8 Message-Id: <20190315230728.67AF9B826AF@rfc-editor.org> Date: Fri, 15 Mar 2019 16:07:28 -0700 (PDT) Archived-At: Subject: [Lsr] =?utf-8?q?RFC_8570_on_IS-IS_Traffic_Engineering_=28TE=29_M?= =?utf-8?q?etric_Extensions?= X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Mar 2019 23:07:40 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8570 Title: IS-IS Traffic Engineering (TE) Metric Extensions Author: L. Ginsberg, Ed., S. Previdi, Ed., S. Giacalone, D. Ward, J. Drake, Q. Wu Status: Standards Track Stream: IETF Date: March 2019 Mailbox: ginsberg@cisco.com, stefano@previdi.net, spencer.giacalone@gmail.com, wardd@cisco.com, jdrake@juniper.net, bill.wu@huawei.com Pages: 21 Characters: 38620 Obsoletes: RFC 7810 I-D Tag: draft-ietf-lsr-isis-rfc7810bis-05.txt URL: https://www.rfc-editor.org/info/rfc8570 DOI: 10.17487/RFC8570 In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network-performance criteria (e.g., latency) are becoming as critical to data-path selection as other metrics. This document describes extensions to IS-IS Traffic Engineering Extensions (RFC 5305). These extensions provide a way to distribute and collect network-performance information in a scalable fashion. The information distributed using IS-IS TE Metric Extensions can then be used to make path-selection decisions based on network performance. Note that this document only covers the mechanisms with which network-performance information is distributed. The mechanisms for measuring network performance or acting on that information, once distributed, are outside the scope of this document. This document obsoletes RFC 7810. This document is a product of the Link State Routing Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Tue Mar 19 07:17:33 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FE6F1312FF for ; Tue, 19 Mar 2019 07:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=K1lOyYFO; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ZwApjufB 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 Ce7glmx3kvOp for ; Tue, 19 Mar 2019 07:17:21 -0700 (PDT) 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 39846131311 for ; Tue, 19 Mar 2019 07:17:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5519; q=dns/txt; s=iport; t=1553005041; x=1554214641; h=from:to:cc:subject:date:message-id:mime-version; bh=9yXqWJ1AOFD8zp6Qk7OiHB2siJH5ACAViZMgnBLlwUo=; b=K1lOyYFOHFROZRjXiZKh/DKUUg+6e69ESyOiAr8IMsl+SjKmmocOK5XZ 0UpXXaNpejVdJ6lIduNBaptV1ty2lPSbvrAtLoq2kVTO/RN3FezJ5Sxnd h5eZHfe/F4QDuBKuLEhCgjOpOIaf/2jK44PC1Z6pR54pIxbBBuEdw+LaD c=; IronPort-PHdr: =?us-ascii?q?9a23=3ARM7F1RA9xgH0R6ruwMrwUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qgw3kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMdRXUg?= =?us-ascii?q?Mdz8AfngguGsmAXETwIfPCZC0hF8MEX1hgrDm2?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AKAABN+ZBc/5hdJa1jGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUwMBAQEBCwGBDi9QA2h0BAsUEwqEAYNHA48ylROESIEuFIE?= =?us-ascii?q?QA1QLAQEshEAZhFQiNgcNAQEDAQEJAQMCbRwMhXQdAQEsBgUBEQEMPgIEMCc?= =?us-ascii?q?EAQ2DJwGBEUwDFQECnnUCihRxgS+CeAEBBYJHgkkYggwIgS8BizAXgX+BECg?= =?us-ascii?q?fhxoBEgE2gnMxgiaKH4JEhBaTcwkCkyoZgXyFcotwijkJSpMDAgQCBAUCDgE?= =?us-ascii?q?BBYFOAy5lcXAVOyoBgkGCCoNuilNygSiGT4EfAYEeAQE?= X-IronPort-AV: E=Sophos;i="5.58,498,1544486400"; d="scan'208,217";a="246978256" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Mar 2019 14:17:20 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x2JEHKdQ018189 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 19 Mar 2019 14:17:20 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 19 Mar 2019 09:17:19 -0500 Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 19 Mar 2019 10:17:18 -0400 Received: from NAM01-BN3-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 19 Mar 2019 09:17:18 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9yXqWJ1AOFD8zp6Qk7OiHB2siJH5ACAViZMgnBLlwUo=; b=ZwApjufBMJVQNo4z2LJI+SUIAKogexmId3Q/aeFCxfaZmhxnG9aFpyMdWXHThqdGFN+aF7eCGD4yns3Tmly8C5zLIRK8nNUVoUOxs0w7CAgQsGiUwsjGnCZTfYcsKaPMV2KacDfo7GEJczF4z5DZAOceCpz0Cs2qpn46XTHROWY= Received: from BN8PR11MB3683.namprd11.prod.outlook.com (20.178.220.74) by BN8PR11MB3619.namprd11.prod.outlook.com (20.178.219.86) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.14; Tue, 19 Mar 2019 14:17:17 +0000 Received: from BN8PR11MB3683.namprd11.prod.outlook.com ([fe80::c62:f0b7:72a0:e853]) by BN8PR11MB3683.namprd11.prod.outlook.com ([fe80::c62:f0b7:72a0:e853%4]) with mapi id 15.20.1709.015; Tue, 19 Mar 2019 14:17:17 +0000 From: "Acee Lindem (acee)" To: "Les Ginsberg (ginsberg)" , "Paul Wells (pauwells)" CC: "lsr@ietf.org" Thread-Topic: IPR Poll for "Restart Signaling for IS-IS" - draft-ietf-lsr-isis-rfc5306bis-01 Thread-Index: AQHU3l50hqrJxqfle0iO1VKqn84gUQ== Date: Tue, 19 Mar 2019 14:17:16 +0000 Message-ID: <365ADAE0-039A-44F3-B2E1-5687DD6C4623@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=acee@cisco.com; x-originating-ip: [173.38.117.93] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 1d18a593-5861-4a9d-5f88-08d6ac75976f x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BN8PR11MB3619; x-ms-traffictypediagnostic: BN8PR11MB3619: x-ld-processed: 5ae1af62-9505-4097-a69a-c1553ef7840e,ExtAddr x-microsoft-antispam-prvs: x-forefront-prvs: 0981815F2F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(376002)(346002)(39860400002)(136003)(366004)(189003)(199004)(82746002)(106356001)(4744005)(68736007)(86362001)(105586002)(478600001)(33656002)(97736004)(6636002)(256004)(316002)(110136005)(2906002)(81156014)(85306007)(8936002)(8676002)(486006)(81166006)(25786009)(6436002)(83716004)(71190400001)(476003)(66066001)(186003)(4326008)(102836004)(5660300002)(71200400001)(36756003)(6506007)(6306002)(6512007)(26005)(53936002)(14454004)(99286004)(54896002)(6486002)(3846002)(2616005)(7736002)(6116002); DIR:OUT; SFP:1101; SCL:1; SRVR:BN8PR11MB3619; H:BN8PR11MB3683.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: qf5Fxcr4YXq5DUqF3V4qSUh6X2hltuDg59dI9smSWG/Bah6y4aHo5xplRrW3Hft1MVIdPnN7Rvmmq6zr3QbLntose4m7OHFdTbrX5ta0xsFkTFaiCgFh6i66vYj+IF0frUldBldnK47RWF+XAH+6fvPw/x1FraPYaq9ZNakmmfHRvsVg4Vem948AXlyL/J8iP3b1GKe2EPLXw30D1D53bRY+vt3TUdV3QAMqEe1q1GyEQZ1Nxf/wGelIUG/1NCg1CBcqz7otzEJ+5k6B5xOn82S2gU86JJbZXbJn7IiTFORz55VeEOvItmUCvOn6WBvdL3QGgzOkY5n7gS0RRO26FeUhJ6mPKryIJRlGPqDuv0bnEsZW4QnhCu146FZHJ39WLD1uflg2oodIcRcSiswrjVaoobaIZ/zM9O5jJhrWcAo= Content-Type: multipart/alternative; boundary="_000_365ADAE0039A44F3B2E15687DD6C4623ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 1d18a593-5861-4a9d-5f88-08d6ac75976f X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Mar 2019 14:17:16.9692 (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-Transport-CrossTenantHeadersStamped: BN8PR11MB3619 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.17, xch-rcd-007.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: [Lsr] IPR Poll for "Restart Signaling for IS-IS" - draft-ietf-lsr-isis-rfc5306bis-01 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2019 14:17:32 -0000 --_000_365ADAE0039A44F3B2E15687DD6C4623ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgTGVzLCBQYXVsLA0KDQpJbiBwcmVwYXJhdGlvbiBmb3IgV0cgbGFzdCBjYWxsLCBJ4oCZZCBs aWtlIHRvIGFzayBvbmUgbW9yZSB0aW1lIGlmIHlvdSBrbm93IG9mIGFueSBJUFIgYXNzb2NpYXRl ZCB3aXRoIHRoaXMgZHJhZnQ/DQoNCklmIHNvLCBoYXMgdGhpcyBJUFIgYmVlbiBkaXNjbG9zZWQg aW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzIChzZWUgUkZDcyAzOTc5LCA0ODc5LCAz NjY5IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMpLg0KSWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBk b2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0b3IgcGxlYXNlIHJlc3BvbmQgdG8gdGhpcyBlbWFp bCByZWdhcmRsZXNzIG9mIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUgYXdhcmUgb2YgYW55IHJlbGV2 YW50IElQUi4gKlRoZSByZXNwb25zZSBuZWVkcyB0byBiZSBzZW50IHRvIHRoZSBMU1IgV0cgbWFp bGluZyBsaXN0LiogVGhlIGRvY3VtZW50IHdpbGwgbm90IGFkdmFuY2UgdG8gdGhlIG5leHQgc3Rh Z2UgdW50aWwgYSByZXNwb25zZSBoYXMgYmVlbiByZWNlaXZlZCBmcm9tIGVhY2ggYXV0aG9yIGFu ZCBjb250cmlidXRvci4NCklmIHlvdSBhcmUgb24gdGhlIExTUiBXRyBlbWFpbCBsaXN0IGJ1dCBh cmUgbm90IGxpc3RlZCBhcyBhbiBhdXRob3Igb3IgY29udHJpYnV0b3IsIHRoZW4gcGxlYXNlIGV4 cGxpY2l0bHkgcmVzcG9uZCBvbmx5IGlmIHlvdSBhcmUgYXdhcmUgb2YgYW55IElQUiB0aGF0IGhh cyBub3QgeWV0IGJlZW4gZGlzY2xvc2VkIGluIGNvbmZvcm1hbmNlIHdpdGggSUVURiBydWxlcy4N Cg0KVGhhbmtzLA0KQWNlZQ0K --_000_365ADAE0039A44F3B2E15687DD6C4623ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <2C65CD661B42904BBEAA5A080598B243@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij5IaSBMZXMsIFBhdWwsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij5JbiBwcmVwYXJhdGlvbiBmb3IgV0cgbGFzdCBjYWxsLCBJ4oCZZCBsaWtlIHRv IGFzayBvbmUgbW9yZSB0aW1lIGlmIHlvdSBrbm93IG9mIGFueSBJUFIgYXNzb2NpYXRlZCB3aXRo IHRoaXMgZHJhZnQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5J ZiBzbywgaGFzIHRoaXMgSVBSIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRG IElQUiBydWxlcyAoc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBmb3IgbW9yZSBk ZXRhaWxzKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SWYgeW91IGFyZSBsaXN0ZWQgYXMgYSBkb2N1bWVu dCBhdXRob3Igb3IgY29udHJpYnV0b3IgcGxlYXNlIHJlc3BvbmQgdG8gdGhpcyBlbWFpbCByZWdh cmRsZXNzIG9mIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQ Ui4gKlRoZSByZXNwb25zZSBuZWVkcyB0byBiZSBzZW50IHRvIHRoZSBMU1IgV0cgbWFpbGluZyBs aXN0LioNCiBUaGUgZG9jdW1lbnQgd2lsbCBub3QgYWR2YW5jZSB0byB0aGUgbmV4dCBzdGFnZSB1 bnRpbCBhIHJlc3BvbnNlIGhhcyBiZWVuIHJlY2VpdmVkIGZyb20gZWFjaCBhdXRob3IgYW5kIGNv bnRyaWJ1dG9yLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JZiB5b3UgYXJlIG9uIHRoZSBMU1IgV0cgZW1h aWwgbGlzdCBidXQgYXJlIG5vdCBsaXN0ZWQgYXMgYW4gYXV0aG9yIG9yIGNvbnRyaWJ1dG9yLCB0 aGVuIHBsZWFzZSBleHBsaWNpdGx5IHJlc3BvbmQgb25seSBpZiB5b3UgYXJlIGF3YXJlIG9mIGFu eSBJUFIgdGhhdCBoYXMgbm90IHlldCBiZWVuIGRpc2Nsb3NlZCBpbiBjb25mb3JtYW5jZSB3aXRo IElFVEYNCiBydWxlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi PlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+QWNlZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_365ADAE0039A44F3B2E15687DD6C4623ciscocom_-- From nobody Tue Mar 19 07:24:46 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5278C131307 for ; Tue, 19 Mar 2019 07:24:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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=bJJNo2kL; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=e8XFt9f2 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 ivl3lhIDREZK for ; Tue, 19 Mar 2019 07:24:41 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CFD7131306 for ; Tue, 19 Mar 2019 07:24:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8370; q=dns/txt; s=iport; t=1553005481; x=1554215081; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=9kp74k8O3hz4RAeG5NEIK9Tn7ydiNHl9DS61e7H8Xbc=; b=bJJNo2kLczHpfi9WkMB2xeQZhjUjLajT3VPDY3xD+Ldpo6Rk15ZEvcmP tBlzCV5brHqByaVxKFEJSNvCtl/bNCQBbMjq3kMR+cki0DLqZdiol1Y+n 9LGowDkG7KCTStt/VbQjZ/04eCdrrwieMWptDVUrJlVsRn+Bnrz9HweCY w=; IronPort-PHdr: =?us-ascii?q?9a23=3AF/J2thN/mhDCoZN0I5cl6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEu6w/l0fHCIPc7f8My/HbtaztQyQh2d6AqzhDFf4ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBj0LfjxZSEgE+xJVURu+DewNk0GUMs=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAAD1+pBc/4kNJK1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUwIBAQEBAQsBgQ4vUANodAQLFBOEC4NHA48ygleSPIR?= =?us-ascii?q?IgS4UgRADVAsBASyEQAIXhFQiNgcNAQEDAQEJAQMCbRwMhUoBAQEBAyMKEwE?= =?us-ascii?q?BLAYFAQ8CAQgRBAEBKwICAjAdCAIEAQ0FCIMbgRFMAxUBAp5+AooUcYEvgng?= =?us-ascii?q?BAQWFEBiCDAiBLwGLMBeBQD+BEEeCTIROARIBIRUPgmQxgiaKH4JEhBaTcwk?= =?us-ascii?q?Ck0OBfIVyi3CKOQlKkwMCBAIEBQIOAQEFgU4CL2VxcBU7gmyCCjaDOIpTcoE?= =?us-ascii?q?ohk+CPgEB?= X-IronPort-AV: E=Sophos;i="5.58,498,1544486400"; d="scan'208,217";a="537080840" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Mar 2019 14:24:39 +0000 Received: from XCH-RCD-005.cisco.com (xch-rcd-005.cisco.com [173.37.102.15]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x2JEOd8d010745 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 19 Mar 2019 14:24:39 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-005.cisco.com (173.37.102.15) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 19 Mar 2019 09:24:38 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 19 Mar 2019 10:24:38 -0400 Received: from NAM01-BN3-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.1473.3 via Frontend Transport; Tue, 19 Mar 2019 09:24:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9kp74k8O3hz4RAeG5NEIK9Tn7ydiNHl9DS61e7H8Xbc=; b=e8XFt9f27jxNYDZzK4eCsdqogrUfig8ore+nhlnVkvgzmiW3F1US14mcn8/HSvuAstbonejR9k0X2WQRN6UVdKljGZVT2FfmX1AME9wGfN1wNVYZkeV/cJdabjvYSka4dkM5EOVexi7c17TELCgWd79OHu3HZ+Rzjqx11zvXAvU= Received: from BYAPR11MB3638.namprd11.prod.outlook.com (20.178.237.19) by BYAPR11MB2951.namprd11.prod.outlook.com (20.177.224.10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.14; Tue, 19 Mar 2019 14:24:36 +0000 Received: from BYAPR11MB3638.namprd11.prod.outlook.com ([fe80::b414:f534:f20a:a26d]) by BYAPR11MB3638.namprd11.prod.outlook.com ([fe80::b414:f534:f20a:a26d%3]) with mapi id 15.20.1709.015; Tue, 19 Mar 2019 14:24:36 +0000 From: "Les Ginsberg (ginsberg)" To: "Acee Lindem (acee)" , "Paul Wells (pauwells)" CC: "lsr@ietf.org" Thread-Topic: IPR Poll for "Restart Signaling for IS-IS" - draft-ietf-lsr-isis-rfc5306bis-01 Thread-Index: AQHU3l50hqrJxqfle0iO1VKqn84gUaYTAhRA Date: Tue, 19 Mar 2019 14:24:36 +0000 Message-ID: References: <365ADAE0-039A-44F3-B2E1-5687DD6C4623@cisco.com> In-Reply-To: <365ADAE0-039A-44F3-B2E1-5687DD6C4623@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ginsberg@cisco.com; x-originating-ip: [2001:420:c0c8:1003::3f] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 55a9d44d-250b-42f0-447f-08d6ac769d90 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BYAPR11MB2951; x-ms-traffictypediagnostic: BYAPR11MB2951: x-ld-processed: 5ae1af62-9505-4097-a69a-c1553ef7840e,ExtAddr x-microsoft-antispam-prvs: x-forefront-prvs: 0981815F2F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(376002)(346002)(136003)(396003)(39860400002)(189003)(199004)(33656002)(486006)(106356001)(105586002)(14454004)(4326008)(81156014)(110136005)(52536014)(102836004)(478600001)(81166006)(53546011)(11346002)(25786009)(99286004)(476003)(446003)(186003)(6506007)(8676002)(7736002)(6436002)(229853002)(71190400001)(68736007)(71200400001)(9686003)(46003)(97736004)(6246003)(6306002)(6116002)(54896002)(55016002)(8936002)(2906002)(316002)(74316002)(7696005)(790700001)(86362001)(5660300002)(76176011)(6636002)(256004)(53936002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB2951; H:BYAPR11MB3638.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 6NtKCCBDuEu90tMuIMJXOqJxGyGnISFOtLyusJN7s5A6LrrzIjvhpCAmOtBjB4lqmtDLhcKgPXZO7HmnEvOMJHWbNYNQQhbmMTUx0dbecSR7HqeMZExJWWBVUtGuFVTWUUh/9NDAZkeBP1yL3k08C5gn1KS3AjNlGDk1Z+BWGufWEEchJsfUtlOhAb01dPQyMVuwU53sZies+5b03HKF7H+JbofkGYr7jY5xRkk4x/5xWCWybtH8XSzVDi9Q4NYitOHL+ZvaRSrGhwOgY/4yRDiXg2HvmAd7za3eEkLwOdMtlHPTidebWAc+/HAMnIucTR23oOIWegQa6tggKdRn/ht/+T7eOmLRXrqYyqZUU3qtvT3jKtgiKifSUZOiiXVsY4v7iHI/BvwZ6Dg170EElbYyYzxiE40jR0HsaJVSvXg= Content-Type: multipart/alternative; boundary="_000_BYAPR11MB3638BDA8D8A65FF2F9D73C81C1400BYAPR11MB3638namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 55a9d44d-250b-42f0-447f-08d6ac769d90 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Mar 2019 14:24:36.7088 (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-Transport-CrossTenantHeadersStamped: BYAPR11MB2951 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.15, xch-rcd-005.cisco.com X-Outbound-Node: alln-core-4.cisco.com Archived-At: Subject: Re: [Lsr] IPR Poll for "Restart Signaling for IS-IS" - draft-ietf-lsr-isis-rfc5306bis-01 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2019 14:24:45 -0000 --_000_BYAPR11MB3638BDA8D8A65FF2F9D73C81C1400BYAPR11MB3638namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBhbSBub3QgYXdhcmUgb2YgYW55IHJlbGV2YW50IElQUi4NCg0KICAgTGVzDQoNCg0KRnJvbTog QWNlZSBMaW5kZW0gKGFjZWUpDQpTZW50OiBUdWVzZGF5LCBNYXJjaCAxOSwgMjAxOSA3OjE3IEFN DQpUbzogTGVzIEdpbnNiZXJnIChnaW5zYmVyZykgPGdpbnNiZXJnQGNpc2NvLmNvbT47IFBhdWwg V2VsbHMgKHBhdXdlbGxzKSA8cGF1d2VsbHNAY2lzY28uY29tPg0KQ2M6IGxzckBpZXRmLm9yZw0K U3ViamVjdDogSVBSIFBvbGwgZm9yICJSZXN0YXJ0IFNpZ25hbGluZyBmb3IgSVMtSVMiIC0gZHJh ZnQtaWV0Zi1sc3ItaXNpcy1yZmM1MzA2YmlzLTAxDQoNCkhpIExlcywgUGF1bCwNCg0KSW4gcHJl cGFyYXRpb24gZm9yIFdHIGxhc3QgY2FsbCwgSeKAmWQgbGlrZSB0byBhc2sgb25lIG1vcmUgdGlt ZSBpZiB5b3Uga25vdyBvZiBhbnkgSVBSIGFzc29jaWF0ZWQgd2l0aCB0aGlzIGRyYWZ0Pw0KDQpJ ZiBzbywgaGFzIHRoaXMgSVBSIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRG IElQUiBydWxlcyAoc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBmb3IgbW9yZSBk ZXRhaWxzKS4NCklmIHlvdSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9yIG9yIGNvbnRy aWJ1dG9yIHBsZWFzZSByZXNwb25kIHRvIHRoaXMgZW1haWwgcmVnYXJkbGVzcyBvZiB3aGV0aGVy IG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueSByZWxldmFudCBJUFIuICpUaGUgcmVzcG9uc2Ug bmVlZHMgdG8gYmUgc2VudCB0byB0aGUgTFNSIFdHIG1haWxpbmcgbGlzdC4qIFRoZSBkb2N1bWVu dCB3aWxsIG5vdCBhZHZhbmNlIHRvIHRoZSBuZXh0IHN0YWdlIHVudGlsIGEgcmVzcG9uc2UgaGFz IGJlZW4gcmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBhbmQgY29udHJpYnV0b3IuDQpJZiB5b3Ug YXJlIG9uIHRoZSBMU1IgV0cgZW1haWwgbGlzdCBidXQgYXJlIG5vdCBsaXN0ZWQgYXMgYW4gYXV0 aG9yIG9yIGNvbnRyaWJ1dG9yLCB0aGVuIHBsZWFzZSBleHBsaWNpdGx5IHJlc3BvbmQgb25seSBp ZiB5b3UgYXJlIGF3YXJlIG9mIGFueSBJUFIgdGhhdCBoYXMgbm90IHlldCBiZWVuIGRpc2Nsb3Nl ZCBpbiBjb25mb3JtYW5jZSB3aXRoIElFVEYgcnVsZXMuDQoNClRoYW5rcywNCkFjZWUNCg== --_000_BYAPR11MB3638BDA8D8A65FF2F9D73C81C1400BYAPR11MB3638namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjoj OTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5t c29ub3JtYWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJ bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsN Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUx OA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTE5DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6 ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9 IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj5JIGFtIG5vdCBhd2FyZSBvZiBhbnkgcmVsZXZhbnQg SVBSLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0O2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZuYnNwOyBMZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xv cjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMS4wcHQiPiBBY2VlIExpbmRlbSAoYWNlZSkNCjxicj4NCjxiPlNlbnQ6PC9iPiBUdWVz ZGF5LCBNYXJjaCAxOSwgMjAxOSA3OjE3IEFNPGJyPg0KPGI+VG86PC9iPiBMZXMgR2luc2Jlcmcg KGdpbnNiZXJnKSAmbHQ7Z2luc2JlcmdAY2lzY28uY29tJmd0OzsgUGF1bCBXZWxscyAocGF1d2Vs bHMpICZsdDtwYXV3ZWxsc0BjaXNjby5jb20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBsc3JAaWV0Zi5v cmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gSVBSIFBvbGwgZm9yICZxdW90O1Jlc3RhcnQgU2lnbmFs aW5nIGZvciBJUy1JUyZxdW90OyAtIGRyYWZ0LWlldGYtbHNyLWlzaXMtcmZjNTMwNmJpcy0wMTxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij5IaSBMZXMsIFBhdWwsPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij5JbiBwcmVwYXJhdGlvbiBmb3IgV0cgbGFzdCBjYWxsLCBJ4oCZ ZCBsaWtlIHRvIGFzayBvbmUgbW9yZSB0aW1lIGlmIHlvdSBrbm93IG9mIGFueSBJUFIgYXNzb2Np YXRlZCB3aXRoIHRoaXMgZHJhZnQ/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0Ij5JZiBzbywgaGFzIHRoaXMgSVBSIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ug d2l0aCBJRVRGIElQUiBydWxlcyAoc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBm b3IgbW9yZSBkZXRhaWxzKS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+SWYgeW91IGFyZSBsaXN0ZWQgYXMg YSBkb2N1bWVudCBhdXRob3Igb3IgY29udHJpYnV0b3IgcGxlYXNlIHJlc3BvbmQgdG8gdGhpcyBl bWFpbCByZWdhcmRsZXNzIG9mIHdoZXRoZXIgb3Igbm90IHlvdSBhcmUgYXdhcmUgb2YgYW55IHJl bGV2YW50IElQUi4gKlRoZSByZXNwb25zZSBuZWVkcyB0byBiZSBzZW50IHRvIHRoZSBMU1IgV0cg bWFpbGluZyBsaXN0LioNCiBUaGUgZG9jdW1lbnQgd2lsbCBub3QgYWR2YW5jZSB0byB0aGUgbmV4 dCBzdGFnZSB1bnRpbCBhIHJlc3BvbnNlIGhhcyBiZWVuIHJlY2VpdmVkIGZyb20gZWFjaCBhdXRo b3IgYW5kIGNvbnRyaWJ1dG9yLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JZiB5b3UgYXJlIG9uIHRoZSBM U1IgV0cgZW1haWwgbGlzdCBidXQgYXJlIG5vdCBsaXN0ZWQgYXMgYW4gYXV0aG9yIG9yIGNvbnRy aWJ1dG9yLCB0aGVuIHBsZWFzZSBleHBsaWNpdGx5IHJlc3BvbmQgb25seSBpZiB5b3UgYXJlIGF3 YXJlIG9mIGFueSBJUFIgdGhhdCBoYXMgbm90IHlldCBiZWVuIGRpc2Nsb3NlZCBpbiBjb25mb3Jt YW5jZSB3aXRoIElFVEYNCiBydWxlcy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPlRoYW5rcyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+QWNlZTxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_BYAPR11MB3638BDA8D8A65FF2F9D73C81C1400BYAPR11MB3638namp_-- From nobody Tue Mar 19 07:30:20 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4335813131D; Tue, 19 Mar 2019 07:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=lIZOgjYy; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=lGXRyyPs 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 Yslzf0ua3f7o; Tue, 19 Mar 2019 07:30:17 -0700 (PDT) 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 5AA2713130C; Tue, 19 Mar 2019 07:30:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3203; q=dns/txt; s=iport; t=1553005817; x=1554215417; h=from:to:cc:subject:date:message-id:mime-version; bh=ZyjRU8o1UySdiYKjVr7jdwzUWPaDkpOiJ1BMqdLgbFo=; b=lIZOgjYy8fxn31nLGkna6dRLwq+Ploka7EQc7i7Nne9sWCkaD5lg9l5S vY+RCuyM9/V1i0wiN5/Dbx/Zlav7lp/Zo9DWVjzeDax3eX7UKOd1KtjNs bvIn+NG7SstFPxENRYmn7S4KeURB8mmwft6ybBXUNleclYCefOvxKSoUg Q=; IronPort-PHdr: =?us-ascii?q?9a23=3A+GAXQRJM+NPLHq3C6tmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeCuKd2lFGcW4Ld5roEkOfQv636EU04qZea+DFKa5lQT1?= =?us-ascii?q?kAgMQSkRYnBZuMAkD2BPXrdCc9Ws9FUQwt8g=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ANAACy+5Bc/51dJa1jGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBUQYBAQELAYEOL1ADaHQECycKhAGDRwOEUopglROESIEugSQDVAs?= =?us-ascii?q?BASyEQBmEVCI0CQ0BAQMBAQkBAwJtHAELhW4GHQEBNwERAQw+AgQwJwQOgyc?= =?us-ascii?q?BgRFMAxUBAp5/AooUcYEvgngBAQWFEBiCDAiBLwGLMBeBf4EQKB+KVzGCJox?= =?us-ascii?q?jhBaTcwkCkyoZgXyFcotwiwyTAwIEAgQFAg4BAQWBRziBVnAVZQGCQYIKNoM?= =?us-ascii?q?4ilNygSiHbgGBHgEB?= X-IronPort-AV: E=Sophos;i="5.58,498,1544486400"; d="scan'208,217";a="247300139" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Mar 2019 14:30:16 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id x2JEUG4s008370 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 19 Mar 2019 14:30:16 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 19 Mar 2019 09:30:15 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 19 Mar 2019 09:30:14 -0500 Received: from NAM05-BY2-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.1473.3 via Frontend Transport; Tue, 19 Mar 2019 09:30:14 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ZyjRU8o1UySdiYKjVr7jdwzUWPaDkpOiJ1BMqdLgbFo=; b=lGXRyyPs+FAAI3lAlgGKTNVbiwZuZCQnSPcRrlZfp0yOxtShIso3POw33KlbRXEPO6u1acFFz6sNLILt5MRh4B61HeAOTOFe1xNk5qA8DmOMrX1ae29Nz0VBVIkgDytT+uAA6sdPv+dciWe+ljZy+/k7ejjZLB+IUUWcx0uZk4g= Received: from BN8PR11MB3683.namprd11.prod.outlook.com (20.178.220.74) by BN8PR11MB3633.namprd11.prod.outlook.com (20.178.219.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.14; Tue, 19 Mar 2019 14:30:13 +0000 Received: from BN8PR11MB3683.namprd11.prod.outlook.com ([fe80::c62:f0b7:72a0:e853]) by BN8PR11MB3683.namprd11.prod.outlook.com ([fe80::c62:f0b7:72a0:e853%4]) with mapi id 15.20.1709.015; Tue, 19 Mar 2019 14:30:12 +0000 From: "Acee Lindem (acee)" To: "lsr@ietf.org" CC: Alvaro Retana , "draft-ietf-lsr-isis-rfc5306bis@ietf.org" Thread-Topic: WG Last Call for "Restart Signaling for IS-IS" - draft-ietf-lsr-isis-rfc5306bis-01 Thread-Index: AQHU3mBDkRukbzuse0eXlC5qQfNwvw== Date: Tue, 19 Mar 2019 14:30:12 +0000 Message-ID: <17641FA5-F07A-41E1-B2F4-ECE888FF5B16@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=acee@cisco.com; x-originating-ip: [173.38.117.93] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: b54e7286-ede1-47e7-9f8e-08d6ac7765e0 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BN8PR11MB3633; x-ms-traffictypediagnostic: BN8PR11MB3633: x-microsoft-antispam-prvs: x-forefront-prvs: 0981815F2F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(136003)(346002)(366004)(376002)(39860400002)(189003)(199004)(68736007)(478600001)(6116002)(25786009)(476003)(2616005)(86362001)(8936002)(186003)(2906002)(106356001)(4326008)(316002)(3846002)(26005)(7736002)(33656002)(2351001)(54906003)(486006)(105586002)(6506007)(99286004)(256004)(5640700003)(81166006)(6306002)(97736004)(71190400001)(71200400001)(83716004)(81156014)(36756003)(82746002)(1730700003)(6436002)(6916009)(6512007)(54896002)(8676002)(5660300002)(14454004)(66066001)(2501003)(53936002)(6486002)(558084003)(102836004); DIR:OUT; SFP:1101; SCL:1; SRVR:BN8PR11MB3633; H:BN8PR11MB3683.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: dBgN6HzwhAtKroavbv3N70CPVi8yQzPyF80UJX0w7IXDV4Vpb8o6XsURD5ssku4vLshi7wFB7QnJb2BXgnJrsVWz4qu5OE7peo1d3fZRlYU29h5Fsy45Bazcrst1o61nmfwlzcpUNB8FtJuN5XTjwe23KcfOqIRN9bpSWXH+jDmZJBpxGX7p/+ltD9/fmPDfD+Y6rLRcTpiwgWu7Ikd9lPZk1+0DxNNrjwdhNh4HLe7rYnOkDu8wiN5m+PI8j0RPsmADTVkWsyH5CfsCqekKjGsSbTChsTHhjTlNkr84Llk6MPGvk/UMmfNcja7pbrLxVYuuYnsMr52u41iLHEMU8oRf6/b+mO19G6qf73Hd3bpfCCSny6fLX/yRYF9JGz4hc0157GGklqXHux4La/XKoW93f79ISCPJ6bmkwXhkS2M= Content-Type: multipart/alternative; boundary="_000_17641FA5F07A41E1B2F4ECE888FF5B16ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: b54e7286-ede1-47e7-9f8e-08d6ac7765e0 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Mar 2019 14:30:12.7937 (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-Transport-CrossTenantHeadersStamped: BN8PR11MB3633 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.18, xch-aln-008.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: [Lsr] WG Last Call for "Restart Signaling for IS-IS" - draft-ietf-lsr-isis-rfc5306bis-01 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2019 14:30:19 -0000 --_000_17641FA5F07A41E1B2F4ECE888FF5B16ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhpcyBiZWdpbnMgYSAzIFdHIGxhc3QgY2FsbCBmb3IgdGhlIHN1YmplY3QgZG9jdW1lbnQuIFRo ZSBleHRyYSB3ZWVrIGlzIHNpbmNlIHRoZSBJRVRGIGlzIG5leHQgd2Vlay4gUGxlYXNlIGVudGVy IHlvdXIgc3VwcG9ydCBvciBvYmplY3Rpb24gdG8gdGhlIGRvY3VtZW50IGJlZm9yZSAxMjowMCBB TSAoRURUKSBvbiBXZWRuZXNkYXksIEFwcmlsIDNyZCwgMjAxOS4NCg0KVGhhbmtzLA0KQWNlZQ0K --_000_17641FA5F07A41E1B2F4ECE888FF5B16ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij5UaGlzIGJlZ2lucyBhIDMgV0cgbGFzdCBjYWxsIGZvciB0aGUgc3ViamVjdCBk b2N1bWVudC4gVGhlIGV4dHJhIHdlZWsgaXMgc2luY2UgdGhlIElFVEYgaXMgbmV4dCB3ZWVrLiBQ bGVhc2UgZW50ZXIgeW91ciBzdXBwb3J0IG9yIG9iamVjdGlvbiB0byB0aGUgZG9jdW1lbnQgYmVm b3JlIDEyOjAwIEFNIChFRFQpIG9uIFdlZG5lc2RheSwgQXByaWwgMzxzdXA+cmQ8L3N1cD4sDQog MjAxOS4gPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaGFua3Ms PGJyPg0KQWNlZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_17641FA5F07A41E1B2F4ECE888FF5B16ciscocom_-- From nobody Tue Mar 19 13:42:11 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C11312867B; Tue, 19 Mar 2019 13:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, 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 xNVDIX3woX3m; Tue, 19 Mar 2019 13:42:08 -0700 (PDT) Received: from mail-pf1-x42b.google.com (mail-pf1-x42b.google.com [IPv6:2607:f8b0:4864:20::42b]) (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 A3968130F06; Tue, 19 Mar 2019 13:42:05 -0700 (PDT) Received: by mail-pf1-x42b.google.com with SMTP id v64so222342pfb.1; Tue, 19 Mar 2019 13:42:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:message-id:in-reply-to:references:subject :mime-version; bh=ZCUcjNuA/3PXhd6ygkX+WYuya+ZSb7HzhZHwhba5HvQ=; b=eT9Jb8v+920eohA5FTN3xWBijRRoHlFBVh+pKNZmH3kJ4Vb3Pu4g+wzE+oxSPcopmN o7UWxH8xlXaiykIKUlXpJ/kmIF58IPAaIC4GCnEn1lw8jut/WYtX1ZaiybKzm/UdoDGU wOLrdiykAkhnBJ3aSruSufoqyvXRktYLVXLtzgnowEqtPrPWm40gF9f7vWB8iJQalCKp Rzxz78VGz2Kkic4ps54mGac6BzB+86xmcuNrE/xQkYKJej81YytECq9NGAIsJxAmQQI1 hn7RzCoCRea0WA+JY9oK+YlkC/meO3lQ2NAZVDdjk6COUAJXkh4gDIrswdSeIkur+gjc y8tA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:message-id:in-reply-to :references:subject:mime-version; bh=ZCUcjNuA/3PXhd6ygkX+WYuya+ZSb7HzhZHwhba5HvQ=; b=S/t5Oi1xA1aEmq7QsIEKuNweRp4q6Eb5GOCjmdbWgoK9DZrj4s0DQdCGtbXxYfcP40 OR3OLrHrZO9oEvIlkJ5sCBorZX3HKlyk/GqrovZgSoE54DTOUIuvGTPI04s+a10ez5S2 8xn4TgzqTEl04gsnt3m4pjbZXt8v8VBFE9D90sl9VTYqoS0LrqF0KXb2SlVZOoBoLpHg zbz7/tkjHractZVMs4gHx0pa4JDSIBvadJvAa5zF6tllWMjwpaAcYFFAF0lM1WWNdDis cq3AwQDP9KrNS5HW5V2IUAavVeAtC91Zi+yE0/ooMuWmztAgSTdJCZk3B5kP2RdZ2wgx jj/A== X-Gm-Message-State: APjAAAULNHOyyI+0vMZjShaCKJt8Viu9YJLCoxEHDxd8lb/n2jMP9llR RKFOd4Kuw99c7lITlOeSxrDF2mvJ X-Google-Smtp-Source: APXvYqy3EzUhpC54XXAUh0XsBY4YIMwaD4zm1KrXKDz8p7lEB7bCiWtZvIVbj6RJ1WBIGZIMu+mS8g== X-Received: by 2002:a63:3d0e:: with SMTP id k14mr3693382pga.302.1553028124981; Tue, 19 Mar 2019 13:42:04 -0700 (PDT) Received: from [10.5.5.194] ([50.235.77.202]) by smtp.gmail.com with ESMTPSA id x5sm17032789pgp.68.2019.03.19.13.42.02 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 19 Mar 2019 13:42:03 -0700 (PDT) Date: Tue, 19 Mar 2019 13:41:55 -0700 From: Jeff Tantsura To: "=?utf-8?Q?lsr=40ietf.org?=" , "Acee Lindem (acee)" Cc: "=?utf-8?Q?draft-ietf-lsr-isis-rfc5306bis=40ietf.org?=" , Alvaro Retana Message-ID: In-Reply-To: <17641FA5-F07A-41E1-B2F4-ECE888FF5B16@cisco.com> References: <17641FA5-F07A-41E1-B2F4-ECE888FF5B16@cisco.com> X-Readdle-Message-ID: ec4457fb-da9e-4dae-906e-56d8bcd24d16@Spark MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="5c91541a_5db70ae5_137d4" Archived-At: Subject: Re: [Lsr] WG Last Call for "Restart Signaling for IS-IS" - draft-ietf-lsr-isis-rfc5306bis-01 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2019 20:42:11 -0000 --5c91541a_5db70ae5_137d4 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline yes/support Cheers, Jeff On Mar 19, 2019, 7:30 AM -0700, Acee Lindem (acee) , wrote: > This begins a 3 WG last call for the subject document. The extra week is since the IETF is next week. Please enter your support or objection to the document before 12:00 AM (EDT) on Wednesday, April 3rd, 2019. > > Thanks, > Acee > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr --5c91541a_5db70ae5_137d4 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline
yes/support


Cheers,
Jeff
On Mar 19, 2019= , 7:30 AM -0700, Acee Lindem (acee) <acee=40cisco.com>, wrote:

This begi= ns a 3 WG last call for the subject document. The extra week is since the= IET=46 is next week. Please enter your support or objection to the docum= ent before 12:00 AM (EDT) on Wednesday, April 3rd, 2019.

&=23160;<= /span>

Thanks, Acee

=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
Lsr mailing list
Lsr=40ietf.org
https://www.ietf.org/mailman/listinfo/lsr
--5c91541a_5db70ae5_137d4-- From nobody Tue Mar 19 13:49:57 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C4C41310BB; Tue, 19 Mar 2019 13:49:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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=V6rOdYI4; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=Z28TQd8T 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 198EC4aCAaVU; Tue, 19 Mar 2019 13:49:53 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B752129C6A; Tue, 19 Mar 2019 13:49:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6405; q=dns/txt; s=iport; t=1553028593; x=1554238193; h=from:to:cc:subject:date:message-id:mime-version; bh=TNsGW010JdT2qlx3vUDFF/DE0K1chO+pEj995kMhXdI=; b=V6rOdYI4rd+lZDYdPXe4YwgqNTRmiZGYbmwteXlUpAgD1YExPkCh8YXZ r5VM1ohHQ4fCrm3XP/kVcMV4BED6wPrJdyMpd5RFB47eUv5v/2vbCG2Fq sxAv0f2FPPL3W3FT8cmt4c6xkS1Qr6mFZ4n900gr0FSTdMFG8ScXly/rp k=; IronPort-PHdr: =?us-ascii?q?9a23=3AqkwURR+MS9ad4v9uRHGN82YQeigqvan1NQcJ65?= =?us-ascii?q?0hzqhDabmn44+/YR7E/fs4iljPUM2b8P9Ch+fM+4HYEW0bqdfJq3UeaNpJXh?= =?us-ascii?q?4Bh98RmlkpC8OIIUb6N/XtKSc9GZcKWQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AoAABvVZFc/4kNJK1jHAEBAQQBAQc?= =?us-ascii?q?EAQGBUQcBAQsBgQ4vUANodAQLJwqEAYNHA4RSimKCV4kziQmESIEugSQDVAs?= =?us-ascii?q?BASyEQBmEVCI0CQ0BAQMBAQkBAwJtHAELhUoBAwMdBh0BATcBEQEIEQMBAis?= =?us-ascii?q?CBB8RHQoEDgWDIgGBEUwDFQECn20CihRxgS+CeAEBBYUEDQuCDAiBLwGLMRe?= =?us-ascii?q?Bf4EQKB+CTIJXgkoGgmQxgiaMY4QWkz02CQKPa4M/GYF8hXKLcIsMhzGLUgI?= =?us-ascii?q?EAgQFAg4BAQWBRziBVnAVZQGCQYIKNoM4ilNygSiNJAGBHgEB?= X-IronPort-AV: E=Sophos;i="5.60,246,1549929600"; d="scan'208,217";a="537418319" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 19 Mar 2019 20:49:52 +0000 Received: from XCH-RCD-015.cisco.com (xch-rcd-015.cisco.com [173.37.102.25]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x2JKnqM1015569 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 19 Mar 2019 20:49:52 GMT Received: from xhs-rcd-001.cisco.com (173.37.227.246) by XCH-RCD-015.cisco.com (173.37.102.25) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 19 Mar 2019 15:49:51 -0500 Received: from xhs-aln-002.cisco.com (173.37.135.119) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 19 Mar 2019 15:49:51 -0500 Received: from NAM04-BN3-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 19 Mar 2019 15:49:51 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=TNsGW010JdT2qlx3vUDFF/DE0K1chO+pEj995kMhXdI=; b=Z28TQd8TZEP39oNznbN1EyOOxZIONXDqLWifE3/0wx/aa8I+qfzdJZ8A1rMf1cHh8VztWlpjKoUTV9k/BYhmwNEvlrtgeMzoadQdeswK9HB8c/Og5E3DPyOVy79XR9BMa+m/L2lVR4Hw4jilm3YE3MA8uZu3Ct1NxnLekql4iFg= Received: from BN8PR11MB3683.namprd11.prod.outlook.com (20.178.220.74) by BN8PR11MB3844.namprd11.prod.outlook.com (20.178.222.88) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.14; Tue, 19 Mar 2019 20:49:50 +0000 Received: from BN8PR11MB3683.namprd11.prod.outlook.com ([fe80::c62:f0b7:72a0:e853]) by BN8PR11MB3683.namprd11.prod.outlook.com ([fe80::c62:f0b7:72a0:e853%4]) with mapi id 15.20.1709.015; Tue, 19 Mar 2019 20:49:50 +0000 From: "Acee Lindem (acee)" To: "lsr@ietf.org" CC: "draft-ietf-lsr-isis-rfc5306bis@ietf.org" , Alvaro Retana Thread-Topic: [Lsr] WG Last Call for "Restart Signaling for IS-IS" - draft-ietf-lsr-isis-rfc5306bis-01 Thread-Index: AQHU3pVLNpCl135vKkqLSCvQUWX2wg== Date: Tue, 19 Mar 2019 20:49:49 +0000 Message-ID: <9F5F11B7-F87A-43EE-AA1C-4974AA6F4318@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=acee@cisco.com; x-originating-ip: [173.38.117.80] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7065ad58-f298-4878-03b1-08d6acac6e24 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BN8PR11MB3844; x-ms-traffictypediagnostic: BN8PR11MB3844: x-microsoft-antispam-prvs: x-forefront-prvs: 0981815F2F x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(376002)(366004)(346002)(136003)(39860400002)(199004)(189003)(7736002)(53936002)(6246003)(5640700003)(54896002)(71190400001)(83716004)(71200400001)(14454004)(81156014)(1730700003)(8676002)(25786009)(81166006)(6512007)(6306002)(86362001)(82746002)(105586002)(68736007)(4326008)(186003)(8936002)(2351001)(6916009)(106356001)(2616005)(476003)(486006)(33656002)(5660300002)(3846002)(6116002)(256004)(97736004)(4744005)(2906002)(6506007)(316002)(26005)(229853002)(66066001)(53546011)(102836004)(2501003)(99286004)(6486002)(478600001)(36756003)(6436002)(54906003); DIR:OUT; SFP:1101; SCL:1; SRVR:BN8PR11MB3844; H:BN8PR11MB3683.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: l1IoEGy9SgxjL+3Id9wiO302dEt2xTmlJ15m11q1q3BYQNjqo9QtBIeKk9atGTgyNiy6ou835wbjMfZTdFAObV4hLBkPI+MJBB+DjLdFdSTEJ+vAOqsJHL+8dJUUCuAfQH7KWQVC00mNy55JyrAhS7q/pnIAzEFZCSvF4xh7QfrjqE/KtKnk1aRizzSx7wcBG3FZQrQlWp0ix22P0y4xbxmXy2B5tJx24k/H8hxOYgG5y6wc2aZB8HU3xKUQBL9qQUa1W/j/ZebEmTcWenG06kbOVYl0gbOYWBt4zwYLfOCdez7uisdB8vEED3g7HCT5tkAOAy0nlJ++IJZy9f0wyg8y4tuJKJ7Pms//SkuqvHHZj7mQRiexnwxE0W0F6nxAbmL/pr8+aJAd8qZftjXixYQZyB1jeko5on9F2IqGI30= Content-Type: multipart/alternative; boundary="_000_9F5F11B7F87A43EEAA1C4974AA6F4318ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 7065ad58-f298-4878-03b1-08d6acac6e24 X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Mar 2019 20:49:49.9738 (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-Transport-CrossTenantHeadersStamped: BN8PR11MB3844 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.25, xch-rcd-015.cisco.com X-Outbound-Node: alln-core-4.cisco.com Archived-At: Subject: Re: [Lsr] WG Last Call for "Restart Signaling for IS-IS" - draft-ietf-lsr-isis-rfc5306bis-01 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2019 20:49:56 -0000 --_000_9F5F11B7F87A43EEAA1C4974AA6F4318ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3BlYWtpbmcgYXMgYSBXRyBtZW1iZXIsDQoNCkkgc3VwcG9ydCBwdWJsaWNhdGlvbiBvZiB0aGUg c3ViamVjdCBkb2N1bWVudC4NCg0KVGhhbmtzLA0KQWNlZQ0KDQpGcm9tOiBMc3IgPGxzci1ib3Vu Y2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgQWNlZSBMaW5kZW0gPGFjZWVAY2lzY28uY29tPg0K RGF0ZTogVHVlc2RheSwgTWFyY2ggMTksIDIwMTkgYXQgMTA6MzAgQU0NClRvOiAibHNyQGlldGYu b3JnIiA8bHNyQGlldGYub3JnPg0KQ2M6ICJkcmFmdC1pZXRmLWxzci1pc2lzLXJmYzUzMDZiaXNA aWV0Zi5vcmciIDxkcmFmdC1pZXRmLWxzci1pc2lzLXJmYzUzMDZiaXNAaWV0Zi5vcmc+LCBBbHZh cm8gUmV0YW5hIDxhcmV0YW5hLmlldGZAZ21haWwuY29tPg0KU3ViamVjdDogW0xzcl0gV0cgTGFz dCBDYWxsIGZvciAiUmVzdGFydCBTaWduYWxpbmcgZm9yIElTLUlTIiAtIGRyYWZ0LWlldGYtbHNy LWlzaXMtcmZjNTMwNmJpcy0wMQ0KDQpUaGlzIGJlZ2lucyBhIDMgV0cgbGFzdCBjYWxsIGZvciB0 aGUgc3ViamVjdCBkb2N1bWVudC4gVGhlIGV4dHJhIHdlZWsgaXMgc2luY2UgdGhlIElFVEYgaXMg bmV4dCB3ZWVrLiBQbGVhc2UgZW50ZXIgeW91ciBzdXBwb3J0IG9yIG9iamVjdGlvbiB0byB0aGUg ZG9jdW1lbnQgYmVmb3JlIDEyOjAwIEFNIChFRFQpIG9uIFdlZG5lc2RheSwgQXByaWwgM3JkLCAy MDE5Lg0KDQpUaGFua3MsDQpBY2VlDQo= --_000_9F5F11B7F87A43EEAA1C4974AA6F4318ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <4F27CAFFA1CEC54AA6BE06303BCB557D@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw Lm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1u YW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6 MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglm b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNw YW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0 eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNh bGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0K CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot LT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZs aW5rPSIjOTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+U3BlYWtpbmcgYXMgYSBXRyBt ZW1iZXIsIDxvOnA+DQo8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5JIHN1 cHBvcnQgcHVibGljYXRpb24gb2YgdGhlIHN1YmplY3QgZG9jdW1lbnQuPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkFj ZWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6 My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1s ZWZ0Oi41aW4iPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+RnJvbTogPC9zcGFuPg0KPC9i PjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+THNyICZsdDtsc3ItYm91bmNlc0BpZXRmLm9yZyZn dDsgb24gYmVoYWxmIG9mIEFjZWUgTGluZGVtICZsdDthY2VlQGNpc2NvLmNvbSZndDs8YnI+DQo8 Yj5EYXRlOiA8L2I+VHVlc2RheSwgTWFyY2ggMTksIDIwMTkgYXQgMTA6MzAgQU08YnI+DQo8Yj5U bzogPC9iPiZxdW90O2xzckBpZXRmLm9yZyZxdW90OyAmbHQ7bHNyQGlldGYub3JnJmd0Ozxicj4N CjxiPkNjOiA8L2I+JnF1b3Q7ZHJhZnQtaWV0Zi1sc3ItaXNpcy1yZmM1MzA2YmlzQGlldGYub3Jn JnF1b3Q7ICZsdDtkcmFmdC1pZXRmLWxzci1pc2lzLXJmYzUzMDZiaXNAaWV0Zi5vcmcmZ3Q7LCBB bHZhcm8gUmV0YW5hICZsdDthcmV0YW5hLmlldGZAZ21haWwuY29tJmd0Ozxicj4NCjxiPlN1Ympl Y3Q6IDwvYj5bTHNyXSBXRyBMYXN0IENhbGwgZm9yICZxdW90O1Jlc3RhcnQgU2lnbmFsaW5nIGZv ciBJUy1JUyZxdW90OyAtIGRyYWZ0LWlldGYtbHNyLWlzaXMtcmZjNTMwNmJpcy0wMTxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4m bmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoaXMg YmVnaW5zIGEgMyBXRyBsYXN0IGNhbGwgZm9yIHRoZSBzdWJqZWN0IGRvY3VtZW50LiBUaGUgZXh0 cmEgd2VlayBpcyBzaW5jZSB0aGUgSUVURiBpcyBuZXh0IHdlZWsuIFBsZWFzZSBlbnRlciB5b3Vy IHN1cHBvcnQgb3Igb2JqZWN0aW9uIHRvIHRoZSBkb2N1bWVudCBiZWZvcmUgMTI6MDAgQU0gKEVE VCkgb24NCiBXZWRuZXNkYXksIEFwcmlsIDM8c3VwPnJkPC9zdXA+LCAyMDE5LiA8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVp biI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhhbmtzLDxicj4NCkFjZWU8L3NwYW4+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_9F5F11B7F87A43EEAA1C4974AA6F4318ciscocom_-- From nobody Tue Mar 19 16:02:27 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 051D213118B; Tue, 19 Mar 2019 16:02:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 i_sH4OSorXIY; Tue, 19 Mar 2019 16:02:22 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 84C08131181; Tue, 19 Mar 2019 16:02:22 -0700 (PDT) Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 964662F178C4616F82BF; Tue, 19 Mar 2019 23:02:20 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 19 Mar 2019 23:01:56 +0000 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.179]) by SJCEML702-CHM.china.huawei.com ([169.254.4.15]) with mapi id 14.03.0415.000; Tue, 19 Mar 2019 16:01:55 -0700 From: Yingzhen Qu To: "Acee Lindem (acee)" , "lsr@ietf.org" CC: "draft-ietf-lsr-isis-rfc5306bis@ietf.org" , Alvaro Retana Thread-Topic: [Lsr] WG Last Call for "Restart Signaling for IS-IS" - draft-ietf-lsr-isis-rfc5306bis-01 Thread-Index: AQHU3pVLkRukbzuse0eXlC5qQfNwv6YTki+A Date: Tue, 19 Mar 2019 23:01:53 +0000 Message-ID: <594D005A3CB0724DB547CF3E9A9E810B011B5AAE@sjceml521-mbx.china.huawei.com> References: <9F5F11B7-F87A-43EE-AA1C-4974AA6F4318@cisco.com> In-Reply-To: <9F5F11B7-F87A-43EE-AA1C-4974AA6F4318@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.209.217.0] Content-Type: multipart/alternative; boundary="_000_594D005A3CB0724DB547CF3E9A9E810B011B5AAEsjceml521mbxchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Lsr] WG Last Call for "Restart Signaling for IS-IS" - draft-ietf-lsr-isis-rfc5306bis-01 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2019 23:02:25 -0000 --_000_594D005A3CB0724DB547CF3E9A9E810B011B5AAEsjceml521mbxchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U3VwcG9ydCArMS4NCg0KVGhhbmtzLA0KWWluZ3poZW4NCg0KRnJvbTogTHNyIFttYWlsdG86bHNy LWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBY2VlIExpbmRlbSAoYWNlZSkNClNlbnQ6 IFR1ZXNkYXksIE1hcmNoIDE5LCAyMDE5IDE6NTAgUE0NClRvOiBsc3JAaWV0Zi5vcmcNCkNjOiBk cmFmdC1pZXRmLWxzci1pc2lzLXJmYzUzMDZiaXNAaWV0Zi5vcmc7IEFsdmFybyBSZXRhbmEgPGFy ZXRhbmEuaWV0ZkBnbWFpbC5jb20+DQpTdWJqZWN0OiBSZTogW0xzcl0gV0cgTGFzdCBDYWxsIGZv ciAiUmVzdGFydCBTaWduYWxpbmcgZm9yIElTLUlTIiAtIGRyYWZ0LWlldGYtbHNyLWlzaXMtcmZj NTMwNmJpcy0wMQ0KDQpTcGVha2luZyBhcyBhIFdHIG1lbWJlciwNCg0KSSBzdXBwb3J0IHB1Ymxp Y2F0aW9uIG9mIHRoZSBzdWJqZWN0IGRvY3VtZW50Lg0KDQpUaGFua3MsDQpBY2VlDQoNCkZyb206 IExzciA8bHNyLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOmxzci1ib3VuY2VzQGlldGYub3JnPj4g b24gYmVoYWxmIG9mIEFjZWUgTGluZGVtIDxhY2VlQGNpc2NvLmNvbTxtYWlsdG86YWNlZUBjaXNj by5jb20+Pg0KRGF0ZTogVHVlc2RheSwgTWFyY2ggMTksIDIwMTkgYXQgMTA6MzAgQU0NClRvOiAi bHNyQGlldGYub3JnPG1haWx0bzpsc3JAaWV0Zi5vcmc+IiA8bHNyQGlldGYub3JnPG1haWx0bzps c3JAaWV0Zi5vcmc+Pg0KQ2M6ICJkcmFmdC1pZXRmLWxzci1pc2lzLXJmYzUzMDZiaXNAaWV0Zi5v cmc8bWFpbHRvOmRyYWZ0LWlldGYtbHNyLWlzaXMtcmZjNTMwNmJpc0BpZXRmLm9yZz4iIDxkcmFm dC1pZXRmLWxzci1pc2lzLXJmYzUzMDZiaXNAaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtbHNy LWlzaXMtcmZjNTMwNmJpc0BpZXRmLm9yZz4+LCBBbHZhcm8gUmV0YW5hIDxhcmV0YW5hLmlldGZA Z21haWwuY29tPG1haWx0bzphcmV0YW5hLmlldGZAZ21haWwuY29tPj4NClN1YmplY3Q6IFtMc3Jd IFdHIExhc3QgQ2FsbCBmb3IgIlJlc3RhcnQgU2lnbmFsaW5nIGZvciBJUy1JUyIgLSBkcmFmdC1p ZXRmLWxzci1pc2lzLXJmYzUzMDZiaXMtMDENCg0KVGhpcyBiZWdpbnMgYSAzIFdHIGxhc3QgY2Fs bCBmb3IgdGhlIHN1YmplY3QgZG9jdW1lbnQuIFRoZSBleHRyYSB3ZWVrIGlzIHNpbmNlIHRoZSBJ RVRGIGlzIG5leHQgd2Vlay4gUGxlYXNlIGVudGVyIHlvdXIgc3VwcG9ydCBvciBvYmplY3Rpb24g dG8gdGhlIGRvY3VtZW50IGJlZm9yZSAxMjowMCBBTSAoRURUKSBvbiBXZWRuZXNkYXksIEFwcmls IDNyZCwgMjAxOS4NCg0KVGhhbmtzLA0KQWNlZQ0K --_000_594D005A3CB0724DB547CF3E9A9E810B011B5AAEsjceml521mbxchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 U2ltU3VuOw0KCXBhbm9zZS0xOjIgMSA2IDAgMyAxIDEgMSAxIDE7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0 O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUg MiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJcQFNpbVN1biI7DQoJ cGFub3NlLTE6MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0K cC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0K CW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5 OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVu ZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVy bGluZTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21z by1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJn aW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0 OjBpbjsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNl cmlmO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5 bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2Fs aWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwv aGVhZD4NCjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+ DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+U3VwcG9ydCAmIzQzOzEuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Y29s b3I6IzFGNDk3RCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2NvbG9yOiMxRjQ5N0QiPllpbmd6 aGVuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgbmFtZT0i X01haWxFbmRDb21wb3NlIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtjb2xvcjojMUY0 OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2E+PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9 ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0 IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w cHQiPiBMc3IgW21haWx0bzpsc3ItYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8 L2I+QWNlZSBMaW5kZW0gKGFjZWUpPGJyPg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIE1hcmNoIDE5 LCAyMDE5IDE6NTAgUE08YnI+DQo8Yj5Ubzo8L2I+IGxzckBpZXRmLm9yZzxicj4NCjxiPkNjOjwv Yj4gZHJhZnQtaWV0Zi1sc3ItaXNpcy1yZmM1MzA2YmlzQGlldGYub3JnOyBBbHZhcm8gUmV0YW5h ICZsdDthcmV0YW5hLmlldGZAZ21haWwuY29tJmd0Ozxicj4NCjxiPlN1YmplY3Q6PC9iPiBSZTog W0xzcl0gV0cgTGFzdCBDYWxsIGZvciAmcXVvdDtSZXN0YXJ0IFNpZ25hbGluZyBmb3IgSVMtSVMm cXVvdDsgLSBkcmFmdC1pZXRmLWxzci1pc2lzLXJmYzUzMDZiaXMtMDE8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdCI+U3BlYWtpbmcgYXMgYSBXRyBtZW1iZXIsIDxvOnA+DQo8L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0Ij5JIHN1cHBvcnQgcHVibGljYXRpb24gb2YgdGhlIHN1YmplY3Qg ZG9jdW1lbnQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaGFu a3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQiPkFjZWU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xp ZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+RnJvbTogPC9zcGFuPg0KPC9iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+THNyICZs dDs8YSBocmVmPSJtYWlsdG86bHNyLWJvdW5jZXNAaWV0Zi5vcmciPmxzci1ib3VuY2VzQGlldGYu b3JnPC9hPiZndDsgb24gYmVoYWxmIG9mIEFjZWUgTGluZGVtICZsdDs8YSBocmVmPSJtYWlsdG86 YWNlZUBjaXNjby5jb20iPmFjZWVAY2lzY28uY29tPC9hPiZndDs8YnI+DQo8Yj5EYXRlOiA8L2I+ VHVlc2RheSwgTWFyY2ggMTksIDIwMTkgYXQgMTA6MzAgQU08YnI+DQo8Yj5UbzogPC9iPiZxdW90 OzxhIGhyZWY9Im1haWx0bzpsc3JAaWV0Zi5vcmciPmxzckBpZXRmLm9yZzwvYT4mcXVvdDsgJmx0 OzxhIGhyZWY9Im1haWx0bzpsc3JAaWV0Zi5vcmciPmxzckBpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0K PGI+Q2M6IDwvYj4mcXVvdDs8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1sc3ItaXNpcy1yZmM1 MzA2YmlzQGlldGYub3JnIj5kcmFmdC1pZXRmLWxzci1pc2lzLXJmYzUzMDZiaXNAaWV0Zi5vcmc8 L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1sc3ItaXNpcy1yZmM1MzA2 YmlzQGlldGYub3JnIj5kcmFmdC1pZXRmLWxzci1pc2lzLXJmYzUzMDZiaXNAaWV0Zi5vcmc8L2E+ Jmd0OywgQWx2YXJvIFJldGFuYSAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFyZXRhbmEuaWV0ZkBnbWFp bC5jb20iPmFyZXRhbmEuaWV0ZkBnbWFpbC5jb208L2E+Jmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwv Yj5bTHNyXSBXRyBMYXN0IENhbGwgZm9yICZxdW90O1Jlc3RhcnQgU2lnbmFsaW5nIGZvciBJUy1J UyZxdW90OyAtIGRyYWZ0LWlldGYtbHNyLWlzaXMtcmZjNTMwNmJpcy0wMTxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFy Z2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPlRoaXMgYmVnaW5z IGEgMyBXRyBsYXN0IGNhbGwgZm9yIHRoZSBzdWJqZWN0IGRvY3VtZW50LiBUaGUgZXh0cmEgd2Vl ayBpcyBzaW5jZSB0aGUgSUVURiBpcyBuZXh0IHdlZWsuIFBsZWFzZSBlbnRlciB5b3VyIHN1cHBv cnQgb3Igb2JqZWN0aW9uIHRvIHRoZSBkb2N1bWVudCBiZWZvcmUgMTI6MDAgQU0gKEVEVCkgb24N CiBXZWRuZXNkYXksIEFwcmlsIDM8c3VwPnJkPC9zdXA+LCAyMDE5LiA8L3NwYW4+PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdCI+VGhhbmtzLDxicj4NCkFjZWU8L3NwYW4+PG86cD48L286cD48 L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_594D005A3CB0724DB547CF3E9A9E810B011B5AAEsjceml521mbxchi_-- From nobody Tue Mar 19 16:47:11 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6FD21310A2 for ; Tue, 19 Mar 2019 16:47:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.272 X-Spam-Level: X-Spam-Status: No, score=-0.272 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MALFORMED_FREEMAIL=0.705, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 lnDBAAidFNkW for ; Tue, 19 Mar 2019 16:47:08 -0700 (PDT) Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com [IPv6:2a00:1450:4864:20::12d]) (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 C53B613104D for ; Tue, 19 Mar 2019 16:47:06 -0700 (PDT) Received: by mail-lf1-x12d.google.com with SMTP id d18so482356lfn.3 for ; Tue, 19 Mar 2019 16:47:06 -0700 (PDT) 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:cc; bh=iE7+bIsWfpLaEkHJKzm6TfNiVkgsi4VqxxqvfYO5cQQ=; b=PK7AsFPYBjLkr7UAFdZwZExgXFgc51fObmG45z6sJrp9XCw6l66Ypr8WOgFxZDvPST h8wWtuG1wYnbBevbzVsOYMq287HE9xPlu3U2RutnueNaChXeaLuf19CH6W/LdOGQysk0 GdaYpZuO14xLKO3gydv4w0PYqZ+uXBwQPbOfZkgh8KaN1X8ilsNcGheLg3ost45O1oW2 ZJbDymBXgbsvKqxG2xB6LYTma5K1GOF8Vw5T/hQNsKBMqJrD1mMvQghWUtbvQWzPryj/ 60uzDwxVh4yzzYuqm/KbE/0zaiL4IJmkv3x3TAF00l3iPf9IroT1VwJyxyRhMooe5/3w xopw== 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:cc; bh=iE7+bIsWfpLaEkHJKzm6TfNiVkgsi4VqxxqvfYO5cQQ=; b=Gf7e7sLkF695Nt3gbVS1LheKmlID/Nxlacoe5D3YXxZZkUSjJ27LP0LKgoY9g+LQ7n 12pQ+hWYG8pfwnOG0mPs+cd8YicZmtWAurr2Sl5BCyTItkwpLNZhmnbArGlysKV0fwNp t2qAiGCRgi0/NhWi4v22PHuH4ShW7o7g7F20swYwf6EkR9NlpOxYKwex/tHz0MovuAuU QJBCD9DHscuspb0zoFm+oq75FbcAEuEenpdb9+kChIoe1/97mI15WCBxDE8duoheKmRc djTgczh2Wgh3+URWwSD1W2k6Z+ZGGHEJXuNBB57N1jLuO1Hil5pv9bPZVYvRSjWl8DZ+ bYFw== X-Gm-Message-State: APjAAAWxqWgDfHNOjJXuMeA9+VjXvnMCI4prxVh2RtAJZJKwD2THSC7i kpYzhgV0lgUuGz7HXmE91ZIP1kXDTwTSXvqmSw0P5QAL X-Received: by 2002:ac2:54bc:: with SMTP id w28mt9974291lfk.127.1553039224800; Tue, 19 Mar 2019 16:47:04 -0700 (PDT) MIME-Version: 1.0 References: <17641FA5-F07A-41E1-B2F4-ECE888FF5B16@cisco.com> In-Reply-To: From: Ayan Banerjee Date: Tue, 19 Mar 2019 16:46:53 -0700 Message-ID: Cc: "lsr@ietf.org" , "draft-ietf-lsr-isis-rfc5306bis@ietf.org" , Alvaro Retana Content-Type: multipart/alternative; boundary="00000000000053e0bc05847b1f03" Archived-At: Subject: Re: [Lsr] WG Last Call for "Restart Signaling for IS-IS" - draft-ietf-lsr-isis-rfc5306bis-01 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Mar 2019 23:47:10 -0000 --00000000000053e0bc05847b1f03 Content-Type: text/plain; charset="UTF-8" Support. Thanks, Ayan On Tue, Mar 19, 2019 at 1:42 PM Jeff Tantsura wrote: > yes/support > > > Cheers, > Jeff > On Mar 19, 2019, 7:30 AM -0700, Acee Lindem (acee) , > wrote: > > This begins a 3 WG last call for the subject document. The extra week is > since the IETF is next week. Please enter your support or objection to the > document before 12:00 AM (EDT) on Wednesday, April 3rd, 2019. > > > > Thanks, > Acee > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > --00000000000053e0bc05847b1f03 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Support.

Thanks,
A= yan

On Tue, Mar 19, 2019 at 1:42 PM Jeff Tantsura <jefftant.ietf@gmail.com> wrote:
yes/support


Cheers,
Jeff
On Mar 19, 2019, 7:30 AM -0700, Ace= e Lindem (acee) <ace= e@cisco.com>, wrote:

This begins a 3 WG la= st call for the subject document. The extra week is since the IETF is next = week. Please enter your support or objection to the document before 12:00 A= M (EDT) on Wednesday, April 3rd, 2019.

=C2=A0

Thanks,
Acee

_______________________________________________
Lsr mailing list
Lsr@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/lsr
_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
--00000000000053e0bc05847b1f03-- From nobody Wed Mar 20 07:40:07 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE575129A4B for ; Wed, 20 Mar 2019 07:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 5_3rM7VtieFY for ; Wed, 20 Mar 2019 07:39:56 -0700 (PDT) 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 5109012799B for ; Wed, 20 Mar 2019 07:39:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4788; q=dns/txt; s=iport; t=1553092796; x=1554302396; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=CmAbkotn7gGdW/uy3sy0JuV3T5JFJifqz/hNbecyJuM=; b=mvTG5CYlmKGgD2Z6S8jZmmM1vVgW7sTIPf58zHXOEjvcohp1NF+W2w3F y56TrnFmxiJP6DUAQzA4ZiAI8IU6dZ6/2I0Ii52sItuu0yG1828EsQ0HZ kun9WU+qybDJXQvHjlNDU26EMms74yfdC+lCbWH2i7FtbynqpkCSyonkD M=; X-IronPort-AV: E=Sophos;i="5.60,249,1549929600"; d="scan'208,217";a="247558880" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 Mar 2019 14:39:55 +0000 Received: from [10.19.43.166] (sjc-pauwells-nitro5.cisco.com [10.19.43.166]) (authenticated bits=0) by alln-core-3.cisco.com (8.15.2/8.15.2) with ESMTPSA id x2KEdmLc021919 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NO); Wed, 20 Mar 2019 14:39:54 GMT To: "Acee Lindem (acee)" , "Les Ginsberg (ginsberg)" Cc: "lsr@ietf.org" References: <365ADAE0-039A-44F3-B2E1-5687DD6C4623@cisco.com> From: Paul Wells Message-ID: <872e64fc-6def-a6c8-607f-f85a40e031a7@cisco.com> Date: Wed, 20 Mar 2019 09:39:47 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <365ADAE0-039A-44F3-B2E1-5687DD6C4623@cisco.com> Content-Type: multipart/alternative; boundary="------------FA7B832BE332F59CFA959D71" Content-Language: en-US X-Authenticated-User: pauwells X-Outbound-SMTP-Client: 10.19.43.166, sjc-pauwells-nitro5.cisco.com X-Outbound-Node: alln-core-3.cisco.com Archived-At: Subject: Re: [Lsr] IPR Poll for "Restart Signaling for IS-IS" - draft-ietf-lsr-isis-rfc5306bis-01 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2019 14:40:00 -0000 This is a multi-part message in MIME format. --------------FA7B832BE332F59CFA959D71 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Acee, I'm not aware of any relevant IPR. Regards, Paul On 3/19/19 9:17 AM, Acee Lindem (acee) wrote: > > Hi Les, Paul, > > In preparation for WG last call, I’d like to ask one more time if you > know of any IPR associated with this draft? > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see RFCs 3979, 4879, 3669 and 5378 for more details). > > If you are listed as a document author or contributor please respond > to this email regardless of whether or not you are aware of any > relevant IPR. *The response needs to be sent to the LSR WG mailing > list.* The document will not advance to the next stage until a > response has been received from each author and contributor. > > If you are on the LSR WG email list but are not listed as an author or > contributor, then please explicitly respond only if you are aware of > any IPR that has not yet been disclosed in conformance with IETF rules. > > Thanks, > > Acee > --------------FA7B832BE332F59CFA959D71 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Hi Acee,

I'm not aware of any relevant IPR.

Regards,
Paul

On 3/19/19 9:17 AM, Acee Lindem (acee) wrote:

Hi Les, Paul,

 

In preparation for WG last call, I’d like to ask one more time if you know of any IPR associated with this draft?

 

If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor please respond to this email regardless of whether or not you are aware of any relevant IPR. *The response needs to be sent to the LSR WG mailing list.* The document will not advance to the next stage until a response has been received from each author and contributor.

If you are on the LSR WG email list but are not listed as an author or contributor, then please explicitly respond only if you are aware of any IPR that has not yet been disclosed in conformance with IETF rules.

 

Thanks,

Acee


--------------FA7B832BE332F59CFA959D71-- From nobody Wed Mar 20 07:42:31 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EFC51279AA; Wed, 20 Mar 2019 07:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 RyduWy6L755i; Wed, 20 Mar 2019 07:42:28 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1ADDC127988; Wed, 20 Mar 2019 07:42:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2788; q=dns/txt; s=iport; t=1553092947; x=1554302547; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=6nF9L2h2DDWghygo3WRM15I0svZwyPGeI3TQbexN58c=; b=d7upBpO5f+VBX5gbNMRTJOVBu/4cWU4/yKtnH2Chjs149jHMU/rIBxuZ W6Axmaz3CO00rwqVt7a/GrHcRZo2oPw1+grMLTICw1SeGVum0ssi2BPDg jF3kWK5M2hyP010NkBDQvp91Tq3reXqROtv00+LeS5fvDrE227XNPAE9K c=; X-IronPort-AV: E=Sophos;i="5.60,249,1549929600"; d="scan'208,217";a="537729682" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 Mar 2019 14:42:26 +0000 Received: from [10.19.43.166] (sjc-pauwells-nitro5.cisco.com [10.19.43.166]) (authenticated bits=0) by rcdn-core-3.cisco.com (8.15.2/8.15.2) with ESMTPSA id x2KEgPl6026958 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NO); Wed, 20 Mar 2019 14:42:26 GMT To: "Acee Lindem (acee)" , "lsr@ietf.org" Cc: Alvaro Retana , "draft-ietf-lsr-isis-rfc5306bis@ietf.org" References: <17641FA5-F07A-41E1-B2F4-ECE888FF5B16@cisco.com> From: Paul Wells Message-ID: <814d8dfa-f121-3318-4008-2683302f92a2@cisco.com> Date: Wed, 20 Mar 2019 09:42:24 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <17641FA5-F07A-41E1-B2F4-ECE888FF5B16@cisco.com> Content-Type: multipart/alternative; boundary="------------F98D30CA5269C2FDFAB905B6" Content-Language: en-US X-Authenticated-User: pauwells X-Outbound-SMTP-Client: 10.19.43.166, sjc-pauwells-nitro5.cisco.com X-Outbound-Node: rcdn-core-3.cisco.com Archived-At: Subject: Re: [Lsr] WG Last Call for "Restart Signaling for IS-IS" - draft-ietf-lsr-isis-rfc5306bis-01 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2019 14:42:30 -0000 This is a multi-part message in MIME format. --------------F98D30CA5269C2FDFAB905B6 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Support (as co-author). Paul On 3/19/19 9:30 AM, Acee Lindem (acee) wrote: > > This begins a 3 WG last call for the subject document. The extra week > is since the IETF is next week. Please enter your support or objection > to the document before 12:00 AM (EDT) on Wednesday, April 3^rd , 2019. > > Thanks, > Acee > --------------F98D30CA5269C2FDFAB905B6 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Support (as co-author).

Paul

On 3/19/19 9:30 AM, Acee Lindem (acee) wrote:

This begins a 3 WG last call for the subject document. The extra week is since the IETF is next week. Please enter your support or objection to the document before 12:00 AM (EDT) on Wednesday, April 3rd, 2019.

 

Thanks,
Acee


--------------F98D30CA5269C2FDFAB905B6-- From nobody Wed Mar 20 07:46:50 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 305FD1279A8; Wed, 20 Mar 2019 07:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 nVLxrqpeaG_c; Wed, 20 Mar 2019 07:46:46 -0700 (PDT) Received: from mail-it1-x133.google.com (mail-it1-x133.google.com [IPv6:2607:f8b0:4864:20::133]) (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 98AD9127988; Wed, 20 Mar 2019 07:46:46 -0700 (PDT) Received: by mail-it1-x133.google.com with SMTP id h9so10702601itl.1; Wed, 20 Mar 2019 07:46:46 -0700 (PDT) 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=oF2KQGI3+fYrh2m1rvnOAE+3/dzXgg/0O59MAFfpyLY=; b=u1LiPOI1bKoX92FWnFy2+UUxy9AWz3xqqFVHRAMnFdz7q2pYimy81YtDdP7R56b2yu Jc1/1dU14XodWMFdWB9zI+DthhLVFJv69MD5iAq+XzGqVTQ7RiiV+HSQCb0K69/x//+E i0lauCCa7er44Ia3S/us0wdAG3Fs0WQSJwdeU24noeBsydvKjDT4M119zV2hrJugtOFh dTu+K6GTe+qP5hXEepIsv4HtXT3LaBFKlhnnPm27OEaQhZqpalAB7A3o3Y7iwZm+YhLH etSzO6+LHz1CC+ECulfRss63cjIrEOXhD5uznB7So1aku1wAFWtyCzYsEGpVXKuLwWEl b/UA== 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=oF2KQGI3+fYrh2m1rvnOAE+3/dzXgg/0O59MAFfpyLY=; b=sMbzzj40JeFPflcgDNBHGPTZlr+zfoQdrGL/LFkZ2dQ3CCqPZRyCux+pKyGVg/9jlC Ez7xSRO+MqQqdET6/BOQmeKrnyesb6mE43CYCnQuiNe+fSbVn8Dg/GZcY6cJoJsspECy 7h58mwcpO07n5zrlfbVGqpx3fUW/po4n8ZN5OdEiDjgo4AKRwOdmHB27LfdMYqZwi1Zi hIED0yGkcKxgVvrraItFg7JkrR8yXNKgO7bfIlI9dcC9L/eYgcw26rm/Yt2KzFBf75/J 6K2MZH54fefyVKZLlVf8e5lXf3johLTQmuUteDlwG8jBVmiBOwCXX/5zTk7EK2FPaLTm OKFw== X-Gm-Message-State: APjAAAWK0bjUttMmh8HxEOM3ZjkJ9sdXkCiqRkSgQljva9XeZ8h8bk9r /HzC1SBUS8L7YTvtSW7Oyz87rg54g8QTL5ymJ1I= X-Google-Smtp-Source: APXvYqx74s5/9FCHQ48/PGssle/6csSLOvNarfT9VC96IZAmWNrMqGMm+yk3nY7ugV6lAIuR9kPHh9bfpzySNK/Yq5o= X-Received: by 2002:a24:ba1a:: with SMTP id p26mr5304198itf.150.1553093205927; Wed, 20 Mar 2019 07:46:45 -0700 (PDT) MIME-Version: 1.0 References: <17641FA5-F07A-41E1-B2F4-ECE888FF5B16@cisco.com> In-Reply-To: <17641FA5-F07A-41E1-B2F4-ECE888FF5B16@cisco.com> From: sridhar santhanam Date: Wed, 20 Mar 2019 07:46:34 -0700 Message-ID: To: "Acee Lindem (acee)" Cc: lsr@ietf.org, "draft-ietf-lsr-isis-rfc5306bis@ietf.org" , Alvaro Retana Content-Type: multipart/alternative; boundary="000000000000d7acc3058487b0f8" Archived-At: Subject: Re: [Lsr] WG Last Call for "Restart Signaling for IS-IS" - draft-ietf-lsr-isis-rfc5306bis-01 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2019 14:46:49 -0000 --000000000000d7acc3058487b0f8 Content-Type: text/plain; charset="UTF-8" Support this draft. Thanks, Sridhar On Tue, Mar 19, 2019, 7:30 AM Acee Lindem (acee) wrote: > This begins a 3 WG last call for the subject document. The extra week is > since the IETF is next week. Please enter your support or objection to the > document before 12:00 AM (EDT) on Wednesday, April 3rd, 2019. > > > > Thanks, > Acee > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > --000000000000d7acc3058487b0f8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Support this draft.

Thanks,
Sridhar

On Tue,= Mar 19, 2019, 7:30 AM Acee Lindem (acee) <acee@cisco.com> wrote:

This begins a 3 WG = last call for the subject document. The extra week is since the IETF is nex= t week. Please enter your support or objection to the document before 12:00= AM (EDT) on Wednesday, April 3rd, 2019.

=C2=A0

Thanks,
Acee

_______________________________________________
Lsr mailing list
Lsr@ie= tf.org
https://www.ietf.org/mailman/listinfo/lsr
--000000000000d7acc3058487b0f8-- From nobody Wed Mar 20 15:20:54 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63A2812798C; Wed, 20 Mar 2019 15:20:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.996 X-Spam-Level: X-Spam-Status: No, score=-1.996 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, THIS_AD=0.001, UNPARSEABLE_RELAY=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 a4UoZ6mb1a5R; Wed, 20 Mar 2019 15:20:45 -0700 (PDT) Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (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 6921A13118F; Wed, 20 Mar 2019 15:20:45 -0700 (PDT) Received: by mail-ot1-x329.google.com with SMTP id q24so3727781otk.0; Wed, 20 Mar 2019 15:20:45 -0700 (PDT) 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; bh=6lYKVLknMaUhOvWE4/5JgVQS9g7IkvRQoYgU4ijXuoU=; b=Pz7qjpHpxVIZrSC83MsCOO+wVzJ0YefZIr0Fb9vCJqMjK4Y8CA9TnHBsWXqRpUW6pT oPH0aEBGxcta94AB0qYpeBe/VHGQR1jGJ5F9bJTI6TUkd9tDf8v+OSm2e2DMiF9TJT/q 5NMLLNCBy2sacGe4GUo6gwpdmqwRl8iMP7qnaZq5/+gi0nCwHYxP/VK7WTDyHKYJSFQe +K7q1fDWGb/ULgFs/nIyjMM81t29k1LcsmfKrmJDmLGnVKp3RGFx77zVq6sNTDeAfppq 8OY9qezTQe6prWO4qsbuVzW5Trz0LBd5xN3vm0nqifSMvALMhKaCpaw2Zn5L9SjdO0EW KJbQ== 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; bh=6lYKVLknMaUhOvWE4/5JgVQS9g7IkvRQoYgU4ijXuoU=; b=NWctglBc8EZimdpILg/e7SoPDFdRSm/TDvKAXw95UYVp54veLI2S4xBAfz79eS+q+P /7dSGjNXN/OfGSMyTmW5hw5hzxmwMh+zkt0+2mTnMJGxiHYwpI6fEnX5YYZc6lZV0jfh CznaJCRbr+y+WGV8xkMe+Qua1d68A7loUZMgy9cVRcjOMvth8eb2750z2ZNlaGR4gdep vVGrI/eE+7S7V3aeKBHMBtw4TtEK6em0cW0Tf+2crbE93aWIKcj7RgNbgIlztfE6ZgS6 16POTab0eurYPuq+z/FIiPucKzMAdKBWgQ+EntazB6MdjWoTOXXUDYjL7M+CgYLYYT9K n8AQ== X-Gm-Message-State: APjAAAUkV63l5FVaSHMo2g2gwSfrWjLMB10mHtAPSY75sDU4QiJkOGUG AjvXCi+nDiMuXByxF5w+DM8wCtKDvlYsKHVOo3PxMg== X-Google-Smtp-Source: APXvYqxC3/iA2GSX0R7dhRopAS1DEkBkXJD7f86tccVYVy4GQXWwSIwVIiYFWrqD2Z4w3uY+E/Bkj6fH8Mei6LemszU= X-Received: by 2002:a9d:6348:: with SMTP id y8mr299966otk.287.1553120443555; Wed, 20 Mar 2019 15:20:43 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Wed, 20 Mar 2019 15:20:42 -0700 From: Alvaro Retana MIME-Version: 1.0 Date: Wed, 20 Mar 2019 15:20:42 -0700 Message-ID: To: draft-ietf-isis-segment-routing-extensions@ietf.org Cc: Uma Chunduri , lsr-chairs@ietf.org, lsr@ietf.org Content-Type: multipart/alternative; boundary="00000000000054e5c605848e084d" Archived-At: Subject: [Lsr] AD Review of draft-ietf-isis-segment-routing-extensions-22 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2019 22:20:53 -0000 --00000000000054e5c605848e084d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear authors: I just finished reviewing this document. Please take a look at the in-line comments below. In general, I think that some more work is needed. I will wait for that before starting the IETF Last Call. There is a significant issue that I want to highlight here (there are also related comments in-line): - =C2=A72.1.1.2 talks about interaction with rfc7794 and a transition perio= d which apparently ends in this specification not being used. Am I reading that correctly? Thanks! Alvaro. [Line numbers come from idnits.] ... 107 1. Introduction 109 Segment Routing (SR) allows for a flexible definition of end-to-end 110 paths within IGP topologies by encoding paths as sequences of 111 topological sub-paths, called "segments". These segments are 112 advertised by the link-state routing protocols (IS-IS and OSPF). 113 Prefix segments represent an ecmp-aware shortest-path to a prefix (or 114 a node), as per the state of the IGP topology. Adjacency segments 115 represent a hop over a specific adjacency between two nodes in the 116 IGP. A prefix segment is typically a multi-hop path while an 117 adjacency segment, in most of the cases, is a one-hop path. SR's 118 control-plane can be applied to both IPv6 and MPLS data-planes, and 119 do not require any additional signaling (other than the regular IGP). 120 For example, when used in MPLS networks, SR paths do not require any 121 LDP or RSVP-TE signaling. Still, SR can interoperate in the presence 122 of LSPs established with RSVP or LDP. [nit] s/ecmp-aware/ECMP-aware 124 There are additional segment types, e.g., Binding SID defined in 125 [RFC8402]. This draft also defines an advertisement for one type of 126 BindingSID: the Mirror Context segment. [nit] s/BindingSID/Binding SID 128 This draft describes the necessary IS-IS extensions that need to be 129 introduced for Segment Routing operating on an MPLS data-plane. 131 Segment Routing architecture is described in [RFC8402]. [nit] s/Segment Routing architecture/The Segment Routing architecture 133 Segment Routing use cases are described in [RFC7855]. 135 2. Segment Routing Identifiers 137 Segment Routing architecture ([RFC8402]) defines different types of 138 Segment Identifiers (SID). This document defines the IS-IS encodings 139 for the IGP-Prefix-SID, the IGP-Adjacency-SID, the IGP-LAN-Adjacency- 140 SID and the Binding-SID. [nit] s/([RFC8402])/[RFC8402] [nit] s/Segment Routing architecture/The Segment Routing architecture [major] rfc8402 doesn't use the names above. Please be consistent. 142 2.1. Prefix Segment Identifier (Prefix-SID Sub-TLV) 144 A new IS-IS sub-TLV is defined: the Prefix Segment Identifier sub-TLV 145 (Prefix-SID sub-TLV). 147 The Prefix-SID sub-TLV carries the Segment Routing IGP-Prefix-SID as 148 defined in [RFC8402]. The 'Prefix SID' MUST be unique within a given 149 IGP domain (when the L-flag is not set). The 'Prefix SID' MUST carry 150 an index (when the V-flag is not set) that determines the actual SID/ 151 label value inside the set of all advertised SID/label ranges of a 152 given router. A receiving router uses the index to determine the 153 actual SID/label value in order to construct forwarding state to a 154 particular destination router. [major] What if the Prefix SID is not unique? What should the receiver do? [major] "...MUST carry an index...that determines the actual SID/label value..." What are you trying to specify with this "MUST"? The description of the V-flag (below) already points at the value being an index, but the qualification ("that determines...") makes the enforcement of this "MUST" more complex: the receiver has to verify that the index actually results in a SID/label inside a range for it to be valid. What should the receiver do if that is not the case? Suggestion: Rearrange the text so that the TLV and its fields are described first. I think that then some of the text above won't be needed. 156 In many use-cases a 'stable transport' IP Address is overloaded as an 157 identifier of a given node. Because the IP Prefixes may be re- 158 advertised into other levels there may be some ambiguity (e.g. 159 Originating router vs. L1L2 router) for which node a particular IP 160 prefix serves as identifier. The Prefix-SID sub-TLV contains the 161 necessary flags to disambiguate IP Prefix to node mappings. 162 Furthermore if a given node has several 'stable transport' IP 163 addresses there are flags to differentiate those among other IP 164 Prefixes advertised from a given node. [minor] Again, this text may be clearer if the TLV description was presented first. If you decide not to rearrange the text, at least put forward references so readers can look forward to find out how the statement above is achieved. ... 180 When the IP Reachability TLV is propagated across level boundaries, 181 the Prefix-SID sub-TLV SHOULD be kept. [major] When would this sub-TLV not be kept? IOW, why is that not a "MUST"= ? =C2=A72.1.2: "The Prefix-SID sub-TLV MUST be preserved when the IP Reachabi= lity TLV gets propagated across level boundaries." I'm not saying that one way is correct...either one may be. Just be consistent. [minor] I'm assuming that "IP Reachability TLV" means one of the TLVs above, true? It may be worth clarifying that. 183 The Prefix-SID sub-TLV has the following format: 185 0 1 2 3 186 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Type | Length | Flags | Algorithm | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | SID/Index/Label (variable) | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 where: 195 Type: TBD, suggested value 3 [major] This value (and all the others in the document) are not "suggested values", they have been already allocated by IANA. Please update the individual descriptions and the IANA Considerations section accordingly. 197 Length: variable. [minor] Yes, variable, but it can only have two values: 5 or 6. 199 Flags: 1 octet field of following flags: 201 0 1 2 3 4 5 6 7 202 +-+-+-+-+-+-+-+-+ 203 |R|N|P|E|V|L| | 204 +-+-+-+-+-+-+-+-+ 206 where: 208 R-Flag: Re-advertisement flag. If set, then the prefix to 209 which this Prefix-SID is attached, has been propagated by the 210 router either from another level (i.e., from level-1 to level-2 211 or the opposite) or from redistribution (e.g.: from another 212 protocol). [major] Should it be used to avoid looping as well? Or is there no risk of that in this case? ... 236 Other bits: MUST be zero when originated and ignored when 237 received. [major] Do you expect IANA to handle the assignment of those other bits? 239 Algorithm: the router may use various algorithms when calculating 240 reachability to other nodes or to prefixes attached to these 241 nodes. Algorithms identifiers are defined in Section 3.2. 242 Examples of these algorithms are metric based Shortest Path First 243 (SPF), various sorts of Constrained SPF, etc. The algorithm field 244 of the Prefix-SID contains the identifier of the algorithm the 245 router has used in order to compute the reachability of the prefix 246 to which the Prefix-SID is associated. 248 At origination, the Prefix-SID algorithm field MUST be set to 0 or 249 to any value advertised in the SR-Algorithm sub-TLV (Section 3.2). [major] What should a receiver do if the Algorithm value doesn't match what has been advertised in the SR-Algorithm Sub-TLV? ... 282 2.1.1.2. R and N Flags 284 The R-Flag MUST be set for prefixes that are not local to the router 285 and either: 287 advertised because of propagation (Level-1 into Level-2); 289 advertised because of leaking (Level-2 into Level-1); 291 advertised because of redistribution (e.g.: from another 292 protocol). 294 In the case where a Level-1-2 router has local interface addresses 295 configured in one level, it may also propagate these addresses into 296 the other level. In such case, the Level-1-2 router MUST NOT set the 297 R bit. The R-bit MUST be set only for prefixes that are not local to 298 the router and advertised by the router because of propagation and/or 299 leaking. [minor] This last sentence is redundant with the start of this section. Please specify the behavior just once. 301 The N-Flag is used in order to define a Node-SID. A router MAY set 302 the N-Flag only if all of the following conditions are met: 304 The prefix to which the Prefix-SID is attached is local to the 305 router (i.e., the prefix is configured on one of the local 306 interfaces, e.g., a 'stable transport' loopback). 308 The prefix to which the Prefix-SID is attached MUST have a Prefix 309 length of either /32 (IPv4) or /128 (IPv6). [major] "The prefix...MUST have a Prefix length..." This condition is not worded as one; perhaps: "The prefix...has a Prefix length..." [minor] Why is the N-Flag needed? If the setting is optional ("MAY"), then not setting it doesn't imply that the conditions are not met... [major] It is clearly an error if both the R-Flag and N-Flag are set, right? What should the receiver do in that case? 311 The router MUST ignore the N-Flag on a received Prefix-SID if the 312 prefix has a Prefix length different than /32 (IPv4) or /128 (IPv6). 314 [RFC7794] also defines the N and R flags and with the same semantics 315 of the equivalent flags defined in this document. There will be a 316 transition period where both sets of flags will be used and 317 eventually only the flags of the Prefix Attributes will remain. 318 During the transition period implementations supporting the N and R 319 flags defined in this document and the N and R flags defined in 320 [RFC7794] MUST advertise and parse all flags. In case the received 321 flags have different values, the value of the flags defined in 322 [RFC7794] prevails. [major] "...transition period where both sets of flags will be used and eventually only the flags of the Prefix Attributes will remain" To be honest, you lost me here? Please explain what will the transition period be between? [major] If "both sets of flags will be used and eventually only the [already defined] flags of the Prefix Attributes will remain", why do we need the new ones? [major] "MUST advertise and parse all flags" What does this mean? By "all flags" I guess you mean the N and R flags...but if both this document and rfc7794 are implemented, it seems to me that the specification above is really meaningless. [major] "In case the received flags have different values..." For a second it seemed to me that what you really wanted was for the flags in this document to behave the same way as the flags defined in rfc7794...the easy solution to that (and to avoid my questions listed before rfc7794 was mentioned) would have been to just point at rfc7794 as the place where the Flags are defined. However, it looks like the definitions (at least for the R-Flag) are not the same. Is that on purpose or is it just an oversight? One piece of information that might make this discussion relevant is understanding the significance of these Flags...but neither document offers any specific use, beyond simply "it may be useful for other routers to know" (rfc7794, =C2=A72.2). 324 2.1.1.3. E and P Flags 326 When calculating the outgoing label for the prefix, the router MUST 327 take into account E and P flags advertised by the next-hop router, if 328 next-hop router advertised the SID for the prefix. This MUST be done 329 regardless of next-hop router contributing to the best path to the 330 prefix or not. [major] "the router MUST take into account" What normative action is standardized with that phrase? It would be clearer/better if the behavior is explicitly specified in function of the flags (as sone below). s/MUST/must [major] "This MUST be done regardless of next-hop router contributing to the best path to the prefix or not." This what? I'm assuming the text refers to "take into account"... Same comment as before: s/MUST/must ... 366 2.1.2. Prefix-SID Propagation 368 The Prefix-SID sub-TLV MUST be preserved when the IP Reachability TLV 369 gets propagated across level boundaries. [major] =C2=A72.1 says that it SHOULD. Please be consistent...and, specify behavior only once. 371 The level-1-2 router that propagates the Prefix-SID sub-TLV between 372 levels MUST set the R-flag. 374 If the Prefix-SID contains a global index (L and V flags unset) and 375 it is propagated as such (with L and V flags unset), the value of the 376 index MUST be preserved when propagated between levels. 378 The level-1-2 router that propagates the Prefix-SID sub-TLV between 379 levels MAY change the setting of the L and V flags in case a local 380 label value is encoded in the Prefix-SID instead of the received 381 value. [major] Up to now, I had been assuming that propagating and preserving meant not changing the sub-TLV (except for the R-Flag). But these last paragraphs indicate that not only can some flags be changed, but the contents can completely change. It would be ideal if the valid operations on the sub-TLV were discussed (or at least referenced) when the preserving behavior was first introduced (I think in =C2=A72.1). ... 409 2.2.1. Adjacency Segment Identifier (Adj-SID) Sub-TLV 411 The following format is defined for the Adj-SID sub-TLV: 413 0 1 2 3 414 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Type | Length | Flags | Weight | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | SID/Label/Index (variable) | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 421 where: 423 Type: TBD, suggested value 31 425 Length: variable. [minor] Yes, variable, but it can only have two values... 427 Flags: 1 octet field of following flags: 429 0 1 2 3 4 5 6 7 430 +-+-+-+-+-+-+-+-+ 431 |F|B|V|L|S|P| | 432 +-+-+-+-+-+-+-+-+ 434 where: 436 F-Flag: Address-Family flag. If unset, then the Adj-SID refers 437 to an adjacency with outgoing IPv4 encapsulation. If set then 438 the Adj-SID refers to an adjacency with outgoing IPv6 439 encapsulation. [major] This document describes the operation on the MPLS data plane, right? The F-Flag talks about the outgoing encapsulation...but that could simply be the next label in the MPLS stack, right? What am I missing? I get the impression that there's a relationship between what this Flag points to and something else...but I just don't know what. 441 B-Flag: Backup flag. If set, the Adj-SID is eligible for 442 protection (e.g.: using IPFRR or MPLS-FRR) as described in 443 [RFC8355]. [major] Because the specification of the B-Flag depends directly on rfc8355, it should be a Normative reference. Looking at rfc8355, I couldn't find a place where it talks about eligibility for protection...just text about potential strategies, but (honestly) nothing that I would call Normative. Please clarify. Perhaps rfc8402 might be a better reference. [major] I'm assuming that this description (pointing at rfc8355), plus the text below about allocation of Adj-SIDs should result in some action related to the protection...what is that? IOW, presented with the B-Flag set, what action should a node take? 445 V-Flag: Value flag. If set, then the Adj-SID carries a value. 446 By default the flag is SET. [minor] Is the description the same at the V-Flag in =C2=A72.1? If so, the= n indicating that, or at least also pointing out here that the value is carried instead of an index would be helpful. 448 L-Flag: Local Flag. If set, then the value/index carried by 449 the Adj-SID has local significance. By default the flag is 450 SET. [major] Looking back at =C2=A72.1.1.1, what are the conditions for which th= e combination of the V and L-Flags are valid/invalid? Do the same conditions apply? ... 460 Other bits: MUST be zero when originated and ignored when 461 received. [major] Do you expect IANA to handle the assignment of those other bits? ... 469 An SR capable router MAY allocate an Adj-SID for each of its 470 adjacencies and SHOULD set the B-Flag when the adjacency is 471 eligible for protection (IP or MPLS). [major] If eligible for protection, when would the router not set the B-Flag? IOW, why is that not a MUST? Beyond that, I think that the use of SHOULD is in conflict with the definition of the B-Flag (above): "If set, the Adj-SID is eligible for protection...", which implies that it isn't eligible if it's not set...but the SHOULD opens the door for not setting the Flag... ... 479 When the P-flag is not set, the Adj-SID MAY be persistent. When 480 the P-flag is set, the Adj-SID MUST be persistent. [major] If the adjacency is persistent, why/when would the P-Flag not be set? ... 488 2.2.2. Adjacency Segment Identifiers in LANs ... 537 Other bits: MUST be zero when originated and ignored when 538 received. [major] Do you expect IANA to handle the assignment of those other bits? ... 544 System-ID: 6 octets of IS-IS System-ID of length "ID Length" as 545 defined in [ISO10589]. [major] Which System-ID? [major] "6 octets of...length "ID Length"" ?? 547 SID/Index/Label as defined in Section 2.1.1.1. 549 Multiple LAN-Adj-SID sub-TLVs MAY be encoded. Note that this sub-TLV 550 MUST NOT appear in TLV 141. 552 When the P-flag is not set, the LAN-Adj-SID MAY be persistent. When 553 the P-flag is set, the LAN-Adj-SID MUST be persistent. 555 In case one TLV-22/23/222/223 (reporting the adjacency to the DIS) 556 can't contain the whole set of LAN-Adj-SID sub-TLVs, multiple 557 advertisements of the adjacency to the DIS MUST be used and all 558 advertisements MUST have the same metric. 560 Each router within the level, by receiving the DIS PN LSP as well as 561 the non-PN LSP of each router in the LAN, is capable of 562 reconstructing the LAN topology as well as the set of Adj-SID each 563 router uses for each of its neighbors. 565 A label is encoded in 3 octets (in the 20 rightmost bits). 567 An index is encoded in 4 octets. [minor] Some of the information above (for example, the paragraph about the P-Flag and these last 2 sentences) seems unnecessary given that the description of these fields is already done somewhere else. 569 2.3. SID/Label Sub-TLV 571 The SID/Label sub-TLV may be present in the following TLVs/sub-TLVs 572 defined in this document: 574 SR-Capabilities Sub-TLV (Section 3.1) 576 SR Local Block Sub-TLV (Section 3.3) 578 SID/Label Binding TLV (Section 2.4) 580 Multi-Topology SID/Label Binding TLV (Section 2.5) [nit] It might have been nice, in line with the OSPF work, to flip Sections 2 and 3. Just a nit... 582 Note that the code point used in all of the above cases is the SID/ 583 Label Sub-TLV code point assigned by IANA in the "sub-TLVs for TLV 584 149 and 150" registry. [major] Because this document is setting up that new registry, we don't have to wait for IANA to assign anything: the document can specify it. IOW, the paragraph above is not needed. 586 The SID/Label sub-TLV contains a SID or a MPLS Label. The SID/Label 587 sub-TLV has the following format: 589 0 1 2 3 590 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 591 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 592 | Type | Length | 593 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 594 | SID/Label (variable) | 595 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 where: 599 Type: TBD, suggested value 1 601 Length: variable [major] Yes, variable...but right now only one value is defined. There's a finite number of possibilities... 602 SID/Label: if length is set to 3 then the 20 rightmost bits 603 represent a MPLS label. [major] Is that it..? What about the SID? 605 2.4. SID/Label Binding TLV ... 619 The SID/Label Binding TLV has Type TBD (suggested value 149), and has 620 the following format: [nit] No need to talk about the Type twice. 622 0 1 2 3 623 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 624 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 625 | Type | Length | Flags | RESERVED | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 | Range | Prefix Length | Prefix | 628 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 629 // Prefix (continued, variable) // 630 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 631 | SubTLVs (variable) | 632 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 634 Figure 1: SID/Label Binding TLV format 636 o Type: TBD, suggested value 149 ... 657 2.4.1. Flags ... 671 M-Flag: Mirror Context flag. Set if the advertised SID 672 corresponds to a mirrored context. The use of the M flag is 673 described in [RFC8402]. [major] Where? Note that rfc8402 says that "The Mirror SID is advertised using the Binding segment defined in SR IGP protocol extensions [ISIS-SR-EXT].", pointing back at this document. [minor] Some places use *-Flag and others "* flag", please be consistent. 675 S-Flag: If set, the SID/Label Binding TLV SHOULD be flooded across 676 the entire routing domain. If the S flag is not set, the SID/ 677 Label Binding TLV MUST NOT be leaked between levels. This bit 678 MUST NOT be altered during the TLV leaking. [major] If the S-Flag is set, when would the TLV not be flooded across the entire domain? IOW, why is the SHOULD not a MUST? 680 D-Flag: when the SID/Label Binding TLV is leaked from level-2 to 681 level-1, the D bit MUST be set. Otherwise, this bit MUST be 682 clear. SID/Label Binding TLVs with the D bit set MUST NOT be 683 leaked from level-1 to level-2. This is to prevent TLV looping 684 across levels. [minor] What about leaking from L2 to L1 with the Flag set? [minor] The text uses Flag, but in some cases bit is used as well. Please be consistent. ... 695 An implementation MAY decide not to honor the S-flag in order not 696 to leak Binding TLV's between levels (for policy reasons). In all 697 cases, the D flag MUST always be set by any router leaking the 698 Binding TLV from level-2 into level-1 and MUST be checked when 699 propagating the Binding TLV from level-1 into level-2. If the D 700 flag is set, the Binding TLV MUST NOT be propagated into level-2. [major] s/implementation MAY decide/implementation may decide There's no Normative action there. [major] Regardless of whether MAY/may is used, the statement in the first sentence contradicts the "MUST NOT be leaked" Normative statement. Given that there are exceptions, maybe "SHOULD NOT" would be more appropriate. [major] This last paragraph seems to contain the same information as the text describing the S-Flag. Please don't duplicate specifications. 702 Other bits: MUST be zero when originated and ignored when 703 received. [major] Do you expect IANA to handle the assignment of those other bits? 705 2.4.2. Range 707 The 'Range' field provides the ability to specify a range of 708 addresses and their associated Prefix SIDs. This advertisement 709 supports the SRMS functionality. It is essentially a compression 710 scheme to distribute a continuous Prefix and their continuous, 711 corresponding SID/Label Block. If a single SID is advertised then 712 the range field MUST be set to one. For range advertisements > 1, 713 the number of addresses that need to be mapped into a Prefix-SID and 714 the starting value of the Prefix-SID range. [nit] The last sentence sounds incomplete... 716 Example 1: if the following router addresses (loopback addresses) 717 need to be mapped into the corresponding Prefix SID indexes. [minor] Suggestion: move the examples to the end of =C2=A72.4...after all t= he fields have been discussed. 719 Router-A: 192.0.2.1/32, Prefix-SID: Index 1 720 Router-B: 192.0.2.2/32, Prefix-SID: Index 2 721 Router-C: 192.0.2.3/32, Prefix-SID: Index 3 722 Router-D: 192.0.2.4/32, Prefix-SID: Index 4 724 0 1 2 3 725 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 726 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 727 | Type | Length |0|0| | RESERVED | 728 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 | Range =3D 4 | /32 | 192 | 730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 731 | .0 | .2 | .1 |Prefix-SID Type| 732 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 | sub-TLV Length| Flags | Algorithm | | 734 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 735 | 1 | 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [nit] The Prefix Length should be "32", not "/32". [nit] The Prefix itself is one field (in the description), but it looks like 4 separate fields above...and the numbers should not have "." in them. [minor] It looks like the fields starting with "Prefix-SID Type" belong to the Prefix-SID Sub-TLV, but that is not explained anywhere (yet). The Algorithm field is not set...nor are the Flags. 738 Example-2: If the following prefixes need to be mapped into the 739 corresponding Prefix-SID indexes: 741 10.1.1/24, Prefix-SID: Index 51 742 10.1.2/24, Prefix-SID: Index 52 743 10.1.3/24, Prefix-SID: Index 53 744 10.1.4/24, Prefix-SID: Index 54 745 10.1.5/24, Prefix-SID: Index 55 746 10.1.6/24, Prefix-SID: Index 56 747 10.1.7/24, Prefix-SID: Index 57 [major] Please use addresses in the rfc5737 reserved ranges. [minor] It would have been nice to see an IPv6 example (see rfc3849). 749 0 1 2 3 750 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 752 | Type | Length |0|0| | RESERVED | 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 | Range =3D 7 | /24 | 10 | 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 | .1 | .1 |Prefix-SID Type| sub-TLV Length| 757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 | Flags | Algorithm | | 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 | 51 | 761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ [] Same comments as above. ... 778 2.4.3. Prefix Length, Prefix ... 784 The 'Prefix Length' field contains the length of the prefix in bits. 785 Only the most significant octets of the Prefix are encoded. (i.e., 1 786 octet for prefix length 1 up to 8, 2 octets for prefix length 9 to 787 16, 3 octets for prefix length 17 up to 24 and 4 octets for prefix 788 length 25 up to 32, ...., 16 octets for prefix length 113 up to 128). [nit] s/encoded. (i.e.,/encoded (i.e., 790 2.4.4. Mapping Server Prefix-SID 792 The Prefix-SID sub-TLV (suggested value 3) is defined in Section 2.1 793 and contains the SID/index/label value associated with the prefix and 794 range. The Prefix-SID SubTLV MUST be present in the SID/Label 795 Binding TLV unless the M-flag is set in the Flags field of the parent 796 TLV. [major] Does it then mean that the Prefix-SID SubTLV must not be present if the M-Flag is not set? [nit] s/SubTLV/Sub-TLV (as it is used almost everywhere else) 798 A node receiving an SRMS entry for a prefix MUST check the existence 799 of such prefix in its link-state database prior to consider and use 800 the associated SID. [major] What does it mean for the prefix to exist in the link-state database? Does it mean that it must have been advertised in a "normal" routing TLV, or something else? I ask not only to clarify, but because =C2=A72.4.3 says that the "'Prefix' does not need to correspond to a routab= le prefix of the originating node". [Ah...I think I understand. Because "the mapping server does not specify the originator of a prefix" (=C2=A72.4.4.2), then the prefix is obviously n= ot routable in the context of the originating node (the server)...but it should be routable in general. Is that it?] 802 2.4.4.1. Prefix-SID Flags 804 The Prefix-SID flags are defined in Section 2.1. The Mapping Server 805 MAY advertise a mapping with the N flag set when the prefix being 806 mapped is known in the link-state topology with a mask length of 32 807 (IPv4) or 128 (IPv6) and when the prefix represents a node. The 808 mechanisms through which the operator defines that a prefix 809 represents a node are outside the scope of this document (typically 810 it will be through configuration). [major] =C2=A72.1.1.2 says that the "router MAY set the N-Flag only if... t= he prefix to which the Prefix-SID is attached MUST have a Prefix length of either /32 (IPv4) or /128 (IPv6)." That is similar to what the text above says (but the text talks about "the prefix...known in the link-state topology"), and it is related to the last question in the previous section. Does the prefix being in the link-state database/topology mean that the match is exact (to the prefix advertised), or is a supernet ok? 812 The other flags defined in Section 2.1 are not used by the Mapping 813 Server and MUST be ignored at reception. [major] How does the receiver know that the sub-TLV was originated by a Mapping Server? Is it the case that it would originate a Binding TLV? IOW, would the other flags always be ignored when the sub-TLV is included in the Binding TLV (but not other TLVs)? Does this apply also to the Multi-Topology SID/Label Binding TLV (=C2=A72.5)? 815 2.4.4.2. PHP Behavior when using Mapping Server Advertisements ... 823 o A prefix reachability advertisement for the prefix has been 824 received which includes the Extended Reachability Attribute Flags 825 sub-TLV ([RFC7794]). [nit] s/([RFC7794])/[RFC7794] 827 o X and R flags are both set to 0 in the Extended Reachability 828 Attribute Flags sub-TLV. 830 In the absence of an Extended Reachability Attribute Flags sub-TLV 831 ([RFC7794]) the A flag in the binding TLV indicates that the 832 originator of a prefix reachability advertisement is directly 833 connected to the prefix and thus PHP MUST be done by the neighbors of 834 the router originating the prefix reachability advertisement. Note 835 that A-flag is only valid in the original area in which the Binding 836 TLV is advertised. [nit] s/([RFC7794])/[RFC7794] [major] =C2=A72.4.1 says that "if the Binding TLV is leaked...the A-flag MU= ST be cleared", which is not the same as not considering it valid (ignoring, as described above). In any case, please be specific about the functionality in the description. 838 2.4.4.3. Prefix-SID Algorithm 840 The algorithm field contains the identifier of the algorithm the 841 router MUST use in order to compute reachability to the range of 842 prefixes. Use of the algorithm field is described in Section 2.1. [major nit] At first glance, it looks like this section is not needed because it repeats what =C2=A72.1 already says about the algorithm. But th= is paragraph refers to "the algorithm the router MUST use in order to compute reachability", in contrast to the definition of the field in =C2=A72.1: "Th= e algorithm field...contains the identifier of the algorithm the router has used in order to compute the reachability..." ... 901 3.1. SR-Capabilities Sub-TLV ... 909 The Router Capability TLV specifies flags that control its 910 advertisement. The SR Capabilities sub-TLV MUST be propagated 911 throughout the level and MUST NOT be advertised across level 912 boundaries. Therefore Router Capability TLV distribution flags are 913 set accordingly, i.e., the S flag in the Router Capability TLV 914 ([RFC7981]) MUST be unset. [nit] s/([RFC7981])/[RFC7981] ... 943 I-Flag: MPLS IPv4 flag. If set, then the router is capable of 944 processing SR MPLS encapsulated IPv4 packets on all interfaces. 946 V-Flag: MPLS IPv6 flag. If set, then the router is capable of 947 processing SR MPLS encapsulated IPv6 packets on all interfaces. [minor] Just curious: How are these flags used? Given that the data plane we're dealing with is MPLS... ... 981 The originating router MUST ensure the order is same after a graceful 982 restart (using checkpointing, non-volatile storage or any other 983 mechanism) in order to guarantee the same order before and after GR. [nit] s/order is same/order is the same ... 1015 3.2. SR-Algorithm Sub-TLV ... 1046 The SR-Algorithm sub-TLV is optional, it MAY only appear a single 1047 time inside the Router Capability TLV. [major] "MAY only appear a single time" means that it can appear more than once. If it does show up more than once, what should the the receiver do? 1049 When the originating router does not advertise the SR-Algorithm sub- 1050 TLV, then all the Prefix-SIDs advertised by the router MUST have 1051 algorithm field set to 0. Any receiving router MUST assume SPF 1052 algorithm (i.e., Shortest Path First). [minor] It seems to me that this part of the specification would fit better in =C2=A72.1. [major] Besides maybe being redundant, what is specified in the last sentence? If the indication of the algorithm is explicit, then I don't understand what "MUST assume" is trying to mandate. 1054 When the originating router does advertise the SR-Algorithm sub-TLV, 1055 then algorithm 0 MUST be present while algorithm 1 MAY be present. [nit] I think that it is clear that algorithm 1 is optional. I would take that last part out just because other algorithms may be defined in the future...and the important part at this point is the inclusion of algorithm 0. 1057 The SR-Algorithm sub-TLV has following format: [nit] s/has following/has the following ... 1073 Algorithm: 1 octet of algorithm Section 2.1 [minor] The Algorithm field is described in this section, not in 2.1. 1075 3.3. SR Local Block Sub-TLV 1077 The SR Local Block (SRLB) Sub-TLV contains the range of labels the 1078 node has reserved for local SIDs. Local SIDs are used, e.g., for 1079 Adjacency-SIDs, and may also be allocated by other components than 1080 IS-IS protocol. As an example, an application or a controller may 1081 instruct the router to allocate a specific local SID. Therefore, in 1082 order for such applications or controllers to know what are the loca= l 1083 SIDs available in the router, it is required that the router 1084 advertises its SRLB. [nit] s/than IS-IS protocol/than the IS-IS protocol ... 1122 The originating router MUST NOT advertise overlapping ranges. [major] What should the receiver do if the ranges overlap? I'm assuming the same thing as what was specified before...please be specific. 1124 It is important to note that each time a SID from the SRLB is 1125 allocated, it SHOULD also be reported to all components (e.g.: 1126 controller or applications) in order for these components to have an 1127 up-to-date view of the current SRLB allocation and in order to avoid 1128 collision between allocation instructions. 1130 Within the context of IS-IS, the reporting of local SIDs is done 1131 through IS-IS Sub-TLVs such as the Adjacency-SID. However, the 1132 reporting of allocated local SIDs may also be done through other 1133 means and protocols which mechanisms are outside the scope of this 1134 document. [major] "SHOULD also be reported to all components" Because that is outside the scope, then it shouldn't be a Normative statement. s/SHOULD/should ... 1170 4. Non backward compatible changes with prior versions of this document [major] I find this section unnecessary. If you want to keep it, please move it to an Appendix and don't use Normative language. ... 1190 5. IANA Considerations 1192 This documents request allocation for the following TLVs and subTLVs= . [minor] IANA may be ok, but I find the formatting below a little confusing. A table may be a better option. ... 1313 This document creates the following sub-TLV Registry: ... [major] Please indicate what the range is. 1333 6. Security Considerations 1335 With the use of the extensions defined in this document, IS-IS 1336 carries information which will be used to program the MPLS data plan= e 1337 [RFC3031]. In general, the same types of attacks that can be carrie= d 1338 out on the IP/IPv6 control plane can be carried out on the MPLS 1339 control plane resulting in traffic being misrouted in the respective 1340 data planes. However, the latter may be more difficult to detect an= d 1341 isolate. Existing security extensions as described in [RFC5304] and 1342 [RFC5310] apply to these segment routing extensions. [nit] Maybe break up the paragraph into multiple ones with independent points. [major] With the last sentence, are you implying that authentication is required when IS-IS is carrying SR extensions? If so, please be explicit. Why would these extensions be different than any other extension? [minor] The companion OSPF documents added the following paragraph to the Security Considerations as a result of one of the reviews...perhaps consider including something similar: Implementations MUST assure that malformed TLV and Sub-TLV defined in this document are detected and do not provide a vulnerability for attackers to crash the OSPFv2 router or routing process. Reception of malformed TLV or Sub-TLV SHOULD be counted and/or logged for further analysis. Logging of malformed TLVs and Sub-TLVs SHOULD be rate-limited to prevent a Denial of Service (DoS) attack (distributed or otherwise) from overloading the OSPF control plane. ... 1415 9.1. Normative References ... [minor] I think that these references can be Informative: 1463 [RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic 1464 Engineering", RFC 5305, DOI 10.17487/RFC5305, October 1465 2008, . 1467 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, 1468 DOI 10.17487/RFC5308, October 2008, 1469 . ... 1527 Les Ginsberg (editor) 1528 Cisco Systems, Inc. 1529 IT [nit] I didn't know you had moved. ;-) --00000000000054e5c605848e084d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
Dear authors:

I just finished reviewing this document.=C2=A0 P= lease take a look at the in-line comments below.=C2=A0 In general, I think = that some more work is needed.=C2=A0 I will wait for that before starting t= he IETF Last Call.

There is a significant issue that I want to highlight here (ther= e are also related comments in-line):

- =C2=A72.1.1.2 talks about interaction with = rfc7794 and a transition period which apparently ends in this specification= not being used.=C2=A0 Am I reading that correctly?

Thanks!

Alvaro.

[Line numbers come from idnits.= ]

...
107 1.=C2=A0 Introduction
=
109 =C2=A0 Segment Routing (SR) allows for a flex= ible definition of end-to-end
110 =C2=A0 paths within = IGP topologies by encoding paths as sequences of
111 = =C2=A0 topological sub-paths, called "segments".=C2=A0 These segm= ents are
112 =C2=A0 advertised by the link-state routi= ng protocols (IS-IS and OSPF).
113 =C2=A0 Prefix segme= nts represent an ecmp-aware shortest-path to a prefix (or
114 =C2=A0 a node), as per the state of the IGP topology.=C2=A0 Adjac= ency segments
115 =C2=A0 represent a hop over a specif= ic adjacency between two nodes in the
116 =C2=A0 IGP.= =C2=A0 A prefix segment is typically a multi-hop path while an
117 =C2=A0 adjacency segment, in most of the cases, is a one-hop p= ath.=C2=A0 SR's
118 =C2=A0 control-plane can be ap= plied to both IPv6 and MPLS data-planes, and
119 =C2= =A0 do not require any additional signaling (other than the regular IGP).
120 =C2=A0 For example, when used in MPLS networks, SR = paths do not require any
121 =C2=A0 LDP or RSVP-TE sig= naling.=C2=A0 Still, SR can interoperate in the presence
122 <= /span> =C2=A0 of LSPs established with RSVP or LDP.

[nit] s/ecmp-aware/ECMP-aware


124 =C2=A0 There are additional segment types, e.g., Bindi= ng SID defined in
125 =C2=A0 [RFC8402].=C2=A0 This dra= ft also defines an advertisement for one type of
126 = =C2=A0 BindingSID: the Mirror Context segment.

[nit] s/BindingSID/Binding SID
=


128 =C2=A0 This draft describes the necessary IS-IS extensions= that need to be
129 =C2=A0 introduced for Segment Rou= ting operating on an MPLS data-plane.

131 =C2=A0 Segment Routing architecture is described in= [RFC8402].

[nit] s/Segment Routing architecture/The Segment Routing architecture


133 =C2=A0 Segment Routing use cases are described in [RFC= 7855].

1= 35 2.=C2=A0= Segment Routing Identifiers

137 =C2=A0 Segment Routing architecture ([RFC8402]) defines diff= erent types of
138 =C2=A0 Segment Identifiers (SID).= =C2=A0 This document defines the IS-IS encodings
139 = =C2=A0 for the IGP-Prefix-SID, the IGP-Adjacency-SID, the IGP-LAN-Adjacency= -
140 =C2=A0 SID and the Binding-SID.

[nit] s/([RFC8402])/[RF= C8402]

[= nit] s/Segment Routing architecture/The Segment Routing architecture
<= div style=3D"margin:0px">
[major] rfc840= 2 doesn't use the names above.=C2=A0 Please be consistent.


142 2.1.=C2=A0 Prefix Segment Identifier (Prefix-SID Sub-TLV)

144 =C2=A0 A new IS-IS s= ub-TLV is defined: the Prefix Segment Identifier sub-TLV
145 <= /span> =C2=A0 (Prefix-SID sub-TLV).

147 =C2=A0 The Prefix-SID sub-TLV carries the Segment Rou= ting IGP-Prefix-SID as
148 =C2=A0 defined in [RFC8402]= .=C2=A0 The 'Prefix SID' MUST be unique within a given
149 =C2=A0 IGP domain (when the L-flag is not set).=C2=A0 The '= ;Prefix SID' MUST carry
150 =C2=A0 an index (whe= n the V-flag is not set) that determines the actual SID/
151 <= /span> =C2=A0 label value inside the set of all advertised SID/label ranges= of a
152 =C2=A0 given router.=C2=A0 A receiving route= r uses the index to determine the
153 =C2=A0 actual SI= D/label value in order to construct forwarding state to a
154 =C2=A0 particular destination router.

[major] What if the Prefix SID is n= ot unique?=C2=A0 What should the receiver do?

[major] "...MUST carry an index.= ..that determines the actual SID/label value..." =C2=A0What are you tr= ying to specify with this "MUST"?=C2=A0 The description of the V-= flag (below) already points at the value being an index, but the qualificat= ion ("that determines...") makes the enforcement of this "MU= ST" more complex: the receiver has to verify that the index actually r= esults in a SID/label inside a range for it to be valid. =C2=A0 What should= the receiver do if that is not the case?
Suggestion: Rearrange the text so that th= e TLV and its fields are described first.=C2=A0 I think that then some of t= he text above won't be needed.


156 =C2=A0 In many use= -cases a 'stable transport' IP Address is overloaded as an
157 =C2=A0 identifier of a given node.=C2=A0 Because the IP Pr= efixes may be re-
158 =C2=A0 advertised into other lev= els there may be some ambiguity (e.g.
159 =C2=A0 Origi= nating router vs. L1L2 router) for which node a particular IP
160 =C2=A0 prefix serves as identifier.=C2=A0 The Prefix-SID sub-TL= V contains the
161 =C2=A0 necessary flags to disambigu= ate IP Prefix to node mappings.
162 =C2=A0 Furthermore= if a given node has several 'stable transport' IP
163 =C2=A0 addresses there are flags to differentiate those among oth= er IP
164 =C2=A0 Prefixes advertised from a given node= .

[minor= ] Again, this text may be clearer if the TLV description was presented firs= t.=C2=A0 If you decide not to rearrange the text, at least put forward refe= rences so readers can look forward to find out how the statement above is a= chieved.


...
180= =C2=A0 Wh= en the IP Reachability TLV is propagated across level boundaries,
181 =C2=A0 the Prefix-SID sub-TLV SHOULD be kept.

[major] When would th= is sub-TLV not be kept?=C2=A0 IOW, why is that not a "MUST"?

=C2=A72.1.2:= "The Prefix-SID sub-TLV MUST be preserved when the IP Reachability TL= V
gets propagated across level boundaries.&q= uot;

I&#= 39;m not saying that one way is correct...either one may be.=C2=A0 Just be = consistent.

[minor] I'm assuming that "IP Reachability TLV" means one= of the TLVs above, true?=C2=A0 It may be worth clarifying that.


183 =C2=A0 The Prefix-SID sub-TLV has the following format:

185 =C2=A0 =C2=A00 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
= 186 =C2=A0= =C2=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
187 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+
188 =C2=A0 | =C2=A0 Type =C2=A0 =C2= =A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 Length =C2=A0 =C2=A0| =C2=A0 =C2=A0 Flags = =C2=A0 =C2=A0 | =C2=A0 Algorithm =C2=A0 |
18= 9 =C2=A0 += -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
190 =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=A0SID/Index/Label (variable) =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
191 =C2=A0 +-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

193 =C2=A0 where:

195 =C2=A0 =C2=A0 =C2=A0Type: TBD, sugge= sted value 3

[major] This value (and all the others in the document) are not "= suggested values", they have been already allocated by IANA.=C2=A0 Ple= ase update the individual descriptions and the IANA Considerations section = accordingly.


197 =C2=A0 =C2=A0 =C2=A0Length: variable.

[minor] Ye= s, variable, but it can only have two values: 5 or 6.


199 = =C2=A0 =C2=A0 =C2=A0Flags: 1 octet field of following flags:

201 =C2=A0 =C2=A00 1 2 3 4 5 6 = 7
202 =C2=A0 +-+-+-+-+-+-+-+-+
203 =C2=A0 |R|N|P|E|V|L| =C2=A0 |
204 =C2=A0 +-+-+-+-+-+= -+-+-+

2= 06 =C2=A0 = =C2=A0 =C2=A0where:

208 =C2=A0 =C2=A0 =C2=A0 =C2=A0 R-Flag: Re-advertisement flag.=C2=A0 If s= et, then the prefix to
209 =C2=A0 =C2=A0 =C2=A0 =C2=A0= which this Prefix-SID is attached, has been propagated by the
210 =C2=A0 =C2=A0 =C2=A0 =C2=A0 router either from another level (= i.e., from level-1 to level-2
211 =C2=A0 =C2=A0 =C2=A0= =C2=A0 or the opposite) or from redistribution (e.g.: from another
212 =C2=A0 =C2=A0 =C2=A0 =C2=A0 protocol).

[major] Should it be used = to avoid looping as well?=C2=A0 Or is there no risk of that in this case?


...
236 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 Other bits: MUST be zero when originated and ignored when
<= div style=3D"margin:0px">237 =C2=A0 =C2=A0 =C2=A0 =C2=A0 received.

[major] Do you expect IANA= to handle the assignment of those other bits?


= 239 =C2=A0= =C2=A0 =C2=A0Algorithm: the router may use various algorithms when calcula= ting
240 =C2=A0 =C2=A0 =C2=A0reachability to other nod= es or to prefixes attached to these
241 =C2=A0 =C2=A0 = =C2=A0nodes.=C2=A0 Algorithms identifiers are defined in Section 3.2.
=
242 =C2=A0 =C2=A0 =C2=A0Examples of these algorithms are me= tric based Shortest Path First
243 =C2=A0 =C2=A0 =C2= =A0(SPF), various sorts of Constrained SPF, etc.=C2=A0 The algorithm field<= /div>
244 =C2=A0 =C2=A0 =C2=A0of the Prefix-SID contains the= identifier of the algorithm the
245 =C2=A0 =C2=A0 =C2= =A0router has used in order to compute the reachability of the prefix
=
246 =C2=A0 =C2=A0 =C2=A0to which the Prefix-SID is associat= ed.

248<= span class=3D"Apple-tab-span" style=3D"white-space:pre"> =C2=A0 =C2= =A0 =C2=A0At origination, the Prefix-SID algorithm field MUST be set to 0 o= r
249 =C2=A0 =C2=A0 =C2=A0to any value advertised in t= he SR-Algorithm sub-TLV (Section 3.2).

<= /div>
[major] What should a receiver do if the Alg= orithm value doesn't match what has been advertised in the SR-Algorithm= Sub-TLV?


...
28= 2 2.1.1.2.= =C2=A0 R and N Flags

284 <= /span> =C2=A0 The R-Flag MUST be set for prefixes that are not local to the= router
285 =C2=A0 and either:

287 =C2=A0 =C2=A0 =C2=A0advertised becaus= e of propagation (Level-1 into Level-2);
289 =C2=A0 =C2=A0 =C2=A0advertised because of leakin= g (Level-2 into Level-1);

291 =C2=A0 =C2=A0 =C2=A0advertised because of redistribution (e.g.:= from another
292 =C2=A0 =C2=A0 =C2=A0protocol).
=

294 =C2=A0 In the case = where a Level-1-2 router has local interface addresses
295 =C2=A0 configured in one level, it may also propagate these addresses = into
296 =C2=A0 the other level.=C2=A0 In such case, t= he Level-1-2 router MUST NOT set the
297 =C2=A0 R bit.= =C2=A0 The R-bit MUST be set only for prefixes that are not local to
<= div style=3D"margin:0px">298 =C2=A0 the router and advertised by the router because o= f propagation and/or
299 =C2=A0 leaking.

[minor] This last sen= tence is redundant with the start of this section.=C2=A0 Please specify the= behavior just once.


301 =C2=A0 The N-Flag is used in ord= er to define a Node-SID.=C2=A0 A router MAY set
302 = =C2=A0 the N-Flag only if all of the following conditions are met:

304 =C2=A0 =C2=A0 =C2=A0= The prefix to which the Prefix-SID is attached is local to the
305 =C2=A0 =C2=A0 =C2=A0router (i.e., the prefix is configured on = one of the local
306 =C2=A0 =C2=A0 =C2=A0interfaces, e= .g., a 'stable transport' loopback).

308 =C2=A0 =C2=A0 =C2=A0The prefix to which the = Prefix-SID is attached MUST have a Prefix
30= 9 =C2=A0 = =C2=A0 =C2=A0length of either /32 (IPv4) or /128 (IPv6).

[major] "The prefix..= .MUST have a Prefix length..." =C2=A0This condition is not worded as o= ne; perhaps: "The prefix...has a Prefix length..."

[minor] Why is the N-F= lag needed?=C2=A0 If the setting is optional ("MAY"), then not se= tting it doesn't imply that the conditions are not met...

[major] It is clearly= an error if both the R-Flag and N-Flag are set, right?=C2=A0 What should t= he receiver do in that case?


311 =C2=A0 The router MUST i= gnore the N-Flag on a received Prefix-SID if the
312 = =C2=A0 prefix has a Prefix length different than /32 (IPv4) or /128 (IPv6).=

314 =C2=A0 [RFC77= 94] also defines the N and R flags and with the same semantics
315 =C2=A0 of the equivalent flags defined in this document.=C2=A0= There will be a
316 =C2=A0 transition period where bo= th sets of flags will be used and
317 =C2=A0 eventuall= y only the flags of the Prefix Attributes will remain.
318 =C2=A0 During the transition period implementations supporting the N a= nd R
319 =C2=A0 flags defined in this document and the= N and R flags defined in
320 =C2=A0 [RFC7794] MUST ad= vertise and parse all flags.=C2=A0 In case the received
321 =C2=A0 flags have different values, the value of the flags defined in=
322 =C2=A0 [RFC7794] prevails.

[major] "...transition pe= riod where both sets of flags will be used and eventually only the flags of= the Prefix Attributes will remain" =C2=A0To be honest, you lost me he= re?=C2=A0 Please explain what will the transition period be between?
<= div style=3D"margin:0px">
[major] If &qu= ot;both sets of flags will be used and eventually only the [already defined= ] flags of the Prefix Attributes will remain", why do we need the new = ones?

[m= ajor] "MUST advertise and parse all flags" =C2=A0What does this m= ean?=C2=A0 By "all flags" I guess you mean the N and R flags...bu= t if both this document and rfc7794 are implemented, it seems to me that th= e specification above is really meaningless.

[major] "In case the received fla= gs have different values..." =C2=A0For a second it seemed to me that w= hat you really wanted was for the flags in this document to behave the same= way as the flags defined in rfc7794...the easy solution to that (and to av= oid my questions listed before rfc7794 was mentioned) would have been to ju= st point at rfc7794 as the place where the Flags are defined.=C2=A0 However= , it looks like the definitions (at least for the R-Flag) are not the same.= =C2=A0 Is that on purpose or is it just an oversight?

One piece of information that= might make this discussion relevant is understanding the significance of t= hese Flags...but neither document offers any specific use, beyond simply &q= uot;it may be useful for other routers to know" (rfc7794, =C2=A72.2).<= /div>


324 2.1.1.3.=C2=A0 E and P Flags

326 =C2=A0 When calculating the outgoing la= bel for the prefix, the router MUST
327 =C2=A0 take in= to account E and P flags advertised by the next-hop router, if
328 =C2=A0 next-hop router advertised the SID for the prefix.=C2= =A0 This MUST be done
329 =C2=A0 regardless of next-ho= p router contributing to the best path to the
330 =C2= =A0 prefix or not.

[major] "the router MUST take into account" =C2=A0What= normative action is standardized with that phrase?=C2=A0 It would be clear= er/better if the behavior is explicitly specified in function of the flags = (as sone below). =C2=A0s/MUST/must

[major] "This MUST be done regardless of ne= xt-hop router contributing to the best path to the prefix or not." =C2= =A0This what?=C2=A0 I'm assuming the text refers to "take into acc= ount"...=C2=A0 Same comment as before: s/MUST/must


...
366 2.1.2.=C2=A0 Prefix-SID Propagation

368 =C2=A0 The Prefi= x-SID sub-TLV MUST be preserved when the IP Reachability TLV
369 =C2=A0 gets propagated across level boundaries.

[major] =C2=A72.1 says = that it SHOULD.=C2=A0 Please be consistent...and, specify behavior only onc= e.

371 =C2=A0 The = level-1-2 router that propagates the Prefix-SID sub-TLV between
372 =C2=A0 levels MUST set the R-flag.

374 =C2=A0 If the Prefix-SID contains a glob= al index (L and V flags unset) and
375 =C2=A0 it is pr= opagated as such (with L and V flags unset), the value of the
376 =C2=A0 index MUST be preserved when propagated between levels.<= /div>

378 =C2=A0 The lev= el-1-2 router that propagates the Prefix-SID sub-TLV between
379 =C2=A0 levels MAY change the setting of the L and V flags in cas= e a local
380 =C2=A0 label value is encoded in the Pre= fix-SID instead of the received
381 =C2=A0 value.

[major] =C2= =A0Up to now, I had been assuming that propagating and preserving meant not= changing the sub-TLV (except for the R-Flag).=C2=A0 But these last paragra= phs indicate that not only can some flags be changed, but the contents can = completely change.=C2=A0 It would be ideal if the valid operations on the s= ub-TLV were discussed (or at least referenced) when the preserving behavior= was first introduced (I think in =C2=A72.1).


.= ..
409 2.2.1.=C2=A0 Adjacency Segment Identifier (Adj= -SID) Sub-TLV

411 = =C2=A0 The following format is defined for the Adj-SID sub-TLV:

413 =C2=A0 =C2=A00 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
414 =C2=A0 =C2=A0= 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
415 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+
416 =C2=A0 | =C2=A0 Type =C2=A0 =C2=A0 =C2= =A0 =C2=A0| =C2=A0 =C2=A0 Length =C2=A0 =C2=A0| =C2=A0 =C2=A0 Flags =C2=A0 = =C2=A0 | =C2=A0 =C2=A0 Weight =C2=A0 =C2=A0|
417 =C2= =A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
=
418 =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 SID/Label/Index (variable) =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
419 =C2=A0 +-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

421 =C2=A0 where:

423 =C2=A0 =C2=A0 =C2=A0Type: TBD= , suggested value 31

425 <= /span> =C2=A0 =C2=A0 =C2=A0Length: variable.

[minor] Yes, variable, but it can only= have two values...

427 =C2=A0 =C2=A0 =C2=A0Flags: 1 octet field of following flags:

429 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A00 1 2 3 4 5 6 7
430 =C2=A0 =C2=A0 =C2=A0= =C2=A0 +-+-+-+-+-+-+-+-+
431 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 |F|B|V|L|S|P| =C2=A0 |
432 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 +-+-+-+-+-+-+-+-+

434 =C2=A0 =C2=A0 =C2=A0where:

436 =C2=A0 =C2=A0 =C2=A0 =C2=A0 F-Flag: Address-Family = flag.=C2=A0 If unset, then the Adj-SID refers
437 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 to an adjacency with outgoing IPv4 encapsulation.= =C2=A0 If set then
438 =C2=A0 =C2=A0 =C2=A0 =C2=A0 the= Adj-SID refers to an adjacency with outgoing IPv6
439 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 encapsulation.
=
[major] This document describes the ope= ration on the MPLS data plane, right?=C2=A0 The F-Flag talks about the outg= oing encapsulation...but that could simply be the next label in the MPLS st= ack, right?=C2=A0 What am I missing?=C2=A0 I get the impression that there&= #39;s a relationship between what this Flag points to and something else...= but I just don't know what.


441 =C2=A0 =C2=A0 =C2=A0= =C2=A0 B-Flag: Backup flag.=C2=A0 If set, the Adj-SID is eligible for
442 =C2=A0 =C2=A0 =C2=A0 =C2=A0 protection (e.g.: using IP= FRR or MPLS-FRR) as described in
443 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 [RFC8355].

[major] Because the specification of the B-Flag depends dir= ectly on rfc8355, it should be a Normative reference.=C2=A0 Looking at rfc8= 355, I couldn't find a place where it talks about eligibility for prote= ction...just text about potential strategies, but (honestly) nothing that I= would call Normative.=C2=A0 Please clarify.=C2=A0 Perhaps rfc8402 might be= a better reference.

[major] I'm assuming that this description (pointing at rf= c8355), plus the text below about allocation of Adj-SIDs should result in s= ome action related to the protection...what is that?=C2=A0 IOW, presented w= ith the B-Flag set, what action should a node take?


445 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 V-Flag: Value flag.=C2=A0 If set, then the Adj-= SID carries a value.
446 =C2=A0 =C2=A0 =C2=A0 =C2=A0 B= y default the flag is SET.

[minor] Is the description the same at the V-Flag in =C2= =A72.1?=C2=A0 If so, then indicating that, or at least also pointing out he= re that the value is carried instead of an index would be helpful.


448 =C2=A0 =C2=A0 =C2=A0 =C2=A0 L-Flag: Local Flag.=C2=A0 If set,= then the value/index carried by
449 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 the Adj-SID has local significance.=C2=A0 By default the flag is=
450 =C2=A0 =C2=A0 =C2=A0 =C2=A0 SET.

[major] Looking back at= =C2=A72.1.1.1, what are the conditions for which the combination of the V = and L-Flags are valid/invalid?=C2=A0 Do the same conditions apply?


...
460 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 Other bits: MUST be zero when originated and ignored when
461 =C2=A0 =C2=A0 =C2=A0 =C2=A0 received.

[major] Do you expect IANA to han= dle the assignment of those other bits?

=

...
469 =C2=A0 =C2=A0 =C2=A0An SR capable router MAY allocate= an Adj-SID for each of its
470 =C2=A0 =C2=A0 =C2=A0= adjacencies and SHOULD set the B-Flag when the adjacency is
471 =C2=A0 =C2=A0 =C2=A0eligible for protection (IP or MPLS).

[major] If elig= ible for protection, when would the router not set the B-Flag?=C2=A0 IOW, w= hy is that not a MUST?

Beyond that, I think that the use of SHOULD is in conflict = with the definition of the B-Flag (above): "If set, the Adj-SID is eli= gible for protection...", which implies that it isn't eligible if = it's not set...but the SHOULD opens the door for not setting the Flag..= .


...
479 =C2=A0 =C2=A0 = =C2=A0When the P-flag is not set, the Adj-SID MAY be persistent.=C2=A0 When=
480 =C2=A0 =C2=A0 =C2=A0the P-flag is set, the Adj-SI= D MUST be persistent.

[major] If the adjacency is persistent, why/when would the = P-Flag not be set?


...
488 = 2.2.2.=C2=A0 Adjacency Segment Identifiers in LANs
...
537 =C2=A0 =C2=A0 =C2=A0Other bits: MUST be= zero when originated and ignored when
538 =C2=A0 =C2= =A0 =C2=A0received.

[major] Do you expect IANA to handle the assignment of those ot= her bits?


...
54= 4 =C2=A0 = =C2=A0 =C2=A0System-ID: 6 octets of IS-IS System-ID of length "ID Leng= th" as
545 =C2=A0 =C2=A0 =C2=A0defined in [ISO105= 89].

[ma= jor] Which System-ID?

[major] "6 octets of...length "ID Length"&qu= ot; =C2=A0??


547 =C2=A0 =C2=A0 =C2=A0SID/Index/Label as d= efined in Section 2.1.1.1.

549 =C2=A0 Multiple LAN-Adj-SID sub-TLVs MAY be encoded.=C2=A0 Not= e that this sub-TLV
550 =C2=A0 MUST NOT appear in TLV = 141.

552= =C2=A0 Wh= en the P-flag is not set, the LAN-Adj-SID MAY be persistent.=C2=A0 When
553 =C2=A0 the P-flag is set, the LAN-Adj-SID MUST be per= sistent.

555 =C2= =A0 In case one TLV-22/23/222/223 (reporting the adjacency to the DIS)
556 =C2=A0 can't contain the whole set of LAN-Adj-SID = sub-TLVs, multiple
557 =C2=A0 advertisements of the ad= jacency to the DIS MUST be used and all
558<= span class=3D"Apple-tab-span" style=3D"white-space:pre"> =C2=A0 adv= ertisements MUST have the same metric.

<= /div>
560 =C2=A0 Each router within the level, by receiving = the DIS PN LSP as well as
561 =C2=A0 the non-PN LSP of= each router in the LAN, is capable of
562 =C2=A0 reco= nstructing the LAN topology as well as the set of Adj-SID each
563 =C2=A0 router uses for each of its neighbors.

565 =C2=A0 A label is encoded in = 3 octets (in the 20 rightmost bits).

567 =C2=A0 An index is encoded in 4 octets.

[minor] Some of the = information above (for example, the paragraph about the P-Flag and these la= st 2 sentences) seems unnecessary given that the description of these field= s is already done somewhere else.

=

569 2.3.=C2=A0 SID/Label= Sub-TLV

571 =C2= =A0 The SID/Label sub-TLV may be present in the following TLVs/sub-TLVs
572 =C2=A0 defined in this document:

574 =C2=A0 SR-Capabilities Sub-TLV (Se= ction 3.1)

576 =C2= =A0 SR Local Block Sub-TLV (Section 3.3)
578 =C2=A0 SID/Label Binding TLV (Section 2.4)
=

580 =C2=A0 Multi-Topolo= gy SID/Label Binding TLV (Section 2.5)

<= /div>
[nit] It might have been nice, in line with = the OSPF work, to flip Sections 2 and 3.=C2=A0 Just a nit...

582 =C2=A0 Note that the code po= int used in all of the above cases is the SID/
583 =C2= =A0 Label Sub-TLV code point assigned by IANA in the "sub-TLVs for TLV=
584 =C2=A0 149 and 150" registry.

[major] Because this d= ocument is setting up that new registry, we don't have to wait for IANA= to assign anything: the document can specify it.=C2=A0 IOW, the paragraph = above is not needed.


586 =C2=A0 The SID/Label sub-TLV con= tains a SID or a MPLS Label.=C2=A0 The SID/Label
587 = =C2=A0 sub-TLV has the following format:
589 =C2=A0 =C2=A00 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 3
590 =C2=A0 =C2=A00 1 2 3 4 5 6 7 8 9 0= 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
5= 91 =C2=A0 = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
592 =C2=A0 | =C2=A0 = Type =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 Length =C2=A0 =C2=A0|
=
593 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+
594 =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=A0SID/La= bel (variable) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
595 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+

597 <= /span> =C2=A0 where:

599 <= /span> =C2=A0 =C2=A0 =C2=A0Type: TBD, suggested value 1

601 =C2=A0 =C2=A0 =C2=A0Length: varia= ble

[maj= or] Yes, variable...but right now only one value is defined.=C2=A0 There= 9;s a finite number of possibilities...

=

602 =C2=A0 =C2=A0= =C2=A0SID/Label: if length is set to 3 then the 20 rightmost bits
603 =C2=A0 =C2=A0 =C2=A0represent a MPLS label.

[major] Is that it..?= =C2=A0 What about the SID?


605 2.4.=C2=A0 SID/Label Bindin= g TLV
...
619= =C2=A0 Th= e SID/Label Binding TLV has Type TBD (suggested value 149), and has
620 =C2=A0 the following format:

[nit] No need to talk about the Type= twice.

= 622 =C2=A0= =C2=A0 =C2=A00 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
623 =C2=A0 =C2=A0 =C2=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1= 2 3 4 5 6 7 8 9 0 1
624 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
625 = =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0Type =C2=A0 =C2=A0 | =C2=A0 =C2=A0 Len= gth =C2=A0 =C2=A0| =C2=A0 =C2=A0 Flags =C2=A0 =C2=A0 | =C2=A0 =C2=A0 RESERV= ED =C2=A0|
626 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
627= =C2=A0 = =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Range =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| Prefix Length | =C2=A0 =C2=A0 Prefix =C2= =A0 =C2=A0|
628 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
62= 9 =C2=A0 = =C2=A0 // =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Prefix (continue= d, variable) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= //
630 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
631 =C2=A0 =C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0SubTL= Vs (variable) =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 |
632 =C2=A0 =C2=A0 +-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

634 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Figure 1: SID/Label Binding TLV format
=

636 =C2=A0 o =C2=A0Type= : TBD, suggested value 149


...
657 2.4.1.=C2=A0 Flags
...
671 =C2=A0 =C2=A0 =C2=A0M-Flag: Mirror Context flag.=C2=A0 Set if = the advertised SID
672 =C2=A0 =C2=A0 =C2=A0corresponds= to a mirrored context.=C2=A0 The use of the M flag is
673 =C2=A0 =C2=A0 =C2=A0described in [RFC8402].

[major] Where?=C2=A0 Note that rfc= 8402 says that "The Mirror SID is advertised using the Binding segment= defined in SR IGP protocol extensions [ISIS-SR-EXT].", pointing back = at this document.

[minor] Some places use *-Flag and others "* flag", ple= ase be consistent.


675 =C2=A0 =C2=A0 =C2=A0S-Flag: If set= , the SID/Label Binding TLV SHOULD be flooded across
676 =C2=A0 =C2=A0 =C2=A0the entire routing domain.=C2=A0 If the S flag is no= t set, the SID/
677 =C2=A0 =C2=A0 =C2=A0Label Binding = TLV MUST NOT be leaked between levels.=C2=A0 This bit
678 =C2=A0 =C2=A0 =C2=A0MUST NOT be altered during the TLV leaking.

[major] If the = S-Flag is set, when would the TLV not be flooded across the entire domain?= =C2=A0 IOW, why is the SHOULD not a MUST?

680 =C2=A0 =C2= =A0 =C2=A0D-Flag: when the SID/Label Binding TLV is leaked from level-2 to<= /div>
681 =C2=A0 =C2=A0 =C2=A0level-1, the D bit MUST be set= .=C2=A0 Otherwise, this bit MUST be
682 =C2=A0 =C2=A0 = =C2=A0clear.=C2=A0 SID/Label Binding TLVs with the D bit set MUST NOT be
683 =C2=A0 =C2=A0 =C2=A0leaked from level-1 to level-2.= =C2=A0 This is to prevent TLV looping
684 =C2=A0 =C2= =A0 =C2=A0across levels.

[minor] What about leaking from L2 to L1 with the Flag set= ?

[minor= ] The text uses Flag, but in some cases bit is used as well.=C2=A0 Please b= e consistent.


...
695 =C2= =A0 =C2=A0 =C2=A0An implementation MAY decide not to honor the S-flag in or= der not
696 =C2=A0 =C2=A0 =C2=A0to leak Binding TLV= 9;s between levels (for policy reasons).=C2=A0 In all
697 =C2=A0 =C2=A0 =C2=A0cases, the D flag MUST always be set by any router = leaking the
698 =C2=A0 =C2=A0 =C2=A0Binding TLV from l= evel-2 into level-1 and MUST be checked when
699 =C2= =A0 =C2=A0 =C2=A0propagating the Binding TLV from level-1 into level-2.=C2= =A0 If the D
700 =C2=A0 =C2=A0 =C2=A0flag is set, the = Binding TLV MUST NOT be propagated into level-2.

[major] s/implementation MAY decid= e/implementation may decide =C2=A0 There's no Normative action there.

[major] R= egardless of whether MAY/may is used, the statement in the first sentence c= ontradicts the "MUST NOT be leaked" Normative statement.=C2=A0 Gi= ven that there are exceptions, maybe "SHOULD NOT" would be more a= ppropriate.

[major] This last paragraph seems to contain the same information as th= e text describing the S-Flag.=C2=A0 Please don't duplicate specificatio= ns.

702<= span class=3D"Apple-tab-span" style=3D"white-space:pre"> =C2=A0 =C2= =A0 =C2=A0Other bits: MUST be zero when originated and ignored when
703 =C2=A0 =C2=A0 =C2=A0received.

[major] Do you expect IANA to handl= e the assignment of those other bits?

705 2.4.2.=C2=A0 Range
707 =C2=A0 The 'Range' field provides the= ability to specify a range of
708 =C2=A0 addresses an= d their associated Prefix SIDs.=C2=A0 This advertisement
709 <= /span> =C2=A0 supports the SRMS functionality.=C2=A0 It is essentially a co= mpression
710 =C2=A0 scheme to distribute a continuous= Prefix and their continuous,
711 =C2=A0 corresponding= SID/Label Block.=C2=A0 If a single SID is advertised then
712 =C2=A0 the range field MUST be set to one.=C2=A0 For range advert= isements > 1,
713 =C2=A0 the number of addresses th= at need to be mapped into a Prefix-SID and
7= 14 =C2=A0 = the starting value of the Prefix-SID range.
=
[nit] The last sentence sounds incomple= te...

71= 6 =C2=A0 E= xample 1: if the following router addresses (loopback addresses)
717 =C2=A0 need to be mapped into the corresponding Prefix SID i= ndexes.

= [minor] Suggestion: move the examples to the end of =C2=A72.4...after all t= he fields have been discussed.

719 =C2=A0 Router-A: 192.0.2.1= /32, Prefix-SID: Index 1
720 =C2=A0 Router-B: 192.0.2.2/32, Prefix-SID: Index 2
721 =C2=A0 Router-C: 192.0.2.3= /32, Prefix-SID: Index 3
722 =C2=A0 Router-D: 192.0.2.4/32, Prefix-SID: Index 4

724 =C2=A0 =C2=A0 =C2=A0= 0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
725 = =C2=A0 =C2=A0 =C2=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7= 8 9 0 1
726 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
727 =C2=A0 =C2= =A0 | =C2=A0 =C2=A0 =C2=A0Type =C2=A0 =C2=A0 | =C2=A0 =C2=A0 Length =C2=A0 = =C2=A0|0|0| =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 RESERVED =C2= =A0|
728 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
729 =C2=A0 =C2=A0 |= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Range =3D 4 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 /32 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0192 =C2=A0 =C2=A0 =C2=A0|
730 =C2=A0 =C2=A0 +-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
731 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 .0 =C2=A0 =C2=A0 =C2=A0| =C2= =A0 =C2=A0 =C2=A0 =C2=A0.2 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A0 .1 =C2=A0 = =C2=A0 =C2=A0|Prefix-SID Type|
732 =C2=A0 =C2=A0 +-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
733 =C2=A0 =C2=A0 | sub-TLV Length| =C2=A0 =C2=A0 Flags =C2=A0 =C2= =A0 | =C2=A0 Algorithm =C2=A0 | =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 |
734 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
735 =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=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 1 |
736 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+

[nit] The Prefix Length should be "32", not = "/32".

[nit] The Prefix itself is one field (in the description), but it = looks like 4 separate fields above...and the numbers should not have "= ." in them.

[minor] It looks like the fields starting with "Prefix-SID Ty= pe" belong to the Prefix-SID Sub-TLV, but that is not explained anywhe= re (yet).=C2=A0 The Algorithm field is not set...nor are the Flags.

738 =C2=A0 Example-2: If= the following prefixes need to be mapped into the
739 = =C2=A0 corresponding Prefix-SID indexes:
741 =C2=A0 10.1.1/24, Prefix-SID: Index 51
<= div style=3D"margin:0px">742 =C2=A0 10.1.2/24, Prefix-SID: Index 52
743 =C2=A0 10.1.3/24, Prefix-SID: Index 53
744 = =C2=A0 10.1.4/24, Prefix-SID: Index 54
745 =C2=A0 10.1= .5/24, Prefix-SID: Index 55
746 =C2=A0 10.1.6/24, Pr= efix-SID: Index 56
747 =C2=A0 10.1.7/24, Prefix-SID: I= ndex 57

= [major] Please use addresses in the rfc5737 reserved ranges.

[minor] It would have = been nice to see an IPv6 example (see rfc3849).

749 =C2=A0 =C2=A0 =C2=A00 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 1 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 2 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 3
750 =C2=A0 =C2=A0 =C2=A0= 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
751 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+
752 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 = =C2=A0Type =C2=A0 =C2=A0 | =C2=A0 =C2=A0 Length =C2=A0 =C2=A0|0|0| =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 RESERVED =C2=A0|
753 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+
754 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Range =3D 7 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0| =C2= =A0 =C2=A0 =C2=A0 /24 =C2=A0 =C2=A0 | =C2=A0 =C2=A0 =C2=A010 =C2=A0 =C2=A0 = =C2=A0 |
755 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+= -+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
756 =C2=A0 =C2= =A0 | =C2=A0 =C2=A0 =C2=A0 .1 =C2=A0 =C2=A0 =C2=A0| =C2=A0 =C2=A0 =C2=A0 = =C2=A0.1 =C2=A0 =C2=A0 |Prefix-SID Type| sub-TLV Length|
757 <= /span> =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+
758 =C2=A0 =C2=A0 | =C2=A0 =C2=A0Flags =C2= =A0 =C2=A0 =C2=A0| Algorithm =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=A0 =C2= =A0 |
759 =C2=A0 =C2=A0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
760 =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 51 =C2=A0|
761 =C2=A0 =C2=A0 +-+-+-= +-+-+-+-+-+-+-+-+-+-+-+-+-+

[] Same comments as above.


= ...
778 2.4.3.=C2=A0 Prefix Length, Prefix
...
784 =C2=A0 The 'Prefix Len= gth' field contains the length of the prefix in bits.
785 =C2=A0 Only the most significant octets of the Prefix are encoded= . =C2=A0(i.e., 1
786 =C2=A0 octet for prefix length 1 = up to 8, 2 octets for prefix length 9 to
787= =C2=A0 16= , 3 octets for prefix length 17 up to 24 and 4 octets for prefix
788 =C2=A0 length 25 up to 32, ...., 16 octets for prefix length= 113 up to 128).

[nit] s/encoded. =C2=A0(i.e.,/encoded (i.e.,


790 = 2.4.4.=C2=A0 Mapping Server Prefix-SID

<= /div>
792 =C2=A0 The Prefix-SID sub-TLV (suggested value 3) = is defined in Section 2.1
793 =C2=A0 and contains the = SID/index/label value associated with the prefix and
794 =C2=A0 range.=C2=A0 The Prefix-SID SubTLV MUST be present in the SID/Lab= el
795 =C2=A0 Binding TLV unless the M-flag is set i= n the Flags field of the parent
796 =C2=A0 TLV.
<= div style=3D"margin:0px">
[major] Does i= t then mean that the Prefix-SID SubTLV must not be present if the M-Flag is= not set?

[nit] s/SubTLV/Sub-TLV (as it is used almost everywhere else)


798 =C2=A0 A node receiving an SRMS entry for a prefix MUST check th= e existence
799 =C2=A0 of such prefix in its link-stat= e database prior to consider and use
800 =C2=A0 the as= sociated SID.

[major] What does it mean for the prefix to exist in the link-state d= atabase?=C2=A0 Does it mean that it must have been advertised in a "no= rmal" routing TLV, or something else?=C2=A0 I ask not only to clarify,= but because =C2=A72.4.3 says that the "'Prefix' does not need= to correspond to a routable prefix of the originating node".

[Ah...I think I = understand.=C2=A0 Because "the mapping server does not specify the ori= ginator of a prefix" (=C2=A72.4.4.2), then the prefix is obviously not= routable in the context of the originating node (the server)...but it shou= ld be routable in general.=C2=A0 Is that it?]


8= 02 2.4.4.1.= =C2=A0 Prefix-SID Flags

804 =C2=A0 The Prefix-SID flags are defined in Section 2.1.=C2=A0 The= Mapping Server
805 =C2=A0 MAY advertise a mapping wit= h the N flag set when the prefix being
806 =C2=A0 mapp= ed is known in the link-state topology with a mask length of 32
807 =C2=A0 (IPv4) or 128 (IPv6) and when the prefix represents a = node.=C2=A0 The
808 =C2=A0 mechanisms through which th= e operator defines that a prefix
809 =C2=A0 represents= a node are outside the scope of this document (typically
810 =C2=A0 it will be through configuration).

[major] =C2=A72.1.1.2 says that= the "router MAY set the N-Flag only if... the prefix to which the Pre= fix-SID is attached MUST have a Prefix length of either /32 (IPv4) or /128 = (IPv6)." =C2=A0That is similar to what the text above says (but the te= xt talks about "the prefix...known in the link-state topology"), = and it is related to the last question in the previous section.=C2=A0 Does = the prefix being in the link-state database/topology mean that the match is= exact (to the prefix advertised), or is a supernet ok?


812 =C2=A0 The other flags defined in Section 2.1 are not used by the Mappin= g
813 =C2=A0 Server and MUST be ignored at reception.<= /div>

[major] = How does the receiver know that the sub-TLV was originated by a Mapping Ser= ver?=C2=A0 Is it the case that it would originate a Binding TLV?=C2=A0 IOW,= would the other flags always be ignored when the sub-TLV is included in th= e Binding TLV (but not other TLVs)? =C2=A0 Does this apply also to the Mult= i-Topology SID/Label Binding TLV (=C2=A72.5)?


8= 15 2.4.4.2.= =C2=A0 PHP Behavior when using Mapping Server Advertisements
...
823 =C2=A0 o =C2=A0A prefix reach= ability advertisement for the prefix has been
824 =C2= =A0 =C2=A0 =C2=A0received which includes the Extended Reachability Attribut= e Flags
825 =C2=A0 =C2=A0 =C2=A0sub-TLV ([RFC7794]).

[nit] s/(= [RFC7794])/[RFC7794]

827 <= /span> =C2=A0 o =C2=A0X and R flags are both set to 0 in the Extended Reach= ability
828 =C2=A0 =C2=A0 =C2=A0Attribute Flags sub-TL= V.

830 =C2=A0 In t= he absence of an Extended Reachability Attribute Flags sub-TLV
831 =C2=A0 ([RFC7794]) the A flag in the binding TLV indicates tha= t the
832 =C2=A0 originator of a prefix reachability a= dvertisement is directly
833 =C2=A0 connected to the p= refix and thus PHP MUST be done by the neighbors of
834 =C2=A0 the router originating the prefix reachability advertisement.=C2= =A0 Note
835 =C2=A0 that A-flag is only valid in the o= riginal area in which the Binding
836 =C2=A0 TLV is ad= vertised.

[nit] s/([RFC7794])/[RFC7794]

[major] =C2=A72.4.1 says that "if the Binding = TLV is leaked...the A-flag MUST be cleared", which is not the same as = not considering it valid (ignoring, as described above).=C2=A0 In any case,= please be specific about the functionality in the description.


838 2.4.4.3.=C2=A0 Prefix-SID Algorithm

840 =C2=A0 The algorithm field contains the ide= ntifier of the algorithm the
841 =C2=A0 router MUST u= se in order to compute reachability to the range of
842 =C2=A0 prefixes.=C2=A0 Use of the algorithm field is described in Section= 2.1.

[m= ajor nit] At first glance, it looks like this section is not needed because= it repeats what =C2=A72.1 already says about the algorithm.=C2=A0 But this= paragraph refers to "the algorithm the router MUST use in order to co= mpute reachability", in contrast to the definition of the field in =C2= =A72.1: "The algorithm field...contains the identifier of the algorith= m the router has used in order to compute the reachability..."


...
901 3.1.=C2=A0 SR-Capabilities= Sub-TLV
...
= 909 =C2=A0= The Router Capability TLV specifies flags that control its
910 =C2=A0 advertisement.=C2=A0 The SR Capabilities sub-TLV MUST be p= ropagated
911 =C2=A0 throughout the level and MUST NOT= be advertised across level
912 =C2=A0 boundaries.= =C2=A0 Therefore Router Capability TLV distribution flags are
913 =C2=A0 set accordingly, i.e., the S flag in the Router Capabili= ty TLV
914 =C2=A0 ([RFC7981]) MUST be unset.

[nit] s/([RFC7981= ])/[RFC7981]


...
943 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 I-Flag: MPLS IPv4 flag.=C2=A0 If set, then the rou= ter is capable of
944 =C2=A0 =C2=A0 =C2=A0 =C2=A0 proc= essing SR MPLS encapsulated IPv4 packets on all interfaces.

946 =C2=A0 =C2=A0 =C2=A0 =C2=A0 V= -Flag: MPLS IPv6 flag.=C2=A0 If set, then the router is capable of
947 =C2=A0 =C2=A0 =C2=A0 =C2=A0 processing SR MPLS encapsulate= d IPv6 packets on all interfaces.

=
[minor] Just curious: How are these flags used?= =C2=A0 Given that the data plane we're dealing with is MPLS...


...
981 =C2=A0 The originating rou= ter MUST ensure the order is same after a graceful
982 = =C2=A0 restart (using checkpointing, non-volatile storage or any other
983 =C2=A0 mechanism) in order to guarantee the same orde= r before and after GR.

[nit] s/order is same/order is the same


...
1015 3.2.=C2=A0 SR-Algorithm Sub-TLV
=
...
1046 =C2=A0 The SR-Algor= ithm sub-TLV is optional, it MAY only appear a single
1047 =C2=A0 time inside the Router Capability TLV.

[major] "MAY only appear a = single time" means that it can appear more than once.=C2=A0 If it does= show up more than once, what should the the receiver do?


1049 = =C2=A0 When the originating router does not advertise the SR-Algori= thm sub-
1050 =C2=A0 TLV, then all the Prefix-SIDs adv= ertised by the router MUST have
1051 =C2=A0 algorithm = field set to 0.=C2=A0 Any receiving router MUST assume SPF
1052 =C2=A0 algorithm (i.e., Shortest Path First).

[minor] It seems to me tha= t this part of the specification would fit better in =C2=A72.1.

[major] Besides may= be being redundant, what is specified in the last sentence?=C2=A0 If the in= dication of the algorithm is explicit, then I don't understand what &qu= ot;MUST assume" is trying to mandate.
<= br>

1054= =C2=A0 Wh= en the originating router does advertise the SR-Algorithm sub-TLV,
1055 =C2=A0 then algorithm 0 MUST be present while algorithm 1= MAY be present.

[nit] I think that it is clear that algorithm 1 is optional.=C2=A0= I would take that last part out just because other algorithms may be defin= ed in the future...and the important part at this point is the inclusion of= algorithm 0.


1057 =C2=A0 The SR-Algorithm sub-TLV has fo= llowing format:

[nit] s/has following/has the following


...
1073 =C2=A0 =C2=A0 =C2=A0Algorithm: 1 octet of al= gorithm Section 2.1

[minor] The Algorithm field is described in this section, not i= n 2.1.

<= br>
1075 3.3.=C2=A0 SR Local Block Sub-TLV

1077 =C2=A0 The SR Local Block= (SRLB) Sub-TLV contains the range of labels the
1078 = =C2=A0 node has reserved for local SIDs.=C2=A0 Local SIDs are used, e.g., f= or
1079 =C2=A0 Adjacency-SIDs, and may also be alloca= ted by other components than
1080 =C2=A0 IS-IS protoco= l.=C2=A0 As an example, an application or a controller may
1081 =C2=A0 instruct the router to allocate a specific local SID.=C2= =A0 Therefore, in
1082 =C2=A0 order for such applicati= ons or controllers to know what are the local
1083 =C2= =A0 SIDs available in the router, it is required that the router
1084 =C2=A0 advertises its SRLB.
=
[nit] s/than IS-IS protocol/than the IS= -IS protocol


...
1122 =C2= =A0 The originating router MUST NOT advertise overlapping ranges.

[major] What shou= ld the receiver do if the ranges overlap?=C2=A0 I'm assuming the same t= hing as what was specified before...please be specific.


1124 =C2=A0 It is important to note that each time a SID from the SRLB is
1125 =C2=A0 allocated, it SHOULD also be reported to all= components (e.g.:
1126 =C2=A0 controller or applicati= ons) in order for these components to have an
1127 =C2= =A0 up-to-date view of the current SRLB allocation and in order to avoid
1128 =C2=A0 collision between allocation instructions.

1130 =C2=A0 Within = the context of IS-IS, the reporting of local SIDs is done
1131 =C2=A0 through IS-IS Sub-TLVs such as the Adjacency-SID.=C2=A0 H= owever, the
1132 =C2=A0 reporting of allocated local S= IDs may also be done through other
1133 =C2=A0 means a= nd protocols which mechanisms are outside the scope of this
1134 =C2=A0 document.

[major] "SHOULD also be reported to all components= " =C2=A0Because that is outside the scope, then it shouldn't be a = Normative statement. =C2=A0s/SHOULD/should
<= br>

...<= /div>
1170 4.=C2=A0 Non backward compatible changes with prio= r versions of this document

[major] I find this section unnecessary.=C2=A0 If you w= ant to keep it, please move it to an Appendix and don't use Normative l= anguage.


...
119= 0 5.=C2=A0 = IANA Considerations

1192 <= /span> =C2=A0 This documents request allocation for the following TLVs and = subTLVs.

[minor] IANA may be ok, but I find the formatting below a little confusing= .=C2=A0 A table may be a better option.

=

...
1313 =C2=A0 This document creates the following sub-TLV R= egistry:
...
= [major] Please indicate what the range is.
<= br>

1333= 6.=C2=A0 S= ecurity Considerations

1335 =C2=A0 With the use of the extensions defined in this document, = IS-IS
1336 =C2=A0 carries information which will be us= ed to program the MPLS data plane
1337 =C2=A0 [RFC3031= ].=C2=A0 In general, the same types of attacks that can be carried
1338 =C2=A0 out on the IP/IPv6 control plane can be carried ou= t on the MPLS
1339 =C2=A0 control plane resulting in t= raffic being misrouted in the respective
134= 0 =C2=A0 d= ata planes.=C2=A0 However, the latter may be more difficult to detect and
1341 =C2=A0 isolate.=C2=A0 Existing security extensions= as described in [RFC5304] and
1342 =C2=A0 [RFC5310] a= pply to these segment routing extensions.
[nit] Maybe break up the paragraph into m= ultiple ones with independent points.

[major] With the last sentence, are you imply= ing that authentication is required when IS-IS is carrying SR extensions?= =C2=A0 If so, please be explicit.=C2=A0 Why would these extensions be diffe= rent than any other extension?

[minor] The companion OSPF documents added the follo= wing paragraph to the Security Considerations as a result of one of the rev= iews...perhaps consider including something similar:

=C2=A0 =C2=A0Implementations M= UST assure that malformed TLV and Sub-TLV defined in
=C2=A0 =C2=A0this document are detected and do not provide a vulne= rability for
=C2=A0 =C2=A0attackers to crash= the OSPFv2 router or routing process.=C2=A0 Reception
=C2=A0 =C2=A0of malformed TLV or Sub-TLV SHOULD be counted and/o= r logged for
=C2=A0 =C2=A0further analysis.= =C2=A0 Logging of malformed TLVs and Sub-TLVs SHOULD be
=C2=A0 =C2=A0rate-limited to prevent a Denial of Service (DoS) = attack (distributed
=C2=A0 =C2=A0or otherwis= e) from overloading the OSPF control plane.
=

...=
1415 9.1.=C2=A0 Normative References
...
[minor] I think that the= se references can be Informative:

=
1463 =C2=A0 [RFC5305] =C2=A0Li, T. and H. Smit, "IS-IS= Extensions for Traffic
1464 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0Engineering", RFC 5305, DOI 10.17487/RFC5305, = October
1465 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A02008, <https:= //www.rfc-editor.org/info/rfc5305>.
<= br>
1467 =C2=A0 [RFC5308] =C2=A0Hopps, C., "Routi= ng IPv6 with IS-IS", RFC 5308,
1468 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0DOI 10.17487/RFC5308, October 2008,
1469 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<<= a href=3D"https://www.rfc-editor.org/info/rfc5308">https://www.rfc-editor.o= rg/info/rfc5308>.


...
1527 = =C2=A0 Les Ginsberg (editor)
1528 =C2=A0 Cisco= Systems, Inc.
1529 =C2=A0 IT

[nit] I didn't know you had = moved. ;-)
<= br>
=

--00000000000054e5c605848e084d-- From nobody Wed Mar 20 15:27:11 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEE3A1200D7; Wed, 20 Mar 2019 15:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.503 X-Spam-Level: X-Spam-Status: No, score=-14.503 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Z+bjSipT; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=MZ/BqxNt 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 F-nLqOtRUVuz; Wed, 20 Mar 2019 15:27:04 -0700 (PDT) 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 F3934126C01; Wed, 20 Mar 2019 15:27:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=58394; q=dns/txt; s=iport; t=1553120824; x=1554330424; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=t7imaJZXwkFIj7gZlGWq/KjI3HohDb8nrDl280dXl/Y=; b=Z+bjSipTgaWQGkcqGhdFL66D7NzmMYfyC0HMF2KMbHy+DHKalCBE5Nd2 wX7B/k+1E8ypCP/URmr5fYpQKRG1UmlraIqoo1pCVWDTm1yqk85pvSaPy IwhA31diakMWDZIQkjRrWZuPRQFlcHdfbPUVm8K0a1hXE58eotYWWUfs+ o=; IronPort-PHdr: =?us-ascii?q?9a23=3AxH6WgBG9IgPdfvw+rK1CsZ1GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4w0Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBjyJ/PnRyc7B89FElRi+iLzPA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B7AAD3vJJc/5ldJa1kHAEBAQQBAQc?= =?us-ascii?q?EAQGBUQcBAQsBgT0kBScDgVwECycKhAODRwOEUopUg1OIN41UgS4UgRADVAs?= =?us-ascii?q?BASyBKgGDFQIXhFAWDDQJDQEBAwEBCQEDAm0cDIVLBhoBCBEMAQElCwcBDwI?= =?us-ascii?q?BCA4ECAIRFQICAh8RFQIOAgQBDQUbgweBXgMVAQKgFQKKFHGBL4J4AQEFhQY?= =?us-ascii?q?NC4IMCIELJAGLMReBf4EQAScfgU5JNYJXgWUBDCICFBcVE4JLMYImihEggji?= =?us-ascii?q?LWotcKjYJAoskQYQKgz8ZgX2Fc4t1ixKBF4YciDKDKQIEAgQFAg4BAQWBTDh?= =?us-ascii?q?CgRRwFWUBgkGCCgwXgQABB4JDilNygSiJGYEtAYEeAQE?= X-IronPort-AV: E=Sophos;i="5.60,250,1549929600"; d="scan'208";a="248079959" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 Mar 2019 22:27:02 +0000 Received: from xch-rcd-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by rcdn-core-2.cisco.com (8.15.2/8.15.2) with ESMTPS id x2KMR1lD030376 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Mar 2019 22:27:01 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 20 Mar 2019 17:27:00 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 20 Mar 2019 18:26:59 -0400 Received: from NAM04-CO1-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.1473.3 via Frontend Transport; Wed, 20 Mar 2019 18:26:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=t7imaJZXwkFIj7gZlGWq/KjI3HohDb8nrDl280dXl/Y=; b=MZ/BqxNtFnAh+P3ZtmHfmbu5VusiKrlzCkrcEQjuLA8XjTCqOfS+4oyeEqjeXbAw/Y88Q+WwkmQ2LANqwlCBu5Y6DMTPU5Yx5dBJvE4nIJcEBG6Hr5k7ZtxCxewORUuWi5EmiRlBOmuJjb2dkevmms3aIuBJ2MrrhA0pA3a5vWU= Received: from BN8PR11MB3683.namprd11.prod.outlook.com (20.178.220.74) by BN8PR11MB3602.namprd11.prod.outlook.com (20.178.219.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.15; Wed, 20 Mar 2019 22:26:56 +0000 Received: from BN8PR11MB3683.namprd11.prod.outlook.com ([fe80::c62:f0b7:72a0:e853]) by BN8PR11MB3683.namprd11.prod.outlook.com ([fe80::c62:f0b7:72a0:e853%4]) with mapi id 15.20.1730.013; Wed, 20 Mar 2019 22:26:56 +0000 From: "Acee Lindem (acee)" To: Alvaro Retana , "draft-ietf-isis-segment-routing-extensions@ietf.org" CC: Uma Chunduri , "lsr-chairs@ietf.org" , "lsr@ietf.org" Thread-Topic: AD Review of draft-ietf-isis-segment-routing-extensions-22 Thread-Index: AQHU32s1ZTHtNdbfmUWTrdRrDGeTQqYU1ieA Date: Wed, 20 Mar 2019 22:26:56 +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: spf=none (sender IP is ) smtp.mailfrom=acee@cisco.com; x-originating-ip: [173.38.117.80] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 7f22701d-528f-4338-dae5-08d6ad832973 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BN8PR11MB3602; x-ms-traffictypediagnostic: BN8PR11MB3602: x-microsoft-antispam-prvs: x-forefront-prvs: 098291215C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(366004)(39860400002)(136003)(376002)(346002)(37854004)(189003)(199004)(51444003)(36756003)(30864003)(6246003)(7736002)(110136005)(305945005)(2906002)(54906003)(229853002)(86362001)(8676002)(6436002)(53936002)(99286004)(186003)(8936002)(81166006)(3846002)(81156014)(6512007)(66066001)(53946003)(486006)(68736007)(316002)(476003)(2616005)(11346002)(446003)(6486002)(6116002)(66574012)(14444005)(256004)(5024004)(71200400001)(83716004)(82746002)(6506007)(26005)(105586002)(71190400001)(106356001)(14454004)(76176011)(97736004)(102836004)(4326008)(2501003)(478600001)(25786009)(5660300002)(33656002)(579004)(569006); DIR:OUT; SFP:1101; SCL:1; SRVR:BN8PR11MB3602; H:BN8PR11MB3683.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: onjQ7S9EbuEcCcOyLyAxmdRNKiVmSTA3QQ1v7IbOTnvz7a54jHC6DAN/nXc3faEQnTWQr5P9xa6bYwazgSSeBwJMp0fv9FN0HUhPNuz0nL44oPeIBbY7cDBDfJTYImZn/lYuXFAtgsQWzQJLY+5pmJE98R5W12vrVOcvUQw7vSoZrz6fk/NlsrKK9TCPqucAPMGlDNRpi/SQiGApJrRgrZkvGOxepb628Hw1A6zsiAcfnPDTWZZpH1f/4Q3G/aqylBd/4h1xmtjY7Pq+6HHFhi5wSDFhC5SJWoFSuArL22SBnR8Qqru63xYnNeXcrfE+zMd5iA6xY7DUA+Oggn7QMC/Iyje8JnkuDEezpG4BIxuTELsbn1r5vHa+6HTkgj75+O+Yx0GWxMibKLB8R4U0FbQHC+xHkTKxETysp1Z5avk= Content-Type: text/plain; charset="utf-8" Content-ID: <9071E0BCA558F24E9C54766C48A3F97E@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 7f22701d-528f-4338-dae5-08d6ad832973 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Mar 2019 22:26:56.5662 (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-Transport-CrossTenantHeadersStamped: BN8PR11MB3602 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.21, xch-rcd-011.cisco.com X-Outbound-Node: rcdn-core-2.cisco.com Archived-At: Subject: Re: [Lsr] AD Review of draft-ietf-isis-segment-routing-extensions-22 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2019 22:27:09 -0000 VGhhbmtzIEFsdmFybyBmb3IgdGhlIHJldmlldyENCg0KQXV0aG9ycyAtIHBsZWFzZSBnaXZlIHRo ZXNlIGNvbW1lbnRzIHRoZSBoaWdoZXN0IHByaW9yaXR5Lg0KDQpUaGFua3MsDQpBY2VlIA0KDQrv u79PbiAzLzIwLzE5LCA2OjIxIFBNLCAiQWx2YXJvIFJldGFuYSIgPGFyZXRhbmEuaWV0ZkBnbWFp bC5jb20+IHdyb3RlOg0KDQogICAgRGVhciBhdXRob3JzOg0KICAgIA0KICAgIEkganVzdCBmaW5p c2hlZCByZXZpZXdpbmcgdGhpcyBkb2N1bWVudC4gIFBsZWFzZSB0YWtlIGEgbG9vayBhdCB0aGUg aW4tbGluZQ0KICAgIGNvbW1lbnRzIGJlbG93LiAgSW4gZ2VuZXJhbCwgSSB0aGluayB0aGF0IHNv bWUgbW9yZSB3b3JrIGlzIG5lZWRlZC4gIEkgd2lsbA0KICAgIHdhaXQgZm9yIHRoYXQgYmVmb3Jl IHN0YXJ0aW5nIHRoZSBJRVRGIExhc3QgQ2FsbC4NCiAgICANCiAgICBUaGVyZSBpcyBhIHNpZ25p ZmljYW50IGlzc3VlIHRoYXQgSSB3YW50IHRvIGhpZ2hsaWdodCBoZXJlICh0aGVyZSBhcmUgYWxz bw0KICAgIHJlbGF0ZWQgY29tbWVudHMgaW4tbGluZSk6DQogICAgDQogICAgLSDCpzIuMS4xLjIg dGFsa3MgYWJvdXQgaW50ZXJhY3Rpb24gd2l0aCByZmM3Nzk0IGFuZCBhIHRyYW5zaXRpb24gcGVy aW9kDQogICAgd2hpY2ggYXBwYXJlbnRseSBlbmRzIGluIHRoaXMgc3BlY2lmaWNhdGlvbiBub3Qg YmVpbmcgdXNlZC4gIEFtIEkgcmVhZGluZw0KICAgIHRoYXQgY29ycmVjdGx5Pw0KICAgIA0KICAg IFRoYW5rcyENCiAgICANCiAgICBBbHZhcm8uDQogICAgDQogICAgW0xpbmUgbnVtYmVycyBjb21l IGZyb20gaWRuaXRzLl0NCiAgICANCiAgICAuLi4NCiAgICAxMDcgMS4gIEludHJvZHVjdGlvbg0K ICAgIA0KICAgIDEwOSAgIFNlZ21lbnQgUm91dGluZyAoU1IpIGFsbG93cyBmb3IgYSBmbGV4aWJs ZSBkZWZpbml0aW9uIG9mIGVuZC10by1lbmQNCiAgICAxMTAgICBwYXRocyB3aXRoaW4gSUdQIHRv cG9sb2dpZXMgYnkgZW5jb2RpbmcgcGF0aHMgYXMgc2VxdWVuY2VzIG9mDQogICAgMTExICAgdG9w b2xvZ2ljYWwgc3ViLXBhdGhzLCBjYWxsZWQgInNlZ21lbnRzIi4gIFRoZXNlIHNlZ21lbnRzIGFy ZQ0KICAgIDExMiAgIGFkdmVydGlzZWQgYnkgdGhlIGxpbmstc3RhdGUgcm91dGluZyBwcm90b2Nv bHMgKElTLUlTIGFuZCBPU1BGKS4NCiAgICAxMTMgICBQcmVmaXggc2VnbWVudHMgcmVwcmVzZW50 IGFuIGVjbXAtYXdhcmUgc2hvcnRlc3QtcGF0aCB0byBhIHByZWZpeCAob3INCiAgICAxMTQgICBh IG5vZGUpLCBhcyBwZXIgdGhlIHN0YXRlIG9mIHRoZSBJR1AgdG9wb2xvZ3kuICBBZGphY2VuY3kg c2VnbWVudHMNCiAgICAxMTUgICByZXByZXNlbnQgYSBob3Agb3ZlciBhIHNwZWNpZmljIGFkamFj ZW5jeSBiZXR3ZWVuIHR3byBub2RlcyBpbiB0aGUNCiAgICAxMTYgICBJR1AuICBBIHByZWZpeCBz ZWdtZW50IGlzIHR5cGljYWxseSBhIG11bHRpLWhvcCBwYXRoIHdoaWxlIGFuDQogICAgMTE3ICAg YWRqYWNlbmN5IHNlZ21lbnQsIGluIG1vc3Qgb2YgdGhlIGNhc2VzLCBpcyBhIG9uZS1ob3AgcGF0 aC4gIFNSJ3MNCiAgICAxMTggICBjb250cm9sLXBsYW5lIGNhbiBiZSBhcHBsaWVkIHRvIGJvdGgg SVB2NiBhbmQgTVBMUyBkYXRhLXBsYW5lcywgYW5kDQogICAgMTE5ICAgZG8gbm90IHJlcXVpcmUg YW55IGFkZGl0aW9uYWwgc2lnbmFsaW5nIChvdGhlciB0aGFuIHRoZSByZWd1bGFyIElHUCkuDQog ICAgMTIwICAgRm9yIGV4YW1wbGUsIHdoZW4gdXNlZCBpbiBNUExTIG5ldHdvcmtzLCBTUiBwYXRo cyBkbyBub3QgcmVxdWlyZSBhbnkNCiAgICAxMjEgICBMRFAgb3IgUlNWUC1URSBzaWduYWxpbmcu ICBTdGlsbCwgU1IgY2FuIGludGVyb3BlcmF0ZSBpbiB0aGUgcHJlc2VuY2UNCiAgICAxMjIgICBv ZiBMU1BzIGVzdGFibGlzaGVkIHdpdGggUlNWUCBvciBMRFAuDQogICAgDQogICAgW25pdF0gcy9l Y21wLWF3YXJlL0VDTVAtYXdhcmUNCiAgICANCiAgICANCiAgICAxMjQgICBUaGVyZSBhcmUgYWRk aXRpb25hbCBzZWdtZW50IHR5cGVzLCBlLmcuLCBCaW5kaW5nIFNJRCBkZWZpbmVkIGluDQogICAg MTI1ICAgW1JGQzg0MDJdLiAgVGhpcyBkcmFmdCBhbHNvIGRlZmluZXMgYW4gYWR2ZXJ0aXNlbWVu dCBmb3Igb25lIHR5cGUgb2YNCiAgICAxMjYgICBCaW5kaW5nU0lEOiB0aGUgTWlycm9yIENvbnRl eHQgc2VnbWVudC4NCiAgICANCiAgICBbbml0XSBzL0JpbmRpbmdTSUQvQmluZGluZyBTSUQNCiAg ICANCiAgICANCiAgICAxMjggICBUaGlzIGRyYWZ0IGRlc2NyaWJlcyB0aGUgbmVjZXNzYXJ5IElT LUlTIGV4dGVuc2lvbnMgdGhhdCBuZWVkIHRvIGJlDQogICAgMTI5ICAgaW50cm9kdWNlZCBmb3Ig U2VnbWVudCBSb3V0aW5nIG9wZXJhdGluZyBvbiBhbiBNUExTIGRhdGEtcGxhbmUuDQogICAgDQog ICAgMTMxICAgU2VnbWVudCBSb3V0aW5nIGFyY2hpdGVjdHVyZSBpcyBkZXNjcmliZWQgaW4gW1JG Qzg0MDJdLg0KICAgIA0KICAgIFtuaXRdIHMvU2VnbWVudCBSb3V0aW5nIGFyY2hpdGVjdHVyZS9U aGUgU2VnbWVudCBSb3V0aW5nIGFyY2hpdGVjdHVyZQ0KICAgIA0KICAgIA0KICAgIDEzMyAgIFNl Z21lbnQgUm91dGluZyB1c2UgY2FzZXMgYXJlIGRlc2NyaWJlZCBpbiBbUkZDNzg1NV0uDQogICAg DQogICAgMTM1IDIuICBTZWdtZW50IFJvdXRpbmcgSWRlbnRpZmllcnMNCiAgICANCiAgICAxMzcg ICBTZWdtZW50IFJvdXRpbmcgYXJjaGl0ZWN0dXJlIChbUkZDODQwMl0pIGRlZmluZXMgZGlmZmVy ZW50IHR5cGVzIG9mDQogICAgMTM4ICAgU2VnbWVudCBJZGVudGlmaWVycyAoU0lEKS4gIFRoaXMg ZG9jdW1lbnQgZGVmaW5lcyB0aGUgSVMtSVMgZW5jb2RpbmdzDQogICAgMTM5ICAgZm9yIHRoZSBJ R1AtUHJlZml4LVNJRCwgdGhlIElHUC1BZGphY2VuY3ktU0lELCB0aGUgSUdQLUxBTi1BZGphY2Vu Y3ktDQogICAgMTQwICAgU0lEIGFuZCB0aGUgQmluZGluZy1TSUQuDQogICAgDQogICAgW25pdF0g cy8oW1JGQzg0MDJdKS9bUkZDODQwMl0NCiAgICANCiAgICBbbml0XSBzL1NlZ21lbnQgUm91dGlu ZyBhcmNoaXRlY3R1cmUvVGhlIFNlZ21lbnQgUm91dGluZyBhcmNoaXRlY3R1cmUNCiAgICANCiAg ICBbbWFqb3JdIHJmYzg0MDIgZG9lc24ndCB1c2UgdGhlIG5hbWVzIGFib3ZlLiAgUGxlYXNlIGJl IGNvbnNpc3RlbnQuDQogICAgDQogICAgDQogICAgMTQyIDIuMS4gIFByZWZpeCBTZWdtZW50IElk ZW50aWZpZXIgKFByZWZpeC1TSUQgU3ViLVRMVikNCiAgICANCiAgICAxNDQgICBBIG5ldyBJUy1J UyBzdWItVExWIGlzIGRlZmluZWQ6IHRoZSBQcmVmaXggU2VnbWVudCBJZGVudGlmaWVyIHN1Yi1U TFYNCiAgICAxNDUgICAoUHJlZml4LVNJRCBzdWItVExWKS4NCiAgICANCiAgICAxNDcgICBUaGUg UHJlZml4LVNJRCBzdWItVExWIGNhcnJpZXMgdGhlIFNlZ21lbnQgUm91dGluZyBJR1AtUHJlZml4 LVNJRCBhcw0KICAgIDE0OCAgIGRlZmluZWQgaW4gW1JGQzg0MDJdLiAgVGhlICdQcmVmaXggU0lE JyBNVVNUIGJlIHVuaXF1ZSB3aXRoaW4gYSBnaXZlbg0KICAgIDE0OSAgIElHUCBkb21haW4gKHdo ZW4gdGhlIEwtZmxhZyBpcyBub3Qgc2V0KS4gIFRoZSAnUHJlZml4IFNJRCcgTVVTVCBjYXJyeQ0K ICAgIDE1MCAgIGFuIGluZGV4ICh3aGVuIHRoZSBWLWZsYWcgaXMgbm90IHNldCkgdGhhdCBkZXRl cm1pbmVzIHRoZSBhY3R1YWwgU0lELw0KICAgIDE1MSAgIGxhYmVsIHZhbHVlIGluc2lkZSB0aGUg c2V0IG9mIGFsbCBhZHZlcnRpc2VkIFNJRC9sYWJlbCByYW5nZXMgb2YgYQ0KICAgIDE1MiAgIGdp dmVuIHJvdXRlci4gIEEgcmVjZWl2aW5nIHJvdXRlciB1c2VzIHRoZSBpbmRleCB0byBkZXRlcm1p bmUgdGhlDQogICAgMTUzICAgYWN0dWFsIFNJRC9sYWJlbCB2YWx1ZSBpbiBvcmRlciB0byBjb25z dHJ1Y3QgZm9yd2FyZGluZyBzdGF0ZSB0byBhDQogICAgMTU0ICAgcGFydGljdWxhciBkZXN0aW5h dGlvbiByb3V0ZXIuDQogICAgDQogICAgW21ham9yXSBXaGF0IGlmIHRoZSBQcmVmaXggU0lEIGlz IG5vdCB1bmlxdWU/ICBXaGF0IHNob3VsZCB0aGUgcmVjZWl2ZXIgZG8/DQogICAgDQogICAgW21h am9yXSAiLi4uTVVTVCBjYXJyeSBhbiBpbmRleC4uLnRoYXQgZGV0ZXJtaW5lcyB0aGUgYWN0dWFs IFNJRC9sYWJlbA0KICAgIHZhbHVlLi4uIiAgV2hhdCBhcmUgeW91IHRyeWluZyB0byBzcGVjaWZ5 IHdpdGggdGhpcyAiTVVTVCI/ICBUaGUNCiAgICBkZXNjcmlwdGlvbiBvZiB0aGUgVi1mbGFnIChi ZWxvdykgYWxyZWFkeSBwb2ludHMgYXQgdGhlIHZhbHVlIGJlaW5nIGFuDQogICAgaW5kZXgsIGJ1 dCB0aGUgcXVhbGlmaWNhdGlvbiAoInRoYXQgZGV0ZXJtaW5lcy4uLiIpIG1ha2VzIHRoZSBlbmZv cmNlbWVudA0KICAgIG9mIHRoaXMgIk1VU1QiIG1vcmUgY29tcGxleDogdGhlIHJlY2VpdmVyIGhh cyB0byB2ZXJpZnkgdGhhdCB0aGUgaW5kZXgNCiAgICBhY3R1YWxseSByZXN1bHRzIGluIGEgU0lE L2xhYmVsIGluc2lkZSBhIHJhbmdlIGZvciBpdCB0byBiZSB2YWxpZC4gICBXaGF0DQogICAgc2hv dWxkIHRoZSByZWNlaXZlciBkbyBpZiB0aGF0IGlzIG5vdCB0aGUgY2FzZT8NCiAgICANCiAgICBT dWdnZXN0aW9uOiBSZWFycmFuZ2UgdGhlIHRleHQgc28gdGhhdCB0aGUgVExWIGFuZCBpdHMgZmll bGRzIGFyZSBkZXNjcmliZWQNCiAgICBmaXJzdC4gIEkgdGhpbmsgdGhhdCB0aGVuIHNvbWUgb2Yg dGhlIHRleHQgYWJvdmUgd29uJ3QgYmUgbmVlZGVkLg0KICAgIA0KICAgIA0KICAgIDE1NiAgIElu IG1hbnkgdXNlLWNhc2VzIGEgJ3N0YWJsZSB0cmFuc3BvcnQnIElQIEFkZHJlc3MgaXMgb3Zlcmxv YWRlZCBhcyBhbg0KICAgIDE1NyAgIGlkZW50aWZpZXIgb2YgYSBnaXZlbiBub2RlLiAgQmVjYXVz ZSB0aGUgSVAgUHJlZml4ZXMgbWF5IGJlIHJlLQ0KICAgIDE1OCAgIGFkdmVydGlzZWQgaW50byBv dGhlciBsZXZlbHMgdGhlcmUgbWF5IGJlIHNvbWUgYW1iaWd1aXR5IChlLmcuDQogICAgMTU5ICAg T3JpZ2luYXRpbmcgcm91dGVyIHZzLiBMMUwyIHJvdXRlcikgZm9yIHdoaWNoIG5vZGUgYSBwYXJ0 aWN1bGFyIElQDQogICAgMTYwICAgcHJlZml4IHNlcnZlcyBhcyBpZGVudGlmaWVyLiAgVGhlIFBy ZWZpeC1TSUQgc3ViLVRMViBjb250YWlucyB0aGUNCiAgICAxNjEgICBuZWNlc3NhcnkgZmxhZ3Mg dG8gZGlzYW1iaWd1YXRlIElQIFByZWZpeCB0byBub2RlIG1hcHBpbmdzLg0KICAgIDE2MiAgIEZ1 cnRoZXJtb3JlIGlmIGEgZ2l2ZW4gbm9kZSBoYXMgc2V2ZXJhbCAnc3RhYmxlIHRyYW5zcG9ydCcg SVANCiAgICAxNjMgICBhZGRyZXNzZXMgdGhlcmUgYXJlIGZsYWdzIHRvIGRpZmZlcmVudGlhdGUg dGhvc2UgYW1vbmcgb3RoZXIgSVANCiAgICAxNjQgICBQcmVmaXhlcyBhZHZlcnRpc2VkIGZyb20g YSBnaXZlbiBub2RlLg0KICAgIA0KICAgIFttaW5vcl0gQWdhaW4sIHRoaXMgdGV4dCBtYXkgYmUg Y2xlYXJlciBpZiB0aGUgVExWIGRlc2NyaXB0aW9uIHdhcw0KICAgIHByZXNlbnRlZCBmaXJzdC4g IElmIHlvdSBkZWNpZGUgbm90IHRvIHJlYXJyYW5nZSB0aGUgdGV4dCwgYXQgbGVhc3QgcHV0DQog ICAgZm9yd2FyZCByZWZlcmVuY2VzIHNvIHJlYWRlcnMgY2FuIGxvb2sgZm9yd2FyZCB0byBmaW5k IG91dCBob3cgdGhlDQogICAgc3RhdGVtZW50IGFib3ZlIGlzIGFjaGlldmVkLg0KICAgIA0KICAg IA0KICAgIC4uLg0KICAgIDE4MCAgIFdoZW4gdGhlIElQIFJlYWNoYWJpbGl0eSBUTFYgaXMgcHJv cGFnYXRlZCBhY3Jvc3MgbGV2ZWwgYm91bmRhcmllcywNCiAgICAxODEgICB0aGUgUHJlZml4LVNJ RCBzdWItVExWIFNIT1VMRCBiZSBrZXB0Lg0KICAgIA0KICAgIFttYWpvcl0gV2hlbiB3b3VsZCB0 aGlzIHN1Yi1UTFYgbm90IGJlIGtlcHQ/ICBJT1csIHdoeSBpcyB0aGF0IG5vdCBhICJNVVNUIj8N CiAgICANCiAgICDCpzIuMS4yOiAiVGhlIFByZWZpeC1TSUQgc3ViLVRMViBNVVNUIGJlIHByZXNl cnZlZCB3aGVuIHRoZSBJUCBSZWFjaGFiaWxpdHkNCiAgICBUTFYNCiAgICBnZXRzIHByb3BhZ2F0 ZWQgYWNyb3NzIGxldmVsIGJvdW5kYXJpZXMuIg0KICAgIA0KICAgIEknbSBub3Qgc2F5aW5nIHRo YXQgb25lIHdheSBpcyBjb3JyZWN0Li4uZWl0aGVyIG9uZSBtYXkgYmUuICBKdXN0IGJlDQogICAg Y29uc2lzdGVudC4NCiAgICANCiAgICBbbWlub3JdIEknbSBhc3N1bWluZyB0aGF0ICJJUCBSZWFj aGFiaWxpdHkgVExWIiBtZWFucyBvbmUgb2YgdGhlIFRMVnMNCiAgICBhYm92ZSwgdHJ1ZT8gIEl0 IG1heSBiZSB3b3J0aCBjbGFyaWZ5aW5nIHRoYXQuDQogICAgDQogICAgDQogICAgMTgzICAgVGhl IFByZWZpeC1TSUQgc3ViLVRMViBoYXMgdGhlIGZvbGxvd2luZyBmb3JtYXQ6DQogICAgDQogICAg MTg1ICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAg ICAgICAgICAgIDMNCiAgICAxODYgICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2 IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxDQogICAgMTg3ICAgKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAx ODggICB8ICAgVHlwZSAgICAgICAgfCAgICAgTGVuZ3RoICAgIHwgICAgIEZsYWdzICAgICB8ICAg QWxnb3JpdGhtICAgfA0KICAgIDE4OSAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgMTkwICAgfCAgICAgICAgICAg ICAgICAgICAgICAgIFNJRC9JbmRleC9MYWJlbCAodmFyaWFibGUpICAgICAgICAgICAgIHwNCiAg ICAxOTEgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKw0KICAgIA0KICAgIDE5MyAgIHdoZXJlOg0KICAgIA0KICAgIDE5NSAg ICAgIFR5cGU6IFRCRCwgc3VnZ2VzdGVkIHZhbHVlIDMNCiAgICANCiAgICBbbWFqb3JdIFRoaXMg dmFsdWUgKGFuZCBhbGwgdGhlIG90aGVycyBpbiB0aGUgZG9jdW1lbnQpIGFyZSBub3QgInN1Z2dl c3RlZA0KICAgIHZhbHVlcyIsIHRoZXkgaGF2ZSBiZWVuIGFscmVhZHkgYWxsb2NhdGVkIGJ5IElB TkEuICBQbGVhc2UgdXBkYXRlIHRoZQ0KICAgIGluZGl2aWR1YWwgZGVzY3JpcHRpb25zIGFuZCB0 aGUgSUFOQSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uIGFjY29yZGluZ2x5Lg0KICAgIA0KICAgIA0K ICAgIDE5NyAgICAgIExlbmd0aDogdmFyaWFibGUuDQogICAgDQogICAgW21pbm9yXSBZZXMsIHZh cmlhYmxlLCBidXQgaXQgY2FuIG9ubHkgaGF2ZSB0d28gdmFsdWVzOiA1IG9yIDYuDQogICAgDQog ICAgDQogICAgMTk5ICAgICAgRmxhZ3M6IDEgb2N0ZXQgZmllbGQgb2YgZm9sbG93aW5nIGZsYWdz Og0KICAgIA0KICAgIDIwMSAgICAwIDEgMiAzIDQgNSA2IDcNCiAgICAyMDIgICArLSstKy0rLSst Ky0rLSstKw0KICAgIDIwMyAgIHxSfE58UHxFfFZ8THwgICB8DQogICAgMjA0ICAgKy0rLSstKy0r LSstKy0rLSsNCiAgICANCiAgICAyMDYgICAgICB3aGVyZToNCiAgICANCiAgICAyMDggICAgICAg ICBSLUZsYWc6IFJlLWFkdmVydGlzZW1lbnQgZmxhZy4gIElmIHNldCwgdGhlbiB0aGUgcHJlZml4 IHRvDQogICAgMjA5ICAgICAgICAgd2hpY2ggdGhpcyBQcmVmaXgtU0lEIGlzIGF0dGFjaGVkLCBo YXMgYmVlbiBwcm9wYWdhdGVkIGJ5IHRoZQ0KICAgIDIxMCAgICAgICAgIHJvdXRlciBlaXRoZXIg ZnJvbSBhbm90aGVyIGxldmVsIChpLmUuLCBmcm9tIGxldmVsLTEgdG8gbGV2ZWwtMg0KICAgIDIx MSAgICAgICAgIG9yIHRoZSBvcHBvc2l0ZSkgb3IgZnJvbSByZWRpc3RyaWJ1dGlvbiAoZS5nLjog ZnJvbSBhbm90aGVyDQogICAgMjEyICAgICAgICAgcHJvdG9jb2wpLg0KICAgIA0KICAgIFttYWpv cl0gU2hvdWxkIGl0IGJlIHVzZWQgdG8gYXZvaWQgbG9vcGluZyBhcyB3ZWxsPyAgT3IgaXMgdGhl cmUgbm8gcmlzayBvZg0KICAgIHRoYXQgaW4gdGhpcyBjYXNlPw0KICAgIA0KICAgIA0KICAgIC4u Lg0KICAgIDIzNiAgICAgICAgIE90aGVyIGJpdHM6IE1VU1QgYmUgemVybyB3aGVuIG9yaWdpbmF0 ZWQgYW5kIGlnbm9yZWQgd2hlbg0KICAgIDIzNyAgICAgICAgIHJlY2VpdmVkLg0KICAgIA0KICAg IFttYWpvcl0gRG8geW91IGV4cGVjdCBJQU5BIHRvIGhhbmRsZSB0aGUgYXNzaWdubWVudCBvZiB0 aG9zZSBvdGhlciBiaXRzPw0KICAgIA0KICAgIA0KICAgIDIzOSAgICAgIEFsZ29yaXRobTogdGhl IHJvdXRlciBtYXkgdXNlIHZhcmlvdXMgYWxnb3JpdGhtcyB3aGVuIGNhbGN1bGF0aW5nDQogICAg MjQwICAgICAgcmVhY2hhYmlsaXR5IHRvIG90aGVyIG5vZGVzIG9yIHRvIHByZWZpeGVzIGF0dGFj aGVkIHRvIHRoZXNlDQogICAgMjQxICAgICAgbm9kZXMuICBBbGdvcml0aG1zIGlkZW50aWZpZXJz IGFyZSBkZWZpbmVkIGluIFNlY3Rpb24gMy4yLg0KICAgIDI0MiAgICAgIEV4YW1wbGVzIG9mIHRo ZXNlIGFsZ29yaXRobXMgYXJlIG1ldHJpYyBiYXNlZCBTaG9ydGVzdCBQYXRoIEZpcnN0DQogICAg MjQzICAgICAgKFNQRiksIHZhcmlvdXMgc29ydHMgb2YgQ29uc3RyYWluZWQgU1BGLCBldGMuICBU aGUgYWxnb3JpdGhtIGZpZWxkDQogICAgMjQ0ICAgICAgb2YgdGhlIFByZWZpeC1TSUQgY29udGFp bnMgdGhlIGlkZW50aWZpZXIgb2YgdGhlIGFsZ29yaXRobSB0aGUNCiAgICAyNDUgICAgICByb3V0 ZXIgaGFzIHVzZWQgaW4gb3JkZXIgdG8gY29tcHV0ZSB0aGUgcmVhY2hhYmlsaXR5IG9mIHRoZSBw cmVmaXgNCiAgICAyNDYgICAgICB0byB3aGljaCB0aGUgUHJlZml4LVNJRCBpcyBhc3NvY2lhdGVk Lg0KICAgIA0KICAgIDI0OCAgICAgIEF0IG9yaWdpbmF0aW9uLCB0aGUgUHJlZml4LVNJRCBhbGdv cml0aG0gZmllbGQgTVVTVCBiZSBzZXQgdG8gMCBvcg0KICAgIDI0OSAgICAgIHRvIGFueSB2YWx1 ZSBhZHZlcnRpc2VkIGluIHRoZSBTUi1BbGdvcml0aG0gc3ViLVRMViAoU2VjdGlvbiAzLjIpLg0K ICAgIA0KICAgIFttYWpvcl0gV2hhdCBzaG91bGQgYSByZWNlaXZlciBkbyBpZiB0aGUgQWxnb3Jp dGhtIHZhbHVlIGRvZXNuJ3QgbWF0Y2ggd2hhdA0KICAgIGhhcyBiZWVuIGFkdmVydGlzZWQgaW4g dGhlIFNSLUFsZ29yaXRobSBTdWItVExWPw0KICAgIA0KICAgIA0KICAgIC4uLg0KICAgIDI4MiAy LjEuMS4yLiAgUiBhbmQgTiBGbGFncw0KICAgIA0KICAgIDI4NCAgIFRoZSBSLUZsYWcgTVVTVCBi ZSBzZXQgZm9yIHByZWZpeGVzIHRoYXQgYXJlIG5vdCBsb2NhbCB0byB0aGUgcm91dGVyDQogICAg Mjg1ICAgYW5kIGVpdGhlcjoNCiAgICANCiAgICAyODcgICAgICBhZHZlcnRpc2VkIGJlY2F1c2Ug b2YgcHJvcGFnYXRpb24gKExldmVsLTEgaW50byBMZXZlbC0yKTsNCiAgICANCiAgICAyODkgICAg ICBhZHZlcnRpc2VkIGJlY2F1c2Ugb2YgbGVha2luZyAoTGV2ZWwtMiBpbnRvIExldmVsLTEpOw0K ICAgIA0KICAgIDI5MSAgICAgIGFkdmVydGlzZWQgYmVjYXVzZSBvZiByZWRpc3RyaWJ1dGlvbiAo ZS5nLjogZnJvbSBhbm90aGVyDQogICAgMjkyICAgICAgcHJvdG9jb2wpLg0KICAgIA0KICAgIDI5 NCAgIEluIHRoZSBjYXNlIHdoZXJlIGEgTGV2ZWwtMS0yIHJvdXRlciBoYXMgbG9jYWwgaW50ZXJm YWNlIGFkZHJlc3Nlcw0KICAgIDI5NSAgIGNvbmZpZ3VyZWQgaW4gb25lIGxldmVsLCBpdCBtYXkg YWxzbyBwcm9wYWdhdGUgdGhlc2UgYWRkcmVzc2VzIGludG8NCiAgICAyOTYgICB0aGUgb3RoZXIg bGV2ZWwuICBJbiBzdWNoIGNhc2UsIHRoZSBMZXZlbC0xLTIgcm91dGVyIE1VU1QgTk9UIHNldCB0 aGUNCiAgICAyOTcgICBSIGJpdC4gIFRoZSBSLWJpdCBNVVNUIGJlIHNldCBvbmx5IGZvciBwcmVm aXhlcyB0aGF0IGFyZSBub3QgbG9jYWwgdG8NCiAgICAyOTggICB0aGUgcm91dGVyIGFuZCBhZHZl cnRpc2VkIGJ5IHRoZSByb3V0ZXIgYmVjYXVzZSBvZiBwcm9wYWdhdGlvbiBhbmQvb3INCiAgICAy OTkgICBsZWFraW5nLg0KICAgIA0KICAgIFttaW5vcl0gVGhpcyBsYXN0IHNlbnRlbmNlIGlzIHJl ZHVuZGFudCB3aXRoIHRoZSBzdGFydCBvZiB0aGlzIHNlY3Rpb24uDQogICAgUGxlYXNlIHNwZWNp ZnkgdGhlIGJlaGF2aW9yIGp1c3Qgb25jZS4NCiAgICANCiAgICANCiAgICAzMDEgICBUaGUgTi1G bGFnIGlzIHVzZWQgaW4gb3JkZXIgdG8gZGVmaW5lIGEgTm9kZS1TSUQuICBBIHJvdXRlciBNQVkg c2V0DQogICAgMzAyICAgdGhlIE4tRmxhZyBvbmx5IGlmIGFsbCBvZiB0aGUgZm9sbG93aW5nIGNv bmRpdGlvbnMgYXJlIG1ldDoNCiAgICANCiAgICAzMDQgICAgICBUaGUgcHJlZml4IHRvIHdoaWNo IHRoZSBQcmVmaXgtU0lEIGlzIGF0dGFjaGVkIGlzIGxvY2FsIHRvIHRoZQ0KICAgIDMwNSAgICAg IHJvdXRlciAoaS5lLiwgdGhlIHByZWZpeCBpcyBjb25maWd1cmVkIG9uIG9uZSBvZiB0aGUgbG9j YWwNCiAgICAzMDYgICAgICBpbnRlcmZhY2VzLCBlLmcuLCBhICdzdGFibGUgdHJhbnNwb3J0JyBs b29wYmFjaykuDQogICAgDQogICAgMzA4ICAgICAgVGhlIHByZWZpeCB0byB3aGljaCB0aGUgUHJl Zml4LVNJRCBpcyBhdHRhY2hlZCBNVVNUIGhhdmUgYSBQcmVmaXgNCiAgICAzMDkgICAgICBsZW5n dGggb2YgZWl0aGVyIC8zMiAoSVB2NCkgb3IgLzEyOCAoSVB2NikuDQogICAgDQogICAgW21ham9y XSAiVGhlIHByZWZpeC4uLk1VU1QgaGF2ZSBhIFByZWZpeCBsZW5ndGguLi4iICBUaGlzIGNvbmRp dGlvbiBpcyBub3QNCiAgICB3b3JkZWQgYXMgb25lOyBwZXJoYXBzOiAiVGhlIHByZWZpeC4uLmhh cyBhIFByZWZpeCBsZW5ndGguLi4iDQogICAgDQogICAgW21pbm9yXSBXaHkgaXMgdGhlIE4tRmxh ZyBuZWVkZWQ/ICBJZiB0aGUgc2V0dGluZyBpcyBvcHRpb25hbCAoIk1BWSIpLCB0aGVuDQogICAg bm90IHNldHRpbmcgaXQgZG9lc24ndCBpbXBseSB0aGF0IHRoZSBjb25kaXRpb25zIGFyZSBub3Qg bWV0Li4uDQogICAgDQogICAgW21ham9yXSBJdCBpcyBjbGVhcmx5IGFuIGVycm9yIGlmIGJvdGgg dGhlIFItRmxhZyBhbmQgTi1GbGFnIGFyZSBzZXQsDQogICAgcmlnaHQ/ICBXaGF0IHNob3VsZCB0 aGUgcmVjZWl2ZXIgZG8gaW4gdGhhdCBjYXNlPw0KICAgIA0KICAgIA0KICAgIDMxMSAgIFRoZSBy b3V0ZXIgTVVTVCBpZ25vcmUgdGhlIE4tRmxhZyBvbiBhIHJlY2VpdmVkIFByZWZpeC1TSUQgaWYg dGhlDQogICAgMzEyICAgcHJlZml4IGhhcyBhIFByZWZpeCBsZW5ndGggZGlmZmVyZW50IHRoYW4g LzMyIChJUHY0KSBvciAvMTI4IChJUHY2KS4NCiAgICANCiAgICAzMTQgICBbUkZDNzc5NF0gYWxz byBkZWZpbmVzIHRoZSBOIGFuZCBSIGZsYWdzIGFuZCB3aXRoIHRoZSBzYW1lIHNlbWFudGljcw0K ICAgIDMxNSAgIG9mIHRoZSBlcXVpdmFsZW50IGZsYWdzIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVu dC4gIFRoZXJlIHdpbGwgYmUgYQ0KICAgIDMxNiAgIHRyYW5zaXRpb24gcGVyaW9kIHdoZXJlIGJv dGggc2V0cyBvZiBmbGFncyB3aWxsIGJlIHVzZWQgYW5kDQogICAgMzE3ICAgZXZlbnR1YWxseSBv bmx5IHRoZSBmbGFncyBvZiB0aGUgUHJlZml4IEF0dHJpYnV0ZXMgd2lsbCByZW1haW4uDQogICAg MzE4ICAgRHVyaW5nIHRoZSB0cmFuc2l0aW9uIHBlcmlvZCBpbXBsZW1lbnRhdGlvbnMgc3VwcG9y dGluZyB0aGUgTiBhbmQgUg0KICAgIDMxOSAgIGZsYWdzIGRlZmluZWQgaW4gdGhpcyBkb2N1bWVu dCBhbmQgdGhlIE4gYW5kIFIgZmxhZ3MgZGVmaW5lZCBpbg0KICAgIDMyMCAgIFtSRkM3Nzk0XSBN VVNUIGFkdmVydGlzZSBhbmQgcGFyc2UgYWxsIGZsYWdzLiAgSW4gY2FzZSB0aGUgcmVjZWl2ZWQN CiAgICAzMjEgICBmbGFncyBoYXZlIGRpZmZlcmVudCB2YWx1ZXMsIHRoZSB2YWx1ZSBvZiB0aGUg ZmxhZ3MgZGVmaW5lZCBpbg0KICAgIDMyMiAgIFtSRkM3Nzk0XSBwcmV2YWlscy4NCiAgICANCiAg ICBbbWFqb3JdICIuLi50cmFuc2l0aW9uIHBlcmlvZCB3aGVyZSBib3RoIHNldHMgb2YgZmxhZ3Mg d2lsbCBiZSB1c2VkIGFuZA0KICAgIGV2ZW50dWFsbHkgb25seSB0aGUgZmxhZ3Mgb2YgdGhlIFBy ZWZpeCBBdHRyaWJ1dGVzIHdpbGwgcmVtYWluIiAgVG8gYmUNCiAgICBob25lc3QsIHlvdSBsb3N0 IG1lIGhlcmU/ICBQbGVhc2UgZXhwbGFpbiB3aGF0IHdpbGwgdGhlIHRyYW5zaXRpb24gcGVyaW9k DQogICAgYmUgYmV0d2Vlbj8NCiAgICANCiAgICBbbWFqb3JdIElmICJib3RoIHNldHMgb2YgZmxh Z3Mgd2lsbCBiZSB1c2VkIGFuZCBldmVudHVhbGx5IG9ubHkgdGhlDQogICAgW2FscmVhZHkgZGVm aW5lZF0gZmxhZ3Mgb2YgdGhlIFByZWZpeCBBdHRyaWJ1dGVzIHdpbGwgcmVtYWluIiwgd2h5IGRv IHdlDQogICAgbmVlZCB0aGUgbmV3IG9uZXM/DQogICAgDQogICAgW21ham9yXSAiTVVTVCBhZHZl cnRpc2UgYW5kIHBhcnNlIGFsbCBmbGFncyIgIFdoYXQgZG9lcyB0aGlzIG1lYW4/ICBCeSAiYWxs DQogICAgZmxhZ3MiIEkgZ3Vlc3MgeW91IG1lYW4gdGhlIE4gYW5kIFIgZmxhZ3MuLi5idXQgaWYg Ym90aCB0aGlzIGRvY3VtZW50IGFuZA0KICAgIHJmYzc3OTQgYXJlIGltcGxlbWVudGVkLCBpdCBz ZWVtcyB0byBtZSB0aGF0IHRoZSBzcGVjaWZpY2F0aW9uIGFib3ZlIGlzDQogICAgcmVhbGx5IG1l YW5pbmdsZXNzLg0KICAgIA0KICAgIFttYWpvcl0gIkluIGNhc2UgdGhlIHJlY2VpdmVkIGZsYWdz IGhhdmUgZGlmZmVyZW50IHZhbHVlcy4uLiIgIEZvciBhIHNlY29uZA0KICAgIGl0IHNlZW1lZCB0 byBtZSB0aGF0IHdoYXQgeW91IHJlYWxseSB3YW50ZWQgd2FzIGZvciB0aGUgZmxhZ3MgaW4gdGhp cw0KICAgIGRvY3VtZW50IHRvIGJlaGF2ZSB0aGUgc2FtZSB3YXkgYXMgdGhlIGZsYWdzIGRlZmlu ZWQgaW4gcmZjNzc5NC4uLnRoZSBlYXN5DQogICAgc29sdXRpb24gdG8gdGhhdCAoYW5kIHRvIGF2 b2lkIG15IHF1ZXN0aW9ucyBsaXN0ZWQgYmVmb3JlIHJmYzc3OTQgd2FzDQogICAgbWVudGlvbmVk KSB3b3VsZCBoYXZlIGJlZW4gdG8ganVzdCBwb2ludCBhdCByZmM3Nzk0IGFzIHRoZSBwbGFjZSB3 aGVyZSB0aGUNCiAgICBGbGFncyBhcmUgZGVmaW5lZC4gIEhvd2V2ZXIsIGl0IGxvb2tzIGxpa2Ug dGhlIGRlZmluaXRpb25zIChhdCBsZWFzdCBmb3INCiAgICB0aGUgUi1GbGFnKSBhcmUgbm90IHRo ZSBzYW1lLiAgSXMgdGhhdCBvbiBwdXJwb3NlIG9yIGlzIGl0IGp1c3QgYW4NCiAgICBvdmVyc2ln aHQ/DQogICAgDQogICAgT25lIHBpZWNlIG9mIGluZm9ybWF0aW9uIHRoYXQgbWlnaHQgbWFrZSB0 aGlzIGRpc2N1c3Npb24gcmVsZXZhbnQgaXMNCiAgICB1bmRlcnN0YW5kaW5nIHRoZSBzaWduaWZp Y2FuY2Ugb2YgdGhlc2UgRmxhZ3MuLi5idXQgbmVpdGhlciBkb2N1bWVudCBvZmZlcnMNCiAgICBh bnkgc3BlY2lmaWMgdXNlLCBiZXlvbmQgc2ltcGx5ICJpdCBtYXkgYmUgdXNlZnVsIGZvciBvdGhl ciByb3V0ZXJzIHRvDQogICAga25vdyIgKHJmYzc3OTQsIMKnMi4yKS4NCiAgICANCiAgICANCiAg ICAzMjQgMi4xLjEuMy4gIEUgYW5kIFAgRmxhZ3MNCiAgICANCiAgICAzMjYgICBXaGVuIGNhbGN1 bGF0aW5nIHRoZSBvdXRnb2luZyBsYWJlbCBmb3IgdGhlIHByZWZpeCwgdGhlIHJvdXRlciBNVVNU DQogICAgMzI3ICAgdGFrZSBpbnRvIGFjY291bnQgRSBhbmQgUCBmbGFncyBhZHZlcnRpc2VkIGJ5 IHRoZSBuZXh0LWhvcCByb3V0ZXIsIGlmDQogICAgMzI4ICAgbmV4dC1ob3Agcm91dGVyIGFkdmVy dGlzZWQgdGhlIFNJRCBmb3IgdGhlIHByZWZpeC4gIFRoaXMgTVVTVCBiZSBkb25lDQogICAgMzI5 ICAgcmVnYXJkbGVzcyBvZiBuZXh0LWhvcCByb3V0ZXIgY29udHJpYnV0aW5nIHRvIHRoZSBiZXN0 IHBhdGggdG8gdGhlDQogICAgMzMwICAgcHJlZml4IG9yIG5vdC4NCiAgICANCiAgICBbbWFqb3Jd ICJ0aGUgcm91dGVyIE1VU1QgdGFrZSBpbnRvIGFjY291bnQiICBXaGF0IG5vcm1hdGl2ZSBhY3Rp b24gaXMNCiAgICBzdGFuZGFyZGl6ZWQgd2l0aCB0aGF0IHBocmFzZT8gIEl0IHdvdWxkIGJlIGNs ZWFyZXIvYmV0dGVyIGlmIHRoZSBiZWhhdmlvcg0KICAgIGlzIGV4cGxpY2l0bHkgc3BlY2lmaWVk IGluIGZ1bmN0aW9uIG9mIHRoZSBmbGFncyAoYXMgc29uZSBiZWxvdykuDQogICAgIHMvTVVTVC9t dXN0DQogICAgDQogICAgW21ham9yXSAiVGhpcyBNVVNUIGJlIGRvbmUgcmVnYXJkbGVzcyBvZiBu ZXh0LWhvcCByb3V0ZXIgY29udHJpYnV0aW5nIHRvDQogICAgdGhlIGJlc3QgcGF0aCB0byB0aGUg cHJlZml4IG9yIG5vdC4iICBUaGlzIHdoYXQ/ICBJJ20gYXNzdW1pbmcgdGhlIHRleHQNCiAgICBy ZWZlcnMgdG8gInRha2UgaW50byBhY2NvdW50Ii4uLiAgU2FtZSBjb21tZW50IGFzIGJlZm9yZTog cy9NVVNUL211c3QNCiAgICANCiAgICANCiAgICAuLi4NCiAgICAzNjYgMi4xLjIuICBQcmVmaXgt U0lEIFByb3BhZ2F0aW9uDQogICAgDQogICAgMzY4ICAgVGhlIFByZWZpeC1TSUQgc3ViLVRMViBN VVNUIGJlIHByZXNlcnZlZCB3aGVuIHRoZSBJUCBSZWFjaGFiaWxpdHkgVExWDQogICAgMzY5ICAg Z2V0cyBwcm9wYWdhdGVkIGFjcm9zcyBsZXZlbCBib3VuZGFyaWVzLg0KICAgIA0KICAgIFttYWpv cl0gwqcyLjEgc2F5cyB0aGF0IGl0IFNIT1VMRC4gIFBsZWFzZSBiZSBjb25zaXN0ZW50Li4uYW5k LCBzcGVjaWZ5DQogICAgYmVoYXZpb3Igb25seSBvbmNlLg0KICAgIA0KICAgIDM3MSAgIFRoZSBs ZXZlbC0xLTIgcm91dGVyIHRoYXQgcHJvcGFnYXRlcyB0aGUgUHJlZml4LVNJRCBzdWItVExWIGJl dHdlZW4NCiAgICAzNzIgICBsZXZlbHMgTVVTVCBzZXQgdGhlIFItZmxhZy4NCiAgICANCiAgICAz NzQgICBJZiB0aGUgUHJlZml4LVNJRCBjb250YWlucyBhIGdsb2JhbCBpbmRleCAoTCBhbmQgViBm bGFncyB1bnNldCkgYW5kDQogICAgMzc1ICAgaXQgaXMgcHJvcGFnYXRlZCBhcyBzdWNoICh3aXRo IEwgYW5kIFYgZmxhZ3MgdW5zZXQpLCB0aGUgdmFsdWUgb2YgdGhlDQogICAgMzc2ICAgaW5kZXgg TVVTVCBiZSBwcmVzZXJ2ZWQgd2hlbiBwcm9wYWdhdGVkIGJldHdlZW4gbGV2ZWxzLg0KICAgIA0K ICAgIDM3OCAgIFRoZSBsZXZlbC0xLTIgcm91dGVyIHRoYXQgcHJvcGFnYXRlcyB0aGUgUHJlZml4 LVNJRCBzdWItVExWIGJldHdlZW4NCiAgICAzNzkgICBsZXZlbHMgTUFZIGNoYW5nZSB0aGUgc2V0 dGluZyBvZiB0aGUgTCBhbmQgViBmbGFncyBpbiBjYXNlIGEgbG9jYWwNCiAgICAzODAgICBsYWJl bCB2YWx1ZSBpcyBlbmNvZGVkIGluIHRoZSBQcmVmaXgtU0lEIGluc3RlYWQgb2YgdGhlIHJlY2Vp dmVkDQogICAgMzgxICAgdmFsdWUuDQogICAgDQogICAgW21ham9yXSAgVXAgdG8gbm93LCBJIGhh ZCBiZWVuIGFzc3VtaW5nIHRoYXQgcHJvcGFnYXRpbmcgYW5kIHByZXNlcnZpbmcNCiAgICBtZWFu dCBub3QgY2hhbmdpbmcgdGhlIHN1Yi1UTFYgKGV4Y2VwdCBmb3IgdGhlIFItRmxhZykuICBCdXQg dGhlc2UgbGFzdA0KICAgIHBhcmFncmFwaHMgaW5kaWNhdGUgdGhhdCBub3Qgb25seSBjYW4gc29t ZSBmbGFncyBiZSBjaGFuZ2VkLCBidXQgdGhlDQogICAgY29udGVudHMgY2FuIGNvbXBsZXRlbHkg Y2hhbmdlLiAgSXQgd291bGQgYmUgaWRlYWwgaWYgdGhlIHZhbGlkIG9wZXJhdGlvbnMNCiAgICBv biB0aGUgc3ViLVRMViB3ZXJlIGRpc2N1c3NlZCAob3IgYXQgbGVhc3QgcmVmZXJlbmNlZCkgd2hl biB0aGUgcHJlc2VydmluZw0KICAgIGJlaGF2aW9yIHdhcyBmaXJzdCBpbnRyb2R1Y2VkIChJIHRo aW5rIGluIMKnMi4xKS4NCiAgICANCiAgICANCiAgICAuLi4NCiAgICA0MDkgMi4yLjEuICBBZGph Y2VuY3kgU2VnbWVudCBJZGVudGlmaWVyIChBZGotU0lEKSBTdWItVExWDQogICAgDQogICAgNDEx ICAgVGhlIGZvbGxvd2luZyBmb3JtYXQgaXMgZGVmaW5lZCBmb3IgdGhlIEFkai1TSUQgc3ViLVRM VjoNCiAgICANCiAgICA0MTMgICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAg ICAgIDIgICAgICAgICAgICAgICAgICAgMw0KICAgIDQxNCAgICAwIDEgMiAzIDQgNSA2IDcgOCA5 IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCiAgICA0MTUgICAr LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKw0KICAgIDQxNiAgIHwgICBUeXBlICAgICAgICB8ICAgICBMZW5ndGggICAgfCAgICAg RmxhZ3MgICAgIHwgICAgIFdlaWdodCAgICB8DQogICAgNDE3ICAgKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICA0MTgg ICB8ICAgICAgICAgICAgICAgICAgICAgICAgIFNJRC9MYWJlbC9JbmRleCAodmFyaWFibGUpICAg ICAgICAgICAgfA0KICAgIDQxOSAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgDQogICAgNDIxICAgd2hlcmU6DQog ICAgDQogICAgNDIzICAgICAgVHlwZTogVEJELCBzdWdnZXN0ZWQgdmFsdWUgMzENCiAgICANCiAg ICA0MjUgICAgICBMZW5ndGg6IHZhcmlhYmxlLg0KICAgIA0KICAgIFttaW5vcl0gWWVzLCB2YXJp YWJsZSwgYnV0IGl0IGNhbiBvbmx5IGhhdmUgdHdvIHZhbHVlcy4uLg0KICAgIA0KICAgIDQyNyAg ICAgIEZsYWdzOiAxIG9jdGV0IGZpZWxkIG9mIGZvbGxvd2luZyBmbGFnczoNCiAgICANCiAgICA0 MjkgICAgICAgICAgMCAxIDIgMyA0IDUgNiA3DQogICAgNDMwICAgICAgICAgKy0rLSstKy0rLSst Ky0rLSsNCiAgICA0MzEgICAgICAgICB8RnxCfFZ8THxTfFB8ICAgfA0KICAgIDQzMiAgICAgICAg ICstKy0rLSstKy0rLSstKy0rDQogICAgDQogICAgNDM0ICAgICAgd2hlcmU6DQogICAgDQogICAg NDM2ICAgICAgICAgRi1GbGFnOiBBZGRyZXNzLUZhbWlseSBmbGFnLiAgSWYgdW5zZXQsIHRoZW4g dGhlIEFkai1TSUQgcmVmZXJzDQogICAgNDM3ICAgICAgICAgdG8gYW4gYWRqYWNlbmN5IHdpdGgg b3V0Z29pbmcgSVB2NCBlbmNhcHN1bGF0aW9uLiAgSWYgc2V0IHRoZW4NCiAgICA0MzggICAgICAg ICB0aGUgQWRqLVNJRCByZWZlcnMgdG8gYW4gYWRqYWNlbmN5IHdpdGggb3V0Z29pbmcgSVB2Ng0K ICAgIDQzOSAgICAgICAgIGVuY2Fwc3VsYXRpb24uDQogICAgDQogICAgW21ham9yXSBUaGlzIGRv Y3VtZW50IGRlc2NyaWJlcyB0aGUgb3BlcmF0aW9uIG9uIHRoZSBNUExTIGRhdGEgcGxhbmUsDQog ICAgcmlnaHQ/ICBUaGUgRi1GbGFnIHRhbGtzIGFib3V0IHRoZSBvdXRnb2luZyBlbmNhcHN1bGF0 aW9uLi4uYnV0IHRoYXQgY291bGQNCiAgICBzaW1wbHkgYmUgdGhlIG5leHQgbGFiZWwgaW4gdGhl IE1QTFMgc3RhY2ssIHJpZ2h0PyAgV2hhdCBhbSBJIG1pc3Npbmc/ICBJDQogICAgZ2V0IHRoZSBp bXByZXNzaW9uIHRoYXQgdGhlcmUncyBhIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHdoYXQgdGhpcyBG bGFnDQogICAgcG9pbnRzIHRvIGFuZCBzb21ldGhpbmcgZWxzZS4uLmJ1dCBJIGp1c3QgZG9uJ3Qg a25vdyB3aGF0Lg0KICAgIA0KICAgIA0KICAgIDQ0MSAgICAgICAgIEItRmxhZzogQmFja3VwIGZs YWcuICBJZiBzZXQsIHRoZSBBZGotU0lEIGlzIGVsaWdpYmxlIGZvcg0KICAgIDQ0MiAgICAgICAg IHByb3RlY3Rpb24gKGUuZy46IHVzaW5nIElQRlJSIG9yIE1QTFMtRlJSKSBhcyBkZXNjcmliZWQg aW4NCiAgICA0NDMgICAgICAgICBbUkZDODM1NV0uDQogICAgDQogICAgW21ham9yXSBCZWNhdXNl IHRoZSBzcGVjaWZpY2F0aW9uIG9mIHRoZSBCLUZsYWcgZGVwZW5kcyBkaXJlY3RseSBvbg0KICAg IHJmYzgzNTUsIGl0IHNob3VsZCBiZSBhIE5vcm1hdGl2ZSByZWZlcmVuY2UuICBMb29raW5nIGF0 IHJmYzgzNTUsIEkNCiAgICBjb3VsZG4ndCBmaW5kIGEgcGxhY2Ugd2hlcmUgaXQgdGFsa3MgYWJv dXQgZWxpZ2liaWxpdHkgZm9yDQogICAgcHJvdGVjdGlvbi4uLmp1c3QgdGV4dCBhYm91dCBwb3Rl bnRpYWwgc3RyYXRlZ2llcywgYnV0IChob25lc3RseSkgbm90aGluZw0KICAgIHRoYXQgSSB3b3Vs ZCBjYWxsIE5vcm1hdGl2ZS4gIFBsZWFzZSBjbGFyaWZ5LiAgUGVyaGFwcyByZmM4NDAyIG1pZ2h0 IGJlIGENCiAgICBiZXR0ZXIgcmVmZXJlbmNlLg0KICAgIA0KICAgIFttYWpvcl0gSSdtIGFzc3Vt aW5nIHRoYXQgdGhpcyBkZXNjcmlwdGlvbiAocG9pbnRpbmcgYXQgcmZjODM1NSksIHBsdXMgdGhl DQogICAgdGV4dCBiZWxvdyBhYm91dCBhbGxvY2F0aW9uIG9mIEFkai1TSURzIHNob3VsZCByZXN1 bHQgaW4gc29tZSBhY3Rpb24NCiAgICByZWxhdGVkIHRvIHRoZSBwcm90ZWN0aW9uLi4ud2hhdCBp cyB0aGF0PyAgSU9XLCBwcmVzZW50ZWQgd2l0aCB0aGUgQi1GbGFnDQogICAgc2V0LCB3aGF0IGFj dGlvbiBzaG91bGQgYSBub2RlIHRha2U/DQogICAgDQogICAgDQogICAgNDQ1ICAgICAgICAgVi1G bGFnOiBWYWx1ZSBmbGFnLiAgSWYgc2V0LCB0aGVuIHRoZSBBZGotU0lEIGNhcnJpZXMgYSB2YWx1 ZS4NCiAgICA0NDYgICAgICAgICBCeSBkZWZhdWx0IHRoZSBmbGFnIGlzIFNFVC4NCiAgICANCiAg ICBbbWlub3JdIElzIHRoZSBkZXNjcmlwdGlvbiB0aGUgc2FtZSBhdCB0aGUgVi1GbGFnIGluIMKn Mi4xPyAgSWYgc28sIHRoZW4NCiAgICBpbmRpY2F0aW5nIHRoYXQsIG9yIGF0IGxlYXN0IGFsc28g cG9pbnRpbmcgb3V0IGhlcmUgdGhhdCB0aGUgdmFsdWUgaXMNCiAgICBjYXJyaWVkIGluc3RlYWQg b2YgYW4gaW5kZXggd291bGQgYmUgaGVscGZ1bC4NCiAgICANCiAgICANCiAgICA0NDggICAgICAg ICBMLUZsYWc6IExvY2FsIEZsYWcuICBJZiBzZXQsIHRoZW4gdGhlIHZhbHVlL2luZGV4IGNhcnJp ZWQgYnkNCiAgICA0NDkgICAgICAgICB0aGUgQWRqLVNJRCBoYXMgbG9jYWwgc2lnbmlmaWNhbmNl LiAgQnkgZGVmYXVsdCB0aGUgZmxhZyBpcw0KICAgIDQ1MCAgICAgICAgIFNFVC4NCiAgICANCiAg ICBbbWFqb3JdIExvb2tpbmcgYmFjayBhdCDCpzIuMS4xLjEsIHdoYXQgYXJlIHRoZSBjb25kaXRp b25zIGZvciB3aGljaCB0aGUNCiAgICBjb21iaW5hdGlvbiBvZiB0aGUgViBhbmQgTC1GbGFncyBh cmUgdmFsaWQvaW52YWxpZD8gIERvIHRoZSBzYW1lIGNvbmRpdGlvbnMNCiAgICBhcHBseT8NCiAg ICANCiAgICANCiAgICAuLi4NCiAgICA0NjAgICAgICAgICBPdGhlciBiaXRzOiBNVVNUIGJlIHpl cm8gd2hlbiBvcmlnaW5hdGVkIGFuZCBpZ25vcmVkIHdoZW4NCiAgICA0NjEgICAgICAgICByZWNl aXZlZC4NCiAgICANCiAgICBbbWFqb3JdIERvIHlvdSBleHBlY3QgSUFOQSB0byBoYW5kbGUgdGhl IGFzc2lnbm1lbnQgb2YgdGhvc2Ugb3RoZXIgYml0cz8NCiAgICANCiAgICANCiAgICAuLi4NCiAg ICA0NjkgICAgICBBbiBTUiBjYXBhYmxlIHJvdXRlciBNQVkgYWxsb2NhdGUgYW4gQWRqLVNJRCBm b3IgZWFjaCBvZiBpdHMNCiAgICA0NzAgICAgICBhZGphY2VuY2llcyBhbmQgU0hPVUxEIHNldCB0 aGUgQi1GbGFnIHdoZW4gdGhlIGFkamFjZW5jeSBpcw0KICAgIDQ3MSAgICAgIGVsaWdpYmxlIGZv ciBwcm90ZWN0aW9uIChJUCBvciBNUExTKS4NCiAgICANCiAgICBbbWFqb3JdIElmIGVsaWdpYmxl IGZvciBwcm90ZWN0aW9uLCB3aGVuIHdvdWxkIHRoZSByb3V0ZXIgbm90IHNldCB0aGUNCiAgICBC LUZsYWc/ICBJT1csIHdoeSBpcyB0aGF0IG5vdCBhIE1VU1Q/DQogICAgDQogICAgQmV5b25kIHRo YXQsIEkgdGhpbmsgdGhhdCB0aGUgdXNlIG9mIFNIT1VMRCBpcyBpbiBjb25mbGljdCB3aXRoIHRo ZQ0KICAgIGRlZmluaXRpb24gb2YgdGhlIEItRmxhZyAoYWJvdmUpOiAiSWYgc2V0LCB0aGUgQWRq LVNJRCBpcyBlbGlnaWJsZSBmb3INCiAgICBwcm90ZWN0aW9uLi4uIiwgd2hpY2ggaW1wbGllcyB0 aGF0IGl0IGlzbid0IGVsaWdpYmxlIGlmIGl0J3Mgbm90IHNldC4uLmJ1dA0KICAgIHRoZSBTSE9V TEQgb3BlbnMgdGhlIGRvb3IgZm9yIG5vdCBzZXR0aW5nIHRoZSBGbGFnLi4uDQogICAgDQogICAg DQogICAgLi4uDQogICAgNDc5ICAgICAgV2hlbiB0aGUgUC1mbGFnIGlzIG5vdCBzZXQsIHRoZSBB ZGotU0lEIE1BWSBiZSBwZXJzaXN0ZW50LiAgV2hlbg0KICAgIDQ4MCAgICAgIHRoZSBQLWZsYWcg aXMgc2V0LCB0aGUgQWRqLVNJRCBNVVNUIGJlIHBlcnNpc3RlbnQuDQogICAgDQogICAgW21ham9y XSBJZiB0aGUgYWRqYWNlbmN5IGlzIHBlcnNpc3RlbnQsIHdoeS93aGVuIHdvdWxkIHRoZSBQLUZs YWcgbm90IGJlDQogICAgc2V0Pw0KICAgIA0KICAgIA0KICAgIC4uLg0KICAgIDQ4OCAyLjIuMi4g IEFkamFjZW5jeSBTZWdtZW50IElkZW50aWZpZXJzIGluIExBTnMNCiAgICAuLi4NCiAgICA1Mzcg ICAgICBPdGhlciBiaXRzOiBNVVNUIGJlIHplcm8gd2hlbiBvcmlnaW5hdGVkIGFuZCBpZ25vcmVk IHdoZW4NCiAgICA1MzggICAgICByZWNlaXZlZC4NCiAgICANCiAgICBbbWFqb3JdIERvIHlvdSBl eHBlY3QgSUFOQSB0byBoYW5kbGUgdGhlIGFzc2lnbm1lbnQgb2YgdGhvc2Ugb3RoZXIgYml0cz8N CiAgICANCiAgICANCiAgICAuLi4NCiAgICA1NDQgICAgICBTeXN0ZW0tSUQ6IDYgb2N0ZXRzIG9m IElTLUlTIFN5c3RlbS1JRCBvZiBsZW5ndGggIklEIExlbmd0aCIgYXMNCiAgICA1NDUgICAgICBk ZWZpbmVkIGluIFtJU08xMDU4OV0uDQogICAgDQogICAgW21ham9yXSBXaGljaCBTeXN0ZW0tSUQ/ DQogICAgDQogICAgW21ham9yXSAiNiBvY3RldHMgb2YuLi5sZW5ndGggIklEIExlbmd0aCIiICA/ Pw0KICAgIA0KICAgIA0KICAgIDU0NyAgICAgIFNJRC9JbmRleC9MYWJlbCBhcyBkZWZpbmVkIGlu IFNlY3Rpb24gMi4xLjEuMS4NCiAgICANCiAgICA1NDkgICBNdWx0aXBsZSBMQU4tQWRqLVNJRCBz dWItVExWcyBNQVkgYmUgZW5jb2RlZC4gIE5vdGUgdGhhdCB0aGlzIHN1Yi1UTFYNCiAgICA1NTAg ICBNVVNUIE5PVCBhcHBlYXIgaW4gVExWIDE0MS4NCiAgICANCiAgICA1NTIgICBXaGVuIHRoZSBQ LWZsYWcgaXMgbm90IHNldCwgdGhlIExBTi1BZGotU0lEIE1BWSBiZSBwZXJzaXN0ZW50LiAgV2hl bg0KICAgIDU1MyAgIHRoZSBQLWZsYWcgaXMgc2V0LCB0aGUgTEFOLUFkai1TSUQgTVVTVCBiZSBw ZXJzaXN0ZW50Lg0KICAgIA0KICAgIDU1NSAgIEluIGNhc2Ugb25lIFRMVi0yMi8yMy8yMjIvMjIz IChyZXBvcnRpbmcgdGhlIGFkamFjZW5jeSB0byB0aGUgRElTKQ0KICAgIDU1NiAgIGNhbid0IGNv bnRhaW4gdGhlIHdob2xlIHNldCBvZiBMQU4tQWRqLVNJRCBzdWItVExWcywgbXVsdGlwbGUNCiAg ICA1NTcgICBhZHZlcnRpc2VtZW50cyBvZiB0aGUgYWRqYWNlbmN5IHRvIHRoZSBESVMgTVVTVCBi ZSB1c2VkIGFuZCBhbGwNCiAgICA1NTggICBhZHZlcnRpc2VtZW50cyBNVVNUIGhhdmUgdGhlIHNh bWUgbWV0cmljLg0KICAgIA0KICAgIDU2MCAgIEVhY2ggcm91dGVyIHdpdGhpbiB0aGUgbGV2ZWws IGJ5IHJlY2VpdmluZyB0aGUgRElTIFBOIExTUCBhcyB3ZWxsIGFzDQogICAgNTYxICAgdGhlIG5v bi1QTiBMU1Agb2YgZWFjaCByb3V0ZXIgaW4gdGhlIExBTiwgaXMgY2FwYWJsZSBvZg0KICAgIDU2 MiAgIHJlY29uc3RydWN0aW5nIHRoZSBMQU4gdG9wb2xvZ3kgYXMgd2VsbCBhcyB0aGUgc2V0IG9m IEFkai1TSUQgZWFjaA0KICAgIDU2MyAgIHJvdXRlciB1c2VzIGZvciBlYWNoIG9mIGl0cyBuZWln aGJvcnMuDQogICAgDQogICAgNTY1ICAgQSBsYWJlbCBpcyBlbmNvZGVkIGluIDMgb2N0ZXRzIChp biB0aGUgMjAgcmlnaHRtb3N0IGJpdHMpLg0KICAgIA0KICAgIDU2NyAgIEFuIGluZGV4IGlzIGVu Y29kZWQgaW4gNCBvY3RldHMuDQogICAgDQogICAgW21pbm9yXSBTb21lIG9mIHRoZSBpbmZvcm1h dGlvbiBhYm92ZSAoZm9yIGV4YW1wbGUsIHRoZSBwYXJhZ3JhcGggYWJvdXQgdGhlDQogICAgUC1G bGFnIGFuZCB0aGVzZSBsYXN0IDIgc2VudGVuY2VzKSBzZWVtcyB1bm5lY2Vzc2FyeSBnaXZlbiB0 aGF0IHRoZQ0KICAgIGRlc2NyaXB0aW9uIG9mIHRoZXNlIGZpZWxkcyBpcyBhbHJlYWR5IGRvbmUg c29tZXdoZXJlIGVsc2UuDQogICAgDQogICAgDQogICAgNTY5IDIuMy4gIFNJRC9MYWJlbCBTdWIt VExWDQogICAgDQogICAgNTcxICAgVGhlIFNJRC9MYWJlbCBzdWItVExWIG1heSBiZSBwcmVzZW50 IGluIHRoZSBmb2xsb3dpbmcgVExWcy9zdWItVExWcw0KICAgIDU3MiAgIGRlZmluZWQgaW4gdGhp cyBkb2N1bWVudDoNCiAgICANCiAgICA1NzQgICBTUi1DYXBhYmlsaXRpZXMgU3ViLVRMViAoU2Vj dGlvbiAzLjEpDQogICAgDQogICAgNTc2ICAgU1IgTG9jYWwgQmxvY2sgU3ViLVRMViAoU2VjdGlv biAzLjMpDQogICAgDQogICAgNTc4ICAgU0lEL0xhYmVsIEJpbmRpbmcgVExWIChTZWN0aW9uIDIu NCkNCiAgICANCiAgICA1ODAgICBNdWx0aS1Ub3BvbG9neSBTSUQvTGFiZWwgQmluZGluZyBUTFYg KFNlY3Rpb24gMi41KQ0KICAgIA0KICAgIFtuaXRdIEl0IG1pZ2h0IGhhdmUgYmVlbiBuaWNlLCBp biBsaW5lIHdpdGggdGhlIE9TUEYgd29yaywgdG8gZmxpcCBTZWN0aW9ucw0KICAgIDIgYW5kIDMu ICBKdXN0IGEgbml0Li4uDQogICAgDQogICAgNTgyICAgTm90ZSB0aGF0IHRoZSBjb2RlIHBvaW50 IHVzZWQgaW4gYWxsIG9mIHRoZSBhYm92ZSBjYXNlcyBpcyB0aGUgU0lELw0KICAgIDU4MyAgIExh YmVsIFN1Yi1UTFYgY29kZSBwb2ludCBhc3NpZ25lZCBieSBJQU5BIGluIHRoZSAic3ViLVRMVnMg Zm9yIFRMVg0KICAgIDU4NCAgIDE0OSBhbmQgMTUwIiByZWdpc3RyeS4NCiAgICANCiAgICBbbWFq b3JdIEJlY2F1c2UgdGhpcyBkb2N1bWVudCBpcyBzZXR0aW5nIHVwIHRoYXQgbmV3IHJlZ2lzdHJ5 LCB3ZSBkb24ndA0KICAgIGhhdmUgdG8gd2FpdCBmb3IgSUFOQSB0byBhc3NpZ24gYW55dGhpbmc6 IHRoZSBkb2N1bWVudCBjYW4gc3BlY2lmeSBpdC4NCiAgICBJT1csIHRoZSBwYXJhZ3JhcGggYWJv dmUgaXMgbm90IG5lZWRlZC4NCiAgICANCiAgICANCiAgICA1ODYgICBUaGUgU0lEL0xhYmVsIHN1 Yi1UTFYgY29udGFpbnMgYSBTSUQgb3IgYSBNUExTIExhYmVsLiAgVGhlIFNJRC9MYWJlbA0KICAg IDU4NyAgIHN1Yi1UTFYgaGFzIHRoZSBmb2xsb3dpbmcgZm9ybWF0Og0KICAgIA0KICAgIDU4OSAg ICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAg ICAgICAzDQogICAgNTkwICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDgg OSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KICAgIDU5MSAgICstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKw0KICAgIDU5MiAgIHwgICBUeXBlICAgICAgICB8ICAgICBMZW5ndGggICAg fA0KICAgIDU5MyAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rDQogICAgNTk0ICAgfCAgICAgICAgICAgICAgICAgICAgICAg ICAgU0lEL0xhYmVsICh2YXJpYWJsZSkgICAgICAgICAgICAgICAgIHwNCiAgICA1OTUgICArLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKw0KICAgIA0KICAgIDU5NyAgIHdoZXJlOg0KICAgIA0KICAgIDU5OSAgICAgIFR5cGU6IFRC RCwgc3VnZ2VzdGVkIHZhbHVlIDENCiAgICANCiAgICA2MDEgICAgICBMZW5ndGg6IHZhcmlhYmxl DQogICAgDQogICAgW21ham9yXSBZZXMsIHZhcmlhYmxlLi4uYnV0IHJpZ2h0IG5vdyBvbmx5IG9u ZSB2YWx1ZSBpcyBkZWZpbmVkLiAgVGhlcmUncyBhDQogICAgZmluaXRlIG51bWJlciBvZiBwb3Nz aWJpbGl0aWVzLi4uDQogICAgDQogICAgDQogICAgNjAyICAgICAgU0lEL0xhYmVsOiBpZiBsZW5n dGggaXMgc2V0IHRvIDMgdGhlbiB0aGUgMjAgcmlnaHRtb3N0IGJpdHMNCiAgICA2MDMgICAgICBy ZXByZXNlbnQgYSBNUExTIGxhYmVsLg0KICAgIA0KICAgIFttYWpvcl0gSXMgdGhhdCBpdC4uPyAg V2hhdCBhYm91dCB0aGUgU0lEPw0KICAgIA0KICAgIA0KICAgIDYwNSAyLjQuICBTSUQvTGFiZWwg QmluZGluZyBUTFYNCiAgICAuLi4NCiAgICA2MTkgICBUaGUgU0lEL0xhYmVsIEJpbmRpbmcgVExW IGhhcyBUeXBlIFRCRCAoc3VnZ2VzdGVkIHZhbHVlIDE0OSksIGFuZCBoYXMNCiAgICA2MjAgICB0 aGUgZm9sbG93aW5nIGZvcm1hdDoNCiAgICANCiAgICBbbml0XSBObyBuZWVkIHRvIHRhbGsgYWJv dXQgdGhlIFR5cGUgdHdpY2UuDQogICAgDQogICAgNjIyICAgICAgMCAgICAgICAgICAgICAgICAg ICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMw0KICAgIDYyMyAgICAg IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcg OCA5IDAgMQ0KICAgIDYyNCAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICA2MjUgICAgIHwgICAgICBUeXBlICAg ICB8ICAgICBMZW5ndGggICAgfCAgICAgRmxhZ3MgICAgIHwgICAgIFJFU0VSVkVEICB8DQogICAg NjI2ICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKw0KICAgIDYyNyAgICAgfCAgICAgICAgICAgIFJhbmdlICAgICAgICAg ICAgICB8IFByZWZpeCBMZW5ndGggfCAgICAgUHJlZml4ICAgIHwNCiAgICA2MjggICAgICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rDQogICAgNjI5ICAgICAvLyAgICAgICAgICAgICAgIFByZWZpeCAoY29udGludWVkLCB2YXJp YWJsZSkgICAgICAgICAgICAgICAgICAvLw0KICAgIDYzMCAgICAgKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICA2MzEg ICAgIHwgICAgICAgICAgICAgICAgICAgIFN1YlRMVnMgKHZhcmlhYmxlKSAgICAgICAgICAgICAg ICAgICAgICAgICB8DQogICAgNjMyICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgIA0KICAgIDYzNCAgICAgICAg ICAgICAgICAgIEZpZ3VyZSAxOiBTSUQvTGFiZWwgQmluZGluZyBUTFYgZm9ybWF0DQogICAgDQog ICAgNjM2ICAgbyAgVHlwZTogVEJELCBzdWdnZXN0ZWQgdmFsdWUgMTQ5DQogICAgDQogICAgDQog ICAgLi4uDQogICAgNjU3IDIuNC4xLiAgRmxhZ3MNCiAgICAuLi4NCiAgICA2NzEgICAgICBNLUZs YWc6IE1pcnJvciBDb250ZXh0IGZsYWcuICBTZXQgaWYgdGhlIGFkdmVydGlzZWQgU0lEDQogICAg NjcyICAgICAgY29ycmVzcG9uZHMgdG8gYSBtaXJyb3JlZCBjb250ZXh0LiAgVGhlIHVzZSBvZiB0 aGUgTSBmbGFnIGlzDQogICAgNjczICAgICAgZGVzY3JpYmVkIGluIFtSRkM4NDAyXS4NCiAgICAN CiAgICBbbWFqb3JdIFdoZXJlPyAgTm90ZSB0aGF0IHJmYzg0MDIgc2F5cyB0aGF0ICJUaGUgTWly cm9yIFNJRCBpcyBhZHZlcnRpc2VkDQogICAgdXNpbmcgdGhlIEJpbmRpbmcgc2VnbWVudCBkZWZp bmVkIGluIFNSIElHUCBwcm90b2NvbCBleHRlbnNpb25zDQogICAgW0lTSVMtU1ItRVhUXS4iLCBw b2ludGluZyBiYWNrIGF0IHRoaXMgZG9jdW1lbnQuDQogICAgDQogICAgW21pbm9yXSBTb21lIHBs YWNlcyB1c2UgKi1GbGFnIGFuZCBvdGhlcnMgIiogZmxhZyIsIHBsZWFzZSBiZSBjb25zaXN0ZW50 Lg0KICAgIA0KICAgIA0KICAgIDY3NSAgICAgIFMtRmxhZzogSWYgc2V0LCB0aGUgU0lEL0xhYmVs IEJpbmRpbmcgVExWIFNIT1VMRCBiZSBmbG9vZGVkIGFjcm9zcw0KICAgIDY3NiAgICAgIHRoZSBl bnRpcmUgcm91dGluZyBkb21haW4uICBJZiB0aGUgUyBmbGFnIGlzIG5vdCBzZXQsIHRoZSBTSUQv DQogICAgNjc3ICAgICAgTGFiZWwgQmluZGluZyBUTFYgTVVTVCBOT1QgYmUgbGVha2VkIGJldHdl ZW4gbGV2ZWxzLiAgVGhpcyBiaXQNCiAgICA2NzggICAgICBNVVNUIE5PVCBiZSBhbHRlcmVkIGR1 cmluZyB0aGUgVExWIGxlYWtpbmcuDQogICAgDQogICAgW21ham9yXSBJZiB0aGUgUy1GbGFnIGlz IHNldCwgd2hlbiB3b3VsZCB0aGUgVExWIG5vdCBiZSBmbG9vZGVkIGFjcm9zcyB0aGUNCiAgICBl bnRpcmUgZG9tYWluPyAgSU9XLCB3aHkgaXMgdGhlIFNIT1VMRCBub3QgYSBNVVNUPw0KICAgIA0K ICAgIA0KICAgIDY4MCAgICAgIEQtRmxhZzogd2hlbiB0aGUgU0lEL0xhYmVsIEJpbmRpbmcgVExW IGlzIGxlYWtlZCBmcm9tIGxldmVsLTIgdG8NCiAgICA2ODEgICAgICBsZXZlbC0xLCB0aGUgRCBi aXQgTVVTVCBiZSBzZXQuICBPdGhlcndpc2UsIHRoaXMgYml0IE1VU1QgYmUNCiAgICA2ODIgICAg ICBjbGVhci4gIFNJRC9MYWJlbCBCaW5kaW5nIFRMVnMgd2l0aCB0aGUgRCBiaXQgc2V0IE1VU1Qg Tk9UIGJlDQogICAgNjgzICAgICAgbGVha2VkIGZyb20gbGV2ZWwtMSB0byBsZXZlbC0yLiAgVGhp cyBpcyB0byBwcmV2ZW50IFRMViBsb29waW5nDQogICAgNjg0ICAgICAgYWNyb3NzIGxldmVscy4N CiAgICANCiAgICBbbWlub3JdIFdoYXQgYWJvdXQgbGVha2luZyBmcm9tIEwyIHRvIEwxIHdpdGgg dGhlIEZsYWcgc2V0Pw0KICAgIA0KICAgIFttaW5vcl0gVGhlIHRleHQgdXNlcyBGbGFnLCBidXQg aW4gc29tZSBjYXNlcyBiaXQgaXMgdXNlZCBhcyB3ZWxsLiAgUGxlYXNlDQogICAgYmUgY29uc2lz dGVudC4NCiAgICANCiAgICANCiAgICAuLi4NCiAgICA2OTUgICAgICBBbiBpbXBsZW1lbnRhdGlv biBNQVkgZGVjaWRlIG5vdCB0byBob25vciB0aGUgUy1mbGFnIGluIG9yZGVyIG5vdA0KICAgIDY5 NiAgICAgIHRvIGxlYWsgQmluZGluZyBUTFYncyBiZXR3ZWVuIGxldmVscyAoZm9yIHBvbGljeSBy ZWFzb25zKS4gIEluIGFsbA0KICAgIDY5NyAgICAgIGNhc2VzLCB0aGUgRCBmbGFnIE1VU1QgYWx3 YXlzIGJlIHNldCBieSBhbnkgcm91dGVyIGxlYWtpbmcgdGhlDQogICAgNjk4ICAgICAgQmluZGlu ZyBUTFYgZnJvbSBsZXZlbC0yIGludG8gbGV2ZWwtMSBhbmQgTVVTVCBiZSBjaGVja2VkIHdoZW4N CiAgICA2OTkgICAgICBwcm9wYWdhdGluZyB0aGUgQmluZGluZyBUTFYgZnJvbSBsZXZlbC0xIGlu dG8gbGV2ZWwtMi4gIElmIHRoZSBEDQogICAgNzAwICAgICAgZmxhZyBpcyBzZXQsIHRoZSBCaW5k aW5nIFRMViBNVVNUIE5PVCBiZSBwcm9wYWdhdGVkIGludG8gbGV2ZWwtMi4NCiAgICANCiAgICBb bWFqb3JdIHMvaW1wbGVtZW50YXRpb24gTUFZIGRlY2lkZS9pbXBsZW1lbnRhdGlvbiBtYXkgZGVj aWRlICAgVGhlcmUncyBubw0KICAgIE5vcm1hdGl2ZSBhY3Rpb24gdGhlcmUuDQogICAgDQogICAg W21ham9yXSBSZWdhcmRsZXNzIG9mIHdoZXRoZXIgTUFZL21heSBpcyB1c2VkLCB0aGUgc3RhdGVt ZW50IGluIHRoZSBmaXJzdA0KICAgIHNlbnRlbmNlIGNvbnRyYWRpY3RzIHRoZSAiTVVTVCBOT1Qg YmUgbGVha2VkIiBOb3JtYXRpdmUgc3RhdGVtZW50LiAgR2l2ZW4NCiAgICB0aGF0IHRoZXJlIGFy ZSBleGNlcHRpb25zLCBtYXliZSAiU0hPVUxEIE5PVCIgd291bGQgYmUgbW9yZSBhcHByb3ByaWF0 ZS4NCiAgICANCiAgICBbbWFqb3JdIFRoaXMgbGFzdCBwYXJhZ3JhcGggc2VlbXMgdG8gY29udGFp biB0aGUgc2FtZSBpbmZvcm1hdGlvbiBhcyB0aGUNCiAgICB0ZXh0IGRlc2NyaWJpbmcgdGhlIFMt RmxhZy4gIFBsZWFzZSBkb24ndCBkdXBsaWNhdGUgc3BlY2lmaWNhdGlvbnMuDQogICAgDQogICAg NzAyICAgICAgT3RoZXIgYml0czogTVVTVCBiZSB6ZXJvIHdoZW4gb3JpZ2luYXRlZCBhbmQgaWdu b3JlZCB3aGVuDQogICAgNzAzICAgICAgcmVjZWl2ZWQuDQogICAgDQogICAgW21ham9yXSBEbyB5 b3UgZXhwZWN0IElBTkEgdG8gaGFuZGxlIHRoZSBhc3NpZ25tZW50IG9mIHRob3NlIG90aGVyIGJp dHM/DQogICAgDQogICAgNzA1IDIuNC4yLiAgUmFuZ2UNCiAgICANCiAgICA3MDcgICBUaGUgJ1Jh bmdlJyBmaWVsZCBwcm92aWRlcyB0aGUgYWJpbGl0eSB0byBzcGVjaWZ5IGEgcmFuZ2Ugb2YNCiAg ICA3MDggICBhZGRyZXNzZXMgYW5kIHRoZWlyIGFzc29jaWF0ZWQgUHJlZml4IFNJRHMuICBUaGlz IGFkdmVydGlzZW1lbnQNCiAgICA3MDkgICBzdXBwb3J0cyB0aGUgU1JNUyBmdW5jdGlvbmFsaXR5 LiAgSXQgaXMgZXNzZW50aWFsbHkgYSBjb21wcmVzc2lvbg0KICAgIDcxMCAgIHNjaGVtZSB0byBk aXN0cmlidXRlIGEgY29udGludW91cyBQcmVmaXggYW5kIHRoZWlyIGNvbnRpbnVvdXMsDQogICAg NzExICAgY29ycmVzcG9uZGluZyBTSUQvTGFiZWwgQmxvY2suICBJZiBhIHNpbmdsZSBTSUQgaXMg YWR2ZXJ0aXNlZCB0aGVuDQogICAgNzEyICAgdGhlIHJhbmdlIGZpZWxkIE1VU1QgYmUgc2V0IHRv IG9uZS4gIEZvciByYW5nZSBhZHZlcnRpc2VtZW50cyA+IDEsDQogICAgNzEzICAgdGhlIG51bWJl ciBvZiBhZGRyZXNzZXMgdGhhdCBuZWVkIHRvIGJlIG1hcHBlZCBpbnRvIGEgUHJlZml4LVNJRCBh bmQNCiAgICA3MTQgICB0aGUgc3RhcnRpbmcgdmFsdWUgb2YgdGhlIFByZWZpeC1TSUQgcmFuZ2Uu DQogICAgDQogICAgW25pdF0gVGhlIGxhc3Qgc2VudGVuY2Ugc291bmRzIGluY29tcGxldGUuLi4N CiAgICANCiAgICA3MTYgICBFeGFtcGxlIDE6IGlmIHRoZSBmb2xsb3dpbmcgcm91dGVyIGFkZHJl c3NlcyAobG9vcGJhY2sgYWRkcmVzc2VzKQ0KICAgIDcxNyAgIG5lZWQgdG8gYmUgbWFwcGVkIGlu dG8gdGhlIGNvcnJlc3BvbmRpbmcgUHJlZml4IFNJRCBpbmRleGVzLg0KICAgIA0KICAgIFttaW5v cl0gU3VnZ2VzdGlvbjogbW92ZSB0aGUgZXhhbXBsZXMgdG8gdGhlIGVuZCBvZiDCpzIuNC4uLmFm dGVyIGFsbCB0aGUNCiAgICBmaWVsZHMgaGF2ZSBiZWVuIGRpc2N1c3NlZC4NCiAgICANCiAgICA3 MTkgICBSb3V0ZXItQTogMTkyLjAuMi4xLzMyLCBQcmVmaXgtU0lEOiBJbmRleCAxDQogICAgNzIw ICAgUm91dGVyLUI6IDE5Mi4wLjIuMi8zMiwgUHJlZml4LVNJRDogSW5kZXggMg0KICAgIDcyMSAg IFJvdXRlci1DOiAxOTIuMC4yLjMvMzIsIFByZWZpeC1TSUQ6IEluZGV4IDMNCiAgICA3MjIgICBS b3V0ZXItRDogMTkyLjAuMi40LzMyLCBQcmVmaXgtU0lEOiBJbmRleCA0DQogICAgDQogICAgNzI0 ICAgICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAg ICAgICAgICAgMw0KICAgIDcyNSAgICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUg NiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KICAgIDcyNiAgICAgKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAg ICA3MjcgICAgIHwgICAgICBUeXBlICAgICB8ICAgICBMZW5ndGggICAgfDB8MHwgICAgICAgICAg IHwgICAgIFJFU0VSVkVEICB8DQogICAgNzI4ICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgIDcyOSAgICAgfCAg ICAgICAgICAgIFJhbmdlID0gNCAgICAgICAgICB8ICAgICAgIC8zMiAgICAgfCAgICAgIDE5MiAg ICAgIHwNCiAgICA3MzAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgNzMxICAgICB8ICAgICAgIC4wICAgICAg fCAgICAgICAgLjIgICAgIHwgICAgICAgLjEgICAgICB8UHJlZml4LVNJRCBUeXBlfA0KICAgIDcz MiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSsNCiAgICA3MzMgICAgIHwgc3ViLVRMViBMZW5ndGh8ICAgICBGbGFncyAg ICAgfCAgIEFsZ29yaXRobSAgIHwgICAgICAgICAgICAgICB8DQogICAgNzM0ICAgICArLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Kw0KICAgIDczNSAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIDEgfA0KICAgIDczNiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKw0KICAgIA0KICAgIFtuaXRdIFRoZSBQcmVmaXggTGVuZ3RoIHNob3VsZCBi ZSAiMzIiLCBub3QgIi8zMiIuDQogICAgDQogICAgW25pdF0gVGhlIFByZWZpeCBpdHNlbGYgaXMg b25lIGZpZWxkIChpbiB0aGUgZGVzY3JpcHRpb24pLCBidXQgaXQgbG9va3MNCiAgICBsaWtlIDQg c2VwYXJhdGUgZmllbGRzIGFib3ZlLi4uYW5kIHRoZSBudW1iZXJzIHNob3VsZCBub3QgaGF2ZSAi LiIgaW4gdGhlbS4NCiAgICANCiAgICBbbWlub3JdIEl0IGxvb2tzIGxpa2UgdGhlIGZpZWxkcyBz dGFydGluZyB3aXRoICJQcmVmaXgtU0lEIFR5cGUiIGJlbG9uZyB0bw0KICAgIHRoZSBQcmVmaXgt U0lEIFN1Yi1UTFYsIGJ1dCB0aGF0IGlzIG5vdCBleHBsYWluZWQgYW55d2hlcmUgKHlldCkuICBU aGUNCiAgICBBbGdvcml0aG0gZmllbGQgaXMgbm90IHNldC4uLm5vciBhcmUgdGhlIEZsYWdzLg0K ICAgIA0KICAgIDczOCAgIEV4YW1wbGUtMjogSWYgdGhlIGZvbGxvd2luZyBwcmVmaXhlcyBuZWVk IHRvIGJlIG1hcHBlZCBpbnRvIHRoZQ0KICAgIDczOSAgIGNvcnJlc3BvbmRpbmcgUHJlZml4LVNJ RCBpbmRleGVzOg0KICAgIA0KICAgIDc0MSAgIDEwLjEuMS8yNCwgUHJlZml4LVNJRDogSW5kZXgg NTENCiAgICA3NDIgICAxMC4xLjIvMjQsIFByZWZpeC1TSUQ6IEluZGV4IDUyDQogICAgNzQzICAg MTAuMS4zLzI0LCBQcmVmaXgtU0lEOiBJbmRleCA1Mw0KICAgIDc0NCAgIDEwLjEuNC8yNCwgUHJl Zml4LVNJRDogSW5kZXggNTQNCiAgICA3NDUgICAxMC4xLjUvMjQsIFByZWZpeC1TSUQ6IEluZGV4 IDU1DQogICAgNzQ2ICAgMTAuMS42LzI0LCBQcmVmaXgtU0lEOiBJbmRleCA1Ng0KICAgIDc0NyAg IDEwLjEuNy8yNCwgUHJlZml4LVNJRDogSW5kZXggNTcNCiAgICANCiAgICBbbWFqb3JdIFBsZWFz ZSB1c2UgYWRkcmVzc2VzIGluIHRoZSByZmM1NzM3IHJlc2VydmVkIHJhbmdlcy4NCiAgICANCiAg ICBbbWlub3JdIEl0IHdvdWxkIGhhdmUgYmVlbiBuaWNlIHRvIHNlZSBhbiBJUHY2IGV4YW1wbGUg KHNlZSByZmMzODQ5KS4NCiAgICANCiAgICA3NDkgICAgICAwICAgICAgICAgICAgICAgICAgIDEg ICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzDQogICAgNzUwICAgICAgMCAx IDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkg MCAxDQogICAgNzUxICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgIDc1MiAgICAgfCAgICAgIFR5cGUgICAgIHwg ICAgIExlbmd0aCAgICB8MHwwfCAgICAgICAgICAgfCAgICAgUkVTRVJWRUQgIHwNCiAgICA3NTMg ICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rDQogICAgNzU0ICAgICB8ICAgICAgICAgICAgUmFuZ2UgPSA3ICAgICAgICAg IHwgICAgICAgLzI0ICAgICB8ICAgICAgMTAgICAgICAgfA0KICAgIDc1NSAgICAgKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsN CiAgICA3NTYgICAgIHwgICAgICAgLjEgICAgICB8ICAgICAgICAuMSAgICAgfFByZWZpeC1TSUQg VHlwZXwgc3ViLVRMViBMZW5ndGh8DQogICAgNzU3ICAgICArLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KICAgIDc1OCAgICAg fCAgICBGbGFncyAgICAgIHwgQWxnb3JpdGhtICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwNCiAgICA3NTkgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQogICAgNzYwICAgICB8ICAgICAgICAgICAg ICAgICAgICAgICAgICAgNTEgIHwNCiAgICA3NjEgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKw0KICAgIA0KICAgIFtdIFNhbWUgY29tbWVudHMgYXMgYWJvdmUuDQogICAgDQog ICAgDQogICAgLi4uDQogICAgNzc4IDIuNC4zLiAgUHJlZml4IExlbmd0aCwgUHJlZml4DQogICAg Li4uDQogICAgNzg0ICAgVGhlICdQcmVmaXggTGVuZ3RoJyBmaWVsZCBjb250YWlucyB0aGUgbGVu Z3RoIG9mIHRoZSBwcmVmaXggaW4gYml0cy4NCiAgICA3ODUgICBPbmx5IHRoZSBtb3N0IHNpZ25p ZmljYW50IG9jdGV0cyBvZiB0aGUgUHJlZml4IGFyZSBlbmNvZGVkLiAgKGkuZS4sIDENCiAgICA3 ODYgICBvY3RldCBmb3IgcHJlZml4IGxlbmd0aCAxIHVwIHRvIDgsIDIgb2N0ZXRzIGZvciBwcmVm aXggbGVuZ3RoIDkgdG8NCiAgICA3ODcgICAxNiwgMyBvY3RldHMgZm9yIHByZWZpeCBsZW5ndGgg MTcgdXAgdG8gMjQgYW5kIDQgb2N0ZXRzIGZvciBwcmVmaXgNCiAgICA3ODggICBsZW5ndGggMjUg dXAgdG8gMzIsIC4uLi4sIDE2IG9jdGV0cyBmb3IgcHJlZml4IGxlbmd0aCAxMTMgdXAgdG8gMTI4 KS4NCiAgICANCiAgICBbbml0XSBzL2VuY29kZWQuICAoaS5lLiwvZW5jb2RlZCAoaS5lLiwNCiAg ICANCiAgICANCiAgICA3OTAgMi40LjQuICBNYXBwaW5nIFNlcnZlciBQcmVmaXgtU0lEDQogICAg DQogICAgNzkyICAgVGhlIFByZWZpeC1TSUQgc3ViLVRMViAoc3VnZ2VzdGVkIHZhbHVlIDMpIGlz IGRlZmluZWQgaW4gU2VjdGlvbiAyLjENCiAgICA3OTMgICBhbmQgY29udGFpbnMgdGhlIFNJRC9p bmRleC9sYWJlbCB2YWx1ZSBhc3NvY2lhdGVkIHdpdGggdGhlIHByZWZpeCBhbmQNCiAgICA3OTQg ICByYW5nZS4gIFRoZSBQcmVmaXgtU0lEIFN1YlRMViBNVVNUIGJlIHByZXNlbnQgaW4gdGhlIFNJ RC9MYWJlbA0KICAgIDc5NSAgIEJpbmRpbmcgVExWIHVubGVzcyB0aGUgTS1mbGFnIGlzIHNldCBp biB0aGUgRmxhZ3MgZmllbGQgb2YgdGhlIHBhcmVudA0KICAgIDc5NiAgIFRMVi4NCiAgICANCiAg ICBbbWFqb3JdIERvZXMgaXQgdGhlbiBtZWFuIHRoYXQgdGhlIFByZWZpeC1TSUQgU3ViVExWIG11 c3Qgbm90IGJlIHByZXNlbnQgaWYNCiAgICB0aGUgTS1GbGFnIGlzIG5vdCBzZXQ/DQogICAgDQog ICAgW25pdF0gcy9TdWJUTFYvU3ViLVRMViAoYXMgaXQgaXMgdXNlZCBhbG1vc3QgZXZlcnl3aGVy ZSBlbHNlKQ0KICAgIA0KICAgIA0KICAgIDc5OCAgIEEgbm9kZSByZWNlaXZpbmcgYW4gU1JNUyBl bnRyeSBmb3IgYSBwcmVmaXggTVVTVCBjaGVjayB0aGUgZXhpc3RlbmNlDQogICAgNzk5ICAgb2Yg c3VjaCBwcmVmaXggaW4gaXRzIGxpbmstc3RhdGUgZGF0YWJhc2UgcHJpb3IgdG8gY29uc2lkZXIg YW5kIHVzZQ0KICAgIDgwMCAgIHRoZSBhc3NvY2lhdGVkIFNJRC4NCiAgICANCiAgICBbbWFqb3Jd IFdoYXQgZG9lcyBpdCBtZWFuIGZvciB0aGUgcHJlZml4IHRvIGV4aXN0IGluIHRoZSBsaW5rLXN0 YXRlDQogICAgZGF0YWJhc2U/ICBEb2VzIGl0IG1lYW4gdGhhdCBpdCBtdXN0IGhhdmUgYmVlbiBh ZHZlcnRpc2VkIGluIGEgIm5vcm1hbCINCiAgICByb3V0aW5nIFRMViwgb3Igc29tZXRoaW5nIGVs c2U/ICBJIGFzayBub3Qgb25seSB0byBjbGFyaWZ5LCBidXQgYmVjYXVzZQ0KICAgIMKnMi40LjMg c2F5cyB0aGF0IHRoZSAiJ1ByZWZpeCcgZG9lcyBub3QgbmVlZCB0byBjb3JyZXNwb25kIHRvIGEg cm91dGFibGUNCiAgICBwcmVmaXggb2YgdGhlIG9yaWdpbmF0aW5nIG5vZGUiLg0KICAgIA0KICAg IFtBaC4uLkkgdGhpbmsgSSB1bmRlcnN0YW5kLiAgQmVjYXVzZSAidGhlIG1hcHBpbmcgc2VydmVy IGRvZXMgbm90IHNwZWNpZnkNCiAgICB0aGUgb3JpZ2luYXRvciBvZiBhIHByZWZpeCIgKMKnMi40 LjQuMiksIHRoZW4gdGhlIHByZWZpeCBpcyBvYnZpb3VzbHkgbm90DQogICAgcm91dGFibGUgaW4g dGhlIGNvbnRleHQgb2YgdGhlIG9yaWdpbmF0aW5nIG5vZGUgKHRoZSBzZXJ2ZXIpLi4uYnV0IGl0 DQogICAgc2hvdWxkIGJlIHJvdXRhYmxlIGluIGdlbmVyYWwuICBJcyB0aGF0IGl0P10NCiAgICAN CiAgICANCiAgICA4MDIgMi40LjQuMS4gIFByZWZpeC1TSUQgRmxhZ3MNCiAgICANCiAgICA4MDQg ICBUaGUgUHJlZml4LVNJRCBmbGFncyBhcmUgZGVmaW5lZCBpbiBTZWN0aW9uIDIuMS4gIFRoZSBN YXBwaW5nIFNlcnZlcg0KICAgIDgwNSAgIE1BWSBhZHZlcnRpc2UgYSBtYXBwaW5nIHdpdGggdGhl IE4gZmxhZyBzZXQgd2hlbiB0aGUgcHJlZml4IGJlaW5nDQogICAgODA2ICAgbWFwcGVkIGlzIGtu b3duIGluIHRoZSBsaW5rLXN0YXRlIHRvcG9sb2d5IHdpdGggYSBtYXNrIGxlbmd0aCBvZiAzMg0K ICAgIDgwNyAgIChJUHY0KSBvciAxMjggKElQdjYpIGFuZCB3aGVuIHRoZSBwcmVmaXggcmVwcmVz ZW50cyBhIG5vZGUuICBUaGUNCiAgICA4MDggICBtZWNoYW5pc21zIHRocm91Z2ggd2hpY2ggdGhl IG9wZXJhdG9yIGRlZmluZXMgdGhhdCBhIHByZWZpeA0KICAgIDgwOSAgIHJlcHJlc2VudHMgYSBu b2RlIGFyZSBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50ICh0eXBpY2FsbHkNCiAg ICA4MTAgICBpdCB3aWxsIGJlIHRocm91Z2ggY29uZmlndXJhdGlvbikuDQogICAgDQogICAgW21h am9yXSDCpzIuMS4xLjIgc2F5cyB0aGF0IHRoZSAicm91dGVyIE1BWSBzZXQgdGhlIE4tRmxhZyBv bmx5IGlmLi4uIHRoZQ0KICAgIHByZWZpeCB0byB3aGljaCB0aGUgUHJlZml4LVNJRCBpcyBhdHRh Y2hlZCBNVVNUIGhhdmUgYSBQcmVmaXggbGVuZ3RoIG9mDQogICAgZWl0aGVyIC8zMiAoSVB2NCkg b3IgLzEyOCAoSVB2NikuIiAgVGhhdCBpcyBzaW1pbGFyIHRvIHdoYXQgdGhlIHRleHQgYWJvdmUN CiAgICBzYXlzIChidXQgdGhlIHRleHQgdGFsa3MgYWJvdXQgInRoZSBwcmVmaXguLi5rbm93biBp biB0aGUgbGluay1zdGF0ZQ0KICAgIHRvcG9sb2d5IiksIGFuZCBpdCBpcyByZWxhdGVkIHRvIHRo ZSBsYXN0IHF1ZXN0aW9uIGluIHRoZSBwcmV2aW91cw0KICAgIHNlY3Rpb24uICBEb2VzIHRoZSBw cmVmaXggYmVpbmcgaW4gdGhlIGxpbmstc3RhdGUgZGF0YWJhc2UvdG9wb2xvZ3kgbWVhbg0KICAg IHRoYXQgdGhlIG1hdGNoIGlzIGV4YWN0ICh0byB0aGUgcHJlZml4IGFkdmVydGlzZWQpLCBvciBp cyBhIHN1cGVybmV0IG9rPw0KICAgIA0KICAgIA0KICAgIDgxMiAgIFRoZSBvdGhlciBmbGFncyBk ZWZpbmVkIGluIFNlY3Rpb24gMi4xIGFyZSBub3QgdXNlZCBieSB0aGUgTWFwcGluZw0KICAgIDgx MyAgIFNlcnZlciBhbmQgTVVTVCBiZSBpZ25vcmVkIGF0IHJlY2VwdGlvbi4NCiAgICANCiAgICBb bWFqb3JdIEhvdyBkb2VzIHRoZSByZWNlaXZlciBrbm93IHRoYXQgdGhlIHN1Yi1UTFYgd2FzIG9y aWdpbmF0ZWQgYnkgYQ0KICAgIE1hcHBpbmcgU2VydmVyPyAgSXMgaXQgdGhlIGNhc2UgdGhhdCBp dCB3b3VsZCBvcmlnaW5hdGUgYSBCaW5kaW5nIFRMVj8NCiAgICBJT1csIHdvdWxkIHRoZSBvdGhl ciBmbGFncyBhbHdheXMgYmUgaWdub3JlZCB3aGVuIHRoZSBzdWItVExWIGlzIGluY2x1ZGVkDQog ICAgaW4gdGhlIEJpbmRpbmcgVExWIChidXQgbm90IG90aGVyIFRMVnMpPyAgIERvZXMgdGhpcyBh cHBseSBhbHNvIHRvIHRoZQ0KICAgIE11bHRpLVRvcG9sb2d5IFNJRC9MYWJlbCBCaW5kaW5nIFRM ViAowqcyLjUpPw0KICAgIA0KICAgIA0KICAgIDgxNSAyLjQuNC4yLiAgUEhQIEJlaGF2aW9yIHdo ZW4gdXNpbmcgTWFwcGluZyBTZXJ2ZXIgQWR2ZXJ0aXNlbWVudHMNCiAgICAuLi4NCiAgICA4MjMg ICBvICBBIHByZWZpeCByZWFjaGFiaWxpdHkgYWR2ZXJ0aXNlbWVudCBmb3IgdGhlIHByZWZpeCBo YXMgYmVlbg0KICAgIDgyNCAgICAgIHJlY2VpdmVkIHdoaWNoIGluY2x1ZGVzIHRoZSBFeHRlbmRl ZCBSZWFjaGFiaWxpdHkgQXR0cmlidXRlIEZsYWdzDQogICAgODI1ICAgICAgc3ViLVRMViAoW1JG Qzc3OTRdKS4NCiAgICANCiAgICBbbml0XSBzLyhbUkZDNzc5NF0pL1tSRkM3Nzk0XQ0KICAgIA0K ICAgIDgyNyAgIG8gIFggYW5kIFIgZmxhZ3MgYXJlIGJvdGggc2V0IHRvIDAgaW4gdGhlIEV4dGVu ZGVkIFJlYWNoYWJpbGl0eQ0KICAgIDgyOCAgICAgIEF0dHJpYnV0ZSBGbGFncyBzdWItVExWLg0K ICAgIA0KICAgIDgzMCAgIEluIHRoZSBhYnNlbmNlIG9mIGFuIEV4dGVuZGVkIFJlYWNoYWJpbGl0 eSBBdHRyaWJ1dGUgRmxhZ3Mgc3ViLVRMVg0KICAgIDgzMSAgIChbUkZDNzc5NF0pIHRoZSBBIGZs YWcgaW4gdGhlIGJpbmRpbmcgVExWIGluZGljYXRlcyB0aGF0IHRoZQ0KICAgIDgzMiAgIG9yaWdp bmF0b3Igb2YgYSBwcmVmaXggcmVhY2hhYmlsaXR5IGFkdmVydGlzZW1lbnQgaXMgZGlyZWN0bHkN CiAgICA4MzMgICBjb25uZWN0ZWQgdG8gdGhlIHByZWZpeCBhbmQgdGh1cyBQSFAgTVVTVCBiZSBk b25lIGJ5IHRoZSBuZWlnaGJvcnMgb2YNCiAgICA4MzQgICB0aGUgcm91dGVyIG9yaWdpbmF0aW5n IHRoZSBwcmVmaXggcmVhY2hhYmlsaXR5IGFkdmVydGlzZW1lbnQuICBOb3RlDQogICAgODM1ICAg dGhhdCBBLWZsYWcgaXMgb25seSB2YWxpZCBpbiB0aGUgb3JpZ2luYWwgYXJlYSBpbiB3aGljaCB0 aGUgQmluZGluZw0KICAgIDgzNiAgIFRMViBpcyBhZHZlcnRpc2VkLg0KICAgIA0KICAgIFtuaXRd IHMvKFtSRkM3Nzk0XSkvW1JGQzc3OTRdDQogICAgDQogICAgW21ham9yXSDCpzIuNC4xIHNheXMg dGhhdCAiaWYgdGhlIEJpbmRpbmcgVExWIGlzIGxlYWtlZC4uLnRoZSBBLWZsYWcgTVVTVCBiZQ0K ICAgIGNsZWFyZWQiLCB3aGljaCBpcyBub3QgdGhlIHNhbWUgYXMgbm90IGNvbnNpZGVyaW5nIGl0 IHZhbGlkIChpZ25vcmluZywgYXMNCiAgICBkZXNjcmliZWQgYWJvdmUpLiAgSW4gYW55IGNhc2Us IHBsZWFzZSBiZSBzcGVjaWZpYyBhYm91dCB0aGUgZnVuY3Rpb25hbGl0eQ0KICAgIGluIHRoZSBk ZXNjcmlwdGlvbi4NCiAgICANCiAgICANCiAgICA4MzggMi40LjQuMy4gIFByZWZpeC1TSUQgQWxn b3JpdGhtDQogICAgDQogICAgODQwICAgVGhlIGFsZ29yaXRobSBmaWVsZCBjb250YWlucyB0aGUg aWRlbnRpZmllciBvZiB0aGUgYWxnb3JpdGhtIHRoZQ0KICAgIDg0MSAgIHJvdXRlciBNVVNUIHVz ZSBpbiBvcmRlciB0byBjb21wdXRlIHJlYWNoYWJpbGl0eSB0byB0aGUgcmFuZ2Ugb2YNCiAgICA4 NDIgICBwcmVmaXhlcy4gIFVzZSBvZiB0aGUgYWxnb3JpdGhtIGZpZWxkIGlzIGRlc2NyaWJlZCBp biBTZWN0aW9uIDIuMS4NCiAgICANCiAgICBbbWFqb3Igbml0XSBBdCBmaXJzdCBnbGFuY2UsIGl0 IGxvb2tzIGxpa2UgdGhpcyBzZWN0aW9uIGlzIG5vdCBuZWVkZWQNCiAgICBiZWNhdXNlIGl0IHJl cGVhdHMgd2hhdCDCpzIuMSBhbHJlYWR5IHNheXMgYWJvdXQgdGhlIGFsZ29yaXRobS4gIEJ1dCB0 aGlzDQogICAgcGFyYWdyYXBoIHJlZmVycyB0byAidGhlIGFsZ29yaXRobSB0aGUgcm91dGVyIE1V U1QgdXNlIGluIG9yZGVyIHRvIGNvbXB1dGUNCiAgICByZWFjaGFiaWxpdHkiLCBpbiBjb250cmFz dCB0byB0aGUgZGVmaW5pdGlvbiBvZiB0aGUgZmllbGQgaW4gwqcyLjE6ICJUaGUNCiAgICBhbGdv cml0aG0gZmllbGQuLi5jb250YWlucyB0aGUgaWRlbnRpZmllciBvZiB0aGUgYWxnb3JpdGhtIHRo ZSByb3V0ZXIgaGFzDQogICAgdXNlZCBpbiBvcmRlciB0byBjb21wdXRlIHRoZSByZWFjaGFiaWxp dHkuLi4iDQogICAgDQogICAgDQogICAgLi4uDQogICAgOTAxIDMuMS4gIFNSLUNhcGFiaWxpdGll cyBTdWItVExWDQogICAgLi4uDQogICAgOTA5ICAgVGhlIFJvdXRlciBDYXBhYmlsaXR5IFRMViBz cGVjaWZpZXMgZmxhZ3MgdGhhdCBjb250cm9sIGl0cw0KICAgIDkxMCAgIGFkdmVydGlzZW1lbnQu ICBUaGUgU1IgQ2FwYWJpbGl0aWVzIHN1Yi1UTFYgTVVTVCBiZSBwcm9wYWdhdGVkDQogICAgOTEx ICAgdGhyb3VnaG91dCB0aGUgbGV2ZWwgYW5kIE1VU1QgTk9UIGJlIGFkdmVydGlzZWQgYWNyb3Nz IGxldmVsDQogICAgOTEyICAgYm91bmRhcmllcy4gIFRoZXJlZm9yZSBSb3V0ZXIgQ2FwYWJpbGl0 eSBUTFYgZGlzdHJpYnV0aW9uIGZsYWdzIGFyZQ0KICAgIDkxMyAgIHNldCBhY2NvcmRpbmdseSwg aS5lLiwgdGhlIFMgZmxhZyBpbiB0aGUgUm91dGVyIENhcGFiaWxpdHkgVExWDQogICAgOTE0ICAg KFtSRkM3OTgxXSkgTVVTVCBiZSB1bnNldC4NCiAgICANCiAgICBbbml0XSBzLyhbUkZDNzk4MV0p L1tSRkM3OTgxXQ0KICAgIA0KICAgIA0KICAgIC4uLg0KICAgIDk0MyAgICAgICAgIEktRmxhZzog TVBMUyBJUHY0IGZsYWcuICBJZiBzZXQsIHRoZW4gdGhlIHJvdXRlciBpcyBjYXBhYmxlIG9mDQog ICAgOTQ0ICAgICAgICAgcHJvY2Vzc2luZyBTUiBNUExTIGVuY2Fwc3VsYXRlZCBJUHY0IHBhY2tl dHMgb24gYWxsIGludGVyZmFjZXMuDQogICAgDQogICAgOTQ2ICAgICAgICAgVi1GbGFnOiBNUExT IElQdjYgZmxhZy4gIElmIHNldCwgdGhlbiB0aGUgcm91dGVyIGlzIGNhcGFibGUgb2YNCiAgICA5 NDcgICAgICAgICBwcm9jZXNzaW5nIFNSIE1QTFMgZW5jYXBzdWxhdGVkIElQdjYgcGFja2V0cyBv biBhbGwgaW50ZXJmYWNlcy4NCiAgICANCiAgICBbbWlub3JdIEp1c3QgY3VyaW91czogSG93IGFy ZSB0aGVzZSBmbGFncyB1c2VkPyAgR2l2ZW4gdGhhdCB0aGUgZGF0YSBwbGFuZQ0KICAgIHdlJ3Jl IGRlYWxpbmcgd2l0aCBpcyBNUExTLi4uDQogICAgDQogICAgDQogICAgLi4uDQogICAgOTgxICAg VGhlIG9yaWdpbmF0aW5nIHJvdXRlciBNVVNUIGVuc3VyZSB0aGUgb3JkZXIgaXMgc2FtZSBhZnRl ciBhIGdyYWNlZnVsDQogICAgOTgyICAgcmVzdGFydCAodXNpbmcgY2hlY2twb2ludGluZywgbm9u LXZvbGF0aWxlIHN0b3JhZ2Ugb3IgYW55IG90aGVyDQogICAgOTgzICAgbWVjaGFuaXNtKSBpbiBv cmRlciB0byBndWFyYW50ZWUgdGhlIHNhbWUgb3JkZXIgYmVmb3JlIGFuZCBhZnRlciBHUi4NCiAg ICANCiAgICBbbml0XSBzL29yZGVyIGlzIHNhbWUvb3JkZXIgaXMgdGhlIHNhbWUNCiAgICANCiAg ICANCiAgICAuLi4NCiAgICAxMDE1IDMuMi4gIFNSLUFsZ29yaXRobSBTdWItVExWDQogICAgLi4u DQogICAgMTA0NiAgIFRoZSBTUi1BbGdvcml0aG0gc3ViLVRMViBpcyBvcHRpb25hbCwgaXQgTUFZ IG9ubHkgYXBwZWFyIGEgc2luZ2xlDQogICAgMTA0NyAgIHRpbWUgaW5zaWRlIHRoZSBSb3V0ZXIg Q2FwYWJpbGl0eSBUTFYuDQogICAgDQogICAgW21ham9yXSAiTUFZIG9ubHkgYXBwZWFyIGEgc2lu Z2xlIHRpbWUiIG1lYW5zIHRoYXQgaXQgY2FuIGFwcGVhciBtb3JlIHRoYW4NCiAgICBvbmNlLiAg SWYgaXQgZG9lcyBzaG93IHVwIG1vcmUgdGhhbiBvbmNlLCB3aGF0IHNob3VsZCB0aGUgdGhlIHJl Y2VpdmVyIGRvPw0KICAgIA0KICAgIA0KICAgIDEwNDkgICBXaGVuIHRoZSBvcmlnaW5hdGluZyBy b3V0ZXIgZG9lcyBub3QgYWR2ZXJ0aXNlIHRoZSBTUi1BbGdvcml0aG0gc3ViLQ0KICAgIDEwNTAg ICBUTFYsIHRoZW4gYWxsIHRoZSBQcmVmaXgtU0lEcyBhZHZlcnRpc2VkIGJ5IHRoZSByb3V0ZXIg TVVTVCBoYXZlDQogICAgMTA1MSAgIGFsZ29yaXRobSBmaWVsZCBzZXQgdG8gMC4gIEFueSByZWNl aXZpbmcgcm91dGVyIE1VU1QgYXNzdW1lIFNQRg0KICAgIDEwNTIgICBhbGdvcml0aG0gKGkuZS4s IFNob3J0ZXN0IFBhdGggRmlyc3QpLg0KICAgIA0KICAgIFttaW5vcl0gSXQgc2VlbXMgdG8gbWUg dGhhdCB0aGlzIHBhcnQgb2YgdGhlIHNwZWNpZmljYXRpb24gd291bGQgZml0IGJldHRlcg0KICAg IGluIMKnMi4xLg0KICAgIA0KICAgIFttYWpvcl0gQmVzaWRlcyBtYXliZSBiZWluZyByZWR1bmRh bnQsIHdoYXQgaXMgc3BlY2lmaWVkIGluIHRoZSBsYXN0DQogICAgc2VudGVuY2U/ICBJZiB0aGUg aW5kaWNhdGlvbiBvZiB0aGUgYWxnb3JpdGhtIGlzIGV4cGxpY2l0LCB0aGVuIEkgZG9uJ3QNCiAg ICB1bmRlcnN0YW5kIHdoYXQgIk1VU1QgYXNzdW1lIiBpcyB0cnlpbmcgdG8gbWFuZGF0ZS4NCiAg ICANCiAgICANCiAgICAxMDU0ICAgV2hlbiB0aGUgb3JpZ2luYXRpbmcgcm91dGVyIGRvZXMgYWR2 ZXJ0aXNlIHRoZSBTUi1BbGdvcml0aG0gc3ViLVRMViwNCiAgICAxMDU1ICAgdGhlbiBhbGdvcml0 aG0gMCBNVVNUIGJlIHByZXNlbnQgd2hpbGUgYWxnb3JpdGhtIDEgTUFZIGJlIHByZXNlbnQuDQog ICAgDQogICAgW25pdF0gSSB0aGluayB0aGF0IGl0IGlzIGNsZWFyIHRoYXQgYWxnb3JpdGhtIDEg aXMgb3B0aW9uYWwuICBJIHdvdWxkIHRha2UNCiAgICB0aGF0IGxhc3QgcGFydCBvdXQganVzdCBi ZWNhdXNlIG90aGVyIGFsZ29yaXRobXMgbWF5IGJlIGRlZmluZWQgaW4gdGhlDQogICAgZnV0dXJl Li4uYW5kIHRoZSBpbXBvcnRhbnQgcGFydCBhdCB0aGlzIHBvaW50IGlzIHRoZSBpbmNsdXNpb24g b2YgYWxnb3JpdGhtDQogICAgMC4NCiAgICANCiAgICANCiAgICAxMDU3ICAgVGhlIFNSLUFsZ29y aXRobSBzdWItVExWIGhhcyBmb2xsb3dpbmcgZm9ybWF0Og0KICAgIA0KICAgIFtuaXRdIHMvaGFz IGZvbGxvd2luZy9oYXMgdGhlIGZvbGxvd2luZw0KICAgIA0KICAgIA0KICAgIC4uLg0KICAgIDEw NzMgICAgICBBbGdvcml0aG06IDEgb2N0ZXQgb2YgYWxnb3JpdGhtIFNlY3Rpb24gMi4xDQogICAg DQogICAgW21pbm9yXSBUaGUgQWxnb3JpdGhtIGZpZWxkIGlzIGRlc2NyaWJlZCBpbiB0aGlzIHNl Y3Rpb24sIG5vdCBpbiAyLjEuDQogICAgDQogICAgDQogICAgMTA3NSAzLjMuICBTUiBMb2NhbCBC bG9jayBTdWItVExWDQogICAgDQogICAgMTA3NyAgIFRoZSBTUiBMb2NhbCBCbG9jayAoU1JMQikg U3ViLVRMViBjb250YWlucyB0aGUgcmFuZ2Ugb2YgbGFiZWxzIHRoZQ0KICAgIDEwNzggICBub2Rl IGhhcyByZXNlcnZlZCBmb3IgbG9jYWwgU0lEcy4gIExvY2FsIFNJRHMgYXJlIHVzZWQsIGUuZy4s IGZvcg0KICAgIDEwNzkgICBBZGphY2VuY3ktU0lEcywgYW5kIG1heSBhbHNvIGJlIGFsbG9jYXRl ZCBieSBvdGhlciBjb21wb25lbnRzIHRoYW4NCiAgICAxMDgwICAgSVMtSVMgcHJvdG9jb2wuICBB cyBhbiBleGFtcGxlLCBhbiBhcHBsaWNhdGlvbiBvciBhIGNvbnRyb2xsZXIgbWF5DQogICAgMTA4 MSAgIGluc3RydWN0IHRoZSByb3V0ZXIgdG8gYWxsb2NhdGUgYSBzcGVjaWZpYyBsb2NhbCBTSUQu ICBUaGVyZWZvcmUsIGluDQogICAgMTA4MiAgIG9yZGVyIGZvciBzdWNoIGFwcGxpY2F0aW9ucyBv ciBjb250cm9sbGVycyB0byBrbm93IHdoYXQgYXJlIHRoZSBsb2NhbA0KICAgIDEwODMgICBTSURz IGF2YWlsYWJsZSBpbiB0aGUgcm91dGVyLCBpdCBpcyByZXF1aXJlZCB0aGF0IHRoZSByb3V0ZXIN CiAgICAxMDg0ICAgYWR2ZXJ0aXNlcyBpdHMgU1JMQi4NCiAgICANCiAgICBbbml0XSBzL3RoYW4g SVMtSVMgcHJvdG9jb2wvdGhhbiB0aGUgSVMtSVMgcHJvdG9jb2wNCiAgICANCiAgICANCiAgICAu Li4NCiAgICAxMTIyICAgVGhlIG9yaWdpbmF0aW5nIHJvdXRlciBNVVNUIE5PVCBhZHZlcnRpc2Ug b3ZlcmxhcHBpbmcgcmFuZ2VzLg0KICAgIA0KICAgIFttYWpvcl0gV2hhdCBzaG91bGQgdGhlIHJl Y2VpdmVyIGRvIGlmIHRoZSByYW5nZXMgb3ZlcmxhcD8gIEknbSBhc3N1bWluZw0KICAgIHRoZSBz YW1lIHRoaW5nIGFzIHdoYXQgd2FzIHNwZWNpZmllZCBiZWZvcmUuLi5wbGVhc2UgYmUgc3BlY2lm aWMuDQogICAgDQogICAgDQogICAgMTEyNCAgIEl0IGlzIGltcG9ydGFudCB0byBub3RlIHRoYXQg ZWFjaCB0aW1lIGEgU0lEIGZyb20gdGhlIFNSTEIgaXMNCiAgICAxMTI1ICAgYWxsb2NhdGVkLCBp dCBTSE9VTEQgYWxzbyBiZSByZXBvcnRlZCB0byBhbGwgY29tcG9uZW50cyAoZS5nLjoNCiAgICAx MTI2ICAgY29udHJvbGxlciBvciBhcHBsaWNhdGlvbnMpIGluIG9yZGVyIGZvciB0aGVzZSBjb21w b25lbnRzIHRvIGhhdmUgYW4NCiAgICAxMTI3ICAgdXAtdG8tZGF0ZSB2aWV3IG9mIHRoZSBjdXJy ZW50IFNSTEIgYWxsb2NhdGlvbiBhbmQgaW4gb3JkZXIgdG8gYXZvaWQNCiAgICAxMTI4ICAgY29s bGlzaW9uIGJldHdlZW4gYWxsb2NhdGlvbiBpbnN0cnVjdGlvbnMuDQogICAgDQogICAgMTEzMCAg IFdpdGhpbiB0aGUgY29udGV4dCBvZiBJUy1JUywgdGhlIHJlcG9ydGluZyBvZiBsb2NhbCBTSURz IGlzIGRvbmUNCiAgICAxMTMxICAgdGhyb3VnaCBJUy1JUyBTdWItVExWcyBzdWNoIGFzIHRoZSBB ZGphY2VuY3ktU0lELiAgSG93ZXZlciwgdGhlDQogICAgMTEzMiAgIHJlcG9ydGluZyBvZiBhbGxv Y2F0ZWQgbG9jYWwgU0lEcyBtYXkgYWxzbyBiZSBkb25lIHRocm91Z2ggb3RoZXINCiAgICAxMTMz ICAgbWVhbnMgYW5kIHByb3RvY29scyB3aGljaCBtZWNoYW5pc21zIGFyZSBvdXRzaWRlIHRoZSBz Y29wZSBvZiB0aGlzDQogICAgMTEzNCAgIGRvY3VtZW50Lg0KICAgIA0KICAgIFttYWpvcl0gIlNI T1VMRCBhbHNvIGJlIHJlcG9ydGVkIHRvIGFsbCBjb21wb25lbnRzIiAgQmVjYXVzZSB0aGF0IGlz DQogICAgb3V0c2lkZSB0aGUgc2NvcGUsIHRoZW4gaXQgc2hvdWxkbid0IGJlIGEgTm9ybWF0aXZl IHN0YXRlbWVudC4NCiAgICAgcy9TSE9VTEQvc2hvdWxkDQogICAgDQogICAgDQogICAgLi4uDQog ICAgMTE3MCA0LiAgTm9uIGJhY2t3YXJkIGNvbXBhdGlibGUgY2hhbmdlcyB3aXRoIHByaW9yIHZl cnNpb25zIG9mIHRoaXMNCiAgICBkb2N1bWVudA0KICAgIA0KICAgIFttYWpvcl0gSSBmaW5kIHRo aXMgc2VjdGlvbiB1bm5lY2Vzc2FyeS4gIElmIHlvdSB3YW50IHRvIGtlZXAgaXQsIHBsZWFzZQ0K ICAgIG1vdmUgaXQgdG8gYW4gQXBwZW5kaXggYW5kIGRvbid0IHVzZSBOb3JtYXRpdmUgbGFuZ3Vh Z2UuDQogICAgDQogICAgDQogICAgLi4uDQogICAgMTE5MCA1LiAgSUFOQSBDb25zaWRlcmF0aW9u cw0KICAgIA0KICAgIDExOTIgICBUaGlzIGRvY3VtZW50cyByZXF1ZXN0IGFsbG9jYXRpb24gZm9y IHRoZSBmb2xsb3dpbmcgVExWcyBhbmQgc3ViVExWcw0KDQo= From nobody Wed Mar 20 16:37:50 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E55B312F1AB; Wed, 20 Mar 2019 16:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=UCJK2Gfh; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=DeaYoG3K 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 vl79zvC-_wl6; Wed, 20 Mar 2019 16:37:42 -0700 (PDT) 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 3C67612788F; Wed, 20 Mar 2019 16:37:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=58066; q=dns/txt; s=iport; t=1553125062; x=1554334662; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ocGKu958zNwIK290EVYkH7TOnHreqhpO1lAlBVUhXHg=; b=UCJK2GfheqnuGTBn1tyyKLPPPw8y30If/QGAMxQgwJrJdJRpBXsduWpN W/mQUrdebaavD0yGRZFrx4/pidHhxuvq6tkpTWJeQ2A/5IZyGYVkJgVDL H3vw4o7rwa77IwvQPy2hh594tKwE5WaNQIg8z2CQcUVeHIZyR7Z2y5zPi s=; IronPort-PHdr: =?us-ascii?q?9a23=3AZ7GGPB3+dEYtO8JHsmDT+zVfbzU7u7jyIg8e44?= =?us-ascii?q?YmjLQLaKm44pD+JxKGt+51ggrPWoPWo7JfhuzavrqoeFRI4I3J8RVgOIdJSw?= =?us-ascii?q?dDjMwXmwI6B8vQBkz9N/TndSMSF8VZX1gj9Ha+YgBY?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AoAABlzZJc/5xdJa1kGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBUQYBAQELAYE9JCwDgVwECyeEDYNHA4RSilSCV3yIN41UgS4UgRA?= =?us-ascii?q?DVAsBASyBKgGDFQIXhFAWDDQJDQEBAwEBCQEDAm0cDIVKAQEBAQIBGgEIEQw?= =?us-ascii?q?BASULBwEEBwQCAQgOAwEDAQEDAhEVAgICHxEVAgYIAgQBDQUIE4RlAw0IAQK?= =?us-ascii?q?gBwKKFHGBL4J4AQEFhQcNC4IMCIELJAGKEoEfF4FAP4EQAUaBTi4bNYJXgWU?= =?us-ascii?q?BDCICFhUPBhOCSzGCJooRIII4lzYqNgkCiyRBhAqDWIF9hXOLdYsSgReGHIg?= =?us-ascii?q?ygykCBAIEBQIOAQEFgUw4QoEUcBWDJ4IKDBeDS4pTcoEoiRmCTAEB?= X-IronPort-AV: E=Sophos;i="5.60,250,1549929600"; d="scan'208";a="250168867" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 20 Mar 2019 23:37:39 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x2KNbd3e016101 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Mar 2019 23:37:39 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 20 Mar 2019 18:37:38 -0500 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Wed, 20 Mar 2019 18:37:37 -0500 Received: from NAM04-SN1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Wed, 20 Mar 2019 18:37:37 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ocGKu958zNwIK290EVYkH7TOnHreqhpO1lAlBVUhXHg=; b=DeaYoG3KCBIK6XC8XxGNRztjxdsD2GAD+c5sQTDv9kgnT7r2twTHdF5WQpjOwWpO3TIvcGm8m5yAPSpbRw9sP0xMluhJSXQjEng+tMMgsTzdPPRUPuQvvv0wXCaPDymwOn2ToyfopHr9RbDHtroy1tMfCC6uengsu3FhqlcyCzg= Received: from BYAPR11MB3638.namprd11.prod.outlook.com (20.178.237.19) by BYAPR11MB2839.namprd11.prod.outlook.com (52.135.228.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1709.14; Wed, 20 Mar 2019 23:37:35 +0000 Received: from BYAPR11MB3638.namprd11.prod.outlook.com ([fe80::b414:f534:f20a:a26d]) by BYAPR11MB3638.namprd11.prod.outlook.com ([fe80::b414:f534:f20a:a26d%3]) with mapi id 15.20.1709.015; Wed, 20 Mar 2019 23:37:35 +0000 From: "Les Ginsberg (ginsberg)" To: Alvaro Retana , "draft-ietf-isis-segment-routing-extensions@ietf.org" CC: Uma Chunduri , "lsr-chairs@ietf.org" , "lsr@ietf.org" Thread-Topic: AD Review of draft-ietf-isis-segment-routing-extensions-22 Thread-Index: AQHU32s2LXimbEtSIUKKc+aYWZUjdqYVKWSw Date: Wed, 20 Mar 2019 23:37:35 +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: spf=none (sender IP is ) smtp.mailfrom=ginsberg@cisco.com; x-originating-ip: [2001:420:c0c8:1003::3f] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3c004c8c-c55d-43a9-eade-08d6ad8d0838 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BYAPR11MB2839; x-ms-traffictypediagnostic: BYAPR11MB2839: x-microsoft-antispam-prvs: x-forefront-prvs: 098291215C x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(376002)(346002)(396003)(366004)(136003)(13464003)(37854004)(199004)(189003)(51444003)(14454004)(2906002)(14444005)(8936002)(446003)(74316002)(486006)(7736002)(229853002)(30864003)(9686003)(11346002)(305945005)(476003)(316002)(106356001)(46003)(6436002)(53936002)(110136005)(53946003)(4326008)(25786009)(54906003)(105586002)(99286004)(68736007)(102836004)(186003)(76176011)(53546011)(8676002)(256004)(71200400001)(7696005)(52536014)(86362001)(6506007)(55016002)(6116002)(5660300002)(33656002)(97736004)(66574012)(2501003)(478600001)(6246003)(81156014)(81166006)(71190400001)(5024004)(569006); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB2839; H:BYAPR11MB3638.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: miwL9SXvSnSc4Caxt/UHIeMlhjm9MW7phq734duO4Lqmo3DFgck7lg40zFji097PYkJMnnfCAt4Ki+iax5PX6Udyujh7fJ9a4hASqyai7lGl9ui74boPDj3VqVGitBk0lnUb38UiVeAQPYBXmtpFjAUQZjWi1DMkl3pv/SCAsIQ4b5jDyN6d+7TLpm7/dYdNSdaFHCSqa/ozjH/Jo+gDpV1QEFEgBqcU465j1OsP/C5edDoFZFGDb4TRwLEHIhqheWHHq0ctF6w1TcI26m+OFq3Xpu6dMKd9h5Gycqxd41M3gBCUJ332g/n5u2LzJWhzBnj1r83ZVb6zmmX6YCMmVxzRTPMZSQ/uXnguptIP7/Y1F/FlHFD3QSECDojlRxM5OcaWKD8owqSccVRDs/lbbYeE6DBfDOjY/ZeUpCecNPg= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 3c004c8c-c55d-43a9-eade-08d6ad8d0838 X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Mar 2019 23:37:35.7174 (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-Transport-CrossTenantHeadersStamped: BYAPR11MB2839 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.18, xch-aln-008.cisco.com X-Outbound-Node: rcdn-core-5.cisco.com Archived-At: Subject: Re: [Lsr] AD Review of draft-ietf-isis-segment-routing-extensions-22 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Mar 2019 23:37:48 -0000 QWx2YXJvIC0NCg0KVGhhbnggZm9yIHRoZSByZXZpZXcuDQpXZSB3aWxsIHdvcmsgb24gYWRkcmVz c2luZyB0aGUgY29tbWVudHMuDQoNCkluIHJlZ2FyZHMgdG8gdGhlIHJlbGF0aW9uc2hpcCB3aXRo IFJGQyA3Nzk0LCB0aGVyZSBpcyBhIGhpc3RvcnkgaGVyZS4NClRoZSBOIGFuZCBSIGZsYWdzIHdl cmUgb3JpZ2luYWxseSBkZWZpbmVkIGFzIHBhcnQgb2YgdGhlIHByZWZpeC1zaWQgc3ViLVRMViBp biBlYXJseSB2ZXJzaW9ucyBvZiB0aGlzIGRyYWZ0LiBIb3dldmVyLCBpdCB3YXMgcmVhbGl6ZWQg dGhhdCB0aGVyZSB3ZXJlIHVzZSBjYXNlcyBmb3IgdGhlc2UgZmxhZ3MgdGhhdCBoYWQgbm90aGlu ZyB0byBkbyB3aXRoIFNSLiANClRoaXMgcHJvbXB0ZWQgd3JpdGluZyB3aGF0IGJlY2FtZSBSRkMg Nzc5NC4gQnV0IGJlY2F1c2UgdGhlcmUgYXJlIGVhcmx5IGRlcGxveW1lbnRzIGluIHRoZSBmaWVs ZCB3aGljaCB3ZXJlIGFscmVhZHkgdXNpbmcgdGhlIE4vUiBmbGFncyBpbiBwcmVmaXgtU0lEIHN1 Yi1UTFYgd2UgY291bGQgbm90IGltbWVkaWF0ZWx5IGRlcHJlY2F0ZSB0aGUgZmxhZ3MgaW4gcHJl Zml4LVNJRCBzdWItVExWLg0KDQpUaGUgaW50ZW50IGlzIGZvciBSRkMgNzc5NCBhZHZlcnRpc2Vt ZW50IHRvIGJlY29tZSB0aGUgc29sZSBwbGFjZSB3aGVyZSBOL1IgZmxhZ3MgYXJlIGFkdmVydGlz ZWQgLSBidXQgaW4gdGhlIGludGVyaW0gaW1wbGVtZW50YXRpb25zIGhhdmUgdG8gc3VwcG9ydCBs b2dpYyB3aGljaCBpcyByb3VnaGx5Og0KDQpJZiAocHJlZml4IGF0dHJpYnV0ZXMgc3ViLVRMViBp cyBwcmVzZW50KQ0KICBVc2UgcHJlZml4IGF0dHJpYnV0ZXMgc3ViLVRMViBzZXR0aW5ncyBhbmQg aWdub3JlIE4vUiBmbGFnIGluIHByZWZpeC1TSUQgc3ViLVRMViBpZiBwcmVzZW50DQpFbHNlDQog IFVzZSBOL1IgZmxhZyBpbiBwcmVmaXgtU0lEIHN1Yi1UTFYgaWYgcHJlc2VudA0KDQoiU29tZWRh eSIgYWxsIGltcGxlbWVudGF0aW9ucyB3aWxsIHN1cHBvcnQgcHJlZml4IGF0dHJpYnV0ZXMgc3Vi LVRMViBhbmQgdGhlcmUgd2lsbCBiZSBubyB1c2UgY2FzZSBmb3IgdGhlIGZsYWdzIGluIHByZWZp eC1TSUQgc3ViLVRMVi4gQXQgdGhhdCBwb2ludCB0aGUgZmxhZ3MgY2FuIGJlIHJlcHVycG9zZWQu DQoNCldoZW4gd2lsbCAic29tZWRheSIgaGFwcGVuPz8NCkkgdGhpbmsgeW91IGtub3cgYXMgd2Vs bCBhcyBJIHRoYXQgc3VjaCB0cmFuc2l0aW9ucyB0YWtlIG1hbnkgeWVhcnMuDQoNClRoZSB0aW1p bmcgb2YgdGhpcyBpcyBub3QgY3JpdGljYWwgdW5sZXNzIHdlIHJ1biBvdXQgb2YgZmxhZyBiaXRz IGluIHRoZSBwcmVmaXgtU0lEIHN1Yi1UTFYgYW5kIG5lZWQgdG8gcmV1c2UgdGhlIE4vUiBiaXRz LiBBdCB0aGlzIHBvaW50IHdlIGRvIG5vdCBmb3Jlc2VlIHRoaXMgaGFwcGVuaW5nIGFueSB0aW1l IHNvb24uDQoNCiAgIExlcw0KDQoNCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBG cm9tOiBBbHZhcm8gUmV0YW5hIDxhcmV0YW5hLmlldGZAZ21haWwuY29tPg0KPiBTZW50OiBXZWRu ZXNkYXksIE1hcmNoIDIwLCAyMDE5IDM6MjEgUE0NCj4gVG86IGRyYWZ0LWlldGYtaXNpcy1zZWdt ZW50LXJvdXRpbmctZXh0ZW5zaW9uc0BpZXRmLm9yZw0KPiBDYzogVW1hIENodW5kdXJpIDx1bWEu Y2h1bmR1cmlAaHVhd2VpLmNvbT47IGxzci1jaGFpcnNAaWV0Zi5vcmc7DQo+IGxzckBpZXRmLm9y Zw0KPiBTdWJqZWN0OiBBRCBSZXZpZXcgb2YgZHJhZnQtaWV0Zi1pc2lzLXNlZ21lbnQtcm91dGlu Zy1leHRlbnNpb25zLTIyDQo+IA0KPiBEZWFyIGF1dGhvcnM6DQo+IA0KPiBJIGp1c3QgZmluaXNo ZWQgcmV2aWV3aW5nIHRoaXMgZG9jdW1lbnQuICBQbGVhc2UgdGFrZSBhIGxvb2sgYXQgdGhlIGlu LWxpbmUNCj4gY29tbWVudHMgYmVsb3cuICBJbiBnZW5lcmFsLCBJIHRoaW5rIHRoYXQgc29tZSBt b3JlIHdvcmsgaXMgbmVlZGVkLiAgSSB3aWxsDQo+IHdhaXQgZm9yIHRoYXQgYmVmb3JlIHN0YXJ0 aW5nIHRoZSBJRVRGIExhc3QgQ2FsbC4NCj4gDQo+IFRoZXJlIGlzIGEgc2lnbmlmaWNhbnQgaXNz dWUgdGhhdCBJIHdhbnQgdG8gaGlnaGxpZ2h0IGhlcmUgKHRoZXJlIGFyZSBhbHNvDQo+IHJlbGF0 ZWQgY29tbWVudHMgaW4tbGluZSk6DQo+IA0KPiAtIMKnMi4xLjEuMiB0YWxrcyBhYm91dCBpbnRl cmFjdGlvbiB3aXRoIHJmYzc3OTQgYW5kIGEgdHJhbnNpdGlvbiBwZXJpb2QNCj4gd2hpY2ggYXBw YXJlbnRseSBlbmRzIGluIHRoaXMgc3BlY2lmaWNhdGlvbiBub3QgYmVpbmcgdXNlZC4gIEFtIEkg cmVhZGluZw0KPiB0aGF0IGNvcnJlY3RseT8NCj4gDQo+IFRoYW5rcyENCj4gDQo+IEFsdmFyby4N Cj4gDQo+IFtMaW5lIG51bWJlcnMgY29tZSBmcm9tIGlkbml0cy5dDQo+IA0KPiAuLi4NCj4gMTA3 IDEuICBJbnRyb2R1Y3Rpb24NCj4gDQo+IDEwOSAgIFNlZ21lbnQgUm91dGluZyAoU1IpIGFsbG93 cyBmb3IgYSBmbGV4aWJsZSBkZWZpbml0aW9uIG9mIGVuZC10by1lbmQNCj4gMTEwICAgcGF0aHMg d2l0aGluIElHUCB0b3BvbG9naWVzIGJ5IGVuY29kaW5nIHBhdGhzIGFzIHNlcXVlbmNlcyBvZg0K PiAxMTEgICB0b3BvbG9naWNhbCBzdWItcGF0aHMsIGNhbGxlZCAic2VnbWVudHMiLiAgVGhlc2Ug c2VnbWVudHMgYXJlDQo+IDExMiAgIGFkdmVydGlzZWQgYnkgdGhlIGxpbmstc3RhdGUgcm91dGlu ZyBwcm90b2NvbHMgKElTLUlTIGFuZCBPU1BGKS4NCj4gMTEzICAgUHJlZml4IHNlZ21lbnRzIHJl cHJlc2VudCBhbiBlY21wLWF3YXJlIHNob3J0ZXN0LXBhdGggdG8gYSBwcmVmaXggKG9yDQo+IDEx NCAgIGEgbm9kZSksIGFzIHBlciB0aGUgc3RhdGUgb2YgdGhlIElHUCB0b3BvbG9neS4gIEFkamFj ZW5jeSBzZWdtZW50cw0KPiAxMTUgICByZXByZXNlbnQgYSBob3Agb3ZlciBhIHNwZWNpZmljIGFk amFjZW5jeSBiZXR3ZWVuIHR3byBub2RlcyBpbiB0aGUNCj4gMTE2ICAgSUdQLiAgQSBwcmVmaXgg c2VnbWVudCBpcyB0eXBpY2FsbHkgYSBtdWx0aS1ob3AgcGF0aCB3aGlsZSBhbg0KPiAxMTcgICBh ZGphY2VuY3kgc2VnbWVudCwgaW4gbW9zdCBvZiB0aGUgY2FzZXMsIGlzIGEgb25lLWhvcCBwYXRo LiAgU1Incw0KPiAxMTggICBjb250cm9sLXBsYW5lIGNhbiBiZSBhcHBsaWVkIHRvIGJvdGggSVB2 NiBhbmQgTVBMUyBkYXRhLXBsYW5lcywgYW5kDQo+IDExOSAgIGRvIG5vdCByZXF1aXJlIGFueSBh ZGRpdGlvbmFsIHNpZ25hbGluZyAob3RoZXIgdGhhbiB0aGUgcmVndWxhciBJR1ApLg0KPiAxMjAg ICBGb3IgZXhhbXBsZSwgd2hlbiB1c2VkIGluIE1QTFMgbmV0d29ya3MsIFNSIHBhdGhzIGRvIG5v dCByZXF1aXJlIGFueQ0KPiAxMjEgICBMRFAgb3IgUlNWUC1URSBzaWduYWxpbmcuICBTdGlsbCwg U1IgY2FuIGludGVyb3BlcmF0ZSBpbiB0aGUgcHJlc2VuY2UNCj4gMTIyICAgb2YgTFNQcyBlc3Rh Ymxpc2hlZCB3aXRoIFJTVlAgb3IgTERQLg0KPiANCj4gW25pdF0gcy9lY21wLWF3YXJlL0VDTVAt YXdhcmUNCj4gDQo+IA0KPiAxMjQgICBUaGVyZSBhcmUgYWRkaXRpb25hbCBzZWdtZW50IHR5cGVz LCBlLmcuLCBCaW5kaW5nIFNJRCBkZWZpbmVkIGluDQo+IDEyNSAgIFtSRkM4NDAyXS4gIFRoaXMg ZHJhZnQgYWxzbyBkZWZpbmVzIGFuIGFkdmVydGlzZW1lbnQgZm9yIG9uZSB0eXBlIG9mDQo+IDEy NiAgIEJpbmRpbmdTSUQ6IHRoZSBNaXJyb3IgQ29udGV4dCBzZWdtZW50Lg0KPiANCj4gW25pdF0g cy9CaW5kaW5nU0lEL0JpbmRpbmcgU0lEDQo+IA0KPiANCj4gMTI4ICAgVGhpcyBkcmFmdCBkZXNj cmliZXMgdGhlIG5lY2Vzc2FyeSBJUy1JUyBleHRlbnNpb25zIHRoYXQgbmVlZCB0byBiZQ0KPiAx MjkgICBpbnRyb2R1Y2VkIGZvciBTZWdtZW50IFJvdXRpbmcgb3BlcmF0aW5nIG9uIGFuIE1QTFMg ZGF0YS1wbGFuZS4NCj4gDQo+IDEzMSAgIFNlZ21lbnQgUm91dGluZyBhcmNoaXRlY3R1cmUgaXMg ZGVzY3JpYmVkIGluIFtSRkM4NDAyXS4NCj4gDQo+IFtuaXRdIHMvU2VnbWVudCBSb3V0aW5nIGFy Y2hpdGVjdHVyZS9UaGUgU2VnbWVudCBSb3V0aW5nIGFyY2hpdGVjdHVyZQ0KPiANCj4gDQo+IDEz MyAgIFNlZ21lbnQgUm91dGluZyB1c2UgY2FzZXMgYXJlIGRlc2NyaWJlZCBpbiBbUkZDNzg1NV0u DQo+IA0KPiAxMzUgMi4gIFNlZ21lbnQgUm91dGluZyBJZGVudGlmaWVycw0KPiANCj4gMTM3ICAg U2VnbWVudCBSb3V0aW5nIGFyY2hpdGVjdHVyZSAoW1JGQzg0MDJdKSBkZWZpbmVzIGRpZmZlcmVu dCB0eXBlcyBvZg0KPiAxMzggICBTZWdtZW50IElkZW50aWZpZXJzIChTSUQpLiAgVGhpcyBkb2N1 bWVudCBkZWZpbmVzIHRoZSBJUy1JUyBlbmNvZGluZ3MNCj4gMTM5ICAgZm9yIHRoZSBJR1AtUHJl Zml4LVNJRCwgdGhlIElHUC1BZGphY2VuY3ktU0lELCB0aGUgSUdQLUxBTi1BZGphY2VuY3ktDQo+ IDE0MCAgIFNJRCBhbmQgdGhlIEJpbmRpbmctU0lELg0KPiANCj4gW25pdF0gcy8oW1JGQzg0MDJd KS9bUkZDODQwMl0NCj4gDQo+IFtuaXRdIHMvU2VnbWVudCBSb3V0aW5nIGFyY2hpdGVjdHVyZS9U aGUgU2VnbWVudCBSb3V0aW5nIGFyY2hpdGVjdHVyZQ0KPiANCj4gW21ham9yXSByZmM4NDAyIGRv ZXNuJ3QgdXNlIHRoZSBuYW1lcyBhYm92ZS4gIFBsZWFzZSBiZSBjb25zaXN0ZW50Lg0KPiANCj4g DQo+IDE0MiAyLjEuICBQcmVmaXggU2VnbWVudCBJZGVudGlmaWVyIChQcmVmaXgtU0lEIFN1Yi1U TFYpDQo+IA0KPiAxNDQgICBBIG5ldyBJUy1JUyBzdWItVExWIGlzIGRlZmluZWQ6IHRoZSBQcmVm aXggU2VnbWVudCBJZGVudGlmaWVyIHN1Yi1UTFYNCj4gMTQ1ICAgKFByZWZpeC1TSUQgc3ViLVRM VikuDQo+IA0KPiAxNDcgICBUaGUgUHJlZml4LVNJRCBzdWItVExWIGNhcnJpZXMgdGhlIFNlZ21l bnQgUm91dGluZyBJR1AtUHJlZml4LVNJRCBhcw0KPiAxNDggICBkZWZpbmVkIGluIFtSRkM4NDAy XS4gIFRoZSAnUHJlZml4IFNJRCcgTVVTVCBiZSB1bmlxdWUgd2l0aGluIGEgZ2l2ZW4NCj4gMTQ5 ICAgSUdQIGRvbWFpbiAod2hlbiB0aGUgTC1mbGFnIGlzIG5vdCBzZXQpLiAgVGhlICdQcmVmaXgg U0lEJyBNVVNUIGNhcnJ5DQo+IDE1MCAgIGFuIGluZGV4ICh3aGVuIHRoZSBWLWZsYWcgaXMgbm90 IHNldCkgdGhhdCBkZXRlcm1pbmVzIHRoZSBhY3R1YWwgU0lELw0KPiAxNTEgICBsYWJlbCB2YWx1 ZSBpbnNpZGUgdGhlIHNldCBvZiBhbGwgYWR2ZXJ0aXNlZCBTSUQvbGFiZWwgcmFuZ2VzIG9mIGEN Cj4gMTUyICAgZ2l2ZW4gcm91dGVyLiAgQSByZWNlaXZpbmcgcm91dGVyIHVzZXMgdGhlIGluZGV4 IHRvIGRldGVybWluZSB0aGUNCj4gMTUzICAgYWN0dWFsIFNJRC9sYWJlbCB2YWx1ZSBpbiBvcmRl ciB0byBjb25zdHJ1Y3QgZm9yd2FyZGluZyBzdGF0ZSB0byBhDQo+IDE1NCAgIHBhcnRpY3VsYXIg ZGVzdGluYXRpb24gcm91dGVyLg0KPiANCj4gW21ham9yXSBXaGF0IGlmIHRoZSBQcmVmaXggU0lE IGlzIG5vdCB1bmlxdWU/ICBXaGF0IHNob3VsZCB0aGUgcmVjZWl2ZXIgZG8/DQo+IA0KPiBbbWFq b3JdICIuLi5NVVNUIGNhcnJ5IGFuIGluZGV4Li4udGhhdCBkZXRlcm1pbmVzIHRoZSBhY3R1YWwg U0lEL2xhYmVsDQo+IHZhbHVlLi4uIiAgV2hhdCBhcmUgeW91IHRyeWluZyB0byBzcGVjaWZ5IHdp dGggdGhpcyAiTVVTVCI/ICBUaGUNCj4gZGVzY3JpcHRpb24gb2YgdGhlIFYtZmxhZyAoYmVsb3cp IGFscmVhZHkgcG9pbnRzIGF0IHRoZSB2YWx1ZSBiZWluZyBhbg0KPiBpbmRleCwgYnV0IHRoZSBx dWFsaWZpY2F0aW9uICgidGhhdCBkZXRlcm1pbmVzLi4uIikgbWFrZXMgdGhlIGVuZm9yY2VtZW50 DQo+IG9mIHRoaXMgIk1VU1QiIG1vcmUgY29tcGxleDogdGhlIHJlY2VpdmVyIGhhcyB0byB2ZXJp ZnkgdGhhdCB0aGUgaW5kZXgNCj4gYWN0dWFsbHkgcmVzdWx0cyBpbiBhIFNJRC9sYWJlbCBpbnNp ZGUgYSByYW5nZSBmb3IgaXQgdG8gYmUgdmFsaWQuICAgV2hhdA0KPiBzaG91bGQgdGhlIHJlY2Vp dmVyIGRvIGlmIHRoYXQgaXMgbm90IHRoZSBjYXNlPw0KPiANCj4gU3VnZ2VzdGlvbjogUmVhcnJh bmdlIHRoZSB0ZXh0IHNvIHRoYXQgdGhlIFRMViBhbmQgaXRzIGZpZWxkcyBhcmUgZGVzY3JpYmVk DQo+IGZpcnN0LiAgSSB0aGluayB0aGF0IHRoZW4gc29tZSBvZiB0aGUgdGV4dCBhYm92ZSB3b24n dCBiZSBuZWVkZWQuDQo+IA0KPiANCj4gMTU2ICAgSW4gbWFueSB1c2UtY2FzZXMgYSAnc3RhYmxl IHRyYW5zcG9ydCcgSVAgQWRkcmVzcyBpcyBvdmVybG9hZGVkIGFzIGFuDQo+IDE1NyAgIGlkZW50 aWZpZXIgb2YgYSBnaXZlbiBub2RlLiAgQmVjYXVzZSB0aGUgSVAgUHJlZml4ZXMgbWF5IGJlIHJl LQ0KPiAxNTggICBhZHZlcnRpc2VkIGludG8gb3RoZXIgbGV2ZWxzIHRoZXJlIG1heSBiZSBzb21l IGFtYmlndWl0eSAoZS5nLg0KPiAxNTkgICBPcmlnaW5hdGluZyByb3V0ZXIgdnMuIEwxTDIgcm91 dGVyKSBmb3Igd2hpY2ggbm9kZSBhIHBhcnRpY3VsYXIgSVANCj4gMTYwICAgcHJlZml4IHNlcnZl cyBhcyBpZGVudGlmaWVyLiAgVGhlIFByZWZpeC1TSUQgc3ViLVRMViBjb250YWlucyB0aGUNCj4g MTYxICAgbmVjZXNzYXJ5IGZsYWdzIHRvIGRpc2FtYmlndWF0ZSBJUCBQcmVmaXggdG8gbm9kZSBt YXBwaW5ncy4NCj4gMTYyICAgRnVydGhlcm1vcmUgaWYgYSBnaXZlbiBub2RlIGhhcyBzZXZlcmFs ICdzdGFibGUgdHJhbnNwb3J0JyBJUA0KPiAxNjMgICBhZGRyZXNzZXMgdGhlcmUgYXJlIGZsYWdz IHRvIGRpZmZlcmVudGlhdGUgdGhvc2UgYW1vbmcgb3RoZXIgSVANCj4gMTY0ICAgUHJlZml4ZXMg YWR2ZXJ0aXNlZCBmcm9tIGEgZ2l2ZW4gbm9kZS4NCj4gDQo+IFttaW5vcl0gQWdhaW4sIHRoaXMg dGV4dCBtYXkgYmUgY2xlYXJlciBpZiB0aGUgVExWIGRlc2NyaXB0aW9uIHdhcw0KPiBwcmVzZW50 ZWQgZmlyc3QuICBJZiB5b3UgZGVjaWRlIG5vdCB0byByZWFycmFuZ2UgdGhlIHRleHQsIGF0IGxl YXN0IHB1dA0KPiBmb3J3YXJkIHJlZmVyZW5jZXMgc28gcmVhZGVycyBjYW4gbG9vayBmb3J3YXJk IHRvIGZpbmQgb3V0IGhvdyB0aGUNCj4gc3RhdGVtZW50IGFib3ZlIGlzIGFjaGlldmVkLg0KPiAN Cj4gDQo+IC4uLg0KPiAxODAgICBXaGVuIHRoZSBJUCBSZWFjaGFiaWxpdHkgVExWIGlzIHByb3Bh Z2F0ZWQgYWNyb3NzIGxldmVsIGJvdW5kYXJpZXMsDQo+IDE4MSAgIHRoZSBQcmVmaXgtU0lEIHN1 Yi1UTFYgU0hPVUxEIGJlIGtlcHQuDQo+IA0KPiBbbWFqb3JdIFdoZW4gd291bGQgdGhpcyBzdWIt VExWIG5vdCBiZSBrZXB0PyAgSU9XLCB3aHkgaXMgdGhhdCBub3QgYQ0KPiAiTVVTVCI/DQo+IA0K PiDCpzIuMS4yOiAiVGhlIFByZWZpeC1TSUQgc3ViLVRMViBNVVNUIGJlIHByZXNlcnZlZCB3aGVu IHRoZSBJUCBSZWFjaGFiaWxpdHkNCj4gVExWDQo+IGdldHMgcHJvcGFnYXRlZCBhY3Jvc3MgbGV2 ZWwgYm91bmRhcmllcy4iDQo+IA0KPiBJJ20gbm90IHNheWluZyB0aGF0IG9uZSB3YXkgaXMgY29y cmVjdC4uLmVpdGhlciBvbmUgbWF5IGJlLiAgSnVzdCBiZQ0KPiBjb25zaXN0ZW50Lg0KPiANCj4g W21pbm9yXSBJJ20gYXNzdW1pbmcgdGhhdCAiSVAgUmVhY2hhYmlsaXR5IFRMViIgbWVhbnMgb25l IG9mIHRoZSBUTFZzDQo+IGFib3ZlLCB0cnVlPyAgSXQgbWF5IGJlIHdvcnRoIGNsYXJpZnlpbmcg dGhhdC4NCj4gDQo+IA0KPiAxODMgICBUaGUgUHJlZml4LVNJRCBzdWItVExWIGhhcyB0aGUgZm9s bG93aW5nIGZvcm1hdDoNCj4gDQo+IDE4NSAgICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAg ICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzDQo+IDE4NiAgICAwIDEgMiAzIDQgNSA2 IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCj4gMTg3 ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSsNCj4gMTg4ICAgfCAgIFR5cGUgICAgICAgIHwgICAgIExlbmd0aCAgICB8ICAg ICBGbGFncyAgICAgfCAgIEFsZ29yaXRobSAgIHwNCj4gMTg5ICAgKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gMTkwICAg fCAgICAgICAgICAgICAgICAgICAgICAgIFNJRC9JbmRleC9MYWJlbCAodmFyaWFibGUpICAgICAg ICAgICAgIHwNCj4gMTkxICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gDQo+IDE5MyAgIHdoZXJlOg0KPiANCj4gMTk1 ICAgICAgVHlwZTogVEJELCBzdWdnZXN0ZWQgdmFsdWUgMw0KPiANCj4gW21ham9yXSBUaGlzIHZh bHVlIChhbmQgYWxsIHRoZSBvdGhlcnMgaW4gdGhlIGRvY3VtZW50KSBhcmUgbm90ICJzdWdnZXN0 ZWQNCj4gdmFsdWVzIiwgdGhleSBoYXZlIGJlZW4gYWxyZWFkeSBhbGxvY2F0ZWQgYnkgSUFOQS4g IFBsZWFzZSB1cGRhdGUgdGhlDQo+IGluZGl2aWR1YWwgZGVzY3JpcHRpb25zIGFuZCB0aGUgSUFO QSBDb25zaWRlcmF0aW9ucyBzZWN0aW9uIGFjY29yZGluZ2x5Lg0KPiANCj4gDQo+IDE5NyAgICAg IExlbmd0aDogdmFyaWFibGUuDQo+IA0KPiBbbWlub3JdIFllcywgdmFyaWFibGUsIGJ1dCBpdCBj YW4gb25seSBoYXZlIHR3byB2YWx1ZXM6IDUgb3IgNi4NCj4gDQo+IA0KPiAxOTkgICAgICBGbGFn czogMSBvY3RldCBmaWVsZCBvZiBmb2xsb3dpbmcgZmxhZ3M6DQo+IA0KPiAyMDEgICAgMCAxIDIg MyA0IDUgNiA3DQo+IDIwMiAgICstKy0rLSstKy0rLSstKy0rDQo+IDIwMyAgIHxSfE58UHxFfFZ8 THwgICB8DQo+IDIwNCAgICstKy0rLSstKy0rLSstKy0rDQo+IA0KPiAyMDYgICAgICB3aGVyZToN Cj4gDQo+IDIwOCAgICAgICAgIFItRmxhZzogUmUtYWR2ZXJ0aXNlbWVudCBmbGFnLiAgSWYgc2V0 LCB0aGVuIHRoZSBwcmVmaXggdG8NCj4gMjA5ICAgICAgICAgd2hpY2ggdGhpcyBQcmVmaXgtU0lE IGlzIGF0dGFjaGVkLCBoYXMgYmVlbiBwcm9wYWdhdGVkIGJ5IHRoZQ0KPiAyMTAgICAgICAgICBy b3V0ZXIgZWl0aGVyIGZyb20gYW5vdGhlciBsZXZlbCAoaS5lLiwgZnJvbSBsZXZlbC0xIHRvIGxl dmVsLTINCj4gMjExICAgICAgICAgb3IgdGhlIG9wcG9zaXRlKSBvciBmcm9tIHJlZGlzdHJpYnV0 aW9uIChlLmcuOiBmcm9tIGFub3RoZXINCj4gMjEyICAgICAgICAgcHJvdG9jb2wpLg0KPiANCj4g W21ham9yXSBTaG91bGQgaXQgYmUgdXNlZCB0byBhdm9pZCBsb29waW5nIGFzIHdlbGw/ICBPciBp cyB0aGVyZSBubyByaXNrIG9mDQo+IHRoYXQgaW4gdGhpcyBjYXNlPw0KPiANCj4gDQo+IC4uLg0K PiAyMzYgICAgICAgICBPdGhlciBiaXRzOiBNVVNUIGJlIHplcm8gd2hlbiBvcmlnaW5hdGVkIGFu ZCBpZ25vcmVkIHdoZW4NCj4gMjM3ICAgICAgICAgcmVjZWl2ZWQuDQo+IA0KPiBbbWFqb3JdIERv IHlvdSBleHBlY3QgSUFOQSB0byBoYW5kbGUgdGhlIGFzc2lnbm1lbnQgb2YgdGhvc2Ugb3RoZXIg Yml0cz8NCj4gDQo+IA0KPiAyMzkgICAgICBBbGdvcml0aG06IHRoZSByb3V0ZXIgbWF5IHVzZSB2 YXJpb3VzIGFsZ29yaXRobXMgd2hlbiBjYWxjdWxhdGluZw0KPiAyNDAgICAgICByZWFjaGFiaWxp dHkgdG8gb3RoZXIgbm9kZXMgb3IgdG8gcHJlZml4ZXMgYXR0YWNoZWQgdG8gdGhlc2UNCj4gMjQx ICAgICAgbm9kZXMuICBBbGdvcml0aG1zIGlkZW50aWZpZXJzIGFyZSBkZWZpbmVkIGluIFNlY3Rp b24gMy4yLg0KPiAyNDIgICAgICBFeGFtcGxlcyBvZiB0aGVzZSBhbGdvcml0aG1zIGFyZSBtZXRy aWMgYmFzZWQgU2hvcnRlc3QgUGF0aCBGaXJzdA0KPiAyNDMgICAgICAoU1BGKSwgdmFyaW91cyBz b3J0cyBvZiBDb25zdHJhaW5lZCBTUEYsIGV0Yy4gIFRoZSBhbGdvcml0aG0gZmllbGQNCj4gMjQ0 ICAgICAgb2YgdGhlIFByZWZpeC1TSUQgY29udGFpbnMgdGhlIGlkZW50aWZpZXIgb2YgdGhlIGFs Z29yaXRobSB0aGUNCj4gMjQ1ICAgICAgcm91dGVyIGhhcyB1c2VkIGluIG9yZGVyIHRvIGNvbXB1 dGUgdGhlIHJlYWNoYWJpbGl0eSBvZiB0aGUgcHJlZml4DQo+IDI0NiAgICAgIHRvIHdoaWNoIHRo ZSBQcmVmaXgtU0lEIGlzIGFzc29jaWF0ZWQuDQo+IA0KPiAyNDggICAgICBBdCBvcmlnaW5hdGlv biwgdGhlIFByZWZpeC1TSUQgYWxnb3JpdGhtIGZpZWxkIE1VU1QgYmUgc2V0IHRvIDAgb3INCj4g MjQ5ICAgICAgdG8gYW55IHZhbHVlIGFkdmVydGlzZWQgaW4gdGhlIFNSLUFsZ29yaXRobSBzdWIt VExWIChTZWN0aW9uIDMuMikuDQo+IA0KPiBbbWFqb3JdIFdoYXQgc2hvdWxkIGEgcmVjZWl2ZXIg ZG8gaWYgdGhlIEFsZ29yaXRobSB2YWx1ZSBkb2Vzbid0IG1hdGNoIHdoYXQNCj4gaGFzIGJlZW4g YWR2ZXJ0aXNlZCBpbiB0aGUgU1ItQWxnb3JpdGhtIFN1Yi1UTFY/DQo+IA0KPiANCj4gLi4uDQo+ IDI4MiAyLjEuMS4yLiAgUiBhbmQgTiBGbGFncw0KPiANCj4gMjg0ICAgVGhlIFItRmxhZyBNVVNU IGJlIHNldCBmb3IgcHJlZml4ZXMgdGhhdCBhcmUgbm90IGxvY2FsIHRvIHRoZSByb3V0ZXINCj4g Mjg1ICAgYW5kIGVpdGhlcjoNCj4gDQo+IDI4NyAgICAgIGFkdmVydGlzZWQgYmVjYXVzZSBvZiBw cm9wYWdhdGlvbiAoTGV2ZWwtMSBpbnRvIExldmVsLTIpOw0KPiANCj4gMjg5ICAgICAgYWR2ZXJ0 aXNlZCBiZWNhdXNlIG9mIGxlYWtpbmcgKExldmVsLTIgaW50byBMZXZlbC0xKTsNCj4gDQo+IDI5 MSAgICAgIGFkdmVydGlzZWQgYmVjYXVzZSBvZiByZWRpc3RyaWJ1dGlvbiAoZS5nLjogZnJvbSBh bm90aGVyDQo+IDI5MiAgICAgIHByb3RvY29sKS4NCj4gDQo+IDI5NCAgIEluIHRoZSBjYXNlIHdo ZXJlIGEgTGV2ZWwtMS0yIHJvdXRlciBoYXMgbG9jYWwgaW50ZXJmYWNlIGFkZHJlc3Nlcw0KPiAy OTUgICBjb25maWd1cmVkIGluIG9uZSBsZXZlbCwgaXQgbWF5IGFsc28gcHJvcGFnYXRlIHRoZXNl IGFkZHJlc3NlcyBpbnRvDQo+IDI5NiAgIHRoZSBvdGhlciBsZXZlbC4gIEluIHN1Y2ggY2FzZSwg dGhlIExldmVsLTEtMiByb3V0ZXIgTVVTVCBOT1Qgc2V0IHRoZQ0KPiAyOTcgICBSIGJpdC4gIFRo ZSBSLWJpdCBNVVNUIGJlIHNldCBvbmx5IGZvciBwcmVmaXhlcyB0aGF0IGFyZSBub3QgbG9jYWwg dG8NCj4gMjk4ICAgdGhlIHJvdXRlciBhbmQgYWR2ZXJ0aXNlZCBieSB0aGUgcm91dGVyIGJlY2F1 c2Ugb2YgcHJvcGFnYXRpb24gYW5kL29yDQo+IDI5OSAgIGxlYWtpbmcuDQo+IA0KPiBbbWlub3Jd IFRoaXMgbGFzdCBzZW50ZW5jZSBpcyByZWR1bmRhbnQgd2l0aCB0aGUgc3RhcnQgb2YgdGhpcyBz ZWN0aW9uLg0KPiBQbGVhc2Ugc3BlY2lmeSB0aGUgYmVoYXZpb3IganVzdCBvbmNlLg0KPiANCj4g DQo+IDMwMSAgIFRoZSBOLUZsYWcgaXMgdXNlZCBpbiBvcmRlciB0byBkZWZpbmUgYSBOb2RlLVNJ RC4gIEEgcm91dGVyIE1BWSBzZXQNCj4gMzAyICAgdGhlIE4tRmxhZyBvbmx5IGlmIGFsbCBvZiB0 aGUgZm9sbG93aW5nIGNvbmRpdGlvbnMgYXJlIG1ldDoNCj4gDQo+IDMwNCAgICAgIFRoZSBwcmVm aXggdG8gd2hpY2ggdGhlIFByZWZpeC1TSUQgaXMgYXR0YWNoZWQgaXMgbG9jYWwgdG8gdGhlDQo+ IDMwNSAgICAgIHJvdXRlciAoaS5lLiwgdGhlIHByZWZpeCBpcyBjb25maWd1cmVkIG9uIG9uZSBv ZiB0aGUgbG9jYWwNCj4gMzA2ICAgICAgaW50ZXJmYWNlcywgZS5nLiwgYSAnc3RhYmxlIHRyYW5z cG9ydCcgbG9vcGJhY2spLg0KPiANCj4gMzA4ICAgICAgVGhlIHByZWZpeCB0byB3aGljaCB0aGUg UHJlZml4LVNJRCBpcyBhdHRhY2hlZCBNVVNUIGhhdmUgYSBQcmVmaXgNCj4gMzA5ICAgICAgbGVu Z3RoIG9mIGVpdGhlciAvMzIgKElQdjQpIG9yIC8xMjggKElQdjYpLg0KPiANCj4gW21ham9yXSAi VGhlIHByZWZpeC4uLk1VU1QgaGF2ZSBhIFByZWZpeCBsZW5ndGguLi4iICBUaGlzIGNvbmRpdGlv biBpcyBub3QNCj4gd29yZGVkIGFzIG9uZTsgcGVyaGFwczogIlRoZSBwcmVmaXguLi5oYXMgYSBQ cmVmaXggbGVuZ3RoLi4uIg0KPiANCj4gW21pbm9yXSBXaHkgaXMgdGhlIE4tRmxhZyBuZWVkZWQ/ ICBJZiB0aGUgc2V0dGluZyBpcyBvcHRpb25hbCAoIk1BWSIpLCB0aGVuDQo+IG5vdCBzZXR0aW5n IGl0IGRvZXNuJ3QgaW1wbHkgdGhhdCB0aGUgY29uZGl0aW9ucyBhcmUgbm90IG1ldC4uLg0KPiAN Cj4gW21ham9yXSBJdCBpcyBjbGVhcmx5IGFuIGVycm9yIGlmIGJvdGggdGhlIFItRmxhZyBhbmQg Ti1GbGFnIGFyZSBzZXQsDQo+IHJpZ2h0PyAgV2hhdCBzaG91bGQgdGhlIHJlY2VpdmVyIGRvIGlu IHRoYXQgY2FzZT8NCj4gDQo+IA0KPiAzMTEgICBUaGUgcm91dGVyIE1VU1QgaWdub3JlIHRoZSBO LUZsYWcgb24gYSByZWNlaXZlZCBQcmVmaXgtU0lEIGlmIHRoZQ0KPiAzMTIgICBwcmVmaXggaGFz IGEgUHJlZml4IGxlbmd0aCBkaWZmZXJlbnQgdGhhbiAvMzIgKElQdjQpIG9yIC8xMjggKElQdjYp Lg0KPiANCj4gMzE0ICAgW1JGQzc3OTRdIGFsc28gZGVmaW5lcyB0aGUgTiBhbmQgUiBmbGFncyBh bmQgd2l0aCB0aGUgc2FtZSBzZW1hbnRpY3MNCj4gMzE1ICAgb2YgdGhlIGVxdWl2YWxlbnQgZmxh Z3MgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50LiAgVGhlcmUgd2lsbCBiZSBhDQo+IDMxNiAgIHRy YW5zaXRpb24gcGVyaW9kIHdoZXJlIGJvdGggc2V0cyBvZiBmbGFncyB3aWxsIGJlIHVzZWQgYW5k DQo+IDMxNyAgIGV2ZW50dWFsbHkgb25seSB0aGUgZmxhZ3Mgb2YgdGhlIFByZWZpeCBBdHRyaWJ1 dGVzIHdpbGwgcmVtYWluLg0KPiAzMTggICBEdXJpbmcgdGhlIHRyYW5zaXRpb24gcGVyaW9kIGlt cGxlbWVudGF0aW9ucyBzdXBwb3J0aW5nIHRoZSBOIGFuZCBSDQo+IDMxOSAgIGZsYWdzIGRlZmlu ZWQgaW4gdGhpcyBkb2N1bWVudCBhbmQgdGhlIE4gYW5kIFIgZmxhZ3MgZGVmaW5lZCBpbg0KPiAz MjAgICBbUkZDNzc5NF0gTVVTVCBhZHZlcnRpc2UgYW5kIHBhcnNlIGFsbCBmbGFncy4gIEluIGNh c2UgdGhlIHJlY2VpdmVkDQo+IDMyMSAgIGZsYWdzIGhhdmUgZGlmZmVyZW50IHZhbHVlcywgdGhl IHZhbHVlIG9mIHRoZSBmbGFncyBkZWZpbmVkIGluDQo+IDMyMiAgIFtSRkM3Nzk0XSBwcmV2YWls cy4NCj4gDQo+IFttYWpvcl0gIi4uLnRyYW5zaXRpb24gcGVyaW9kIHdoZXJlIGJvdGggc2V0cyBv ZiBmbGFncyB3aWxsIGJlIHVzZWQgYW5kDQo+IGV2ZW50dWFsbHkgb25seSB0aGUgZmxhZ3Mgb2Yg dGhlIFByZWZpeCBBdHRyaWJ1dGVzIHdpbGwgcmVtYWluIiAgVG8gYmUNCj4gaG9uZXN0LCB5b3Ug bG9zdCBtZSBoZXJlPyAgUGxlYXNlIGV4cGxhaW4gd2hhdCB3aWxsIHRoZSB0cmFuc2l0aW9uIHBl cmlvZA0KPiBiZSBiZXR3ZWVuPw0KPiANCj4gW21ham9yXSBJZiAiYm90aCBzZXRzIG9mIGZsYWdz IHdpbGwgYmUgdXNlZCBhbmQgZXZlbnR1YWxseSBvbmx5IHRoZQ0KPiBbYWxyZWFkeSBkZWZpbmVk XSBmbGFncyBvZiB0aGUgUHJlZml4IEF0dHJpYnV0ZXMgd2lsbCByZW1haW4iLCB3aHkgZG8gd2UN Cj4gbmVlZCB0aGUgbmV3IG9uZXM/DQo+IA0KPiBbbWFqb3JdICJNVVNUIGFkdmVydGlzZSBhbmQg cGFyc2UgYWxsIGZsYWdzIiAgV2hhdCBkb2VzIHRoaXMgbWVhbj8gIEJ5ICJhbGwNCj4gZmxhZ3Mi IEkgZ3Vlc3MgeW91IG1lYW4gdGhlIE4gYW5kIFIgZmxhZ3MuLi5idXQgaWYgYm90aCB0aGlzIGRv Y3VtZW50IGFuZA0KPiByZmM3Nzk0IGFyZSBpbXBsZW1lbnRlZCwgaXQgc2VlbXMgdG8gbWUgdGhh dCB0aGUgc3BlY2lmaWNhdGlvbiBhYm92ZSBpcw0KPiByZWFsbHkgbWVhbmluZ2xlc3MuDQo+IA0K PiBbbWFqb3JdICJJbiBjYXNlIHRoZSByZWNlaXZlZCBmbGFncyBoYXZlIGRpZmZlcmVudCB2YWx1 ZXMuLi4iICBGb3IgYSBzZWNvbmQNCj4gaXQgc2VlbWVkIHRvIG1lIHRoYXQgd2hhdCB5b3UgcmVh bGx5IHdhbnRlZCB3YXMgZm9yIHRoZSBmbGFncyBpbiB0aGlzDQo+IGRvY3VtZW50IHRvIGJlaGF2 ZSB0aGUgc2FtZSB3YXkgYXMgdGhlIGZsYWdzIGRlZmluZWQgaW4gcmZjNzc5NC4uLnRoZSBlYXN5 DQo+IHNvbHV0aW9uIHRvIHRoYXQgKGFuZCB0byBhdm9pZCBteSBxdWVzdGlvbnMgbGlzdGVkIGJl Zm9yZSByZmM3Nzk0IHdhcw0KPiBtZW50aW9uZWQpIHdvdWxkIGhhdmUgYmVlbiB0byBqdXN0IHBv aW50IGF0IHJmYzc3OTQgYXMgdGhlIHBsYWNlIHdoZXJlIHRoZQ0KPiBGbGFncyBhcmUgZGVmaW5l ZC4gIEhvd2V2ZXIsIGl0IGxvb2tzIGxpa2UgdGhlIGRlZmluaXRpb25zIChhdCBsZWFzdCBmb3IN Cj4gdGhlIFItRmxhZykgYXJlIG5vdCB0aGUgc2FtZS4gIElzIHRoYXQgb24gcHVycG9zZSBvciBp cyBpdCBqdXN0IGFuDQo+IG92ZXJzaWdodD8NCj4gDQo+IE9uZSBwaWVjZSBvZiBpbmZvcm1hdGlv biB0aGF0IG1pZ2h0IG1ha2UgdGhpcyBkaXNjdXNzaW9uIHJlbGV2YW50IGlzDQo+IHVuZGVyc3Rh bmRpbmcgdGhlIHNpZ25pZmljYW5jZSBvZiB0aGVzZSBGbGFncy4uLmJ1dCBuZWl0aGVyIGRvY3Vt ZW50IG9mZmVycw0KPiBhbnkgc3BlY2lmaWMgdXNlLCBiZXlvbmQgc2ltcGx5ICJpdCBtYXkgYmUg dXNlZnVsIGZvciBvdGhlciByb3V0ZXJzIHRvDQo+IGtub3ciIChyZmM3Nzk0LCDCpzIuMikuDQo+ IA0KPiANCj4gMzI0IDIuMS4xLjMuICBFIGFuZCBQIEZsYWdzDQo+IA0KPiAzMjYgICBXaGVuIGNh bGN1bGF0aW5nIHRoZSBvdXRnb2luZyBsYWJlbCBmb3IgdGhlIHByZWZpeCwgdGhlIHJvdXRlciBN VVNUDQo+IDMyNyAgIHRha2UgaW50byBhY2NvdW50IEUgYW5kIFAgZmxhZ3MgYWR2ZXJ0aXNlZCBi eSB0aGUgbmV4dC1ob3Agcm91dGVyLCBpZg0KPiAzMjggICBuZXh0LWhvcCByb3V0ZXIgYWR2ZXJ0 aXNlZCB0aGUgU0lEIGZvciB0aGUgcHJlZml4LiAgVGhpcyBNVVNUIGJlIGRvbmUNCj4gMzI5ICAg cmVnYXJkbGVzcyBvZiBuZXh0LWhvcCByb3V0ZXIgY29udHJpYnV0aW5nIHRvIHRoZSBiZXN0IHBh dGggdG8gdGhlDQo+IDMzMCAgIHByZWZpeCBvciBub3QuDQo+IA0KPiBbbWFqb3JdICJ0aGUgcm91 dGVyIE1VU1QgdGFrZSBpbnRvIGFjY291bnQiICBXaGF0IG5vcm1hdGl2ZSBhY3Rpb24gaXMNCj4g c3RhbmRhcmRpemVkIHdpdGggdGhhdCBwaHJhc2U/ICBJdCB3b3VsZCBiZSBjbGVhcmVyL2JldHRl ciBpZiB0aGUgYmVoYXZpb3INCj4gaXMgZXhwbGljaXRseSBzcGVjaWZpZWQgaW4gZnVuY3Rpb24g b2YgdGhlIGZsYWdzIChhcyBzb25lIGJlbG93KS4NCj4gIHMvTVVTVC9tdXN0DQo+IA0KPiBbbWFq b3JdICJUaGlzIE1VU1QgYmUgZG9uZSByZWdhcmRsZXNzIG9mIG5leHQtaG9wIHJvdXRlciBjb250 cmlidXRpbmcgdG8NCj4gdGhlIGJlc3QgcGF0aCB0byB0aGUgcHJlZml4IG9yIG5vdC4iICBUaGlz IHdoYXQ/ICBJJ20gYXNzdW1pbmcgdGhlIHRleHQNCj4gcmVmZXJzIHRvICJ0YWtlIGludG8gYWNj b3VudCIuLi4gIFNhbWUgY29tbWVudCBhcyBiZWZvcmU6IHMvTVVTVC9tdXN0DQo+IA0KPiANCj4g Li4uDQo+IDM2NiAyLjEuMi4gIFByZWZpeC1TSUQgUHJvcGFnYXRpb24NCj4gDQo+IDM2OCAgIFRo ZSBQcmVmaXgtU0lEIHN1Yi1UTFYgTVVTVCBiZSBwcmVzZXJ2ZWQgd2hlbiB0aGUgSVAgUmVhY2hh YmlsaXR5DQo+IFRMVg0KPiAzNjkgICBnZXRzIHByb3BhZ2F0ZWQgYWNyb3NzIGxldmVsIGJvdW5k YXJpZXMuDQo+IA0KPiBbbWFqb3JdIMKnMi4xIHNheXMgdGhhdCBpdCBTSE9VTEQuICBQbGVhc2Ug YmUgY29uc2lzdGVudC4uLmFuZCwgc3BlY2lmeQ0KPiBiZWhhdmlvciBvbmx5IG9uY2UuDQo+IA0K PiAzNzEgICBUaGUgbGV2ZWwtMS0yIHJvdXRlciB0aGF0IHByb3BhZ2F0ZXMgdGhlIFByZWZpeC1T SUQgc3ViLVRMViBiZXR3ZWVuDQo+IDM3MiAgIGxldmVscyBNVVNUIHNldCB0aGUgUi1mbGFnLg0K PiANCj4gMzc0ICAgSWYgdGhlIFByZWZpeC1TSUQgY29udGFpbnMgYSBnbG9iYWwgaW5kZXggKEwg YW5kIFYgZmxhZ3MgdW5zZXQpIGFuZA0KPiAzNzUgICBpdCBpcyBwcm9wYWdhdGVkIGFzIHN1Y2gg KHdpdGggTCBhbmQgViBmbGFncyB1bnNldCksIHRoZSB2YWx1ZSBvZiB0aGUNCj4gMzc2ICAgaW5k ZXggTVVTVCBiZSBwcmVzZXJ2ZWQgd2hlbiBwcm9wYWdhdGVkIGJldHdlZW4gbGV2ZWxzLg0KPiAN Cj4gMzc4ICAgVGhlIGxldmVsLTEtMiByb3V0ZXIgdGhhdCBwcm9wYWdhdGVzIHRoZSBQcmVmaXgt U0lEIHN1Yi1UTFYgYmV0d2Vlbg0KPiAzNzkgICBsZXZlbHMgTUFZIGNoYW5nZSB0aGUgc2V0dGlu ZyBvZiB0aGUgTCBhbmQgViBmbGFncyBpbiBjYXNlIGEgbG9jYWwNCj4gMzgwICAgbGFiZWwgdmFs dWUgaXMgZW5jb2RlZCBpbiB0aGUgUHJlZml4LVNJRCBpbnN0ZWFkIG9mIHRoZSByZWNlaXZlZA0K PiAzODEgICB2YWx1ZS4NCj4gDQo+IFttYWpvcl0gIFVwIHRvIG5vdywgSSBoYWQgYmVlbiBhc3N1 bWluZyB0aGF0IHByb3BhZ2F0aW5nIGFuZCBwcmVzZXJ2aW5nDQo+IG1lYW50IG5vdCBjaGFuZ2lu ZyB0aGUgc3ViLVRMViAoZXhjZXB0IGZvciB0aGUgUi1GbGFnKS4gIEJ1dCB0aGVzZSBsYXN0DQo+ IHBhcmFncmFwaHMgaW5kaWNhdGUgdGhhdCBub3Qgb25seSBjYW4gc29tZSBmbGFncyBiZSBjaGFu Z2VkLCBidXQgdGhlDQo+IGNvbnRlbnRzIGNhbiBjb21wbGV0ZWx5IGNoYW5nZS4gIEl0IHdvdWxk IGJlIGlkZWFsIGlmIHRoZSB2YWxpZCBvcGVyYXRpb25zDQo+IG9uIHRoZSBzdWItVExWIHdlcmUg ZGlzY3Vzc2VkIChvciBhdCBsZWFzdCByZWZlcmVuY2VkKSB3aGVuIHRoZSBwcmVzZXJ2aW5nDQo+ IGJlaGF2aW9yIHdhcyBmaXJzdCBpbnRyb2R1Y2VkIChJIHRoaW5rIGluIMKnMi4xKS4NCj4gDQo+ IA0KPiAuLi4NCj4gNDA5IDIuMi4xLiAgQWRqYWNlbmN5IFNlZ21lbnQgSWRlbnRpZmllciAoQWRq LVNJRCkgU3ViLVRMVg0KPiANCj4gNDExICAgVGhlIGZvbGxvd2luZyBmb3JtYXQgaXMgZGVmaW5l ZCBmb3IgdGhlIEFkai1TSUQgc3ViLVRMVjoNCj4gDQo+IDQxMyAgICAwICAgICAgICAgICAgICAg ICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzDQo+IDQxNCAgICAw IDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDgg OSAwIDENCj4gNDE1ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gNDE2ICAgfCAgIFR5cGUgICAgICAgIHwgICAgIExl bmd0aCAgICB8ICAgICBGbGFncyAgICAgfCAgICAgV2VpZ2h0ICAgIHwNCj4gNDE3ICAgKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSsNCj4gNDE4ICAgfCAgICAgICAgICAgICAgICAgICAgICAgICBTSUQvTGFiZWwvSW5kZXggKHZh cmlhYmxlKSAgICAgICAgICAgIHwNCj4gNDE5ICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gDQo+IDQyMSAgIHdoZXJl Og0KPiANCj4gNDIzICAgICAgVHlwZTogVEJELCBzdWdnZXN0ZWQgdmFsdWUgMzENCj4gDQo+IDQy NSAgICAgIExlbmd0aDogdmFyaWFibGUuDQo+IA0KPiBbbWlub3JdIFllcywgdmFyaWFibGUsIGJ1 dCBpdCBjYW4gb25seSBoYXZlIHR3byB2YWx1ZXMuLi4NCj4gDQo+IDQyNyAgICAgIEZsYWdzOiAx IG9jdGV0IGZpZWxkIG9mIGZvbGxvd2luZyBmbGFnczoNCj4gDQo+IDQyOSAgICAgICAgICAwIDEg MiAzIDQgNSA2IDcNCj4gNDMwICAgICAgICAgKy0rLSstKy0rLSstKy0rLSsNCj4gNDMxICAgICAg ICAgfEZ8QnxWfEx8U3xQfCAgIHwNCj4gNDMyICAgICAgICAgKy0rLSstKy0rLSstKy0rLSsNCj4g DQo+IDQzNCAgICAgIHdoZXJlOg0KPiANCj4gNDM2ICAgICAgICAgRi1GbGFnOiBBZGRyZXNzLUZh bWlseSBmbGFnLiAgSWYgdW5zZXQsIHRoZW4gdGhlIEFkai1TSUQgcmVmZXJzDQo+IDQzNyAgICAg ICAgIHRvIGFuIGFkamFjZW5jeSB3aXRoIG91dGdvaW5nIElQdjQgZW5jYXBzdWxhdGlvbi4gIElm IHNldCB0aGVuDQo+IDQzOCAgICAgICAgIHRoZSBBZGotU0lEIHJlZmVycyB0byBhbiBhZGphY2Vu Y3kgd2l0aCBvdXRnb2luZyBJUHY2DQo+IDQzOSAgICAgICAgIGVuY2Fwc3VsYXRpb24uDQo+IA0K PiBbbWFqb3JdIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVzIHRoZSBvcGVyYXRpb24gb24gdGhlIE1Q TFMgZGF0YSBwbGFuZSwNCj4gcmlnaHQ/ICBUaGUgRi1GbGFnIHRhbGtzIGFib3V0IHRoZSBvdXRn b2luZyBlbmNhcHN1bGF0aW9uLi4uYnV0IHRoYXQgY291bGQNCj4gc2ltcGx5IGJlIHRoZSBuZXh0 IGxhYmVsIGluIHRoZSBNUExTIHN0YWNrLCByaWdodD8gIFdoYXQgYW0gSSBtaXNzaW5nPyAgSQ0K PiBnZXQgdGhlIGltcHJlc3Npb24gdGhhdCB0aGVyZSdzIGEgcmVsYXRpb25zaGlwIGJldHdlZW4g d2hhdCB0aGlzIEZsYWcNCj4gcG9pbnRzIHRvIGFuZCBzb21ldGhpbmcgZWxzZS4uLmJ1dCBJIGp1 c3QgZG9uJ3Qga25vdyB3aGF0Lg0KPiANCj4gDQo+IDQ0MSAgICAgICAgIEItRmxhZzogQmFja3Vw IGZsYWcuICBJZiBzZXQsIHRoZSBBZGotU0lEIGlzIGVsaWdpYmxlIGZvcg0KPiA0NDIgICAgICAg ICBwcm90ZWN0aW9uIChlLmcuOiB1c2luZyBJUEZSUiBvciBNUExTLUZSUikgYXMgZGVzY3JpYmVk IGluDQo+IDQ0MyAgICAgICAgIFtSRkM4MzU1XS4NCj4gDQo+IFttYWpvcl0gQmVjYXVzZSB0aGUg c3BlY2lmaWNhdGlvbiBvZiB0aGUgQi1GbGFnIGRlcGVuZHMgZGlyZWN0bHkgb24NCj4gcmZjODM1 NSwgaXQgc2hvdWxkIGJlIGEgTm9ybWF0aXZlIHJlZmVyZW5jZS4gIExvb2tpbmcgYXQgcmZjODM1 NSwgSQ0KPiBjb3VsZG4ndCBmaW5kIGEgcGxhY2Ugd2hlcmUgaXQgdGFsa3MgYWJvdXQgZWxpZ2li aWxpdHkgZm9yDQo+IHByb3RlY3Rpb24uLi5qdXN0IHRleHQgYWJvdXQgcG90ZW50aWFsIHN0cmF0 ZWdpZXMsIGJ1dCAoaG9uZXN0bHkpIG5vdGhpbmcNCj4gdGhhdCBJIHdvdWxkIGNhbGwgTm9ybWF0 aXZlLiAgUGxlYXNlIGNsYXJpZnkuICBQZXJoYXBzIHJmYzg0MDIgbWlnaHQgYmUgYQ0KPiBiZXR0 ZXIgcmVmZXJlbmNlLg0KPiANCj4gW21ham9yXSBJJ20gYXNzdW1pbmcgdGhhdCB0aGlzIGRlc2Ny aXB0aW9uIChwb2ludGluZyBhdCByZmM4MzU1KSwgcGx1cyB0aGUNCj4gdGV4dCBiZWxvdyBhYm91 dCBhbGxvY2F0aW9uIG9mIEFkai1TSURzIHNob3VsZCByZXN1bHQgaW4gc29tZSBhY3Rpb24NCj4g cmVsYXRlZCB0byB0aGUgcHJvdGVjdGlvbi4uLndoYXQgaXMgdGhhdD8gIElPVywgcHJlc2VudGVk IHdpdGggdGhlIEItRmxhZw0KPiBzZXQsIHdoYXQgYWN0aW9uIHNob3VsZCBhIG5vZGUgdGFrZT8N Cj4gDQo+IA0KPiA0NDUgICAgICAgICBWLUZsYWc6IFZhbHVlIGZsYWcuICBJZiBzZXQsIHRoZW4g dGhlIEFkai1TSUQgY2FycmllcyBhIHZhbHVlLg0KPiA0NDYgICAgICAgICBCeSBkZWZhdWx0IHRo ZSBmbGFnIGlzIFNFVC4NCj4gDQo+IFttaW5vcl0gSXMgdGhlIGRlc2NyaXB0aW9uIHRoZSBzYW1l IGF0IHRoZSBWLUZsYWcgaW4gwqcyLjE/ICBJZiBzbywgdGhlbg0KPiBpbmRpY2F0aW5nIHRoYXQs IG9yIGF0IGxlYXN0IGFsc28gcG9pbnRpbmcgb3V0IGhlcmUgdGhhdCB0aGUgdmFsdWUgaXMNCj4g Y2FycmllZCBpbnN0ZWFkIG9mIGFuIGluZGV4IHdvdWxkIGJlIGhlbHBmdWwuDQo+IA0KPiANCj4g NDQ4ICAgICAgICAgTC1GbGFnOiBMb2NhbCBGbGFnLiAgSWYgc2V0LCB0aGVuIHRoZSB2YWx1ZS9p bmRleCBjYXJyaWVkIGJ5DQo+IDQ0OSAgICAgICAgIHRoZSBBZGotU0lEIGhhcyBsb2NhbCBzaWdu aWZpY2FuY2UuICBCeSBkZWZhdWx0IHRoZSBmbGFnIGlzDQo+IDQ1MCAgICAgICAgIFNFVC4NCj4g DQo+IFttYWpvcl0gTG9va2luZyBiYWNrIGF0IMKnMi4xLjEuMSwgd2hhdCBhcmUgdGhlIGNvbmRp dGlvbnMgZm9yIHdoaWNoIHRoZQ0KPiBjb21iaW5hdGlvbiBvZiB0aGUgViBhbmQgTC1GbGFncyBh cmUgdmFsaWQvaW52YWxpZD8gIERvIHRoZSBzYW1lIGNvbmRpdGlvbnMNCj4gYXBwbHk/DQo+IA0K PiANCj4gLi4uDQo+IDQ2MCAgICAgICAgIE90aGVyIGJpdHM6IE1VU1QgYmUgemVybyB3aGVuIG9y aWdpbmF0ZWQgYW5kIGlnbm9yZWQgd2hlbg0KPiA0NjEgICAgICAgICByZWNlaXZlZC4NCj4gDQo+ IFttYWpvcl0gRG8geW91IGV4cGVjdCBJQU5BIHRvIGhhbmRsZSB0aGUgYXNzaWdubWVudCBvZiB0 aG9zZSBvdGhlciBiaXRzPw0KPiANCj4gDQo+IC4uLg0KPiA0NjkgICAgICBBbiBTUiBjYXBhYmxl IHJvdXRlciBNQVkgYWxsb2NhdGUgYW4gQWRqLVNJRCBmb3IgZWFjaCBvZiBpdHMNCj4gNDcwICAg ICAgYWRqYWNlbmNpZXMgYW5kIFNIT1VMRCBzZXQgdGhlIEItRmxhZyB3aGVuIHRoZSBhZGphY2Vu Y3kgaXMNCj4gNDcxICAgICAgZWxpZ2libGUgZm9yIHByb3RlY3Rpb24gKElQIG9yIE1QTFMpLg0K PiANCj4gW21ham9yXSBJZiBlbGlnaWJsZSBmb3IgcHJvdGVjdGlvbiwgd2hlbiB3b3VsZCB0aGUg cm91dGVyIG5vdCBzZXQgdGhlDQo+IEItRmxhZz8gIElPVywgd2h5IGlzIHRoYXQgbm90IGEgTVVT VD8NCj4gDQo+IEJleW9uZCB0aGF0LCBJIHRoaW5rIHRoYXQgdGhlIHVzZSBvZiBTSE9VTEQgaXMg aW4gY29uZmxpY3Qgd2l0aCB0aGUNCj4gZGVmaW5pdGlvbiBvZiB0aGUgQi1GbGFnIChhYm92ZSk6 ICJJZiBzZXQsIHRoZSBBZGotU0lEIGlzIGVsaWdpYmxlIGZvcg0KPiBwcm90ZWN0aW9uLi4uIiwg d2hpY2ggaW1wbGllcyB0aGF0IGl0IGlzbid0IGVsaWdpYmxlIGlmIGl0J3Mgbm90IHNldC4uLmJ1 dA0KPiB0aGUgU0hPVUxEIG9wZW5zIHRoZSBkb29yIGZvciBub3Qgc2V0dGluZyB0aGUgRmxhZy4u Lg0KPiANCj4gDQo+IC4uLg0KPiA0NzkgICAgICBXaGVuIHRoZSBQLWZsYWcgaXMgbm90IHNldCwg dGhlIEFkai1TSUQgTUFZIGJlIHBlcnNpc3RlbnQuICBXaGVuDQo+IDQ4MCAgICAgIHRoZSBQLWZs YWcgaXMgc2V0LCB0aGUgQWRqLVNJRCBNVVNUIGJlIHBlcnNpc3RlbnQuDQo+IA0KPiBbbWFqb3Jd IElmIHRoZSBhZGphY2VuY3kgaXMgcGVyc2lzdGVudCwgd2h5L3doZW4gd291bGQgdGhlIFAtRmxh ZyBub3QgYmUNCj4gc2V0Pw0KPiANCj4gDQo+IC4uLg0KPiA0ODggMi4yLjIuICBBZGphY2VuY3kg U2VnbWVudCBJZGVudGlmaWVycyBpbiBMQU5zDQo+IC4uLg0KPiA1MzcgICAgICBPdGhlciBiaXRz OiBNVVNUIGJlIHplcm8gd2hlbiBvcmlnaW5hdGVkIGFuZCBpZ25vcmVkIHdoZW4NCj4gNTM4ICAg ICAgcmVjZWl2ZWQuDQo+IA0KPiBbbWFqb3JdIERvIHlvdSBleHBlY3QgSUFOQSB0byBoYW5kbGUg dGhlIGFzc2lnbm1lbnQgb2YgdGhvc2Ugb3RoZXIgYml0cz8NCj4gDQo+IA0KPiAuLi4NCj4gNTQ0 ICAgICAgU3lzdGVtLUlEOiA2IG9jdGV0cyBvZiBJUy1JUyBTeXN0ZW0tSUQgb2YgbGVuZ3RoICJJ RCBMZW5ndGgiIGFzDQo+IDU0NSAgICAgIGRlZmluZWQgaW4gW0lTTzEwNTg5XS4NCj4gDQo+IFtt YWpvcl0gV2hpY2ggU3lzdGVtLUlEPw0KPiANCj4gW21ham9yXSAiNiBvY3RldHMgb2YuLi5sZW5n dGggIklEIExlbmd0aCIiICA/Pw0KPiANCj4gDQo+IDU0NyAgICAgIFNJRC9JbmRleC9MYWJlbCBh cyBkZWZpbmVkIGluIFNlY3Rpb24gMi4xLjEuMS4NCj4gDQo+IDU0OSAgIE11bHRpcGxlIExBTi1B ZGotU0lEIHN1Yi1UTFZzIE1BWSBiZSBlbmNvZGVkLiAgTm90ZSB0aGF0IHRoaXMgc3ViLQ0KPiBU TFYNCj4gNTUwICAgTVVTVCBOT1QgYXBwZWFyIGluIFRMViAxNDEuDQo+IA0KPiA1NTIgICBXaGVu IHRoZSBQLWZsYWcgaXMgbm90IHNldCwgdGhlIExBTi1BZGotU0lEIE1BWSBiZSBwZXJzaXN0ZW50 LiAgV2hlbg0KPiA1NTMgICB0aGUgUC1mbGFnIGlzIHNldCwgdGhlIExBTi1BZGotU0lEIE1VU1Qg YmUgcGVyc2lzdGVudC4NCj4gDQo+IDU1NSAgIEluIGNhc2Ugb25lIFRMVi0yMi8yMy8yMjIvMjIz IChyZXBvcnRpbmcgdGhlIGFkamFjZW5jeSB0byB0aGUgRElTKQ0KPiA1NTYgICBjYW4ndCBjb250 YWluIHRoZSB3aG9sZSBzZXQgb2YgTEFOLUFkai1TSUQgc3ViLVRMVnMsIG11bHRpcGxlDQo+IDU1 NyAgIGFkdmVydGlzZW1lbnRzIG9mIHRoZSBhZGphY2VuY3kgdG8gdGhlIERJUyBNVVNUIGJlIHVz ZWQgYW5kIGFsbA0KPiA1NTggICBhZHZlcnRpc2VtZW50cyBNVVNUIGhhdmUgdGhlIHNhbWUgbWV0 cmljLg0KPiANCj4gNTYwICAgRWFjaCByb3V0ZXIgd2l0aGluIHRoZSBsZXZlbCwgYnkgcmVjZWl2 aW5nIHRoZSBESVMgUE4gTFNQIGFzIHdlbGwgYXMNCj4gNTYxICAgdGhlIG5vbi1QTiBMU1Agb2Yg ZWFjaCByb3V0ZXIgaW4gdGhlIExBTiwgaXMgY2FwYWJsZSBvZg0KPiA1NjIgICByZWNvbnN0cnVj dGluZyB0aGUgTEFOIHRvcG9sb2d5IGFzIHdlbGwgYXMgdGhlIHNldCBvZiBBZGotU0lEIGVhY2gN Cj4gNTYzICAgcm91dGVyIHVzZXMgZm9yIGVhY2ggb2YgaXRzIG5laWdoYm9ycy4NCj4gDQo+IDU2 NSAgIEEgbGFiZWwgaXMgZW5jb2RlZCBpbiAzIG9jdGV0cyAoaW4gdGhlIDIwIHJpZ2h0bW9zdCBi aXRzKS4NCj4gDQo+IDU2NyAgIEFuIGluZGV4IGlzIGVuY29kZWQgaW4gNCBvY3RldHMuDQo+IA0K PiBbbWlub3JdIFNvbWUgb2YgdGhlIGluZm9ybWF0aW9uIGFib3ZlIChmb3IgZXhhbXBsZSwgdGhl IHBhcmFncmFwaCBhYm91dA0KPiB0aGUNCj4gUC1GbGFnIGFuZCB0aGVzZSBsYXN0IDIgc2VudGVu Y2VzKSBzZWVtcyB1bm5lY2Vzc2FyeSBnaXZlbiB0aGF0IHRoZQ0KPiBkZXNjcmlwdGlvbiBvZiB0 aGVzZSBmaWVsZHMgaXMgYWxyZWFkeSBkb25lIHNvbWV3aGVyZSBlbHNlLg0KPiANCj4gDQo+IDU2 OSAyLjMuICBTSUQvTGFiZWwgU3ViLVRMVg0KPiANCj4gNTcxICAgVGhlIFNJRC9MYWJlbCBzdWIt VExWIG1heSBiZSBwcmVzZW50IGluIHRoZSBmb2xsb3dpbmcgVExWcy9zdWItVExWcw0KPiA1NzIg ICBkZWZpbmVkIGluIHRoaXMgZG9jdW1lbnQ6DQo+IA0KPiA1NzQgICBTUi1DYXBhYmlsaXRpZXMg U3ViLVRMViAoU2VjdGlvbiAzLjEpDQo+IA0KPiA1NzYgICBTUiBMb2NhbCBCbG9jayBTdWItVExW IChTZWN0aW9uIDMuMykNCj4gDQo+IDU3OCAgIFNJRC9MYWJlbCBCaW5kaW5nIFRMViAoU2VjdGlv biAyLjQpDQo+IA0KPiA1ODAgICBNdWx0aS1Ub3BvbG9neSBTSUQvTGFiZWwgQmluZGluZyBUTFYg KFNlY3Rpb24gMi41KQ0KPiANCj4gW25pdF0gSXQgbWlnaHQgaGF2ZSBiZWVuIG5pY2UsIGluIGxp bmUgd2l0aCB0aGUgT1NQRiB3b3JrLCB0byBmbGlwIFNlY3Rpb25zDQo+IDIgYW5kIDMuICBKdXN0 IGEgbml0Li4uDQo+IA0KPiA1ODIgICBOb3RlIHRoYXQgdGhlIGNvZGUgcG9pbnQgdXNlZCBpbiBh bGwgb2YgdGhlIGFib3ZlIGNhc2VzIGlzIHRoZSBTSUQvDQo+IDU4MyAgIExhYmVsIFN1Yi1UTFYg Y29kZSBwb2ludCBhc3NpZ25lZCBieSBJQU5BIGluIHRoZSAic3ViLVRMVnMgZm9yIFRMVg0KPiA1 ODQgICAxNDkgYW5kIDE1MCIgcmVnaXN0cnkuDQo+IA0KPiBbbWFqb3JdIEJlY2F1c2UgdGhpcyBk b2N1bWVudCBpcyBzZXR0aW5nIHVwIHRoYXQgbmV3IHJlZ2lzdHJ5LCB3ZSBkb24ndA0KPiBoYXZl IHRvIHdhaXQgZm9yIElBTkEgdG8gYXNzaWduIGFueXRoaW5nOiB0aGUgZG9jdW1lbnQgY2FuIHNw ZWNpZnkgaXQuDQo+IElPVywgdGhlIHBhcmFncmFwaCBhYm92ZSBpcyBub3QgbmVlZGVkLg0KPiAN Cj4gDQo+IDU4NiAgIFRoZSBTSUQvTGFiZWwgc3ViLVRMViBjb250YWlucyBhIFNJRCBvciBhIE1Q TFMgTGFiZWwuICBUaGUgU0lEL0xhYmVsDQo+IDU4NyAgIHN1Yi1UTFYgaGFzIHRoZSBmb2xsb3dp bmcgZm9ybWF0Og0KPiANCj4gNTg5ICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAg ICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMNCj4gNTkwICAgIDAgMSAyIDMgNCA1IDYgNyA4 IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KPiA1OTEgICAr LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gNTkyICAgfCAgIFR5cGUgICAgICAg IHwgICAgIExlbmd0aCAgICB8DQo+IDU5MyAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+IDU5NCAgIHwgICAgICAgICAg ICAgICAgICAgICAgICAgIFNJRC9MYWJlbCAodmFyaWFibGUpICAgICAgICAgICAgICAgICB8DQo+ IDU5NSAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rDQo+IA0KPiA1OTcgICB3aGVyZToNCj4gDQo+IDU5OSAgICAgIFR5cGU6 IFRCRCwgc3VnZ2VzdGVkIHZhbHVlIDENCj4gDQo+IDYwMSAgICAgIExlbmd0aDogdmFyaWFibGUN Cj4gDQo+IFttYWpvcl0gWWVzLCB2YXJpYWJsZS4uLmJ1dCByaWdodCBub3cgb25seSBvbmUgdmFs dWUgaXMgZGVmaW5lZC4gIFRoZXJlJ3MgYQ0KPiBmaW5pdGUgbnVtYmVyIG9mIHBvc3NpYmlsaXRp ZXMuLi4NCj4gDQo+IA0KPiA2MDIgICAgICBTSUQvTGFiZWw6IGlmIGxlbmd0aCBpcyBzZXQgdG8g MyB0aGVuIHRoZSAyMCByaWdodG1vc3QgYml0cw0KPiA2MDMgICAgICByZXByZXNlbnQgYSBNUExT IGxhYmVsLg0KPiANCj4gW21ham9yXSBJcyB0aGF0IGl0Li4/ICBXaGF0IGFib3V0IHRoZSBTSUQ/ DQo+IA0KPiANCj4gNjA1IDIuNC4gIFNJRC9MYWJlbCBCaW5kaW5nIFRMVg0KPiAuLi4NCj4gNjE5 ICAgVGhlIFNJRC9MYWJlbCBCaW5kaW5nIFRMViBoYXMgVHlwZSBUQkQgKHN1Z2dlc3RlZCB2YWx1 ZSAxNDkpLCBhbmQgaGFzDQo+IDYyMCAgIHRoZSBmb2xsb3dpbmcgZm9ybWF0Og0KPiANCj4gW25p dF0gTm8gbmVlZCB0byB0YWxrIGFib3V0IHRoZSBUeXBlIHR3aWNlLg0KPiANCj4gNjIyICAgICAg MCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAg ICAgMw0KPiA2MjMgICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkg MCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCj4gNjI0ICAgICArLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiA2MjUgICAgIHwg ICAgICBUeXBlICAgICB8ICAgICBMZW5ndGggICAgfCAgICAgRmxhZ3MgICAgIHwgICAgIFJFU0VS VkVEICB8DQo+IDYyNiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gNjI3ICAgICB8ICAgICAgICAgICAgUmFuZ2Ug ICAgICAgICAgICAgIHwgUHJlZml4IExlbmd0aCB8ICAgICBQcmVmaXggICAgfA0KPiA2MjggICAg ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rDQo+IDYyOSAgICAgLy8gICAgICAgICAgICAgICBQcmVmaXggKGNvbnRpbnVlZCwg dmFyaWFibGUpICAgICAgICAgICAgICAgICAgLy8NCj4gNjMwICAgICArLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiA2MzEg ICAgIHwgICAgICAgICAgICAgICAgICAgIFN1YlRMVnMgKHZhcmlhYmxlKSAgICAgICAgICAgICAg ICAgICAgICAgICB8DQo+IDYzMiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gDQo+IDYzNCAgICAgICAgICAgICAg ICAgIEZpZ3VyZSAxOiBTSUQvTGFiZWwgQmluZGluZyBUTFYgZm9ybWF0DQo+IA0KPiA2MzYgICBv ICBUeXBlOiBUQkQsIHN1Z2dlc3RlZCB2YWx1ZSAxNDkNCj4gDQo+IA0KPiAuLi4NCj4gNjU3IDIu NC4xLiAgRmxhZ3MNCj4gLi4uDQo+IDY3MSAgICAgIE0tRmxhZzogTWlycm9yIENvbnRleHQgZmxh Zy4gIFNldCBpZiB0aGUgYWR2ZXJ0aXNlZCBTSUQNCj4gNjcyICAgICAgY29ycmVzcG9uZHMgdG8g YSBtaXJyb3JlZCBjb250ZXh0LiAgVGhlIHVzZSBvZiB0aGUgTSBmbGFnIGlzDQo+IDY3MyAgICAg IGRlc2NyaWJlZCBpbiBbUkZDODQwMl0uDQo+IA0KPiBbbWFqb3JdIFdoZXJlPyAgTm90ZSB0aGF0 IHJmYzg0MDIgc2F5cyB0aGF0ICJUaGUgTWlycm9yIFNJRCBpcyBhZHZlcnRpc2VkDQo+IHVzaW5n IHRoZSBCaW5kaW5nIHNlZ21lbnQgZGVmaW5lZCBpbiBTUiBJR1AgcHJvdG9jb2wgZXh0ZW5zaW9u cw0KPiBbSVNJUy1TUi1FWFRdLiIsIHBvaW50aW5nIGJhY2sgYXQgdGhpcyBkb2N1bWVudC4NCj4g DQo+IFttaW5vcl0gU29tZSBwbGFjZXMgdXNlICotRmxhZyBhbmQgb3RoZXJzICIqIGZsYWciLCBw bGVhc2UgYmUgY29uc2lzdGVudC4NCj4gDQo+IA0KPiA2NzUgICAgICBTLUZsYWc6IElmIHNldCwg dGhlIFNJRC9MYWJlbCBCaW5kaW5nIFRMViBTSE9VTEQgYmUgZmxvb2RlZCBhY3Jvc3MNCj4gNjc2 ICAgICAgdGhlIGVudGlyZSByb3V0aW5nIGRvbWFpbi4gIElmIHRoZSBTIGZsYWcgaXMgbm90IHNl dCwgdGhlIFNJRC8NCj4gNjc3ICAgICAgTGFiZWwgQmluZGluZyBUTFYgTVVTVCBOT1QgYmUgbGVh a2VkIGJldHdlZW4gbGV2ZWxzLiAgVGhpcyBiaXQNCj4gNjc4ICAgICAgTVVTVCBOT1QgYmUgYWx0 ZXJlZCBkdXJpbmcgdGhlIFRMViBsZWFraW5nLg0KPiANCj4gW21ham9yXSBJZiB0aGUgUy1GbGFn IGlzIHNldCwgd2hlbiB3b3VsZCB0aGUgVExWIG5vdCBiZSBmbG9vZGVkIGFjcm9zcyB0aGUNCj4g ZW50aXJlIGRvbWFpbj8gIElPVywgd2h5IGlzIHRoZSBTSE9VTEQgbm90IGEgTVVTVD8NCj4gDQo+ IA0KPiA2ODAgICAgICBELUZsYWc6IHdoZW4gdGhlIFNJRC9MYWJlbCBCaW5kaW5nIFRMViBpcyBs ZWFrZWQgZnJvbSBsZXZlbC0yIHRvDQo+IDY4MSAgICAgIGxldmVsLTEsIHRoZSBEIGJpdCBNVVNU IGJlIHNldC4gIE90aGVyd2lzZSwgdGhpcyBiaXQgTVVTVCBiZQ0KPiA2ODIgICAgICBjbGVhci4g IFNJRC9MYWJlbCBCaW5kaW5nIFRMVnMgd2l0aCB0aGUgRCBiaXQgc2V0IE1VU1QgTk9UIGJlDQo+ IDY4MyAgICAgIGxlYWtlZCBmcm9tIGxldmVsLTEgdG8gbGV2ZWwtMi4gIFRoaXMgaXMgdG8gcHJl dmVudCBUTFYgbG9vcGluZw0KPiA2ODQgICAgICBhY3Jvc3MgbGV2ZWxzLg0KPiANCj4gW21pbm9y XSBXaGF0IGFib3V0IGxlYWtpbmcgZnJvbSBMMiB0byBMMSB3aXRoIHRoZSBGbGFnIHNldD8NCj4g DQo+IFttaW5vcl0gVGhlIHRleHQgdXNlcyBGbGFnLCBidXQgaW4gc29tZSBjYXNlcyBiaXQgaXMg dXNlZCBhcyB3ZWxsLiAgUGxlYXNlDQo+IGJlIGNvbnNpc3RlbnQuDQo+IA0KPiANCj4gLi4uDQo+ IDY5NSAgICAgIEFuIGltcGxlbWVudGF0aW9uIE1BWSBkZWNpZGUgbm90IHRvIGhvbm9yIHRoZSBT LWZsYWcgaW4gb3JkZXIgbm90DQo+IDY5NiAgICAgIHRvIGxlYWsgQmluZGluZyBUTFYncyBiZXR3 ZWVuIGxldmVscyAoZm9yIHBvbGljeSByZWFzb25zKS4gIEluIGFsbA0KPiA2OTcgICAgICBjYXNl cywgdGhlIEQgZmxhZyBNVVNUIGFsd2F5cyBiZSBzZXQgYnkgYW55IHJvdXRlciBsZWFraW5nIHRo ZQ0KPiA2OTggICAgICBCaW5kaW5nIFRMViBmcm9tIGxldmVsLTIgaW50byBsZXZlbC0xIGFuZCBN VVNUIGJlIGNoZWNrZWQgd2hlbg0KPiA2OTkgICAgICBwcm9wYWdhdGluZyB0aGUgQmluZGluZyBU TFYgZnJvbSBsZXZlbC0xIGludG8gbGV2ZWwtMi4gIElmIHRoZSBEDQo+IDcwMCAgICAgIGZsYWcg aXMgc2V0LCB0aGUgQmluZGluZyBUTFYgTVVTVCBOT1QgYmUgcHJvcGFnYXRlZCBpbnRvIGxldmVs LTIuDQo+IA0KPiBbbWFqb3JdIHMvaW1wbGVtZW50YXRpb24gTUFZIGRlY2lkZS9pbXBsZW1lbnRh dGlvbiBtYXkgZGVjaWRlICAgVGhlcmUncw0KPiBubw0KPiBOb3JtYXRpdmUgYWN0aW9uIHRoZXJl Lg0KPiANCj4gW21ham9yXSBSZWdhcmRsZXNzIG9mIHdoZXRoZXIgTUFZL21heSBpcyB1c2VkLCB0 aGUgc3RhdGVtZW50IGluIHRoZSBmaXJzdA0KPiBzZW50ZW5jZSBjb250cmFkaWN0cyB0aGUgIk1V U1QgTk9UIGJlIGxlYWtlZCIgTm9ybWF0aXZlIHN0YXRlbWVudC4NCj4gR2l2ZW4NCj4gdGhhdCB0 aGVyZSBhcmUgZXhjZXB0aW9ucywgbWF5YmUgIlNIT1VMRCBOT1QiIHdvdWxkIGJlIG1vcmUNCj4g YXBwcm9wcmlhdGUuDQo+IA0KPiBbbWFqb3JdIFRoaXMgbGFzdCBwYXJhZ3JhcGggc2VlbXMgdG8g Y29udGFpbiB0aGUgc2FtZSBpbmZvcm1hdGlvbiBhcyB0aGUNCj4gdGV4dCBkZXNjcmliaW5nIHRo ZSBTLUZsYWcuICBQbGVhc2UgZG9uJ3QgZHVwbGljYXRlIHNwZWNpZmljYXRpb25zLg0KPiANCj4g NzAyICAgICAgT3RoZXIgYml0czogTVVTVCBiZSB6ZXJvIHdoZW4gb3JpZ2luYXRlZCBhbmQgaWdu b3JlZCB3aGVuDQo+IDcwMyAgICAgIHJlY2VpdmVkLg0KPiANCj4gW21ham9yXSBEbyB5b3UgZXhw ZWN0IElBTkEgdG8gaGFuZGxlIHRoZSBhc3NpZ25tZW50IG9mIHRob3NlIG90aGVyIGJpdHM/DQo+ IA0KPiA3MDUgMi40LjIuICBSYW5nZQ0KPiANCj4gNzA3ICAgVGhlICdSYW5nZScgZmllbGQgcHJv dmlkZXMgdGhlIGFiaWxpdHkgdG8gc3BlY2lmeSBhIHJhbmdlIG9mDQo+IDcwOCAgIGFkZHJlc3Nl cyBhbmQgdGhlaXIgYXNzb2NpYXRlZCBQcmVmaXggU0lEcy4gIFRoaXMgYWR2ZXJ0aXNlbWVudA0K PiA3MDkgICBzdXBwb3J0cyB0aGUgU1JNUyBmdW5jdGlvbmFsaXR5LiAgSXQgaXMgZXNzZW50aWFs bHkgYSBjb21wcmVzc2lvbg0KPiA3MTAgICBzY2hlbWUgdG8gZGlzdHJpYnV0ZSBhIGNvbnRpbnVv dXMgUHJlZml4IGFuZCB0aGVpciBjb250aW51b3VzLA0KPiA3MTEgICBjb3JyZXNwb25kaW5nIFNJ RC9MYWJlbCBCbG9jay4gIElmIGEgc2luZ2xlIFNJRCBpcyBhZHZlcnRpc2VkIHRoZW4NCj4gNzEy ICAgdGhlIHJhbmdlIGZpZWxkIE1VU1QgYmUgc2V0IHRvIG9uZS4gIEZvciByYW5nZSBhZHZlcnRp c2VtZW50cyA+IDEsDQo+IDcxMyAgIHRoZSBudW1iZXIgb2YgYWRkcmVzc2VzIHRoYXQgbmVlZCB0 byBiZSBtYXBwZWQgaW50byBhIFByZWZpeC1TSUQgYW5kDQo+IDcxNCAgIHRoZSBzdGFydGluZyB2 YWx1ZSBvZiB0aGUgUHJlZml4LVNJRCByYW5nZS4NCj4gDQo+IFtuaXRdIFRoZSBsYXN0IHNlbnRl bmNlIHNvdW5kcyBpbmNvbXBsZXRlLi4uDQo+IA0KPiA3MTYgICBFeGFtcGxlIDE6IGlmIHRoZSBm b2xsb3dpbmcgcm91dGVyIGFkZHJlc3NlcyAobG9vcGJhY2sgYWRkcmVzc2VzKQ0KPiA3MTcgICBu ZWVkIHRvIGJlIG1hcHBlZCBpbnRvIHRoZSBjb3JyZXNwb25kaW5nIFByZWZpeCBTSUQgaW5kZXhl cy4NCj4gDQo+IFttaW5vcl0gU3VnZ2VzdGlvbjogbW92ZSB0aGUgZXhhbXBsZXMgdG8gdGhlIGVu ZCBvZiDCpzIuNC4uLmFmdGVyIGFsbCB0aGUNCj4gZmllbGRzIGhhdmUgYmVlbiBkaXNjdXNzZWQu DQo+IA0KPiA3MTkgICBSb3V0ZXItQTogMTkyLjAuMi4xLzMyLCBQcmVmaXgtU0lEOiBJbmRleCAx DQo+IDcyMCAgIFJvdXRlci1COiAxOTIuMC4yLjIvMzIsIFByZWZpeC1TSUQ6IEluZGV4IDINCj4g NzIxICAgUm91dGVyLUM6IDE5Mi4wLjIuMy8zMiwgUHJlZml4LVNJRDogSW5kZXggMw0KPiA3MjIg ICBSb3V0ZXItRDogMTkyLjAuMi40LzMyLCBQcmVmaXgtU0lEOiBJbmRleCA0DQo+IA0KPiA3MjQg ICAgICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAg ICAgICAgICAzDQo+IDcyNSAgICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3 IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KPiA3MjYgICAgICstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+IDcyNyAg ICAgfCAgICAgIFR5cGUgICAgIHwgICAgIExlbmd0aCAgICB8MHwwfCAgICAgICAgICAgfCAgICAg UkVTRVJWRUQgIHwNCj4gNzI4ICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiA3MjkgICAgIHwgICAgICAgICAgICBS YW5nZSA9IDQgICAgICAgICAgfCAgICAgICAvMzIgICAgIHwgICAgICAxOTIgICAgICB8DQo+IDcz MCAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSsNCj4gNzMxICAgICB8ICAgICAgIC4wICAgICAgfCAgICAgICAgLjIgICAg IHwgICAgICAgLjEgICAgICB8UHJlZml4LVNJRCBUeXBlfA0KPiA3MzIgICAgICstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+ IDczMyAgICAgfCBzdWItVExWIExlbmd0aHwgICAgIEZsYWdzICAgICB8ICAgQWxnb3JpdGhtICAg fCAgICAgICAgICAgICAgIHwNCj4gNzM0ICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiA3MzUgICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAxIHwNCj4gNzM2ICAgICArLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+IA0KPiBbbml0 XSBUaGUgUHJlZml4IExlbmd0aCBzaG91bGQgYmUgIjMyIiwgbm90ICIvMzIiLg0KPiANCj4gW25p dF0gVGhlIFByZWZpeCBpdHNlbGYgaXMgb25lIGZpZWxkIChpbiB0aGUgZGVzY3JpcHRpb24pLCBi dXQgaXQgbG9va3MNCj4gbGlrZSA0IHNlcGFyYXRlIGZpZWxkcyBhYm92ZS4uLmFuZCB0aGUgbnVt YmVycyBzaG91bGQgbm90IGhhdmUgIi4iIGluIHRoZW0uDQo+IA0KPiBbbWlub3JdIEl0IGxvb2tz IGxpa2UgdGhlIGZpZWxkcyBzdGFydGluZyB3aXRoICJQcmVmaXgtU0lEIFR5cGUiIGJlbG9uZyB0 bw0KPiB0aGUgUHJlZml4LVNJRCBTdWItVExWLCBidXQgdGhhdCBpcyBub3QgZXhwbGFpbmVkIGFu eXdoZXJlICh5ZXQpLiAgVGhlDQo+IEFsZ29yaXRobSBmaWVsZCBpcyBub3Qgc2V0Li4ubm9yIGFy ZSB0aGUgRmxhZ3MuDQo+IA0KPiA3MzggICBFeGFtcGxlLTI6IElmIHRoZSBmb2xsb3dpbmcgcHJl Zml4ZXMgbmVlZCB0byBiZSBtYXBwZWQgaW50byB0aGUNCj4gNzM5ICAgY29ycmVzcG9uZGluZyBQ cmVmaXgtU0lEIGluZGV4ZXM6DQo+IA0KPiA3NDEgICAxMC4xLjEvMjQsIFByZWZpeC1TSUQ6IElu ZGV4IDUxDQo+IDc0MiAgIDEwLjEuMi8yNCwgUHJlZml4LVNJRDogSW5kZXggNTINCj4gNzQzICAg MTAuMS4zLzI0LCBQcmVmaXgtU0lEOiBJbmRleCA1Mw0KPiA3NDQgICAxMC4xLjQvMjQsIFByZWZp eC1TSUQ6IEluZGV4IDU0DQo+IDc0NSAgIDEwLjEuNS8yNCwgUHJlZml4LVNJRDogSW5kZXggNTUN Cj4gNzQ2ICAgMTAuMS42LzI0LCBQcmVmaXgtU0lEOiBJbmRleCA1Ng0KPiA3NDcgICAxMC4xLjcv MjQsIFByZWZpeC1TSUQ6IEluZGV4IDU3DQo+IA0KPiBbbWFqb3JdIFBsZWFzZSB1c2UgYWRkcmVz c2VzIGluIHRoZSByZmM1NzM3IHJlc2VydmVkIHJhbmdlcy4NCj4gDQo+IFttaW5vcl0gSXQgd291 bGQgaGF2ZSBiZWVuIG5pY2UgdG8gc2VlIGFuIElQdjYgZXhhbXBsZSAoc2VlIHJmYzM4NDkpLg0K PiANCj4gNzQ5ICAgICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIg ICAgICAgICAgICAgICAgICAgMw0KPiA3NTAgICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAy IDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCj4gNzUxICAgICArLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Kw0KPiA3NTIgICAgIHwgICAgICBUeXBlICAgICB8ICAgICBMZW5ndGggICAgfDB8MHwgICAgICAg ICAgIHwgICAgIFJFU0VSVkVEICB8DQo+IDc1MyAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gNzU0ICAgICB8ICAg ICAgICAgICAgUmFuZ2UgPSA3ICAgICAgICAgIHwgICAgICAgLzI0ICAgICB8ICAgICAgMTAgICAg ICAgfA0KPiA3NTUgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+IDc1NiAgICAgfCAgICAgICAuMSAgICAgIHwgICAg ICAgIC4xICAgICB8UHJlZml4LVNJRCBUeXBlfCBzdWItVExWIExlbmd0aHwNCj4gNzU3ICAgICAr LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKw0KPiA3NTggICAgIHwgICAgRmxhZ3MgICAgICB8IEFsZ29yaXRobSAgICAgfCAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+IDc1OSAgICAgKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gNzYwICAg ICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgNTEgIHwNCj4gNzYxICAgICArLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gDQo+IFtdIFNhbWUgY29tbWVudHMgYXMgYWJvdmUu DQo+IA0KPiANCj4gLi4uDQo+IDc3OCAyLjQuMy4gIFByZWZpeCBMZW5ndGgsIFByZWZpeA0KPiAu Li4NCj4gNzg0ICAgVGhlICdQcmVmaXggTGVuZ3RoJyBmaWVsZCBjb250YWlucyB0aGUgbGVuZ3Ro IG9mIHRoZSBwcmVmaXggaW4gYml0cy4NCj4gNzg1ICAgT25seSB0aGUgbW9zdCBzaWduaWZpY2Fu dCBvY3RldHMgb2YgdGhlIFByZWZpeCBhcmUgZW5jb2RlZC4gIChpLmUuLCAxDQo+IDc4NiAgIG9j dGV0IGZvciBwcmVmaXggbGVuZ3RoIDEgdXAgdG8gOCwgMiBvY3RldHMgZm9yIHByZWZpeCBsZW5n dGggOSB0bw0KPiA3ODcgICAxNiwgMyBvY3RldHMgZm9yIHByZWZpeCBsZW5ndGggMTcgdXAgdG8g MjQgYW5kIDQgb2N0ZXRzIGZvciBwcmVmaXgNCj4gNzg4ICAgbGVuZ3RoIDI1IHVwIHRvIDMyLCAu Li4uLCAxNiBvY3RldHMgZm9yIHByZWZpeCBsZW5ndGggMTEzIHVwIHRvIDEyOCkuDQo+IA0KPiBb bml0XSBzL2VuY29kZWQuICAoaS5lLiwvZW5jb2RlZCAoaS5lLiwNCj4gDQo+IA0KPiA3OTAgMi40 LjQuICBNYXBwaW5nIFNlcnZlciBQcmVmaXgtU0lEDQo+IA0KPiA3OTIgICBUaGUgUHJlZml4LVNJ RCBzdWItVExWIChzdWdnZXN0ZWQgdmFsdWUgMykgaXMgZGVmaW5lZCBpbiBTZWN0aW9uIDIuMQ0K PiA3OTMgICBhbmQgY29udGFpbnMgdGhlIFNJRC9pbmRleC9sYWJlbCB2YWx1ZSBhc3NvY2lhdGVk IHdpdGggdGhlIHByZWZpeCBhbmQNCj4gNzk0ICAgcmFuZ2UuICBUaGUgUHJlZml4LVNJRCBTdWJU TFYgTVVTVCBiZSBwcmVzZW50IGluIHRoZSBTSUQvTGFiZWwNCj4gNzk1ICAgQmluZGluZyBUTFYg dW5sZXNzIHRoZSBNLWZsYWcgaXMgc2V0IGluIHRoZSBGbGFncyBmaWVsZCBvZiB0aGUgcGFyZW50 DQo+IDc5NiAgIFRMVi4NCj4gDQo+IFttYWpvcl0gRG9lcyBpdCB0aGVuIG1lYW4gdGhhdCB0aGUg UHJlZml4LVNJRCBTdWJUTFYgbXVzdCBub3QgYmUgcHJlc2VudCBpZg0KPiB0aGUgTS1GbGFnIGlz IG5vdCBzZXQ/DQo+IA0KPiBbbml0XSBzL1N1YlRMVi9TdWItVExWIChhcyBpdCBpcyB1c2VkIGFs bW9zdCBldmVyeXdoZXJlIGVsc2UpDQo+IA0KPiANCj4gNzk4ICAgQSBub2RlIHJlY2VpdmluZyBh biBTUk1TIGVudHJ5IGZvciBhIHByZWZpeCBNVVNUIGNoZWNrIHRoZSBleGlzdGVuY2UNCj4gNzk5 ICAgb2Ygc3VjaCBwcmVmaXggaW4gaXRzIGxpbmstc3RhdGUgZGF0YWJhc2UgcHJpb3IgdG8gY29u c2lkZXIgYW5kIHVzZQ0KPiA4MDAgICB0aGUgYXNzb2NpYXRlZCBTSUQuDQo+IA0KPiBbbWFqb3Jd IFdoYXQgZG9lcyBpdCBtZWFuIGZvciB0aGUgcHJlZml4IHRvIGV4aXN0IGluIHRoZSBsaW5rLXN0 YXRlDQo+IGRhdGFiYXNlPyAgRG9lcyBpdCBtZWFuIHRoYXQgaXQgbXVzdCBoYXZlIGJlZW4gYWR2 ZXJ0aXNlZCBpbiBhICJub3JtYWwiDQo+IHJvdXRpbmcgVExWLCBvciBzb21ldGhpbmcgZWxzZT8g IEkgYXNrIG5vdCBvbmx5IHRvIGNsYXJpZnksIGJ1dCBiZWNhdXNlDQo+IMKnMi40LjMgc2F5cyB0 aGF0IHRoZSAiJ1ByZWZpeCcgZG9lcyBub3QgbmVlZCB0byBjb3JyZXNwb25kIHRvIGEgcm91dGFi bGUNCj4gcHJlZml4IG9mIHRoZSBvcmlnaW5hdGluZyBub2RlIi4NCj4gDQo+IFtBaC4uLkkgdGhp bmsgSSB1bmRlcnN0YW5kLiAgQmVjYXVzZSAidGhlIG1hcHBpbmcgc2VydmVyIGRvZXMgbm90IHNw ZWNpZnkNCj4gdGhlIG9yaWdpbmF0b3Igb2YgYSBwcmVmaXgiICjCpzIuNC40LjIpLCB0aGVuIHRo ZSBwcmVmaXggaXMgb2J2aW91c2x5IG5vdA0KPiByb3V0YWJsZSBpbiB0aGUgY29udGV4dCBvZiB0 aGUgb3JpZ2luYXRpbmcgbm9kZSAodGhlIHNlcnZlcikuLi5idXQgaXQNCj4gc2hvdWxkIGJlIHJv dXRhYmxlIGluIGdlbmVyYWwuICBJcyB0aGF0IGl0P10NCj4gDQo+IA0KPiA4MDIgMi40LjQuMS4g IFByZWZpeC1TSUQgRmxhZ3MNCj4gDQo+IDgwNCAgIFRoZSBQcmVmaXgtU0lEIGZsYWdzIGFyZSBk ZWZpbmVkIGluIFNlY3Rpb24gMi4xLiAgVGhlIE1hcHBpbmcgU2VydmVyDQo+IDgwNSAgIE1BWSBh ZHZlcnRpc2UgYSBtYXBwaW5nIHdpdGggdGhlIE4gZmxhZyBzZXQgd2hlbiB0aGUgcHJlZml4IGJl aW5nDQo+IDgwNiAgIG1hcHBlZCBpcyBrbm93biBpbiB0aGUgbGluay1zdGF0ZSB0b3BvbG9neSB3 aXRoIGEgbWFzayBsZW5ndGggb2YgMzINCj4gODA3ICAgKElQdjQpIG9yIDEyOCAoSVB2NikgYW5k IHdoZW4gdGhlIHByZWZpeCByZXByZXNlbnRzIGEgbm9kZS4gIFRoZQ0KPiA4MDggICBtZWNoYW5p c21zIHRocm91Z2ggd2hpY2ggdGhlIG9wZXJhdG9yIGRlZmluZXMgdGhhdCBhIHByZWZpeA0KPiA4 MDkgICByZXByZXNlbnRzIGEgbm9kZSBhcmUgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1 bWVudCAodHlwaWNhbGx5DQo+IDgxMCAgIGl0IHdpbGwgYmUgdGhyb3VnaCBjb25maWd1cmF0aW9u KS4NCj4gDQo+IFttYWpvcl0gwqcyLjEuMS4yIHNheXMgdGhhdCB0aGUgInJvdXRlciBNQVkgc2V0 IHRoZSBOLUZsYWcgb25seSBpZi4uLiB0aGUNCj4gcHJlZml4IHRvIHdoaWNoIHRoZSBQcmVmaXgt U0lEIGlzIGF0dGFjaGVkIE1VU1QgaGF2ZSBhIFByZWZpeCBsZW5ndGggb2YNCj4gZWl0aGVyIC8z MiAoSVB2NCkgb3IgLzEyOCAoSVB2NikuIiAgVGhhdCBpcyBzaW1pbGFyIHRvIHdoYXQgdGhlIHRl eHQgYWJvdmUNCj4gc2F5cyAoYnV0IHRoZSB0ZXh0IHRhbGtzIGFib3V0ICJ0aGUgcHJlZml4Li4u a25vd24gaW4gdGhlIGxpbmstc3RhdGUNCj4gdG9wb2xvZ3kiKSwgYW5kIGl0IGlzIHJlbGF0ZWQg dG8gdGhlIGxhc3QgcXVlc3Rpb24gaW4gdGhlIHByZXZpb3VzDQo+IHNlY3Rpb24uICBEb2VzIHRo ZSBwcmVmaXggYmVpbmcgaW4gdGhlIGxpbmstc3RhdGUgZGF0YWJhc2UvdG9wb2xvZ3kgbWVhbg0K PiB0aGF0IHRoZSBtYXRjaCBpcyBleGFjdCAodG8gdGhlIHByZWZpeCBhZHZlcnRpc2VkKSwgb3Ig aXMgYSBzdXBlcm5ldCBvaz8NCj4gDQo+IA0KPiA4MTIgICBUaGUgb3RoZXIgZmxhZ3MgZGVmaW5l ZCBpbiBTZWN0aW9uIDIuMSBhcmUgbm90IHVzZWQgYnkgdGhlIE1hcHBpbmcNCj4gODEzICAgU2Vy dmVyIGFuZCBNVVNUIGJlIGlnbm9yZWQgYXQgcmVjZXB0aW9uLg0KPiANCj4gW21ham9yXSBIb3cg ZG9lcyB0aGUgcmVjZWl2ZXIga25vdyB0aGF0IHRoZSBzdWItVExWIHdhcyBvcmlnaW5hdGVkIGJ5 IGENCj4gTWFwcGluZyBTZXJ2ZXI/ICBJcyBpdCB0aGUgY2FzZSB0aGF0IGl0IHdvdWxkIG9yaWdp bmF0ZSBhIEJpbmRpbmcgVExWPw0KPiBJT1csIHdvdWxkIHRoZSBvdGhlciBmbGFncyBhbHdheXMg YmUgaWdub3JlZCB3aGVuIHRoZSBzdWItVExWIGlzIGluY2x1ZGVkDQo+IGluIHRoZSBCaW5kaW5n IFRMViAoYnV0IG5vdCBvdGhlciBUTFZzKT8gICBEb2VzIHRoaXMgYXBwbHkgYWxzbyB0byB0aGUN Cj4gTXVsdGktVG9wb2xvZ3kgU0lEL0xhYmVsIEJpbmRpbmcgVExWICjCpzIuNSk/DQo+IA0KPiAN Cj4gODE1IDIuNC40LjIuICBQSFAgQmVoYXZpb3Igd2hlbiB1c2luZyBNYXBwaW5nIFNlcnZlciBB ZHZlcnRpc2VtZW50cw0KPiAuLi4NCj4gODIzICAgbyAgQSBwcmVmaXggcmVhY2hhYmlsaXR5IGFk dmVydGlzZW1lbnQgZm9yIHRoZSBwcmVmaXggaGFzIGJlZW4NCj4gODI0ICAgICAgcmVjZWl2ZWQg d2hpY2ggaW5jbHVkZXMgdGhlIEV4dGVuZGVkIFJlYWNoYWJpbGl0eSBBdHRyaWJ1dGUgRmxhZ3MN Cj4gODI1ICAgICAgc3ViLVRMViAoW1JGQzc3OTRdKS4NCj4gDQo+IFtuaXRdIHMvKFtSRkM3Nzk0 XSkvW1JGQzc3OTRdDQo+IA0KPiA4MjcgICBvICBYIGFuZCBSIGZsYWdzIGFyZSBib3RoIHNldCB0 byAwIGluIHRoZSBFeHRlbmRlZCBSZWFjaGFiaWxpdHkNCj4gODI4ICAgICAgQXR0cmlidXRlIEZs YWdzIHN1Yi1UTFYuDQo+IA0KPiA4MzAgICBJbiB0aGUgYWJzZW5jZSBvZiBhbiBFeHRlbmRlZCBS ZWFjaGFiaWxpdHkgQXR0cmlidXRlIEZsYWdzIHN1Yi1UTFYNCj4gODMxICAgKFtSRkM3Nzk0XSkg dGhlIEEgZmxhZyBpbiB0aGUgYmluZGluZyBUTFYgaW5kaWNhdGVzIHRoYXQgdGhlDQo+IDgzMiAg IG9yaWdpbmF0b3Igb2YgYSBwcmVmaXggcmVhY2hhYmlsaXR5IGFkdmVydGlzZW1lbnQgaXMgZGly ZWN0bHkNCj4gODMzICAgY29ubmVjdGVkIHRvIHRoZSBwcmVmaXggYW5kIHRodXMgUEhQIE1VU1Qg YmUgZG9uZSBieSB0aGUgbmVpZ2hib3JzDQo+IG9mDQo+IDgzNCAgIHRoZSByb3V0ZXIgb3JpZ2lu YXRpbmcgdGhlIHByZWZpeCByZWFjaGFiaWxpdHkgYWR2ZXJ0aXNlbWVudC4gIE5vdGUNCj4gODM1 ICAgdGhhdCBBLWZsYWcgaXMgb25seSB2YWxpZCBpbiB0aGUgb3JpZ2luYWwgYXJlYSBpbiB3aGlj aCB0aGUgQmluZGluZw0KPiA4MzYgICBUTFYgaXMgYWR2ZXJ0aXNlZC4NCj4gDQo+IFtuaXRdIHMv KFtSRkM3Nzk0XSkvW1JGQzc3OTRdDQo+IA0KPiBbbWFqb3JdIMKnMi40LjEgc2F5cyB0aGF0ICJp ZiB0aGUgQmluZGluZyBUTFYgaXMgbGVha2VkLi4udGhlIEEtZmxhZyBNVVNUIGJlDQo+IGNsZWFy ZWQiLCB3aGljaCBpcyBub3QgdGhlIHNhbWUgYXMgbm90IGNvbnNpZGVyaW5nIGl0IHZhbGlkIChp Z25vcmluZywgYXMNCj4gZGVzY3JpYmVkIGFib3ZlKS4gIEluIGFueSBjYXNlLCBwbGVhc2UgYmUg c3BlY2lmaWMgYWJvdXQgdGhlIGZ1bmN0aW9uYWxpdHkNCj4gaW4gdGhlIGRlc2NyaXB0aW9uLg0K PiANCj4gDQo+IDgzOCAyLjQuNC4zLiAgUHJlZml4LVNJRCBBbGdvcml0aG0NCj4gDQo+IDg0MCAg IFRoZSBhbGdvcml0aG0gZmllbGQgY29udGFpbnMgdGhlIGlkZW50aWZpZXIgb2YgdGhlIGFsZ29y aXRobSB0aGUNCj4gODQxICAgcm91dGVyIE1VU1QgdXNlIGluIG9yZGVyIHRvIGNvbXB1dGUgcmVh Y2hhYmlsaXR5IHRvIHRoZSByYW5nZSBvZg0KPiA4NDIgICBwcmVmaXhlcy4gIFVzZSBvZiB0aGUg YWxnb3JpdGhtIGZpZWxkIGlzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDIuMS4NCj4gDQo+IFttYWpv ciBuaXRdIEF0IGZpcnN0IGdsYW5jZSwgaXQgbG9va3MgbGlrZSB0aGlzIHNlY3Rpb24gaXMgbm90 IG5lZWRlZA0KPiBiZWNhdXNlIGl0IHJlcGVhdHMgd2hhdCDCpzIuMSBhbHJlYWR5IHNheXMgYWJv dXQgdGhlIGFsZ29yaXRobS4gIEJ1dCB0aGlzDQo+IHBhcmFncmFwaCByZWZlcnMgdG8gInRoZSBh bGdvcml0aG0gdGhlIHJvdXRlciBNVVNUIHVzZSBpbiBvcmRlciB0byBjb21wdXRlDQo+IHJlYWNo YWJpbGl0eSIsIGluIGNvbnRyYXN0IHRvIHRoZSBkZWZpbml0aW9uIG9mIHRoZSBmaWVsZCBpbiDC pzIuMTogIlRoZQ0KPiBhbGdvcml0aG0gZmllbGQuLi5jb250YWlucyB0aGUgaWRlbnRpZmllciBv ZiB0aGUgYWxnb3JpdGhtIHRoZSByb3V0ZXIgaGFzDQo+IHVzZWQgaW4gb3JkZXIgdG8gY29tcHV0 ZSB0aGUgcmVhY2hhYmlsaXR5Li4uIg0KPiANCj4gDQo+IC4uLg0KPiA5MDEgMy4xLiAgU1ItQ2Fw YWJpbGl0aWVzIFN1Yi1UTFYNCj4gLi4uDQo+IDkwOSAgIFRoZSBSb3V0ZXIgQ2FwYWJpbGl0eSBU TFYgc3BlY2lmaWVzIGZsYWdzIHRoYXQgY29udHJvbCBpdHMNCj4gOTEwICAgYWR2ZXJ0aXNlbWVu dC4gIFRoZSBTUiBDYXBhYmlsaXRpZXMgc3ViLVRMViBNVVNUIGJlIHByb3BhZ2F0ZWQNCj4gOTEx ICAgdGhyb3VnaG91dCB0aGUgbGV2ZWwgYW5kIE1VU1QgTk9UIGJlIGFkdmVydGlzZWQgYWNyb3Nz IGxldmVsDQo+IDkxMiAgIGJvdW5kYXJpZXMuICBUaGVyZWZvcmUgUm91dGVyIENhcGFiaWxpdHkg VExWIGRpc3RyaWJ1dGlvbiBmbGFncyBhcmUNCj4gOTEzICAgc2V0IGFjY29yZGluZ2x5LCBpLmUu LCB0aGUgUyBmbGFnIGluIHRoZSBSb3V0ZXIgQ2FwYWJpbGl0eSBUTFYNCj4gOTE0ICAgKFtSRkM3 OTgxXSkgTVVTVCBiZSB1bnNldC4NCj4gDQo+IFtuaXRdIHMvKFtSRkM3OTgxXSkvW1JGQzc5ODFd DQo+IA0KPiANCj4gLi4uDQo+IDk0MyAgICAgICAgIEktRmxhZzogTVBMUyBJUHY0IGZsYWcuICBJ ZiBzZXQsIHRoZW4gdGhlIHJvdXRlciBpcyBjYXBhYmxlIG9mDQo+IDk0NCAgICAgICAgIHByb2Nl c3NpbmcgU1IgTVBMUyBlbmNhcHN1bGF0ZWQgSVB2NCBwYWNrZXRzIG9uIGFsbCBpbnRlcmZhY2Vz Lg0KPiANCj4gOTQ2ICAgICAgICAgVi1GbGFnOiBNUExTIElQdjYgZmxhZy4gIElmIHNldCwgdGhl biB0aGUgcm91dGVyIGlzIGNhcGFibGUgb2YNCj4gOTQ3ICAgICAgICAgcHJvY2Vzc2luZyBTUiBN UExTIGVuY2Fwc3VsYXRlZCBJUHY2IHBhY2tldHMgb24gYWxsIGludGVyZmFjZXMuDQo+IA0KPiBb bWlub3JdIEp1c3QgY3VyaW91czogSG93IGFyZSB0aGVzZSBmbGFncyB1c2VkPyAgR2l2ZW4gdGhh dCB0aGUgZGF0YSBwbGFuZQ0KPiB3ZSdyZSBkZWFsaW5nIHdpdGggaXMgTVBMUy4uLg0KPiANCj4g DQo+IC4uLg0KPiA5ODEgICBUaGUgb3JpZ2luYXRpbmcgcm91dGVyIE1VU1QgZW5zdXJlIHRoZSBv cmRlciBpcyBzYW1lIGFmdGVyIGEgZ3JhY2VmdWwNCj4gOTgyICAgcmVzdGFydCAodXNpbmcgY2hl Y2twb2ludGluZywgbm9uLXZvbGF0aWxlIHN0b3JhZ2Ugb3IgYW55IG90aGVyDQo+IDk4MyAgIG1l Y2hhbmlzbSkgaW4gb3JkZXIgdG8gZ3VhcmFudGVlIHRoZSBzYW1lIG9yZGVyIGJlZm9yZSBhbmQg YWZ0ZXIgR1IuDQo+IA0KPiBbbml0XSBzL29yZGVyIGlzIHNhbWUvb3JkZXIgaXMgdGhlIHNhbWUN Cj4gDQo+IA0KPiAuLi4NCj4gMTAxNSAzLjIuICBTUi1BbGdvcml0aG0gU3ViLVRMVg0KPiAuLi4N Cj4gMTA0NiAgIFRoZSBTUi1BbGdvcml0aG0gc3ViLVRMViBpcyBvcHRpb25hbCwgaXQgTUFZIG9u bHkgYXBwZWFyIGEgc2luZ2xlDQo+IDEwNDcgICB0aW1lIGluc2lkZSB0aGUgUm91dGVyIENhcGFi aWxpdHkgVExWLg0KPiANCj4gW21ham9yXSAiTUFZIG9ubHkgYXBwZWFyIGEgc2luZ2xlIHRpbWUi IG1lYW5zIHRoYXQgaXQgY2FuIGFwcGVhciBtb3JlIHRoYW4NCj4gb25jZS4gIElmIGl0IGRvZXMg c2hvdyB1cCBtb3JlIHRoYW4gb25jZSwgd2hhdCBzaG91bGQgdGhlIHRoZSByZWNlaXZlciBkbz8N Cj4gDQo+IA0KPiAxMDQ5ICAgV2hlbiB0aGUgb3JpZ2luYXRpbmcgcm91dGVyIGRvZXMgbm90IGFk dmVydGlzZSB0aGUgU1ItQWxnb3JpdGhtIHN1Yi0NCj4gMTA1MCAgIFRMViwgdGhlbiBhbGwgdGhl IFByZWZpeC1TSURzIGFkdmVydGlzZWQgYnkgdGhlIHJvdXRlciBNVVNUIGhhdmUNCj4gMTA1MSAg IGFsZ29yaXRobSBmaWVsZCBzZXQgdG8gMC4gIEFueSByZWNlaXZpbmcgcm91dGVyIE1VU1QgYXNz dW1lIFNQRg0KPiAxMDUyICAgYWxnb3JpdGhtIChpLmUuLCBTaG9ydGVzdCBQYXRoIEZpcnN0KS4N Cj4gDQo+IFttaW5vcl0gSXQgc2VlbXMgdG8gbWUgdGhhdCB0aGlzIHBhcnQgb2YgdGhlIHNwZWNp ZmljYXRpb24gd291bGQgZml0IGJldHRlcg0KPiBpbiDCpzIuMS4NCj4gDQo+IFttYWpvcl0gQmVz aWRlcyBtYXliZSBiZWluZyByZWR1bmRhbnQsIHdoYXQgaXMgc3BlY2lmaWVkIGluIHRoZSBsYXN0 DQo+IHNlbnRlbmNlPyAgSWYgdGhlIGluZGljYXRpb24gb2YgdGhlIGFsZ29yaXRobSBpcyBleHBs aWNpdCwgdGhlbiBJIGRvbid0DQo+IHVuZGVyc3RhbmQgd2hhdCAiTVVTVCBhc3N1bWUiIGlzIHRy eWluZyB0byBtYW5kYXRlLg0KPiANCj4gDQo+IDEwNTQgICBXaGVuIHRoZSBvcmlnaW5hdGluZyBy b3V0ZXIgZG9lcyBhZHZlcnRpc2UgdGhlIFNSLUFsZ29yaXRobSBzdWItVExWLA0KPiAxMDU1ICAg dGhlbiBhbGdvcml0aG0gMCBNVVNUIGJlIHByZXNlbnQgd2hpbGUgYWxnb3JpdGhtIDEgTUFZIGJl IHByZXNlbnQuDQo+IA0KPiBbbml0XSBJIHRoaW5rIHRoYXQgaXQgaXMgY2xlYXIgdGhhdCBhbGdv cml0aG0gMSBpcyBvcHRpb25hbC4gIEkgd291bGQgdGFrZQ0KPiB0aGF0IGxhc3QgcGFydCBvdXQg anVzdCBiZWNhdXNlIG90aGVyIGFsZ29yaXRobXMgbWF5IGJlIGRlZmluZWQgaW4gdGhlDQo+IGZ1 dHVyZS4uLmFuZCB0aGUgaW1wb3J0YW50IHBhcnQgYXQgdGhpcyBwb2ludCBpcyB0aGUgaW5jbHVz aW9uIG9mIGFsZ29yaXRobQ0KPiAwLg0KPiANCj4gDQo+IDEwNTcgICBUaGUgU1ItQWxnb3JpdGht IHN1Yi1UTFYgaGFzIGZvbGxvd2luZyBmb3JtYXQ6DQo+IA0KPiBbbml0XSBzL2hhcyBmb2xsb3dp bmcvaGFzIHRoZSBmb2xsb3dpbmcNCj4gDQo+IA0KPiAuLi4NCj4gMTA3MyAgICAgIEFsZ29yaXRo bTogMSBvY3RldCBvZiBhbGdvcml0aG0gU2VjdGlvbiAyLjENCj4gDQo+IFttaW5vcl0gVGhlIEFs Z29yaXRobSBmaWVsZCBpcyBkZXNjcmliZWQgaW4gdGhpcyBzZWN0aW9uLCBub3QgaW4gMi4xLg0K PiANCj4gDQo+IDEwNzUgMy4zLiAgU1IgTG9jYWwgQmxvY2sgU3ViLVRMVg0KPiANCj4gMTA3NyAg IFRoZSBTUiBMb2NhbCBCbG9jayAoU1JMQikgU3ViLVRMViBjb250YWlucyB0aGUgcmFuZ2Ugb2Yg bGFiZWxzIHRoZQ0KPiAxMDc4ICAgbm9kZSBoYXMgcmVzZXJ2ZWQgZm9yIGxvY2FsIFNJRHMuICBM b2NhbCBTSURzIGFyZSB1c2VkLCBlLmcuLCBmb3INCj4gMTA3OSAgIEFkamFjZW5jeS1TSURzLCBh bmQgbWF5IGFsc28gYmUgYWxsb2NhdGVkIGJ5IG90aGVyIGNvbXBvbmVudHMgdGhhbg0KPiAxMDgw ICAgSVMtSVMgcHJvdG9jb2wuICBBcyBhbiBleGFtcGxlLCBhbiBhcHBsaWNhdGlvbiBvciBhIGNv bnRyb2xsZXIgbWF5DQo+IDEwODEgICBpbnN0cnVjdCB0aGUgcm91dGVyIHRvIGFsbG9jYXRlIGEg c3BlY2lmaWMgbG9jYWwgU0lELiAgVGhlcmVmb3JlLCBpbg0KPiAxMDgyICAgb3JkZXIgZm9yIHN1 Y2ggYXBwbGljYXRpb25zIG9yIGNvbnRyb2xsZXJzIHRvIGtub3cgd2hhdCBhcmUgdGhlIGxvY2Fs DQo+IDEwODMgICBTSURzIGF2YWlsYWJsZSBpbiB0aGUgcm91dGVyLCBpdCBpcyByZXF1aXJlZCB0 aGF0IHRoZSByb3V0ZXINCj4gMTA4NCAgIGFkdmVydGlzZXMgaXRzIFNSTEIuDQo+IA0KPiBbbml0 XSBzL3RoYW4gSVMtSVMgcHJvdG9jb2wvdGhhbiB0aGUgSVMtSVMgcHJvdG9jb2wNCj4gDQo+IA0K PiAuLi4NCj4gMTEyMiAgIFRoZSBvcmlnaW5hdGluZyByb3V0ZXIgTVVTVCBOT1QgYWR2ZXJ0aXNl IG92ZXJsYXBwaW5nIHJhbmdlcy4NCj4gDQo+IFttYWpvcl0gV2hhdCBzaG91bGQgdGhlIHJlY2Vp dmVyIGRvIGlmIHRoZSByYW5nZXMgb3ZlcmxhcD8gIEknbSBhc3N1bWluZw0KPiB0aGUgc2FtZSB0 aGluZyBhcyB3aGF0IHdhcyBzcGVjaWZpZWQgYmVmb3JlLi4ucGxlYXNlIGJlIHNwZWNpZmljLg0K PiANCj4gDQo+IDExMjQgICBJdCBpcyBpbXBvcnRhbnQgdG8gbm90ZSB0aGF0IGVhY2ggdGltZSBh IFNJRCBmcm9tIHRoZSBTUkxCIGlzDQo+IDExMjUgICBhbGxvY2F0ZWQsIGl0IFNIT1VMRCBhbHNv IGJlIHJlcG9ydGVkIHRvIGFsbCBjb21wb25lbnRzIChlLmcuOg0KPiAxMTI2ICAgY29udHJvbGxl ciBvciBhcHBsaWNhdGlvbnMpIGluIG9yZGVyIGZvciB0aGVzZSBjb21wb25lbnRzIHRvIGhhdmUg YW4NCj4gMTEyNyAgIHVwLXRvLWRhdGUgdmlldyBvZiB0aGUgY3VycmVudCBTUkxCIGFsbG9jYXRp b24gYW5kIGluIG9yZGVyIHRvIGF2b2lkDQo+IDExMjggICBjb2xsaXNpb24gYmV0d2VlbiBhbGxv Y2F0aW9uIGluc3RydWN0aW9ucy4NCj4gDQo+IDExMzAgICBXaXRoaW4gdGhlIGNvbnRleHQgb2Yg SVMtSVMsIHRoZSByZXBvcnRpbmcgb2YgbG9jYWwgU0lEcyBpcyBkb25lDQo+IDExMzEgICB0aHJv dWdoIElTLUlTIFN1Yi1UTFZzIHN1Y2ggYXMgdGhlIEFkamFjZW5jeS1TSUQuICBIb3dldmVyLCB0 aGUNCj4gMTEzMiAgIHJlcG9ydGluZyBvZiBhbGxvY2F0ZWQgbG9jYWwgU0lEcyBtYXkgYWxzbyBi ZSBkb25lIHRocm91Z2ggb3RoZXINCj4gMTEzMyAgIG1lYW5zIGFuZCBwcm90b2NvbHMgd2hpY2gg bWVjaGFuaXNtcyBhcmUgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcw0KPiAxMTM0ICAgZG9jdW1l bnQuDQo+IA0KPiBbbWFqb3JdICJTSE9VTEQgYWxzbyBiZSByZXBvcnRlZCB0byBhbGwgY29tcG9u ZW50cyIgIEJlY2F1c2UgdGhhdCBpcw0KPiBvdXRzaWRlIHRoZSBzY29wZSwgdGhlbiBpdCBzaG91 bGRuJ3QgYmUgYSBOb3JtYXRpdmUgc3RhdGVtZW50Lg0KPiAgcy9TSE9VTEQvc2hvdWxkDQo+IA0K PiANCj4gLi4uDQo+IDExNzAgNC4gIE5vbiBiYWNrd2FyZCBjb21wYXRpYmxlIGNoYW5nZXMgd2l0 aCBwcmlvciB2ZXJzaW9ucyBvZiB0aGlzDQo+IGRvY3VtZW50DQo+IA0KPiBbbWFqb3JdIEkgZmlu ZCB0aGlzIHNlY3Rpb24gdW5uZWNlc3NhcnkuICBJZiB5b3Ugd2FudCB0byBrZWVwIGl0LCBwbGVh c2UNCj4gbW92ZSBpdCB0byBhbiBBcHBlbmRpeCBhbmQgZG9uJ3QgdXNlIE5vcm1hdGl2ZSBsYW5n dWFnZS4NCj4gDQo+IA0KPiAuLi4NCj4gMTE5MCA1LiAgSUFOQSBDb25zaWRlcmF0aW9ucw0KPiAN Cj4gMTE5MiAgIFRoaXMgZG9jdW1lbnRzIHJlcXVlc3QgYWxsb2NhdGlvbiBmb3IgdGhlIGZvbGxv d2luZyBUTFZzIGFuZCBzdWJUTFZzDQo= From nobody Thu Mar 21 08:41:19 2019 Return-Path: X-Original-To: lsr@ietf.org Delivered-To: lsr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0763F1312FD; Thu, 21 Mar 2019 08:41:18 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Acee Lindem via Datatracker To: X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Cc: lsr-chairs@ietf.org, iesg-secretary@ietf.org, acee@cisco.com, Acee Lindem , lsr@ietf.org Message-ID: <155318287802.9899.11835114605818437863.idtracker@ietfa.amsl.com> Date: Thu, 21 Mar 2019 08:41:18 -0700 Archived-At: Subject: [Lsr] Publication has been requested for draft-ietf-ospf-xaf-te-05 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2019 15:41:18 -0000 Acee Lindem has requested publication of draft-ietf-ospf-xaf-te-05 as Proposed Standard on behalf of the LSR working group. Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-ospf-xaf-te/ From nobody Thu Mar 21 10:52:29 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1756F13153C; Thu, 21 Mar 2019 10:52:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_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 2yDxN9Ptq66M; Thu, 21 Mar 2019 10:52:26 -0700 (PDT) Received: from mail-oi1-x235.google.com (mail-oi1-x235.google.com [IPv6:2607:f8b0:4864:20::235]) (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 D6B3C1310D6; Thu, 21 Mar 2019 10:52:25 -0700 (PDT) Received: by mail-oi1-x235.google.com with SMTP id i21so5298053oib.11; Thu, 21 Mar 2019 10:52:25 -0700 (PDT) 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=ZusD5t29Sitdxh5P0daYQLoYIObWqu84vPVCjvLqCQw=; b=FFXEeJGGT3kX6m2VQ2WkuR3KHI6Ner2OpWAyz2vnOzqW3hRs2BGymKtiY92MvtFILU QLpMMnDXIz7Ou01JunJbqZpq+scx8FscwxZzACDBo3hCV54aEnaatHnSCGPC209dMGZA Y1nirKfjRF3HAEag4NpeMLmVBb4OndgsTesV8PVz/3RHlVdgL5z5chrmSni7HGZtTWy+ C4Bqz3NGcNXTWEG06QuxKNA13Za2s/7+xJX0bvuloPJ3tTcJOg3qgG9otDIpPDKRFmlR SE4GajlB/Ogy22CXMz+ovA4Kn1EZf3WUXog6nXCgVoZpUA2LzospAIJgSXOIEUE0ki9N ggUw== 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=ZusD5t29Sitdxh5P0daYQLoYIObWqu84vPVCjvLqCQw=; b=gV3hDvTIVgXEcHgNZDKUnGbdD+KeOTVmE/kGhXqnU+hOsj31JCOTrc+4vw876OL1CX vfj5R7Swo1/vL6NokYXoPJBanfZL2FeOP1Cp4YtGUXPSC/4oWOthrJHcpRwhlhgyBb7A 3h8LzVg7jJJ8wZ/3cui48gODPCPiRAVjEJLWzpABFQj1s+1DkZySesO0dmQZKHARnAMf tVEAjyojUc6TMq29r5ql6ht/8HV2C4jXEMApRtX0QNvmZnQpXQfLp6F65zf98gvnE002 yFmXP/xjdwccasRNSCRPBqvITHG9/3Bq5shCGvbVJYmvRtah9HauUeQiyTZVjQyP5KVR lfgQ== X-Gm-Message-State: APjAAAVf1b7oNZfB4LiyK1+5Rx2sE9CcVgrCPnsE/HXc/fXx79mJAsBM KYXEYWZH80lQfsjrPp+haqsrv6dLQB329bTDgFs= X-Google-Smtp-Source: APXvYqzlate3eMRSuSVzrhPn0VzaEG7okcUKZHYythfIqBc3x69feUepM6KjeDjRb+rk8/G92bMuXuEsCNZIDS9oIG4= X-Received: by 2002:aca:3306:: with SMTP id z6mr371920oiz.45.1553190744958; Thu, 21 Mar 2019 10:52:24 -0700 (PDT) Received: from 1058052472880 named unknown by gmailapi.google.com with HTTPREST; Thu, 21 Mar 2019 18:52:23 +0100 From: Alvaro Retana In-Reply-To: References: MIME-Version: 1.0 Date: Thu, 21 Mar 2019 18:52:23 +0100 Message-ID: To: "Les Ginsberg (ginsberg)" , "draft-ietf-isis-segment-routing-extensions@ietf.org" Cc: "lsr-chairs@ietf.org" , "lsr@ietf.org" , Uma Chunduri Content-Type: multipart/alternative; boundary="0000000000009f2e9f05849e66c3" Archived-At: Subject: Re: [Lsr] AD Review of draft-ietf-isis-segment-routing-extensions-22 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2019 17:52:28 -0000 --0000000000009f2e9f05849e66c3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On March 20, 2019 at 7:37:42 PM, Les Ginsberg (ginsberg) (ginsberg@cisco.co= m) wrote: Les: Hi! In regards to the relationship with RFC 7794, there is a history here. Thanks for the history lesson! :-) To avoid more confusion (specially from other reviewers), I think that it would be a good idea to avoid talking about transitions=E2=80=A6. The logic= of preferring the prefix attributes sub-TLV seems enough. When =E2=80=9Csomeday=E2=80=9D comes, and if it=E2=80=99s needed, we can wo= rry about repurposing the flags. Thanks! Alvaro. The N and R flags were originally defined as part of the prefix-sid sub-TLV in early versions of this draft. However, it was realized that there were use cases for these flags that had nothing to do with SR. This prompted writing what became RFC 7794. But because there are early deployments in the field which were already using the N/R flags in prefix-SID sub-TLV we could not immediately deprecate the flags in prefix-SID sub-TLV. The intent is for RFC 7794 advertisement to become the sole place where N/R flags are advertised - but in the interim implementations have to support logic which is roughly: If (prefix attributes sub-TLV is present) Use prefix attributes sub-TLV settings and ignore N/R flag in prefix-SID sub-TLV if present Else Use N/R flag in prefix-SID sub-TLV if present "Someday" all implementations will support prefix attributes sub-TLV and there will be no use case for the flags in prefix-SID sub-TLV. At that point the flags can be repurposed. When will "someday" happen?? I think you know as well as I that such transitions take many years. The timing of this is not critical unless we run out of flag bits in the prefix-SID sub-TLV and need to reuse the N/R bits. At this point we do not foresee this happening any time soon. --0000000000009f2e9f05849e66c3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =
On March 20, 2019 at 7:37:42 PM, Les Ginsberg (ginsberg= ) (ginsberg@cisco.com) wrote:

Les:

Hi!

In = regards to the relationship with RFC 7794, there is a history here.=C2=A0

Thanks for the history lesson! :-= )

To avoid more confusion (specially = from other reviewers), I think that it would be a good idea to avoid talkin= g about transitions=E2=80=A6. The logic of preferring the=C2=A0prefix attri= butes sub-TLV seems enough.

When =E2= =80=9Csomeday=E2=80=9D comes, and if it=E2=80=99s needed, we can worry abou= t repurposing the flags.

Thanks!

Alvaro.


The N and R flags were originally defined as part of the p= refix-sid sub-TLV in early versions of this draft. However, it was realized= that there were use cases for these flags that had nothing to do with SR.<= span class=3D"Apple-converted-space">=C2=A0
<= span style=3D"color:rgb(0,0,0);font-variant-caps:normal;letter-spacing:norm= al;text-align:start;text-indent:0px;text-transform:none;white-space:normal;= word-spacing:0px;background-color:rgb(255,255,255);float:none;display:inlin= e!important">This prompted writing what became RFC 7794. But because there = are early deployments in the field which were already using the N/R flags i= n prefix-SID sub-TLV we could not immediately deprecate the flags in prefix= -SID sub-TLV.=C2=A0

The intent is for RFC 7794 adve= rtisement to become the sole place where N/R flags are advertised - but in = the interim implementations have to support logic which is roughly:=C2=A0

If (prefix attributes sub-TLV is present)=C2=A0
Use prefix attributes sub-TLV settings and ignore N/R flag in prefix-SID= sub-TLV if present=C2=A0
Else= =C2=A0
Use N/R flag in prefix-S= ID sub-TLV if present=C2=A0

"Someday" all= implementations will support prefix attributes sub-TLV and there will be n= o use case for the flags in prefix-SID sub-TLV. At that point the flags can= be repurposed.=C2=A0
When will "someday"= happen??=C2=A0
I think you know as well as I that such transitions = take many years.=C2=A0<= br style=3D"color:rgb(0,0,0);font-variant-caps:normal;letter-spacing:normal= ;text-align:start;text-indent:0px;text-transform:none;white-space:normal;wo= rd-spacing:0px">
The timing of this is not cr= itical unless we run out of flag bits in the prefix-SID sub-TLV and need to= reuse the N/R bits. At this point we do not foresee this happening any tim= e soon.=C2=A0

--0000000000009f2e9f05849e66c3-- From nobody Thu Mar 21 11:32:59 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF4E713157D; Thu, 21 Mar 2019 11:32:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.5 X-Spam-Level: X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, 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=Dj0xJkyk; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=RKX5SfJt 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 twoTvMdPqTWR; Thu, 21 Mar 2019 11:32:56 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F5A513157B; Thu, 21 Mar 2019 11:32:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16102; q=dns/txt; s=iport; t=1553193175; x=1554402775; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=/6ZmpxdJp1iIl65Bgi1oCoHfx5at9ze6CgelVZSuQQ4=; b=Dj0xJkykTdl2jCsqFey0L4fA4RqivbOJ00sNYmXsqordN8R+S5y18jSk 9T5jUczGqmctMjKU0wBDTOwsi4NAMUh18/AX5Pwt+fQyBnt+SbTeJUfLR 4oNyyuedhp+z1jbxKSjB6FubGmnXPYQ9LNZfeLsgHteFDtpzr4nB3mHsI U=; IronPort-PHdr: =?us-ascii?q?9a23=3AQ/HoPRTy0d//CYLRdaNDBWYVA9psv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESXBNfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5g640NmhA4RsuMCEn1NvnvOiM7Gt9IWUVq13q6KkNSXs35Yg6arw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAAB+15Nc/4sNJK1kGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBDi8kLANodAQLJ4QOg0cDhFKKV4JXiTWJC4R?= =?us-ascii?q?JgS6BJANUDQEBLIRAAheEXSI0CQ0BAQMBAQkBAwJtHAyFSgEBAQQjChMBATA?= =?us-ascii?q?HAQ8CAQgOAwQBASgDAgICHxEUCQgCBAENBQiDG4ERTAMVAQKgCgKKFHGBL4J?= =?us-ascii?q?4AQEFhQMNC4IMCIEvAYoSgR8XgUA/ZnGBfFA+ghqCLBUfglQxgiaKFoJYhBu?= =?us-ascii?q?HQ4wINgkCj3aDWJNzixiHOItmAgQCBAUCDgEBBYFNOIFWcBWDJ4IKDBeDS4p?= =?us-ascii?q?TcoEojGABAQ?= X-IronPort-AV: E=Sophos;i="5.60,253,1549929600"; d="scan'208,217";a="319963529" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 21 Mar 2019 18:32:53 +0000 Received: from XCH-ALN-001.cisco.com (xch-aln-001.cisco.com [173.36.7.11]) by alln-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id x2LIWrLM005571 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 21 Mar 2019 18:32:53 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.1473.3; Thu, 21 Mar 2019 13:32:52 -0500 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.1473.3; Thu, 21 Mar 2019 13:32:52 -0500 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Thu, 21 Mar 2019 13:32:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=/6ZmpxdJp1iIl65Bgi1oCoHfx5at9ze6CgelVZSuQQ4=; b=RKX5SfJtSLSYt0hFZVEBvwNsfC73X1DPjg/kepap++gGPrcivXPxlB8MMzcqAZPxPo/2WxweZstDNXXSJhHJbrcP6WAKAWeWljN1lbDPQ6mBR3By826PxzD+xBASWAunC8RGLbc1QZr9HVoKEq8SN8kM6zmWB9eMldqZVi7byA0= Received: from BYAPR11MB3638.namprd11.prod.outlook.com (20.178.237.19) by BYAPR11MB2725.namprd11.prod.outlook.com (52.135.227.155) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.16; Thu, 21 Mar 2019 18:32:51 +0000 Received: from BYAPR11MB3638.namprd11.prod.outlook.com ([fe80::b414:f534:f20a:a26d]) by BYAPR11MB3638.namprd11.prod.outlook.com ([fe80::b414:f534:f20a:a26d%3]) with mapi id 15.20.1709.015; Thu, 21 Mar 2019 18:32:51 +0000 From: "Les Ginsberg (ginsberg)" To: Alvaro Retana , "draft-ietf-isis-segment-routing-extensions@ietf.org" CC: "lsr-chairs@ietf.org" , "lsr@ietf.org" , Uma Chunduri Thread-Topic: AD Review of draft-ietf-isis-segment-routing-extensions-22 Thread-Index: AQHU32s2LXimbEtSIUKKc+aYWZUjdqYVKWSwgAE1coCAAAqY4A== Date: Thu, 21 Mar 2019 18:32:51 +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: spf=none (sender IP is ) smtp.mailfrom=ginsberg@cisco.com; x-originating-ip: [2001:420:30d:1254:8012:e90b:7af9:9084] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c8c525e3-2d3d-4291-2e18-08d6ae2ba024 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BYAPR11MB2725; x-ms-traffictypediagnostic: BYAPR11MB2725: x-microsoft-antispam-prvs: x-forefront-prvs: 0983EAD6B2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(366004)(136003)(396003)(39860400002)(346002)(51914003)(189003)(199004)(51444003)(8936002)(33656002)(6506007)(186003)(71200400001)(7696005)(256004)(76176011)(53546011)(71190400001)(68736007)(99286004)(6436002)(6116002)(790700001)(74316002)(7736002)(81166006)(8676002)(102836004)(478600001)(110136005)(54906003)(81156014)(4326008)(2501003)(6306002)(6246003)(14454004)(53936002)(25786009)(97736004)(229853002)(236005)(106356001)(2906002)(55016002)(316002)(9686003)(52536014)(486006)(54896002)(86362001)(476003)(46003)(11346002)(446003)(105586002)(5660300002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB2725; H:BYAPR11MB3638.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: P0YnDSZargel+B6uC6dGgX4pRG9VlYIIhrWO35BRVmSuKCWACsIQ3GR31AsZNhd9U0vql7MQMb9pwudROSFozrIloztWKD1RX2niemm0Kyk4VvaJW2ZHzv59zIUqXCpWyfqEo4JYBe01VkA5UzJx2nZi/VO98TOrjPQzkWh6Q4Y35inxvxnmfGJwsvlQls7At0G3f6c9++zGn2Qet7v9LRLL04A0RYybAdfM6fCc2xS3624jc+Dq3lxa7tveBjav4QQCh3oK4oX2puyCkqQ3zXsnYhaTndgLRboLYaQQ9PLekL2/xviVf9IWzqfSo0MIpY0M9kLcLkXD6MOB291H8cRgijwAI34RYho0KqPzBlBs5u7BN/rOCPR5pznj4qy3gA1/c23wOmSvSKk12vjo89HzlTl11DatpWpsWW2NNMQ= Content-Type: multipart/alternative; boundary="_000_BYAPR11MB363849CE292864969A27E6B4C1420BYAPR11MB3638namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c8c525e3-2d3d-4291-2e18-08d6ae2ba024 X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Mar 2019 18:32:51.1034 (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-Transport-CrossTenantHeadersStamped: BYAPR11MB2725 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.11, xch-aln-001.cisco.com X-Outbound-Node: alln-core-6.cisco.com Archived-At: Subject: Re: [Lsr] AD Review of draft-ietf-isis-segment-routing-extensions-22 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Mar 2019 18:32:58 -0000 --_000_BYAPR11MB363849CE292864969A27E6B4C1420BYAPR11MB3638namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWx2YXJvIC0NCg0KRnJvbTogQWx2YXJvIFJldGFuYSA8YXJldGFuYS5pZXRmQGdtYWlsLmNvbT4N ClNlbnQ6IFRodXJzZGF5LCBNYXJjaCAyMSwgMjAxOSAxMDo1MiBBTQ0KVG86IExlcyBHaW5zYmVy ZyAoZ2luc2JlcmcpIDxnaW5zYmVyZ0BjaXNjby5jb20+OyBkcmFmdC1pZXRmLWlzaXMtc2VnbWVu dC1yb3V0aW5nLWV4dGVuc2lvbnNAaWV0Zi5vcmcNCkNjOiBsc3ItY2hhaXJzQGlldGYub3JnOyBs c3JAaWV0Zi5vcmc7IFVtYSBDaHVuZHVyaSA8dW1hLmNodW5kdXJpQGh1YXdlaS5jb20+DQpTdWJq ZWN0OiBSRTogQUQgUmV2aWV3IG9mIGRyYWZ0LWlldGYtaXNpcy1zZWdtZW50LXJvdXRpbmctZXh0 ZW5zaW9ucy0yMg0KDQpPbiBNYXJjaCAyMCwgMjAxOSBhdCA3OjM3OjQyIFBNLCBMZXMgR2luc2Jl cmcgKGdpbnNiZXJnKSAoZ2luc2JlcmdAY2lzY28uY29tPG1haWx0bzpnaW5zYmVyZ0BjaXNjby5j b20+KSB3cm90ZToNCg0KTGVzOg0KDQpIaSENCg0KSW4gcmVnYXJkcyB0byB0aGUgcmVsYXRpb25z aGlwIHdpdGggUkZDIDc3OTQsIHRoZXJlIGlzIGEgaGlzdG9yeSBoZXJlLg0KDQpUaGFua3MgZm9y IHRoZSBoaXN0b3J5IGxlc3NvbiEgOi0pDQoNClRvIGF2b2lkIG1vcmUgY29uZnVzaW9uIChzcGVj aWFsbHkgZnJvbSBvdGhlciByZXZpZXdlcnMpLCBJIHRoaW5rIHRoYXQgaXQgd291bGQgYmUgYSBn b29kIGlkZWEgdG8gYXZvaWQgdGFsa2luZyBhYm91dCB0cmFuc2l0aW9uc+KApi4gVGhlIGxvZ2lj IG9mIHByZWZlcnJpbmcgdGhlIHByZWZpeCBhdHRyaWJ1dGVzIHN1Yi1UTFYgc2VlbXMgZW5vdWdo Lg0KDQpbTGVzOl0gT0sg4oCTIHBvaW50IHRha2VuLiAgSG9wZSBhbGwgb2YgdGhlIGNvbW1lbnRz IGNhbiBiZSByZXNvbHZlZCBzbyBlYXNpbHkuIOKYug0KDQogICBMZXMNCg0KDQoNCldoZW4g4oCc c29tZWRheeKAnSBjb21lcywgYW5kIGlmIGl04oCZcyBuZWVkZWQsIHdlIGNhbiB3b3JyeSBhYm91 dCByZXB1cnBvc2luZyB0aGUgZmxhZ3MuDQoNClRoYW5rcyENCg0KQWx2YXJvLg0KDQpUaGUgTiBh bmQgUiBmbGFncyB3ZXJlIG9yaWdpbmFsbHkgZGVmaW5lZCBhcyBwYXJ0IG9mIHRoZSBwcmVmaXgt c2lkIHN1Yi1UTFYgaW4gZWFybHkgdmVyc2lvbnMgb2YgdGhpcyBkcmFmdC4gSG93ZXZlciwgaXQg d2FzIHJlYWxpemVkIHRoYXQgdGhlcmUgd2VyZSB1c2UgY2FzZXMgZm9yIHRoZXNlIGZsYWdzIHRo YXQgaGFkIG5vdGhpbmcgdG8gZG8gd2l0aCBTUi4NClRoaXMgcHJvbXB0ZWQgd3JpdGluZyB3aGF0 IGJlY2FtZSBSRkMgNzc5NC4gQnV0IGJlY2F1c2UgdGhlcmUgYXJlIGVhcmx5IGRlcGxveW1lbnRz IGluIHRoZSBmaWVsZCB3aGljaCB3ZXJlIGFscmVhZHkgdXNpbmcgdGhlIE4vUiBmbGFncyBpbiBw cmVmaXgtU0lEIHN1Yi1UTFYgd2UgY291bGQgbm90IGltbWVkaWF0ZWx5IGRlcHJlY2F0ZSB0aGUg ZmxhZ3MgaW4gcHJlZml4LVNJRCBzdWItVExWLg0KDQpUaGUgaW50ZW50IGlzIGZvciBSRkMgNzc5 NCBhZHZlcnRpc2VtZW50IHRvIGJlY29tZSB0aGUgc29sZSBwbGFjZSB3aGVyZSBOL1IgZmxhZ3Mg YXJlIGFkdmVydGlzZWQgLSBidXQgaW4gdGhlIGludGVyaW0gaW1wbGVtZW50YXRpb25zIGhhdmUg dG8gc3VwcG9ydCBsb2dpYyB3aGljaCBpcyByb3VnaGx5Og0KDQpJZiAocHJlZml4IGF0dHJpYnV0 ZXMgc3ViLVRMViBpcyBwcmVzZW50KQ0KVXNlIHByZWZpeCBhdHRyaWJ1dGVzIHN1Yi1UTFYgc2V0 dGluZ3MgYW5kIGlnbm9yZSBOL1IgZmxhZyBpbiBwcmVmaXgtU0lEIHN1Yi1UTFYgaWYgcHJlc2Vu dA0KRWxzZQ0KVXNlIE4vUiBmbGFnIGluIHByZWZpeC1TSUQgc3ViLVRMViBpZiBwcmVzZW50DQoN CiJTb21lZGF5IiBhbGwgaW1wbGVtZW50YXRpb25zIHdpbGwgc3VwcG9ydCBwcmVmaXggYXR0cmli dXRlcyBzdWItVExWIGFuZCB0aGVyZSB3aWxsIGJlIG5vIHVzZSBjYXNlIGZvciB0aGUgZmxhZ3Mg aW4gcHJlZml4LVNJRCBzdWItVExWLiBBdCB0aGF0IHBvaW50IHRoZSBmbGFncyBjYW4gYmUgcmVw dXJwb3NlZC4NCg0KV2hlbiB3aWxsICJzb21lZGF5IiBoYXBwZW4/Pw0KSSB0aGluayB5b3Uga25v dyBhcyB3ZWxsIGFzIEkgdGhhdCBzdWNoIHRyYW5zaXRpb25zIHRha2UgbWFueSB5ZWFycy4NCg0K VGhlIHRpbWluZyBvZiB0aGlzIGlzIG5vdCBjcml0aWNhbCB1bmxlc3Mgd2UgcnVuIG91dCBvZiBm bGFnIGJpdHMgaW4gdGhlIHByZWZpeC1TSUQgc3ViLVRMViBhbmQgbmVlZCB0byByZXVzZSB0aGUg Ti9SIGJpdHMuIEF0IHRoaXMgcG9pbnQgd2UgZG8gbm90IGZvcmVzZWUgdGhpcyBoYXBwZW5pbmcg YW55IHRpbWUgc29vbi4NCg0K --_000_BYAPR11MB363849CE292864969A27E6B4C1420BYAPR11MB3638namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 SGVsdmV0aWNhOw0KCXBhbm9zZS0xOjIgMTEgNiA0IDIgMiAyIDIgMiA0O30NCkBmb250LWZhY2UN Cgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7 fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToy IDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsN CglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAq Lw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGlu Ow0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFt aWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsN Cgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9u OnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5k ZXJsaW5lO30NCnANCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFs dDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYu bXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3At YWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToi VGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXtt c28tc3R5bGUtbmFtZTphcHBsZS1jb252ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjAN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5 bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0 aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w aW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxl PjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIg c3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48 eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQi IGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPkFsdmFybyAtPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk IGJsdWUgMS41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4w cHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gQWx2YXJvIFJldGFuYSAmbHQ7YXJl dGFuYS5pZXRmQGdtYWlsLmNvbSZndDsNCjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgTWFy Y2ggMjEsIDIwMTkgMTA6NTIgQU08YnI+DQo8Yj5Ubzo8L2I+IExlcyBHaW5zYmVyZyAoZ2luc2Jl cmcpICZsdDtnaW5zYmVyZ0BjaXNjby5jb20mZ3Q7OyBkcmFmdC1pZXRmLWlzaXMtc2VnbWVudC1y b3V0aW5nLWV4dGVuc2lvbnNAaWV0Zi5vcmc8YnI+DQo8Yj5DYzo8L2I+IGxzci1jaGFpcnNAaWV0 Zi5vcmc7IGxzckBpZXRmLm9yZzsgVW1hIENodW5kdXJpICZsdDt1bWEuY2h1bmR1cmlAaHVhd2Vp LmNvbSZndDs8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUkU6IEFEIFJldmlldyBvZiBkcmFmdC1pZXRm LWlzaXMtc2VnbWVudC1yb3V0aW5nLWV4dGVuc2lvbnMtMjI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPk9uIE1h cmNoIDIwLCAyMDE5IGF0IDc6Mzc6NDIgUE0sIExlcyBHaW5zYmVyZyAoZ2luc2JlcmcpICg8YSBo cmVmPSJtYWlsdG86Z2luc2JlcmdAY2lzY28uY29tIj5naW5zYmVyZ0BjaXNjby5jb208L2E+KSB3 cm90ZTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkxl czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkhpITxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGlj YSZxdW90OyxzYW5zLXNlcmlmIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t OjUuMHB0O2ZvbnQtdmFyaWFudC1jYXBzOm5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0O3dvcmQtc3Bh Y2luZzowcHgiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOmJsYWNrO2JhY2tncm91bmQ6d2hpdGUiPkluIHJlZ2FyZHMgdG8gdGhlIHJlbGF0aW9u c2hpcCB3aXRoIFJGQyA3Nzk0LCB0aGVyZSBpcyBhIGhpc3RvcnkgaGVyZS48c3BhbiBjbGFzcz0i YXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNl cmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2 Pg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVs dmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPlRoYW5rcyBmb3IgdGhlIGhpc3RvcnkgbGVzc29uISA6 LSk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cD48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EmcXVvdDssc2Fucy1zZXJpZiI+VG8gYXZvaWQg bW9yZSBjb25mdXNpb24gKHNwZWNpYWxseSBmcm9tIG90aGVyIHJldmlld2VycyksIEkgdGhpbmsg dGhhdCBpdCB3b3VsZCBiZSBhIGdvb2QgaWRlYSB0byBhdm9pZCB0YWxraW5nIGFib3V0IHRyYW5z aXRpb25z4oCmLiBUaGUgbG9naWMgb2YgcHJlZmVycmluZyB0aGUmbmJzcDtwcmVmaXggYXR0cmli dXRlcyBzdWItVExWIHNlZW1zDQogZW5vdWdoLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxi PjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5bTGVzOl0gT0sg4oCTIHBvaW50IHRh a2VuLiAmbmJzcDtIb3BlIGFsbCBvZiB0aGUgY29tbWVudHMgY2FuIGJlIHJlc29sdmVkIHNvIGVh c2lseS4NCjwvc3Bhbj48L2k+PC9iPjxiPjxpPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OldpbmdkaW5ncztjb2xvcjojMUY0OTdEIj5KPC9zcGFuPjwvaT48L2I+PGI+ PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+PC9vOnA+PC9zcGFuPjwvaT48 L2I+PC9wPg0KPHA+PGI+PGk+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOyZu YnNwOyBMZXM8bzpwPjwvbzpwPjwvc3Bhbj48L2k+PC9iPjwvcD4NCjxwPjxiPjxpPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2k+PC9iPjwv cD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0hl bHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5XaGVuIOKAnHNvbWVkYXnigJ0gY29tZXMsIGFuZCBp ZiBpdOKAmXMgbmVlZGVkLCB3ZSBjYW4gd29ycnkgYWJvdXQgcmVwdXJwb3NpbmcgdGhlIGZsYWdz LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSZxdW90OyxzYW5zLXNlcmlmIj5UaGFua3MhPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHA+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPkFsdmFyby48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdDtmb250LXZhcmlhbnQtY2Fwczpub3JtYWw7dGV4dC1hbGln bjpzdGFydDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2Em cXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+PGJyPg0KPHNwYW4gc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPlRoZSBOIGFuZCBSIGZsYWdzIHdlcmUgb3JpZ2luYWxseSBkZWZpbmVkIGFzIHBh cnQgb2YgdGhlIHByZWZpeC1zaWQgc3ViLVRMViBpbiBlYXJseSB2ZXJzaW9ucyBvZiB0aGlzIGRy YWZ0LiBIb3dldmVyLCBpdCB3YXMgcmVhbGl6ZWQgdGhhdCB0aGVyZSB3ZXJlIHVzZSBjYXNlcyBm b3IgdGhlc2UgZmxhZ3MgdGhhdCBoYWQgbm90aGluZyB0byBkbyB3aXRoIFNSLjxzcGFuIGNsYXNz PSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PGJyPg0KPHNwYW4g c3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPlRoaXMgcHJvbXB0ZWQgd3JpdGluZyB3aGF0IGJlY2Ft ZSBSRkMgNzc5NC4gQnV0IGJlY2F1c2UgdGhlcmUgYXJlIGVhcmx5IGRlcGxveW1lbnRzIGluIHRo ZSBmaWVsZCB3aGljaCB3ZXJlIGFscmVhZHkgdXNpbmcgdGhlIE4vUiBmbGFncyBpbiBwcmVmaXgt U0lEIHN1Yi1UTFYgd2UgY291bGQgbm90IGltbWVkaWF0ZWx5IGRlcHJlY2F0ZSB0aGUgZmxhZ3Mg aW4gcHJlZml4LVNJRCBzdWItVExWLjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui PiZuYnNwOzwvc3Bhbj48L3NwYW4+PGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6 d2hpdGUiPlRoZSBpbnRlbnQgaXMgZm9yIFJGQyA3Nzk0IGFkdmVydGlzZW1lbnQgdG8gYmVjb21l IHRoZSBzb2xlIHBsYWNlIHdoZXJlIE4vUiBmbGFncyBhcmUgYWR2ZXJ0aXNlZCAtIGJ1dCBpbiB0 aGUgaW50ZXJpbSBpbXBsZW1lbnRhdGlvbnMgaGF2ZSB0byBzdXBwb3J0IGxvZ2ljIHdoaWNoIGlz IHJvdWdobHk6PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFu Pjwvc3Bhbj48YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+SWYgKHBy ZWZpeCBhdHRyaWJ1dGVzIHN1Yi1UTFYgaXMgcHJlc2VudCk8c3BhbiBjbGFzcz0iYXBwbGUtY29u dmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxicj4NCjxzcGFuIHN0eWxlPSJiYWNr Z3JvdW5kOndoaXRlIj5Vc2UgcHJlZml4IGF0dHJpYnV0ZXMgc3ViLVRMViBzZXR0aW5ncyBhbmQg aWdub3JlIE4vUiBmbGFnIGluIHByZWZpeC1TSUQgc3ViLVRMViBpZiBwcmVzZW50PHNwYW4gY2xh c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48YnI+DQo8c3Bh biBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+RWxzZTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0 ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PGJyPg0KPHNwYW4gc3R5bGU9ImJhY2tncm91 bmQ6d2hpdGUiPlVzZSBOL1IgZmxhZyBpbiBwcmVmaXgtU0lEIHN1Yi1UTFYgaWYgcHJlc2VudDxz cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PGJy Pg0KPGJyPg0KPHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPiZxdW90O1NvbWVkYXkmcXVv dDsgYWxsIGltcGxlbWVudGF0aW9ucyB3aWxsIHN1cHBvcnQgcHJlZml4IGF0dHJpYnV0ZXMgc3Vi LVRMViBhbmQgdGhlcmUgd2lsbCBiZSBubyB1c2UgY2FzZSBmb3IgdGhlIGZsYWdzIGluIHByZWZp eC1TSUQgc3ViLVRMVi4gQXQgdGhhdCBwb2ludCB0aGUgZmxhZ3MgY2FuIGJlIHJlcHVycG9zZWQu PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjwvc3Bhbj48 YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0iYmFja2dyb3VuZDp3aGl0ZSI+V2hlbiB3aWxsICZxdW90 O3NvbWVkYXkmcXVvdDsgaGFwcGVuPz88c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNl Ij4mbmJzcDs8L3NwYW4+PC9zcGFuPjxicj4NCjxzcGFuIHN0eWxlPSJiYWNrZ3JvdW5kOndoaXRl Ij5JIHRoaW5rIHlvdSBrbm93IGFzIHdlbGwgYXMgSSB0aGF0IHN1Y2ggdHJhbnNpdGlvbnMgdGFr ZSBtYW55IHllYXJzLjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv c3Bhbj48L3NwYW4+PGJyPg0KPGJyPg0KPHNwYW4gc3R5bGU9ImJhY2tncm91bmQ6d2hpdGUiPlRo ZSB0aW1pbmcgb2YgdGhpcyBpcyBub3QgY3JpdGljYWwgdW5sZXNzIHdlIHJ1biBvdXQgb2YgZmxh ZyBiaXRzIGluIHRoZSBwcmVmaXgtU0lEIHN1Yi1UTFYgYW5kIG5lZWQgdG8gcmV1c2UgdGhlIE4v UiBiaXRzLiBBdCB0aGlzIHBvaW50IHdlIGRvIG5vdCBmb3Jlc2VlIHRoaXMgaGFwcGVuaW5nIGFu eSB0aW1lIHNvb24uPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z cGFuPjwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhJnF1b3Q7LHNh bnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8 L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BYAPR11MB363849CE292864969A27E6B4C1420BYAPR11MB3638namp_-- From nobody Fri Mar 22 03:40:49 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4C6F1200D7; Fri, 22 Mar 2019 03:40:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u-FcQ9lkYHmz; Fri, 22 Mar 2019 03:40:44 -0700 (PDT) Received: from orange.com (mta241.mail.business.static.orange.com [80.12.66.41]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6F261200B3; Fri, 22 Mar 2019 03:40:40 -0700 (PDT) Received: from opfedar03.francetelecom.fr (unknown [xx.xx.xx.5]) by opfedar27.francetelecom.fr (ESMTP service) with ESMTP id 44QgD66qnbz2y7C; Fri, 22 Mar 2019 11:40:38 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.26]) by opfedar03.francetelecom.fr (ESMTP service) with ESMTP id 44QgD65pHQzCqkY; Fri, 22 Mar 2019 11:40:38 +0100 (CET) Received: from OPEXCAUBM43.corporate.adroot.infra.ftgroup ([fe80::b846:2467:1591:5d9d]) by OPEXCAUBM31.corporate.adroot.infra.ftgroup ([fe80::34b6:11d0:147f:6560%21]) with mapi id 14.03.0439.000; Fri, 22 Mar 2019 11:40:38 +0100 From: To: "lsr@ietf.org" , "draft-ginsberg-lsr-isis-invalid-tlv@ietf.org" CC: Alvaro Retana Thread-Topic: draft-ginsberg-lsr-isis-invalid-tlv Thread-Index: AdTglBRECrXWUxPzTUGVlZ6TbJL//A== Date: Fri, 22 Mar 2019 10:40:38 +0000 Message-ID: <7565_1553251238_5C94BBA6_7565_333_1_53C29892C857584299CBF5D05346208A48A28540@OPEXCAUBM43.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A48A28540OPEXCAUBM43corp_" MIME-Version: 1.0 Archived-At: Subject: [Lsr] draft-ginsberg-lsr-isis-invalid-tlv X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2019 10:40:47 -0000 --_000_53C29892C857584299CBF5D05346208A48A28540OPEXCAUBM43corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, To be clear, I support that document. Thanks for writing it. I have some comments, mostly asking for even more of this/such document. (a= lthough I expect that some comments will trigger a discussion ;-) ) ---- =A73.1 "Any codes in a received PDU that are not recognised shall be ignored." Therefore the presence of TLVs in a PDU which are not allowed MUST NOT cause the PDU itself to be rejected by the receiving IS. I don't think that "not recognized" is the same as "not allowed". IMHO, the fact that unknown TLV are to be ignored seem rather obvious as th= is is a designed goal of the TLV format. Yet, it's good that [ISO10589] explicitly stated it. I definitely support that LSR defines the behavior for TLV (and sub-TLV) wh= ich are not allowed. But I find the justification and reference debatable. = I'd rather prefer that we remove it, or at least remove the "Therefore". I'= d favor something along OLD: Therefore NEW: In addition, this document specifies that ---- =A73.3 Registries associated with sub-TLVs are associated with the TLV Codepoints Registry and specify in which TLVs a given sub-TLV is allowed. As with TLVs, it is required that sub- TLVs which are NOT allowed MUST be ignored on receipt. In addition to "not recognized" and "not allowed by the registry" I believe= that there are others cases that would benefit from been clarified. Such a= s: - not allowed by the specification (in a given case/condition) - REQUIRED (MUST) but not present e.g. "it MUST include this sub-TLV on poi= nt-to-point adjacencies" https://tools.ietf.org/html/rfc5305#section-3.3 - Malformed (bad syntax) - Correctly formed but illegal value (in a given case/condition) I would like LSR to specify all types of error handling. Either in this doc= ument, or in another document if general error handling is considered out o= f scope of this document. --- =A71 " PDUs which are valid MUST be accepted even if an individual TLV contained within that PDU is invalid in some way." I wish "valid" be further defined. E.g. do you mean from a syntax/parsing p= oint of view? Or do you mean something else? In particular [ISO10589] use the terms "invalid PDU syntax". If you m= ean the same, I'd favor using the same terms. If you mean something differe= nt, please clarify the differences. --- " Nevertheless, a certain degree of "common knowledge" is assumed on the part of implementors in regards to these behaviors." What do you mean by that? That some "common knowledge" are required for the= protocol to (correctly) work but that this knowledge is not written in a s= pecification? If so, I believe LSR should write down such behavior. " This document serves to make explicit what is expected. While it does not alter any existing protocol behavior or specifications, it is intended to close any gaps between what is explicitly stated and what has been "commonly understood"." Same comment. A behavior is either specified or not specified. I don't understand the mea= ning of the term "commonly understood". Thank you, Regards, --Bruno PS: To clarify, I'm copying Alvaro as an individual contributor, as he expr= essed interest in error handling in BGP-LS which for some code points may b= e related to error handing in IS-IS. ___________________________________________________________________________= ______________________________________________ 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 messages el= ectroniques 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. --_000_53C29892C857584299CBF5D05346208A48A28540OPEXCAUBM43corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi all,

 

To be clear, I support that document. Thanks for writing it.<= /span>

I have some comments, mostly asking for even more of this/such document.= (although I expect that some comments will trigger a discussion ;-) )=

 

----

=A73.1

"Any codes in a received PDU that ar= e not recognised shall be

 &n= bsp; ignored."

 

 &n= bsp; Therefore the presence of TLVs in a PDU which are not allowed MUST

 &n= bsp; NOT cause the PDU itself to be rejected by the receiving IS.

 

 

I don’t think that “not recognized” is the same as = 220;not allowed”.

IMHO, the fact that unknown TLV are to be ignored seem rathe=
r obvious as this is a designed goal of the TLV format. Yet, it’s goo=
d that [ISO10589] explicitly stated it.=

I definitely support that LSR defines the behavior for TLV (and sub-TLV)= which are not allowed. But I find the justification and reference debatabl= e. I’d rather prefer that we remove it, or at least remove the “Therefore”. I’d favor something = along

OLD: Therefore

NEW: In addition, this document specifies that

----

=A73.3

Registries asso=
ciated with sub-TLVs are
   associated with the TLV Codepoints Registry and specify in which TLVs=

   a given sub-TLV is allowed.  As with TLVs, it is required that sub-=

   TLVs which are NOT allowed MUST be ig=
nored on receipt.

 

In addition to “not recognized” and “not allowed by th= e registry” I believe that there are others cases that would benefit = from been clarified. Such as:

- not allowed by the specification (in a given case/condition)

- REQUIRED (MUST) but not present e.g. “it MUST include this sub-T= LV on point-to-point adjacencies” https://tools.i= etf.org/html/rfc5305#section-3.3

- Malformed (bad syntax)

- Correctly formed but illegal value (in a given case/condition)

 

I would like LSR to specify all types of error handling. Either in this = document, or in another document if general error handling is considered ou= t of scope of this document.

---

=A71
“   PDUs which ar=
e valid MUST be accepted even if an individual TLV
   contained within that PDU is invalid =
in some way.”
 
I wish “valid” be further defined. E.g. do you m=
ean from a syntax/parsing point of view? Or do you mean something else?
In particular [ISO10589] use the te=
rms “invalid PDU syntax”. If you mean the same, I’d favor=
 using the same terms. If you mean something different, please clarify the =
differences.
---
“   Nevertheless,=
 a certain degree of "common knowledge" is assumed on<=
/span>
   the part of im=
plementors in regards to these behaviors.”

 


What do you mean by that? That some “common knowledge&=
#8221; are required for the protocol to (correctly) work but that this know=
ledge is not written in a specification? If so, I believe LSR should write =
down such behavior.


 


“   This document=
 serves to make explicit what is expected.=
  While it


   does not alter any existing protocol =
behavior or specifications, it


   is intended to close any gaps between=
 what is explicitly stated and


   what has been "commonly understo=
od".”


 


Same comment.


A behavior is either specified or not specified. I don’=
;t understand the meaning of the term “commonly understood”. 


 


Thank you,


Regards,


--Bruno


 


PS: To clarify, I’m copying Alvaro as an individual contributor, a=
s he expressed interest in error handling in BGP-LS which for some code poi=
nts may be related to error handing in IS-IS.


 


______________________________________________________________________=
___________________________________________________

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 messages el=
ectroniques 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.
--_000_53C29892C857584299CBF5D05346208A48A28540OPEXCAUBM43corp_-- From nobody Fri Mar 22 04:02:33 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51927130EBF; Fri, 22 Mar 2019 04:02:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.588 X-Spam-Level: X-Spam-Status: No, score=-2.588 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UQG8UKEM23x5; Fri, 22 Mar 2019 04:02:18 -0700 (PDT) Received: from orange.com (mta134.mail.business.static.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 E23AB130F2B; Fri, 22 Mar 2019 04:02:17 -0700 (PDT) Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr20.francetelecom.fr (ESMTP service) with ESMTP id 44Qgj41B3Fz1yWZ; Fri, 22 Mar 2019 12:02:16 +0100 (CET) Received: from Exchangemail-eme6.itn.ftgroup (unknown [xx.xx.13.82]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 44Qgj36s8Wz1xpq; Fri, 22 Mar 2019 12:02:15 +0100 (CET) Received: from OPEXCAUBM43.corporate.adroot.infra.ftgroup ([fe80::b846:2467:1591:5d9d]) by OPEXCAUBM5E.corporate.adroot.infra.ftgroup ([fe80::849f:f804:b713:d99a%21]) with mapi id 14.03.0439.000; Fri, 22 Mar 2019 12:02:14 +0100 From: To: "lsr@ietf.org" , "draft-ginsberg-lsr-isis-invalid-tlv@ietf.org" CC: Alvaro Retana Thread-Topic: draft-ginsberg-lsr-isis-invalid-tlv Thread-Index: AdTglBRECrXWUxPzTUGVlZ6TbJL//AACGNNg Date: Fri, 22 Mar 2019 11:02:13 +0000 Message-ID: <12194_1553252536_5C94C0B8_12194_166_1_53C29892C857584299CBF5D05346208A48A28723@OPEXCAUBM43.corporate.adroot.infra.ftgroup> References: <7565_1553251238_5C94BBA6_7565_333_1_53C29892C857584299CBF5D05346208A48A28540@OPEXCAUBM43.corporate.adroot.infra.ftgroup> In-Reply-To: <7565_1553251238_5C94BBA6_7565_333_1_53C29892C857584299CBF5D05346208A48A28540@OPEXCAUBM43.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.114.13.247] Content-Type: multipart/alternative; boundary="_000_53C29892C857584299CBF5D05346208A48A28723OPEXCAUBM43corp_" MIME-Version: 1.0 Archived-At: Subject: Re: [Lsr] draft-ginsberg-lsr-isis-invalid-tlv X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Mar 2019 11:02:31 -0000 --_000_53C29892C857584299CBF5D05346208A48A28723OPEXCAUBM43corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =A74 The presence of a TLV (or sub-TLV) with content which does not conform to the relevant specification MUST NOT cause the LSP itself to be rejected. Again, thank you for your effort to clarify the specification. Given the "MUST", I feel that this sentence may be read as contradicting wi= th some other text. E.g " An implementation that implements HMAC-MD5 authentication and receives HMAC-MD5 Authentication Information MUST discard the PDU if the Authentication Value is incorrect." https://tools.ietf.org/html/rfc5304#section-2 Do you think it could be slightly rephrased? May be something along :s/reje= cted/considered invalid [or incorrect, although 10589 seems to use the = term "invalid PDU"] (as "rejected" could be read as similar to "discarded") Thanks, --Bruno From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of bruno.decraene@orange.= com Sent: Friday, March 22, 2019 11:41 AM To: lsr@ietf.org; draft-ginsberg-lsr-isis-invalid-tlv@ietf.org Cc: Alvaro Retana Subject: [Lsr] draft-ginsberg-lsr-isis-invalid-tlv Hi all, To be clear, I support that document. Thanks for writing it. I have some comments, mostly asking for even more of this/such document. (a= lthough I expect that some comments will trigger a discussion ;-) ) ---- =A73.1 "Any codes in a received PDU that are not recognised shall be ignored." Therefore the presence of TLVs in a PDU which are not allowed MUST NOT cause the PDU itself to be rejected by the receiving IS. I don't think that "not recognized" is the same as "not allowed". IMHO, the fact that unknown TLV are to be ignored seem rather obvious as th= is is a designed goal of the TLV format. Yet, it's good that [ISO10589] explicitly stated it. I definitely support that LSR defines the behavior for TLV (and sub-TLV) wh= ich are not allowed. But I find the justification and reference debatable. = I'd rather prefer that we remove it, or at least remove the "Therefore". I'= d favor something along OLD: Therefore NEW: In addition, this document specifies that ---- =A73.3 Registries associated with sub-TLVs are associated with the TLV Codepoints Registry and specify in which TLVs a given sub-TLV is allowed. As with TLVs, it is required that sub- TLVs which are NOT allowed MUST be ignored on receipt. In addition to "not recognized" and "not allowed by the registry" I believe= that there are others cases that would benefit from been clarified. Such a= s: - not allowed by the specification (in a given case/condition) - REQUIRED (MUST) but not present e.g. "it MUST include this sub-TLV on poi= nt-to-point adjacencies" https://tools.ietf.org/html/rfc5305#section-3.3 - Malformed (bad syntax) - Correctly formed but illegal value (in a given case/condition) I would like LSR to specify all types of error handling. Either in this doc= ument, or in another document if general error handling is considered out o= f scope of this document. --- =A71 " PDUs which are valid MUST be accepted even if an individual TLV contained within that PDU is invalid in some way." I wish "valid" be further defined. E.g. do you mean from a syntax/parsing p= oint of view? Or do you mean something else? In particular [ISO10589] use the terms "invalid PDU syntax". If you m= ean the same, I'd favor using the same terms. If you mean something differe= nt, please clarify the differences. --- " Nevertheless, a certain degree of "common knowledge" is assumed on the part of implementors in regards to these behaviors." What do you mean by that? That some "common knowledge" are required for the= protocol to (correctly) work but that this knowledge is not written in a s= pecification? If so, I believe LSR should write down such behavior. " This document serves to make explicit what is expected. While it does not alter any existing protocol behavior or specifications, it is intended to close any gaps between what is explicitly stated and what has been "commonly understood"." Same comment. A behavior is either specified or not specified. I don't understand the mea= ning of the term "commonly understood". Thank you, Regards, --Bruno PS: To clarify, I'm copying Alvaro as an individual contributor, as he expr= essed interest in error handling in BGP-LS which for some code points may b= e related to error handing in IS-IS. ___________________________________________________________________________= ______________________________________________ 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 messages el= ectroniques 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. ___________________________________________________________________________= ______________________________________________ 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 messages el= ectroniques 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. --_000_53C29892C857584299CBF5D05346208A48A28723OPEXCAUBM43corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

=A74

 &n= bsp; The presence of a TLV (or sub-TLV) with content which does not<= /o:p>

 &n= bsp; conform to the relevant specification MUST NOT cause the LSP itself<= o:p>

 &n= bsp; to be rejected.

 

Again, thank you for your effort to clarify the specification.

 

Given the “MUST”, I feel that this sentence may be read as c= ontradicting with some other text. E.g

“   An implementation that impleme=
nts HMAC-MD5 authentication and

 &n= bsp; receives HMAC-MD5 Authentication Information MUST discard the PDU if=

 &n= bsp; the Authentication Value is incorrect.”

https://tools.ietf.org/html/rfc5304#section-2

 

Do you think it could be slightly rephrased? May be something along :s/r= ejected/considered invalid     [or incorre= ct, although 10589 seems to use the term “invalid PDU”]

(as “rejected” could be read as similar to “discarded&= #8221;)

 

Thanks,

--Bruno 

 

= From: Lsr [mailto:lsr-bounces@ietf.org] On Behal= f Of bruno.decraene@orange.com
Sent: Friday, March 22, 2019 11:41 AM
To: lsr@ietf.org; draft-ginsberg-lsr-isis-invalid-tlv@ietf.org
Cc: Alvaro Retana
Subject: [Lsr] draft-ginsberg-lsr-isis-invalid-tlv=

 

Hi all,

 

To be clear, I support that document. Thank= s for writing it.

I have some comments, mostly asking for eve= n more of this/such document. (although I expect that some comments will tr= igger a discussion ;-) )

 

----

=A73.1

"Any codes in a received PDU that ar= e not recognised shall be

 &n= bsp; ignored."

 

 &n= bsp; Therefore the presence of TLVs in a PDU which are not allowed MUST

 &n= bsp; NOT cause the PDU itself to be rejected by the receiving IS.

 

 

I don’t think that “not recogni= zed” is the same as “not allowed”.

IMHO, the fact that unknown TLV=
 are to be ignored seem rather obvious as this is a designed goal of the TL=
V format. Yet, it’s good that [ISO10589] exp=
licitly stated it.

I definitely support that LSR defines the b= ehavior for TLV (and sub-TLV) which are not allowed. But I find the justifi= cation and reference debatable. I’d rather prefer that we remove it, or at least remove the “Therefore”. = I’d favor something along

OLD: Therefore

NEW: In addition, this document specifies t= hat

----

=A73.3

Registries associated with sub-TLVs are

   associat=
ed with the TLV Codepoints Registry and specify in which TLVs


   a given =
sub-TLV is allowed.  As with T=
LVs, it is required that sub-


   TLVs whi=
ch are NOT allowed MUST be ignored on receipt.


 


In addition to “not recognized”=
 and “not allowed by the registry” I believe that there are oth=
ers cases that would benefit from been clarified. Such as:


- not allowed by the specification (in a gi=
ven case/condition)


- REQUIRED (MUST) but not present e.g. R=
20;it MUST include this sub-TLV on point-to-point adjacencies”
https://tools.i=
etf.org/html/rfc5305#section-3.3


- Malformed (bad syntax)<=
/p>

- Correctly formed but illegal value (in a =
given case/condition)


 


I would like LSR to specify all types of er=
ror handling. Either in this document, or in another document if general er=
ror handling is considered out of scope
 of this document.


---


=A71


“&nbs=
p;  PDUs which are valid MUST be accepted even if an individual=
 TLV


   containe=
d within that PDU is invalid in some way.”


 


I wish “valid” be f=
urther defined. E.g. do you mean from a syntax/parsing point of view? Or do=
 you mean something else?


In particular [<=
span style=3D"color:windowtext;text-decoration:none;text-underline:none">IS=
O10589] use the terms “invalid PDU syntax”. If you m=
ean the same, I’d favor using the same terms. If you mean something d=
ifferent, please clarify the differences.


---


“&nbs=
p;  Nevertheless, a certain degree of "common knowledge&qu=
ot; is assumed on


   the part=
 of implementors in regards to these behaviors.”

 


What do you mean by that? That =
some “common knowledge” are required for the protocol to (corre=
ctly) work but that this knowledge is not written in a specification? If so=
, I believe LSR should write down such behavior.


 


“&nbs=
p;  This document serves to make explicit what is expected.  While it


   does not=
 alter any existing protocol behavior or specifications, it


   is inten=
ded to close any gaps between what is explicitly stated and


   what has=
 been "commonly understood".”


 


Same comment.=



A behavior is either specified =
or not specified. I don’t understand the meaning of the term “c=
ommonly understood”. 


 


Thank you,

Regards,


--Bruno


 


PS: To clarify, I’m copying Alvaro as=
 an individual contributor, as he expressed interest in error handling in B=
GP-LS which for some code points may be related
 to error handing in IS-IS.


 


_________________________________________=
___________________________________________________________________________=
_____


 


Ce message et ses pieces jointes peuvent =
contenir des informations confidentielles ou privilegiees et ne doivent don=
c


pas etre diffuses, exploites ou copies sa=
ns autorisation. Si vous avez recu ce message par erreur, veuillez le signa=
ler


a l'expediteur et le detruire ainsi que l=
es pieces jointes. Les messages electroniques etant susceptibles d'alterati=
on,


Orange decline toute responsabilite si ce=
 message a ete altere, deforme ou falsifie. Merci.


 


This message and its attachments may cont=
ain confidential or privileged information that may be protected by law;


they should not be distributed, used or c=
opied 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 l=
iable for messages that have been modified, changed or falsified.


Thank you.


______________________________________________________________________=
___________________________________________________

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 messages el=
ectroniques 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.
--_000_53C29892C857584299CBF5D05346208A48A28723OPEXCAUBM43corp_-- From nobody Mon Mar 25 06:53:05 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6E881203EF; Mon, 25 Mar 2019 06:53:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Z1h2PLlu; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=F/col4Am 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 rCrsf53ncjid; Mon, 25 Mar 2019 06:53:02 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A90AD12038C; Mon, 25 Mar 2019 06:53:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4439; q=dns/txt; s=iport; t=1553521981; x=1554731581; h=from:to:cc:subject:date:message-id:mime-version; bh=shC1IMM4ASwn2kUU/BqUzklEpCJfMv9LciNB4iwPwok=; b=Z1h2PLlueZR7IyYbcPuJLOKtTCkUsiYmCNYcr35AxJxO09EUC5uSKrEQ BqvdIyckMMEFh1B16OY36P6fzeBB3pNkKruMn5S86brCuCBZ0a1iGiGn5 pyZxv1+1Fol/8fW2RvBkrzUIx7ewQvuAoyL6Kkqb62ymXg/r7Fb8amPux M=; IronPort-PHdr: =?us-ascii?q?9a23=3AiTKaYRFMpLbierk3jcbmz51GYnJ96bzpIg4Y7I?= =?us-ascii?q?YmgLtSc6Oluo7vJ1Hb+e4w0Q3SRYuO7fVChqKWqK3mVWEaqbe5+HEZON0ETB?= =?us-ascii?q?oZkYMTlg0kDtSCDBjyJ/PnRyc7B89FElRi+iLzPA=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAwD33Jhc/4ENJK1jHAEBAQQBAQc?= =?us-ascii?q?EAQGBZYEPL1ADaHQECyeEDoNHA48qlRqESYJSA1QNAQEshEAZhHsiOBIBAQM?= =?us-ascii?q?BAQkBAwJtHAELhXQdAQE3AREBDD4CBDAnBA6DJwGBEUwDFQGjHwKKFHGBL4J?= =?us-ascii?q?4AQEFgkeCNhiCDAiBL4syF4F/gRABJx+KWDGCJoxzhB+UBwkCkzcZggKJSIg?= =?us-ascii?q?0ixyTKgIEAgQFAg4BAQWBZCGBVnAVZQGCQYIKg26KU3KBKI5+AQE?= X-IronPort-AV: E=Sophos;i="5.60,269,1549929600"; d="scan'208,217";a="539530534" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 25 Mar 2019 13:52:58 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id x2PDqw9C004107 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 25 Mar 2019 13:52:58 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Mon, 25 Mar 2019 08:52:58 -0500 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.1473.3; Mon, 25 Mar 2019 09:52:57 -0400 Received: from NAM01-SN1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Mon, 25 Mar 2019 08:52:56 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=shC1IMM4ASwn2kUU/BqUzklEpCJfMv9LciNB4iwPwok=; b=F/col4Am/6VlG9ezWhtLhY8emcezvtlCKRV1yATxE/n5PsIiQ7oUFk0GCCwMfiF2WPw5NygkS+8bAWnjAA2cBppVkPChwiOugWQ5Tt3nNwvXQPnD5kug0fhQK5QzOcmDAMgZpWdw5Tb94Cu7YuOAxmdX/FRBLuair3vManDCjXw= Received: from BN6PR1101MB2226.namprd11.prod.outlook.com (10.174.112.11) by BN6PR1101MB2145.namprd11.prod.outlook.com (10.174.112.138) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.15; Mon, 25 Mar 2019 13:52:55 +0000 Received: from BN6PR1101MB2226.namprd11.prod.outlook.com ([fe80::7c15:be1e:a2bd:7e28]) by BN6PR1101MB2226.namprd11.prod.outlook.com ([fe80::7c15:be1e:a2bd:7e28%5]) with mapi id 15.20.1730.019; Mon, 25 Mar 2019 13:52:55 +0000 From: "Acee Lindem (acee)" To: "draft-peng-lsr-network-slicing@ietf.org" CC: "lsr@ietf.org" , "teas@ietf.org" Thread-Topic: "Packet Network Slicing using Segment Routing" Thread-Index: AQHU4xILek5NKjADBEyPAWo56MO/iA== Date: Mon, 25 Mar 2019 13:52:54 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=acee@cisco.com; x-originating-ip: [2001:420:c0c8:1002::287] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: f067457c-fc7a-4b93-cafd-08d6b1292e8e x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:BN6PR1101MB2145; x-ms-traffictypediagnostic: BN6PR1101MB2145: x-microsoft-antispam-prvs: x-forefront-prvs: 0987ACA2E2 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(346002)(39860400002)(396003)(376002)(136003)(189003)(199004)(6486002)(478600001)(83716004)(316002)(68736007)(53936002)(476003)(6506007)(9326002)(81166006)(2906002)(2501003)(6436002)(82746002)(6116002)(5640700003)(256004)(54896002)(6512007)(7736002)(6306002)(8936002)(97736004)(6916009)(102836004)(2616005)(106356001)(14454004)(46003)(4326008)(450100002)(105586002)(99286004)(2351001)(486006)(54906003)(71190400001)(86362001)(8676002)(33656002)(81156014)(36756003)(5660300002)(25786009)(71200400001)(4744005)(186003)(440344003)(222603001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR1101MB2145; H:BN6PR1101MB2226.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: U0Y/2tEAQ8nZPM6z2CWFF7ED4S+A7yPjMvG2UYgK1yG0vMNBbIirjTZSQ9EksNt8QhR8DUlTeTPeRLOeIp8J0MVhlJxbIlf31zbggPCLpcxICbBF1zDvAUYh/rjwy5R/thsHVneVk7bR+BZXCPv58pgQqooEFVIJgBMXzNbtZxqKMyQf3+qqH/w08RrOiLuT2FSdL2bwicwExQMPomagwKsKDIgliS4e0o/sPfzUEmRWXrm43bYmuNA/7urveKLWFK/WyltJJfFO+Z8/GbilnU1b+Wtcy2K8GkTAnj0Jm9j7+N7kn19yUqRcq6Re922EL+aiZ94sHqylBMLqwfS7kTwAfz39mCDqd9Nj3MmKbhubAL3QBT4XfT/8s53S+hrOvLuReeI5DI6lYhx/emYPFp9yCL3d7zW6RTpdBMQTDmI= Content-Type: multipart/alternative; boundary="_000_DB700EDA6ACF4B179B9AC5C2939F89D7ciscocom_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: f067457c-fc7a-4b93-cafd-08d6b1292e8e X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Mar 2019 13:52:54.9867 (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-Transport-CrossTenantHeadersStamped: BN6PR1101MB2145 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.15, xch-aln-005.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: [Lsr] "Packet Network Slicing using Segment Routing" X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 13:53:04 -0000 --_000_DB700EDA6ACF4B179B9AC5C2939F89D7ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQXV0aG9ycywNCg0KSSByZWFkIHRoaXMgZHJhZnQgb24gdGhlIHBsYW5lIG9uIHRoZSB3YXkg dG8gUHJhZ3VlIGFuZCBJIGRvbuKAmXQgdGhpbmsgaXQgYmVsb25ncyBpbiBMU1IuIEkgYmVsaWV2 ZSBpdCBiZWxvbmdzIGluIFRFQXMgYXMgaXQgaXMgbW9yZSBhYm91dCB0aGUgcmVxdWlyZW1lbnQg YW5kIGZyYW1ld29yayBmb3IgVEUgc2xpY2luZyB0aGFuIGl0IGRvZXMgYWJvdXQgYWRkaW5nIHRo ZSBBZG1pbmlzdHJhdGl2ZSBJbnN0YW5jZSBJZGVudGlmaWVyIChBSUkpIHRvIHRoZSBPU1BGIGFu ZCBJUy1JUyBURSBlbmNvZGluZ3MuIFdlIHdpbGwgZ28gZm9yd2FyZCB3aXRoIHRoZSBwcmVzZW50 YXRpb24gb24gVGh1cnNkYXkgd2l0aCB0aGUgdW5kZXJzdGFuZGluZyB0aGF0IExTUiB3aWxsIG5v dCBhZG9wdCB0aGlzIHdvcmsuIElmIGl0IGlzIGFkb3B0ZWQgaW4gVEVBUywgd2UgY2FuIGRlY2lk ZSB3aGV0aGVyIHRvIHByb2NlZWQgd2l0aCBhIHNtYWxsIExTUiBkcmFmdCB3aXRoIGp1c3QgdGhl IG5ldyBBSUlzIG9yIHNpbXBseSBwcm92aWRlIHJldmlldyBhbmQgSUFOQSBjb2RlIHBvaW50cyBp biBvdXIgcmVnaXN0cmllcy4NCg0KVGhhbmtzLA0KQWNlZQ0K --_000_DB700EDA6ACF4B179B9AC5C2939F89D7ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <4DDC91C988501C4C8CF4D75D7ED53C56@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpz cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1z b0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4g MTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rp b24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBs YW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0i V29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTEuMHB0Ij5IaSBBdXRob3JzLCA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMS4wcHQiPkkgcmVhZCB0aGlzIGRyYWZ0IG9uIHRoZSBwbGFuZSBvbiB0aGUgd2F5IHRvIFBy YWd1ZSBhbmQgSSBkb27igJl0IHRoaW5rIGl0IGJlbG9uZ3MgaW4gTFNSLiBJIGJlbGlldmUgaXQg YmVsb25ncyBpbiBURUFzIGFzIGl0IGlzIG1vcmUgYWJvdXQgdGhlIHJlcXVpcmVtZW50IGFuZCBm cmFtZXdvcmsgZm9yIFRFIHNsaWNpbmcgdGhhbiBpdCBkb2VzIGFib3V0IGFkZGluZw0KIHRoZSBB ZG1pbmlzdHJhdGl2ZSBJbnN0YW5jZSBJZGVudGlmaWVyIChBSUkpIHRvIHRoZSBPU1BGIGFuZCBJ Uy1JUyBURSBlbmNvZGluZ3MuIFdlIHdpbGwgZ28gZm9yd2FyZCB3aXRoIHRoZSBwcmVzZW50YXRp b24gb24gVGh1cnNkYXkgd2l0aCB0aGUgdW5kZXJzdGFuZGluZyB0aGF0IExTUiB3aWxsIG5vdCBh ZG9wdCB0aGlzIHdvcmsuIElmIGl0IGlzIGFkb3B0ZWQgaW4gVEVBUywgd2UgY2FuIGRlY2lkZSB3 aGV0aGVyIHRvIHByb2NlZWQgd2l0aA0KIGEgc21hbGwgTFNSIGRyYWZ0IHdpdGgganVzdCB0aGUg bmV3IEFJSXMgb3Igc2ltcGx5IHByb3ZpZGUgcmV2aWV3IGFuZCBJQU5BIGNvZGUgcG9pbnRzIGlu IG91ciByZWdpc3RyaWVzLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu MHB0Ij5UaGFua3MsPGJyPg0KQWNlZTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9i b2R5Pg0KPC9odG1sPg0K --_000_DB700EDA6ACF4B179B9AC5C2939F89D7ciscocom_-- From nobody Mon Mar 25 16:32:55 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F8C312014C for ; Mon, 25 Mar 2019 16:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net 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 71-JwolI0Vdj for ; Mon, 25 Mar 2019 16:32:52 -0700 (PDT) Received: from gproxy6-pub.mail.unifiedlayer.com (outbound-ss-348.hostmonster.com [74.220.202.212]) (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 B006412001A for ; Mon, 25 Mar 2019 16:32:52 -0700 (PDT) Received: from cmgw11.unifiedlayer.com (unknown [10.9.0.11]) by gproxy6.mail.unifiedlayer.com (Postfix) with ESMTP id 8EEA11E204D for ; Mon, 25 Mar 2019 17:30:54 -0600 (MDT) Received: from box313.bluehost.com ([69.89.31.113]) by cmsmtp with ESMTP id 8Z3OhMY0pD8Rp8Z3OhhJZq; Mon, 25 Mar 2019 17:30:54 -0600 X-Authority-Reason: nr=8 X-Authority-Analysis: $(_cmae_reason DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID:From: References:Cc:To:Subject:Sender:Reply-To:Content-Transfer-Encoding:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=KwLl0JVOPwQMr2UMsBsTzDaAftPE426L9Q0kfVtKXm4=; b=zoxGasvSvoKoVQJ9ytay9eck7G E7HtZWmo1An3kl/JE4vQrQdIXfz5k5sbwwuHEYJKmQzsXdpABLD8BCDFhUCLaKtuf/Q+8OYaleBD7 CzRuwi7gWx/hJe+zrwY06hTFZ; Received: from pool-72-66-11-201.washdc.fios.verizon.net ([72.66.11.201]:59916 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1h8Z3O-000JYv-6L; Mon, 25 Mar 2019 17:30:54 -0600 To: "Acee Lindem (acee)" , "draft-peng-lsr-network-slicing@ietf.org" Cc: "lsr@ietf.org" , "teas@ietf.org" References: From: Lou Berger Message-ID: <728204ac-3c16-6a49-21de-2ad1b62a28ba@labn.net> Date: Tue, 26 Mar 2019 00:30:51 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------98B46BE6B3B222A866FBB24D" Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 72.66.11.201 X-Source-L: No X-Exim-ID: 1h8Z3O-000JYv-6L X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-72-66-11-201.washdc.fios.verizon.net ([IPv6:::1]) [72.66.11.201]:59916 X-Source-Auth: lberger@labn.net X-Email-Count: 3 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== X-Local-Domain: yes Archived-At: Subject: Re: [Lsr] [Teas] "Packet Network Slicing using Segment Routing" X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Mar 2019 23:32:54 -0000 This is a multi-part message in MIME format. --------------98B46BE6B3B222A866FBB24D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Authors, just resubmit with teas in place of lsr, when you do your update based on other feedback you received this week. Thanks, Lou (TEAS co-chair) On 3/25/2019 2:52 PM, Acee Lindem (acee) wrote: > > Hi Authors, > > I read this draft on the plane on the way to Prague and I don’t think > it belongs in LSR. I believe it belongs in TEAs as it is more about > the requirement and framework for TE slicing than it does about adding > the Administrative Instance Identifier (AII) to the OSPF and IS-IS TE > encodings. We will go forward with the presentation on Thursday with > the understanding that LSR will not adopt this work. If it is adopted > in TEAS, we can decide whether to proceed with a small LSR draft with > just the new AIIs or simply provide review and IANA code points in our > registries. > > Thanks, > Acee > > > _______________________________________________ > Teas mailing list > Teas@ietf.org > https://www.ietf.org/mailman/listinfo/teas --------------98B46BE6B3B222A866FBB24D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Authors, just resubmit with teas in place of lsr, when you do your update based on other feedback you received this week.

Thanks,

Lou

(TEAS co-chair)

On 3/25/2019 2:52 PM, Acee Lindem (acee) wrote:

Hi Authors,

 

I read this draft on the plane on the way to Prague and I don’t think it belongs in LSR. I believe it belongs in TEAs as it is more about the requirement and framework for TE slicing than it does about adding the Administrative Instance Identifier (AII) to the OSPF and IS-IS TE encodings. We will go forward with the presentation on Thursday with the understanding that LSR will not adopt this work. If it is adopted in TEAS, we can decide whether to proceed with a small LSR draft with just the new AIIs or simply provide review and IANA code points in our registries.

 

Thanks,
Acee


_______________________________________________
Teas mailing list
Teas@ietf.org
https://www.ietf.org/mailman/listinfo/teas
--------------98B46BE6B3B222A866FBB24D-- From nobody Tue Mar 26 02:01:37 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78332120296; Tue, 26 Mar 2019 02:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.198 X-Spam-Level: X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38nwuB9bPK_D; Tue, 26 Mar 2019 02:01:18 -0700 (PDT) Received: from mxhk.zte.com.cn (mxhk.zte.com.cn [63.217.80.70]) (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 1D35E120309; Tue, 26 Mar 2019 02:01:15 -0700 (PDT) Received: from mxct.zte.com.cn (unknown [192.168.164.217]) by Forcepoint Email with ESMTPS id 3D9F349AD8696E7E9EDA; Tue, 26 Mar 2019 17:01:11 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Forcepoint Email with ESMTPS id 025BBE2D2E7AD24E60B0; Tue, 26 Mar 2019 17:01:11 +0800 (CST) Received: from njxapp04.zte.com.cn ([10.41.132.203]) by mse01.zte.com.cn with SMTP id x2Q90vFn016605; Tue, 26 Mar 2019 17:00:57 +0800 (GMT-8) (envelope-from chen.ran@zte.com.cn) Received: from mapi (njxapp05[null]) by mapi (Zmail) with MAPI id mid203; Tue, 26 Mar 2019 17:00:58 +0800 (CST) Date: Tue, 26 Mar 2019 17:00:58 +0800 (CST) X-Zmail-TransId: 2afd5c99ea4a0ee07aec X-Mailer: Zmail v1.0 Message-ID: <201903261700586759048@zte.com.cn> Mime-Version: 1.0 From: To: , Cc: , Content-Type: multipart/mixed; boundary="=====_001_next=====" X-MAIL: mse01.zte.com.cn x2Q90vFn016605 Archived-At: Subject: Re: [Lsr] =?utf-8?q?//Re=3A__=5BTeas=5D_=22Packet_Network_Slicing_us?= =?utf-8?q?ing_Segment_Routing=22?= X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 09:01:31 -0000 --=====_001_next===== Content-Type: multipart/related; boundary="=====_002_next=====" --=====_002_next===== Content-Type: multipart/alternative; boundary="=====_003_next=====" --=====_003_next===== Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGkgY2hhaXJz77yMDQoNClRoYW5rIHlvdSB2ZXJ5IG11Y2ggZm9yIHlvdXIgc3VnZ2VzdGlvbnMu DQoNCkkgd2lsbCBjaGFuZ2UgdGhlIG5hbWUgb2YgdGhlIGRyYWZ0LCBhbmQgY29udGludWUgdGhl IGRyYWZ0IG9uIHRoZSB0ZWFzIHdHLg0KDQpSZWdhcmRzLA0KDQoNClJhbg0KDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LVJlOiBbTHNyXSBbVGVhc10gIlBhY2tldCBOZXR3b3JrIFNsaWNpbmcgdXNpbmcgU2VnbWVudCBS b3V0aW5nIg0KTG91IEJlcmdlciA8bGJlcmdlckBsYWJuLm5ldD4gTW9uLCAyNSBNYXJjaCAyMDE5 IDIzOjMyIFVUQ1Nob3cgaGVhZGVyDQoNCg0KQXV0aG9ycywganVzdCByZXN1Ym1pdCB3aXRoIHRl YXMgaW4gcGxhY2Ugb2YgbHNyLCB3aGVuIHlvdSBkbyB5b3VyIAp1cGRhdGUgYmFzZWQgb24gb3Ro ZXIgZmVlZGJhY2sgeW91IHJlY2VpdmVkIHRoaXMgd2Vlay4KClRoYW5rcywKCkxvdQoKKFRFQVMg Y28tY2hhaXIpCgpPbiAzLzI1LzIwMTkgMjo1MiBQTSwgQWNlZSBMaW5kZW0gKGFjZWUpIHdyb3Rl Ogo+Cj4gSGkgQXV0aG9ycywKPgo+IEkgcmVhZCB0aGlzIGRyYWZ0IG9uIHRoZSBwbGFuZSBvbiB0 aGUgd2F5IHRvIFByYWd1ZSBhbmQgSSBkb27igJl0IHRoaW5rIAo+IGl0IGJlbG9uZ3MgaW4gTFNS LiBJIGJlbGlldmUgaXQgYmVsb25ncyBpbiBURUFzIGFzIGl0IGlzIG1vcmUgYWJvdXQgCj4gdGhl IHJlcXVpcmVtZW50IGFuZCBmcmFtZXdvcmsgZm9yIFRFIHNsaWNpbmcgdGhhbiBpdCBkb2VzIGFi b3V0IGFkZGluZyAKPiB0aGUgQWRtaW5pc3RyYXRpdmUgSW5zdGFuY2UgSWRlbnRpZmllciAoQUlJ KSB0byB0aGUgT1NQRiBhbmQgSVMtSVMgVEUgCj4gZW5jb2RpbmdzLiBXZSB3aWxsIGdvIGZvcndh cmQgd2l0aCB0aGUgcHJlc2VudGF0aW9uIG9uIFRodXJzZGF5IHdpdGggCj4gdGhlIHVuZGVyc3Rh bmRpbmcgdGhhdCBMU1Igd2lsbCBub3QgYWRvcHQgdGhpcyB3b3JrLiBJZiBpdCBpcyBhZG9wdGVk IAo+IGluIFRFQVMsIHdlIGNhbiBkZWNpZGUgd2hldGhlciB0byBwcm9jZWVkIHdpdGggYSBzbWFs bCBMU1IgZHJhZnQgd2l0aCAKPiBqdXN0IHRoZSBuZXcgQUlJcyBvciBzaW1wbHkgcHJvdmlkZSBy ZXZpZXcgYW5kIElBTkEgY29kZSBwb2ludHMgaW4gb3VyIAo+IHJlZ2lzdHJpZXMuCj4KPiBUaGFu a3MsCj4gQWNlZQo+Cj4= --=====_003_next===== Content-Type: text/html ; charset="UTF-8" Content-Transfer-Encoding: base64 PGRpdiBjbGFzcz0iemNvbnRlbnRSb3ciPjxwPkhpIGNoYWlyc++8jDwvcD48cD5UaGFuayB5b3Ug dmVyeSBtdWNoIGZvciB5b3VyIHN1Z2dlc3Rpb25zLjwvcD5JIHdpbGwgY2hhbmdlIHRoZSBuYW1l IG9mIHRoZSBkcmFmdCwgYW5kIGNvbnRpbnVlIHRoZSBkcmFmdCBvbiB0aGUgdGVhcyB3Ry48YnI+ PGgzIHN0eWxlPSJib3gtc2l6aW5nOiBib3JkZXItYm94OyBtYXJnaW46IDJweCAwcHg7IGZvbnQt ZmFtaWx5OiAtYXBwbGUtc3lzdGVtLCBCbGlua01hY1N5c3RlbUZvbnQsICdTZWdvZSBVSScsIFJv Ym90bywgJ0hlbHZldGljYSBOZXVlJywgQXJpYWwsIHNhbnMtc2VyaWYsICdBcHBsZSBDb2xvciBF bW9qaScsICdTZWdvZSBVSSBFbW9qaScsICdTZWdvZSBVSSBTeW1ib2wnLCAnTm90byBDb2xvciBF bW9qaSc7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxpbmUtaGVpZ2h0OiAxLjI7IGNvbG9yOiByZ2Io MzMsIDM3LCA0MSk7IGZvbnQtc2l6ZTogMThweDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsgYmFja2dy b3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+PGJyPjwvaDM+PHA+UmVnYXJkcyw8YnI+ PC9wPjxwPlJhbjwvcD48aDMgc3R5bGU9ImJveC1zaXppbmc6IGJvcmRlci1ib3g7IG1hcmdpbjog MnB4IDBweDsgZm9udC1mYW1pbHk6IC1hcHBsZS1zeXN0ZW0sIEJsaW5rTWFjU3lzdGVtRm9udCwg J1NlZ29lIFVJJywgUm9ib3RvLCAnSGVsdmV0aWNhIE5ldWUnLCBBcmlhbCwgc2Fucy1zZXJpZiwg J0FwcGxlIENvbG9yIEVtb2ppJywgJ1NlZ29lIFVJIEVtb2ppJywgJ1NlZ29lIFVJIFN5bWJvbCcs ICdOb3RvIENvbG9yIEVtb2ppJzsgZm9udC13ZWlnaHQ6IG5vcm1hbDsgbGluZS1oZWlnaHQ6IDEu MjsgY29sb3I6IHJnYigzMywgMzcsIDQxKTsgZm9udC1zaXplOiAxOHB4OyB3aGl0ZS1zcGFjZTog bm9ybWFsOyBiYWNrZ3JvdW5kLWNvbG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij4tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LTwvaDM+PGgzIHN0eWxlPSJib3gtc2l6aW5nOiBib3JkZXItYm94OyBtYXJnaW46IDJweCAwcHg7 IGZvbnQtZmFtaWx5OiAtYXBwbGUtc3lzdGVtLCBCbGlua01hY1N5c3RlbUZvbnQsICdTZWdvZSBV SScsIFJvYm90bywgJ0hlbHZldGljYSBOZXVlJywgQXJpYWwsIHNhbnMtc2VyaWYsICdBcHBsZSBD b2xvciBFbW9qaScsICdTZWdvZSBVSSBFbW9qaScsICdTZWdvZSBVSSBTeW1ib2wnLCAnTm90byBD b2xvciBFbW9qaSc7IGZvbnQtd2VpZ2h0OiBub3JtYWw7IGxpbmUtaGVpZ2h0OiAxLjI7IGNvbG9y OiByZ2IoMzMsIDM3LCA0MSk7IGZvbnQtc2l6ZTogMThweDsgd2hpdGUtc3BhY2U6IG5vcm1hbDsg YmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+UmU6IFtMc3JdIFtUZWFzXSAi UGFja2V0IE5ldHdvcmsgU2xpY2luZyB1c2luZyBTZWdtZW50IFJvdXRpbmciPC9oMz48cCBpZD0i bXNnLWluZm8iIGNsYXNzPSJtc2ctaGVhZGVyIiBzdHlsZT0iYm94LXNpemluZzogYm9yZGVyLWJv eDsgbWFyZ2luLXRvcDogMHB4OyBtYXJnaW4tYm90dG9tOiAyMHB4OyBjb2xvcjogcmdiKDEyOCwg MTI4LCAxMjgpOyBmb250LWZhbWlseTogLWFwcGxlLXN5c3RlbSwgQmxpbmtNYWNTeXN0ZW1Gb250 LCAnU2Vnb2UgVUknLCBSb2JvdG8sICdIZWx2ZXRpY2EgTmV1ZScsIEFyaWFsLCBzYW5zLXNlcmlm LCAnQXBwbGUgQ29sb3IgRW1vamknLCAnU2Vnb2UgVUkgRW1vamknLCAnU2Vnb2UgVUkgU3ltYm9s JywgJ05vdG8gQ29sb3IgRW1vamknOyBsaW5lLWhlaWdodDogMjBweDsgd2hpdGUtc3BhY2U6IG5v cm1hbDsgYmFja2dyb3VuZC1jb2xvcjogcmdiKDI1NSwgMjU1LCAyNTUpOyI+PHNwYW4gaWQ9Im1z Zy1mcm9tIiBjbGFzcz0icGlwZSIgc3R5bGU9ImJveC1zaXppbmc6IGJvcmRlci1ib3g7Ij5Mb3Ug QmVyZ2VyICZsdDtsYmVyZ2VyQGxhYm4ubmV0Jmd0Ozwvc3Bhbj4mbmJzcDs8c3BhbiBpZD0ibXNn LWRhdGUiIGNsYXNzPSJwaXBlIiBzdHlsZT0iYm94LXNpemluZzogYm9yZGVyLWJveDsiPk1vbiwg MjUgTWFyY2ggMjAxOSAyMzozMiBVVEM8L3NwYW4+PGEgaWQ9InRvZ2dsZS1tc2ctaGVhZGVyIiBj bGFzcz0idG9nZ2xlIiBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNn L2xzci8tQnh4RDRXUmNtTkJxa0VpTnExQ0RERnF4RGsjIiBzdHlsZT0iYm94LXNpemluZzogYm9y ZGVyLWJveDsgY29sb3I6IHJnYig1MSwgMTIyLCAxODMpOyB0ZXh0LWRlY29yYXRpb246IG5vbmU7 IGJhY2tncm91bmQtY29sb3I6IHRyYW5zcGFyZW50OyI+U2hvdyBoZWFkZXI8L2E+PC9wPjxkaXYg Y2xhc3M9Im1zZy1wYXlsb2FkIiBzdHlsZT0iYm94LXNpemluZzogYm9yZGVyLWJveDsgY29sb3I6 IHJnYigzMywgMzcsIDQxKTsgZm9udC1mYW1pbHk6IC1hcHBsZS1zeXN0ZW0sIEJsaW5rTWFjU3lz dGVtRm9udCwgJ1NlZ29lIFVJJywgUm9ib3RvLCAnSGVsdmV0aWNhIE5ldWUnLCBBcmlhbCwgc2Fu cy1zZXJpZiwgJ0FwcGxlIENvbG9yIEVtb2ppJywgJ1NlZ29lIFVJIEVtb2ppJywgJ1NlZ29lIFVJ IFN5bWJvbCcsICdOb3RvIENvbG9yIEVtb2ppJzsgbGluZS1oZWlnaHQ6IDIwcHg7IHdoaXRlLXNw YWNlOiBub3JtYWw7IGJhY2tncm91bmQtY29sb3I6IHJnYigyNTUsIDI1NSwgMjU1KTsiPjxwcmUg Y2xhc3M9IndvcmR3cmFwIiBzdHlsZT0iYm94LXNpemluZzogYm9yZGVyLWJveDsgZm9udC1mYW1p bHk6IFNGTW9uby1SZWd1bGFyLCBNZW5sbywgTW9uYWNvLCBDb25zb2xhcywgJ0xpYmVyYXRpb24g TW9ubycsICdDb3VyaWVyIE5ldycsIG1vbm9zcGFjZTsgZm9udC1zaXplOiAxMi4yNXB4OyBtYXJn aW4tdG9wOiAwcHg7IG1hcmdpbi1ib3R0b206IDFyZW07IG92ZXJmbG93OiBhdXRvOyB3aGl0ZS1z cGFjZTogcHJlLXdyYXA7IHdvcmQtd3JhcDogbm9ybWFsOyB3b3JkLWJyZWFrOiBub3JtYWw7IHBh ZGRpbmc6IDBweDsiPkF1dGhvcnMsIGp1c3QgcmVzdWJtaXQgd2l0aCB0ZWFzIGluIHBsYWNlIG9m IGxzciwgd2hlbiB5b3UgZG8geW91ciAKdXBkYXRlIGJhc2VkIG9uIG90aGVyIGZlZWRiYWNrIHlv dSByZWNlaXZlZCB0aGlzIHdlZWsuCgpUaGFua3MsCgpMb3UKCihURUFTIGNvLWNoYWlyKQoKT24g My8yNS8yMDE5IDI6NTIgUE0sIEFjZWUgTGluZGVtIChhY2VlKSB3cm90ZToKJmd0OwomZ3Q7IEhp IEF1dGhvcnMsCiZndDsKJmd0OyBJIHJlYWQgdGhpcyBkcmFmdCBvbiB0aGUgcGxhbmUgb24gdGhl IHdheSB0byBQcmFndWUgYW5kIEkgZG9u4oCZdCB0aGluayAKJmd0OyBpdCBiZWxvbmdzIGluIExT Ui4gSSBiZWxpZXZlIGl0IGJlbG9uZ3MgaW4gVEVBcyBhcyBpdCBpcyBtb3JlIGFib3V0IAomZ3Q7 IHRoZSByZXF1aXJlbWVudCBhbmQgZnJhbWV3b3JrIGZvciBURSBzbGljaW5nIHRoYW4gaXQgZG9l cyBhYm91dCBhZGRpbmcgCiZndDsgdGhlIEFkbWluaXN0cmF0aXZlIEluc3RhbmNlIElkZW50aWZp ZXIgKEFJSSkgdG8gdGhlIE9TUEYgYW5kIElTLUlTIFRFIAomZ3Q7IGVuY29kaW5ncy4gV2Ugd2ls bCBnbyBmb3J3YXJkIHdpdGggdGhlIHByZXNlbnRhdGlvbiBvbiBUaHVyc2RheSB3aXRoIAomZ3Q7 IHRoZSB1bmRlcnN0YW5kaW5nIHRoYXQgTFNSIHdpbGwgbm90IGFkb3B0IHRoaXMgd29yay4gSWYg aXQgaXMgYWRvcHRlZCAKJmd0OyBpbiBURUFTLCB3ZSBjYW4gZGVjaWRlIHdoZXRoZXIgdG8gcHJv Y2VlZCB3aXRoIGEgc21hbGwgTFNSIGRyYWZ0IHdpdGggCiZndDsganVzdCB0aGUgbmV3IEFJSXMg b3Igc2ltcGx5IHByb3ZpZGUgcmV2aWV3IGFuZCBJQU5BIGNvZGUgcG9pbnRzIGluIG91ciAKJmd0 OyByZWdpc3RyaWVzLgomZ3Q7CiZndDsgVGhhbmtzLAomZ3Q7IEFjZWUKJmd0OwomZ3Q7PC9wcmU+ PC9kaXY+PHAgc3R5bGU9ImZvbnQtc2l6ZToxNHB4O2ZvbnQtZmFtaWx5OmFyaWFsOyI+PGJyPjwv cD48cCBzdHlsZT0iZm9udC1zaXplOjE0cHg7Zm9udC1mYW1pbHk6YXJpYWw7Ij48YnI+PC9wPjwv ZGl2Pg== --=====_003_next=====-- --=====_002_next=====-- --=====_001_next=====-- From nobody Tue Mar 26 16:31:59 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F4B41200B6; Tue, 26 Mar 2019 16:31:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.49 X-Spam-Level: X-Spam-Status: No, score=-14.49 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=GhbUDa4D; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=diMAIuSd 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 TC7nF0gIBlF2; Tue, 26 Mar 2019 16:31:53 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CDD7120112; Tue, 26 Mar 2019 16:31:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=34429; q=dns/txt; s=iport; t=1553643112; x=1554852712; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=vG4FNjhjuOLiocVR1dpGpwd2NrOpU84xoEitDzs6eeg=; b=GhbUDa4DBDPgih0j92FdO3GGIheJfxs7gmIXHBYD7+Cdq3VDn83KZRRe W0007ja2MMZmeh9h1nHMZGwt4PwBvoSs2uVNOoVAEXxNTrEsHyGgfGErP +wtg8J0lMkIuXD1E0h30PlZtohQCjWrhTRJ1m8t9hgiJ5Sxy8rb9u+yeq Q=; IronPort-PHdr: =?us-ascii?q?9a23=3A3xez1RJR2IyCbVnGHtmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeBvKd2lFGcW4Ld5roEkOfQv636EU04qZea+DFnEtRXUg?= =?us-ascii?q?Mdz8AfngguGsmAXEL6KuXgYjY1NM9DT1RiuXq8NBsdFQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAABRtZpc/4kNJK1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUwIBAQEBAQsBgQ4vKScDaHQECyeHVQOPL4JXiTiNVYE?= =?us-ascii?q?uFIEQA1QNAQElB4RAAoUiIjYHDQEBAwEBCQEDAm0cDIVKAQEBBC0TAQE3AQ8?= =?us-ascii?q?CAQgRBAEBIQEGByERFAkIAQEEAQ0FCIJPTIERTAMVAQIMoQcCihSCIIJ4AQE?= =?us-ascii?q?FhQoNC4IMAwWBLwGLMReBQD+BEAFGgkw+ghpHAQECAYErARIBISQHCYMFgia?= =?us-ascii?q?KI0KGL2mBHYVBi2EqNgkCh2GIGoNXggKFfYNMiDeLHYYGgTqLcgIEAgQFAg4?= =?us-ascii?q?BAQWBVAgpZXFwFYMngXMXDRaDS4UUhT9yAYEnjGGCPgEB?= X-IronPort-AV: E=Sophos;i="5.60,274,1549929600"; d="scan'208,217";a="538070277" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 26 Mar 2019 23:31:41 +0000 Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by alln-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x2QNVfgL031118 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 26 Mar 2019 23:31:41 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 26 Mar 2019 18:31:40 -0500 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 26 Mar 2019 19:31:39 -0400 Received: from NAM05-DM3-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 26 Mar 2019 18:31:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=o4c8Nxmw9ZxH8iqCouTRupuLw9VeAylHKsihx8TL5hg=; b=diMAIuSdNCQLLFKQi7b0KCXqpD078As2oH9OgSLkSLpzC/E1MIlMWcdMboQifX0ai1EWEU5ONXndzDhSHu7vikyX/Zdg1QG93DcXVuYhMLHoWMsf5VSc+IsyFstiyJ4OlcQgKZ0YIomil3EfuvoFnKkz0/MWyLwtUGfqGRKnZss= Received: from BYAPR11MB3638.namprd11.prod.outlook.com (20.178.237.19) by BYAPR11MB3702.namprd11.prod.outlook.com (20.178.237.219) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.15; Tue, 26 Mar 2019 23:31:37 +0000 Received: from BYAPR11MB3638.namprd11.prod.outlook.com ([fe80::a059:dd34:3c0c:214b]) by BYAPR11MB3638.namprd11.prod.outlook.com ([fe80::a059:dd34:3c0c:214b%2]) with mapi id 15.20.1730.017; Tue, 26 Mar 2019 23:31:37 +0000 From: "Les Ginsberg (ginsberg)" To: "bruno.decraene@orange.com" , "lsr@ietf.org" , "draft-ginsberg-lsr-isis-invalid-tlv@ietf.org" CC: Alvaro Retana Thread-Topic: draft-ginsberg-lsr-isis-invalid-tlv Thread-Index: AdTglBRECrXWUxPzTUGVlZ6TbJL//AACGNNgAONZ8GA= Date: Tue, 26 Mar 2019 23:31:37 +0000 Message-ID: References: <7565_1553251238_5C94BBA6_7565_333_1_53C29892C857584299CBF5D05346208A48A28540@OPEXCAUBM43.corporate.adroot.infra.ftgroup> <12194_1553252536_5C94C0B8_12194_166_1_53C29892C857584299CBF5D05346208A48A28723@OPEXCAUBM43.corporate.adroot.infra.ftgroup> In-Reply-To: <12194_1553252536_5C94C0B8_12194_166_1_53C29892C857584299CBF5D05346208A48A28723@OPEXCAUBM43.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ginsberg@cisco.com; x-originating-ip: [2001:420:c0c8:1007::b1] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 62937b22-811a-4fb6-2b9f-08d6b2433139 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:BYAPR11MB3702; x-ms-traffictypediagnostic: BYAPR11MB3702: x-ms-exchange-purlcount: 3 x-microsoft-antispam-prvs: x-forefront-prvs: 09888BC01D x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(376002)(39860400002)(136003)(366004)(346002)(396003)(199004)(189003)(53754006)(2201001)(97736004)(52536014)(476003)(7696005)(446003)(5660300002)(74316002)(9686003)(236005)(256004)(11346002)(46003)(102836004)(105586002)(790700001)(6116002)(53546011)(6506007)(4326008)(606006)(6436002)(99286004)(86362001)(54896002)(6306002)(6246003)(186003)(53936002)(229853002)(55016002)(76176011)(2906002)(81156014)(2501003)(7736002)(5024004)(8676002)(486006)(33656002)(81166006)(68736007)(478600001)(966005)(71200400001)(8936002)(110136005)(316002)(106356001)(25786009)(71190400001)(14444005)(14454004); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3702; H:BYAPR11MB3638.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: Z+rpFzZjjVjGSINej5ENaeQClclRmxinQCi5QoenkrwfOMwoBJfjiMsXjEkGdVcU0UZzOVRiTLiLL7Hc6+bQhwJJID//fE8cSsvkVu+evchf9q22AH3XrbPrjWbJF0GMOgGxR0g3ZJxo05QCfLWl1VpX2GGv5ls1hlXKlv1JhoIELAMteGstPfFr/U2ZIUsFt1kGEcRGZZig4Afq9vWswDPQlzJjyX5np5gJ5Yu+ExJU/IszqYHNwM6oQgggAR7t2/jPBzU3prHACXqGS6wm0UQoWRicdIY0CcORd9ItB/8dW6qSMA93doZx5beVTIyvKc4xWoDZHM7Fq1LL59Rs1oceZkuiNxu/YzOX2dt4SGQchnSIcxLEq7Xhj0w4RBIRzXUfaMHVPy9f3gRmn580se0gvTtTFIljusHdhla6qbI= Content-Type: multipart/alternative; boundary="_000_BYAPR11MB36387AE55811CCD16A022185C15F0BYAPR11MB3638namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 62937b22-811a-4fb6-2b9f-08d6b2433139 X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Mar 2019 23:31:37.6836 (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-Transport-CrossTenantHeadersStamped: BYAPR11MB3702 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.20, xch-aln-010.cisco.com X-Outbound-Node: alln-core-4.cisco.com Archived-At: Subject: Re: [Lsr] draft-ginsberg-lsr-isis-invalid-tlv X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Mar 2019 23:31:58 -0000 --_000_BYAPR11MB36387AE55811CCD16A022185C15F0BYAPR11MB3638namp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Bruno - Thanx for your comments. V2 of the draft has been posted which addresses a number of the issues. More inline. From: bruno.decraene@orange.com Sent: Friday, March 22, 2019 4:02 AM To: lsr@ietf.org; draft-ginsberg-lsr-isis-invalid-tlv@ietf.org Cc: Alvaro Retana Subject: RE: draft-ginsberg-lsr-isis-invalid-tlv =A74 The presence of a TLV (or sub-TLV) with content which does not conform to the relevant specification MUST NOT cause the LSP itself to be rejected. Again, thank you for your effort to clarify the specification. Given the "MUST", I feel that this sentence may be read as contradicting wi= th some other text. E.g " An implementation that implements HMAC-MD5 authentication and receives HMAC-MD5 Authentication Information MUST discard the PDU if the Authentication Value is incorrect." https://tools.ietf.org/html/rfc5304#section-2 Do you think it could be slightly rephrased? May be something along :s/reje= cted/considered invalid [or incorrect, although 10589 seems to use the = term "invalid PDU"] (as "rejected" could be read as similar to "discarded") [Les:] The behavior described in RFC 5304 is normative (i.e., MUST is both = intentional and correct) and implementations which conform to RFC 5304 will= indeed discard such a PDU. If your concern is about the word "discard" - this follows the terminology = used in ISO 10589 - for example Section 7.3.14.2e: "An Intermediate system receiving a Link State PDU with an incorrect LSP Ch= ecksum or with an invalid PDU syntax shall 1) generate a corruptedLSPReceived circuit event, 2) discard the PDU. Therefore I prefer to continue to use "discard". Thanks, --Bruno From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of bruno.decraene@orange.= com Sent: Friday, March 22, 2019 11:41 AM To: lsr@ietf.org; draft-ginsberg-lsr-isis-invalid-tlv@= ietf.org Cc: Alvaro Retana Subject: [Lsr] draft-ginsberg-lsr-isis-invalid-tlv Hi all, To be clear, I support that document. Thanks for writing it. I have some comments, mostly asking for even more of this/such document. (a= lthough I expect that some comments will trigger a discussion ;-) ) ---- =A73.1 "Any codes in a received PDU that are not recognised shall be ignored." Therefore the presence of TLVs in a PDU which are not allowed MUST NOT cause the PDU itself to be rejected by the receiving IS. I don't think that "not recognized" is the same as "not allowed". IMHO, the fact that unknown TLV are to be ignored seem rather obvious as th= is is a designed goal of the TLV format. Yet, it's good that [ISO10589] explicitly stated it. I definitely support that LSR defines the behavior for TLV (and sub-TLV) wh= ich are not allowed. But I find the justification and reference debatable. = I'd rather prefer that we remove it, or at least remove the "Therefore". I'= d favor something along OLD: Therefore NEW: In addition, this document specifies that ---- =A73.3 Registries associated with sub-TLVs are associated with the TLV Codepoints Registry and specify in which TLVs a given sub-TLV is allowed. As with TLVs, it is required that sub- TLVs which are NOT allowed MUST be ignored on receipt. In addition to "not recognized" and "not allowed by the registry" I believe= that there are others cases that would benefit from been clarified. Such a= s: - not allowed by the specification (in a given case/condition) - REQUIRED (MUST) but not present e.g. "it MUST include this sub-TLV on poi= nt-to-point adjacencies" https://tools.ietf.org/html/rfc5305#section-3.3 - Malformed (bad syntax) - Correctly formed but illegal value (in a given case/condition) I would like LSR to specify all types of error handling. Either in this doc= ument, or in another document if general error handling is considered out o= f scope of this document. [Les:] Error handling associated with incorrect encoding of a TLV is specif= ic to the individual TLV. It is the responsibility of the document which de= fines the TLV encoding to specify what to do if a particular field does not= conform to the set of allowed values, or if the TLV omits required informa= tion, or a Reserved bit is set, etc. I don't think using a central documen= t to define error handling for each individual TLV is a good option. --- =A71 " PDUs which are valid MUST be accepted even if an individual TLV contained within that PDU is invalid in some way." I wish "valid" be further defined. E.g. do you mean from a syntax/parsing p= oint of view? Or do you mean something else? In particular [ISO10589] use the terms "invalid PDU syntax". If you m= ean the same, I'd favor using the same terms. If you mean something differe= nt, please clarify the differences. --- " Nevertheless, a certain degree of "common knowledge" is assumed on the part of implementors in regards to these behaviors." What do you mean by that? That some "common knowledge" are required for the= protocol to (correctly) work but that this knowledge is not written in a s= pecification? If so, I believe LSR should write down such behavior. " This document serves to make explicit what is expected. While it does not alter any existing protocol behavior or specifications, it is intended to close any gaps between what is explicitly stated and what has been "commonly understood"." Same comment. A behavior is either specified or not specified. I don't understand the mea= ning of the term "commonly understood". [Les:] Revised text I believe addresses these points - which I think were v= alid comments. Please let us know if you think these points have been adequ= ately addressed. Les Thank you, Regards, --Bruno PS: To clarify, I'm copying Alvaro as an individual contributor, as he expr= essed interest in error handling in BGP-LS which for some code points may b= e related to error handing in IS-IS. ___________________________________________________________________________= ______________________________________________ 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 messages el= ectroniques 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. ___________________________________________________________________________= ______________________________________________ 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 messages el= ectroniques 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. --_000_BYAPR11MB36387AE55811CCD16A022185C15F0BYAPR11MB3638namp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Bruno –

 

Thanx for your comment= s.

 

V2 of the draft has be= en posted which addresses a number of the issues.

More inline.

 

From: bruno.decraene@orange.com <bruno.dec= raene@orange.com>
Sent: Friday, March 22, 2019 4:02 AM
To: lsr@ietf.org; draft-ginsberg-lsr-isis-invalid-tlv@ietf.org
Cc: Alvaro Retana <aretana.ietf@gmail.com>
Subject: RE: draft-ginsberg-lsr-isis-invalid-tlv

 

=A74=

   The presence of a TLV= (or sub-TLV) with content which does not

   conform to the releva= nt specification MUST NOT cause the LSP itself

   to be rejected.

 = ;

Again, thank you for your effort to clarify the spec= ification.

 

Given the “MUST”, I feel that this sente= nce may be read as contradicting with some other text. E.g

“   An implementation that implements HMAC-MD5 authent=
ication and

   receives HMAC-MD5 Aut= hentication Information MUST discard the PDU if

   the Authentication Va= lue is incorrect.”

https://tools.ietf.org/html/rfc5304#section-2

 

Do you think it could be slightly rephrased? May be = something along :s/rejected/considered invalid     [or = incorrect, although 10589 seems to use the term “invalid PDU”]<= o:p>

(as “rejected” could be read as similar = to “discarded”)

 

[Les:] The behav= ior described in RFC 5304 is normative (i.e., MUST is both intentional and = correct) and implementations which conform to RFC 5304 will indeed discard = such a PDU.

If your concern = is about the word “discard” – this follows the terminolog= y used in ISO 10589 – for example Section 7.3.14.2e:

 

“An Intermediate system receiving a Link State PDU with a= n incorrect LSP Checksum or with an invalid PDU syntax shall

 

1)       generate a corruptedLSPR= eceived circuit event,

 

2)  &n= bsp;      discard the PDU.

 

Therefore I pref= er to continue to use “discard”.

 

 

Thanks,

--Bruno

 

 

=  

Hi al= l,

=  

To be clear, I support = that document. Thanks for writing it.

I have some comments, m= ostly asking for even more of this/such document. (although I expect that s= ome comments will trigger a discussion ;-) )

 

----

=A73.1

"= ;Any codes in a received PDU that are not recognised shall be

 = ;  ignored."

=  

 = ;  Therefore the presence of TLVs in a PDU which are not allowed MUST<= o:p>

 = ;  NOT cause the PDU itself to be rejected by the receiving IS.

 

 

I don’t think tha= t “not recognized” is the same as “not allowed”.

IMHO, the fact that unknown TLV are to b=
e ignored seem rather obvious as this is a designed goal of the TLV format.=
 Yet, it’s good that [ISO10589] explicitly stated it.=

I definitely support th= at LSR defines the behavior for TLV (and sub-TLV) which are not allowed. Bu= t I find the justification and reference debatable. I’d rather prefer= that we remove it, or at least remove the “Therefore”. I’d favor something along

OLD: Therefore

NEW: In addition, this = document specifies that

----

=A73.3

Registries associated with sub-TLVs are
   associated with the TLV Code=
points Registry and specify in which TLVs
   a given sub-TLV is allowed.&=
nbsp; As with TLVs, it is required that sub-
   TLVs which are NOT allowed M=
UST be ignored on receipt.

 

In addition to “n= ot recognized” and “not allowed by the registry” I believ= e that there are others cases that would benefit from been clarified. Such = as:

- not allowed by the sp= ecification (in a given case/condition)

- REQUIRED (MUST) but n= ot present e.g. “it MUST include this sub-TLV on point-to-point adjac= encies” https://tools.i= etf.org/html/rfc5305#section-3.3

- Malformed (bad syntax= )

- Correctly formed but = illegal value (in a given case/condition)

 

I would like LSR to spe= cify all types of error handling. Either in this document, or in another do= cument if general error handling is considered out of scope of this documen= t.

 

[Les:] Error han= dling associated with incorrect encoding of a TLV is specific to the indivi= dual TLV. It is the responsibility of the document which defines the TLV en= coding to specify what to do if a particular field does not conform to the set of allowed values, or if the TLV omits r= equired information, or a Reserved bit is set,  etc. I don’t thi= nk using a central document to define error handling for each individual TL= V is a good option.

---

=A71
“   PDUs which ar=
e valid MUST be accepted even if an individual TLV
   contained within that PDU is=
 invalid in some way.”
 
I wish “valid” be further de=
fined. E.g. do you mean from a syntax/parsing point of view? Or do you mean=
 something else?
In particular [ISO10589] use the te=
rms “invalid PDU syntax”. If you mean the same, I’d favor=
 using the same terms. If you mean something different, please clarify the =
differences.
---
“   Nevertheless,=
 a certain degree of "common knowledge" is assumed on<=
/pre>

   the part of implementors in =
regards to these behaviors.”


 


What do you mean by that? That some R=
20;common knowledge” are required for the protocol to (correctly) wor=
k but that this knowledge is not written in a specification? If so, I belie=
ve LSR should write down such behavior.


 


“   This document=
 serves to make explicit what is expected.  While it


   does not alter any existing =
protocol behavior or specifications, it


   is intended to close any gap=
s between what is explicitly stated and


   what has been "commonly=
 understood".”


 


Same comment.


A behavior is either specified or not sp=
ecified. I don’t understand the meaning of the term “commonly u=
nderstood”. 


 

[Les:] Revised text I believe addresses these poi=
nts – which I think were valid comments. Please let us know if you th=
ink these points have been adequately addressed.<=
/pre>

 


   Les


Thank you,


Regards,


--Bruno


 


PS: To clarify, I’=
;m copying Alvaro as an individual contributor, as he expressed interest in=
 error handling in BGP-LS which for some code points may be related to erro=
r handing in IS-IS.


 


_______________________=
___________________________________________________________________________=
_______________________


 


Ce message et ses piece=
s jointes peuvent contenir des informations confidentielles ou privilegiees=
 et ne doivent donc


pas etre diffuses, expl=
oites ou copies sans autorisation. Si vous avez recu ce message par erreur,=
 veuillez le signaler


a l'expediteur et le de=
truire ainsi que les pieces jointes. Les messages electroniques etant susce=
ptibles d'alteration,


Orange decline toute re=
sponsabilite si ce message a ete altere, deforme ou falsifie. Merci.


 


This message and its at=
tachments may contain confidential or privileged information that may be pr=
otected by law;


they should not be dist=
ributed, used or copied without authorisation.


If you have received th=
is email in error, please notify the sender and delete this message and its=
 attachments.


As emails may be altere=
d, Orange is not liable for messages that have been modified, changed or fa=
lsified.


Thank you.


____________________________________________________=
_____________________________________________________________________<=
/o:p>


 


Ce message et ses pieces jointes peuvent contenir de=
s informations confidentielles ou privilegiees et ne doivent donc


pas etre diffuses, exploites ou copies sans autorisa=
tion. Si vous avez recu ce message par erreur, veuillez le signaler


a l'expediteur et le detruire ainsi que les pieces j=
ointes. Les messages 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 confide=
ntial or privileged information that may be protected by law;


they should not be distributed, used or copied witho=
ut authorisation.


If you have received this email in error, please not=
ify the sender and delete this message and its attachments.


As emails may be altered, Orange is not liable for m=
essages that have been modified, changed or falsified.

Thank you.
--_000_BYAPR11MB36387AE55811CCD16A022185C15F0BYAPR11MB3638namp_-- From nobody Thu Mar 28 22:53:19 2019 Return-Path: X-Original-To: lsr@ietf.org Delivered-To: lsr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id CC078120203; Thu, 28 Mar 2019 22:53:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lsr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.94.1 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lsr@ietf.org Message-ID: <155383878069.1511.1216157877571875782@ietfa.amsl.com> Date: Thu, 28 Mar 2019 22:53:00 -0700 Archived-At: Subject: [Lsr] I-D Action: draft-ietf-isis-segment-routing-extensions-23.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2019 05:53:11 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Link State Routing WG of the IETF. Title : IS-IS Extensions for Segment Routing Authors : Stefano Previdi Les Ginsberg Clarence Filsfils Ahmed Bashandy Hannes Gredler Bruno Decraene Filename : draft-ietf-isis-segment-routing-extensions-23.txt Pages : 33 Date : 2019-03-28 Abstract: Segment Routing (SR) allows for a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF). This draft describes the necessary IS-IS extensions that need to be introduced for Segment Routing operating on an MPLS data-plane. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-isis-segment-routing-extensions/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-isis-segment-routing-extensions-23 https://datatracker.ietf.org/doc/html/draft-ietf-isis-segment-routing-extensions-23 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-isis-segment-routing-extensions-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 Thu Mar 28 22:55:36 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44EA412021D; Thu, 28 Mar 2019 22:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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=a1PAe1On; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=FzqLBd7R 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 9TEhWPcdEHKJ; Thu, 28 Mar 2019 22:55:17 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6344812021F; Thu, 28 Mar 2019 22:55:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=64470; q=dns/txt; s=iport; t=1553838917; x=1555048517; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=BtYPqOlxahQ4MGs9huTawCeCk/cBp0DQk9yFO1YFKoQ=; b=a1PAe1OnK8ldXG2EutvCcvPV5vvO0aa5djycSq4qoi6z9GvstTibVGAG NTObTyK26HEKhb9bIlYiyTQaGg8RAwZt3UhaIX2wCpE61/SxQ/rSMXtTw NMZ6FDa9ccbKL08WrkDf15Za6hhn2Gdni/gaodhQ+zZVlXu3BMtVfV37N s=; IronPort-PHdr: =?us-ascii?q?9a23=3AKme5+BXK4jRCXwlEABnYY72EDqTV8LGuZFwc94?= =?us-ascii?q?YnhrRSc6+q45XlOgnF6O5wiEPSA9yJ8OpK3uzRta2oGXcN55qMqjgjSNRNTF?= =?us-ascii?q?dE7KdehAk8GIiAAEz/IuTtank1HcJZXlJ/8FmwMFNeH4D1YFiB6nA=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A9AAC5sp1c/4UNJK1bChoBAQEBAQI?= =?us-ascii?q?BAQEBBwIBAQEBgVIEAQEBAQsBgT0kLANodAQLJ4QOg0cDjzGCV36IOo1WgS4?= =?us-ascii?q?UgRADVA0BASUHgSoBgxUCF4UdFgw1CA0BAQMBAQkBAwJtHAyFSgEBAQMBGgE?= =?us-ascii?q?IEQwBASULBwEEBwQCAQgOAwEDAQEDAhEVAgICHxEVAgYIAgQBDQUIE4MIgV0?= =?us-ascii?q?DDQgBAgyeNAKKFHGBL4J4AQEFhQgNC4IMAwWBCyQBizEXgUA/gRABRoFOSTU?= =?us-ascii?q?+ghpHAQECAYEZAQwNEwICFhUPBhOCSzGCJoojIII5i2yLZio2CQKHaoNMQYQ?= =?us-ascii?q?Pg1mCA4YCg02GfYE9iyyBGIRxgTyISYMsAgQCBAUCDgEBBYFOATZCgRRwFYM?= =?us-ascii?q?nggoJAxeDS4UUhT9yAYEnjAGCTAEB?= X-IronPort-AV: E=Sophos;i="5.60,283,1549929600"; d="scan'208";a="544266056" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 29 Mar 2019 05:55:14 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by alln-core-11.cisco.com (8.15.2/8.15.2) with ESMTPS id x2T5tE0W007892 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 29 Mar 2019 05:55:14 GMT Received: from xhs-aln-001.cisco.com (173.37.135.118) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 29 Mar 2019 00:55:13 -0500 Received: from xhs-rtp-003.cisco.com (64.101.210.230) by xhs-aln-001.cisco.com (173.37.135.118) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Fri, 29 Mar 2019 00:55:12 -0500 Received: from NAM05-CO1-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.1473.3 via Frontend Transport; Fri, 29 Mar 2019 01:55:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=BtYPqOlxahQ4MGs9huTawCeCk/cBp0DQk9yFO1YFKoQ=; b=FzqLBd7RHQPztXgsPi1KqaKkUip1vS3m27RWR1MjmuCOV23OgMMsRmqxkd2t1xBdSescjlGWzNIJlWmwGk+Yy1E5lYYhuAy4D0N1YsOlPrrbREJO4ZenFartOkPNZyg/2y/9+Zt9L6yYlxbiWthOCxCRwmGANynqyTuyqE87WGQ= Received: from MN2PR11MB3647.namprd11.prod.outlook.com (20.178.251.26) by MN2PR11MB3551.namprd11.prod.outlook.com (20.178.250.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.17; Fri, 29 Mar 2019 05:55:10 +0000 Received: from MN2PR11MB3647.namprd11.prod.outlook.com ([fe80::f451:ee5d:e9de:9f6]) by MN2PR11MB3647.namprd11.prod.outlook.com ([fe80::f451:ee5d:e9de:9f6%5]) with mapi id 15.20.1750.014; Fri, 29 Mar 2019 05:55:10 +0000 From: "Les Ginsberg (ginsberg)" To: Alvaro Retana , "draft-ietf-isis-segment-routing-extensions@ietf.org" CC: Uma Chunduri , "lsr-chairs@ietf.org" , "lsr@ietf.org" Thread-Topic: AD Review of draft-ietf-isis-segment-routing-extensions-22 Thread-Index: AQHU32s2LXimbEtSIUKKc+aYWZUjdqYc4ArA Date: Fri, 29 Mar 2019 05:55:09 +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: spf=none (sender IP is ) smtp.mailfrom=ginsberg@cisco.com; x-originating-ip: [2001:420:c0c8:1007::b1] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6e0cc1aa-4286-4cc5-9a22-08d6b40b1a73 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:MN2PR11MB3551; x-ms-traffictypediagnostic: MN2PR11MB3551: x-ms-exchange-purlcount: 4 x-microsoft-antispam-prvs: x-forefront-prvs: 0991CAB7B3 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(39860400002)(346002)(366004)(136003)(376002)(13464003)(51444003)(189003)(37854004)(199004)(7696005)(99286004)(2906002)(6116002)(5660300002)(33656002)(316002)(66574012)(71190400001)(71200400001)(76176011)(52536014)(110136005)(476003)(30864003)(105586002)(5024004)(11346002)(106356001)(446003)(6506007)(54906003)(46003)(102836004)(486006)(186003)(53546011)(14444005)(256004)(478600001)(55016002)(9686003)(53936002)(6306002)(53946003)(6436002)(4326008)(68736007)(25786009)(229853002)(74316002)(14454004)(966005)(6246003)(305945005)(97736004)(2501003)(7736002)(81166006)(8676002)(86362001)(8936002)(81156014)(569006); DIR:OUT; SFP:1101; SCL:1; SRVR:MN2PR11MB3551; H:MN2PR11MB3647.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: k7tqJxU2+WoLolv3vUDXbB5uXzyK+bKZRZl7+9C3mf/KvT2leB/cFByshneFaVtoWm7i3eZTRNoPBMVkWwOtIxaBeoMIANrtESt3TiA4Fb4pk5SbJNZ+fg/iDqLJ2XQkf/iYLWepmBH0gk4hXhwDAQQDdR7o/9sktNRbTndVzJ0b7HXFUWt9MFalt9S2FCnrWXx12morufc+eAzzV6yP5EYMsJrAW6fl4PwBvKi06bE5wbmcGX01EUet4I6v/JMnWXKX5eP1kK/XSW713QSFxdyyPTXjf0ni83TXf/Foa64qDWFJvkT8fk27xqGg2Nm1PVrxakuSi80nCNGwUeKMi03V9EyZL70kiv/iBTeLwe/a07O8O+ZRXtqlEynf9r3azSNqw23eUCkaGPQd+VnPHA8PpIyK4JgHsb7ROcnCAGg= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 6e0cc1aa-4286-4cc5-9a22-08d6b40b1a73 X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Mar 2019 05:55:09.9246 (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-Transport-CrossTenantHeadersStamped: MN2PR11MB3551 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.23, xch-rcd-013.cisco.com X-Outbound-Node: alln-core-11.cisco.com Archived-At: Subject: Re: [Lsr] AD Review of draft-ietf-isis-segment-routing-extensions-22 X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2019 05:55:35 -0000 QWx2YXJvIC0NCg0KVGhhbnggZm9yIHRoZSBleGNlbGxlbnQgcmV2aWV3Lg0KDQpWMjMgb2YgdGhl IGRyYWZ0IGhhcyBiZWVuIHBvc3RlZA0KUGxlYXNlIHJldmlldyBhbmQgdmVyaWZ5IHRoYXQgYWxs IGNvbW1lbnRzIGhhdmUgYmVlbiBhZGRyZXNzZWQgdG8geW91ciBzYXRpc2ZhY3Rpb24gLSBzdWJq ZWN0IHRvIG15IHJlc3BvbnNlcyBpbmxpbmUgYmVsb3cuDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCj4gRnJvbTogQWx2YXJvIFJldGFuYSA8YXJldGFuYS5pZXRmQGdtYWlsLmNvbT4N Cj4gU2VudDogV2VkbmVzZGF5LCBNYXJjaCAyMCwgMjAxOSAzOjIxIFBNDQo+IFRvOiBkcmFmdC1p ZXRmLWlzaXMtc2VnbWVudC1yb3V0aW5nLWV4dGVuc2lvbnNAaWV0Zi5vcmcNCj4gQ2M6IFVtYSBD aHVuZHVyaSA8dW1hLmNodW5kdXJpQGh1YXdlaS5jb20+OyBsc3ItY2hhaXJzQGlldGYub3JnOw0K PiBsc3JAaWV0Zi5vcmcNCj4gU3ViamVjdDogQUQgUmV2aWV3IG9mIGRyYWZ0LWlldGYtaXNpcy1z ZWdtZW50LXJvdXRpbmctZXh0ZW5zaW9ucy0yMg0KPiANCj4gRGVhciBhdXRob3JzOg0KPiANCj4g SSBqdXN0IGZpbmlzaGVkIHJldmlld2luZyB0aGlzIGRvY3VtZW50LiAgUGxlYXNlIHRha2UgYSBs b29rIGF0IHRoZSBpbi1saW5lDQo+IGNvbW1lbnRzIGJlbG93LiAgSW4gZ2VuZXJhbCwgSSB0aGlu ayB0aGF0IHNvbWUgbW9yZSB3b3JrIGlzIG5lZWRlZC4gIEkgd2lsbA0KPiB3YWl0IGZvciB0aGF0 IGJlZm9yZSBzdGFydGluZyB0aGUgSUVURiBMYXN0IENhbGwuDQo+IA0KPiBUaGVyZSBpcyBhIHNp Z25pZmljYW50IGlzc3VlIHRoYXQgSSB3YW50IHRvIGhpZ2hsaWdodCBoZXJlICh0aGVyZSBhcmUg YWxzbw0KPiByZWxhdGVkIGNvbW1lbnRzIGluLWxpbmUpOg0KPiANCj4gLSDCpzIuMS4xLjIgdGFs a3MgYWJvdXQgaW50ZXJhY3Rpb24gd2l0aCByZmM3Nzk0IGFuZCBhIHRyYW5zaXRpb24gcGVyaW9k DQo+IHdoaWNoIGFwcGFyZW50bHkgZW5kcyBpbiB0aGlzIHNwZWNpZmljYXRpb24gbm90IGJlaW5n IHVzZWQuICBBbSBJIHJlYWRpbmcNCj4gdGhhdCBjb3JyZWN0bHk/DQo+IA0KPiBUaGFua3MhDQo+ IA0KPiBBbHZhcm8uDQo+IA0KPiBbTGluZSBudW1iZXJzIGNvbWUgZnJvbSBpZG5pdHMuXQ0KPiAN Cj4gLi4uDQo+IDEwNyAxLiAgSW50cm9kdWN0aW9uDQo+IA0KPiAxMDkgICBTZWdtZW50IFJvdXRp bmcgKFNSKSBhbGxvd3MgZm9yIGEgZmxleGlibGUgZGVmaW5pdGlvbiBvZiBlbmQtdG8tZW5kDQo+ IDExMCAgIHBhdGhzIHdpdGhpbiBJR1AgdG9wb2xvZ2llcyBieSBlbmNvZGluZyBwYXRocyBhcyBz ZXF1ZW5jZXMgb2YNCj4gMTExICAgdG9wb2xvZ2ljYWwgc3ViLXBhdGhzLCBjYWxsZWQgInNlZ21l bnRzIi4gIFRoZXNlIHNlZ21lbnRzIGFyZQ0KPiAxMTIgICBhZHZlcnRpc2VkIGJ5IHRoZSBsaW5r LXN0YXRlIHJvdXRpbmcgcHJvdG9jb2xzIChJUy1JUyBhbmQgT1NQRikuDQo+IDExMyAgIFByZWZp eCBzZWdtZW50cyByZXByZXNlbnQgYW4gZWNtcC1hd2FyZSBzaG9ydGVzdC1wYXRoIHRvIGEgcHJl Zml4IChvcg0KPiAxMTQgICBhIG5vZGUpLCBhcyBwZXIgdGhlIHN0YXRlIG9mIHRoZSBJR1AgdG9w b2xvZ3kuICBBZGphY2VuY3kgc2VnbWVudHMNCj4gMTE1ICAgcmVwcmVzZW50IGEgaG9wIG92ZXIg YSBzcGVjaWZpYyBhZGphY2VuY3kgYmV0d2VlbiB0d28gbm9kZXMgaW4gdGhlDQo+IDExNiAgIElH UC4gIEEgcHJlZml4IHNlZ21lbnQgaXMgdHlwaWNhbGx5IGEgbXVsdGktaG9wIHBhdGggd2hpbGUg YW4NCj4gMTE3ICAgYWRqYWNlbmN5IHNlZ21lbnQsIGluIG1vc3Qgb2YgdGhlIGNhc2VzLCBpcyBh IG9uZS1ob3AgcGF0aC4gIFNSJ3MNCj4gMTE4ICAgY29udHJvbC1wbGFuZSBjYW4gYmUgYXBwbGll ZCB0byBib3RoIElQdjYgYW5kIE1QTFMgZGF0YS1wbGFuZXMsIGFuZA0KPiAxMTkgICBkbyBub3Qg cmVxdWlyZSBhbnkgYWRkaXRpb25hbCBzaWduYWxpbmcgKG90aGVyIHRoYW4gdGhlIHJlZ3VsYXIg SUdQKS4NCj4gMTIwICAgRm9yIGV4YW1wbGUsIHdoZW4gdXNlZCBpbiBNUExTIG5ldHdvcmtzLCBT UiBwYXRocyBkbyBub3QgcmVxdWlyZSBhbnkNCj4gMTIxICAgTERQIG9yIFJTVlAtVEUgc2lnbmFs aW5nLiAgU3RpbGwsIFNSIGNhbiBpbnRlcm9wZXJhdGUgaW4gdGhlIHByZXNlbmNlDQo+IDEyMiAg IG9mIExTUHMgZXN0YWJsaXNoZWQgd2l0aCBSU1ZQIG9yIExEUC4NCj4gDQo+IFtuaXRdIHMvZWNt cC1hd2FyZS9FQ01QLWF3YXJlDQoNCltMZXM6XSBEb25lDQoNCj4gDQo+IA0KPiAxMjQgICBUaGVy ZSBhcmUgYWRkaXRpb25hbCBzZWdtZW50IHR5cGVzLCBlLmcuLCBCaW5kaW5nIFNJRCBkZWZpbmVk IGluDQo+IDEyNSAgIFtSRkM4NDAyXS4gIFRoaXMgZHJhZnQgYWxzbyBkZWZpbmVzIGFuIGFkdmVy dGlzZW1lbnQgZm9yIG9uZSB0eXBlIG9mDQo+IDEyNiAgIEJpbmRpbmdTSUQ6IHRoZSBNaXJyb3Ig Q29udGV4dCBzZWdtZW50Lg0KPiANCj4gW25pdF0gcy9CaW5kaW5nU0lEL0JpbmRpbmcgU0lEDQo+ IA0KW0xlczpdIERvbmUNCj4gDQo+IDEyOCAgIFRoaXMgZHJhZnQgZGVzY3JpYmVzIHRoZSBuZWNl c3NhcnkgSVMtSVMgZXh0ZW5zaW9ucyB0aGF0IG5lZWQgdG8gYmUNCj4gMTI5ICAgaW50cm9kdWNl ZCBmb3IgU2VnbWVudCBSb3V0aW5nIG9wZXJhdGluZyBvbiBhbiBNUExTIGRhdGEtcGxhbmUuDQo+ IA0KPiAxMzEgICBTZWdtZW50IFJvdXRpbmcgYXJjaGl0ZWN0dXJlIGlzIGRlc2NyaWJlZCBpbiBb UkZDODQwMl0uDQo+IA0KPiBbbml0XSBzL1NlZ21lbnQgUm91dGluZyBhcmNoaXRlY3R1cmUvVGhl IFNlZ21lbnQgUm91dGluZyBhcmNoaXRlY3R1cmUNCj4gDQo+IA0KPiAxMzMgICBTZWdtZW50IFJv dXRpbmcgdXNlIGNhc2VzIGFyZSBkZXNjcmliZWQgaW4gW1JGQzc4NTVdLg0KPiANCj4gMTM1IDIu ICBTZWdtZW50IFJvdXRpbmcgSWRlbnRpZmllcnMNCj4gDQo+IDEzNyAgIFNlZ21lbnQgUm91dGlu ZyBhcmNoaXRlY3R1cmUgKFtSRkM4NDAyXSkgZGVmaW5lcyBkaWZmZXJlbnQgdHlwZXMgb2YNCj4g MTM4ICAgU2VnbWVudCBJZGVudGlmaWVycyAoU0lEKS4gIFRoaXMgZG9jdW1lbnQgZGVmaW5lcyB0 aGUgSVMtSVMgZW5jb2RpbmdzDQo+IDEzOSAgIGZvciB0aGUgSUdQLVByZWZpeC1TSUQsIHRoZSBJ R1AtQWRqYWNlbmN5LVNJRCwgdGhlIElHUC1MQU4tQWRqYWNlbmN5LQ0KPiAxNDAgICBTSUQgYW5k IHRoZSBCaW5kaW5nLVNJRC4NCj4gDQo+IFtuaXRdIHMvKFtSRkM4NDAyXSkvW1JGQzg0MDJdDQo+ IA0KPiBbbml0XSBzL1NlZ21lbnQgUm91dGluZyBhcmNoaXRlY3R1cmUvVGhlIFNlZ21lbnQgUm91 dGluZyBhcmNoaXRlY3R1cmUNCj4gDQo+IFttYWpvcl0gcmZjODQwMiBkb2Vzbid0IHVzZSB0aGUg bmFtZXMgYWJvdmUuICBQbGVhc2UgYmUgY29uc2lzdGVudC4NCj4gDQpbTGVzOl0gRG9uZS4NCg0K PiANCj4gMTQyIDIuMS4gIFByZWZpeCBTZWdtZW50IElkZW50aWZpZXIgKFByZWZpeC1TSUQgU3Vi LVRMVikNCj4gDQo+IDE0NCAgIEEgbmV3IElTLUlTIHN1Yi1UTFYgaXMgZGVmaW5lZDogdGhlIFBy ZWZpeCBTZWdtZW50IElkZW50aWZpZXIgc3ViLVRMVg0KPiAxNDUgICAoUHJlZml4LVNJRCBzdWIt VExWKS4NCj4gDQo+IDE0NyAgIFRoZSBQcmVmaXgtU0lEIHN1Yi1UTFYgY2FycmllcyB0aGUgU2Vn bWVudCBSb3V0aW5nIElHUC1QcmVmaXgtU0lEIGFzDQo+IDE0OCAgIGRlZmluZWQgaW4gW1JGQzg0 MDJdLiAgVGhlICdQcmVmaXggU0lEJyBNVVNUIGJlIHVuaXF1ZSB3aXRoaW4gYSBnaXZlbg0KPiAx NDkgICBJR1AgZG9tYWluICh3aGVuIHRoZSBMLWZsYWcgaXMgbm90IHNldCkuICBUaGUgJ1ByZWZp eCBTSUQnIE1VU1QgY2FycnkNCj4gMTUwICAgYW4gaW5kZXggKHdoZW4gdGhlIFYtZmxhZyBpcyBu b3Qgc2V0KSB0aGF0IGRldGVybWluZXMgdGhlIGFjdHVhbCBTSUQvDQo+IDE1MSAgIGxhYmVsIHZh bHVlIGluc2lkZSB0aGUgc2V0IG9mIGFsbCBhZHZlcnRpc2VkIFNJRC9sYWJlbCByYW5nZXMgb2Yg YQ0KPiAxNTIgICBnaXZlbiByb3V0ZXIuICBBIHJlY2VpdmluZyByb3V0ZXIgdXNlcyB0aGUgaW5k ZXggdG8gZGV0ZXJtaW5lIHRoZQ0KPiAxNTMgICBhY3R1YWwgU0lEL2xhYmVsIHZhbHVlIGluIG9y ZGVyIHRvIGNvbnN0cnVjdCBmb3J3YXJkaW5nIHN0YXRlIHRvIGENCj4gMTU0ICAgcGFydGljdWxh ciBkZXN0aW5hdGlvbiByb3V0ZXIuDQo+IA0KPiBbbWFqb3JdIFdoYXQgaWYgdGhlIFByZWZpeCBT SUQgaXMgbm90IHVuaXF1ZT8gIFdoYXQgc2hvdWxkIHRoZSByZWNlaXZlciBkbz8NCj4gDQpbTGVz Ol0gVGhpcyBpcyBub3Qgd2l0aGluIHRoZSBwdXJ2aWV3IG9mIHRoZSBJR1AgZHJhZnRzLiBUaGlz IGlzIG5vdyBjb3ZlcmVkIGluIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm LXNwcmluZy1zZWdtZW50LXJvdXRpbmctbXBscy0xOCNzZWN0aW9uLTIuNSBhbmQgaXQgaXMgbm90 IGFwcHJvcHJpYXRlIGZvciBJR1AgZHJhZnRzIHRvIGRpc2N1c3MgdGhpcyBpc3N1ZSBub3IgcmVm ZXJlbmNlIHRoZSBzb2x1dGlvbiBhcyBpdCBpcyBub3QgdGhlIElHUCB3aGljaCBpcyByZXNwb25z aWJsZSBmb3IgaW1wbGVtZW50aW5nIHRoZSBzb2x1dGlvbi4NCg0KPiBbbWFqb3JdICIuLi5NVVNU IGNhcnJ5IGFuIGluZGV4Li4udGhhdCBkZXRlcm1pbmVzIHRoZSBhY3R1YWwgU0lEL2xhYmVsDQo+ IHZhbHVlLi4uIiAgV2hhdCBhcmUgeW91IHRyeWluZyB0byBzcGVjaWZ5IHdpdGggdGhpcyAiTVVT VCI/ICBUaGUNCj4gZGVzY3JpcHRpb24gb2YgdGhlIFYtZmxhZyAoYmVsb3cpIGFscmVhZHkgcG9p bnRzIGF0IHRoZSB2YWx1ZSBiZWluZyBhbg0KPiBpbmRleCwgYnV0IHRoZSBxdWFsaWZpY2F0aW9u ICgidGhhdCBkZXRlcm1pbmVzLi4uIikgbWFrZXMgdGhlIGVuZm9yY2VtZW50DQo+IG9mIHRoaXMg Ik1VU1QiIG1vcmUgY29tcGxleDogdGhlIHJlY2VpdmVyIGhhcyB0byB2ZXJpZnkgdGhhdCB0aGUg aW5kZXgNCj4gYWN0dWFsbHkgcmVzdWx0cyBpbiBhIFNJRC9sYWJlbCBpbnNpZGUgYSByYW5nZSBm b3IgaXQgdG8gYmUgdmFsaWQuICAgV2hhdA0KPiBzaG91bGQgdGhlIHJlY2VpdmVyIGRvIGlmIHRo YXQgaXMgbm90IHRoZSBjYXNlPw0KPiANCj4gU3VnZ2VzdGlvbjogUmVhcnJhbmdlIHRoZSB0ZXh0 IHNvIHRoYXQgdGhlIFRMViBhbmQgaXRzIGZpZWxkcyBhcmUgZGVzY3JpYmVkDQo+IGZpcnN0LiAg SSB0aGluayB0aGF0IHRoZW4gc29tZSBvZiB0aGUgdGV4dCBhYm92ZSB3b24ndCBiZSBuZWVkZWQu DQo+IA0KW0xlczpdIERvbmUuDQo+IA0KPiAxNTYgICBJbiBtYW55IHVzZS1jYXNlcyBhICdzdGFi bGUgdHJhbnNwb3J0JyBJUCBBZGRyZXNzIGlzIG92ZXJsb2FkZWQgYXMgYW4NCj4gMTU3ICAgaWRl bnRpZmllciBvZiBhIGdpdmVuIG5vZGUuICBCZWNhdXNlIHRoZSBJUCBQcmVmaXhlcyBtYXkgYmUg cmUtDQo+IDE1OCAgIGFkdmVydGlzZWQgaW50byBvdGhlciBsZXZlbHMgdGhlcmUgbWF5IGJlIHNv bWUgYW1iaWd1aXR5IChlLmcuDQo+IDE1OSAgIE9yaWdpbmF0aW5nIHJvdXRlciB2cy4gTDFMMiBy b3V0ZXIpIGZvciB3aGljaCBub2RlIGEgcGFydGljdWxhciBJUA0KPiAxNjAgICBwcmVmaXggc2Vy dmVzIGFzIGlkZW50aWZpZXIuICBUaGUgUHJlZml4LVNJRCBzdWItVExWIGNvbnRhaW5zIHRoZQ0K PiAxNjEgICBuZWNlc3NhcnkgZmxhZ3MgdG8gZGlzYW1iaWd1YXRlIElQIFByZWZpeCB0byBub2Rl IG1hcHBpbmdzLg0KPiAxNjIgICBGdXJ0aGVybW9yZSBpZiBhIGdpdmVuIG5vZGUgaGFzIHNldmVy YWwgJ3N0YWJsZSB0cmFuc3BvcnQnIElQDQo+IDE2MyAgIGFkZHJlc3NlcyB0aGVyZSBhcmUgZmxh Z3MgdG8gZGlmZmVyZW50aWF0ZSB0aG9zZSBhbW9uZyBvdGhlciBJUA0KPiAxNjQgICBQcmVmaXhl cyBhZHZlcnRpc2VkIGZyb20gYSBnaXZlbiBub2RlLg0KPiANCj4gW21pbm9yXSBBZ2FpbiwgdGhp cyB0ZXh0IG1heSBiZSBjbGVhcmVyIGlmIHRoZSBUTFYgZGVzY3JpcHRpb24gd2FzDQo+IHByZXNl bnRlZCBmaXJzdC4gIElmIHlvdSBkZWNpZGUgbm90IHRvIHJlYXJyYW5nZSB0aGUgdGV4dCwgYXQg bGVhc3QgcHV0DQo+IGZvcndhcmQgcmVmZXJlbmNlcyBzbyByZWFkZXJzIGNhbiBsb29rIGZvcndh cmQgdG8gZmluZCBvdXQgaG93IHRoZQ0KPiBzdGF0ZW1lbnQgYWJvdmUgaXMgYWNoaWV2ZWQuDQo+ IA0KW0xlczpdIFRleHQgcmVvcmRlcmVkIGFzIHlvdSBzdWdnZXN0ZWQuDQoNCj4gDQo+IC4uLg0K PiAxODAgICBXaGVuIHRoZSBJUCBSZWFjaGFiaWxpdHkgVExWIGlzIHByb3BhZ2F0ZWQgYWNyb3Nz IGxldmVsIGJvdW5kYXJpZXMsDQo+IDE4MSAgIHRoZSBQcmVmaXgtU0lEIHN1Yi1UTFYgU0hPVUxE IGJlIGtlcHQuDQo+IA0KPiBbbWFqb3JdIFdoZW4gd291bGQgdGhpcyBzdWItVExWIG5vdCBiZSBr ZXB0PyAgSU9XLCB3aHkgaXMgdGhhdCBub3QgYSAiTVVTVCI/DQo+IA0KDQpbTGVzOl0gVGhpcyB0 ZXh0IHdhcyByZW1vdmVkIGFzIGl0IGlzIG5vdCBuZWVkZWQgYW5kIC0gYXMgeW91IHBvaW50IG91 dCAtIGNvbnRyYWRpY3RzIGVhcmxpZXIgdGV4dCB3aGljaCBzcGVjaWZpZXMgTVVTVC4NCg0KPiDC pzIuMS4yOiAiVGhlIFByZWZpeC1TSUQgc3ViLVRMViBNVVNUIGJlIHByZXNlcnZlZCB3aGVuIHRo ZSBJUCBSZWFjaGFiaWxpdHkNCj4gVExWDQo+IGdldHMgcHJvcGFnYXRlZCBhY3Jvc3MgbGV2ZWwg Ym91bmRhcmllcy4iDQo+IA0KPiBJJ20gbm90IHNheWluZyB0aGF0IG9uZSB3YXkgaXMgY29ycmVj dC4uLmVpdGhlciBvbmUgbWF5IGJlLiAgSnVzdCBiZQ0KPiBjb25zaXN0ZW50Lg0KPiANCj4gW21p bm9yXSBJJ20gYXNzdW1pbmcgdGhhdCAiSVAgUmVhY2hhYmlsaXR5IFRMViIgbWVhbnMgb25lIG9m IHRoZSBUTFZzDQo+IGFib3ZlLCB0cnVlPyAgSXQgbWF5IGJlIHdvcnRoIGNsYXJpZnlpbmcgdGhh dC4NCj4gDQpbTGVzOl0gWW91IGFyZSBjb3JyZWN0LiBDaGFuZ2VkIHRvIHRoZSBnZW5lcmljIHRl cm0gUHJlZml4IFJlYWNoYWJpbGl0eS4NCg0KPiANCj4gMTgzICAgVGhlIFByZWZpeC1TSUQgc3Vi LVRMViBoYXMgdGhlIGZvbGxvd2luZyBmb3JtYXQ6DQo+IA0KPiAxODUgICAgMCAgICAgICAgICAg ICAgICAgICAxICAgICAgICAgICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMw0KPiAxODYg ICAgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYg NyA4IDkgMCAxDQo+IDE4NyAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+IDE4OCAgIHwgICBUeXBlICAgICAgICB8ICAg ICBMZW5ndGggICAgfCAgICAgRmxhZ3MgICAgIHwgICBBbGdvcml0aG0gICB8DQo+IDE4OSAgICst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rDQo+IDE5MCAgIHwgICAgICAgICAgICAgICAgICAgICAgICBTSUQvSW5kZXgvTGFiZWwg KHZhcmlhYmxlKSAgICAgICAgICAgICB8DQo+IDE5MSAgICstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+IA0KPiAxOTMgICB3 aGVyZToNCj4gDQo+IDE5NSAgICAgIFR5cGU6IFRCRCwgc3VnZ2VzdGVkIHZhbHVlIDMNCj4gDQo+ IFttYWpvcl0gVGhpcyB2YWx1ZSAoYW5kIGFsbCB0aGUgb3RoZXJzIGluIHRoZSBkb2N1bWVudCkg YXJlIG5vdCAic3VnZ2VzdGVkDQo+IHZhbHVlcyIsIHRoZXkgaGF2ZSBiZWVuIGFscmVhZHkgYWxs b2NhdGVkIGJ5IElBTkEuICBQbGVhc2UgdXBkYXRlIHRoZQ0KPiBpbmRpdmlkdWFsIGRlc2NyaXB0 aW9ucyBhbmQgdGhlIElBTkEgQ29uc2lkZXJhdGlvbnMgc2VjdGlvbiBhY2NvcmRpbmdseS4NCj4g DQpbTGVzOl0gRG9uZS4NCj4gDQo+IDE5NyAgICAgIExlbmd0aDogdmFyaWFibGUuDQo+IA0KPiBb bWlub3JdIFllcywgdmFyaWFibGUsIGJ1dCBpdCBjYW4gb25seSBoYXZlIHR3byB2YWx1ZXM6IDUg b3IgNi4NCj4gDQpbTGVzOl0gRG9uZS4NCj4gDQo+IDE5OSAgICAgIEZsYWdzOiAxIG9jdGV0IGZp ZWxkIG9mIGZvbGxvd2luZyBmbGFnczoNCj4gDQo+IDIwMSAgICAwIDEgMiAzIDQgNSA2IDcNCj4g MjAyICAgKy0rLSstKy0rLSstKy0rLSsNCj4gMjAzICAgfFJ8TnxQfEV8VnxMfCAgIHwNCj4gMjA0 ICAgKy0rLSstKy0rLSstKy0rLSsNCj4gDQo+IDIwNiAgICAgIHdoZXJlOg0KPiANCj4gMjA4ICAg ICAgICAgUi1GbGFnOiBSZS1hZHZlcnRpc2VtZW50IGZsYWcuICBJZiBzZXQsIHRoZW4gdGhlIHBy ZWZpeCB0bw0KPiAyMDkgICAgICAgICB3aGljaCB0aGlzIFByZWZpeC1TSUQgaXMgYXR0YWNoZWQs IGhhcyBiZWVuIHByb3BhZ2F0ZWQgYnkgdGhlDQo+IDIxMCAgICAgICAgIHJvdXRlciBlaXRoZXIg ZnJvbSBhbm90aGVyIGxldmVsIChpLmUuLCBmcm9tIGxldmVsLTEgdG8gbGV2ZWwtMg0KPiAyMTEg ICAgICAgICBvciB0aGUgb3Bwb3NpdGUpIG9yIGZyb20gcmVkaXN0cmlidXRpb24gKGUuZy46IGZy b20gYW5vdGhlcg0KPiAyMTIgICAgICAgICBwcm90b2NvbCkuDQo+IA0KPiBbbWFqb3JdIFNob3Vs ZCBpdCBiZSB1c2VkIHRvIGF2b2lkIGxvb3BpbmcgYXMgd2VsbD8gIE9yIGlzIHRoZXJlIG5vIHJp c2sgb2YNCj4gdGhhdCBpbiB0aGlzIGNhc2U/DQo+IA0KW0xlczpdIFByZXZlbnRpb24gb2YgbG9v cGluZyBpcyBkb25lIHRocm91Z2ggdXNlIG9mIHRoZSBELWJpdCBhcyBzcGVjaWZpZWQgaW4gUkZD IDUzMDUuIFIgZmxhZyBoYXMgbm8gcm9sZSBpbiB0aGF0LiBJdCBleGlzdHMgdG8gaWRlbnRpZnkg YSBwcmVmaXggd2hpY2ggaXMgbm90IGxvY2FsbHkgY29ubmVjdGVkIHRvIHRoZSBhZHZlcnRpc2lu ZyByb3V0ZXIgKGVpdGhlciBsZWFrZWQgYmV0d2VlbiBsZXZlbHMgb3IgcmVkaXN0cmlidXRlZCBm cm9tIGFub3RoZXIgcHJvdG9jb2wpLg0KDQo+IA0KPiAuLi4NCj4gMjM2ICAgICAgICAgT3RoZXIg Yml0czogTVVTVCBiZSB6ZXJvIHdoZW4gb3JpZ2luYXRlZCBhbmQgaWdub3JlZCB3aGVuDQo+IDIz NyAgICAgICAgIHJlY2VpdmVkLg0KPiANCj4gW21ham9yXSBEbyB5b3UgZXhwZWN0IElBTkEgdG8g aGFuZGxlIHRoZSBhc3NpZ25tZW50IG9mIHRob3NlIG90aGVyIGJpdHM/DQo+IA0KW0xlczpdIE5v LiBCaXQgZGVmaW5pdGlvbnMgc3BlY2lmaWNhbGx5IGFzc29jaWF0ZWQgd2l0aCBhIFRMVi9zdWIt VExWIGRlZGljYXRlZCB0byBwYXJ0aWN1bGFyIGZ1bmN0aW9uYWxpdHkgaGlzdG9yaWNhbGx5IGFy ZSBOT1QgbWFuYWdlZCB2aWEgYW4gSUFOQSByZWdpc3RyeS4gQW55IGFkZGl0aW9uYWwgYml0IGRl ZmluaXRpb25zIHJlcXVpcmVkIHdpbGwgYmUgc3BlY2lmaWVkIGluIGEgbmV3IGRyYWZ0IHdoaWNo IGRlZmluZXMgdGhlIGFkZGl0aW9uYWwgZnVuY3Rpb25hbGl0eS4NCg0KPiANCj4gMjM5ICAgICAg QWxnb3JpdGhtOiB0aGUgcm91dGVyIG1heSB1c2UgdmFyaW91cyBhbGdvcml0aG1zIHdoZW4gY2Fs Y3VsYXRpbmcNCj4gMjQwICAgICAgcmVhY2hhYmlsaXR5IHRvIG90aGVyIG5vZGVzIG9yIHRvIHBy ZWZpeGVzIGF0dGFjaGVkIHRvIHRoZXNlDQo+IDI0MSAgICAgIG5vZGVzLiAgQWxnb3JpdGhtcyBp ZGVudGlmaWVycyBhcmUgZGVmaW5lZCBpbiBTZWN0aW9uIDMuMi4NCj4gMjQyICAgICAgRXhhbXBs ZXMgb2YgdGhlc2UgYWxnb3JpdGhtcyBhcmUgbWV0cmljIGJhc2VkIFNob3J0ZXN0IFBhdGggRmly c3QNCj4gMjQzICAgICAgKFNQRiksIHZhcmlvdXMgc29ydHMgb2YgQ29uc3RyYWluZWQgU1BGLCBl dGMuICBUaGUgYWxnb3JpdGhtIGZpZWxkDQo+IDI0NCAgICAgIG9mIHRoZSBQcmVmaXgtU0lEIGNv bnRhaW5zIHRoZSBpZGVudGlmaWVyIG9mIHRoZSBhbGdvcml0aG0gdGhlDQo+IDI0NSAgICAgIHJv dXRlciBoYXMgdXNlZCBpbiBvcmRlciB0byBjb21wdXRlIHRoZSByZWFjaGFiaWxpdHkgb2YgdGhl IHByZWZpeA0KPiAyNDYgICAgICB0byB3aGljaCB0aGUgUHJlZml4LVNJRCBpcyBhc3NvY2lhdGVk Lg0KPiANCj4gMjQ4ICAgICAgQXQgb3JpZ2luYXRpb24sIHRoZSBQcmVmaXgtU0lEIGFsZ29yaXRo bSBmaWVsZCBNVVNUIGJlIHNldCB0byAwIG9yDQo+IDI0OSAgICAgIHRvIGFueSB2YWx1ZSBhZHZl cnRpc2VkIGluIHRoZSBTUi1BbGdvcml0aG0gc3ViLVRMViAoU2VjdGlvbiAzLjIpLg0KPiANCj4g W21ham9yXSBXaGF0IHNob3VsZCBhIHJlY2VpdmVyIGRvIGlmIHRoZSBBbGdvcml0aG0gdmFsdWUg ZG9lc24ndCBtYXRjaCB3aGF0DQo+IGhhcyBiZWVuIGFkdmVydGlzZWQgaW4gdGhlIFNSLUFsZ29y aXRobSBTdWItVExWPw0KPiANCltMZXM6XSBUaGlzIGlzIGV4cGxpY2l0bHkgc3RhdGVkIGF0IHRo ZSBlbmQgb2YgIFNlY3Rpb24gMi4xOg0KDQoiICAgICAgIEEgcm91dGVyIHJlY2VpdmluZyBhIFBy ZWZpeC1TSUQgZnJvbSBhIHJlbW90ZSBub2RlIGFuZCB3aXRoIGFuDQogICAgIGFsZ29yaXRobSB2 YWx1ZSB0aGF0IHN1Y2ggcmVtb3RlIG5vZGUgaGFzIG5vdCBhZHZlcnRpc2VkIGluIHRoZQ0KICAg ICAgU1ItQWxnb3JpdGhtIHN1Yi1UTFYgKFNlY3Rpb24gMy4yKSBNVVNUIGlnbm9yZSB0aGUgUHJl Zml4LVNJRCBzdWItDQogICAgICBUTFYuIg0KDQo+IA0KPiAuLi4NCj4gMjgyIDIuMS4xLjIuICBS IGFuZCBOIEZsYWdzDQo+IA0KPiAyODQgICBUaGUgUi1GbGFnIE1VU1QgYmUgc2V0IGZvciBwcmVm aXhlcyB0aGF0IGFyZSBub3QgbG9jYWwgdG8gdGhlIHJvdXRlcg0KPiAyODUgICBhbmQgZWl0aGVy Og0KPiANCj4gMjg3ICAgICAgYWR2ZXJ0aXNlZCBiZWNhdXNlIG9mIHByb3BhZ2F0aW9uIChMZXZl bC0xIGludG8gTGV2ZWwtMik7DQo+IA0KPiAyODkgICAgICBhZHZlcnRpc2VkIGJlY2F1c2Ugb2Yg bGVha2luZyAoTGV2ZWwtMiBpbnRvIExldmVsLTEpOw0KPiANCj4gMjkxICAgICAgYWR2ZXJ0aXNl ZCBiZWNhdXNlIG9mIHJlZGlzdHJpYnV0aW9uIChlLmcuOiBmcm9tIGFub3RoZXINCj4gMjkyICAg ICAgcHJvdG9jb2wpLg0KPiANCj4gMjk0ICAgSW4gdGhlIGNhc2Ugd2hlcmUgYSBMZXZlbC0xLTIg cm91dGVyIGhhcyBsb2NhbCBpbnRlcmZhY2UgYWRkcmVzc2VzDQo+IDI5NSAgIGNvbmZpZ3VyZWQg aW4gb25lIGxldmVsLCBpdCBtYXkgYWxzbyBwcm9wYWdhdGUgdGhlc2UgYWRkcmVzc2VzIGludG8N Cj4gMjk2ICAgdGhlIG90aGVyIGxldmVsLiAgSW4gc3VjaCBjYXNlLCB0aGUgTGV2ZWwtMS0yIHJv dXRlciBNVVNUIE5PVCBzZXQgdGhlDQo+IDI5NyAgIFIgYml0LiAgVGhlIFItYml0IE1VU1QgYmUg c2V0IG9ubHkgZm9yIHByZWZpeGVzIHRoYXQgYXJlIG5vdCBsb2NhbCB0bw0KPiAyOTggICB0aGUg cm91dGVyIGFuZCBhZHZlcnRpc2VkIGJ5IHRoZSByb3V0ZXIgYmVjYXVzZSBvZiBwcm9wYWdhdGlv biBhbmQvb3INCj4gMjk5ICAgbGVha2luZy4NCj4gDQo+IFttaW5vcl0gVGhpcyBsYXN0IHNlbnRl bmNlIGlzIHJlZHVuZGFudCB3aXRoIHRoZSBzdGFydCBvZiB0aGlzIHNlY3Rpb24uDQo+IFBsZWFz ZSBzcGVjaWZ5IHRoZSBiZWhhdmlvciBqdXN0IG9uY2UuDQo+IA0KW0xlczpdIERvbmUuDQo+IA0K PiAzMDEgICBUaGUgTi1GbGFnIGlzIHVzZWQgaW4gb3JkZXIgdG8gZGVmaW5lIGEgTm9kZS1TSUQu ICBBIHJvdXRlciBNQVkgc2V0DQo+IDMwMiAgIHRoZSBOLUZsYWcgb25seSBpZiBhbGwgb2YgdGhl IGZvbGxvd2luZyBjb25kaXRpb25zIGFyZSBtZXQ6DQo+IA0KPiAzMDQgICAgICBUaGUgcHJlZml4 IHRvIHdoaWNoIHRoZSBQcmVmaXgtU0lEIGlzIGF0dGFjaGVkIGlzIGxvY2FsIHRvIHRoZQ0KPiAz MDUgICAgICByb3V0ZXIgKGkuZS4sIHRoZSBwcmVmaXggaXMgY29uZmlndXJlZCBvbiBvbmUgb2Yg dGhlIGxvY2FsDQo+IDMwNiAgICAgIGludGVyZmFjZXMsIGUuZy4sIGEgJ3N0YWJsZSB0cmFuc3Bv cnQnIGxvb3BiYWNrKS4NCj4gDQo+IDMwOCAgICAgIFRoZSBwcmVmaXggdG8gd2hpY2ggdGhlIFBy ZWZpeC1TSUQgaXMgYXR0YWNoZWQgTVVTVCBoYXZlIGEgUHJlZml4DQo+IDMwOSAgICAgIGxlbmd0 aCBvZiBlaXRoZXIgLzMyIChJUHY0KSBvciAvMTI4IChJUHY2KS4NCj4gDQo+IFttYWpvcl0gIlRo ZSBwcmVmaXguLi5NVVNUIGhhdmUgYSBQcmVmaXggbGVuZ3RoLi4uIiAgVGhpcyBjb25kaXRpb24g aXMgbm90DQo+IHdvcmRlZCBhcyBvbmU7IHBlcmhhcHM6ICJUaGUgcHJlZml4Li4uaGFzIGEgUHJl Zml4IGxlbmd0aC4uLiINCj4gDQpbTGVzOl0gRG9uZS4NCg0KPiBbbWlub3JdIFdoeSBpcyB0aGUg Ti1GbGFnIG5lZWRlZD8gIElmIHRoZSBzZXR0aW5nIGlzIG9wdGlvbmFsICgiTUFZIiksIHRoZW4N Cj4gbm90IHNldHRpbmcgaXQgZG9lc24ndCBpbXBseSB0aGF0IHRoZSBjb25kaXRpb25zIGFyZSBu b3QgbWV0Li4uDQo+IA0KW0xlczpdIFBsZWFzZSBzZWUgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL3JmYzc3OTQjc2VjdGlvbi0yLjEgDQoNCj4gW21ham9yXSBJdCBpcyBjbGVhcmx5IGFuIGVy cm9yIGlmIGJvdGggdGhlIFItRmxhZyBhbmQgTi1GbGFnIGFyZSBzZXQsDQo+IHJpZ2h0PyAgV2hh dCBzaG91bGQgdGhlIHJlY2VpdmVyIGRvIGluIHRoYXQgY2FzZT8NCj4gDQpbTGVzOl0gSXQgaXMg bGVnYWwgdG8gaGF2ZSBSIGFuZCBOIGZsYWdzIHNldC4gVGhpcyBvY2N1cnMgd2hlbiBhIHByZWZp eCB3aGljaCBoYXMgdGhlIE4gZmxhZyBzZXQgaXMgbGVha2VkIGludG8gYW5vdGhlciBsZXZlbC4N Cg0KPiANCj4gMzExICAgVGhlIHJvdXRlciBNVVNUIGlnbm9yZSB0aGUgTi1GbGFnIG9uIGEgcmVj ZWl2ZWQgUHJlZml4LVNJRCBpZiB0aGUNCj4gMzEyICAgcHJlZml4IGhhcyBhIFByZWZpeCBsZW5n dGggZGlmZmVyZW50IHRoYW4gLzMyIChJUHY0KSBvciAvMTI4IChJUHY2KS4NCj4gDQo+IDMxNCAg IFtSRkM3Nzk0XSBhbHNvIGRlZmluZXMgdGhlIE4gYW5kIFIgZmxhZ3MgYW5kIHdpdGggdGhlIHNh bWUgc2VtYW50aWNzDQo+IDMxNSAgIG9mIHRoZSBlcXVpdmFsZW50IGZsYWdzIGRlZmluZWQgaW4g dGhpcyBkb2N1bWVudC4gIFRoZXJlIHdpbGwgYmUgYQ0KPiAzMTYgICB0cmFuc2l0aW9uIHBlcmlv ZCB3aGVyZSBib3RoIHNldHMgb2YgZmxhZ3Mgd2lsbCBiZSB1c2VkIGFuZA0KPiAzMTcgICBldmVu dHVhbGx5IG9ubHkgdGhlIGZsYWdzIG9mIHRoZSBQcmVmaXggQXR0cmlidXRlcyB3aWxsIHJlbWFp bi4NCj4gMzE4ICAgRHVyaW5nIHRoZSB0cmFuc2l0aW9uIHBlcmlvZCBpbXBsZW1lbnRhdGlvbnMg c3VwcG9ydGluZyB0aGUgTiBhbmQgUg0KPiAzMTkgICBmbGFncyBkZWZpbmVkIGluIHRoaXMgZG9j dW1lbnQgYW5kIHRoZSBOIGFuZCBSIGZsYWdzIGRlZmluZWQgaW4NCj4gMzIwICAgW1JGQzc3OTRd IE1VU1QgYWR2ZXJ0aXNlIGFuZCBwYXJzZSBhbGwgZmxhZ3MuICBJbiBjYXNlIHRoZSByZWNlaXZl ZA0KPiAzMjEgICBmbGFncyBoYXZlIGRpZmZlcmVudCB2YWx1ZXMsIHRoZSB2YWx1ZSBvZiB0aGUg ZmxhZ3MgZGVmaW5lZCBpbg0KPiAzMjIgICBbUkZDNzc5NF0gcHJldmFpbHMuDQo+IA0KPiBbbWFq b3JdICIuLi50cmFuc2l0aW9uIHBlcmlvZCB3aGVyZSBib3RoIHNldHMgb2YgZmxhZ3Mgd2lsbCBi ZSB1c2VkIGFuZA0KPiBldmVudHVhbGx5IG9ubHkgdGhlIGZsYWdzIG9mIHRoZSBQcmVmaXggQXR0 cmlidXRlcyB3aWxsIHJlbWFpbiIgIFRvIGJlDQo+IGhvbmVzdCwgeW91IGxvc3QgbWUgaGVyZT8g IFBsZWFzZSBleHBsYWluIHdoYXQgd2lsbCB0aGUgdHJhbnNpdGlvbiBwZXJpb2QNCj4gYmUgYmV0 d2Vlbj8NCj4gDQo+IFttYWpvcl0gSWYgImJvdGggc2V0cyBvZiBmbGFncyB3aWxsIGJlIHVzZWQg YW5kIGV2ZW50dWFsbHkgb25seSB0aGUNCj4gW2FscmVhZHkgZGVmaW5lZF0gZmxhZ3Mgb2YgdGhl IFByZWZpeCBBdHRyaWJ1dGVzIHdpbGwgcmVtYWluIiwgd2h5IGRvIHdlDQo+IG5lZWQgdGhlIG5l dyBvbmVzPw0KPiANCj4gW21ham9yXSAiTVVTVCBhZHZlcnRpc2UgYW5kIHBhcnNlIGFsbCBmbGFn cyIgIFdoYXQgZG9lcyB0aGlzIG1lYW4/ICBCeSAiYWxsDQo+IGZsYWdzIiBJIGd1ZXNzIHlvdSBt ZWFuIHRoZSBOIGFuZCBSIGZsYWdzLi4uYnV0IGlmIGJvdGggdGhpcyBkb2N1bWVudCBhbmQNCj4g cmZjNzc5NCBhcmUgaW1wbGVtZW50ZWQsIGl0IHNlZW1zIHRvIG1lIHRoYXQgdGhlIHNwZWNpZmlj YXRpb24gYWJvdmUgaXMNCj4gcmVhbGx5IG1lYW5pbmdsZXNzLg0KPiANCj4gW21ham9yXSAiSW4g Y2FzZSB0aGUgcmVjZWl2ZWQgZmxhZ3MgaGF2ZSBkaWZmZXJlbnQgdmFsdWVzLi4uIiAgRm9yIGEg c2Vjb25kDQo+IGl0IHNlZW1lZCB0byBtZSB0aGF0IHdoYXQgeW91IHJlYWxseSB3YW50ZWQgd2Fz IGZvciB0aGUgZmxhZ3MgaW4gdGhpcw0KPiBkb2N1bWVudCB0byBiZWhhdmUgdGhlIHNhbWUgd2F5 IGFzIHRoZSBmbGFncyBkZWZpbmVkIGluIHJmYzc3OTQuLi50aGUgZWFzeQ0KPiBzb2x1dGlvbiB0 byB0aGF0IChhbmQgdG8gYXZvaWQgbXkgcXVlc3Rpb25zIGxpc3RlZCBiZWZvcmUgcmZjNzc5NCB3 YXMNCj4gbWVudGlvbmVkKSB3b3VsZCBoYXZlIGJlZW4gdG8ganVzdCBwb2ludCBhdCByZmM3Nzk0 IGFzIHRoZSBwbGFjZSB3aGVyZSB0aGUNCj4gRmxhZ3MgYXJlIGRlZmluZWQuICBIb3dldmVyLCBp dCBsb29rcyBsaWtlIHRoZSBkZWZpbml0aW9ucyAoYXQgbGVhc3QgZm9yDQo+IHRoZSBSLUZsYWcp IGFyZSBub3QgdGhlIHNhbWUuICBJcyB0aGF0IG9uIHB1cnBvc2Ugb3IgaXMgaXQganVzdCBhbg0K PiBvdmVyc2lnaHQ/DQo+IA0KW0xlczpdIFRoZSB0ZXh0IGhhcyBiZWVuIHJldmlzZWQgdG8gc2lt cGx5IHN0YXRlIHRoZSBwcmVmZXJlbmNlIGZvciBSRkMgNzc5NCB2YWx1ZXMgb3ZlciBQcmVmaXgt U0lEIHZhbHVlcy4NCg0KPiBPbmUgcGllY2Ugb2YgaW5mb3JtYXRpb24gdGhhdCBtaWdodCBtYWtl IHRoaXMgZGlzY3Vzc2lvbiByZWxldmFudCBpcw0KPiB1bmRlcnN0YW5kaW5nIHRoZSBzaWduaWZp Y2FuY2Ugb2YgdGhlc2UgRmxhZ3MuLi5idXQgbmVpdGhlciBkb2N1bWVudCBvZmZlcnMNCj4gYW55 IHNwZWNpZmljIHVzZSwgYmV5b25kIHNpbXBseSAiaXQgbWF5IGJlIHVzZWZ1bCBmb3Igb3RoZXIg cm91dGVycyB0bw0KPiBrbm93IiAocmZjNzc5NCwgwqcyLjIpLg0KPg0KW0xlczpdIFByZWZpeGVz IHdpdGggTiBmbGFnIHNldCBzZXJ2ZSBhcyBOb2RlIElkZW50aWZpZXJzIGZvciB0aGUgb3JpZ2lu YXRpbmcgbm9kZS4gVGhlc2UgYWRkcmVzc2VzIGFyZSB0aGVuIGNhbmRpZGF0ZXMgdG8gYmUgdXNl ZCBpbiBwb2xpY2llcyBpbmNsdWRpbmcgZXhwbGljaXQgcGF0aHMgdXNlZCBmb3IgcmVwYWlyIGFu ZC9vciBtaWNyb2xvb3AgYXZvaWRhbmNlLg0KIA0KPiANCj4gMzI0IDIuMS4xLjMuICBFIGFuZCBQ IEZsYWdzDQo+IA0KPiAzMjYgICBXaGVuIGNhbGN1bGF0aW5nIHRoZSBvdXRnb2luZyBsYWJlbCBm b3IgdGhlIHByZWZpeCwgdGhlIHJvdXRlciBNVVNUDQo+IDMyNyAgIHRha2UgaW50byBhY2NvdW50 IEUgYW5kIFAgZmxhZ3MgYWR2ZXJ0aXNlZCBieSB0aGUgbmV4dC1ob3Agcm91dGVyLCBpZg0KPiAz MjggICBuZXh0LWhvcCByb3V0ZXIgYWR2ZXJ0aXNlZCB0aGUgU0lEIGZvciB0aGUgcHJlZml4LiAg VGhpcyBNVVNUIGJlIGRvbmUNCj4gMzI5ICAgcmVnYXJkbGVzcyBvZiBuZXh0LWhvcCByb3V0ZXIg Y29udHJpYnV0aW5nIHRvIHRoZSBiZXN0IHBhdGggdG8gdGhlDQo+IDMzMCAgIHByZWZpeCBvciBu b3QuDQo+IA0KPiBbbWFqb3JdICJ0aGUgcm91dGVyIE1VU1QgdGFrZSBpbnRvIGFjY291bnQiICBX aGF0IG5vcm1hdGl2ZSBhY3Rpb24gaXMNCj4gc3RhbmRhcmRpemVkIHdpdGggdGhhdCBwaHJhc2U/ ICBJdCB3b3VsZCBiZSBjbGVhcmVyL2JldHRlciBpZiB0aGUgYmVoYXZpb3INCj4gaXMgZXhwbGlj aXRseSBzcGVjaWZpZWQgaW4gZnVuY3Rpb24gb2YgdGhlIGZsYWdzIChhcyBzb25lIGJlbG93KS4N Cj4gIHMvTVVTVC9tdXN0DQo+IA0KPiBbbWFqb3JdICJUaGlzIE1VU1QgYmUgZG9uZSByZWdhcmRs ZXNzIG9mIG5leHQtaG9wIHJvdXRlciBjb250cmlidXRpbmcgdG8NCj4gdGhlIGJlc3QgcGF0aCB0 byB0aGUgcHJlZml4IG9yIG5vdC4iICBUaGlzIHdoYXQ/ICBJJ20gYXNzdW1pbmcgdGhlIHRleHQN Cj4gcmVmZXJzIHRvICJ0YWtlIGludG8gYWNjb3VudCIuLi4gIFNhbWUgY29tbWVudCBhcyBiZWZv cmU6IHMvTVVTVC9tdXN0DQo+IA0KW0xlczpdIFRoaXMgdGV4dCBoYXMgYmVlbiByZW1vdmVkLiBX aGF0IGlzIGxlZnQgaXMgc2ltcGx5IHRoZSBub3JtYXRpdmUgZGVzY3JpcHRpb24gb2YgYmVoYXZp b3JzIGFzc29jaWF0ZWQgd2l0aCBFL1AgZmxhZ3MuDQoNCj4gDQo+IC4uLg0KPiAzNjYgMi4xLjIu ICBQcmVmaXgtU0lEIFByb3BhZ2F0aW9uDQo+IA0KPiAzNjggICBUaGUgUHJlZml4LVNJRCBzdWIt VExWIE1VU1QgYmUgcHJlc2VydmVkIHdoZW4gdGhlIElQIFJlYWNoYWJpbGl0eSBUTFYNCj4gMzY5 ICAgZ2V0cyBwcm9wYWdhdGVkIGFjcm9zcyBsZXZlbCBib3VuZGFyaWVzLg0KPiANCj4gW21ham9y XSDCpzIuMSBzYXlzIHRoYXQgaXQgU0hPVUxELiAgUGxlYXNlIGJlIGNvbnNpc3RlbnQuLi5hbmQs IHNwZWNpZnkNCj4gYmVoYXZpb3Igb25seSBvbmNlLg0KPiANCltMZXM6XSBEb25lDQoNCj4gMzcx ICAgVGhlIGxldmVsLTEtMiByb3V0ZXIgdGhhdCBwcm9wYWdhdGVzIHRoZSBQcmVmaXgtU0lEIHN1 Yi1UTFYgYmV0d2Vlbg0KPiAzNzIgICBsZXZlbHMgTVVTVCBzZXQgdGhlIFItZmxhZy4NCj4gDQo+ IDM3NCAgIElmIHRoZSBQcmVmaXgtU0lEIGNvbnRhaW5zIGEgZ2xvYmFsIGluZGV4IChMIGFuZCBW IGZsYWdzIHVuc2V0KSBhbmQNCj4gMzc1ICAgaXQgaXMgcHJvcGFnYXRlZCBhcyBzdWNoICh3aXRo IEwgYW5kIFYgZmxhZ3MgdW5zZXQpLCB0aGUgdmFsdWUgb2YgdGhlDQo+IDM3NiAgIGluZGV4IE1V U1QgYmUgcHJlc2VydmVkIHdoZW4gcHJvcGFnYXRlZCBiZXR3ZWVuIGxldmVscy4NCj4gDQo+IDM3 OCAgIFRoZSBsZXZlbC0xLTIgcm91dGVyIHRoYXQgcHJvcGFnYXRlcyB0aGUgUHJlZml4LVNJRCBz dWItVExWIGJldHdlZW4NCj4gMzc5ICAgbGV2ZWxzIE1BWSBjaGFuZ2UgdGhlIHNldHRpbmcgb2Yg dGhlIEwgYW5kIFYgZmxhZ3MgaW4gY2FzZSBhIGxvY2FsDQo+IDM4MCAgIGxhYmVsIHZhbHVlIGlz IGVuY29kZWQgaW4gdGhlIFByZWZpeC1TSUQgaW5zdGVhZCBvZiB0aGUgcmVjZWl2ZWQNCj4gMzgx ICAgdmFsdWUuDQo+IA0KPiBbbWFqb3JdICBVcCB0byBub3csIEkgaGFkIGJlZW4gYXNzdW1pbmcg dGhhdCBwcm9wYWdhdGluZyBhbmQgcHJlc2VydmluZw0KPiBtZWFudCBub3QgY2hhbmdpbmcgdGhl IHN1Yi1UTFYgKGV4Y2VwdCBmb3IgdGhlIFItRmxhZykuICBCdXQgdGhlc2UgbGFzdA0KPiBwYXJh Z3JhcGhzIGluZGljYXRlIHRoYXQgbm90IG9ubHkgY2FuIHNvbWUgZmxhZ3MgYmUgY2hhbmdlZCwg YnV0IHRoZQ0KPiBjb250ZW50cyBjYW4gY29tcGxldGVseSBjaGFuZ2UuICBJdCB3b3VsZCBiZSBp ZGVhbCBpZiB0aGUgdmFsaWQgb3BlcmF0aW9ucw0KPiBvbiB0aGUgc3ViLVRMViB3ZXJlIGRpc2N1 c3NlZCAob3IgYXQgbGVhc3QgcmVmZXJlbmNlZCkgd2hlbiB0aGUgcHJlc2VydmluZw0KPiBiZWhh dmlvciB3YXMgZmlyc3QgaW50cm9kdWNlZCAoSSB0aGluayBpbiDCpzIuMSkuDQo+IA0KDQpbTGVz Ol0gVGhpcyB0ZXh0IGhhcyBiZWVuIHJlbW92ZWQuDQoNCj4gDQo+IC4uLg0KPiA0MDkgMi4yLjEu ICBBZGphY2VuY3kgU2VnbWVudCBJZGVudGlmaWVyIChBZGotU0lEKSBTdWItVExWDQo+IA0KPiA0 MTEgICBUaGUgZm9sbG93aW5nIGZvcm1hdCBpcyBkZWZpbmVkIGZvciB0aGUgQWRqLVNJRCBzdWIt VExWOg0KPiANCj4gNDEzICAgIDAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAg ICAyICAgICAgICAgICAgICAgICAgIDMNCj4gNDE0ICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAx IDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KPiA0MTUgICArLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Kw0KPiA0MTYgICB8ICAgVHlwZSAgICAgICAgfCAgICAgTGVuZ3RoICAgIHwgICAgIEZsYWdzICAg ICB8ICAgICBXZWlnaHQgICAgfA0KPiA0MTcgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiA0MTggICB8ICAgICAgICAg ICAgICAgICAgICAgICAgIFNJRC9MYWJlbC9JbmRleCAodmFyaWFibGUpICAgICAgICAgICAgfA0K PiA0MTkgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKw0KPiANCj4gNDIxICAgd2hlcmU6DQo+IA0KPiA0MjMgICAgICBUeXBl OiBUQkQsIHN1Z2dlc3RlZCB2YWx1ZSAzMQ0KPiANCj4gNDI1ICAgICAgTGVuZ3RoOiB2YXJpYWJs ZS4NCj4gDQo+IFttaW5vcl0gWWVzLCB2YXJpYWJsZSwgYnV0IGl0IGNhbiBvbmx5IGhhdmUgdHdv IHZhbHVlcy4uLg0KPiANCltMZXM6XSBEb25lDQoNCj4gNDI3ICAgICAgRmxhZ3M6IDEgb2N0ZXQg ZmllbGQgb2YgZm9sbG93aW5nIGZsYWdzOg0KPiANCj4gNDI5ICAgICAgICAgIDAgMSAyIDMgNCA1 IDYgNw0KPiA0MzAgICAgICAgICArLSstKy0rLSstKy0rLSstKw0KPiA0MzEgICAgICAgICB8RnxC fFZ8THxTfFB8ICAgfA0KPiA0MzIgICAgICAgICArLSstKy0rLSstKy0rLSstKw0KPiANCj4gNDM0 ICAgICAgd2hlcmU6DQo+IA0KPiA0MzYgICAgICAgICBGLUZsYWc6IEFkZHJlc3MtRmFtaWx5IGZs YWcuICBJZiB1bnNldCwgdGhlbiB0aGUgQWRqLVNJRCByZWZlcnMNCj4gNDM3ICAgICAgICAgdG8g YW4gYWRqYWNlbmN5IHdpdGggb3V0Z29pbmcgSVB2NCBlbmNhcHN1bGF0aW9uLiAgSWYgc2V0IHRo ZW4NCj4gNDM4ICAgICAgICAgdGhlIEFkai1TSUQgcmVmZXJzIHRvIGFuIGFkamFjZW5jeSB3aXRo IG91dGdvaW5nIElQdjYNCj4gNDM5ICAgICAgICAgZW5jYXBzdWxhdGlvbi4NCj4gDQo+IFttYWpv cl0gVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIG9wZXJhdGlvbiBvbiB0aGUgTVBMUyBkYXRh IHBsYW5lLA0KPiByaWdodD8gIFRoZSBGLUZsYWcgdGFsa3MgYWJvdXQgdGhlIG91dGdvaW5nIGVu Y2Fwc3VsYXRpb24uLi5idXQgdGhhdCBjb3VsZA0KPiBzaW1wbHkgYmUgdGhlIG5leHQgbGFiZWwg aW4gdGhlIE1QTFMgc3RhY2ssIHJpZ2h0PyAgV2hhdCBhbSBJIG1pc3Npbmc/ICBJDQo+IGdldCB0 aGUgaW1wcmVzc2lvbiB0aGF0IHRoZXJlJ3MgYSByZWxhdGlvbnNoaXAgYmV0d2VlbiB3aGF0IHRo aXMgRmxhZw0KPiBwb2ludHMgdG8gYW5kIHNvbWV0aGluZyBlbHNlLi4uYnV0IEkganVzdCBkb24n dCBrbm93IHdoYXQuDQo+IA0KW0xlczpdIFRleHQgcmV2aXNlZC4gRm9yd2FyZGluZyBwbGFuZSBp bXBsZW1lbnRhdGlvbnMgZnJlcXVlbnRseSBhcmUgYWRkcmVzcy1mYW1pbHkgc3BlY2lmaWMgLSB3 aGljaCBpcyB3aGF0IHRoZSB0ZXh0IHdhcyB0cnlpbmcgdG8gZGVzY3JpYmUuDQoNCj4gDQo+IDQ0 MSAgICAgICAgIEItRmxhZzogQmFja3VwIGZsYWcuICBJZiBzZXQsIHRoZSBBZGotU0lEIGlzIGVs aWdpYmxlIGZvcg0KPiA0NDIgICAgICAgICBwcm90ZWN0aW9uIChlLmcuOiB1c2luZyBJUEZSUiBv ciBNUExTLUZSUikgYXMgZGVzY3JpYmVkIGluDQo+IDQ0MyAgICAgICAgIFtSRkM4MzU1XS4NCj4g DQo+IFttYWpvcl0gQmVjYXVzZSB0aGUgc3BlY2lmaWNhdGlvbiBvZiB0aGUgQi1GbGFnIGRlcGVu ZHMgZGlyZWN0bHkgb24NCj4gcmZjODM1NSwgaXQgc2hvdWxkIGJlIGEgTm9ybWF0aXZlIHJlZmVy ZW5jZS4gIExvb2tpbmcgYXQgcmZjODM1NSwgSQ0KPiBjb3VsZG4ndCBmaW5kIGEgcGxhY2Ugd2hl cmUgaXQgdGFsa3MgYWJvdXQgZWxpZ2liaWxpdHkgZm9yDQo+IHByb3RlY3Rpb24uLi5qdXN0IHRl eHQgYWJvdXQgcG90ZW50aWFsIHN0cmF0ZWdpZXMsIGJ1dCAoaG9uZXN0bHkpIG5vdGhpbmcNCj4g dGhhdCBJIHdvdWxkIGNhbGwgTm9ybWF0aXZlLiAgUGxlYXNlIGNsYXJpZnkuICBQZXJoYXBzIHJm Yzg0MDIgbWlnaHQgYmUgYQ0KPiBiZXR0ZXIgcmVmZXJlbmNlLg0KPiANCj4gW21ham9yXSBJJ20g YXNzdW1pbmcgdGhhdCB0aGlzIGRlc2NyaXB0aW9uIChwb2ludGluZyBhdCByZmM4MzU1KSwgcGx1 cyB0aGUNCj4gdGV4dCBiZWxvdyBhYm91dCBhbGxvY2F0aW9uIG9mIEFkai1TSURzIHNob3VsZCBy ZXN1bHQgaW4gc29tZSBhY3Rpb24NCj4gcmVsYXRlZCB0byB0aGUgcHJvdGVjdGlvbi4uLndoYXQg aXMgdGhhdD8gIElPVywgcHJlc2VudGVkIHdpdGggdGhlIEItRmxhZw0KPiBzZXQsIHdoYXQgYWN0 aW9uIHNob3VsZCBhIG5vZGUgdGFrZT8NCj4gDQo+IA0KW0xlczpdIENvcnJlY3QgcmVmZXJlbmNl IGlzIChhcyB5b3UgcG9pbnRlZCBvdXQpIHRvIFJGQyA4NDAyLiBUZXh0IHVwZGF0ZWQgYW5kIHJl ZmVyZW5jZSB0byBSRkM4MzU1IHJlbW92ZWQuDQoNCj4gNDQ1ICAgICAgICAgVi1GbGFnOiBWYWx1 ZSBmbGFnLiAgSWYgc2V0LCB0aGVuIHRoZSBBZGotU0lEIGNhcnJpZXMgYSB2YWx1ZS4NCj4gNDQ2 ICAgICAgICAgQnkgZGVmYXVsdCB0aGUgZmxhZyBpcyBTRVQuDQo+IA0KPiBbbWlub3JdIElzIHRo ZSBkZXNjcmlwdGlvbiB0aGUgc2FtZSBhdCB0aGUgVi1GbGFnIGluIMKnMi4xPyAgSWYgc28sIHRo ZW4NCj4gaW5kaWNhdGluZyB0aGF0LCBvciBhdCBsZWFzdCBhbHNvIHBvaW50aW5nIG91dCBoZXJl IHRoYXQgdGhlIHZhbHVlIGlzDQo+IGNhcnJpZWQgaW5zdGVhZCBvZiBhbiBpbmRleCB3b3VsZCBi ZSBoZWxwZnVsLg0KPiANCltMZXM6XSBEb25lLg0KPiANCj4gNDQ4ICAgICAgICAgTC1GbGFnOiBM b2NhbCBGbGFnLiAgSWYgc2V0LCB0aGVuIHRoZSB2YWx1ZS9pbmRleCBjYXJyaWVkIGJ5DQo+IDQ0 OSAgICAgICAgIHRoZSBBZGotU0lEIGhhcyBsb2NhbCBzaWduaWZpY2FuY2UuICBCeSBkZWZhdWx0 IHRoZSBmbGFnIGlzDQo+IDQ1MCAgICAgICAgIFNFVC4NCj4gDQo+IFttYWpvcl0gTG9va2luZyBi YWNrIGF0IMKnMi4xLjEuMSwgd2hhdCBhcmUgdGhlIGNvbmRpdGlvbnMgZm9yIHdoaWNoIHRoZQ0K PiBjb21iaW5hdGlvbiBvZiB0aGUgViBhbmQgTC1GbGFncyBhcmUgdmFsaWQvaW52YWxpZD8gIERv IHRoZSBzYW1lIGNvbmRpdGlvbnMNCj4gYXBwbHk/DQo+IA0KW0xlczpdIFRoaXMgaXMgZXhwbGlj aXRseSBzdGF0ZWQgaW4gU2VjdGlvbiAyLjEuMS4xLg0KDQo+IA0KPiAuLi4NCj4gNDYwICAgICAg ICAgT3RoZXIgYml0czogTVVTVCBiZSB6ZXJvIHdoZW4gb3JpZ2luYXRlZCBhbmQgaWdub3JlZCB3 aGVuDQo+IDQ2MSAgICAgICAgIHJlY2VpdmVkLg0KPiANCj4gW21ham9yXSBEbyB5b3UgZXhwZWN0 IElBTkEgdG8gaGFuZGxlIHRoZSBhc3NpZ25tZW50IG9mIHRob3NlIG90aGVyIGJpdHM/DQo+IA0K W0xlczpdIE5vIC0gc2ltaWxhciB0byBwcmV2aW91cyBjYXNlIGFuc3dlcmVkIGFib3ZlLg0KDQo+ IA0KPiAuLi4NCj4gNDY5ICAgICAgQW4gU1IgY2FwYWJsZSByb3V0ZXIgTUFZIGFsbG9jYXRlIGFu IEFkai1TSUQgZm9yIGVhY2ggb2YgaXRzDQo+IDQ3MCAgICAgIGFkamFjZW5jaWVzIGFuZCBTSE9V TEQgc2V0IHRoZSBCLUZsYWcgd2hlbiB0aGUgYWRqYWNlbmN5IGlzDQo+IDQ3MSAgICAgIGVsaWdp YmxlIGZvciBwcm90ZWN0aW9uIChJUCBvciBNUExTKS4NCj4gDQo+IFttYWpvcl0gSWYgZWxpZ2li bGUgZm9yIHByb3RlY3Rpb24sIHdoZW4gd291bGQgdGhlIHJvdXRlciBub3Qgc2V0IHRoZQ0KPiBC LUZsYWc/ICBJT1csIHdoeSBpcyB0aGF0IG5vdCBhIE1VU1Q/DQo+IA0KPiBCZXlvbmQgdGhhdCwg SSB0aGluayB0aGF0IHRoZSB1c2Ugb2YgU0hPVUxEIGlzIGluIGNvbmZsaWN0IHdpdGggdGhlDQo+ IGRlZmluaXRpb24gb2YgdGhlIEItRmxhZyAoYWJvdmUpOiAiSWYgc2V0LCB0aGUgQWRqLVNJRCBp cyBlbGlnaWJsZSBmb3INCj4gcHJvdGVjdGlvbi4uLiIsIHdoaWNoIGltcGxpZXMgdGhhdCBpdCBp c24ndCBlbGlnaWJsZSBpZiBpdCdzIG5vdCBzZXQuLi5idXQNCj4gdGhlIFNIT1VMRCBvcGVucyB0 aGUgZG9vciBmb3Igbm90IHNldHRpbmcgdGhlIEZsYWcuLi4NCj4gDQpbTGVzOl0gT2ZmZW5kaW5n IHRleHQgcmVtb3ZlZC4gQi1mbGFnIGlzIGRlZmluZWQgaW4gU2VjdGlvbjIuMi4xDQogDQo+IA0K PiAuLi4NCj4gNDc5ICAgICAgV2hlbiB0aGUgUC1mbGFnIGlzIG5vdCBzZXQsIHRoZSBBZGotU0lE IE1BWSBiZSBwZXJzaXN0ZW50LiAgV2hlbg0KPiA0ODAgICAgICB0aGUgUC1mbGFnIGlzIHNldCwg dGhlIEFkai1TSUQgTVVTVCBiZSBwZXJzaXN0ZW50Lg0KPiANCj4gW21ham9yXSBJZiB0aGUgYWRq YWNlbmN5IGlzIHBlcnNpc3RlbnQsIHdoeS93aGVuIHdvdWxkIHRoZSBQLUZsYWcgbm90IGJlDQo+ IHNldD8NCj4gDQpbTGVzOl0gSXQgaXMgcG9zc2libGUgdGhhdCBpbXBsZW1lbnRhdGlvbiBvZiBh ICJkeW5hbWljYWxseSBhbGxvY2F0ZWQiIGFkai1zaWQgY291bGQgcmVzdWx0IGluIHRoZSBzYW1l IHZhbHVlIGJlaW5nIGFsbG9jYXRlZCBhZnRlciByZWJvb3QuIEhvd2V2ZXIsIFAtZmxhZyBzZXQg cmVxdWlyZXMgdGhhdCBiZWhhdmlvciB3aGVyZWFzIFAtZmxhZyB1bnNldCBhbGxvd3MgYW4gaW1w bGVtZW50YXRpb24gdG8gYWx0ZXIgdGhlIGFkamFjZW5jeS1zaWQgdmFsdWUgZm9sbG93aW5nIHJl Ym9vdCBidXQgZG9lcyBub3QgcmVxdWlyZSB0aGF0IGJlaGF2aW9yLg0KDQo+IA0KPiAuLi4NCj4g NDg4IDIuMi4yLiAgQWRqYWNlbmN5IFNlZ21lbnQgSWRlbnRpZmllcnMgaW4gTEFOcw0KPiAuLi4N Cj4gNTM3ICAgICAgT3RoZXIgYml0czogTVVTVCBiZSB6ZXJvIHdoZW4gb3JpZ2luYXRlZCBhbmQg aWdub3JlZCB3aGVuDQo+IDUzOCAgICAgIHJlY2VpdmVkLg0KPiANCj4gW21ham9yXSBEbyB5b3Ug ZXhwZWN0IElBTkEgdG8gaGFuZGxlIHRoZSBhc3NpZ25tZW50IG9mIHRob3NlIG90aGVyIGJpdHM/ DQo+IA0KW0xlczpdIE5vIC0gYXMgcGVyIHByZXZpb3VzIGFuc3dlci4NCg0KPiANCj4gLi4uDQo+ IDU0NCAgICAgIFN5c3RlbS1JRDogNiBvY3RldHMgb2YgSVMtSVMgU3lzdGVtLUlEIG9mIGxlbmd0 aCAiSUQgTGVuZ3RoIiBhcw0KPiA1NDUgICAgICBkZWZpbmVkIGluIFtJU08xMDU4OV0uDQo+IA0K PiBbbWFqb3JdIFdoaWNoIFN5c3RlbS1JRD8NCj4gDQpbTGVzOl0gVGV4dCBoYXMgYmVlbiBhbHRl cmVkIHRvIGluZGljYXRlIGl0IGlzIHRoZSBzeXN0ZW0taWQgb2YgdGhlIG5laWdoYm9yLg0KDQo+ IFttYWpvcl0gIjYgb2N0ZXRzIG9mLi4ubGVuZ3RoICJJRCBMZW5ndGgiIiAgPz8NCj4NCltMZXM6 XSBEb25lLg0KIA0KPiANCj4gNTQ3ICAgICAgU0lEL0luZGV4L0xhYmVsIGFzIGRlZmluZWQgaW4g U2VjdGlvbiAyLjEuMS4xLg0KPiANCj4gNTQ5ICAgTXVsdGlwbGUgTEFOLUFkai1TSUQgc3ViLVRM VnMgTUFZIGJlIGVuY29kZWQuICBOb3RlIHRoYXQgdGhpcyBzdWItVExWDQo+IDU1MCAgIE1VU1Qg Tk9UIGFwcGVhciBpbiBUTFYgMTQxLg0KPiANCj4gNTUyICAgV2hlbiB0aGUgUC1mbGFnIGlzIG5v dCBzZXQsIHRoZSBMQU4tQWRqLVNJRCBNQVkgYmUgcGVyc2lzdGVudC4gIFdoZW4NCj4gNTUzICAg dGhlIFAtZmxhZyBpcyBzZXQsIHRoZSBMQU4tQWRqLVNJRCBNVVNUIGJlIHBlcnNpc3RlbnQuDQo+ IA0KPiA1NTUgICBJbiBjYXNlIG9uZSBUTFYtMjIvMjMvMjIyLzIyMyAocmVwb3J0aW5nIHRoZSBh ZGphY2VuY3kgdG8gdGhlIERJUykNCj4gNTU2ICAgY2FuJ3QgY29udGFpbiB0aGUgd2hvbGUgc2V0 IG9mIExBTi1BZGotU0lEIHN1Yi1UTFZzLCBtdWx0aXBsZQ0KPiA1NTcgICBhZHZlcnRpc2VtZW50 cyBvZiB0aGUgYWRqYWNlbmN5IHRvIHRoZSBESVMgTVVTVCBiZSB1c2VkIGFuZCBhbGwNCj4gNTU4 ICAgYWR2ZXJ0aXNlbWVudHMgTVVTVCBoYXZlIHRoZSBzYW1lIG1ldHJpYy4NCj4gDQo+IDU2MCAg IEVhY2ggcm91dGVyIHdpdGhpbiB0aGUgbGV2ZWwsIGJ5IHJlY2VpdmluZyB0aGUgRElTIFBOIExT UCBhcyB3ZWxsIGFzDQo+IDU2MSAgIHRoZSBub24tUE4gTFNQIG9mIGVhY2ggcm91dGVyIGluIHRo ZSBMQU4sIGlzIGNhcGFibGUgb2YNCj4gNTYyICAgcmVjb25zdHJ1Y3RpbmcgdGhlIExBTiB0b3Bv bG9neSBhcyB3ZWxsIGFzIHRoZSBzZXQgb2YgQWRqLVNJRCBlYWNoDQo+IDU2MyAgIHJvdXRlciB1 c2VzIGZvciBlYWNoIG9mIGl0cyBuZWlnaGJvcnMuDQo+IA0KPiA1NjUgICBBIGxhYmVsIGlzIGVu Y29kZWQgaW4gMyBvY3RldHMgKGluIHRoZSAyMCByaWdodG1vc3QgYml0cykuDQo+IA0KPiA1Njcg ICBBbiBpbmRleCBpcyBlbmNvZGVkIGluIDQgb2N0ZXRzLg0KPiANCj4gW21pbm9yXSBTb21lIG9m IHRoZSBpbmZvcm1hdGlvbiBhYm92ZSAoZm9yIGV4YW1wbGUsIHRoZSBwYXJhZ3JhcGggYWJvdXQg dGhlDQo+IFAtRmxhZyBhbmQgdGhlc2UgbGFzdCAyIHNlbnRlbmNlcykgc2VlbXMgdW5uZWNlc3Nh cnkgZ2l2ZW4gdGhhdCB0aGUNCj4gZGVzY3JpcHRpb24gb2YgdGhlc2UgZmllbGRzIGlzIGFscmVh ZHkgZG9uZSBzb21ld2hlcmUgZWxzZS4NCj4gDQpbTGVzOl0gVW5uZWNlc3NhcnkgdGV4dCByZW1v dmVkLg0KDQo+IA0KPiA1NjkgMi4zLiAgU0lEL0xhYmVsIFN1Yi1UTFYNCj4gDQo+IDU3MSAgIFRo ZSBTSUQvTGFiZWwgc3ViLVRMViBtYXkgYmUgcHJlc2VudCBpbiB0aGUgZm9sbG93aW5nIFRMVnMv c3ViLVRMVnMNCj4gNTcyICAgZGVmaW5lZCBpbiB0aGlzIGRvY3VtZW50Og0KPiANCj4gNTc0ICAg U1ItQ2FwYWJpbGl0aWVzIFN1Yi1UTFYgKFNlY3Rpb24gMy4xKQ0KPiANCj4gNTc2ICAgU1IgTG9j YWwgQmxvY2sgU3ViLVRMViAoU2VjdGlvbiAzLjMpDQo+IA0KPiA1NzggICBTSUQvTGFiZWwgQmlu ZGluZyBUTFYgKFNlY3Rpb24gMi40KQ0KPiANCj4gNTgwICAgTXVsdGktVG9wb2xvZ3kgU0lEL0xh YmVsIEJpbmRpbmcgVExWIChTZWN0aW9uIDIuNSkNCj4gDQo+IFtuaXRdIEl0IG1pZ2h0IGhhdmUg YmVlbiBuaWNlLCBpbiBsaW5lIHdpdGggdGhlIE9TUEYgd29yaywgdG8gZmxpcCBTZWN0aW9ucw0K PiAyIGFuZCAzLiAgSnVzdCBhIG5pdC4uLg0KPiANCltMZXM6XSBTb3JyeSBidXQgSSBjaG9zZSBu b3QgdG8gZG8gdGhpcy4gVGhlcmUgYXJlIG90aGVyIGRpZmZlcmVuY2VzIGluIG9yZGVyaW5nIGJl dHdlZW4gdGhlIHR3byBzcGVjcyAtIGluIHBhcnQgYmVjYXVzZSB0aGUgcHJvdG9jb2wgc3BlY2lm aWMgbmF0dXJlIG9mIHRoZSBhZHZlcnRpc2VtZW50cyBpcyBzb21ld2hhdCBkaWZmZXJlbnQuIFJl b3JkZXJpbmcganVzdCB0aGVzZSB0d28gc2VjdGlvbnMgd291bGQgbm90IHJlc3VsdCBpbiBpZGVu dGljYWwgb3JkZXJpbmcuDQoNCj4gNTgyICAgTm90ZSB0aGF0IHRoZSBjb2RlIHBvaW50IHVzZWQg aW4gYWxsIG9mIHRoZSBhYm92ZSBjYXNlcyBpcyB0aGUgU0lELw0KPiA1ODMgICBMYWJlbCBTdWIt VExWIGNvZGUgcG9pbnQgYXNzaWduZWQgYnkgSUFOQSBpbiB0aGUgInN1Yi1UTFZzIGZvciBUTFYN Cj4gNTg0ICAgMTQ5IGFuZCAxNTAiIHJlZ2lzdHJ5Lg0KPiANCj4gW21ham9yXSBCZWNhdXNlIHRo aXMgZG9jdW1lbnQgaXMgc2V0dGluZyB1cCB0aGF0IG5ldyByZWdpc3RyeSwgd2UgZG9uJ3QNCj4g aGF2ZSB0byB3YWl0IGZvciBJQU5BIHRvIGFzc2lnbiBhbnl0aGluZzogdGhlIGRvY3VtZW50IGNh biBzcGVjaWZ5IGl0Lg0KPiBJT1csIHRoZSBwYXJhZ3JhcGggYWJvdmUgaXMgbm90IG5lZWRlZC4N Cj4gDQpbTGVzOl0gRG9uZS4NCj4gDQo+IDU4NiAgIFRoZSBTSUQvTGFiZWwgc3ViLVRMViBjb250 YWlucyBhIFNJRCBvciBhIE1QTFMgTGFiZWwuICBUaGUgU0lEL0xhYmVsDQo+IDU4NyAgIHN1Yi1U TFYgaGFzIHRoZSBmb2xsb3dpbmcgZm9ybWF0Og0KPiANCj4gNTg5ICAgIDAgICAgICAgICAgICAg ICAgICAgMSAgICAgICAgICAgICAgICAgICAyICAgICAgICAgICAgICAgICAgIDMNCj4gNTkwICAg IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcg OCA5IDAgMQ0KPiA1OTEgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gNTky ICAgfCAgIFR5cGUgICAgICAgIHwgICAgIExlbmd0aCAgICB8DQo+IDU5MyAgICstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+ IDU5NCAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgIFNJRC9MYWJlbCAodmFyaWFibGUpICAg ICAgICAgICAgICAgICB8DQo+IDU5NSAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+IA0KPiA1OTcgICB3aGVyZToNCj4g DQo+IDU5OSAgICAgIFR5cGU6IFRCRCwgc3VnZ2VzdGVkIHZhbHVlIDENCj4gDQo+IDYwMSAgICAg IExlbmd0aDogdmFyaWFibGUNCj4gDQo+IFttYWpvcl0gWWVzLCB2YXJpYWJsZS4uLmJ1dCByaWdo dCBub3cgb25seSBvbmUgdmFsdWUgaXMgZGVmaW5lZC4gIFRoZXJlJ3MgYQ0KPiBmaW5pdGUgbnVt YmVyIG9mIHBvc3NpYmlsaXRpZXMuLi4NCj4gDQpbTGVzOl0gRmluaXRlIHBlcmhhcHMsIGJ1dCBj ZXJ0YWlubHkgcXVpdGUgYSBmZXcgbGVnYWwgdmFsdWVzIGR1ZSB0byB0aGUgdmFyaWFibGUgbGVu Z3RoIG9mIHRoZSBwcmVmaXggZmllbGQuIFRleHQgdW5jaGFuZ2VkLg0KDQo+IA0KPiA2MDIgICAg ICBTSUQvTGFiZWw6IGlmIGxlbmd0aCBpcyBzZXQgdG8gMyB0aGVuIHRoZSAyMCByaWdodG1vc3Qg Yml0cw0KPiA2MDMgICAgICByZXByZXNlbnQgYSBNUExTIGxhYmVsLg0KPiANCj4gW21ham9yXSBJ cyB0aGF0IGl0Li4/ICBXaGF0IGFib3V0IHRoZSBTSUQ/DQo+IA0KW0xlczpdIEFkZGVkIGRlZmlu aXRpb25zIGZvciAzIGFuZCA0Lg0KDQo+IA0KPiA2MDUgMi40LiAgU0lEL0xhYmVsIEJpbmRpbmcg VExWDQo+IC4uLg0KPiA2MTkgICBUaGUgU0lEL0xhYmVsIEJpbmRpbmcgVExWIGhhcyBUeXBlIFRC RCAoc3VnZ2VzdGVkIHZhbHVlIDE0OSksIGFuZCBoYXMNCj4gNjIwICAgdGhlIGZvbGxvd2luZyBm b3JtYXQ6DQo+IA0KPiBbbml0XSBObyBuZWVkIHRvIHRhbGsgYWJvdXQgdGhlIFR5cGUgdHdpY2Uu DQo+IA0KPiA2MjIgICAgICAwICAgICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAg MiAgICAgICAgICAgICAgICAgICAzDQo+IDYyMyAgICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAx IDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMQ0KPiA2MjQgICAgICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rDQo+IDYyNSAgICAgfCAgICAgIFR5cGUgICAgIHwgICAgIExlbmd0aCAgICB8ICAgICBGbGFn cyAgICAgfCAgICAgUkVTRVJWRUQgIHwNCj4gNjI2ICAgICArLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiA2MjcgICAgIHwg ICAgICAgICAgICBSYW5nZSAgICAgICAgICAgICAgfCBQcmVmaXggTGVuZ3RoIHwgICAgIFByZWZp eCAgICB8DQo+IDYyOCAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4gNjI5ICAgICAvLyAgICAgICAgICAgICAgIFBy ZWZpeCAoY29udGludWVkLCB2YXJpYWJsZSkgICAgICAgICAgICAgICAgICAvLw0KPiA2MzAgICAg ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rDQo+IDYzMSAgICAgfCAgICAgICAgICAgICAgICAgICAgU3ViVExWcyAodmFyaWFi bGUpICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gNjMyICAgICArLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0KPiANCj4g NjM0ICAgICAgICAgICAgICAgICAgRmlndXJlIDE6IFNJRC9MYWJlbCBCaW5kaW5nIFRMViBmb3Jt YXQNCj4gDQo+IDYzNiAgIG8gIFR5cGU6IFRCRCwgc3VnZ2VzdGVkIHZhbHVlIDE0OQ0KPiANCj4g DQo+IC4uLg0KPiA2NTcgMi40LjEuICBGbGFncw0KPiAuLi4NCj4gNjcxICAgICAgTS1GbGFnOiBN aXJyb3IgQ29udGV4dCBmbGFnLiAgU2V0IGlmIHRoZSBhZHZlcnRpc2VkIFNJRA0KPiA2NzIgICAg ICBjb3JyZXNwb25kcyB0byBhIG1pcnJvcmVkIGNvbnRleHQuICBUaGUgdXNlIG9mIHRoZSBNIGZs YWcgaXMNCj4gNjczICAgICAgZGVzY3JpYmVkIGluIFtSRkM4NDAyXS4NCj4gDQo+IFttYWpvcl0g V2hlcmU/ICBOb3RlIHRoYXQgcmZjODQwMiBzYXlzIHRoYXQgIlRoZSBNaXJyb3IgU0lEIGlzIGFk dmVydGlzZWQNCj4gdXNpbmcgdGhlIEJpbmRpbmcgc2VnbWVudCBkZWZpbmVkIGluIFNSIElHUCBw cm90b2NvbCBleHRlbnNpb25zDQo+IFtJU0lTLVNSLUVYVF0uIiwgcG9pbnRpbmcgYmFjayBhdCB0 aGlzIGRvY3VtZW50Lg0KPiANCltMZXM6XSBSZXZpc2VkIHRleHQgdG8gYXZvaWQgY2lyY3VsYXIg cmVmZXJlbmNlcy4NCg0KPiBbbWlub3JdIFNvbWUgcGxhY2VzIHVzZSAqLUZsYWcgYW5kIG90aGVy cyAiKiBmbGFnIiwgcGxlYXNlIGJlIGNvbnNpc3RlbnQuDQo+DQpbTGVzOl0gRG9uZQ0KIA0KPiAN Cj4gNjc1ICAgICAgUy1GbGFnOiBJZiBzZXQsIHRoZSBTSUQvTGFiZWwgQmluZGluZyBUTFYgU0hP VUxEIGJlIGZsb29kZWQgYWNyb3NzDQo+IDY3NiAgICAgIHRoZSBlbnRpcmUgcm91dGluZyBkb21h aW4uICBJZiB0aGUgUyBmbGFnIGlzIG5vdCBzZXQsIHRoZSBTSUQvDQo+IDY3NyAgICAgIExhYmVs IEJpbmRpbmcgVExWIE1VU1QgTk9UIGJlIGxlYWtlZCBiZXR3ZWVuIGxldmVscy4gIFRoaXMgYml0 DQo+IDY3OCAgICAgIE1VU1QgTk9UIGJlIGFsdGVyZWQgZHVyaW5nIHRoZSBUTFYgbGVha2luZy4N Cj4gDQo+IFttYWpvcl0gSWYgdGhlIFMtRmxhZyBpcyBzZXQsIHdoZW4gd291bGQgdGhlIFRMViBu b3QgYmUgZmxvb2RlZCBhY3Jvc3MgdGhlDQo+IGVudGlyZSBkb21haW4/ICBJT1csIHdoeSBpcyB0 aGUgU0hPVUxEIG5vdCBhIE1VU1Q/DQo+IA0KW0xlczpdIFNIT1VMRCBpcyB1c2VkIGJlY2F1c2Ug b2YgdGhlIG9wdGlvbiB0byBpZ25vcmUgdGhlIFMtZmxhZyBzZXR0aW5nIGFuZCBzdXBwcmVzcyBp bnRlci1sZXZlbCBsZWFraW5nLg0KDQo+IA0KPiA2ODAgICAgICBELUZsYWc6IHdoZW4gdGhlIFNJ RC9MYWJlbCBCaW5kaW5nIFRMViBpcyBsZWFrZWQgZnJvbSBsZXZlbC0yIHRvDQo+IDY4MSAgICAg IGxldmVsLTEsIHRoZSBEIGJpdCBNVVNUIGJlIHNldC4gIE90aGVyd2lzZSwgdGhpcyBiaXQgTVVT VCBiZQ0KPiA2ODIgICAgICBjbGVhci4gIFNJRC9MYWJlbCBCaW5kaW5nIFRMVnMgd2l0aCB0aGUg RCBiaXQgc2V0IE1VU1QgTk9UIGJlDQo+IDY4MyAgICAgIGxlYWtlZCBmcm9tIGxldmVsLTEgdG8g bGV2ZWwtMi4gIFRoaXMgaXMgdG8gcHJldmVudCBUTFYgbG9vcGluZw0KPiA2ODQgICAgICBhY3Jv c3MgbGV2ZWxzLg0KPiANCj4gW21pbm9yXSBXaGF0IGFib3V0IGxlYWtpbmcgZnJvbSBMMiB0byBM MSB3aXRoIHRoZSBGbGFnIHNldD8NCj4gDQpbTGVzOl0gUGxlYXNlIHJlYWQgaHR0cHM6Ly90b29s cy5pZXRmLm9yZy9odG1sL3JmYzc3NzUjc2VjdGlvbi0yIHdoaWNoIGRpc2N1c3NlcyB0aGlzIGlz c3VlIGluIGRldGFpbC4NCg0KPiBbbWlub3JdIFRoZSB0ZXh0IHVzZXMgRmxhZywgYnV0IGluIHNv bWUgY2FzZXMgYml0IGlzIHVzZWQgYXMgd2VsbC4gIFBsZWFzZQ0KPiBiZSBjb25zaXN0ZW50Lg0K PiANCltMZXM6XSBEb25lDQoNCj4gDQo+IC4uLg0KPiA2OTUgICAgICBBbiBpbXBsZW1lbnRhdGlv biBNQVkgZGVjaWRlIG5vdCB0byBob25vciB0aGUgUy1mbGFnIGluIG9yZGVyIG5vdA0KPiA2OTYg ICAgICB0byBsZWFrIEJpbmRpbmcgVExWJ3MgYmV0d2VlbiBsZXZlbHMgKGZvciBwb2xpY3kgcmVh c29ucykuICBJbiBhbGwNCj4gNjk3ICAgICAgY2FzZXMsIHRoZSBEIGZsYWcgTVVTVCBhbHdheXMg YmUgc2V0IGJ5IGFueSByb3V0ZXIgbGVha2luZyB0aGUNCj4gNjk4ICAgICAgQmluZGluZyBUTFYg ZnJvbSBsZXZlbC0yIGludG8gbGV2ZWwtMSBhbmQgTVVTVCBiZSBjaGVja2VkIHdoZW4NCj4gNjk5 ICAgICAgcHJvcGFnYXRpbmcgdGhlIEJpbmRpbmcgVExWIGZyb20gbGV2ZWwtMSBpbnRvIGxldmVs LTIuICBJZiB0aGUgRA0KPiA3MDAgICAgICBmbGFnIGlzIHNldCwgdGhlIEJpbmRpbmcgVExWIE1V U1QgTk9UIGJlIHByb3BhZ2F0ZWQgaW50byBsZXZlbC0yLg0KPiANCj4gW21ham9yXSBzL2ltcGxl bWVudGF0aW9uIE1BWSBkZWNpZGUvaW1wbGVtZW50YXRpb24gbWF5IGRlY2lkZSAgIFRoZXJlJ3Mg bm8NCj4gTm9ybWF0aXZlIGFjdGlvbiB0aGVyZS4NCj4gDQpbTGVzOl0gRG9uZS4NCg0KPiBbbWFq b3JdIFJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBNQVkvbWF5IGlzIHVzZWQsIHRoZSBzdGF0ZW1lbnQg aW4gdGhlIGZpcnN0DQo+IHNlbnRlbmNlIGNvbnRyYWRpY3RzIHRoZSAiTVVTVCBOT1QgYmUgbGVh a2VkIiBOb3JtYXRpdmUgc3RhdGVtZW50LiAgR2l2ZW4NCj4gdGhhdCB0aGVyZSBhcmUgZXhjZXB0 aW9ucywgbWF5YmUgIlNIT1VMRCBOT1QiIHdvdWxkIGJlIG1vcmUgYXBwcm9wcmlhdGUuDQo+IA0K W0xlczpdIEFsdGVyZWQgdG8gU0hPVUxEIC0gd2hpY2ggd29ya3Mgd2l0aCB0aGUgTUFZL21heSBj aGFuZ2UgeW91IHN1Z2dlc3RlZA0KDQo+IFttYWpvcl0gVGhpcyBsYXN0IHBhcmFncmFwaCBzZWVt cyB0byBjb250YWluIHRoZSBzYW1lIGluZm9ybWF0aW9uIGFzIHRoZQ0KPiB0ZXh0IGRlc2NyaWJp bmcgdGhlIFMtRmxhZy4gIFBsZWFzZSBkb24ndCBkdXBsaWNhdGUgc3BlY2lmaWNhdGlvbnMuDQo+ IA0KPiA3MDIgICAgICBPdGhlciBiaXRzOiBNVVNUIGJlIHplcm8gd2hlbiBvcmlnaW5hdGVkIGFu ZCBpZ25vcmVkIHdoZW4NCj4gNzAzICAgICAgcmVjZWl2ZWQuDQo+IA0KPiBbbWFqb3JdIERvIHlv dSBleHBlY3QgSUFOQSB0byBoYW5kbGUgdGhlIGFzc2lnbm1lbnQgb2YgdGhvc2Ugb3RoZXIgYml0 cz8NCj4gDQpbTGVzOl0gTm8gLSBzZWUgcHJldmlvdXMgYW5zd2Vycy4NCg0KPiA3MDUgMi40LjIu ICBSYW5nZQ0KPiANCj4gNzA3ICAgVGhlICdSYW5nZScgZmllbGQgcHJvdmlkZXMgdGhlIGFiaWxp dHkgdG8gc3BlY2lmeSBhIHJhbmdlIG9mDQo+IDcwOCAgIGFkZHJlc3NlcyBhbmQgdGhlaXIgYXNz b2NpYXRlZCBQcmVmaXggU0lEcy4gIFRoaXMgYWR2ZXJ0aXNlbWVudA0KPiA3MDkgICBzdXBwb3J0 cyB0aGUgU1JNUyBmdW5jdGlvbmFsaXR5LiAgSXQgaXMgZXNzZW50aWFsbHkgYSBjb21wcmVzc2lv bg0KPiA3MTAgICBzY2hlbWUgdG8gZGlzdHJpYnV0ZSBhIGNvbnRpbnVvdXMgUHJlZml4IGFuZCB0 aGVpciBjb250aW51b3VzLA0KPiA3MTEgICBjb3JyZXNwb25kaW5nIFNJRC9MYWJlbCBCbG9jay4g IElmIGEgc2luZ2xlIFNJRCBpcyBhZHZlcnRpc2VkIHRoZW4NCj4gNzEyICAgdGhlIHJhbmdlIGZp ZWxkIE1VU1QgYmUgc2V0IHRvIG9uZS4gIEZvciByYW5nZSBhZHZlcnRpc2VtZW50cyA+IDEsDQo+ IDcxMyAgIHRoZSBudW1iZXIgb2YgYWRkcmVzc2VzIHRoYXQgbmVlZCB0byBiZSBtYXBwZWQgaW50 byBhIFByZWZpeC1TSUQgYW5kDQo+IDcxNCAgIHRoZSBzdGFydGluZyB2YWx1ZSBvZiB0aGUgUHJl Zml4LVNJRCByYW5nZS4NCj4gDQo+IFtuaXRdIFRoZSBsYXN0IHNlbnRlbmNlIHNvdW5kcyBpbmNv bXBsZXRlLi4uDQo+IA0KW0xlczpdIENvcnJlY3RlZC4NCg0KPiA3MTYgICBFeGFtcGxlIDE6IGlm IHRoZSBmb2xsb3dpbmcgcm91dGVyIGFkZHJlc3NlcyAobG9vcGJhY2sgYWRkcmVzc2VzKQ0KPiA3 MTcgICBuZWVkIHRvIGJlIG1hcHBlZCBpbnRvIHRoZSBjb3JyZXNwb25kaW5nIFByZWZpeCBTSUQg aW5kZXhlcy4NCj4gDQo+IFttaW5vcl0gU3VnZ2VzdGlvbjogbW92ZSB0aGUgZXhhbXBsZXMgdG8g dGhlIGVuZCBvZiDCpzIuNC4uLmFmdGVyIGFsbCB0aGUNCj4gZmllbGRzIGhhdmUgYmVlbiBkaXNj dXNzZWQuDQo+IA0KW0xlczpdIERvbmUuDQoNCj4gNzE5ICAgUm91dGVyLUE6IDE5Mi4wLjIuMS8z MiwgUHJlZml4LVNJRDogSW5kZXggMQ0KPiA3MjAgICBSb3V0ZXItQjogMTkyLjAuMi4yLzMyLCBQ cmVmaXgtU0lEOiBJbmRleCAyDQo+IDcyMSAgIFJvdXRlci1DOiAxOTIuMC4yLjMvMzIsIFByZWZp eC1TSUQ6IEluZGV4IDMNCj4gNzIyICAgUm91dGVyLUQ6IDE5Mi4wLjIuNC8zMiwgUHJlZml4LVNJ RDogSW5kZXggNA0KPiANCj4gNzI0ICAgICAgMCAgICAgICAgICAgICAgICAgICAxICAgICAgICAg ICAgICAgICAgIDIgICAgICAgICAgICAgICAgICAgMw0KPiA3MjUgICAgICAwIDEgMiAzIDQgNSA2 IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCj4gNzI2 ICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKw0KPiA3MjcgICAgIHwgICAgICBUeXBlICAgICB8ICAgICBMZW5ndGggICAg fDB8MHwgICAgICAgICAgIHwgICAgIFJFU0VSVkVEICB8DQo+IDcyOCAgICAgKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCj4g NzI5ICAgICB8ICAgICAgICAgICAgUmFuZ2UgPSA0ICAgICAgICAgIHwgICAgICAgLzMyICAgICB8 ICAgICAgMTkyICAgICAgfA0KPiA3MzAgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+IDczMSAgICAgfCAgICAgICAu MCAgICAgIHwgICAgICAgIC4yICAgICB8ICAgICAgIC4xICAgICAgfFByZWZpeC1TSUQgVHlwZXwN Cj4gNzMyICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKw0KPiA3MzMgICAgIHwgc3ViLVRMViBMZW5ndGh8ICAgICBGbGFn cyAgICAgfCAgIEFsZ29yaXRobSAgIHwgICAgICAgICAgICAgICB8DQo+IDczNCAgICAgKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSsNCj4gNzM1ICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgMSB8DQo+IDczNiAgICAgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKw0KPiANCj4gW25pdF0gVGhlIFByZWZpeCBMZW5ndGggc2hvdWxkIGJlICIzMiIs IG5vdCAiLzMyIi4NCj4gDQpbTGVzOl0gRG9uZS4NCg0KPiBbbml0XSBUaGUgUHJlZml4IGl0c2Vs ZiBpcyBvbmUgZmllbGQgKGluIHRoZSBkZXNjcmlwdGlvbiksIGJ1dCBpdCBsb29rcw0KPiBsaWtl IDQgc2VwYXJhdGUgZmllbGRzIGFib3ZlLi4uYW5kIHRoZSBudW1iZXJzIHNob3VsZCBub3QgaGF2 ZSAiLiIgaW4gdGhlbS4NCj4NCltMZXM6XSBSZWZvcm1hdHRlZCB0byBiZSBjb3JyZWN0Lg0KQnV0 IHdlIHdhbnQgdG8gaWxsdXN0cmF0ZSB0aGF0IHRoZSBudW1iZXIgb2YgYnl0ZXMgaW4gdGhlIFBy ZWZpeCBpcyB2YXJpYWJsZSBiYXNlZCBvbiBiaXQgbGVuZ3RoIHNwZWNpZmllZC4NCiANCj4gW21p bm9yXSBJdCBsb29rcyBsaWtlIHRoZSBmaWVsZHMgc3RhcnRpbmcgd2l0aCAiUHJlZml4LVNJRCBU eXBlIiBiZWxvbmcgdG8NCj4gdGhlIFByZWZpeC1TSUQgU3ViLVRMViwgYnV0IHRoYXQgaXMgbm90 IGV4cGxhaW5lZCBhbnl3aGVyZSAoeWV0KS4gIFRoZQ0KPiBBbGdvcml0aG0gZmllbGQgaXMgbm90 IHNldC4uLm5vciBhcmUgdGhlIEZsYWdzLg0KW0xlczpdIFRleHQgcmVvcmRlcmVkLg0KPiANCj4g NzM4ICAgRXhhbXBsZS0yOiBJZiB0aGUgZm9sbG93aW5nIHByZWZpeGVzIG5lZWQgdG8gYmUgbWFw cGVkIGludG8gdGhlDQo+IDczOSAgIGNvcnJlc3BvbmRpbmcgUHJlZml4LVNJRCBpbmRleGVzOg0K PiANCj4gNzQxICAgMTAuMS4xLzI0LCBQcmVmaXgtU0lEOiBJbmRleCA1MQ0KPiA3NDIgICAxMC4x LjIvMjQsIFByZWZpeC1TSUQ6IEluZGV4IDUyDQo+IDc0MyAgIDEwLjEuMy8yNCwgUHJlZml4LVNJ RDogSW5kZXggNTMNCj4gNzQ0ICAgMTAuMS40LzI0LCBQcmVmaXgtU0lEOiBJbmRleCA1NA0KPiA3 NDUgICAxMC4xLjUvMjQsIFByZWZpeC1TSUQ6IEluZGV4IDU1DQo+IDc0NiAgIDEwLjEuNi8yNCwg UHJlZml4LVNJRDogSW5kZXggNTYNCj4gNzQ3ICAgMTAuMS43LzI0LCBQcmVmaXgtU0lEOiBJbmRl eCA1Nw0KPiANCj4gW21ham9yXSBQbGVhc2UgdXNlIGFkZHJlc3NlcyBpbiB0aGUgcmZjNTczNyBy ZXNlcnZlZCByYW5nZXMuDQo+IA0KW0xlczpdIFVuZm9ydHVuYXRlbHkgdGhpcyBpcyBub3QgcG9z c2libGUuIFdoYXQgd2Ugd2FudCB0byBpbGx1c3RyYXRlIGhlcmUgaXMgdGhhdCB0aGUgZW5jb2Rp bmcgb2YgdGhlIHN0YXJ0aW5nIHByZWZpeCBpdHNlbGYgbWlnaHQgYmUgYWJicmV2aWF0ZWQgYmFz ZWQgb24gdGhlIHByZWZpeCBtYXNrLiBUbyBkbyBzbyB3ZSBNVVNUIHVzZSBhbiBleGFtcGxlIHBy ZWZpeCBvZiAvMjQgb3Igc2hvcnRlciBtYXNrIGxlbmd0aCAtIHdoaWNoIG1lYW5zIHdlIGhhdmUg dG8gdXNlIGFkZHJlc3NlcyB0aGF0IGFyZSBub3Qgc3BlY2lmaWVkIGluIFJGQyA1NzM3Lg0KDQo+ IFttaW5vcl0gSXQgd291bGQgaGF2ZSBiZWVuIG5pY2UgdG8gc2VlIGFuIElQdjYgZXhhbXBsZSAo c2VlIHJmYzM4NDkpLg0KPg0KW0xlczpdIEFkZGVkLg0KIA0KPiA3NDkgICAgICAwICAgICAgICAg ICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAzDQo+IDc1 MCAgICAgIDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDEgMiAzIDQg NSA2IDcgOCA5IDAgMQ0KPiA3NTEgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+IDc1MiAgICAgfCAgICAgIFR5cGUg ICAgIHwgICAgIExlbmd0aCAgICB8MHwwfCAgICAgICAgICAgfCAgICAgUkVTRVJWRUQgIHwNCj4g NzUzICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKw0KPiA3NTQgICAgIHwgICAgICAgICAgICBSYW5nZSA9IDcgICAgICAg ICAgfCAgICAgICAvMjQgICAgIHwgICAgICAxMCAgICAgICB8DQo+IDc1NSAgICAgKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsN Cj4gNzU2ICAgICB8ICAgICAgIC4xICAgICAgfCAgICAgICAgLjEgICAgIHxQcmVmaXgtU0lEIFR5 cGV8IHN1Yi1UTFYgTGVuZ3RofA0KPiA3NTcgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSst Ky0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rDQo+IDc1OCAgICAgfCAgICBG bGFncyAgICAgIHwgQWxnb3JpdGhtICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwNCj4gNzU5ICAgICArLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKw0KPiA3NjAgICAgIHwgICAgICAgICAgICAgICAgICAgICAg ICAgICA1MSAgfA0KPiA3NjEgICAgICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKw0K PiANCj4gW10gU2FtZSBjb21tZW50cyBhcyBhYm92ZS4NCj4gDQpbTGVzOl0gRG9uZS4NCj4gDQo+ IC4uLg0KPiA3NzggMi40LjMuICBQcmVmaXggTGVuZ3RoLCBQcmVmaXgNCj4gLi4uDQo+IDc4NCAg IFRoZSAnUHJlZml4IExlbmd0aCcgZmllbGQgY29udGFpbnMgdGhlIGxlbmd0aCBvZiB0aGUgcHJl Zml4IGluIGJpdHMuDQo+IDc4NSAgIE9ubHkgdGhlIG1vc3Qgc2lnbmlmaWNhbnQgb2N0ZXRzIG9m IHRoZSBQcmVmaXggYXJlIGVuY29kZWQuICAoaS5lLiwgMQ0KPiA3ODYgICBvY3RldCBmb3IgcHJl Zml4IGxlbmd0aCAxIHVwIHRvIDgsIDIgb2N0ZXRzIGZvciBwcmVmaXggbGVuZ3RoIDkgdG8NCj4g Nzg3ICAgMTYsIDMgb2N0ZXRzIGZvciBwcmVmaXggbGVuZ3RoIDE3IHVwIHRvIDI0IGFuZCA0IG9j dGV0cyBmb3IgcHJlZml4DQo+IDc4OCAgIGxlbmd0aCAyNSB1cCB0byAzMiwgLi4uLiwgMTYgb2N0 ZXRzIGZvciBwcmVmaXggbGVuZ3RoIDExMyB1cCB0byAxMjgpLg0KPiANCj4gW25pdF0gcy9lbmNv ZGVkLiAgKGkuZS4sL2VuY29kZWQgKGkuZS4sDQo+IA0KW0xlczpdIERvbmUuDQoNCj4gDQo+IDc5 MCAyLjQuNC4gIE1hcHBpbmcgU2VydmVyIFByZWZpeC1TSUQNCj4gDQo+IDc5MiAgIFRoZSBQcmVm aXgtU0lEIHN1Yi1UTFYgKHN1Z2dlc3RlZCB2YWx1ZSAzKSBpcyBkZWZpbmVkIGluIFNlY3Rpb24g Mi4xDQo+IDc5MyAgIGFuZCBjb250YWlucyB0aGUgU0lEL2luZGV4L2xhYmVsIHZhbHVlIGFzc29j aWF0ZWQgd2l0aCB0aGUgcHJlZml4IGFuZA0KPiA3OTQgICByYW5nZS4gIFRoZSBQcmVmaXgtU0lE IFN1YlRMViBNVVNUIGJlIHByZXNlbnQgaW4gdGhlIFNJRC9MYWJlbA0KPiA3OTUgICBCaW5kaW5n IFRMViB1bmxlc3MgdGhlIE0tZmxhZyBpcyBzZXQgaW4gdGhlIEZsYWdzIGZpZWxkIG9mIHRoZSBw YXJlbnQNCj4gNzk2ICAgVExWLg0KPiANCj4gW21ham9yXSBEb2VzIGl0IHRoZW4gbWVhbiB0aGF0 IHRoZSBQcmVmaXgtU0lEIFN1YlRMViBtdXN0IG5vdCBiZSBwcmVzZW50IGlmDQo+IHRoZSBNLUZs YWcgaXMgbm90IHNldD8NCj4gDQpbTGVzOl0gQ29ycmVjdC4gVGhpcyBoYXMgYmVlbiBjbGFyaWZp ZWQuDQoNCj4gW25pdF0gcy9TdWJUTFYvU3ViLVRMViAoYXMgaXQgaXMgdXNlZCBhbG1vc3QgZXZl cnl3aGVyZSBlbHNlKQ0KPiANCltMZXM6XSBEb25lLg0KDQo+IA0KPiA3OTggICBBIG5vZGUgcmVj ZWl2aW5nIGFuIFNSTVMgZW50cnkgZm9yIGEgcHJlZml4IE1VU1QgY2hlY2sgdGhlIGV4aXN0ZW5j ZQ0KPiA3OTkgICBvZiBzdWNoIHByZWZpeCBpbiBpdHMgbGluay1zdGF0ZSBkYXRhYmFzZSBwcmlv ciB0byBjb25zaWRlciBhbmQgdXNlDQo+IDgwMCAgIHRoZSBhc3NvY2lhdGVkIFNJRC4NCj4gDQo+ IFttYWpvcl0gV2hhdCBkb2VzIGl0IG1lYW4gZm9yIHRoZSBwcmVmaXggdG8gZXhpc3QgaW4gdGhl IGxpbmstc3RhdGUNCj4gZGF0YWJhc2U/ICBEb2VzIGl0IG1lYW4gdGhhdCBpdCBtdXN0IGhhdmUg YmVlbiBhZHZlcnRpc2VkIGluIGEgIm5vcm1hbCINCj4gcm91dGluZyBUTFYsIG9yIHNvbWV0aGlu ZyBlbHNlPyAgSSBhc2sgbm90IG9ubHkgdG8gY2xhcmlmeSwgYnV0IGJlY2F1c2UNCj4gwqcyLjQu MyBzYXlzIHRoYXQgdGhlICInUHJlZml4JyBkb2VzIG5vdCBuZWVkIHRvIGNvcnJlc3BvbmQgdG8g YSByb3V0YWJsZQ0KPiBwcmVmaXggb2YgdGhlIG9yaWdpbmF0aW5nIG5vZGUiLg0KPiANCj4gW0Fo Li4uSSB0aGluayBJIHVuZGVyc3RhbmQuICBCZWNhdXNlICJ0aGUgbWFwcGluZyBzZXJ2ZXIgZG9l cyBub3Qgc3BlY2lmeQ0KPiB0aGUgb3JpZ2luYXRvciBvZiBhIHByZWZpeCIgKMKnMi40LjQuMiks IHRoZW4gdGhlIHByZWZpeCBpcyBvYnZpb3VzbHkgbm90DQo+IHJvdXRhYmxlIGluIHRoZSBjb250 ZXh0IG9mIHRoZSBvcmlnaW5hdGluZyBub2RlICh0aGUgc2VydmVyKS4uLmJ1dCBpdA0KPiBzaG91 bGQgYmUgcm91dGFibGUgaW4gZ2VuZXJhbC4gIElzIHRoYXQgaXQ/XQ0KPg0KW0xlczpdIENvbmZ1 c2luZyB0ZXh0IHJlbW92ZWQuDQogDQo+IA0KPiA4MDIgMi40LjQuMS4gIFByZWZpeC1TSUQgRmxh Z3MNCj4gDQo+IDgwNCAgIFRoZSBQcmVmaXgtU0lEIGZsYWdzIGFyZSBkZWZpbmVkIGluIFNlY3Rp b24gMi4xLiAgVGhlIE1hcHBpbmcgU2VydmVyDQo+IDgwNSAgIE1BWSBhZHZlcnRpc2UgYSBtYXBw aW5nIHdpdGggdGhlIE4gZmxhZyBzZXQgd2hlbiB0aGUgcHJlZml4IGJlaW5nDQo+IDgwNiAgIG1h cHBlZCBpcyBrbm93biBpbiB0aGUgbGluay1zdGF0ZSB0b3BvbG9neSB3aXRoIGEgbWFzayBsZW5n dGggb2YgMzINCj4gODA3ICAgKElQdjQpIG9yIDEyOCAoSVB2NikgYW5kIHdoZW4gdGhlIHByZWZp eCByZXByZXNlbnRzIGEgbm9kZS4gIFRoZQ0KPiA4MDggICBtZWNoYW5pc21zIHRocm91Z2ggd2hp Y2ggdGhlIG9wZXJhdG9yIGRlZmluZXMgdGhhdCBhIHByZWZpeA0KPiA4MDkgICByZXByZXNlbnRz IGEgbm9kZSBhcmUgb3V0c2lkZSB0aGUgc2NvcGUgb2YgdGhpcyBkb2N1bWVudCAodHlwaWNhbGx5 DQo+IDgxMCAgIGl0IHdpbGwgYmUgdGhyb3VnaCBjb25maWd1cmF0aW9uKS4NCj4gDQo+IFttYWpv cl0gwqcyLjEuMS4yIHNheXMgdGhhdCB0aGUgInJvdXRlciBNQVkgc2V0IHRoZSBOLUZsYWcgb25s eSBpZi4uLiB0aGUNCj4gcHJlZml4IHRvIHdoaWNoIHRoZSBQcmVmaXgtU0lEIGlzIGF0dGFjaGVk IE1VU1QgaGF2ZSBhIFByZWZpeCBsZW5ndGggb2YNCj4gZWl0aGVyIC8zMiAoSVB2NCkgb3IgLzEy OCAoSVB2NikuIiAgVGhhdCBpcyBzaW1pbGFyIHRvIHdoYXQgdGhlIHRleHQgYWJvdmUNCj4gc2F5 cyAoYnV0IHRoZSB0ZXh0IHRhbGtzIGFib3V0ICJ0aGUgcHJlZml4Li4ua25vd24gaW4gdGhlIGxp bmstc3RhdGUNCj4gdG9wb2xvZ3kiKSwgYW5kIGl0IGlzIHJlbGF0ZWQgdG8gdGhlIGxhc3QgcXVl c3Rpb24gaW4gdGhlIHByZXZpb3VzDQo+IHNlY3Rpb24uICBEb2VzIHRoZSBwcmVmaXggYmVpbmcg aW4gdGhlIGxpbmstc3RhdGUgZGF0YWJhc2UvdG9wb2xvZ3kgbWVhbg0KPiB0aGF0IHRoZSBtYXRj aCBpcyBleGFjdCAodG8gdGhlIHByZWZpeCBhZHZlcnRpc2VkKSwgb3IgaXMgYSBzdXBlcm5ldCBv az8NCj4gDQpbTGVzOl0gQ29uZnVzaW5nIHRleHQgcmVtb3ZlZC4NCg0KPiANCj4gODEyICAgVGhl IG90aGVyIGZsYWdzIGRlZmluZWQgaW4gU2VjdGlvbiAyLjEgYXJlIG5vdCB1c2VkIGJ5IHRoZSBN YXBwaW5nDQo+IDgxMyAgIFNlcnZlciBhbmQgTVVTVCBiZSBpZ25vcmVkIGF0IHJlY2VwdGlvbi4N Cj4gDQo+IFttYWpvcl0gSG93IGRvZXMgdGhlIHJlY2VpdmVyIGtub3cgdGhhdCB0aGUgc3ViLVRM ViB3YXMgb3JpZ2luYXRlZCBieSBhDQo+IE1hcHBpbmcgU2VydmVyPyAgSXMgaXQgdGhlIGNhc2Ug dGhhdCBpdCB3b3VsZCBvcmlnaW5hdGUgYSBCaW5kaW5nIFRMVj8NCj4gSU9XLCB3b3VsZCB0aGUg b3RoZXIgZmxhZ3MgYWx3YXlzIGJlIGlnbm9yZWQgd2hlbiB0aGUgc3ViLVRMViBpcyBpbmNsdWRl ZA0KPiBpbiB0aGUgQmluZGluZyBUTFYgKGJ1dCBub3Qgb3RoZXIgVExWcyk/ICAgRG9lcyB0aGlz IGFwcGx5IGFsc28gdG8gdGhlDQo+IE11bHRpLVRvcG9sb2d5IFNJRC9MYWJlbCBCaW5kaW5nIFRM ViAowqcyLjUpPw0KPiANCltMZXM6XSAiWWVzIiB0byBhbGwgb2YgeW91ciBxdWVzdGlvbnMuDQoN Cj4gDQo+IDgxNSAyLjQuNC4yLiAgUEhQIEJlaGF2aW9yIHdoZW4gdXNpbmcgTWFwcGluZyBTZXJ2 ZXIgQWR2ZXJ0aXNlbWVudHMNCj4gLi4uDQo+IDgyMyAgIG8gIEEgcHJlZml4IHJlYWNoYWJpbGl0 eSBhZHZlcnRpc2VtZW50IGZvciB0aGUgcHJlZml4IGhhcyBiZWVuDQo+IDgyNCAgICAgIHJlY2Vp dmVkIHdoaWNoIGluY2x1ZGVzIHRoZSBFeHRlbmRlZCBSZWFjaGFiaWxpdHkgQXR0cmlidXRlIEZs YWdzDQo+IDgyNSAgICAgIHN1Yi1UTFYgKFtSRkM3Nzk0XSkuDQo+IA0KPiBbbml0XSBzLyhbUkZD Nzc5NF0pL1tSRkM3Nzk0XQ0KPiANCltMZXM6XSBEb25lDQoNCj4gODI3ICAgbyAgWCBhbmQgUiBm bGFncyBhcmUgYm90aCBzZXQgdG8gMCBpbiB0aGUgRXh0ZW5kZWQgUmVhY2hhYmlsaXR5DQo+IDgy OCAgICAgIEF0dHJpYnV0ZSBGbGFncyBzdWItVExWLg0KPiANCj4gODMwICAgSW4gdGhlIGFic2Vu Y2Ugb2YgYW4gRXh0ZW5kZWQgUmVhY2hhYmlsaXR5IEF0dHJpYnV0ZSBGbGFncyBzdWItVExWDQo+ IDgzMSAgIChbUkZDNzc5NF0pIHRoZSBBIGZsYWcgaW4gdGhlIGJpbmRpbmcgVExWIGluZGljYXRl cyB0aGF0IHRoZQ0KPiA4MzIgICBvcmlnaW5hdG9yIG9mIGEgcHJlZml4IHJlYWNoYWJpbGl0eSBh ZHZlcnRpc2VtZW50IGlzIGRpcmVjdGx5DQo+IDgzMyAgIGNvbm5lY3RlZCB0byB0aGUgcHJlZml4 IGFuZCB0aHVzIFBIUCBNVVNUIGJlIGRvbmUgYnkgdGhlIG5laWdoYm9ycyBvZg0KPiA4MzQgICB0 aGUgcm91dGVyIG9yaWdpbmF0aW5nIHRoZSBwcmVmaXggcmVhY2hhYmlsaXR5IGFkdmVydGlzZW1l bnQuICBOb3RlDQo+IDgzNSAgIHRoYXQgQS1mbGFnIGlzIG9ubHkgdmFsaWQgaW4gdGhlIG9yaWdp bmFsIGFyZWEgaW4gd2hpY2ggdGhlIEJpbmRpbmcNCj4gODM2ICAgVExWIGlzIGFkdmVydGlzZWQu DQo+IA0KPiBbbml0XSBzLyhbUkZDNzc5NF0pL1tSRkM3Nzk0XQ0KDQpbTGVzOl0gRG9uZQ0KDQo+ IA0KPiBbbWFqb3JdIMKnMi40LjEgc2F5cyB0aGF0ICJpZiB0aGUgQmluZGluZyBUTFYgaXMgbGVh a2VkLi4udGhlIEEtZmxhZyBNVVNUIGJlDQo+IGNsZWFyZWQiLCB3aGljaCBpcyBub3QgdGhlIHNh bWUgYXMgbm90IGNvbnNpZGVyaW5nIGl0IHZhbGlkIChpZ25vcmluZywgYXMNCj4gZGVzY3JpYmVk IGFib3ZlKS4gIEluIGFueSBjYXNlLCBwbGVhc2UgYmUgc3BlY2lmaWMgYWJvdXQgdGhlIGZ1bmN0 aW9uYWxpdHkNCj4gaW4gdGhlIGRlc2NyaXB0aW9uLg0KPg0KW0xlczpdIFJldmlzZWQgdGV4dCBw cm92aWRlZC4NCiANCj4gDQo+IDgzOCAyLjQuNC4zLiAgUHJlZml4LVNJRCBBbGdvcml0aG0NCj4g DQo+IDg0MCAgIFRoZSBhbGdvcml0aG0gZmllbGQgY29udGFpbnMgdGhlIGlkZW50aWZpZXIgb2Yg dGhlIGFsZ29yaXRobSB0aGUNCj4gODQxICAgcm91dGVyIE1VU1QgdXNlIGluIG9yZGVyIHRvIGNv bXB1dGUgcmVhY2hhYmlsaXR5IHRvIHRoZSByYW5nZSBvZg0KPiA4NDIgICBwcmVmaXhlcy4gIFVz ZSBvZiB0aGUgYWxnb3JpdGhtIGZpZWxkIGlzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDIuMS4NCj4g DQo+IFttYWpvciBuaXRdIEF0IGZpcnN0IGdsYW5jZSwgaXQgbG9va3MgbGlrZSB0aGlzIHNlY3Rp b24gaXMgbm90IG5lZWRlZA0KPiBiZWNhdXNlIGl0IHJlcGVhdHMgd2hhdCDCpzIuMSBhbHJlYWR5 IHNheXMgYWJvdXQgdGhlIGFsZ29yaXRobS4gIEJ1dCB0aGlzDQo+IHBhcmFncmFwaCByZWZlcnMg dG8gInRoZSBhbGdvcml0aG0gdGhlIHJvdXRlciBNVVNUIHVzZSBpbiBvcmRlciB0byBjb21wdXRl DQo+IHJlYWNoYWJpbGl0eSIsIGluIGNvbnRyYXN0IHRvIHRoZSBkZWZpbml0aW9uIG9mIHRoZSBm aWVsZCBpbiDCpzIuMTogIlRoZQ0KPiBhbGdvcml0aG0gZmllbGQuLi5jb250YWlucyB0aGUgaWRl bnRpZmllciBvZiB0aGUgYWxnb3JpdGhtIHRoZSByb3V0ZXIgaGFzDQo+IHVzZWQgaW4gb3JkZXIg dG8gY29tcHV0ZSB0aGUgcmVhY2hhYmlsaXR5Li4uIg0KPiANCltMZXM6XSBVbm5lY2Vzc2FyeSB0 ZXh0IHJlbW92ZWQuDQoNCj4gDQo+IC4uLg0KPiA5MDEgMy4xLiAgU1ItQ2FwYWJpbGl0aWVzIFN1 Yi1UTFYNCj4gLi4uDQo+IDkwOSAgIFRoZSBSb3V0ZXIgQ2FwYWJpbGl0eSBUTFYgc3BlY2lmaWVz IGZsYWdzIHRoYXQgY29udHJvbCBpdHMNCj4gOTEwICAgYWR2ZXJ0aXNlbWVudC4gIFRoZSBTUiBD YXBhYmlsaXRpZXMgc3ViLVRMViBNVVNUIGJlIHByb3BhZ2F0ZWQNCj4gOTExICAgdGhyb3VnaG91 dCB0aGUgbGV2ZWwgYW5kIE1VU1QgTk9UIGJlIGFkdmVydGlzZWQgYWNyb3NzIGxldmVsDQo+IDkx MiAgIGJvdW5kYXJpZXMuICBUaGVyZWZvcmUgUm91dGVyIENhcGFiaWxpdHkgVExWIGRpc3RyaWJ1 dGlvbiBmbGFncyBhcmUNCj4gOTEzICAgc2V0IGFjY29yZGluZ2x5LCBpLmUuLCB0aGUgUyBmbGFn IGluIHRoZSBSb3V0ZXIgQ2FwYWJpbGl0eSBUTFYNCj4gOTE0ICAgKFtSRkM3OTgxXSkgTVVTVCBi ZSB1bnNldC4NCj4gDQo+IFtuaXRdIHMvKFtSRkM3OTgxXSkvW1JGQzc5ODFdDQo+DQpbTGVzOl0g RG9uZS4NCiANCj4gDQo+IC4uLg0KPiA5NDMgICAgICAgICBJLUZsYWc6IE1QTFMgSVB2NCBmbGFn LiAgSWYgc2V0LCB0aGVuIHRoZSByb3V0ZXIgaXMgY2FwYWJsZSBvZg0KPiA5NDQgICAgICAgICBw cm9jZXNzaW5nIFNSIE1QTFMgZW5jYXBzdWxhdGVkIElQdjQgcGFja2V0cyBvbiBhbGwgaW50ZXJm YWNlcy4NCj4gDQo+IDk0NiAgICAgICAgIFYtRmxhZzogTVBMUyBJUHY2IGZsYWcuICBJZiBzZXQs IHRoZW4gdGhlIHJvdXRlciBpcyBjYXBhYmxlIG9mDQo+IDk0NyAgICAgICAgIHByb2Nlc3Npbmcg U1IgTVBMUyBlbmNhcHN1bGF0ZWQgSVB2NiBwYWNrZXRzIG9uIGFsbCBpbnRlcmZhY2VzLg0KPiAN Cj4gW21pbm9yXSBKdXN0IGN1cmlvdXM6IEhvdyBhcmUgdGhlc2UgZmxhZ3MgdXNlZD8gIEdpdmVu IHRoYXQgdGhlIGRhdGEgcGxhbmUNCj4gd2UncmUgZGVhbGluZyB3aXRoIGlzIE1QTFMuLi4NCg0K W0xlczpdIFRoaXMgaW5kaWNhdGVzIHdoZXRoZXIgdGhlIGFkdmVydGlzaW5nIHJvdXRlciBzdXBw b3J0cyBNUExTIGZvciBJUHY0IGFuZC9vciBJUHY2LiBOb3QgYWxsIGltcGxlbWVudGF0aW9ucyBz dXBwb3J0IGJvdGguDQoNCj4gDQo+IA0KPiAuLi4NCj4gOTgxICAgVGhlIG9yaWdpbmF0aW5nIHJv dXRlciBNVVNUIGVuc3VyZSB0aGUgb3JkZXIgaXMgc2FtZSBhZnRlciBhIGdyYWNlZnVsDQo+IDk4 MiAgIHJlc3RhcnQgKHVzaW5nIGNoZWNrcG9pbnRpbmcsIG5vbi12b2xhdGlsZSBzdG9yYWdlIG9y IGFueSBvdGhlcg0KPiA5ODMgICBtZWNoYW5pc20pIGluIG9yZGVyIHRvIGd1YXJhbnRlZSB0aGUg c2FtZSBvcmRlciBiZWZvcmUgYW5kIGFmdGVyIEdSLg0KPiANCj4gW25pdF0gcy9vcmRlciBpcyBz YW1lL29yZGVyIGlzIHRoZSBzYW1lDQo+DQpbTGVzOl0gRG9uZQ0KIA0KPiANCj4gLi4uDQo+IDEw MTUgMy4yLiAgU1ItQWxnb3JpdGhtIFN1Yi1UTFYNCj4gLi4uDQo+IDEwNDYgICBUaGUgU1ItQWxn b3JpdGhtIHN1Yi1UTFYgaXMgb3B0aW9uYWwsIGl0IE1BWSBvbmx5IGFwcGVhciBhIHNpbmdsZQ0K PiAxMDQ3ICAgdGltZSBpbnNpZGUgdGhlIFJvdXRlciBDYXBhYmlsaXR5IFRMVi4NCj4gDQo+IFtt YWpvcl0gIk1BWSBvbmx5IGFwcGVhciBhIHNpbmdsZSB0aW1lIiBtZWFucyB0aGF0IGl0IGNhbiBh cHBlYXIgbW9yZSB0aGFuDQo+IG9uY2UuICBJZiBpdCBkb2VzIHNob3cgdXAgbW9yZSB0aGFuIG9u Y2UsIHdoYXQgc2hvdWxkIHRoZSB0aGUgcmVjZWl2ZXIgZG8/DQo+IA0KW0xlczpdIFRleHQgaGFz IGJlZW4gYWRkZWQgdG8gc3RhdGUgaG93IHRvIGhhbmRsZSB0aGlzIGNhc2UuDQoNCj4gDQo+IDEw NDkgICBXaGVuIHRoZSBvcmlnaW5hdGluZyByb3V0ZXIgZG9lcyBub3QgYWR2ZXJ0aXNlIHRoZSBT Ui1BbGdvcml0aG0gc3ViLQ0KPiAxMDUwICAgVExWLCB0aGVuIGFsbCB0aGUgUHJlZml4LVNJRHMg YWR2ZXJ0aXNlZCBieSB0aGUgcm91dGVyIE1VU1QgaGF2ZQ0KPiAxMDUxICAgYWxnb3JpdGhtIGZp ZWxkIHNldCB0byAwLiAgQW55IHJlY2VpdmluZyByb3V0ZXIgTVVTVCBhc3N1bWUgU1BGDQo+IDEw NTIgICBhbGdvcml0aG0gKGkuZS4sIFNob3J0ZXN0IFBhdGggRmlyc3QpLg0KPiANCj4gW21pbm9y XSBJdCBzZWVtcyB0byBtZSB0aGF0IHRoaXMgcGFydCBvZiB0aGUgc3BlY2lmaWNhdGlvbiB3b3Vs ZCBmaXQgYmV0dGVyDQo+IGluIMKnMi4xLg0KPiANCj4gW21ham9yXSBCZXNpZGVzIG1heWJlIGJl aW5nIHJlZHVuZGFudCwgd2hhdCBpcyBzcGVjaWZpZWQgaW4gdGhlIGxhc3QNCj4gc2VudGVuY2U/ ICBJZiB0aGUgaW5kaWNhdGlvbiBvZiB0aGUgYWxnb3JpdGhtIGlzIGV4cGxpY2l0LCB0aGVuIEkg ZG9uJ3QNCj4gdW5kZXJzdGFuZCB3aGF0ICJNVVNUIGFzc3VtZSIgaXMgdHJ5aW5nIHRvIG1hbmRh dGUuDQo+IA0KPiANCj4gMTA1NCAgIFdoZW4gdGhlIG9yaWdpbmF0aW5nIHJvdXRlciBkb2VzIGFk dmVydGlzZSB0aGUgU1ItQWxnb3JpdGhtIHN1Yi1UTFYsDQo+IDEwNTUgICB0aGVuIGFsZ29yaXRo bSAwIE1VU1QgYmUgcHJlc2VudCB3aGlsZSBhbGdvcml0aG0gMSBNQVkgYmUgcHJlc2VudC4NCj4g DQo+IFtuaXRdIEkgdGhpbmsgdGhhdCBpdCBpcyBjbGVhciB0aGF0IGFsZ29yaXRobSAxIGlzIG9w dGlvbmFsLiAgSSB3b3VsZCB0YWtlDQo+IHRoYXQgbGFzdCBwYXJ0IG91dCBqdXN0IGJlY2F1c2Ug b3RoZXIgYWxnb3JpdGhtcyBtYXkgYmUgZGVmaW5lZCBpbiB0aGUNCj4gZnV0dXJlLi4uYW5kIHRo ZSBpbXBvcnRhbnQgcGFydCBhdCB0aGlzIHBvaW50IGlzIHRoZSBpbmNsdXNpb24gb2YgYWxnb3Jp dGhtDQo+IDAuDQo+IA0KW0xlczpdICBUZXh0IGhhcyBiZWVuIG1vZGlmaWVkIHRvIGFkZHJlc3Mg dGhlIGFib3ZlIGlzc3Vlcy4NCg0KPiANCj4gMTA1NyAgIFRoZSBTUi1BbGdvcml0aG0gc3ViLVRM ViBoYXMgZm9sbG93aW5nIGZvcm1hdDoNCj4gDQo+IFtuaXRdIHMvaGFzIGZvbGxvd2luZy9oYXMg dGhlIGZvbGxvd2luZw0KPiANCltMZXM6XSBEb25lDQoNCj4gDQo+IC4uLg0KPiAxMDczICAgICAg QWxnb3JpdGhtOiAxIG9jdGV0IG9mIGFsZ29yaXRobSBTZWN0aW9uIDIuMQ0KPiANCj4gW21pbm9y XSBUaGUgQWxnb3JpdGhtIGZpZWxkIGlzIGRlc2NyaWJlZCBpbiB0aGlzIHNlY3Rpb24sIG5vdCBp biAyLjEuDQo+IA0KW0xlczpdIERvbmUNCg0KPiANCj4gMTA3NSAzLjMuICBTUiBMb2NhbCBCbG9j ayBTdWItVExWDQo+IA0KPiAxMDc3ICAgVGhlIFNSIExvY2FsIEJsb2NrIChTUkxCKSBTdWItVExW IGNvbnRhaW5zIHRoZSByYW5nZSBvZiBsYWJlbHMgdGhlDQo+IDEwNzggICBub2RlIGhhcyByZXNl cnZlZCBmb3IgbG9jYWwgU0lEcy4gIExvY2FsIFNJRHMgYXJlIHVzZWQsIGUuZy4sIGZvcg0KPiAx MDc5ICAgQWRqYWNlbmN5LVNJRHMsIGFuZCBtYXkgYWxzbyBiZSBhbGxvY2F0ZWQgYnkgb3RoZXIg Y29tcG9uZW50cyB0aGFuDQo+IDEwODAgICBJUy1JUyBwcm90b2NvbC4gIEFzIGFuIGV4YW1wbGUs IGFuIGFwcGxpY2F0aW9uIG9yIGEgY29udHJvbGxlciBtYXkNCj4gMTA4MSAgIGluc3RydWN0IHRo ZSByb3V0ZXIgdG8gYWxsb2NhdGUgYSBzcGVjaWZpYyBsb2NhbCBTSUQuICBUaGVyZWZvcmUsIGlu DQo+IDEwODIgICBvcmRlciBmb3Igc3VjaCBhcHBsaWNhdGlvbnMgb3IgY29udHJvbGxlcnMgdG8g a25vdyB3aGF0IGFyZSB0aGUgbG9jYWwNCj4gMTA4MyAgIFNJRHMgYXZhaWxhYmxlIGluIHRoZSBy b3V0ZXIsIGl0IGlzIHJlcXVpcmVkIHRoYXQgdGhlIHJvdXRlcg0KPiAxMDg0ICAgYWR2ZXJ0aXNl cyBpdHMgU1JMQi4NCj4gDQo+IFtuaXRdIHMvdGhhbiBJUy1JUyBwcm90b2NvbC90aGFuIHRoZSBJ Uy1JUyBwcm90b2NvbA0KDQpbTGVzOl0gRG9uZS4NCg0KPiANCj4gDQo+IC4uLg0KPiAxMTIyICAg VGhlIG9yaWdpbmF0aW5nIHJvdXRlciBNVVNUIE5PVCBhZHZlcnRpc2Ugb3ZlcmxhcHBpbmcgcmFu Z2VzLg0KPiANCj4gW21ham9yXSBXaGF0IHNob3VsZCB0aGUgcmVjZWl2ZXIgZG8gaWYgdGhlIHJh bmdlcyBvdmVybGFwPyAgSSdtIGFzc3VtaW5nDQo+IHRoZSBzYW1lIHRoaW5nIGFzIHdoYXQgd2Fz IHNwZWNpZmllZCBiZWZvcmUuLi5wbGVhc2UgYmUgc3BlY2lmaWMuDQo+DQpbTGVzOl0gU2ltaWxh ciBxdWVzdGlvbiBpcyByZWxldmFudCB0byBTUkdCIGFuZCB0aGUgYmVoYXZpb3IgaGFzIGJlZW4g c3BlY2lmaWVkIGluIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLXNwcmlu Zy1zZWdtZW50LXJvdXRpbmctbXBscy0xOCNzZWN0aW9uLTIuMyBhbmQgdGhpcyBkcmFmdCByZWZl cmVuY2VzIGl0LiBJIHdvdWxkIGRvIHRoZSBzYW1lIGhlcmUsIGJ1dCB0aGUgU1IgTVBMUyBkcmFm dCBkb2VzIG5vdCBzcGVjaWZ5IGJlaGF2aW9yIGZvciBTUkxCIC0gZXZlbiB0aG91Z2ggdGhlIHJl ZmVyZW5jZWQgc2VjdGlvbiBpcyBlbnRpdGxlZCAiU2VnbWVudCBSb3V0aW5nIEdsb2JhbCBCbG9j ayBhbmQgTG9jYWwgQmxvY2siLiBCZXN0IHNvbHV0aW9uIEkgd291bGQgdGhpbmsgaXMgdG8gdXBk YXRlIFNSIE1QS1MgZHJhZnQgc28gdGhhdCBhIHJlZmVyZW5jZSB0byBpdCBjb3VsZCBiZSBhZGRl ZCBoZXJlLg0KIA0KPiANCj4gMTEyNCAgIEl0IGlzIGltcG9ydGFudCB0byBub3RlIHRoYXQgZWFj aCB0aW1lIGEgU0lEIGZyb20gdGhlIFNSTEIgaXMNCj4gMTEyNSAgIGFsbG9jYXRlZCwgaXQgU0hP VUxEIGFsc28gYmUgcmVwb3J0ZWQgdG8gYWxsIGNvbXBvbmVudHMgKGUuZy46DQo+IDExMjYgICBj b250cm9sbGVyIG9yIGFwcGxpY2F0aW9ucykgaW4gb3JkZXIgZm9yIHRoZXNlIGNvbXBvbmVudHMg dG8gaGF2ZSBhbg0KPiAxMTI3ICAgdXAtdG8tZGF0ZSB2aWV3IG9mIHRoZSBjdXJyZW50IFNSTEIg YWxsb2NhdGlvbiBhbmQgaW4gb3JkZXIgdG8gYXZvaWQNCj4gMTEyOCAgIGNvbGxpc2lvbiBiZXR3 ZWVuIGFsbG9jYXRpb24gaW5zdHJ1Y3Rpb25zLg0KPiANCj4gMTEzMCAgIFdpdGhpbiB0aGUgY29u dGV4dCBvZiBJUy1JUywgdGhlIHJlcG9ydGluZyBvZiBsb2NhbCBTSURzIGlzIGRvbmUNCj4gMTEz MSAgIHRocm91Z2ggSVMtSVMgU3ViLVRMVnMgc3VjaCBhcyB0aGUgQWRqYWNlbmN5LVNJRC4gIEhv d2V2ZXIsIHRoZQ0KPiAxMTMyICAgcmVwb3J0aW5nIG9mIGFsbG9jYXRlZCBsb2NhbCBTSURzIG1h eSBhbHNvIGJlIGRvbmUgdGhyb3VnaCBvdGhlcg0KPiAxMTMzICAgbWVhbnMgYW5kIHByb3RvY29s cyB3aGljaCBtZWNoYW5pc21zIGFyZSBvdXRzaWRlIHRoZSBzY29wZSBvZiB0aGlzDQo+IDExMzQg ICBkb2N1bWVudC4NCj4gDQo+IFttYWpvcl0gIlNIT1VMRCBhbHNvIGJlIHJlcG9ydGVkIHRvIGFs bCBjb21wb25lbnRzIiAgQmVjYXVzZSB0aGF0IGlzDQo+IG91dHNpZGUgdGhlIHNjb3BlLCB0aGVu IGl0IHNob3VsZG4ndCBiZSBhIE5vcm1hdGl2ZSBzdGF0ZW1lbnQuDQo+ICBzL1NIT1VMRC9zaG91 bGQNCj4gDQpbTGVzOl0gRG9uZS4NCg0KPiANCj4gLi4uDQo+IDExNzAgNC4gIE5vbiBiYWNrd2Fy ZCBjb21wYXRpYmxlIGNoYW5nZXMgd2l0aCBwcmlvciB2ZXJzaW9ucyBvZiB0aGlzDQo+IGRvY3Vt ZW50DQo+IA0KPiBbbWFqb3JdIEkgZmluZCB0aGlzIHNlY3Rpb24gdW5uZWNlc3NhcnkuICBJZiB5 b3Ugd2FudCB0byBrZWVwIGl0LCBwbGVhc2UNCj4gbW92ZSBpdCB0byBhbiBBcHBlbmRpeCBhbmQg ZG9uJ3QgdXNlIE5vcm1hdGl2ZSBsYW5ndWFnZS4NCj4gDQpbTGVzOl0gSSBoYXZlIHJlbW92ZWQg aXQuIFRoaXMgY2hhbmdlIHdhcyBtYWRlIGEgbG9uZyB0aW1lIGFnbyAtIEkgZG8gbm90IHRoaW5r IHdlIG5lZWQgdG8gY29udGludWUgdG8gYmUgY29uY2VybmVkIGFib3V0IHRoaXMgaW50ZXJvcGVy YWJpbGl0eSBpc3N1ZS4NCg0KPiANCj4gLi4uDQo+IDExOTAgNS4gIElBTkEgQ29uc2lkZXJhdGlv bnMNCj4gDQo+IDExOTIgICBUaGlzIGRvY3VtZW50cyByZXF1ZXN0IGFsbG9jYXRpb24gZm9yIHRo ZSBmb2xsb3dpbmcgVExWcyBhbmQgc3ViVExWcw0K From nobody Fri Mar 29 01:17:12 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6D5912021B for ; Fri, 29 Mar 2019 01:17:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 nQAuTIKiYI04 for ; Fri, 29 Mar 2019 01:17:09 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 477A6120144 for ; Fri, 29 Mar 2019 01:17:09 -0700 (PDT) Received: from pip.chopps.org (dhcp-9207.meeting.ietf.org [31.133.146.7]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 3ED76605A0; Fri, 29 Mar 2019 04:17:08 -0400 (EDT) User-agent: mu4e 1.0; emacs 26.1 From: Christian Hopps To: "lsr\@ietf.org" Cc: chopps@chopps.org Date: Fri, 29 Mar 2019 09:17:06 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: [Lsr] When to augment LSR base YANG modules... X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2019 08:17:11 -0000 --=-=-= Content-Type: text/plain; format=flowed The base YANG modules for IS-IS and OSPF both include operational state to describe TLV data. During the discussion about OSPFv3's version of this data, I brought up the issue of when and how the base modules should be augmented to add new TLV types to the model, suggesting it be done inline and with the RFC that adds the new feature/functionality to the protocol. I'll go farther here and say this should apply to all the YANG required for management of the new feature, and it should all be added inline with the feature (i.e., in the same draft). In other words new features/functionality should include the YANG augment required to manage said features/functionality. This has been suggested/tried previously with SNMP with varying (low) levels of success. The difference here is 1) YANG additions (a new module perhaps just augmenting the base) is easy, whereas SNMP wasn't. Additionally, operators weren't using SNMP to fully manage functionality (e.g., not doing configuration) so a requirement for extra work was harder to justify. Operators *do* want to fully manage their networks/servers with YANG though. The argument against this during the meeting was that it would create many small modules. I don't find this compelling (i.e., "so"? :) Assume I'm an operator -- the actual consumer of this management stuff: - If I'm going to use this new feature X, I need to be able to manage it. So I need it YANG for it. Not only do I need any new TLV data in the operational state, but I need the configuration and any other operational state right along with it. Otherwise each vendor has to add new YANG to their vendor modules, or the feature is useless to me. I can't use something if I can't turn it on. - I don't care about having many smaller modules that augment the base module -- at all. Quite the opposite actually, when new functionality is accompanied by it's own module it provides me a simple way to see if that functionality is present as the module will be present in the YANG capabilities announced by the device. I'd be interested in hearing reasons we (as a WG) shouldn't just expect a YANG module (even if it's small) to be included with drafts that add new functionality. Thanks, Chris. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAlyd1IIACgkQLh2DDte4 MCX8jhAAi88TDBwwcCzGLXMI3AjgXmLHisJ8wds2fgrVAUEosf5QF1u+czHywzrq oB/HOLQrikYhzwSoTPH68q2QkWUeGeAwB5mCbXIDZPosprWGz+7+w8QsyzDLEQ5D RbG3EI1aC07xcDwAKAkQf6kYsqXkRfe/SICXbvXqq5D2n5YOQAEnBPY0BVh+g49W TBwwSQuFiZ0jgl4IjHoOhYZrFRF5kiOXgPh28qW7YB3Q0m1OiCNfdgnuicGyNMfb ssPfsB8FLeL/1tzZWtmriA0cxu6U6cIaOa4vwH0TL/14HRTqJx32Xn01DQXfVTab OIhNM96zd45ulmdDvcMotwcHmOOy2NJSYo4vTkZ0afK+l3lXZQrWKUdaqHlKwbh6 /Xgzd+jwTa5RLjCAmFobkov8L1nGbsr6FV2FwZrObJxcJ2/60qsUBU4qInXpgoVG 6yiF+3yF1VVUGtuCCbL7D8sArHAHhN+y2ExCqKs2JiyMVMOHhiYOOfkF+PFYIUC+ bhkrrBrw8Z1D+aIXioIecnGl9TOqV+tvn9N85ZkvsDXYEv7Y9LPm/1eSXrbnx98i XiVIOuhzaMMeEDmGy7bVfWMAyE9m17TqwYbsb7Wx3IdBPgN8iof/K/O5jtRjbhWm N411Nxvk74+VFZTZT4YpW4Ir6wPMiV1wRyjMqaQc8Ec0c5MNrjQ= =vxzy -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Mar 29 01:32:01 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C105112051B for ; Fri, 29 Mar 2019 01:31:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.648 X-Spam-Level: X-Spam-Status: No, score=-1.648 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 fm1LKQNr9-Z0 for ; Fri, 29 Mar 2019 01:31:50 -0700 (PDT) Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) (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 43D4112046C for ; Fri, 29 Mar 2019 01:31:47 -0700 (PDT) Received: by mail-wm1-x330.google.com with SMTP id q16so1554531wmj.3 for ; Fri, 29 Mar 2019 01:31:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Jo/VclBp2baJtGtMXgU0C4JJob8JNuBM8EfnVF4683M=; b=FA9dMlXM3OvC8TmmrKh7zeJ5ShNAvVKQZVkp06xIKTCKD32AaTVnYxT0rVgAoX8INM RC50+sGmaI3Fr8srBEF5ro7kKLRw+/OWQs0GThhA/9e1uNgq/jxW6uMKPqmb6PEg1QeW 33DUkw0VBXsD3l/lbgrcqLwrYtMALKkikd0vB6fCv2qMJZfaCE1c/6jz+TphMlxUSzbd EWLhFTlku0MEL7uVpkXHeEW5IzPJRYHKQ02Y4ZHQDvIJGvEcSC3bquxKeCLJWxi3+LZ3 ssCDVJWqp0hADgHT8oeU963yGXQrcBcmeliWUoe9WRQQ1fh0Svp9QNZTdX95UteuT/5F HA8A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:mime-version:subject:from:in-reply-to :date:cc:content-transfer-encoding:message-id:references:to; bh=Jo/VclBp2baJtGtMXgU0C4JJob8JNuBM8EfnVF4683M=; b=afaerNnH5avzuBpkym+2ebHl9oicr3HqomQov/Q9zp+s4qGejnsbJxAsq1XZ8su9rT osM02aHtLxTp+52Ksfmw7V0YSfTCTZftDRH4jNro4SBoydxMt3Vb3D+7CSUQ4ntn+Ucx 7kpzrp5V5CW742RfGleGPsN5/pjiOPPf2hkFSnt59F9YU3OZoeBXqVh7s8wFsIPViR02 daf7ROrbUe45tHJpXnL7FeRk8Ao2+HjPQ40Sm2KV3o+OK2rdNo7y6E+s3MeIv+JT+oaJ nZDhIEIXnet2mbWzjmdghOtliXGZTTTouoM8M9MhrVhHe786TjBRmTBTicgnbiEGuajw aKsQ== X-Gm-Message-State: APjAAAWq9PNvAIHIRqTataUT0bA+NWNi+G37Qnzvugm60irVwuetCX1s bbsw+qYV+mY/10pqazhmWBbKbfKTiEU= X-Google-Smtp-Source: APXvYqyDRCjfeEGaFURihSnwt18qUaBFQdw/Wyny/MgXu6ES2YwTLqu2ig2m/t9O+eTKnQQoTJVXaQ== X-Received: by 2002:a1c:7a03:: with SMTP id v3mr2544806wmc.58.1553848305776; Fri, 29 Mar 2019 01:31:45 -0700 (PDT) Received: from ?IPv6:2001:67c:370:128:f837:b7ed:f2ac:3602? ([2001:67c:370:128:f837:b7ed:f2ac:3602]) by smtp.gmail.com with ESMTPSA id n11sm1639661wrt.63.2019.03.29.01.31.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 Mar 2019 01:31:45 -0700 (PDT) Sender: Tony Li Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) From: tony.li@tony.li In-Reply-To: Date: Fri, 29 Mar 2019 09:31:36 +0100 Cc: "lsr@ietf.org" Content-Transfer-Encoding: quoted-printable Message-Id: <2E6CA4AD-AD65-4A20-9545-1C81ED8B8968@tony.li> References: To: Christian Hopps X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Lsr] When to augment LSR base YANG modules... X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2019 08:32:01 -0000 Chris, One concern is simply one of scale: doing this will increase the size of = the document. At what point do things become sufficiently awkward that = we want to have a separate, concurrent document. In other words, if the requirement is for concurrent delivery, is = co-location really a requirement? Regards, Tony > On Mar 29, 2019, at 9:17 AM, Christian Hopps = wrote: >=20 >=20 > The base YANG modules for IS-IS and OSPF both include operational = state to describe TLV data. During the discussion about OSPFv3's version = of this data, I brought up the issue of when and how the base modules = should be augmented to add new TLV types to the model, suggesting it be = done inline and with the RFC that adds the new feature/functionality to = the protocol. >=20 > I'll go farther here and say this should apply to all the YANG = required for management of the new feature, and it should all be added = inline with the feature (i.e., in the same draft). In other words new = features/functionality should include the YANG augment required to = manage said features/functionality. >=20 > This has been suggested/tried previously with SNMP with varying (low) = levels of success. The difference here is 1) YANG additions (a new = module perhaps just augmenting the base) is easy, whereas SNMP wasn't. = Additionally, operators weren't using SNMP to fully manage functionality = (e.g., not doing configuration) so a requirement for extra work was = harder to justify. Operators *do* want to fully manage their = networks/servers with YANG though. >=20 > The argument against this during the meeting was that it would create = many small modules. I don't find this compelling (i.e., "so"? :) >=20 > Assume I'm an operator -- the actual consumer of this management = stuff: >=20 > - If I'm going to use this new feature X, I need to be able to manage = it. So I need it YANG for it. Not only do I need any new TLV data in the = operational state, but I need the configuration and any other = operational state right along with it. Otherwise each vendor has to add = new YANG to their vendor modules, or the feature is useless to me. I = can't use something if I can't turn it on. >=20 > - I don't care about having many smaller modules that augment the base = module -- at all. Quite the opposite actually, when new functionality is = accompanied by it's own module it provides me a simple way to see if = that functionality is present as the module will be present in the YANG = capabilities announced by the device. >=20 > I'd be interested in hearing reasons we (as a WG) shouldn't just = expect a YANG module (even if it's small) to be included with drafts = that add new functionality. >=20 > Thanks, > Chris. > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr From nobody Sat Mar 30 09:14:54 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B441B1201B5 for ; Sat, 30 Mar 2019 09:14:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.501 X-Spam-Level: X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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=jBZ+Wugb; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=lxZIR/wM 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 PfxOdlpqndEX for ; Sat, 30 Mar 2019 09:14:49 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5548A1201A3 for ; Sat, 30 Mar 2019 09:14:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5350; q=dns/txt; s=iport; t=1553962489; x=1555172089; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=b4g2SBMsA/mayCLpKZVyxGBxT+SyRjGer3DSNpPbq48=; b=jBZ+WugbU9Q1VuqBBAAAnQFBK1DCrxqBCQCvDOwSdqyElal0GgJJXo5l 2eFsFs6bsAHE2Fyp8AwGv/c85hFMBLLdPONHJ2wqFAr3i9lRWyQoKByUv 1/8L2TspV/67zCQkRITCcreUWmDpjy3z0I36N0YJKy297X+OZqlmYgrn8 c=; IronPort-PHdr: =?us-ascii?q?9a23=3AneCtmxT+T7UzHwgEYPg+pMukh9psv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESUANfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH1?= =?us-ascii?q?5NksAKh0olCc+BB1f8KavjZCE3NM9DT1RiuXq8NBsdFQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AHAAD/lJ9c/5tdJa1kGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUwIBAQEBAQsBgT1QA2h0BAsnCoQEg0cDjzKCV5cPgS6?= =?us-ascii?q?BJANUDgEBGAsJhEACF4UgIjYHDQEBAwEBCQEDAm0cDIVKAQEBAQIBAQEhEQw?= =?us-ascii?q?BASwLAQ8CAQgYAgImAgICJQsVEAIEAQ0FgyIBgV0DDQgBDp0uAooUcYEvgnk?= =?us-ascii?q?BAQWCRoI2GIIMAwWBCyQBizIXgX+BECgfgh4uPoJhAQGEa4JXin+CBJhKCQK?= =?us-ascii?q?TXhqULIs/k04CBAIEBQIOAQEFgVQELYFWcBU7KgGCQYIKDBeDS4NGgU6FP3K?= =?us-ascii?q?BKI4UAYEeAQE?= X-IronPort-AV: E=Sophos;i="5.60,289,1549929600"; d="scan'208";a="323173061" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 30 Mar 2019 16:14:47 +0000 Received: from XCH-ALN-002.cisco.com (xch-aln-002.cisco.com [173.36.7.12]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x2UGElrg022790 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sat, 30 Mar 2019 16:14:47 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-002.cisco.com (173.36.7.12) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sat, 30 Mar 2019 11:14:47 -0500 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.1473.3; Sat, 30 Mar 2019 11:14:46 -0500 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sat, 30 Mar 2019 12:14:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=b4g2SBMsA/mayCLpKZVyxGBxT+SyRjGer3DSNpPbq48=; b=lxZIR/wMqyqsZmfamNyPM9Zk3IjfVacP6H9CdWK4fAAo130SYcu5jn4tMqPyiFqZ2KNJG8uTlycFmUQVxjYdybk7PxfhoMnBZQyqxb0nivzFNbBBJccfVr0g3UY/gbbJtdP6C1PxM3jRZBTdgMSQMKEjsU3TZmY4OOKyoTLYq6U= Received: from BN6PR1101MB2226.namprd11.prod.outlook.com (10.174.112.11) by BN6PR1101MB2275.namprd11.prod.outlook.com (10.174.114.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1730.18; Sat, 30 Mar 2019 16:14:44 +0000 Received: from BN6PR1101MB2226.namprd11.prod.outlook.com ([fe80::9c05:e282:840b:51a1]) by BN6PR1101MB2226.namprd11.prod.outlook.com ([fe80::9c05:e282:840b:51a1%8]) with mapi id 15.20.1750.017; Sat, 30 Mar 2019 16:14:44 +0000 From: "Acee Lindem (acee)" To: "tony.li@tony.li" , Christian Hopps CC: "lsr@ietf.org" Thread-Topic: [Lsr] When to augment LSR base YANG modules... Thread-Index: AQHU5gfd4acSIv/HVEeXIb5nGax0OaYiR5UAgAHQpQA= Date: Sat, 30 Mar 2019 16:14:44 +0000 Message-ID: References: <2E6CA4AD-AD65-4A20-9545-1C81ED8B8968@tony.li> In-Reply-To: <2E6CA4AD-AD65-4A20-9545-1C81ED8B8968@tony.li> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=acee@cisco.com; x-originating-ip: [128.107.241.180] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 57155aa7-120b-4be6-2534-08d6b52ad2ba x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600127)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:BN6PR1101MB2275; x-ms-traffictypediagnostic: BN6PR1101MB2275: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 09928BEC91 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39860400002)(366004)(136003)(346002)(376002)(396003)(199004)(189003)(97736004)(3846002)(446003)(68736007)(229853002)(8936002)(11346002)(26005)(25786009)(71200400001)(105586002)(33656002)(476003)(106356001)(8676002)(81156014)(6512007)(76176011)(2501003)(6116002)(186003)(305945005)(81166006)(2616005)(6506007)(36756003)(53546011)(53936002)(6486002)(2906002)(71190400001)(6306002)(478600001)(966005)(102836004)(83716004)(7736002)(256004)(99286004)(82746002)(5660300002)(6246003)(6436002)(486006)(66066001)(110136005)(4326008)(86362001)(316002)(14454004); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR1101MB2275; H:BN6PR1101MB2226.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: ab3PSx7sRJXFdpYzmpzIKqmJSW3DPBrmlzJPfMfU9F5u9urJa80f1c07dJ70OGZTwp5gojDtbTSjN+dy2HA9GVuNQGGi5cvugRUKm6fM7zbST+8Z1oZZdZhs9n0O5u+I67RvNgiofLjBTeROD4E5pd/XEYMF+d8tOjgc6C4YyOkkvflZph74Ils9nSKjrU3nLdKO2fcVA313eFf7zUXe+gzmiTbLuWJDDWfF0UPVnhG27TeH+g6hGGqxXDrsrOsTS2xJ4mcTln0gLgc1/4ged9Rt3NOPdn6cBBGJreY9G5zYBTFiu8q5+u2IGkdc/9AM/vlpEN+ON1UYK8TnKPAznUWN22FqvtaozGze+OZSQ4kaoLE3JEsvybrcPsYj5sUA0QueCUMEsd6jWjS+w9PwWtSVl4TiUw78R+MGue4Q7YM= Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 57155aa7-120b-4be6-2534-08d6b52ad2ba X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Mar 2019 16:14:44.7491 (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-Transport-CrossTenantHeadersStamped: BN6PR1101MB2275 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.12, xch-aln-002.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: Re: [Lsr] When to augment LSR base YANG modules... X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2019 16:14:52 -0000 U3BlYWtpbmcgYXMgV0cgbWVtYmVyOg0KDQpGb3IgbWFueSBvZiB0aGUgbmV3IExTUiBXRyBkb2N1 bWVudHMsIHdlIGFyZSBhbHJlYWR5IGluY2x1ZGVkIGJvdGggT1NQRiBhbmQgSVMtSVMgZW5jb2Rp bmdzIGluIGEgc2luZ2xlIGRvY3VtZW50LiBOb3csIHdlIGhhdmUgYWdyZWVkIHRoYXQgZG9jdW1l bnRzIHJlcXVpcmluZyBzaW1wbGUgQkdQLUxTIGNoYW5nZXMgd2lsbCBhbHNvIGluY2x1ZGUgdGhl IEJHUC1MUyBlbmNvZGluZy4gR2l2ZW4gdGhpcywgSSBkb24ndCB3YW50IHRvIGFkZCBhbm90aGVy IHJlcXVpcmVtZW50IGZvciBwdWJsaWNhdGlvbiBvZiBhIFdHIGRvY3VtZW50LiBUaGlzIHdvdWxk IGFsc28gYWRkIGFkZGl0aW9uYWwgcmV2aWV3cyB0byB0aGUgZG9jdW1lbnQuIFlvdSd2ZSBhbGwg aGVhcmQgdGhlIGV4cHJlc3Npb24gImRpdmlkZSBhbmQgY29ucXVlciIsIHdoaWxlIGxldCBtZSBp bnRyb2R1Y2UgdGhlIGNvcm9sbGFyeSwgImNvbnNvbGlkYXRlIGFuZCBzdGFnbmF0ZSIuIA0KDQpB ZGRpdGlvbmFsbHksIEkgYWdyZWUgd2l0aCBZaW5nemhlbidzIGNvbW1lbnQgdGhhdCBpdCBpcyBu b3QgY2xlYXIgdGhhdCB3ZSB3YW50IGEgc2VwYXJhdGUgWUFORyBtb2R1bGUgZm9yIGV2ZXJ5IE9T UEYvSVMtSVMgZmVhdHVyZS4gDQoNClRoYW5rcywNCkFjZWUNCg0K77u/T24gMy8yOS8xOSwgNDoz MyBBTSwgIkxzciBvbiBiZWhhbGYgb2YgdG9ueS5saUB0b255LmxpIiA8bHNyLWJvdW5jZXNAaWV0 Zi5vcmcgb24gYmVoYWxmIG9mIHRvbnkubGlAdG9ueS5saT4gd3JvdGU6DQoNCiAgICANCiAgICBD aHJpcywNCiAgICANCiAgICBPbmUgY29uY2VybiBpcyBzaW1wbHkgb25lIG9mIHNjYWxlOiBkb2lu ZyB0aGlzIHdpbGwgaW5jcmVhc2UgdGhlIHNpemUgb2YgdGhlIGRvY3VtZW50LiAgQXQgd2hhdCBw b2ludCBkbyB0aGluZ3MgYmVjb21lIHN1ZmZpY2llbnRseSBhd2t3YXJkIHRoYXQgd2Ugd2FudCB0 byBoYXZlIGEgc2VwYXJhdGUsIGNvbmN1cnJlbnQgZG9jdW1lbnQuDQogICAgDQogICAgSW4gb3Ro ZXIgd29yZHMsIGlmIHRoZSByZXF1aXJlbWVudCBpcyBmb3IgY29uY3VycmVudCBkZWxpdmVyeSwg aXMgY28tbG9jYXRpb24gcmVhbGx5IGEgcmVxdWlyZW1lbnQ/DQogICAgDQogICAgUmVnYXJkcywN CiAgICBUb255DQogICAgDQogICAgDQogICAgPiBPbiBNYXIgMjksIDIwMTksIGF0IDk6MTcgQU0s IENocmlzdGlhbiBIb3BwcyA8Y2hvcHBzQGNob3Bwcy5vcmc+IHdyb3RlOg0KICAgID4gDQogICAg PiANCiAgICA+IFRoZSBiYXNlIFlBTkcgbW9kdWxlcyBmb3IgSVMtSVMgYW5kIE9TUEYgYm90aCBp bmNsdWRlIG9wZXJhdGlvbmFsIHN0YXRlIHRvIGRlc2NyaWJlIFRMViBkYXRhLiBEdXJpbmcgdGhl IGRpc2N1c3Npb24gYWJvdXQgT1NQRnYzJ3MgdmVyc2lvbiBvZiB0aGlzIGRhdGEsIEkgYnJvdWdo dCB1cCB0aGUgaXNzdWUgb2Ygd2hlbiBhbmQgaG93IHRoZSBiYXNlIG1vZHVsZXMgc2hvdWxkIGJl IGF1Z21lbnRlZCB0byBhZGQgbmV3IFRMViB0eXBlcyB0byB0aGUgbW9kZWwsIHN1Z2dlc3Rpbmcg aXQgYmUgZG9uZSBpbmxpbmUgYW5kIHdpdGggdGhlIFJGQyB0aGF0IGFkZHMgdGhlIG5ldyBmZWF0 dXJlL2Z1bmN0aW9uYWxpdHkgdG8gdGhlIHByb3RvY29sLg0KICAgID4gDQogICAgPiBJJ2xsIGdv IGZhcnRoZXIgaGVyZSBhbmQgc2F5IHRoaXMgc2hvdWxkIGFwcGx5IHRvIGFsbCB0aGUgWUFORyBy ZXF1aXJlZCBmb3IgbWFuYWdlbWVudCBvZiB0aGUgbmV3IGZlYXR1cmUsIGFuZCBpdCBzaG91bGQg YWxsIGJlIGFkZGVkIGlubGluZSB3aXRoIHRoZSBmZWF0dXJlIChpLmUuLCBpbiB0aGUgc2FtZSBk cmFmdCkuIEluIG90aGVyIHdvcmRzIG5ldyBmZWF0dXJlcy9mdW5jdGlvbmFsaXR5IHNob3VsZCBp bmNsdWRlIHRoZSBZQU5HIGF1Z21lbnQgcmVxdWlyZWQgdG8gbWFuYWdlIHNhaWQgZmVhdHVyZXMv ZnVuY3Rpb25hbGl0eS4NCiAgICA+IA0KICAgID4gVGhpcyBoYXMgYmVlbiBzdWdnZXN0ZWQvdHJp ZWQgcHJldmlvdXNseSB3aXRoIFNOTVAgd2l0aCB2YXJ5aW5nIChsb3cpIGxldmVscyBvZiBzdWNj ZXNzLiBUaGUgZGlmZmVyZW5jZSBoZXJlIGlzIDEpIFlBTkcgYWRkaXRpb25zIChhIG5ldyBtb2R1 bGUgcGVyaGFwcyBqdXN0IGF1Z21lbnRpbmcgdGhlIGJhc2UpIGlzIGVhc3ksIHdoZXJlYXMgU05N UCB3YXNuJ3QuIEFkZGl0aW9uYWxseSwgb3BlcmF0b3JzIHdlcmVuJ3QgdXNpbmcgU05NUCB0byBm dWxseSBtYW5hZ2UgZnVuY3Rpb25hbGl0eSAoZS5nLiwgbm90IGRvaW5nIGNvbmZpZ3VyYXRpb24p IHNvIGEgcmVxdWlyZW1lbnQgZm9yIGV4dHJhIHdvcmsgd2FzIGhhcmRlciB0byBqdXN0aWZ5LiBP cGVyYXRvcnMgKmRvKiB3YW50IHRvIGZ1bGx5IG1hbmFnZSB0aGVpciBuZXR3b3Jrcy9zZXJ2ZXJz IHdpdGggWUFORyB0aG91Z2guDQogICAgPiANCiAgICA+IFRoZSBhcmd1bWVudCBhZ2FpbnN0IHRo aXMgZHVyaW5nIHRoZSBtZWV0aW5nIHdhcyB0aGF0IGl0IHdvdWxkIGNyZWF0ZSBtYW55IHNtYWxs IG1vZHVsZXMuIEkgZG9uJ3QgZmluZCB0aGlzIGNvbXBlbGxpbmcgKGkuZS4sICJzbyI/IDopDQog ICAgPiANCiAgICA+IEFzc3VtZSBJJ20gYW4gb3BlcmF0b3IgLS0gdGhlIGFjdHVhbCBjb25zdW1l ciBvZiB0aGlzIG1hbmFnZW1lbnQgc3R1ZmY6DQogICAgPiANCiAgICA+IC0gSWYgSSdtIGdvaW5n IHRvIHVzZSB0aGlzIG5ldyBmZWF0dXJlIFgsIEkgbmVlZCB0byBiZSBhYmxlIHRvIG1hbmFnZSBp dC4gU28gSSBuZWVkIGl0IFlBTkcgZm9yIGl0LiBOb3Qgb25seSBkbyBJIG5lZWQgYW55IG5ldyBU TFYgZGF0YSBpbiB0aGUgb3BlcmF0aW9uYWwgc3RhdGUsIGJ1dCBJIG5lZWQgdGhlIGNvbmZpZ3Vy YXRpb24gYW5kIGFueSBvdGhlciBvcGVyYXRpb25hbCBzdGF0ZSByaWdodCBhbG9uZyB3aXRoIGl0 LiBPdGhlcndpc2UgZWFjaCB2ZW5kb3IgaGFzIHRvIGFkZCBuZXcgWUFORyB0byB0aGVpciB2ZW5k b3IgbW9kdWxlcywgb3IgdGhlIGZlYXR1cmUgaXMgdXNlbGVzcyB0byBtZS4gSSBjYW4ndCB1c2Ug c29tZXRoaW5nIGlmIEkgY2FuJ3QgdHVybiBpdCBvbi4NCiAgICA+IA0KICAgID4gLSBJIGRvbid0 IGNhcmUgYWJvdXQgaGF2aW5nIG1hbnkgc21hbGxlciBtb2R1bGVzIHRoYXQgYXVnbWVudCB0aGUg YmFzZSBtb2R1bGUgLS0gYXQgYWxsLiBRdWl0ZSB0aGUgb3Bwb3NpdGUgYWN0dWFsbHksIHdoZW4g bmV3IGZ1bmN0aW9uYWxpdHkgaXMgYWNjb21wYW5pZWQgYnkgaXQncyBvd24gbW9kdWxlIGl0IHBy b3ZpZGVzIG1lIGEgc2ltcGxlIHdheSB0byBzZWUgaWYgdGhhdCBmdW5jdGlvbmFsaXR5IGlzIHBy ZXNlbnQgYXMgdGhlIG1vZHVsZSB3aWxsIGJlIHByZXNlbnQgaW4gdGhlIFlBTkcgY2FwYWJpbGl0 aWVzIGFubm91bmNlZCBieSB0aGUgZGV2aWNlLg0KICAgID4gDQogICAgPiBJJ2QgYmUgaW50ZXJl c3RlZCBpbiBoZWFyaW5nIHJlYXNvbnMgd2UgKGFzIGEgV0cpIHNob3VsZG4ndCBqdXN0IGV4cGVj dCBhIFlBTkcgbW9kdWxlIChldmVuIGlmIGl0J3Mgc21hbGwpIHRvIGJlIGluY2x1ZGVkIHdpdGgg ZHJhZnRzIHRoYXQgYWRkIG5ldyBmdW5jdGlvbmFsaXR5Lg0KICAgID4gDQogICAgPiBUaGFua3Ms DQogICAgPiBDaHJpcy4NCiAgICA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQogICAgPiBMc3IgbWFpbGluZyBsaXN0DQogICAgPiBMc3JAaWV0Zi5vcmcN CiAgICA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHNyDQogICAgDQog ICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICBM c3IgbWFpbGluZyBsaXN0DQogICAgTHNyQGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9sc3INCiAgICANCg0K From nobody Sat Mar 30 11:00:19 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 245A5120240 for ; Sat, 30 Mar 2019 11:00:18 -0700 (PDT) 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, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=rob-sh.20150623.gappssmtp.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 yng1rAZHOd5K for ; Sat, 30 Mar 2019 11:00:14 -0700 (PDT) Received: from mail-oi1-x22b.google.com (mail-oi1-x22b.google.com [IPv6:2607:f8b0:4864:20::22b]) (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 9BCDB120232 for ; Sat, 30 Mar 2019 11:00:14 -0700 (PDT) Received: by mail-oi1-x22b.google.com with SMTP id v7so4154573oie.8 for ; Sat, 30 Mar 2019 11:00:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=rob-sh.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=p2j5XDPggyN+QPgj4FAmIKfrBh6OX7OAMHBxqttfYRY=; b=okVKog8Db6NsGnQnvslSEPf4Bx7t5dL414O30BupHezXTmPrT7z9zhghfHjnlPycPJ BZw/FX9A+FXFCKKvLAfCWavXVg47PYUIlW01ggdI7A1jZ0/tv/KuZoBl/wzOqukssYNG hVj6HGZ8FgoyehxzBL8n0rfv5RtY6738OgqYUxGHDJ8vcOCoGXuqw8L73BY0p+rqYm8/ Hw7Mzb7d5gc1ej2mjekrLKzFe/TPM2RrtFuMoeCacJzeFhfvy5eCTNL7p/MxWD4LSSZZ iTNJs7mpUoh444eMOfbqbxpW0wSbUECYctWrBwvGDPklMgQPmgiBakMtLu8dRd41zjjH QJsw== 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=p2j5XDPggyN+QPgj4FAmIKfrBh6OX7OAMHBxqttfYRY=; b=PNssPr4kTKPnY3W7uINWGK1p9UPc48V8aVD2ks817/NnXNrc4r0TfpSdvWIGGw38+A CLmAU53wok23xfSP4cQXnf/MOL/nqCTaW1/0Q7ohjFnoJ3edsGpGTDLggeWSr1JDjjDK UwdjIOR9KhHkIyLnMLvjCgRXQ8pXvlvnsrBmkjjJVD+0oKiAAOMef/JPor2ntK9KaTcy vynq34kH5XbR28t3mbx8VeqMcNoYYHUCGORdkT6Z/CSOdf0BGFGdE6b/R2VNJuI65fRX ddqnjqLJWI9Dlmbkh+E8qbKryJTyf6lr3jcXX3MvacwfkEHWcUuZIWQLIR7SD6zXtUp2 z9RA== X-Gm-Message-State: APjAAAUWJbHOPWFJx8HUhIuLNLTWUc/WfC2+TkZT5jzeI73zPzm/iVoI pZU/11dj5yPdgjcHUuL8xzAOroHlg4rpmObu6/aAzw== X-Google-Smtp-Source: APXvYqz59L5OLEfwl3/VjdaLZGzG6spgviLkLB7uh4DP85GSBAeJfdVd5KUAQtgAWiPldUviSB1UCip1xVOZP0aT1Wc= X-Received: by 2002:aca:4a53:: with SMTP id x80mr1786688oia.21.1553968813472; Sat, 30 Mar 2019 11:00:13 -0700 (PDT) MIME-Version: 1.0 References: <2E6CA4AD-AD65-4A20-9545-1C81ED8B8968@tony.li> In-Reply-To: From: Rob Shakir Date: Sat, 30 Mar 2019 11:00:02 -0700 Message-ID: To: "Acee Lindem (acee)" Cc: "tony.li@tony.li" , Christian Hopps , "lsr@ietf.org" Content-Type: multipart/alternative; boundary="0000000000001e8f0f0585538fc8" Archived-At: Subject: Re: [Lsr] When to augment LSR base YANG modules... X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Mar 2019 18:00:18 -0000 --0000000000001e8f0f0585538fc8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I think this is a generic challenge that has to be solved across all protocols -- and relies on a robust way to version and revise YANG modules in the IETF. In OpenConfig, as we're very lightweight for pushing a new revision, since we're just specifying new versions of modules, adding new features to an existing module is pretty trivial. They can be done as a minor revision if there's no backwards incompatible changes. It seems better, to me, to ensure that there is common logic for how one splits up modules, to make things actually usable for developers trying to consume them, rather than needing to understand when and where in the IETF a feature was developed. That being said -- this means one should probably expect each LSR base module to be revised with most new LSR RFCs. With the current agility of the review and publication process -- I'm not sure that is realistic either= . r. On Sat, 30 Mar 2019 at 09:15, Acee Lindem (acee) wrote: > Speaking as WG member: > > For many of the new LSR WG documents, we are already included both OSPF > and IS-IS encodings in a single document. Now, we have agreed that > documents requiring simple BGP-LS changes will also include the BGP-LS > encoding. Given this, I don't want to add another requirement for > publication of a WG document. This would also add additional reviews to t= he > document. You've all heard the expression "divide and conquer", while let > me introduce the corollary, "consolidate and stagnate". > > Additionally, I agree with Yingzhen's comment that it is not clear that w= e > want a separate YANG module for every OSPF/IS-IS feature. > > Thanks, > Acee > > =EF=BB=BFOn 3/29/19, 4:33 AM, "Lsr on behalf of tony.li@tony.li" < > lsr-bounces@ietf.org on behalf of tony.li@tony.li> wrote: > > > Chris, > > One concern is simply one of scale: doing this will increase the size > of the document. At what point do things become sufficiently awkward tha= t > we want to have a separate, concurrent document. > > In other words, if the requirement is for concurrent delivery, is > co-location really a requirement? > > Regards, > Tony > > > > On Mar 29, 2019, at 9:17 AM, Christian Hopps > wrote: > > > > > > The base YANG modules for IS-IS and OSPF both include operational > state to describe TLV data. During the discussion about OSPFv3's version = of > this data, I brought up the issue of when and how the base modules should > be augmented to add new TLV types to the model, suggesting it be done > inline and with the RFC that adds the new feature/functionality to the > protocol. > > > > I'll go farther here and say this should apply to all the YANG > required for management of the new feature, and it should all be added > inline with the feature (i.e., in the same draft). In other words new > features/functionality should include the YANG augment required to manage > said features/functionality. > > > > This has been suggested/tried previously with SNMP with varying > (low) levels of success. The difference here is 1) YANG additions (a new > module perhaps just augmenting the base) is easy, whereas SNMP wasn't. > Additionally, operators weren't using SNMP to fully manage functionality > (e.g., not doing configuration) so a requirement for extra work was harde= r > to justify. Operators *do* want to fully manage their networks/servers wi= th > YANG though. > > > > The argument against this during the meeting was that it would > create many small modules. I don't find this compelling (i.e., "so"? :) > > > > Assume I'm an operator -- the actual consumer of this management > stuff: > > > > - If I'm going to use this new feature X, I need to be able to > manage it. So I need it YANG for it. Not only do I need any new TLV data = in > the operational state, but I need the configuration and any other > operational state right along with it. Otherwise each vendor has to add n= ew > YANG to their vendor modules, or the feature is useless to me. I can't us= e > something if I can't turn it on. > > > > - I don't care about having many smaller modules that augment the > base module -- at all. Quite the opposite actually, when new functionalit= y > is accompanied by it's own module it provides me a simple way to see if > that functionality is present as the module will be present in the YANG > capabilities announced by the device. > > > > I'd be interested in hearing reasons we (as a WG) shouldn't just > expect a YANG module (even if it's small) to be included with drafts that > add new functionality. > > > > Thanks, > > Chris. > > _______________________________________________ > > Lsr mailing list > > Lsr@ietf.org > > https://www.ietf.org/mailman/listinfo/lsr > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > --0000000000001e8f0f0585538fc8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think this is a generic challenge that has to be solved = across all protocols -- and relies on a robust way to version and revise YA= NG modules in the IETF.=C2=A0

In OpenConfig, as we'r= e very lightweight for pushing a new revision, since we're just specify= ing new versions of modules, adding new features to an existing module is p= retty trivial. They can be done as a minor revision if there's no backw= ards incompatible changes.=C2=A0 It seems better, to me, to ensure that the= re is common logic for how one splits up modules, to make things actually u= sable for developers trying to consume them, rather than needing to underst= and when and where in the IETF a feature was developed.

= That being said -- this means one should probably expect each LSR base modu= le to be revised with most new LSR RFCs. With the current agility of the re= view and publication process -- I'm not sure that is realistic either.<= /div>

r.

On Sat, 30 Mar 2019 at 09:15, Acee L= indem (acee) <acee@cisco.com> w= rote:
Speaking a= s WG member:

For many of the new LSR WG documents, we are already included both OSPF and= IS-IS encodings in a single document. Now, we have agreed that documents r= equiring simple BGP-LS changes will also include the BGP-LS encoding. Given= this, I don't want to add another requirement for publication of a WG = document. This would also add additional reviews to the document. You'v= e all heard the expression "divide and conquer", while let me int= roduce the corollary, "consolidate and stagnate".

Additionally, I agree with Yingzhen's comment that it is not clear that= we want a separate YANG module for every OSPF/IS-IS feature.

Thanks,
Acee

=EF=BB=BFOn 3/29/19, 4:33 AM, "Lsr on behalf of tony.li@tony.li" <lsr-bounces@ietf.org on beh= alf of tony.li@tony.li= > wrote:


=C2=A0 =C2=A0 Chris,

=C2=A0 =C2=A0 One concern is simply one of scale: doing this will increase = the size of the document.=C2=A0 At what point do things become sufficiently= awkward that we want to have a separate, concurrent document.

=C2=A0 =C2=A0 In other words, if the requirement is for concurrent delivery= , is co-location really a requirement?

=C2=A0 =C2=A0 Regards,
=C2=A0 =C2=A0 Tony


=C2=A0 =C2=A0 > On Mar 29, 2019, at 9:17 AM, Christian Hopps <chopps@chopps.org> w= rote:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > The base YANG modules for IS-IS and OSPF both include op= erational state to describe TLV data. During the discussion about OSPFv3= 9;s version of this data, I brought up the issue of when and how the base m= odules should be augmented to add new TLV types to the model, suggesting it= be done inline and with the RFC that adds the new feature/functionality to= the protocol.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > I'll go farther here and say this should apply to al= l the YANG required for management of the new feature, and it should all be= added inline with the feature (i.e., in the same draft). In other words ne= w features/functionality should include the YANG augment required to manage= said features/functionality.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > This has been suggested/tried previously with SNMP with = varying (low) levels of success. The difference here is 1) YANG additions (= a new module perhaps just augmenting the base) is easy, whereas SNMP wasn&#= 39;t. Additionally, operators weren't using SNMP to fully manage functi= onality (e.g., not doing configuration) so a requirement for extra work was= harder to justify. Operators *do* want to fully manage their networks/serv= ers with YANG though.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > The argument against this during the meeting was that it= would create many small modules. I don't find this compelling (i.e., &= quot;so"? :)
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Assume I'm an operator -- the actual consumer of thi= s management stuff:
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > - If I'm going to use this new feature X, I need to = be able to manage it. So I need it YANG for it. Not only do I need any new = TLV data in the operational state, but I need the configuration and any oth= er operational state right along with it. Otherwise each vendor has to add = new YANG to their vendor modules, or the feature is useless to me. I can= 9;t use something if I can't turn it on.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > - I don't care about having many smaller modules tha= t augment the base module -- at all. Quite the opposite actually, when new = functionality is accompanied by it's own module it provides me a simple= way to see if that functionality is present as the module will be present = in the YANG capabilities announced by the device.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > I'd be interested in hearing reasons we (as a WG) sh= ouldn't just expect a YANG module (even if it's small) to be includ= ed with drafts that add new functionality.
=C2=A0 =C2=A0 >
=C2=A0 =C2=A0 > Thanks,
=C2=A0 =C2=A0 > Chris.
=C2=A0 =C2=A0 > _______________________________________________
=C2=A0 =C2=A0 > Lsr mailing list
=C2=A0 =C2=A0 > Lsr@ie= tf.org
=C2=A0 =C2=A0 > https://www.ietf.org/mailman/listinfo/ls= r

=C2=A0 =C2=A0 _______________________________________________
=C2=A0 =C2=A0 Lsr mailing list
=C2=A0 =C2=A0 Lsr@ietf.or= g
=C2=A0 =C2=A0 https://www.ietf.org/mailman/listinfo/lsr=


_______________________________________________
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr
--0000000000001e8f0f0585538fc8-- From nobody Sat Mar 30 23:33:12 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE161200B6 for ; Sat, 30 Mar 2019 23:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 2UaGSKW6IRXs for ; Sat, 30 Mar 2019 23:33:08 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 43EBA12006A for ; Sat, 30 Mar 2019 23:33:08 -0700 (PDT) Received: from tops.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 5929D604DC; Sun, 31 Mar 2019 02:33:07 -0400 (EDT) References: <2E6CA4AD-AD65-4A20-9545-1C81ED8B8968@tony.li> User-agent: mu4e 1.1.0; emacs 26.1 From: Christian Hopps To: "Acee Lindem \(acee\)" Cc: "tony.li\@tony.li" , Christian Hopps , "lsr\@ietf.org" In-reply-to: Date: Sun, 31 Mar 2019 02:33:06 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [Lsr] When to augment LSR base YANG modules... X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2019 06:33:10 -0000 --=-=-= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Acee Lindem (acee) writes: > Speaking as WG member: > > For many of the new LSR WG documents, we are already included both OSPF a= nd IS-IS encodings in a single document. Now, we have agreed that documents= requiring simple BGP-LS changes will also include the BGP-LS encoding. Giv= en this, I don't want to add another requirement for publication of a WG do= cument. This would also add additional reviews to the document. You've all = heard the expression "divide and conquer", while let me introduce the corol= lary, "consolidate and stagnate". If I had to choose between being able to use a feature (management) and sup= porting BGP-LS inline, I guess I choose management. I don't think this need= s to be a one-or-the-other choice though. Please note that this isn't like SNMP, and it's not like creating a base-mo= dule that will require lots of revisions and text. Adding a YANG section sh= ouldn't add huge swaths of text, rather a small auto-generated tree diagram= (for quick perusal) and the small module definition that augments the base= module should be all that's needed. The functionality is being defined in = the same document so there's no need to repeat it for the management sectio= n. YANG doctor reviews can happen in parallel with other reviews, and this has= not been something that holds documents up in my experience at all. The ov= erall document process *does* hold things up so having 2 documents instead = of 1 actually creates more opportunity for (superfluous) delay. I think it's worth trying this out to gain some experience and data; we don= 't have to create a requirement. Indeed, I think that if the management of the new functionality is sufficie= ntly complex that it requires it's own non-trivial amount of work to get ri= ght, I think it's reasonable to do this in a second parallel document too. > Additionally, I agree with Yingzhen's comment that it is not clear that w= e want a separate YANG module for every OSPF/IS-IS feature. Why? If you batch things together you then have to add a bunch of conditional "f= eatures" that the client has to check anyway. These features are reported t= hrough capability entries. IOW, they look just like small modules except no= w you have 2 entries instead of one (the parent module capability and the f= eature capability). There's no reduction in complexity by batching, it actu= ally makes things more complex. Thanks, Chris. > > Thanks, > Acee > > =EF=BB=BFOn 3/29/19, 4:33 AM, "Lsr on behalf of tony.li@tony.li" wrote: > > > Chris, > > One concern is simply one of scale: doing this will increase the size= of the document. At what point do things become sufficiently awkward that= we want to have a separate, concurrent document. > > In other words, if the requirement is for concurrent delivery, is co-= location really a requirement? > > Regards, > Tony > > > > On Mar 29, 2019, at 9:17 AM, Christian Hopps wr= ote: > > > > > > The base YANG modules for IS-IS and OSPF both include operational s= tate to describe TLV data. During the discussion about OSPFv3's version of = this data, I brought up the issue of when and how the base modules should b= e augmented to add new TLV types to the model, suggesting it be done inline= and with the RFC that adds the new feature/functionality to the protocol. > > > > I'll go farther here and say this should apply to all the YANG requ= ired for management of the new feature, and it should all be added inline w= ith the feature (i.e., in the same draft). In other words new features/func= tionality should include the YANG augment required to manage said features/= functionality. > > > > This has been suggested/tried previously with SNMP with varying (lo= w) levels of success. The difference here is 1) YANG additions (a new modul= e perhaps just augmenting the base) is easy, whereas SNMP wasn't. Additiona= lly, operators weren't using SNMP to fully manage functionality (e.g., not = doing configuration) so a requirement for extra work was harder to justify.= Operators *do* want to fully manage their networks/servers with YANG thoug= h. > > > > The argument against this during the meeting was that it would crea= te many small modules. I don't find this compelling (i.e., "so"? :) > > > > Assume I'm an operator -- the actual consumer of this management st= uff: > > > > - If I'm going to use this new feature X, I need to be able to mana= ge it. So I need it YANG for it. Not only do I need any new TLV data in the= operational state, but I need the configuration and any other operational = state right along with it. Otherwise each vendor has to add new YANG to the= ir vendor modules, or the feature is useless to me. I can't use something i= f I can't turn it on. > > > > - I don't care about having many smaller modules that augment the b= ase module -- at all. Quite the opposite actually, when new functionality i= s accompanied by it's own module it provides me a simple way to see if that= functionality is present as the module will be present in the YANG capabil= ities announced by the device. > > > > I'd be interested in hearing reasons we (as a WG) shouldn't just ex= pect a YANG module (even if it's small) to be included with drafts that add= new functionality. > > > > Thanks, > > Chris. > > _______________________________________________ > > Lsr mailing list > > Lsr@ietf.org > > https://www.ietf.org/mailman/listinfo/lsr > > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAlygXyIACgkQLh2DDte4 MCXEsw//WXpbFb4pBXg/vlxNSHJz6XYsviW5qK9Qa/n+KBYXCe6nECwxPA4bNONJ Z/iORZhQ8dnA0c52pjE6TYvxxoLdZnMJ/ApQlNINLFwWfmquA8oa8LOMy9Z9MUH8 mZpuiKrBPMV3oqR0l1V99o4ktlIsQq9bCBlkdRPWKCduaYUgmoMLDg0tFsn+dBjM SWGqfEKzIKixdvu15d58a3W7cb/mo5iGn3GW3H/pRNaPegu+nga3tgcYxWPWhYkG nVvUn9p/xJlsses0f8tDySKJO9+dHXK3U8J3db9A74xvWOKCfdwLubkZVoi+8WgV nuU54EhCZ1xkm6t0v+I1LpQSZOrTp1wT+o/X/P7npPpnqA/0Z66+cacw2W0a5Npx RD7tgY1e+3WD8jo0fx0yVFd0JM7X0j/gBJjKNecZO0jVXykOwslkSu0/XYk0aAii DfDm3/RUkkSPnyCVg9vpcw/m84dVqZXSkDEeX1BoqDbFjLanY1rY/Jv8FZ0gE3Ta /b/x6UFGQpTPfdcdiFyrfiVKlBggR7asKXC4lSwNupW8zPYK8e86z8fakZfuwrNA Y992JhsmGyn2RDw7Yi8Bj4xFMQuGY2tjquDMnAZlRpFto29q4xZOvLMSjlJy51g5 kSO0/p13gpmoLIzHAxZtKY2l/5MUld0gUaQP5NFUwaN4muEhTo8= =ymga -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Mar 31 00:07:38 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86E1A120179 for ; Sun, 31 Mar 2019 00:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se 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 MK4Idqm13CR7 for ; Sun, 31 Mar 2019 00:07:35 -0700 (PDT) Received: from uplift.swm.pp.se (swm.pp.se [212.247.200.143]) (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 59F941200B6 for ; Sun, 31 Mar 2019 00:07:35 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 28BD0B1; Sun, 31 Mar 2019 09:07:32 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1554016052; bh=xg2Q1cQr/+ZlTnG2nVUaTiEbhA4uhfesDYlyTirg+qg=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=B6XZy3cpDerebLq83crwgRdzey9Li8GE5O9lNCg8IgXfFAg3u48I7PL4SDoHB/Utd 6DKcfkjj5BFI1iiQVPU6JXmGOVqQ7lUHny+r5hTzCiUr75PmlhOq6QI1p9fdvsvoqG vLXPIT6ojC5iuAty3p+2YeSamkoa9MUzStw+imBg= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 2685AB0; Sun, 31 Mar 2019 09:07:32 +0200 (CEST) Date: Sun, 31 Mar 2019 09:07:32 +0200 (CEST) From: Mikael Abrahamsson To: "Acee Lindem (acee)" cc: "lsr@ietf.org" In-Reply-To: Message-ID: References: <2E6CA4AD-AD65-4A20-9545-1C81ED8B8968@tony.li> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Lsr] When to augment LSR base YANG modules... X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2019 07:07:37 -0000 On Sat, 30 Mar 2019, Acee Lindem (acee) wrote: > Additionally, I agree with Yingzhen's comment that it is not clear that > we want a separate YANG module for every OSPF/IS-IS feature. As an operator, I expect to manage my routers using YANG modules. Thus, every feature that is introduced that would provide requirement for management and/or provide operational data needs to have an YANG module come with it, otherwise this new feature isn't useful. I don't want YANG to be second class citizen compared to CLI the way SNMP has been. I also want to avoid having vendor-specific YANG modules if possible. Thus it makes sense to require YANG module with every new work. If this is in the same document or an accompanying document is not of importance to me, as long as it gets the YANG module shows up in roughly the same timeframe as the feature. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Sun Mar 31 00:09:34 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87DAA120282 for ; Sun, 31 Mar 2019 00:09:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se 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 O6DUnJ_dm-GY for ; Sun, 31 Mar 2019 00:09:32 -0700 (PDT) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (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 17B2212017A for ; Sun, 31 Mar 2019 00:09:32 -0700 (PDT) Received: by uplift.swm.pp.se (Postfix, from userid 501) id CE7D9B1; Sun, 31 Mar 2019 09:09:29 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1554016169; bh=WKkgqgPl5MYLwVBDjLaUJwnHnehLq4RNgINxygFzmN0=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=moVPa51qNhKsCmgR11JGyQ05h+c1dcVwHUpYalxIVgkgM8V4KuFpkQ/EGpLKJjnD7 fzEQMqctJ+/GhZuaNQgckASdtLUKi2lQmvOJwg1m39gASmvpI7UCT0lIqRDibGONbx W6g5KAUyoCHx+byx8kk7WuDdbJWI2N4aZEc0C050= Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id CC9C9B0; Sun, 31 Mar 2019 09:09:29 +0200 (CEST) Date: Sun, 31 Mar 2019 09:09:29 +0200 (CEST) From: Mikael Abrahamsson To: Rob Shakir cc: "lsr@ietf.org" In-Reply-To: Message-ID: References: <2E6CA4AD-AD65-4A20-9545-1C81ED8B8968@tony.li> User-Agent: Alpine 2.20 (DEB 67 2015-01-07) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [Lsr] When to augment LSR base YANG modules... X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2019 07:09:33 -0000 On Sat, 30 Mar 2019, Rob Shakir wrote: > That being said -- this means one should probably expect each LSR base > module to be revised with most new LSR RFCs. With the current agility of > the review and publication process -- I'm not sure that is realistic > either.. I have discussed this with Benoit before and I've voiced my opinion that the RFC process of handling YANG modules is very slow and cumbersome and doesn't seem to yield desired results. I think the IETF needs a different process to handle YANG modules that is more agile and speedy. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Sun Mar 31 05:53:57 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAB1812014C for ; Sun, 31 Mar 2019 05:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 QGHqSVJtw69p for ; Sun, 31 Mar 2019 05:53:54 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 668FA12012B for ; Sun, 31 Mar 2019 05:53:54 -0700 (PDT) Received: from tops.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 7FF17604DC; Sun, 31 Mar 2019 08:53:53 -0400 (EDT) References: <2E6CA4AD-AD65-4A20-9545-1C81ED8B8968@tony.li> User-agent: mu4e 1.1.0; emacs 26.1 From: Christian Hopps To: "Acee Lindem \(acee\)" Cc: "tony.li\@tony.li" , "lsr\@ietf.org" In-reply-to: Date: Sun, 31 Mar 2019 08:53:52 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" Archived-At: Subject: Re: [Lsr] When to augment LSR base YANG modules... X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2019 12:53:56 -0000 --=-=-= Content-Type: text/plain; format=flowed So to have something to look at while we discuss this I wrote a bare-bones module document for IS-IS reverse metrics: https://tools.ietf.org/html/draft-hopps-lsr-yang-isis-reverse-metric-00 If you look at the meat of that document and then imagine including it as an appendix or whatever with the functional IS-IS reverse metric document (https://tools.ietf.org/html/rfc8500) it doesn't seem that onerous of an addition. And it makes things very nice for the actual users/operators. Overall publishing time should improve b/c we have 1 document to shepherd through the IETF process instead of 2. And, again, if the YANG module is not straight-forward then having separate documents makes sense to me as well. I think we should give it a try with some small upcoming LSR draft -- we can always rip out the management section if it's causing issues. Thanks, Chris. --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAlyguGAACgkQLh2DDte4 MCW/8g//dYoh5VzOy1ciUa9U7WO/ylijMwhSSA4tCxy5GtTt5HIMnCG5mmJJeOpv joh9UeyRgqYVeLmC4V9FmXCj/FXWLJnUnaKNUwJimYvH6gxCqI+1I4uy+YrN9hRv Y7wrXFc1Vfc54E4bJAb5ihA9x6c9PkhwYDf0v/311PBGZWcdbvnAe3sremj0ACTE WBTEo0ya1Jou4mf8vY/IFDP6uaLlOJwmoDr8WfyXjfLEhQk9PopbpObxSNfV/Vi6 C4421iDHMZvG9W9WPMhGUzzi9NQfSVTkF496ftaMyJMgPC/lF+2o0mzLgT+TY4Of vZF5uBWmbShFqrOjAvnqQWkq0VWp9MXEznEtSEdAb/mbc1MhL7QBviPqan9jbh5e mf5jwyCTzUd1eUgdif8R1dSWDgeO3hmr33VQYponyw4C2thesHQrhmOaaoHU5IOi 8jY4W6tcpir3Jp4ztV4grGmPF1vOB8fNVMU1Oul5XjbDaSv8ghLmd7+F5TaZWAh6 6sz+9QZtQfarlJRuHyTx1ynHNOJLGG+c8zVcwPkmYuOhqf2iTLc7nYmVgAPsg+n6 OQIa992fipXJiP63jXs7/CtOfu6/A0Y+pf14ose5hQB6wSssCDtWQjA/5TH/e2/S K4sJtHe1/+gZCVswwjg3VAZjD457I72kRvobglhUCy5dy2Et10o= =RBtJ -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Mar 31 07:14:35 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 729081200B6 for ; Sun, 31 Mar 2019 07:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no 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 fXQ2tVx6dAAN for ; Sun, 31 Mar 2019 07:14:32 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (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 720A812017E for ; Sun, 31 Mar 2019 07:14:32 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.176.248.72; From: "Susan Hares" To: "'Rob Shakir'" , "'Acee Lindem \(acee\)'" Cc: , , "'Christian Hopps'" References: <2E6CA4AD-AD65-4A20-9545-1C81ED8B8968@tony.li> In-Reply-To: Date: Sun, 31 Mar 2019 10:14:23 -0400 Message-ID: <080001d4e7cc$0b434690$21c9d3b0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0801_01D4E7AA.8433A260" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGoH8+nve3qHRQxQ6VhC8ww+MXAdQFDaKl5AY1EoIQBjzlv9KZcVVrg Content-Language: en-us X-Antivirus: AVG (VPS 190331-2, 03/31/2019), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Lsr] When to augment LSR base YANG modules... X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2019 14:14:35 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0801_01D4E7AA.8433A260 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Rob and Acee:=20 =20 I agree that with Rob that it is a generic problem that you must have a = robust way to version and revise the Yang models. This is true for = configuration, operational data, and dynamic data stores. The netmod = modeling is focusing on configuration at this time. =20 =20 It is critical to determine how the base models yang models prepare for = augmentations. OSPF, ISIS, BGP, FIB/RIB, and policy are key models. = Since our protocols are augmented based on capabilities, augmentation = based on the same capabilities for models makes the most sense. We can = review info/data, and code functionality based on the key senses.=20 =20 If we have good versioning of the base model, can revise both the data = model and the capability independently. If we utilize the grouping of = data models based on the versioning, automatic deployment of this work = can occur.=20 =20 Acee and Chris has been actively participating on the versioning = discussion in netmod=E2=80=99s work on versioning. I=E2=80=99m sure = they can report if they feel the support his there for this type of = version.=20 =20 BGP and rtgwg can integrate this type of version prior to the upcoming = WG LC.=20 =20 Sue =20 =20 =20 From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Rob Shakir Sent: Saturday, March 30, 2019 2:00 PM To: Acee Lindem (acee) Cc: lsr@ietf.org; tony.li@tony.li; Christian Hopps Subject: Re: [Lsr] When to augment LSR base YANG modules... =20 I think this is a generic challenge that has to be solved across all = protocols -- and relies on a robust way to version and revise YANG = modules in the IETF.=20 =20 In OpenConfig, as we're very lightweight for pushing a new revision, = since we're just specifying new versions of modules, adding new features = to an existing module is pretty trivial. They can be done as a minor = revision if there's no backwards incompatible changes. It seems better, = to me, to ensure that there is common logic for how one splits up = modules, to make things actually usable for developers trying to consume = them, rather than needing to understand when and where in the IETF a = feature was developed. =20 That being said -- this means one should probably expect each LSR base = module to be revised with most new LSR RFCs. With the current agility of = the review and publication process -- I'm not sure that is realistic = either. =20 r. =20 On Sat, 30 Mar 2019 at 09:15, Acee Lindem (acee) wrote: Speaking as WG member: For many of the new LSR WG documents, we are already included both OSPF = and IS-IS encodings in a single document. Now, we have agreed that = documents requiring simple BGP-LS changes will also include the BGP-LS = encoding. Given this, I don't want to add another requirement for = publication of a WG document. This would also add additional reviews to = the document. You've all heard the expression "divide and conquer", = while let me introduce the corollary, "consolidate and stagnate".=20 Additionally, I agree with Yingzhen's comment that it is not clear that = we want a separate YANG module for every OSPF/IS-IS feature.=20 Thanks, Acee =EF=BB=BFOn 3/29/19, 4:33 AM, "Lsr on behalf of tony.li@tony.li = " wrote: Chris, One concern is simply one of scale: doing this will increase the = size of the document. At what point do things become sufficiently = awkward that we want to have a separate, concurrent document. In other words, if the requirement is for concurrent delivery, is = co-location really a requirement? Regards, Tony > On Mar 29, 2019, at 9:17 AM, Christian Hopps = wrote: >=20 >=20 > The base YANG modules for IS-IS and OSPF both include operational = state to describe TLV data. During the discussion about OSPFv3's version = of this data, I brought up the issue of when and how the base modules = should be augmented to add new TLV types to the model, suggesting it be = done inline and with the RFC that adds the new feature/functionality to = the protocol. >=20 > I'll go farther here and say this should apply to all the YANG = required for management of the new feature, and it should all be added = inline with the feature (i.e., in the same draft). In other words new = features/functionality should include the YANG augment required to = manage said features/functionality. >=20 > This has been suggested/tried previously with SNMP with varying = (low) levels of success. The difference here is 1) YANG additions (a new = module perhaps just augmenting the base) is easy, whereas SNMP wasn't. = Additionally, operators weren't using SNMP to fully manage functionality = (e.g., not doing configuration) so a requirement for extra work was = harder to justify. Operators *do* want to fully manage their = networks/servers with YANG though. >=20 > The argument against this during the meeting was that it would = create many small modules. I don't find this compelling (i.e., "so"? :) >=20 > Assume I'm an operator -- the actual consumer of this management = stuff: >=20 > - If I'm going to use this new feature X, I need to be able to = manage it. So I need it YANG for it. Not only do I need any new TLV data = in the operational state, but I need the configuration and any other = operational state right along with it. Otherwise each vendor has to add = new YANG to their vendor modules, or the feature is useless to me. I = can't use something if I can't turn it on. >=20 > - I don't care about having many smaller modules that augment the = base module -- at all. Quite the opposite actually, when new = functionality is accompanied by it's own module it provides me a simple = way to see if that functionality is present as the module will be = present in the YANG capabilities announced by the device. >=20 > I'd be interested in hearing reasons we (as a WG) shouldn't just = expect a YANG module (even if it's small) to be included with drafts = that add new functionality. >=20 > Thanks, > Chris. > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ------=_NextPart_000_0801_01D4E7AA.8433A260 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Rob and Acee:

 

I agree that with Rob that it is a generic problem that you must have = a robust way to version and revise the Yang models.=C2=A0 =C2=A0This is = true for configuration, operational data, and dynamic data = stores.=C2=A0=C2=A0 The netmod modeling is focusing on configuration at = this time.=C2=A0 =C2=A0

 

It is critical to determine how the base models yang models prepare = for augmentations.=C2=A0 OSPF, ISIS, BGP, FIB/RIB, and policy are key = models. =C2=A0=C2=A0Since our protocols are augmented based on = capabilities, augmentation based on the same capabilities for models = makes the most sense. =C2=A0=C2=A0We can review info/data, and code = functionality based on the key senses.

 

If we have good versioning of the base model, can revise both the = data model and the capability independently.=C2=A0=C2=A0 If we utilize = the grouping of data models based on the versioning, automatic = deployment of this work can occur.

 

Acee and Chris has been actively participating on the versioning = discussion in netmod=E2=80=99s work on versioning.=C2=A0 = =C2=A0I=E2=80=99m sure they can report if they feel the support his = there for this type of version.

 

BGP and rtgwg can integrate this type of version prior to the = upcoming WG LC.

 

Sue =C2=A0

=C2=A0

 

From:= = Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Rob = Shakir
Sent: Saturday, March 30, 2019 2:00 PM
To: = Acee Lindem (acee)
Cc: lsr@ietf.org; tony.li@tony.li; = Christian Hopps
Subject: Re: [Lsr] When to augment LSR base = YANG modules...

 

I think = this is a generic challenge that has to be solved across all protocols = -- and relies on a robust way to version and revise YANG modules in the = IETF. 

 

In OpenConfig, as we're very lightweight for pushing a = new revision, since we're just specifying new versions of modules, = adding new features to an existing module is pretty trivial. They can be = done as a minor revision if there's no backwards incompatible = changes.  It seems better, to me, to ensure that there is common = logic for how one splits up modules, to make things actually usable for = developers trying to consume them, rather than needing to understand = when and where in the IETF a feature was = developed.

 

That being said -- this means one should probably = expect each LSR base module to be revised with most new LSR RFCs. With = the current agility of the review and publication process -- I'm not = sure that is realistic either.

 

r.

 

On = Sat, 30 Mar 2019 at 09:15, Acee Lindem (acee) <acee@cisco.com> = wrote:

Speaking = as WG member:

For many of the new LSR WG documents, we are = already included both OSPF and IS-IS encodings in a single document. = Now, we have agreed that documents requiring simple BGP-LS changes will = also include the BGP-LS encoding. Given this, I don't want to add = another requirement for publication of a WG document. This would also = add additional reviews to the document. You've all heard the expression = "divide and conquer", while let me introduce the corollary, = "consolidate and stagnate".

Additionally, I agree with = Yingzhen's comment that it is not clear that we want a separate YANG = module for every OSPF/IS-IS feature. =

Thanks,
Acee

=EF=BB=BFOn 3/29/19, = 4:33 AM, "Lsr on behalf of tony.li@tony.li" <lsr-bounces@ietf.org on behalf of tony.li@tony.li> wrote:


  =   Chris,

    One concern is simply one of scale: = doing this will increase the size of the document.  At what point = do things become sufficiently awkward that we want to have a separate, = concurrent document.

    In other words, if the = requirement is for concurrent delivery, is co-location really a = requirement?

    Regards,
    = Tony


    > On Mar 29, 2019, at 9:17 AM, = Christian Hopps <chopps@chopps.org> wrote:
    > =
    >
    > The base YANG modules for = IS-IS and OSPF both include operational state to describe TLV data. = During the discussion about OSPFv3's version of this data, I brought up = the issue of when and how the base modules should be augmented to add = new TLV types to the model, suggesting it be done inline and with the = RFC that adds the new feature/functionality to the protocol.
  =   >
    > I'll go farther here and say this = should apply to all the YANG required for management of the new feature, = and it should all be added inline with the feature (i.e., in the same = draft). In other words new features/functionality should include the = YANG augment required to manage said features/functionality.
  =   >
    > This has been suggested/tried = previously with SNMP with varying (low) levels of success. The = difference here is 1) YANG additions (a new module perhaps just = augmenting the base) is easy, whereas SNMP wasn't. Additionally, = operators weren't using SNMP to fully manage functionality (e.g., not = doing configuration) so a requirement for extra work was harder to = justify. Operators *do* want to fully manage their networks/servers with = YANG though.
    >
    > The argument = against this during the meeting was that it would create many small = modules. I don't find this compelling (i.e., "so"? = :)
    >
    > Assume I'm an operator = -- the actual consumer of this management stuff:
    > =
    > - If I'm going to use this new feature X, I need = to be able to manage it. So I need it YANG for it. Not only do I need = any new TLV data in the operational state, but I need the configuration = and any other operational state right along with it. Otherwise each = vendor has to add new YANG to their vendor modules, or the feature is = useless to me. I can't use something if I can't turn it on.
  =   >
    > - I don't care about having many = smaller modules that augment the base module -- at all. Quite the = opposite actually, when new functionality is accompanied by it's own = module it provides me a simple way to see if that functionality is = present as the module will be present in the YANG capabilities announced = by the device.
    >
    > I'd be = interested in hearing reasons we (as a WG) shouldn't just expect a YANG = module (even if it's small) to be included with drafts that add new = functionality.
    >
    > = Thanks,
    > Chris.
    > = _______________________________________________
    > = Lsr mailing list
    > Lsr@ietf.org
    > https://www.ietf.org/mailman/listinfo/lsr

&n= bsp;   _______________________________________________
  =   Lsr mailing list
    Lsr@ietf.org
    https://www.ietf.org/mailman/listinfo/lsr

_______________________________________________
Lsr mailing = list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

------=_NextPart_000_0801_01D4E7AA.8433A260-- From nobody Sun Mar 31 07:21:53 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3604412018A for ; Sun, 31 Mar 2019 07:21:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no 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 Ujicb7bBzKqE for ; Sun, 31 Mar 2019 07:21:50 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (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 1C60B1200B6 for ; Sun, 31 Mar 2019 07:21:50 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=166.176.248.72; From: "Susan Hares" To: "'Rob Shakir'" , "'Acee Lindem \(acee\)'" Cc: , , "'Christian Hopps'" Date: Sun, 31 Mar 2019 10:21:40 -0400 Message-ID: <000c01d4e7cd$0f998be0$2ecca3a0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01D4E7AB.888B4740" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQGoH8+nve3qHRQxQ6VhC8ww+MXAdQFDaKl5AY1EoIQBjzlv9AEB4wBUplRLJMA= Content-Language: en-us X-Antivirus: AVG (VPS 190331-2, 03/31/2019), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Lsr] *** SPAM ***Re: When to augment LSR base YANG modules... X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2019 14:21:52 -0000 This is a multipart message in MIME format. ------=_NextPart_000_000D_01D4E7AB.888B4740 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Rob and Acee:=20 =20 My apologies- I missed a vital typo.=20 =20 --- We can review info/data, and code functionality based on the key = capability. =20 I=E2=80=99ve revised the text inline below. =20 =20 Sue=20 =20 From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Sunday, March 31, 2019 10:14 AM To: 'Rob Shakir'; 'Acee Lindem (acee)' Cc: lsr@ietf.org; tony.li@tony.li; 'Christian Hopps' Subject: *** SPAM ***Re: [Lsr] When to augment LSR base YANG modules... =20 Rob and Acee:=20 =20 I agree that with Rob that it is a generic problem that you must have a = robust way to version and revise the Yang models. This is true for = configuration, operational data, and dynamic data stores. The netmod = modeling is focusing on configuration at this time. =20 =20 It is critical to determine how the base models yang models prepare for = augmentations. OSPF, ISIS, BGP, FIB/RIB, and policy are key models. = Since our protocols are augmented based on capabilities, augmentation = based on the same capabilities for models makes the most sense. We can = review info/data, and code functionality based on the key capability.=20 =20 If we have good versioning of the base model, can revise both the data = model and the capability independently. If we utilize the grouping of = data models based on the versioning, automatic deployment of this work = can occur.=20 =20 Acee and Chris has been actively participating on the versioning = discussion in netmod=E2=80=99s work on versioning. I=E2=80=99m sure = they can report if they feel the support his there for this type of = version.=20 =20 BGP and rtgwg can integrate this type of version prior to the upcoming = WG LC.=20 =20 Sue =20 =20 =20 From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Rob Shakir Sent: Saturday, March 30, 2019 2:00 PM To: Acee Lindem (acee) Cc: lsr@ietf.org; tony.li@tony.li; Christian Hopps Subject: Re: [Lsr] When to augment LSR base YANG modules... =20 I think this is a generic challenge that has to be solved across all = protocols -- and relies on a robust way to version and revise YANG = modules in the IETF.=20 =20 In OpenConfig, as we're very lightweight for pushing a new revision, = since we're just specifying new versions of modules, adding new features = to an existing module is pretty trivial. They can be done as a minor = revision if there's no backwards incompatible changes. It seems better, = to me, to ensure that there is common logic for how one splits up = modules, to make things actually usable for developers trying to consume = them, rather than needing to understand when and where in the IETF a = feature was developed. =20 That being said -- this means one should probably expect each LSR base = module to be revised with most new LSR RFCs. With the current agility of = the review and publication process -- I'm not sure that is realistic = either. =20 r. =20 On Sat, 30 Mar 2019 at 09:15, Acee Lindem (acee) wrote: Speaking as WG member: For many of the new LSR WG documents, we are already included both OSPF = and IS-IS encodings in a single document. Now, we have agreed that = documents requiring simple BGP-LS changes will also include the BGP-LS = encoding. Given this, I don't want to add another requirement for = publication of a WG document. This would also add additional reviews to = the document. You've all heard the expression "divide and conquer", = while let me introduce the corollary, "consolidate and stagnate".=20 Additionally, I agree with Yingzhen's comment that it is not clear that = we want a separate YANG module for every OSPF/IS-IS feature.=20 Thanks, Acee =EF=BB=BFOn 3/29/19, 4:33 AM, "Lsr on behalf of tony.li@tony.li = " wrote: Chris, One concern is simply one of scale: doing this will increase the = size of the document. At what point do things become sufficiently = awkward that we want to have a separate, concurrent document. In other words, if the requirement is for concurrent delivery, is = co-location really a requirement? Regards, Tony > On Mar 29, 2019, at 9:17 AM, Christian Hopps = wrote: >=20 >=20 > The base YANG modules for IS-IS and OSPF both include operational = state to describe TLV data. During the discussion about OSPFv3's version = of this data, I brought up the issue of when and how the base modules = should be augmented to add new TLV types to the model, suggesting it be = done inline and with the RFC that adds the new feature/functionality to = the protocol. >=20 > I'll go farther here and say this should apply to all the YANG = required for management of the new feature, and it should all be added = inline with the feature (i.e., in the same draft). In other words new = features/functionality should include the YANG augment required to = manage said features/functionality. >=20 > This has been suggested/tried previously with SNMP with varying = (low) levels of success. The difference here is 1) YANG additions (a new = module perhaps just augmenting the base) is easy, whereas SNMP wasn't. = Additionally, operators weren't using SNMP to fully manage functionality = (e.g., not doing configuration) so a requirement for extra work was = harder to justify. Operators *do* want to fully manage their = networks/servers with YANG though. >=20 > The argument against this during the meeting was that it would = create many small modules. I don't find this compelling (i.e., "so"? :) >=20 > Assume I'm an operator -- the actual consumer of this management = stuff: >=20 > - If I'm going to use this new feature X, I need to be able to = manage it. So I need it YANG for it. Not only do I need any new TLV data = in the operational state, but I need the configuration and any other = operational state right along with it. Otherwise each vendor has to add = new YANG to their vendor modules, or the feature is useless to me. I = can't use something if I can't turn it on. >=20 > - I don't care about having many smaller modules that augment the = base module -- at all. Quite the opposite actually, when new = functionality is accompanied by it's own module it provides me a simple = way to see if that functionality is present as the module will be = present in the YANG capabilities announced by the device. >=20 > I'd be interested in hearing reasons we (as a WG) shouldn't just = expect a YANG module (even if it's small) to be included with drafts = that add new functionality. >=20 > Thanks, > Chris. > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr ------=_NextPart_000_000D_01D4E7AB.888B4740 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Rob and Acee:

 

My apologies- I missed a vital typo.

 

---  We can review info/data, and code functionality based on = the key capability.

 

I=E2=80=99ve revised the text inline below. = =C2=A0

 

Sue

 

From:= = Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Susan = Hares
Sent: Sunday, March 31, 2019 10:14 AM
To: 'Rob = Shakir'; 'Acee Lindem (acee)'
Cc: lsr@ietf.org; = tony.li@tony.li; 'Christian Hopps'
Subject: *** SPAM ***Re: = [Lsr] When to augment LSR base YANG = modules...

 

Rob and Acee:

 

I agree that with Rob that it is a generic problem that you must have = a robust way to version and revise the Yang models.   This is = true for configuration, operational data, and dynamic data = stores.   The netmod modeling is focusing on configuration at = this time.   

 

It is critical to determine how the base models yang models prepare = for augmentations.  OSPF, ISIS, BGP, FIB/RIB, and policy are key = models.   Since our protocols are augmented based on = capabilities, augmentation based on the same capabilities for models = makes the most sense.   We can review info/data, and code = functionality based on the key capability.

 

If we have good versioning of the base model, can revise both the = data model and the capability independently.   If we utilize = the grouping of data models based on the versioning, automatic = deployment of this work can occur.

 

Acee and Chris has been actively participating on the versioning = discussion in netmod=E2=80=99s work on versioning.  =  I=E2=80=99m sure they can report if they feel the support his = there for this type of version.

 

BGP and rtgwg can integrate this type of version prior to the = upcoming WG LC.

 

Sue  

 

 

From:= = Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Rob = Shakir
Sent: Saturday, March 30, 2019 2:00 PM
To: = Acee Lindem (acee)
Cc: lsr@ietf.org; tony.li@tony.li; = Christian Hopps
Subject: Re: [Lsr] When to augment LSR base = YANG modules...

 

I think = this is a generic challenge that has to be solved across all protocols = -- and relies on a robust way to version and revise YANG modules in the = IETF. 

 

In OpenConfig, as we're very lightweight for pushing a = new revision, since we're just specifying new versions of modules, = adding new features to an existing module is pretty trivial. They can be = done as a minor revision if there's no backwards incompatible = changes.  It seems better, to me, to ensure that there is common = logic for how one splits up modules, to make things actually usable for = developers trying to consume them, rather than needing to understand = when and where in the IETF a feature was = developed.

 

That being said -- this means one should probably = expect each LSR base module to be revised with most new LSR RFCs. With = the current agility of the review and publication process -- I'm not = sure that is realistic either.

 

r.

 

On = Sat, 30 Mar 2019 at 09:15, Acee Lindem (acee) <acee@cisco.com> = wrote:

Speaking as WG member:

For many of the = new LSR WG documents, we are already included both OSPF and IS-IS = encodings in a single document. Now, we have agreed that documents = requiring simple BGP-LS changes will also include the BGP-LS encoding. = Given this, I don't want to add another requirement for publication of a = WG document. This would also add additional reviews to the document. = You've all heard the expression "divide and conquer", while = let me introduce the corollary, "consolidate and stagnate". =

Additionally, I agree with Yingzhen's comment that it is not = clear that we want a separate YANG module for every OSPF/IS-IS feature. =

Thanks,
Acee

=EF=BB=BFOn 3/29/19, = 4:33 AM, "Lsr on behalf of tony.li@tony.li" <lsr-bounces@ietf.org on behalf of tony.li@tony.li> wrote:


  =   Chris,

    One concern is simply one of scale: = doing this will increase the size of the document.  At what point = do things become sufficiently awkward that we want to have a separate, = concurrent document.

    In other words, if the = requirement is for concurrent delivery, is co-location really a = requirement?

    Regards,
    = Tony


    > On Mar 29, 2019, at 9:17 AM, = Christian Hopps <chopps@chopps.org> wrote:
    > =
    >
    > The base YANG modules for = IS-IS and OSPF both include operational state to describe TLV data. = During the discussion about OSPFv3's version of this data, I brought up = the issue of when and how the base modules should be augmented to add = new TLV types to the model, suggesting it be done inline and with the = RFC that adds the new feature/functionality to the protocol.
  =   >
    > I'll go farther here and say this = should apply to all the YANG required for management of the new feature, = and it should all be added inline with the feature (i.e., in the same = draft). In other words new features/functionality should include the = YANG augment required to manage said features/functionality.
  =   >
    > This has been suggested/tried = previously with SNMP with varying (low) levels of success. The = difference here is 1) YANG additions (a new module perhaps just = augmenting the base) is easy, whereas SNMP wasn't. Additionally, = operators weren't using SNMP to fully manage functionality (e.g., not = doing configuration) so a requirement for extra work was harder to = justify. Operators *do* want to fully manage their networks/servers with = YANG though.
    >
    > The argument = against this during the meeting was that it would create many small = modules. I don't find this compelling (i.e., "so"? = :)
    >
    > Assume I'm an operator = -- the actual consumer of this management stuff:
    > =
    > - If I'm going to use this new feature X, I need = to be able to manage it. So I need it YANG for it. Not only do I need = any new TLV data in the operational state, but I need the configuration = and any other operational state right along with it. Otherwise each = vendor has to add new YANG to their vendor modules, or the feature is = useless to me. I can't use something if I can't turn it on.
  =   >
    > - I don't care about having many = smaller modules that augment the base module -- at all. Quite the = opposite actually, when new functionality is accompanied by it's own = module it provides me a simple way to see if that functionality is = present as the module will be present in the YANG capabilities announced = by the device.
    >
    > I'd be = interested in hearing reasons we (as a WG) shouldn't just expect a YANG = module (even if it's small) to be included with drafts that add new = functionality.
    >
    > = Thanks,
    > Chris.
    > = _______________________________________________
    > = Lsr mailing list
    > Lsr@ietf.org
    > https://www.ietf.org/mailman/listinfo/lsr

&n= bsp;   _______________________________________________
  =   Lsr mailing list
    Lsr@ietf.org
    https://www.ietf.org/mailman/listinfo/lsr

_______________________________________________
Lsr mailing = list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

------=_NextPart_000_000D_01D4E7AB.888B4740-- From nobody Sun Mar 31 10:31:40 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B52061201AD for ; Sun, 31 Mar 2019 10:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hhot-B9NtNMe for ; Sun, 31 Mar 2019 10:31:37 -0700 (PDT) Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD0841201AC for ; Sun, 31 Mar 2019 10:31:36 -0700 (PDT) Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id A3CB12127E86F09D7D3D for ; Sun, 31 Mar 2019 18:31:34 +0100 (IST) Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.408.0; Sun, 31 Mar 2019 18:31:34 +0100 Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.136]) by SJCEML701-CHM.china.huawei.com ([169.254.3.61]) with mapi id 14.03.0439.000; Sun, 31 Mar 2019 10:31:27 -0700 From: Yingzhen Qu To: Susan Hares , 'Rob Shakir' , "'Acee Lindem (acee)'" CC: "lsr@ietf.org" , "tony.li@tony.li" , 'Christian Hopps' Thread-Topic: [Lsr] When to augment LSR base YANG modules... Thread-Index: AQHU5gfhVwOv7QrRVka3sBCUMBCWt6YivO0AgAITuwCAAB1sAIABU0mA///BkQA= Date: Sun, 31 Mar 2019 17:31:26 +0000 Message-ID: <75095E67-2867-4466-B232-48E27DC47C9B@huawei.com> References: <2E6CA4AD-AD65-4A20-9545-1C81ED8B8968@tony.li> <080001d4e7cc$0b434690$21c9d3b0$@ndzh.com> In-Reply-To: <080001d4e7cc$0b434690$21c9d3b0$@ndzh.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.245.141] Content-Type: multipart/alternative; boundary="_000_75095E6728674466B23248E27DC47C9Bhuaweicom_" MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: Subject: Re: [Lsr] When to augment LSR base YANG modules... X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2019 17:31:40 -0000 --_000_75095E6728674466B23248E27DC47C9Bhuaweicom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlcmUgYXJlIG1hbnkgc21hbGwgZmVhdHVyZSBkcmFmdHMgaW4gTFNSLCBmb3IgZXhhbXBsZTog aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1vc3BmLW9zcGZ2Mi1o Yml0LyAgaXQgb25seSBhZGRzIEgtYml0IHRvIHJvdXRlci1sc2EuDQoNCkZvciBzdXJlIHdlIHdh bnQgbW9kZWxzIHRvIGJlIG1vZHVsYXIsIGJ1dCBub3QgdG9vIG1hbnkgdGlueSBwaWVjZXMuIE1h eWJlIHdlIHNob3VsZCBjb21iaW5lIGEgZmV3IHNtYWxsIGZlYXR1cmVzIGxpa2UgSC1CaXQgaW50 byBvbmUgbW9kdWxlPw0KDQpUaGUgYm90dG9tIGxpbmUgaXMgd2UgbmVlZCB0byBrZWVwIFlBTkcg ZGVsaXZlcnkgbm90IGZhbGxpbmcgYmVoaW5kIHRvbyBtdWNoLg0KDQpUaGFua3MsDQpZaW5nemhl bg0KDQpGcm9tOiBMc3IgPGxzci1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2YgU3VzYW4g SGFyZXMgPHNoYXJlc0BuZHpoLmNvbT4NCkRhdGU6IFN1bmRheSwgTWFyY2ggMzEsIDIwMTkgYXQg NzoxNSBBTQ0KVG86ICdSb2IgU2hha2lyJyA8cmpzQHJvYi5zaD4sICInQWNlZSBMaW5kZW0gKGFj ZWUpJyIgPGFjZWVAY2lzY28uY29tPg0KQ2M6ICJsc3JAaWV0Zi5vcmciIDxsc3JAaWV0Zi5vcmc+ LCAidG9ueS5saUB0b255LmxpIiA8dG9ueS5saUB0b255LmxpPiwgJ0NocmlzdGlhbiBIb3Bwcycg PGNob3Bwc0BjaG9wcHMub3JnPg0KU3ViamVjdDogUmU6IFtMc3JdIFdoZW4gdG8gYXVnbWVudCBM U1IgYmFzZSBZQU5HIG1vZHVsZXMuLi4NCg0KUm9iIGFuZCBBY2VlOg0KDQpJIGFncmVlIHRoYXQg d2l0aCBSb2IgdGhhdCBpdCBpcyBhIGdlbmVyaWMgcHJvYmxlbSB0aGF0IHlvdSBtdXN0IGhhdmUg YSByb2J1c3Qgd2F5IHRvIHZlcnNpb24gYW5kIHJldmlzZSB0aGUgWWFuZyBtb2RlbHMuICAgVGhp cyBpcyB0cnVlIGZvciBjb25maWd1cmF0aW9uLCBvcGVyYXRpb25hbCBkYXRhLCBhbmQgZHluYW1p YyBkYXRhIHN0b3Jlcy4gICBUaGUgbmV0bW9kIG1vZGVsaW5nIGlzIGZvY3VzaW5nIG9uIGNvbmZp Z3VyYXRpb24gYXQgdGhpcyB0aW1lLg0KDQpJdCBpcyBjcml0aWNhbCB0byBkZXRlcm1pbmUgaG93 IHRoZSBiYXNlIG1vZGVscyB5YW5nIG1vZGVscyBwcmVwYXJlIGZvciBhdWdtZW50YXRpb25zLiAg T1NQRiwgSVNJUywgQkdQLCBGSUIvUklCLCBhbmQgcG9saWN5IGFyZSBrZXkgbW9kZWxzLiAgIFNp bmNlIG91ciBwcm90b2NvbHMgYXJlIGF1Z21lbnRlZCBiYXNlZCBvbiBjYXBhYmlsaXRpZXMsIGF1 Z21lbnRhdGlvbiBiYXNlZCBvbiB0aGUgc2FtZSBjYXBhYmlsaXRpZXMgZm9yIG1vZGVscyBtYWtl cyB0aGUgbW9zdCBzZW5zZS4gICBXZSBjYW4gcmV2aWV3IGluZm8vZGF0YSwgYW5kIGNvZGUgZnVu Y3Rpb25hbGl0eSBiYXNlZCBvbiB0aGUga2V5IHNlbnNlcy4NCg0KSWYgd2UgaGF2ZSBnb29kIHZl cnNpb25pbmcgb2YgdGhlIGJhc2UgbW9kZWwsIGNhbiByZXZpc2UgYm90aCB0aGUgZGF0YSBtb2Rl bCBhbmQgdGhlIGNhcGFiaWxpdHkgaW5kZXBlbmRlbnRseS4gICBJZiB3ZSB1dGlsaXplIHRoZSBn cm91cGluZyBvZiBkYXRhIG1vZGVscyBiYXNlZCBvbiB0aGUgdmVyc2lvbmluZywgYXV0b21hdGlj IGRlcGxveW1lbnQgb2YgdGhpcyB3b3JrIGNhbiBvY2N1ci4NCg0KQWNlZSBhbmQgQ2hyaXMgaGFz IGJlZW4gYWN0aXZlbHkgcGFydGljaXBhdGluZyBvbiB0aGUgdmVyc2lvbmluZyBkaXNjdXNzaW9u IGluIG5ldG1vZOKAmXMgd29yayBvbiB2ZXJzaW9uaW5nLiAgIEnigJltIHN1cmUgdGhleSBjYW4g cmVwb3J0IGlmIHRoZXkgZmVlbCB0aGUgc3VwcG9ydCBoaXMgdGhlcmUgZm9yIHRoaXMgdHlwZSBv ZiB2ZXJzaW9uLg0KDQpCR1AgYW5kIHJ0Z3dnIGNhbiBpbnRlZ3JhdGUgdGhpcyB0eXBlIG9mIHZl cnNpb24gcHJpb3IgdG8gdGhlIHVwY29taW5nIFdHIExDLg0KDQpTdWUNCg0KDQpGcm9tOiBMc3Ig W21haWx0bzpsc3ItYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFJvYiBTaGFraXINClNl bnQ6IFNhdHVyZGF5LCBNYXJjaCAzMCwgMjAxOSAyOjAwIFBNDQpUbzogQWNlZSBMaW5kZW0gKGFj ZWUpDQpDYzogbHNyQGlldGYub3JnOyB0b255LmxpQHRvbnkubGk7IENocmlzdGlhbiBIb3Bwcw0K U3ViamVjdDogUmU6IFtMc3JdIFdoZW4gdG8gYXVnbWVudCBMU1IgYmFzZSBZQU5HIG1vZHVsZXMu Li4NCg0KSSB0aGluayB0aGlzIGlzIGEgZ2VuZXJpYyBjaGFsbGVuZ2UgdGhhdCBoYXMgdG8gYmUg c29sdmVkIGFjcm9zcyBhbGwgcHJvdG9jb2xzIC0tIGFuZCByZWxpZXMgb24gYSByb2J1c3Qgd2F5 IHRvIHZlcnNpb24gYW5kIHJldmlzZSBZQU5HIG1vZHVsZXMgaW4gdGhlIElFVEYuDQoNCkluIE9w ZW5Db25maWcsIGFzIHdlJ3JlIHZlcnkgbGlnaHR3ZWlnaHQgZm9yIHB1c2hpbmcgYSBuZXcgcmV2 aXNpb24sIHNpbmNlIHdlJ3JlIGp1c3Qgc3BlY2lmeWluZyBuZXcgdmVyc2lvbnMgb2YgbW9kdWxl cywgYWRkaW5nIG5ldyBmZWF0dXJlcyB0byBhbiBleGlzdGluZyBtb2R1bGUgaXMgcHJldHR5IHRy aXZpYWwuIFRoZXkgY2FuIGJlIGRvbmUgYXMgYSBtaW5vciByZXZpc2lvbiBpZiB0aGVyZSdzIG5v IGJhY2t3YXJkcyBpbmNvbXBhdGlibGUgY2hhbmdlcy4gIEl0IHNlZW1zIGJldHRlciwgdG8gbWUs IHRvIGVuc3VyZSB0aGF0IHRoZXJlIGlzIGNvbW1vbiBsb2dpYyBmb3IgaG93IG9uZSBzcGxpdHMg dXAgbW9kdWxlcywgdG8gbWFrZSB0aGluZ3MgYWN0dWFsbHkgdXNhYmxlIGZvciBkZXZlbG9wZXJz IHRyeWluZyB0byBjb25zdW1lIHRoZW0sIHJhdGhlciB0aGFuIG5lZWRpbmcgdG8gdW5kZXJzdGFu ZCB3aGVuIGFuZCB3aGVyZSBpbiB0aGUgSUVURiBhIGZlYXR1cmUgd2FzIGRldmVsb3BlZC4NCg0K VGhhdCBiZWluZyBzYWlkIC0tIHRoaXMgbWVhbnMgb25lIHNob3VsZCBwcm9iYWJseSBleHBlY3Qg ZWFjaCBMU1IgYmFzZSBtb2R1bGUgdG8gYmUgcmV2aXNlZCB3aXRoIG1vc3QgbmV3IExTUiBSRkNz LiBXaXRoIHRoZSBjdXJyZW50IGFnaWxpdHkgb2YgdGhlIHJldmlldyBhbmQgcHVibGljYXRpb24g cHJvY2VzcyAtLSBJJ20gbm90IHN1cmUgdGhhdCBpcyByZWFsaXN0aWMgZWl0aGVyLg0KDQpyLg0K DQpPbiBTYXQsIDMwIE1hciAyMDE5IGF0IDA5OjE1LCBBY2VlIExpbmRlbSAoYWNlZSkgPGFjZWVA Y2lzY28uY29tPG1haWx0bzphY2VlQGNpc2NvLmNvbT4+IHdyb3RlOg0KU3BlYWtpbmcgYXMgV0cg bWVtYmVyOg0KDQpGb3IgbWFueSBvZiB0aGUgbmV3IExTUiBXRyBkb2N1bWVudHMsIHdlIGFyZSBh bHJlYWR5IGluY2x1ZGVkIGJvdGggT1NQRiBhbmQgSVMtSVMgZW5jb2RpbmdzIGluIGEgc2luZ2xl IGRvY3VtZW50LiBOb3csIHdlIGhhdmUgYWdyZWVkIHRoYXQgZG9jdW1lbnRzIHJlcXVpcmluZyBz aW1wbGUgQkdQLUxTIGNoYW5nZXMgd2lsbCBhbHNvIGluY2x1ZGUgdGhlIEJHUC1MUyBlbmNvZGlu Zy4gR2l2ZW4gdGhpcywgSSBkb24ndCB3YW50IHRvIGFkZCBhbm90aGVyIHJlcXVpcmVtZW50IGZv ciBwdWJsaWNhdGlvbiBvZiBhIFdHIGRvY3VtZW50LiBUaGlzIHdvdWxkIGFsc28gYWRkIGFkZGl0 aW9uYWwgcmV2aWV3cyB0byB0aGUgZG9jdW1lbnQuIFlvdSd2ZSBhbGwgaGVhcmQgdGhlIGV4cHJl c3Npb24gImRpdmlkZSBhbmQgY29ucXVlciIsIHdoaWxlIGxldCBtZSBpbnRyb2R1Y2UgdGhlIGNv cm9sbGFyeSwgImNvbnNvbGlkYXRlIGFuZCBzdGFnbmF0ZSIuDQoNCkFkZGl0aW9uYWxseSwgSSBh Z3JlZSB3aXRoIFlpbmd6aGVuJ3MgY29tbWVudCB0aGF0IGl0IGlzIG5vdCBjbGVhciB0aGF0IHdl IHdhbnQgYSBzZXBhcmF0ZSBZQU5HIG1vZHVsZSBmb3IgZXZlcnkgT1NQRi9JUy1JUyBmZWF0dXJl Lg0KDQpUaGFua3MsDQpBY2VlDQoNCk9uIDMvMjkvMTksIDQ6MzMgQU0sICJMc3Igb24gYmVoYWxm IG9mIHRvbnkubGlAdG9ueS5saTxtYWlsdG86dG9ueS4ubGlAdG9ueS5saT4iIDxsc3ItYm91bmNl c0BpZXRmLm9yZzxtYWlsdG86bHNyLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiB0b255 LmxpQHRvbnkubGk8bWFpbHRvOnRvbnkubGlAdG9ueS5saT4+IHdyb3RlOg0KDQoNCiAgICBDaHJp cywNCg0KICAgIE9uZSBjb25jZXJuIGlzIHNpbXBseSBvbmUgb2Ygc2NhbGU6IGRvaW5nIHRoaXMg d2lsbCBpbmNyZWFzZSB0aGUgc2l6ZSBvZiB0aGUgZG9jdW1lbnQuICBBdCB3aGF0IHBvaW50IGRv IHRoaW5ncyBiZWNvbWUgc3VmZmljaWVudGx5IGF3a3dhcmQgdGhhdCB3ZSB3YW50IHRvIGhhdmUg YSBzZXBhcmF0ZSwgY29uY3VycmVudCBkb2N1bWVudC4NCg0KICAgIEluIG90aGVyIHdvcmRzLCBp ZiB0aGUgcmVxdWlyZW1lbnQgaXMgZm9yIGNvbmN1cnJlbnQgZGVsaXZlcnksIGlzIGNvLWxvY2F0 aW9uIHJlYWxseSBhIHJlcXVpcmVtZW50Pw0KDQogICAgUmVnYXJkcywNCiAgICBUb255DQoNCg0K ICAgID4gT24gTWFyIDI5LCAyMDE5LCBhdCA5OjE3IEFNLCBDaHJpc3RpYW4gSG9wcHMgPGNob3Bw c0BjaG9wcHMub3JnPG1haWx0bzpjaG9wcHNAY2hvcHBzLm9yZz4+IHdyb3RlOg0KICAgID4NCiAg ICA+DQogICAgPiBUaGUgYmFzZSBZQU5HIG1vZHVsZXMgZm9yIElTLUlTIGFuZCBPU1BGIGJvdGgg aW5jbHVkZSBvcGVyYXRpb25hbCBzdGF0ZSB0byBkZXNjcmliZSBUTFYgZGF0YS4gRHVyaW5nIHRo ZSBkaXNjdXNzaW9uIGFib3V0IE9TUEZ2MydzIHZlcnNpb24gb2YgdGhpcyBkYXRhLCBJIGJyb3Vn aHQgdXAgdGhlIGlzc3VlIG9mIHdoZW4gYW5kIGhvdyB0aGUgYmFzZSBtb2R1bGVzIHNob3VsZCBi ZSBhdWdtZW50ZWQgdG8gYWRkIG5ldyBUTFYgdHlwZXMgdG8gdGhlIG1vZGVsLCBzdWdnZXN0aW5n IGl0IGJlIGRvbmUgaW5saW5lIGFuZCB3aXRoIHRoZSBSRkMgdGhhdCBhZGRzIHRoZSBuZXcgZmVh dHVyZS9mdW5jdGlvbmFsaXR5IHRvIHRoZSBwcm90b2NvbC4NCiAgICA+DQogICAgPiBJJ2xsIGdv IGZhcnRoZXIgaGVyZSBhbmQgc2F5IHRoaXMgc2hvdWxkIGFwcGx5IHRvIGFsbCB0aGUgWUFORyBy ZXF1aXJlZCBmb3IgbWFuYWdlbWVudCBvZiB0aGUgbmV3IGZlYXR1cmUsIGFuZCBpdCBzaG91bGQg YWxsIGJlIGFkZGVkIGlubGluZSB3aXRoIHRoZSBmZWF0dXJlIChpLmUuLCBpbiB0aGUgc2FtZSBk cmFmdCkuIEluIG90aGVyIHdvcmRzIG5ldyBmZWF0dXJlcy9mdW5jdGlvbmFsaXR5IHNob3VsZCBp bmNsdWRlIHRoZSBZQU5HIGF1Z21lbnQgcmVxdWlyZWQgdG8gbWFuYWdlIHNhaWQgZmVhdHVyZXMv ZnVuY3Rpb25hbGl0eS4NCiAgICA+DQogICAgPiBUaGlzIGhhcyBiZWVuIHN1Z2dlc3RlZC90cmll ZCBwcmV2aW91c2x5IHdpdGggU05NUCB3aXRoIHZhcnlpbmcgKGxvdykgbGV2ZWxzIG9mIHN1Y2Nl c3MuIFRoZSBkaWZmZXJlbmNlIGhlcmUgaXMgMSkgWUFORyBhZGRpdGlvbnMgKGEgbmV3IG1vZHVs ZSBwZXJoYXBzIGp1c3QgYXVnbWVudGluZyB0aGUgYmFzZSkgaXMgZWFzeSwgd2hlcmVhcyBTTk1Q IHdhc24ndC4gQWRkaXRpb25hbGx5LCBvcGVyYXRvcnMgd2VyZW4ndCB1c2luZyBTTk1QIHRvIGZ1 bGx5IG1hbmFnZSBmdW5jdGlvbmFsaXR5IChlLmcuLCBub3QgZG9pbmcgY29uZmlndXJhdGlvbikg c28gYSByZXF1aXJlbWVudCBmb3IgZXh0cmEgd29yayB3YXMgaGFyZGVyIHRvIGp1c3RpZnkuIE9w ZXJhdG9ycyAqZG8qIHdhbnQgdG8gZnVsbHkgbWFuYWdlIHRoZWlyIG5ldHdvcmtzL3NlcnZlcnMg d2l0aCBZQU5HIHRob3VnaC4NCiAgICA+DQogICAgPiBUaGUgYXJndW1lbnQgYWdhaW5zdCB0aGlz IGR1cmluZyB0aGUgbWVldGluZyB3YXMgdGhhdCBpdCB3b3VsZCBjcmVhdGUgbWFueSBzbWFsbCBt b2R1bGVzLiBJIGRvbid0IGZpbmQgdGhpcyBjb21wZWxsaW5nIChpLmUuLCAic28iPyA6KQ0KICAg ID4NCiAgICA+IEFzc3VtZSBJJ20gYW4gb3BlcmF0b3IgLS0gdGhlIGFjdHVhbCBjb25zdW1lciBv ZiB0aGlzIG1hbmFnZW1lbnQgc3R1ZmY6DQogICAgPg0KICAgID4gLSBJZiBJJ20gZ29pbmcgdG8g dXNlIHRoaXMgbmV3IGZlYXR1cmUgWCwgSSBuZWVkIHRvIGJlIGFibGUgdG8gbWFuYWdlIGl0LiBT byBJIG5lZWQgaXQgWUFORyBmb3IgaXQuIE5vdCBvbmx5IGRvIEkgbmVlZCBhbnkgbmV3IFRMViBk YXRhIGluIHRoZSBvcGVyYXRpb25hbCBzdGF0ZSwgYnV0IEkgbmVlZCB0aGUgY29uZmlndXJhdGlv biBhbmQgYW55IG90aGVyIG9wZXJhdGlvbmFsIHN0YXRlIHJpZ2h0IGFsb25nIHdpdGggaXQuIE90 aGVyd2lzZSBlYWNoIHZlbmRvciBoYXMgdG8gYWRkIG5ldyBZQU5HIHRvIHRoZWlyIHZlbmRvciBt b2R1bGVzLCBvciB0aGUgZmVhdHVyZSBpcyB1c2VsZXNzIHRvIG1lLiBJIGNhbid0IHVzZSBzb21l dGhpbmcgaWYgSSBjYW4ndCB0dXJuIGl0IG9uLg0KICAgID4NCiAgICA+IC0gSSBkb24ndCBjYXJl IGFib3V0IGhhdmluZyBtYW55IHNtYWxsZXIgbW9kdWxlcyB0aGF0IGF1Z21lbnQgdGhlIGJhc2Ug bW9kdWxlIC0tIGF0IGFsbC4gUXVpdGUgdGhlIG9wcG9zaXRlIGFjdHVhbGx5LCB3aGVuIG5ldyBm dW5jdGlvbmFsaXR5IGlzIGFjY29tcGFuaWVkIGJ5IGl0J3Mgb3duIG1vZHVsZSBpdCBwcm92aWRl cyBtZSBhIHNpbXBsZSB3YXkgdG8gc2VlIGlmIHRoYXQgZnVuY3Rpb25hbGl0eSBpcyBwcmVzZW50 IGFzIHRoZSBtb2R1bGUgd2lsbCBiZSBwcmVzZW50IGluIHRoZSBZQU5HIGNhcGFiaWxpdGllcyBh bm5vdW5jZWQgYnkgdGhlIGRldmljZS4NCiAgICA+DQogICAgPiBJJ2QgYmUgaW50ZXJlc3RlZCBp biBoZWFyaW5nIHJlYXNvbnMgd2UgKGFzIGEgV0cpIHNob3VsZG4ndCBqdXN0IGV4cGVjdCBhIFlB TkcgbW9kdWxlIChldmVuIGlmIGl0J3Mgc21hbGwpIHRvIGJlIGluY2x1ZGVkIHdpdGggZHJhZnRz IHRoYXQgYWRkIG5ldyBmdW5jdGlvbmFsaXR5Lg0KICAgID4NCiAgICA+IFRoYW5rcywNCiAgICA+ IENocmlzLg0KICAgID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCiAgICA+IExzciBtYWlsaW5nIGxpc3QNCiAgICA+IExzckBpZXRmLm9yZzxtYWlsdG86 THNyQGlldGYub3JnPg0KICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9sc3INCg0KICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQogICAgTHNyIG1haWxpbmcgbGlzdA0KICAgIExzckBpZXRmLm9yZzxtYWlsdG86THNyQGll dGYub3JnPg0KICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHNyDQoN Cg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkxzciBt YWlsaW5nIGxpc3QNCkxzckBpZXRmLm9yZzxtYWlsdG86THNyQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sc3INCg== --_000_75095E6728674466B23248E27DC47C9Bhuaweicom_ Content-Type: text/html; charset="utf-8" Content-ID: <29C71CDC85502B47AAC598DBCDABBE1D@huawei.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6RGVuZ1hpYW47DQoJcGFub3NlLTE6 MiAxIDYgMCAzIDEgMSAxIDEgMTt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7 DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh bWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiXEBEZW5nWGlhbiI7DQoJcGFub3NlLTE6MiAxIDYgMCAzIDEgMSAx IDEgMTt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlm O30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNw YW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9y OnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAubXNvbm9ybWFsMCwgbGku bXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0K CW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsN Cgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4 cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3Np emU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYu V29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+ DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm Ij5UaGVyZSBhcmUgbWFueSBzbWFsbCBmZWF0dXJlIGRyYWZ0cyBpbiBMU1IsIGZvciBleGFtcGxl Og0KPGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1v c3BmLW9zcGZ2Mi1oYml0LyI+aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt aWV0Zi1vc3BmLW9zcGZ2Mi1oYml0LzwvYT4gJm5ic3A7aXQgb25seSBhZGRzIEgtYml0IHRvIHJv dXRlci1sc2EuDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90 O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+Rm9yIHN1cmUgd2Ugd2FudCBtb2RlbHMgdG8gYmUg bW9kdWxhciwgYnV0IG5vdCB0b28gbWFueSB0aW55IHBpZWNlcy4gTWF5YmUgd2Ugc2hvdWxkIGNv bWJpbmUgYSBmZXcgc21hbGwgZmVhdHVyZXMgbGlrZSBILUJpdCBpbnRvIG9uZSBtb2R1bGU/DQo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2Vy aWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVv dDssc2Fucy1zZXJpZiI+VGhlIGJvdHRvbSBsaW5lIGlzIHdlIG5lZWQgdG8ga2VlcCBZQU5HIGRl bGl2ZXJ5IG5vdCBmYWxsaW5nIGJlaGluZCB0b28gbXVjaC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+VGhhbmtz LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZiI+WWluZ3poZW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJp JnF1b3Q7LHNhbnMtc2VyaWYiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXYgc3R5 bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5nOjMu MHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+RnJvbTogPC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPkxz ciAmbHQ7bHNyLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IG9uIGJlaGFsZiBvZiBTdXNhbiBIYXJlcyAm bHQ7c2hhcmVzQG5kemguY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5TdW5kYXksIE1hcmNoIDMx LCAyMDE5IGF0IDc6MTUgQU08YnI+DQo8Yj5UbzogPC9iPidSb2IgU2hha2lyJyAmbHQ7cmpzQHJv Yi5zaCZndDssICZxdW90OydBY2VlIExpbmRlbSAoYWNlZSknJnF1b3Q7ICZsdDthY2VlQGNpc2Nv LmNvbSZndDs8YnI+DQo8Yj5DYzogPC9iPiZxdW90O2xzckBpZXRmLm9yZyZxdW90OyAmbHQ7bHNy QGlldGYub3JnJmd0OywgJnF1b3Q7dG9ueS5saUB0b255LmxpJnF1b3Q7ICZsdDt0b255LmxpQHRv bnkubGkmZ3Q7LCAnQ2hyaXN0aWFuIEhvcHBzJyAmbHQ7Y2hvcHBzQGNob3Bwcy5vcmcmZ3Q7PGJy Pg0KPGI+U3ViamVjdDogPC9iPlJlOiBbTHNyXSBXaGVuIHRvIGF1Z21lbnQgTFNSIGJhc2UgWUFO RyBtb2R1bGVzLi4uPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlJvYiBhbmQgQWNlZToNCjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SSBhZ3JlZSB0aGF0IHdpdGggUm9iIHRoYXQgaXQgaXMg YSBnZW5lcmljIHByb2JsZW0gdGhhdCB5b3UgbXVzdCBoYXZlIGEgcm9idXN0IHdheSB0byB2ZXJz aW9uIGFuZCByZXZpc2UgdGhlIFlhbmcgbW9kZWxzLiZuYnNwOyAmbmJzcDtUaGlzIGlzIHRydWUg Zm9yIGNvbmZpZ3VyYXRpb24sIG9wZXJhdGlvbmFsDQogZGF0YSwgYW5kIGR5bmFtaWMgZGF0YSBz dG9yZXMuJm5ic3A7Jm5ic3A7IFRoZSBuZXRtb2QgbW9kZWxpbmcgaXMgZm9jdXNpbmcgb24gY29u ZmlndXJhdGlvbiBhdCB0aGlzIHRpbWUuJm5ic3A7ICZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj4m bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+SXQgaXMgY3JpdGljYWwgdG8gZGV0ZXJtaW5lIGhvdyB0 aGUgYmFzZSBtb2RlbHMgeWFuZyBtb2RlbHMgcHJlcGFyZSBmb3IgYXVnbWVudGF0aW9ucy4mbmJz cDsgT1NQRiwgSVNJUywgQkdQLCBGSUIvUklCLCBhbmQgcG9saWN5IGFyZSBrZXkgbW9kZWxzLiAm bmJzcDsmbmJzcDtTaW5jZSBvdXIgcHJvdG9jb2xzDQogYXJlIGF1Z21lbnRlZCBiYXNlZCBvbiBj YXBhYmlsaXRpZXMsIGF1Z21lbnRhdGlvbiBiYXNlZCBvbiB0aGUgc2FtZSBjYXBhYmlsaXRpZXMg Zm9yIG1vZGVscyBtYWtlcyB0aGUgbW9zdCBzZW5zZS4gJm5ic3A7Jm5ic3A7V2UgY2FuIHJldmll dyBpbmZvL2RhdGEsIGFuZCBjb2RlIGZ1bmN0aW9uYWxpdHkgYmFzZWQgb24gdGhlIGtleSBzZW5z ZXMuDQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPklmIHdlIGhh dmUgZ29vZCB2ZXJzaW9uaW5nIG9mIHRoZSBiYXNlIG1vZGVsLCBjYW4gcmV2aXNlIGJvdGggdGhl IGRhdGEgbW9kZWwgYW5kIHRoZSBjYXBhYmlsaXR5IGluZGVwZW5kZW50bHkuJm5ic3A7Jm5ic3A7 IElmIHdlIHV0aWxpemUgdGhlIGdyb3VwaW5nIG9mIGRhdGEgbW9kZWxzIGJhc2VkDQogb24gdGhl IHZlcnNpb25pbmcsIGF1dG9tYXRpYyBkZXBsb3ltZW50IG9mIHRoaXMgd29yayBjYW4gb2NjdXIu IDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+QWNlZSBhbmQgQ2hy aXMgaGFzIGJlZW4gYWN0aXZlbHkgcGFydGljaXBhdGluZyBvbiB0aGUgdmVyc2lvbmluZyBkaXNj dXNzaW9uIGluIG5ldG1vZOKAmXMgd29yayBvbiB2ZXJzaW9uaW5nLiZuYnNwOyAmbmJzcDtJ4oCZ bSBzdXJlIHRoZXkgY2FuIHJlcG9ydCBpZiB0aGV5IGZlZWwgdGhlIHN1cHBvcnQNCiBoaXMgdGhl cmUgZm9yIHRoaXMgdHlwZSBvZiB2ZXJzaW9uLiA8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5ic3A7PC9z cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPkJHUCBhbmQgcnRnd2cgY2FuIGludGVncmF0ZSB0aGlzIHR5cGUgb2Yg dmVyc2lvbiBwcmlvciB0byB0aGUgdXBjb21pbmcgV0cgTEMuDQo8L3NwYW4+PG86cD48L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm b250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+ Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPlN1ZSAmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+Jm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O1RhaG9tYSZxdW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21hJnF1b3Q7LHNh bnMtc2VyaWYiPiBMc3IgW21haWx0bzpsc3ItYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFs ZiBPZiA8L2I+Um9iIFNoYWtpcjxicj4NCjxiPlNlbnQ6PC9iPiBTYXR1cmRheSwgTWFyY2ggMzAs IDIwMTkgMjowMCBQTTxicj4NCjxiPlRvOjwvYj4gQWNlZSBMaW5kZW0gKGFjZWUpPGJyPg0KPGI+ Q2M6PC9iPiBsc3JAaWV0Zi5vcmc7IHRvbnkubGlAdG9ueS5saTsgQ2hyaXN0aWFuIEhvcHBzPGJy Pg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbTHNyXSBXaGVuIHRvIGF1Z21lbnQgTFNSIGJhc2UgWUFO RyBtb2R1bGVzLi4uPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ Jm5ic3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB0aGlu ayB0aGlzIGlzIGEgZ2VuZXJpYyBjaGFsbGVuZ2UgdGhhdCBoYXMgdG8gYmUgc29sdmVkIGFjcm9z cyBhbGwgcHJvdG9jb2xzIC0tIGFuZCByZWxpZXMgb24gYSByb2J1c3Qgd2F5IHRvIHZlcnNpb24g YW5kIHJldmlzZSBZQU5HIG1vZHVsZXMgaW4gdGhlIElFVEYuJm5ic3A7PG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JbiBPcGVuQ29uZmlnLCBhcyB3ZSdyZSB2 ZXJ5IGxpZ2h0d2VpZ2h0IGZvciBwdXNoaW5nIGEgbmV3IHJldmlzaW9uLCBzaW5jZSB3ZSdyZSBq dXN0IHNwZWNpZnlpbmcgbmV3IHZlcnNpb25zIG9mIG1vZHVsZXMsIGFkZGluZyBuZXcgZmVhdHVy ZXMgdG8gYW4gZXhpc3RpbmcgbW9kdWxlIGlzIHByZXR0eSB0cml2aWFsLiBUaGV5IGNhbiBiZSBk b25lIGFzIGEgbWlub3IgcmV2aXNpb24gaWYgdGhlcmUncyBubyBiYWNrd2FyZHMNCiBpbmNvbXBh dGlibGUgY2hhbmdlcy4mbmJzcDsgSXQgc2VlbXMgYmV0dGVyLCB0byBtZSwgdG8gZW5zdXJlIHRo YXQgdGhlcmUgaXMgY29tbW9uIGxvZ2ljIGZvciBob3cgb25lIHNwbGl0cyB1cCBtb2R1bGVzLCB0 byBtYWtlIHRoaW5ncyBhY3R1YWxseSB1c2FibGUgZm9yIGRldmVsb3BlcnMgdHJ5aW5nIHRvIGNv bnN1bWUgdGhlbSwgcmF0aGVyIHRoYW4gbmVlZGluZyB0byB1bmRlcnN0YW5kIHdoZW4gYW5kIHdo ZXJlIGluIHRoZSBJRVRGIGEgZmVhdHVyZQ0KIHdhcyBkZXZlbG9wZWQuPG86cD48L286cD48L3A+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGF0IGJlaW5nIHNhaWQgLS0gdGhpcyBt ZWFucyBvbmUgc2hvdWxkIHByb2JhYmx5IGV4cGVjdCBlYWNoIExTUiBiYXNlIG1vZHVsZSB0byBi ZSByZXZpc2VkIHdpdGggbW9zdCBuZXcgTFNSIFJGQ3MuIFdpdGggdGhlIGN1cnJlbnQgYWdpbGl0 eSBvZiB0aGUgcmV2aWV3IGFuZCBwdWJsaWNhdGlvbiBwcm9jZXNzIC0tIEknbSBub3Qgc3VyZSB0 aGF0IGlzIHJlYWxpc3RpYyBlaXRoZXIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPnIuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gU2F0LCAzMCBNYXIgMjAxOSBhdCAwOTox NSwgQWNlZSBMaW5kZW0gKGFjZWUpICZsdDs8YSBocmVmPSJtYWlsdG86YWNlZUBjaXNjby5jb20i PmFjZWVAY2lzY28uY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxi bG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEu MHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+U3BlYWtpbmcgYXMgV0cgbWVtYmVyOjxicj4NCjxicj4NCkZvciBtYW55IG9m IHRoZSBuZXcgTFNSIFdHIGRvY3VtZW50cywgd2UgYXJlIGFscmVhZHkgaW5jbHVkZWQgYm90aCBP U1BGIGFuZCBJUy1JUyBlbmNvZGluZ3MgaW4gYSBzaW5nbGUgZG9jdW1lbnQuIE5vdywgd2UgaGF2 ZSBhZ3JlZWQgdGhhdCBkb2N1bWVudHMgcmVxdWlyaW5nIHNpbXBsZSBCR1AtTFMgY2hhbmdlcyB3 aWxsIGFsc28gaW5jbHVkZSB0aGUgQkdQLUxTIGVuY29kaW5nLiBHaXZlbiB0aGlzLCBJIGRvbid0 IHdhbnQgdG8gYWRkIGFub3RoZXINCiByZXF1aXJlbWVudCBmb3IgcHVibGljYXRpb24gb2YgYSBX RyBkb2N1bWVudC4gVGhpcyB3b3VsZCBhbHNvIGFkZCBhZGRpdGlvbmFsIHJldmlld3MgdG8gdGhl IGRvY3VtZW50LiBZb3UndmUgYWxsIGhlYXJkIHRoZSBleHByZXNzaW9uICZxdW90O2RpdmlkZSBh bmQgY29ucXVlciZxdW90Oywgd2hpbGUgbGV0IG1lIGludHJvZHVjZSB0aGUgY29yb2xsYXJ5LCAm cXVvdDtjb25zb2xpZGF0ZSBhbmQgc3RhZ25hdGUmcXVvdDsuDQo8YnI+DQo8YnI+DQpBZGRpdGlv bmFsbHksIEkgYWdyZWUgd2l0aCBZaW5nemhlbidzIGNvbW1lbnQgdGhhdCBpdCBpcyBub3QgY2xl YXIgdGhhdCB3ZSB3YW50IGEgc2VwYXJhdGUgWUFORyBtb2R1bGUgZm9yIGV2ZXJ5IE9TUEYvSVMt SVMgZmVhdHVyZS4NCjxicj4NCjxicj4NClRoYW5rcyw8YnI+DQpBY2VlPGJyPg0KPGJyPg0KT24g My8yOS8xOSwgNDozMyBBTSwgJnF1b3Q7THNyIG9uIGJlaGFsZiBvZiA8YSBocmVmPSJtYWlsdG86 dG9ueS4ubGlAdG9ueS5saSIgdGFyZ2V0PSJfYmxhbmsiPg0KdG9ueS5saUB0b255LmxpPC9hPiZx dW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOmxzci1ib3VuY2VzQGlldGYub3JnIiB0YXJnZXQ9Il9i bGFuayI+bHNyLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IG9uIGJlaGFsZiBvZg0KPGEgaHJlZj0ibWFp bHRvOnRvbnkubGlAdG9ueS5saSIgdGFyZ2V0PSJfYmxhbmsiPnRvbnkubGlAdG9ueS5saTwvYT4m Z3Q7IHdyb3RlOjxicj4NCjxicj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgQ2hyaXMsPGJyPg0KPGJy Pg0KJm5ic3A7ICZuYnNwOyBPbmUgY29uY2VybiBpcyBzaW1wbHkgb25lIG9mIHNjYWxlOiBkb2lu ZyB0aGlzIHdpbGwgaW5jcmVhc2UgdGhlIHNpemUgb2YgdGhlIGRvY3VtZW50LiZuYnNwOyBBdCB3 aGF0IHBvaW50IGRvIHRoaW5ncyBiZWNvbWUgc3VmZmljaWVudGx5IGF3a3dhcmQgdGhhdCB3ZSB3 YW50IHRvIGhhdmUgYSBzZXBhcmF0ZSwgY29uY3VycmVudCBkb2N1bWVudC48YnI+DQo8YnI+DQom bmJzcDsgJm5ic3A7IEluIG90aGVyIHdvcmRzLCBpZiB0aGUgcmVxdWlyZW1lbnQgaXMgZm9yIGNv bmN1cnJlbnQgZGVsaXZlcnksIGlzIGNvLWxvY2F0aW9uIHJlYWxseSBhIHJlcXVpcmVtZW50Pzxi cj4NCjxicj4NCiZuYnNwOyAmbmJzcDsgUmVnYXJkcyw8YnI+DQombmJzcDsgJm5ic3A7IFRvbnk8 YnI+DQo8YnI+DQo8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgT24gTWFyIDI5LCAyMDE5LCBhdCA5 OjE3IEFNLCBDaHJpc3RpYW4gSG9wcHMgJmx0OzxhIGhyZWY9Im1haWx0bzpjaG9wcHNAY2hvcHBz Lm9yZyIgdGFyZ2V0PSJfYmxhbmsiPmNob3Bwc0BjaG9wcHMub3JnPC9hPiZndDsgd3JvdGU6PGJy Pg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IDxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyA8YnI+DQombmJz cDsgJm5ic3A7ICZndDsgVGhlIGJhc2UgWUFORyBtb2R1bGVzIGZvciBJUy1JUyBhbmQgT1NQRiBi b3RoIGluY2x1ZGUgb3BlcmF0aW9uYWwgc3RhdGUgdG8gZGVzY3JpYmUgVExWIGRhdGEuIER1cmlu ZyB0aGUgZGlzY3Vzc2lvbiBhYm91dCBPU1BGdjMncyB2ZXJzaW9uIG9mIHRoaXMgZGF0YSwgSSBi cm91Z2h0IHVwIHRoZSBpc3N1ZSBvZiB3aGVuIGFuZCBob3cgdGhlIGJhc2UgbW9kdWxlcyBzaG91 bGQgYmUgYXVnbWVudGVkIHRvIGFkZCBuZXcgVExWIHR5cGVzIHRvDQogdGhlIG1vZGVsLCBzdWdn ZXN0aW5nIGl0IGJlIGRvbmUgaW5saW5lIGFuZCB3aXRoIHRoZSBSRkMgdGhhdCBhZGRzIHRoZSBu ZXcgZmVhdHVyZS9mdW5jdGlvbmFsaXR5IHRvIHRoZSBwcm90b2NvbC48YnI+DQombmJzcDsgJm5i c3A7ICZndDsgPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IEknbGwgZ28gZmFydGhlciBoZXJlIGFu ZCBzYXkgdGhpcyBzaG91bGQgYXBwbHkgdG8gYWxsIHRoZSBZQU5HIHJlcXVpcmVkIGZvciBtYW5h Z2VtZW50IG9mIHRoZSBuZXcgZmVhdHVyZSwgYW5kIGl0IHNob3VsZCBhbGwgYmUgYWRkZWQgaW5s aW5lIHdpdGggdGhlIGZlYXR1cmUgKGkuZS4sIGluIHRoZSBzYW1lIGRyYWZ0KS4gSW4gb3RoZXIg d29yZHMgbmV3IGZlYXR1cmVzL2Z1bmN0aW9uYWxpdHkgc2hvdWxkIGluY2x1ZGUgdGhlIFlBTkcN CiBhdWdtZW50IHJlcXVpcmVkIHRvIG1hbmFnZSBzYWlkIGZlYXR1cmVzL2Z1bmN0aW9uYWxpdHku PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IDxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBUaGlzIGhh cyBiZWVuIHN1Z2dlc3RlZC90cmllZCBwcmV2aW91c2x5IHdpdGggU05NUCB3aXRoIHZhcnlpbmcg KGxvdykgbGV2ZWxzIG9mIHN1Y2Nlc3MuIFRoZSBkaWZmZXJlbmNlIGhlcmUgaXMgMSkgWUFORyBh ZGRpdGlvbnMgKGEgbmV3IG1vZHVsZSBwZXJoYXBzIGp1c3QgYXVnbWVudGluZyB0aGUgYmFzZSkg aXMgZWFzeSwgd2hlcmVhcyBTTk1QIHdhc24ndC4gQWRkaXRpb25hbGx5LCBvcGVyYXRvcnMgd2Vy ZW4ndCB1c2luZyBTTk1QDQogdG8gZnVsbHkgbWFuYWdlIGZ1bmN0aW9uYWxpdHkgKGUuZy4sIG5v dCBkb2luZyBjb25maWd1cmF0aW9uKSBzbyBhIHJlcXVpcmVtZW50IGZvciBleHRyYSB3b3JrIHdh cyBoYXJkZXIgdG8ganVzdGlmeS4gT3BlcmF0b3JzICpkbyogd2FudCB0byBmdWxseSBtYW5hZ2Ug dGhlaXIgbmV0d29ya3Mvc2VydmVycyB3aXRoIFlBTkcgdGhvdWdoLjxicj4NCiZuYnNwOyAmbmJz cDsgJmd0OyA8YnI+DQombmJzcDsgJm5ic3A7ICZndDsgVGhlIGFyZ3VtZW50IGFnYWluc3QgdGhp cyBkdXJpbmcgdGhlIG1lZXRpbmcgd2FzIHRoYXQgaXQgd291bGQgY3JlYXRlIG1hbnkgc21hbGwg bW9kdWxlcy4gSSBkb24ndCBmaW5kIHRoaXMgY29tcGVsbGluZyAoaS5lLiwgJnF1b3Q7c28mcXVv dDs/IDopPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IDxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBB c3N1bWUgSSdtIGFuIG9wZXJhdG9yIC0tIHRoZSBhY3R1YWwgY29uc3VtZXIgb2YgdGhpcyBtYW5h Z2VtZW50IHN0dWZmOjxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyA8YnI+DQombmJzcDsgJm5ic3A7 ICZndDsgLSBJZiBJJ20gZ29pbmcgdG8gdXNlIHRoaXMgbmV3IGZlYXR1cmUgWCwgSSBuZWVkIHRv IGJlIGFibGUgdG8gbWFuYWdlIGl0LiBTbyBJIG5lZWQgaXQgWUFORyBmb3IgaXQuIE5vdCBvbmx5 IGRvIEkgbmVlZCBhbnkgbmV3IFRMViBkYXRhIGluIHRoZSBvcGVyYXRpb25hbCBzdGF0ZSwgYnV0 IEkgbmVlZCB0aGUgY29uZmlndXJhdGlvbiBhbmQgYW55IG90aGVyIG9wZXJhdGlvbmFsIHN0YXRl IHJpZ2h0IGFsb25nIHdpdGggaXQuIE90aGVyd2lzZQ0KIGVhY2ggdmVuZG9yIGhhcyB0byBhZGQg bmV3IFlBTkcgdG8gdGhlaXIgdmVuZG9yIG1vZHVsZXMsIG9yIHRoZSBmZWF0dXJlIGlzIHVzZWxl c3MgdG8gbWUuIEkgY2FuJ3QgdXNlIHNvbWV0aGluZyBpZiBJIGNhbid0IHR1cm4gaXQgb24uPGJy Pg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IDxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyAtIEkgZG9uJ3Qg Y2FyZSBhYm91dCBoYXZpbmcgbWFueSBzbWFsbGVyIG1vZHVsZXMgdGhhdCBhdWdtZW50IHRoZSBi YXNlIG1vZHVsZSAtLSBhdCBhbGwuIFF1aXRlIHRoZSBvcHBvc2l0ZSBhY3R1YWxseSwgd2hlbiBu ZXcgZnVuY3Rpb25hbGl0eSBpcyBhY2NvbXBhbmllZCBieSBpdCdzIG93biBtb2R1bGUgaXQgcHJv dmlkZXMgbWUgYSBzaW1wbGUgd2F5IHRvIHNlZSBpZiB0aGF0IGZ1bmN0aW9uYWxpdHkgaXMgcHJl c2VudCBhcyB0aGUgbW9kdWxlDQogd2lsbCBiZSBwcmVzZW50IGluIHRoZSBZQU5HIGNhcGFiaWxp dGllcyBhbm5vdW5jZWQgYnkgdGhlIGRldmljZS48YnI+DQombmJzcDsgJm5ic3A7ICZndDsgPGJy Pg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IEknZCBiZSBpbnRlcmVzdGVkIGluIGhlYXJpbmcgcmVhc29u cyB3ZSAoYXMgYSBXRykgc2hvdWxkbid0IGp1c3QgZXhwZWN0IGEgWUFORyBtb2R1bGUgKGV2ZW4g aWYgaXQncyBzbWFsbCkgdG8gYmUgaW5jbHVkZWQgd2l0aCBkcmFmdHMgdGhhdCBhZGQgbmV3IGZ1 bmN0aW9uYWxpdHkuPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IDxicj4NCiZuYnNwOyAmbmJzcDsg Jmd0OyBUaGFua3MsPGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IENocmlzLjxicj4NCiZuYnNwOyAm bmJzcDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCiZuYnNwOyAmbmJzcDsgJmd0OyBMc3IgbWFpbGluZyBsaXN0PGJyPg0KJm5ic3A7ICZu YnNwOyAmZ3Q7IDxhIGhyZWY9Im1haWx0bzpMc3JAaWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5M c3JAaWV0Zi5vcmc8L2E+PGJyPg0KJm5ic3A7ICZuYnNwOyAmZ3Q7IDxhIGhyZWY9Imh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHNyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sc3I8L2E+PGJyPg0KPGJyPg0KJm5ic3A7 ICZuYnNwOyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxi cj4NCiZuYnNwOyAmbmJzcDsgTHNyIG1haWxpbmcgbGlzdDxicj4NCiZuYnNwOyAmbmJzcDsgPGEg aHJlZj0ibWFpbHRvOkxzckBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPkxzckBpZXRmLm9yZzwv YT48YnI+DQombmJzcDsgJm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vbHNyIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9sc3I8L2E+PGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpMc3IgbWFpbGluZyBsaXN0PGJyPg0K PGEgaHJlZj0ibWFpbHRvOkxzckBpZXRmLm9yZyIgdGFyZ2V0PSJfYmxhbmsiPkxzckBpZXRmLm9y ZzwvYT48YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2xzciIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vbHNyPC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_75095E6728674466B23248E27DC47C9Bhuaweicom_-- From nobody Sun Mar 31 12:41:44 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A88401200B3 for ; Sun, 31 Mar 2019 12:41:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 LpgIW-Z8JLLE for ; Sun, 31 Mar 2019 12:41:40 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id C7D6612008A for ; Sun, 31 Mar 2019 12:41:39 -0700 (PDT) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 81211604DC; Sun, 31 Mar 2019 15:41:38 -0400 (EDT) From: Christian Hopps Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_628D2022-C27E-4976-8887-DCA46500A966"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Sun, 31 Mar 2019 15:41:37 -0400 In-Reply-To: <75095E67-2867-4466-B232-48E27DC47C9B@huawei.com> Cc: Christian Hopps , Susan Hares , Rob Shakir , "Acee Lindem (acee)" , "lsr@ietf.org" , Tony Li To: Yingzhen Qu References: <2E6CA4AD-AD65-4A20-9545-1C81ED8B8968@tony.li> <080001d4e7cc$0b434690$21c9d3b0$@ndzh.com> <75095E67-2867-4466-B232-48E27DC47C9B@huawei.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Lsr] When to augment LSR base YANG modules... X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2019 19:41:43 -0000 --Apple-Mail=_628D2022-C27E-4976-8887-DCA46500A966 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 31, 2019, at 1:31 PM, Yingzhen Qu = wrote: >=20 > There are many small feature drafts in LSR, for example: = https://datatracker.ietf.org/doc/draft-ietf-ospf-ospfv2-hbit/ it only = adds H-bit to router-lsa. >=20 > For sure we want models to be modular, but not too many tiny pieces. = Maybe we should combine a few small features like H-Bit into one module? But why? Delaying the publication of the management definition until some (so far = as I can tell) arbitrary number of features has been collected = negatively impacts users. What do they gain in return? Thanks, Chris. >=20 > Thanks, > Yingzhen >=20 > From: Lsr on behalf of Susan Hares = > Date: Sunday, March 31, 2019 at 7:15 AM > To: 'Rob Shakir' , "'Acee Lindem (acee)'" > Cc: "lsr@ietf.org" , "tony.li@tony.li" = , 'Christian Hopps' > Subject: Re: [Lsr] When to augment LSR base YANG modules... >=20 > Rob and Acee: >=20 > I agree that with Rob that it is a generic problem that you must have = a robust way to version and revise the Yang models. This is true for = configuration, operational data, and dynamic data stores. The netmod = modeling is focusing on configuration at this time. >=20 > It is critical to determine how the base models yang models prepare = for augmentations. OSPF, ISIS, BGP, FIB/RIB, and policy are key models. = Since our protocols are augmented based on capabilities, augmentation = based on the same capabilities for models makes the most sense. We can = review info/data, and code functionality based on the key senses. >=20 > If we have good versioning of the base model, can revise both the data = model and the capability independently. If we utilize the grouping of = data models based on the versioning, automatic deployment of this work = can occur. >=20 > Acee and Chris has been actively participating on the versioning = discussion in netmod=E2=80=99s work on versioning. I=E2=80=99m sure = they can report if they feel the support his there for this type of = version. >=20 > BGP and rtgwg can integrate this type of version prior to the upcoming = WG LC. >=20 > Sue >=20 >=20 > From: Lsr [mailto:lsr-bounces@ietf.org] On Behalf Of Rob Shakir > Sent: Saturday, March 30, 2019 2:00 PM > To: Acee Lindem (acee) > Cc: lsr@ietf.org; tony.li@tony.li; Christian Hopps > Subject: Re: [Lsr] When to augment LSR base YANG modules... >=20 > I think this is a generic challenge that has to be solved across all = protocols -- and relies on a robust way to version and revise YANG = modules in the IETF. >=20 > In OpenConfig, as we're very lightweight for pushing a new revision, = since we're just specifying new versions of modules, adding new features = to an existing module is pretty trivial. They can be done as a minor = revision if there's no backwards incompatible changes. It seems better, = to me, to ensure that there is common logic for how one splits up = modules, to make things actually usable for developers trying to consume = them, rather than needing to understand when and where in the IETF a = feature was developed. >=20 > That being said -- this means one should probably expect each LSR base = module to be revised with most new LSR RFCs. With the current agility of = the review and publication process -- I'm not sure that is realistic = either. >=20 > r. >=20 > On Sat, 30 Mar 2019 at 09:15, Acee Lindem (acee) = wrote: > Speaking as WG member: >=20 > For many of the new LSR WG documents, we are already included both = OSPF and IS-IS encodings in a single document. Now, we have agreed that = documents requiring simple BGP-LS changes will also include the BGP-LS = encoding. Given this, I don't want to add another requirement for = publication of a WG document. This would also add additional reviews to = the document. You've all heard the expression "divide and conquer", = while let me introduce the corollary, "consolidate and stagnate". >=20 > Additionally, I agree with Yingzhen's comment that it is not clear = that we want a separate YANG module for every OSPF/IS-IS feature. >=20 > Thanks, > Acee >=20 > On 3/29/19, 4:33 AM, "Lsr on behalf of tony.li@tony.li" = wrote: >=20 >=20 > Chris, >=20 > One concern is simply one of scale: doing this will increase the = size of the document. At what point do things become sufficiently = awkward that we want to have a separate, concurrent document. >=20 > In other words, if the requirement is for concurrent delivery, is = co-location really a requirement? >=20 > Regards, > Tony >=20 >=20 > > On Mar 29, 2019, at 9:17 AM, Christian Hopps = wrote: > > > > > > The base YANG modules for IS-IS and OSPF both include = operational state to describe TLV data. During the discussion about = OSPFv3's version of this data, I brought up the issue of when and how = the base modules should be augmented to add new TLV types to the model, = suggesting it be done inline and with the RFC that adds the new = feature/functionality to the protocol. > > > > I'll go farther here and say this should apply to all the YANG = required for management of the new feature, and it should all be added = inline with the feature (i.e., in the same draft). In other words new = features/functionality should include the YANG augment required to = manage said features/functionality. > > > > This has been suggested/tried previously with SNMP with varying = (low) levels of success. The difference here is 1) YANG additions (a new = module perhaps just augmenting the base) is easy, whereas SNMP wasn't. = Additionally, operators weren't using SNMP to fully manage functionality = (e.g., not doing configuration) so a requirement for extra work was = harder to justify. Operators *do* want to fully manage their = networks/servers with YANG though. > > > > The argument against this during the meeting was that it would = create many small modules. I don't find this compelling (i.e., "so"? :) > > > > Assume I'm an operator -- the actual consumer of this management = stuff: > > > > - If I'm going to use this new feature X, I need to be able to = manage it. So I need it YANG for it. Not only do I need any new TLV data = in the operational state, but I need the configuration and any other = operational state right along with it. Otherwise each vendor has to add = new YANG to their vendor modules, or the feature is useless to me. I = can't use something if I can't turn it on. > > > > - I don't care about having many smaller modules that augment = the base module -- at all. Quite the opposite actually, when new = functionality is accompanied by it's own module it provides me a simple = way to see if that functionality is present as the module will be = present in the YANG capabilities announced by the device. > > > > I'd be interested in hearing reasons we (as a WG) shouldn't just = expect a YANG module (even if it's small) to be included with drafts = that add new functionality. > > > > Thanks, > > Chris. > > _______________________________________________ > > Lsr mailing list > > Lsr@ietf.org > > https://www.ietf.org/mailman/listinfo/lsr >=20 > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr >=20 >=20 > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr > _______________________________________________ > Lsr mailing list > Lsr@ietf.org > https://www.ietf.org/mailman/listinfo/lsr --Apple-Mail=_628D2022-C27E-4976-8887-DCA46500A966 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAlyhF/EACgkQLh2DDte4 MCXBtg//XaoTwiejH+niTDGvcLyC1VXa06GOArjXRVwm9kXoB2X5ZZvJAtEMjQOf clVU76xTzpyj2SDeHBFwSmTOBf1G7tdsmbmeac+vdMv74FZYL6QGY1SbB+jA7pWm pLAl4fbdhfNJRecjctplIo0rYeISg0E3u4TOzHgtfLKs8tqY0w2gQKah46dokgWd ponztsyaIm8F1vNYVfl/sPt9x1mujHRmlagW+i+Jj/cMUlhoTN55+ijBF9i65+/n F4dLGWSOF8SFqMV3B4lxum7b7TqZu3Wm/U8uHCXDJGCU1wM45kyUsNXfa4wHuJve gJCveOxkpNdBNwSqFAJYm+JCU90ExYtUfE57upUMOj0WOc5xgIuIIG+GFIT4Y5xG 3bt/GuVioNrMKUcS9oZZudBFHVuPtV6ixdNLgz5fXEYx9+JuGIUITERg/Y+O0l+z UHJUq2pfBIlscx2cJuTaWM/UAEJ/9eoMMNaRPpcmioxM+Z0j+XehgANkdzV0YMuQ ZQ04G5/cks9BcLSPkPW1m5p6/qstk/0pdWtm0krNEQVYEU4QqB2yxaIcDYKy3Gy+ nGOZxDFfdnZOp+27QGN6PhBPzItQD1ZbE4OnRxtmvi5Quah8PK2z/YHPedAQRnKi +pJDMlOYxTU5MMFMY4iJ2ZABXQWMqeQvs/UMrbpj96U/wDjQFCQ= =puCP -----END PGP SIGNATURE----- --Apple-Mail=_628D2022-C27E-4976-8887-DCA46500A966-- From nobody Sun Mar 31 13:24:29 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E819112000E for ; Sun, 31 Mar 2019 13:24:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 V31VINe3XdXw for ; Sun, 31 Mar 2019 13:24:24 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id E55D012024C for ; Sun, 31 Mar 2019 13:24:22 -0700 (PDT) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 607AC604DC; Sun, 31 Mar 2019 16:24:22 -0400 (EDT) From: Christian Hopps Content-Type: multipart/signed; boundary="Apple-Mail=_99B1EAA9-5766-4D91-83A9-7EAAAE2D822E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-Id: Date: Sun, 31 Mar 2019 16:24:21 -0400 Cc: Christian Hopps To: lsr@ietf.org X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: [Lsr] "unknown TLVs" in YANG data models X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2019 20:24:27 -0000 --Apple-Mail=_99B1EAA9-5766-4D91-83A9-7EAAAE2D822E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii So this came up during the second session at IETF104. Our base YANG data = models have "baked" representations of TLV data and then a catch all = "unknown tlv" list for the unrecognized data. When a new feature is added that adds a new TLVs it would seem obvious = to also add an augmentation to the base model to provide a similar = "baked" version of the new TLV data. However, does this now mean that = the TLV is no longer "unknown"? Is the data removed from the unknown = list or just present in both cases? Thinking about this made me realize the following: It's very common to = want to get *all* the TLV data in raw form. With the current design the = client has to settle for reverse engineering the baked data in addition = to pulling the TLV data from the unknown list. A more functional choice is to simply have the "unknonwn-tlv" list = return *all* the TLV data. Whether a TLV is "known" (i.e., a baked = version is present) to the server is already indicated by looking at the = servers reported capabilities. At least with the IS-IS module this could be a minor change (rename = "unknown-tlvs" to "tlvs" and update the description). I believe the = change is also similarly minor for OSPF as well. It would be nice, if people agree, and agree its not too late, to make = this change now rather than wait for the IESG/IETF LC to complete and = then have to do a BIS update. Thanks, Chris. --Apple-Mail=_99B1EAA9-5766-4D91-83A9-7EAAAE2D822E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAlyhIfUACgkQLh2DDte4 MCVVPw//X6WuiBJdg6EgBYc1sfUTcU17adZ6IOH6A4xA6Uc6ehHAp3bg4SVFXXJ2 W93TwQJbn85EhwwoG/x+BY331OHlj6OHfNGFXxw+drlbmDiASQiLqyGVVNYBnVY9 Z6w4VwqrcSQhiq3oTV/jL0i0O/uOymBuLYL+x3vvkecmpTLye1A8JzaE6pWL2dRL DsoyeaTUQRg7ms+EpfamERrdTPEUksM2KIRTZGfttAgel8yzbgT1jYP2fkxA7Hwk F2NzczIq9UbhBYg9UqS+wSV4m3Ja5iVvJHmQ2/NHgv/DtORXT0aVkVx/rMCUXdQ3 LPY9s5YVG19Mv0j+Qf5N+C2r4Z6MvhPPIkCcL6PHUxYqOTeDIBwi2xDpfTBNfvTz IOLj3I2kbnKk0JYhi5utaVBOKpaczhMx40ViKbFu8fPGp6wEYuqkE8dwANb8DoHX SVMOuN815iifwnMVn6MVsQEHFzHXyPUEMvCcO2yURF2kU3640uKRd6cqZ636RqpO kN4i/QaZGgnOQZ4v3UsSnNEADZRJcwsv0934LXARszGEHa4RrWR2T5lBaxj/enff UVocMfmeYMR7NEFS6OILhhf8TMxFw/NSM8B8ajVzpsf0dExc5q1axX5vJKZyeWs1 Wn/zYa7EyFoYHF7pa/Hvc+yZymHfxBNJmOfjfXhxQPhrnrDXbLs= =+pAC -----END PGP SIGNATURE----- --Apple-Mail=_99B1EAA9-5766-4D91-83A9-7EAAAE2D822E-- From nobody Sun Mar 31 13:25:35 2019 Return-Path: <7riw77@gmail.com> X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A7CA1201C0 for ; Sun, 31 Mar 2019 13:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 mZbb0j_EQhQV for ; Sun, 31 Mar 2019 13:25:32 -0700 (PDT) Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (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 8F26912000E for ; Sun, 31 Mar 2019 13:25:29 -0700 (PDT) Received: by mail-ot1-x32a.google.com with SMTP id f10so6661415otb.6 for ; Sun, 31 Mar 2019 13:25:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=65F0Gjdu73nhGx2GuXwI11XL6zBxxZ2XLZSHWkTyYDE=; b=i0tmxMglffDEBCAExbNDlG/AjPBFpS3sXLVHKvnD9Y/UsVl67nqmUho5mjRu1CZT9+ 9fSfVWzv/u+ifIUpm6gafIqXJ8gkgxElTL2XgJw7XkQRzyTHLF0iuWIDdobly0TelxX7 nhSOmuCnm9uw8U9jpTVJ+EGYF8zF1ERbpNsbc8LVFmaC8burM5Hb1FJAxKK2tpJiKSJp AuXc3b78Y97REwh/eYyXchnf4tcuCTO5B2o5aSQpAa/3AQsjKgGoL96buemAkAr1QNHa FChPVMMNEsNsT4qCLNqr/7GmUm/ZPiykG8OucWuUJ4zhq12paLVmjQstQ6xAgzwG8Pwe BbZw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=65F0Gjdu73nhGx2GuXwI11XL6zBxxZ2XLZSHWkTyYDE=; b=MRcUqFBtTItK28si0NuK1f9B6uFHnWAke4Bc6scYbM96iBfYWN2UY3cKcjCpl/zaBq uyWyn8eLV2R1rNxirFSnQaviQ5KUCimUyD9NNMvI88jcYv0qSKivav/GmUY1thDygOTP OzZG7LqPKEvYZ386Sf4yfjYb3IVO0cR2HluDWJmveFIFVXYnjCD6U/Qp56m425Lx6sRs epdrUJbqKpUPT9QjeybWrYyQl8gxrYhUnnpRQgSZlpZbyiEglJnrebusv+AOJRhAYlKD TmkiV01M0x/DyXxPOR1Zf0Dhb5lKGtLaHJjq1zMZ0c+pxK7v4ANYGJK+EAyOdVXaeyIX c+Sw== X-Gm-Message-State: APjAAAWwwLOz7/vWFzpdZA40cfFaFGIKleb4Pa0Jd+6XT43QhsZUiBuh Z8xxCNYdhgRUS6WOtoMHabQT9o5Nr5A= X-Google-Smtp-Source: APXvYqw62V58Ug/mBqttIr2doo5kMwTNRAQEG2Iw3lMIiJCZCxxAZV9GWtQWkyXGvpl9+rTlCokcGA== X-Received: by 2002:a9d:68c3:: with SMTP id i3mr21908226oto.235.1554063928736; Sun, 31 Mar 2019 13:25:28 -0700 (PDT) Received: from RussPC ([2600:1700:720:1050::440]) by smtp.gmail.com with ESMTPSA id a23sm3327580otf.69.2019.03.31.13.25.28 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 31 Mar 2019 13:25:28 -0700 (PDT) From: <7riw77@gmail.com> To: References: <155406381670.12357.17272312414769230549.idtracker@ietfa.amsl.com> In-Reply-To: <155406381670.12357.17272312414769230549.idtracker@ietfa.amsl.com> Date: Sun, 31 Mar 2019 16:25:27 -0400 Message-ID: <04bf01d4e7ff$e16d7230$a4485690$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLwM/JIkPbzT8Vkdbi80JHv2Wjy+aPvl4FQ Content-Language: en-us Archived-At: Subject: [Lsr] FW: New Version Notification for draft-white-distoptflood-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2019 20:25:34 -0000 FYI -- I've put just the flooding optimizations from the openfabric work = into a separate draft and submitted it. I've also modified the wording a = bit, as this is applicable far beyond data center fabrics. =F0=9F=98=8A /r > -----Original Message----- > From: internet-drafts@ietf.org > Sent: Sunday, March 31, 2019 4:24 PM > To: Shawn Zandi ; Russ White > Subject: New Version Notification for draft-white-distoptflood-00.txt >=20 >=20 > A new version of I-D, draft-white-distoptflood-00.txt has been = successfully > submitted by Russ White and posted to the IETF repository. >=20 > Name: draft-white-distoptflood > Revision: 00 > Title: IS-IS Optimal Distributed Flooding for Dense Topologies > Document date: 2019-03-31 > Group: Individual Submission > Pages: 13 > URL: = https://www.ietf.org/internet-drafts/draft-white-distoptflood- > 00.txt > Status: = https://datatracker.ietf.org/doc/draft-white-distoptflood/ > Htmlized: = https://tools.ietf.org/html/draft-white-distoptflood-00 > Htmlized: = https://datatracker.ietf.org/doc/html/draft-white-distoptflood >=20 >=20 > Abstract: > Dense topologies, such as data center fabrics based on the Clos and > butterfly fabric topologies. Flooding mechanisms designed for = sparse > topologies, when used in these dense topologies, can result in = slower > convergence times and higher resource utilization. The = modifications > to the flooding mechanism in the Intermediate System to = Intermediate > System (IS-IS) link state protocol described in this document = reduce > resource utilization to a minimum, while increaseing convergence > performance in dense topologies. >=20 > Note that a Clos fabric is used as the primary example of a desne > flooding topology throughout this document. However, the flooding > optimizations described in this document apply to any dense = topology. >=20 >=20 >=20 >=20 > 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. >=20 > The IETF Secretariat From nobody Sun Mar 31 14:09:42 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B004A1200D8 for ; Sun, 31 Mar 2019 14:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.503 X-Spam-Level: X-Spam-Status: No, score=-14.503 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=VG9aFrn9; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=ir6mdpFB 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 Y2JNWzmjGA_C for ; Sun, 31 Mar 2019 14:09:37 -0700 (PDT) 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 6C574120003 for ; Sun, 31 Mar 2019 14:09:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11804; q=dns/txt; s=iport; t=1554066577; x=1555276177; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=sQzKhKwWFBxVH2PJcnSYfrB7mv/6dygBWxHH0auQ7CM=; b=VG9aFrn9FSxmPg8joZ8dvbxOxpcseSynQB+zFTxXWdsfGk/H2g+jDWkx PBFBJp6FiclXrbD+KG60G+e7aPCbVy3tZ1pBuQaKT4vZPR49z+OM7xV2r sVpPlsi1QkHvmdUusMejoVaXxivTqTI5U4Jc4mPNrOX7h/vUtnZ9TYGjY M=; IronPort-PHdr: =?us-ascii?q?9a23=3AmgsEuRAjqai7zWiuuTchUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qgw3kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMdRXUg?= =?us-ascii?q?Mdz8AfngguGsmAXETwIfPCZC0hF8MEX1hgrDm2?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAABlK6Fc/51dJa1jGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAQGBUQQBAQEBAQsBgT0kLANodAQLJwqEBINHA4RSimCCV36?= =?us-ascii?q?WEYEugSQDVA4BARgLCYRAAheFICI0CQ0BAQMBAQkBAwJtHAyFSgEBAQMBAQE?= =?us-ascii?q?hEQwBASoCCAMBDwIBCA4DAwEBAQECAiMDAgICJQsUAQgIAgQBDQWDIgGBXQM?= =?us-ascii?q?NCAEOnVkCihRxgS+CeQEBBYFFQYJzGIIMAwWBCyQBizIXgX+BECgfghcHLj6?= =?us-ascii?q?CYQEBAwGBXSaCZDGCJop/ggSXamAJAodvi28alCyLP4YRjT0CBAIEBQIOAQE?= =?us-ascii?q?FgU04gVZwFTsqAYJBggoMF4NLg0aBToU/coEojhQBgR4BAQ?= X-IronPort-AV: E=Sophos;i="5.60,294,1549929600"; d="scan'208";a="252371749" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 31 Mar 2019 21:09:36 +0000 Received: from XCH-ALN-017.cisco.com (xch-aln-017.cisco.com [173.36.7.27]) by rcdn-core-6.cisco.com (8.15.2/8.15.2) with ESMTPS id x2VL9ZdY005125 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 31 Mar 2019 21:09:35 GMT Received: from xhs-rcd-002.cisco.com (173.37.227.247) by XCH-ALN-017.cisco.com (173.36.7.27) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 31 Mar 2019 16:09:35 -0500 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 31 Mar 2019 16:09:34 -0500 Received: from NAM05-DM3-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sun, 31 Mar 2019 16:09:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=sQzKhKwWFBxVH2PJcnSYfrB7mv/6dygBWxHH0auQ7CM=; b=ir6mdpFBz2OfNxJg1rhiwA62f6uY+90upqFf5tx6aLlbnM6Vl296aWn+HqRtmbwF/K2seMk99AGVAfHfpiXuoEXD7tgA1P/JTr3iUnOVmdMTSIwoEKXDmnLy2jBYEnu16C+QGw0fxRTlvbsSkaJLtqSrKPHl5t6So1ujry5wqhI= Received: from BN6PR1101MB2226.namprd11.prod.outlook.com (10.174.112.11) by BN6PR1101MB2337.namprd11.prod.outlook.com (10.173.199.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.20; Sun, 31 Mar 2019 21:09:32 +0000 Received: from BN6PR1101MB2226.namprd11.prod.outlook.com ([fe80::9c05:e282:840b:51a1]) by BN6PR1101MB2226.namprd11.prod.outlook.com ([fe80::9c05:e282:840b:51a1%8]) with mapi id 15.20.1750.017; Sun, 31 Mar 2019 21:09:32 +0000 From: "Acee Lindem (acee)" To: Christian Hopps , Yingzhen Qu CC: Susan Hares , Rob Shakir , "lsr@ietf.org" , Tony Li Thread-Topic: [Lsr] When to augment LSR base YANG modules... Thread-Index: AQHU5gfd4acSIv/HVEeXIb5nGax0OaYiR5UAgAHQpQCAAGCBAIABU0mAgAA3DgCAACRggP//1YGA Date: Sun, 31 Mar 2019 21:09:32 +0000 Message-ID: <9FACB29E-7E8C-4FDB-B45F-9002AC891113@cisco.com> References: <2E6CA4AD-AD65-4A20-9545-1C81ED8B8968@tony.li> <080001d4e7cc$0b434690$21c9d3b0$@ndzh.com> <75095E67-2867-4466-B232-48E27DC47C9B@huawei.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=acee@cisco.com; x-originating-ip: [173.38.117.65] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e64df764-3ee3-4951-9523-08d6b61d2c0d x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BN6PR1101MB2337; x-ms-traffictypediagnostic: BN6PR1101MB2337: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 0993689CD1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(396003)(376002)(346002)(366004)(39860400002)(136003)(199004)(189003)(36756003)(26005)(6506007)(82746002)(6116002)(3846002)(66574012)(53546011)(99286004)(68736007)(2906002)(478600001)(305945005)(256004)(7736002)(14454004)(97736004)(71200400001)(83716004)(8936002)(5660300002)(81156014)(81166006)(106356001)(105586002)(8676002)(76176011)(966005)(54906003)(4326008)(110136005)(25786009)(71190400001)(33656002)(316002)(6436002)(6512007)(6306002)(6486002)(53936002)(66066001)(6246003)(476003)(2616005)(486006)(11346002)(229853002)(86362001)(93886005)(446003)(186003)(102836004); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR1101MB2337; H:BN6PR1101MB2226.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: SlHmTxxItThmUEE76b5TKWHUa2l+aQ14+GVN0nv7RW2uUgEzZRMZoXJ5nnGyTJjMkUXlLrxIJysa4d0VhKrYxtZTL036gTaf5IFq+SaHgIuvgdaTifzXWrzkYFaiKyXg5Vnw4ZpL4npX69ze28rrTcnI1JU9g8lSeHs/CeDhvOqi5k4Q7Cyv+w0rlfhGqHBHoAi3jnF2CWElopmKsgVALpU+XuoJrdZiSGi0wsO5dQgGyaCjqaJHmTbXKjjFjVFFoZAz0rEUmpndSk2SSZdTMxIXHqY1jU04xoOaMoyjutntfJTgY7Wa8mOIKCFqMjo90ZUqIrs2T7FZixR3rLU+0jMYam8gLX39stsXKUVbD0T52mMjtxrBvO0B4xb14j4gZjxL76VHyCB8KCzlimuKmbN7kWA3mdohlY0S/1+Pc6s= Content-Type: text/plain; charset="utf-8" Content-ID: <96001B5558D29541BD3A283D2391D3D4@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e64df764-3ee3-4951-9523-08d6b61d2c0d X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Mar 2019 21:09:32.5315 (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-Transport-CrossTenantHeadersStamped: BN6PR1101MB2337 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.27, xch-aln-017.cisco.com X-Outbound-Node: rcdn-core-6.cisco.com Archived-At: Subject: Re: [Lsr] When to augment LSR base YANG modules... X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2019 21:09:41 -0000 SGkgQ2hyaXMsIFlpbmd6aGVuLCANCg0KTGV0J3MgaGF2ZSBhIGRpc2N1c3Npb24gb24gWUFORyBk b2N0b3JzIGxpc3Qgb24gdGhlIG1lcml0cyBvZiBhIHNtYWxsIG1vZHVsZSBwZXIgZmVhdHVyZSB2 cyBhbiBhZ2dyZWdhdGUgbW9kZWwgd2l0aCBmZWF0dXJlcy4gDQoNCldlIGNhbiB0cnkgdGhpcyBh cyBhbiBleHBlcmltZW50LiBQZXJoYXBzLCB3ZSBjYW4gZ2V0IGEgcGVybWFuZW50IGRpc3BlbnNh dGlvbiB0byB0aGUgNSBhdXRob3IgcnVsZSBpZiBldmVyeSBkcmFmdCBuZWVkcyBzb21lb25lIFlB TkcgZmx1ZW50IGFuZCBmYW1pbGlhciB3aXRoIHRoZSBiYXNlIE9TUEYgYW5kIElTSVMgbW9kZWxz LiANCg0KVGhhbmtzLA0KQWNlZQ0KDQrvu79PbiAzLzMxLzE5LCAzOjQxIFBNLCAiQ2hyaXN0aWFu IEhvcHBzIiA8Y2hvcHBzQGNob3Bwcy5vcmc+IHdyb3RlOg0KDQogICAgDQogICAgDQogICAgPiBP biBNYXIgMzEsIDIwMTksIGF0IDE6MzEgUE0sIFlpbmd6aGVuIFF1IDx5aW5nemhlbi5xdUBodWF3 ZWkuY29tPiB3cm90ZToNCiAgICA+IA0KICAgID4gVGhlcmUgYXJlIG1hbnkgc21hbGwgZmVhdHVy ZSBkcmFmdHMgaW4gTFNSLCBmb3IgZXhhbXBsZTogaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9y Zy9kb2MvZHJhZnQtaWV0Zi1vc3BmLW9zcGZ2Mi1oYml0LyAgaXQgb25seSBhZGRzIEgtYml0IHRv IHJvdXRlci1sc2EuDQogICAgPiANCiAgICA+IEZvciBzdXJlIHdlIHdhbnQgbW9kZWxzIHRvIGJl IG1vZHVsYXIsIGJ1dCBub3QgdG9vIG1hbnkgdGlueSBwaWVjZXMuIE1heWJlIHdlIHNob3VsZCBj b21iaW5lIGEgZmV3IHNtYWxsIGZlYXR1cmVzIGxpa2UgSC1CaXQgaW50byBvbmUgbW9kdWxlPw0K ICAgIA0KICAgIEJ1dCB3aHk/DQogICAgDQogICAgRGVsYXlpbmcgdGhlIHB1YmxpY2F0aW9uIG9m IHRoZSBtYW5hZ2VtZW50IGRlZmluaXRpb24gdW50aWwgc29tZSAoc28gZmFyIGFzIEkgY2FuIHRl bGwpIGFyYml0cmFyeSBudW1iZXIgb2YgZmVhdHVyZXMgaGFzIGJlZW4gY29sbGVjdGVkIG5lZ2F0 aXZlbHkgaW1wYWN0cyB1c2Vycy4gV2hhdCBkbyB0aGV5IGdhaW4gaW4gcmV0dXJuPw0KICAgIA0K ICAgIFRoYW5rcywNCiAgICBDaHJpcy4NCiAgICANCiAgICA+IA0KICAgID4gVGhhbmtzLA0KICAg ID4gWWluZ3poZW4NCiAgICA+IA0KICAgID4gRnJvbTogTHNyIDxsc3ItYm91bmNlc0BpZXRmLm9y Zz4gb24gYmVoYWxmIG9mIFN1c2FuIEhhcmVzIDxzaGFyZXNAbmR6aC5jb20+DQogICAgPiBEYXRl OiBTdW5kYXksIE1hcmNoIDMxLCAyMDE5IGF0IDc6MTUgQU0NCiAgICA+IFRvOiAnUm9iIFNoYWtp cicgPHJqc0Byb2Iuc2g+LCAiJ0FjZWUgTGluZGVtIChhY2VlKSciIDxhY2VlQGNpc2NvLmNvbT4N CiAgICA+IENjOiAibHNyQGlldGYub3JnIiA8bHNyQGlldGYub3JnPiwgInRvbnkubGlAdG9ueS5s aSIgPHRvbnkubGlAdG9ueS5saT4sICdDaHJpc3RpYW4gSG9wcHMnIDxjaG9wcHNAY2hvcHBzLm9y Zz4NCiAgICA+IFN1YmplY3Q6IFJlOiBbTHNyXSBXaGVuIHRvIGF1Z21lbnQgTFNSIGJhc2UgWUFO RyBtb2R1bGVzLi4uDQogICAgPiANCiAgICA+IFJvYiBhbmQgQWNlZToNCiAgICA+IA0KICAgID4g SSBhZ3JlZSB0aGF0IHdpdGggUm9iIHRoYXQgaXQgaXMgYSBnZW5lcmljIHByb2JsZW0gdGhhdCB5 b3UgbXVzdCBoYXZlIGEgcm9idXN0IHdheSB0byB2ZXJzaW9uIGFuZCByZXZpc2UgdGhlIFlhbmcg bW9kZWxzLiAgIFRoaXMgaXMgdHJ1ZSBmb3IgY29uZmlndXJhdGlvbiwgb3BlcmF0aW9uYWwgZGF0 YSwgYW5kIGR5bmFtaWMgZGF0YSBzdG9yZXMuICAgVGhlIG5ldG1vZCBtb2RlbGluZyBpcyBmb2N1 c2luZyBvbiBjb25maWd1cmF0aW9uIGF0IHRoaXMgdGltZS4NCiAgICA+IA0KICAgID4gSXQgaXMg Y3JpdGljYWwgdG8gZGV0ZXJtaW5lIGhvdyB0aGUgYmFzZSBtb2RlbHMgeWFuZyBtb2RlbHMgcHJl cGFyZSBmb3IgYXVnbWVudGF0aW9ucy4gIE9TUEYsIElTSVMsIEJHUCwgRklCL1JJQiwgYW5kIHBv bGljeSBhcmUga2V5IG1vZGVscy4gICBTaW5jZSBvdXIgcHJvdG9jb2xzIGFyZSBhdWdtZW50ZWQg YmFzZWQgb24gY2FwYWJpbGl0aWVzLCBhdWdtZW50YXRpb24gYmFzZWQgb24gdGhlIHNhbWUgY2Fw YWJpbGl0aWVzIGZvciBtb2RlbHMgbWFrZXMgdGhlIG1vc3Qgc2Vuc2UuICAgV2UgY2FuIHJldmll dyBpbmZvL2RhdGEsIGFuZCBjb2RlIGZ1bmN0aW9uYWxpdHkgYmFzZWQgb24gdGhlIGtleSBzZW5z ZXMuDQogICAgPiANCiAgICA+IElmIHdlIGhhdmUgZ29vZCB2ZXJzaW9uaW5nIG9mIHRoZSBiYXNl IG1vZGVsLCBjYW4gcmV2aXNlIGJvdGggdGhlIGRhdGEgbW9kZWwgYW5kIHRoZSBjYXBhYmlsaXR5 IGluZGVwZW5kZW50bHkuICAgSWYgd2UgdXRpbGl6ZSB0aGUgZ3JvdXBpbmcgb2YgZGF0YSBtb2Rl bHMgYmFzZWQgb24gdGhlIHZlcnNpb25pbmcsIGF1dG9tYXRpYyBkZXBsb3ltZW50IG9mIHRoaXMg d29yayBjYW4gb2NjdXIuDQogICAgPiANCiAgICA+IEFjZWUgYW5kIENocmlzIGhhcyBiZWVuIGFj dGl2ZWx5IHBhcnRpY2lwYXRpbmcgb24gdGhlIHZlcnNpb25pbmcgZGlzY3Vzc2lvbiBpbiBuZXRt b2TigJlzIHdvcmsgb24gdmVyc2lvbmluZy4gICBJ4oCZbSBzdXJlIHRoZXkgY2FuIHJlcG9ydCBp ZiB0aGV5IGZlZWwgdGhlIHN1cHBvcnQgaGlzIHRoZXJlIGZvciB0aGlzIHR5cGUgb2YgdmVyc2lv bi4NCiAgICA+IA0KICAgID4gQkdQIGFuZCBydGd3ZyBjYW4gaW50ZWdyYXRlIHRoaXMgdHlwZSBv ZiB2ZXJzaW9uIHByaW9yIHRvIHRoZSB1cGNvbWluZyBXRyBMQy4NCiAgICA+IA0KICAgID4gU3Vl DQogICAgPiANCiAgICA+IA0KICAgID4gRnJvbTogTHNyIFttYWlsdG86bHNyLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBSb2IgU2hha2lyDQogICAgPiBTZW50OiBTYXR1cmRheSwgTWFy Y2ggMzAsIDIwMTkgMjowMCBQTQ0KICAgID4gVG86IEFjZWUgTGluZGVtIChhY2VlKQ0KICAgID4g Q2M6IGxzckBpZXRmLm9yZzsgdG9ueS5saUB0b255LmxpOyBDaHJpc3RpYW4gSG9wcHMNCiAgICA+ IFN1YmplY3Q6IFJlOiBbTHNyXSBXaGVuIHRvIGF1Z21lbnQgTFNSIGJhc2UgWUFORyBtb2R1bGVz Li4uDQogICAgPiANCiAgICA+IEkgdGhpbmsgdGhpcyBpcyBhIGdlbmVyaWMgY2hhbGxlbmdlIHRo YXQgaGFzIHRvIGJlIHNvbHZlZCBhY3Jvc3MgYWxsIHByb3RvY29scyAtLSBhbmQgcmVsaWVzIG9u IGEgcm9idXN0IHdheSB0byB2ZXJzaW9uIGFuZCByZXZpc2UgWUFORyBtb2R1bGVzIGluIHRoZSBJ RVRGLg0KICAgID4gDQogICAgPiBJbiBPcGVuQ29uZmlnLCBhcyB3ZSdyZSB2ZXJ5IGxpZ2h0d2Vp Z2h0IGZvciBwdXNoaW5nIGEgbmV3IHJldmlzaW9uLCBzaW5jZSB3ZSdyZSBqdXN0IHNwZWNpZnlp bmcgbmV3IHZlcnNpb25zIG9mIG1vZHVsZXMsIGFkZGluZyBuZXcgZmVhdHVyZXMgdG8gYW4gZXhp c3RpbmcgbW9kdWxlIGlzIHByZXR0eSB0cml2aWFsLiBUaGV5IGNhbiBiZSBkb25lIGFzIGEgbWlu b3IgcmV2aXNpb24gaWYgdGhlcmUncyBubyBiYWNrd2FyZHMgaW5jb21wYXRpYmxlIGNoYW5nZXMu ICBJdCBzZWVtcyBiZXR0ZXIsIHRvIG1lLCB0byBlbnN1cmUgdGhhdCB0aGVyZSBpcyBjb21tb24g bG9naWMgZm9yIGhvdyBvbmUgc3BsaXRzIHVwIG1vZHVsZXMsIHRvIG1ha2UgdGhpbmdzIGFjdHVh bGx5IHVzYWJsZSBmb3IgZGV2ZWxvcGVycyB0cnlpbmcgdG8gY29uc3VtZSB0aGVtLCByYXRoZXIg dGhhbiBuZWVkaW5nIHRvIHVuZGVyc3RhbmQgd2hlbiBhbmQgd2hlcmUgaW4gdGhlIElFVEYgYSBm ZWF0dXJlIHdhcyBkZXZlbG9wZWQuDQogICAgPiANCiAgICA+IFRoYXQgYmVpbmcgc2FpZCAtLSB0 aGlzIG1lYW5zIG9uZSBzaG91bGQgcHJvYmFibHkgZXhwZWN0IGVhY2ggTFNSIGJhc2UgbW9kdWxl IHRvIGJlIHJldmlzZWQgd2l0aCBtb3N0IG5ldyBMU1IgUkZDcy4gV2l0aCB0aGUgY3VycmVudCBh Z2lsaXR5IG9mIHRoZSByZXZpZXcgYW5kIHB1YmxpY2F0aW9uIHByb2Nlc3MgLS0gSSdtIG5vdCBz dXJlIHRoYXQgaXMgcmVhbGlzdGljIGVpdGhlci4NCiAgICA+IA0KICAgID4gci4NCiAgICA+IA0K ICAgID4gT24gU2F0LCAzMCBNYXIgMjAxOSBhdCAwOToxNSwgQWNlZSBMaW5kZW0gKGFjZWUpIDxh Y2VlQGNpc2NvLmNvbT4gd3JvdGU6DQogICAgPiBTcGVha2luZyBhcyBXRyBtZW1iZXI6DQogICAg PiANCiAgICA+IEZvciBtYW55IG9mIHRoZSBuZXcgTFNSIFdHIGRvY3VtZW50cywgd2UgYXJlIGFs cmVhZHkgaW5jbHVkZWQgYm90aCBPU1BGIGFuZCBJUy1JUyBlbmNvZGluZ3MgaW4gYSBzaW5nbGUg ZG9jdW1lbnQuIE5vdywgd2UgaGF2ZSBhZ3JlZWQgdGhhdCBkb2N1bWVudHMgcmVxdWlyaW5nIHNp bXBsZSBCR1AtTFMgY2hhbmdlcyB3aWxsIGFsc28gaW5jbHVkZSB0aGUgQkdQLUxTIGVuY29kaW5n LiBHaXZlbiB0aGlzLCBJIGRvbid0IHdhbnQgdG8gYWRkIGFub3RoZXIgcmVxdWlyZW1lbnQgZm9y IHB1YmxpY2F0aW9uIG9mIGEgV0cgZG9jdW1lbnQuIFRoaXMgd291bGQgYWxzbyBhZGQgYWRkaXRp b25hbCByZXZpZXdzIHRvIHRoZSBkb2N1bWVudC4gWW91J3ZlIGFsbCBoZWFyZCB0aGUgZXhwcmVz c2lvbiAiZGl2aWRlIGFuZCBjb25xdWVyIiwgd2hpbGUgbGV0IG1lIGludHJvZHVjZSB0aGUgY29y b2xsYXJ5LCAiY29uc29saWRhdGUgYW5kIHN0YWduYXRlIi4NCiAgICA+IA0KICAgID4gQWRkaXRp b25hbGx5LCBJIGFncmVlIHdpdGggWWluZ3poZW4ncyBjb21tZW50IHRoYXQgaXQgaXMgbm90IGNs ZWFyIHRoYXQgd2Ugd2FudCBhIHNlcGFyYXRlIFlBTkcgbW9kdWxlIGZvciBldmVyeSBPU1BGL0lT LUlTIGZlYXR1cmUuDQogICAgPiANCiAgICA+IFRoYW5rcywNCiAgICA+IEFjZWUNCiAgICA+IA0K ICAgID4gT24gMy8yOS8xOSwgNDozMyBBTSwgIkxzciBvbiBiZWhhbGYgb2YgdG9ueS5saUB0b255 LmxpIiA8bHNyLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9mIHRvbnkubGlAdG9ueS5saT4g d3JvdGU6DQogICAgPiANCiAgICA+IA0KICAgID4gICAgIENocmlzLA0KICAgID4gDQogICAgPiAg ICAgT25lIGNvbmNlcm4gaXMgc2ltcGx5IG9uZSBvZiBzY2FsZTogZG9pbmcgdGhpcyB3aWxsIGlu Y3JlYXNlIHRoZSBzaXplIG9mIHRoZSBkb2N1bWVudC4gIEF0IHdoYXQgcG9pbnQgZG8gdGhpbmdz IGJlY29tZSBzdWZmaWNpZW50bHkgYXdrd2FyZCB0aGF0IHdlIHdhbnQgdG8gaGF2ZSBhIHNlcGFy YXRlLCBjb25jdXJyZW50IGRvY3VtZW50Lg0KICAgID4gDQogICAgPiAgICAgSW4gb3RoZXIgd29y ZHMsIGlmIHRoZSByZXF1aXJlbWVudCBpcyBmb3IgY29uY3VycmVudCBkZWxpdmVyeSwgaXMgY28t bG9jYXRpb24gcmVhbGx5IGEgcmVxdWlyZW1lbnQ/DQogICAgPiANCiAgICA+ICAgICBSZWdhcmRz LA0KICAgID4gICAgIFRvbnkNCiAgICA+IA0KICAgID4gDQogICAgPiAgICAgPiBPbiBNYXIgMjks IDIwMTksIGF0IDk6MTcgQU0sIENocmlzdGlhbiBIb3BwcyA8Y2hvcHBzQGNob3Bwcy5vcmc+IHdy b3RlOg0KICAgID4gICAgID4NCiAgICA+ICAgICA+DQogICAgPiAgICAgPiBUaGUgYmFzZSBZQU5H IG1vZHVsZXMgZm9yIElTLUlTIGFuZCBPU1BGIGJvdGggaW5jbHVkZSBvcGVyYXRpb25hbCBzdGF0 ZSB0byBkZXNjcmliZSBUTFYgZGF0YS4gRHVyaW5nIHRoZSBkaXNjdXNzaW9uIGFib3V0IE9TUEZ2 MydzIHZlcnNpb24gb2YgdGhpcyBkYXRhLCBJIGJyb3VnaHQgdXAgdGhlIGlzc3VlIG9mIHdoZW4g YW5kIGhvdyB0aGUgYmFzZSBtb2R1bGVzIHNob3VsZCBiZSBhdWdtZW50ZWQgdG8gYWRkIG5ldyBU TFYgdHlwZXMgdG8gdGhlIG1vZGVsLCBzdWdnZXN0aW5nIGl0IGJlIGRvbmUgaW5saW5lIGFuZCB3 aXRoIHRoZSBSRkMgdGhhdCBhZGRzIHRoZSBuZXcgZmVhdHVyZS9mdW5jdGlvbmFsaXR5IHRvIHRo ZSBwcm90b2NvbC4NCiAgICA+ICAgICA+DQogICAgPiAgICAgPiBJJ2xsIGdvIGZhcnRoZXIgaGVy ZSBhbmQgc2F5IHRoaXMgc2hvdWxkIGFwcGx5IHRvIGFsbCB0aGUgWUFORyByZXF1aXJlZCBmb3Ig bWFuYWdlbWVudCBvZiB0aGUgbmV3IGZlYXR1cmUsIGFuZCBpdCBzaG91bGQgYWxsIGJlIGFkZGVk IGlubGluZSB3aXRoIHRoZSBmZWF0dXJlIChpLmUuLCBpbiB0aGUgc2FtZSBkcmFmdCkuIEluIG90 aGVyIHdvcmRzIG5ldyBmZWF0dXJlcy9mdW5jdGlvbmFsaXR5IHNob3VsZCBpbmNsdWRlIHRoZSBZ QU5HIGF1Z21lbnQgcmVxdWlyZWQgdG8gbWFuYWdlIHNhaWQgZmVhdHVyZXMvZnVuY3Rpb25hbGl0 eS4NCiAgICA+ICAgICA+DQogICAgPiAgICAgPiBUaGlzIGhhcyBiZWVuIHN1Z2dlc3RlZC90cmll ZCBwcmV2aW91c2x5IHdpdGggU05NUCB3aXRoIHZhcnlpbmcgKGxvdykgbGV2ZWxzIG9mIHN1Y2Nl c3MuIFRoZSBkaWZmZXJlbmNlIGhlcmUgaXMgMSkgWUFORyBhZGRpdGlvbnMgKGEgbmV3IG1vZHVs ZSBwZXJoYXBzIGp1c3QgYXVnbWVudGluZyB0aGUgYmFzZSkgaXMgZWFzeSwgd2hlcmVhcyBTTk1Q IHdhc24ndC4gQWRkaXRpb25hbGx5LCBvcGVyYXRvcnMgd2VyZW4ndCB1c2luZyBTTk1QIHRvIGZ1 bGx5IG1hbmFnZSBmdW5jdGlvbmFsaXR5IChlLmcuLCBub3QgZG9pbmcgY29uZmlndXJhdGlvbikg c28gYSByZXF1aXJlbWVudCBmb3IgZXh0cmEgd29yayB3YXMgaGFyZGVyIHRvIGp1c3RpZnkuIE9w ZXJhdG9ycyAqZG8qIHdhbnQgdG8gZnVsbHkgbWFuYWdlIHRoZWlyIG5ldHdvcmtzL3NlcnZlcnMg d2l0aCBZQU5HIHRob3VnaC4NCiAgICA+ICAgICA+DQogICAgPiAgICAgPiBUaGUgYXJndW1lbnQg YWdhaW5zdCB0aGlzIGR1cmluZyB0aGUgbWVldGluZyB3YXMgdGhhdCBpdCB3b3VsZCBjcmVhdGUg bWFueSBzbWFsbCBtb2R1bGVzLiBJIGRvbid0IGZpbmQgdGhpcyBjb21wZWxsaW5nIChpLmUuLCAi c28iPyA6KQ0KICAgID4gICAgID4NCiAgICA+ICAgICA+IEFzc3VtZSBJJ20gYW4gb3BlcmF0b3Ig LS0gdGhlIGFjdHVhbCBjb25zdW1lciBvZiB0aGlzIG1hbmFnZW1lbnQgc3R1ZmY6DQogICAgPiAg ICAgPg0KICAgID4gICAgID4gLSBJZiBJJ20gZ29pbmcgdG8gdXNlIHRoaXMgbmV3IGZlYXR1cmUg WCwgSSBuZWVkIHRvIGJlIGFibGUgdG8gbWFuYWdlIGl0LiBTbyBJIG5lZWQgaXQgWUFORyBmb3Ig aXQuIE5vdCBvbmx5IGRvIEkgbmVlZCBhbnkgbmV3IFRMViBkYXRhIGluIHRoZSBvcGVyYXRpb25h bCBzdGF0ZSwgYnV0IEkgbmVlZCB0aGUgY29uZmlndXJhdGlvbiBhbmQgYW55IG90aGVyIG9wZXJh dGlvbmFsIHN0YXRlIHJpZ2h0IGFsb25nIHdpdGggaXQuIE90aGVyd2lzZSBlYWNoIHZlbmRvciBo YXMgdG8gYWRkIG5ldyBZQU5HIHRvIHRoZWlyIHZlbmRvciBtb2R1bGVzLCBvciB0aGUgZmVhdHVy ZSBpcyB1c2VsZXNzIHRvIG1lLiBJIGNhbid0IHVzZSBzb21ldGhpbmcgaWYgSSBjYW4ndCB0dXJu IGl0IG9uLg0KICAgID4gICAgID4NCiAgICA+ICAgICA+IC0gSSBkb24ndCBjYXJlIGFib3V0IGhh dmluZyBtYW55IHNtYWxsZXIgbW9kdWxlcyB0aGF0IGF1Z21lbnQgdGhlIGJhc2UgbW9kdWxlIC0t IGF0IGFsbC4gUXVpdGUgdGhlIG9wcG9zaXRlIGFjdHVhbGx5LCB3aGVuIG5ldyBmdW5jdGlvbmFs aXR5IGlzIGFjY29tcGFuaWVkIGJ5IGl0J3Mgb3duIG1vZHVsZSBpdCBwcm92aWRlcyBtZSBhIHNp bXBsZSB3YXkgdG8gc2VlIGlmIHRoYXQgZnVuY3Rpb25hbGl0eSBpcyBwcmVzZW50IGFzIHRoZSBt b2R1bGUgd2lsbCBiZSBwcmVzZW50IGluIHRoZSBZQU5HIGNhcGFiaWxpdGllcyBhbm5vdW5jZWQg YnkgdGhlIGRldmljZS4NCiAgICA+ICAgICA+DQogICAgPiAgICAgPiBJJ2QgYmUgaW50ZXJlc3Rl ZCBpbiBoZWFyaW5nIHJlYXNvbnMgd2UgKGFzIGEgV0cpIHNob3VsZG4ndCBqdXN0IGV4cGVjdCBh IFlBTkcgbW9kdWxlIChldmVuIGlmIGl0J3Mgc21hbGwpIHRvIGJlIGluY2x1ZGVkIHdpdGggZHJh ZnRzIHRoYXQgYWRkIG5ldyBmdW5jdGlvbmFsaXR5Lg0KICAgID4gICAgID4NCiAgICA+ICAgICA+ IFRoYW5rcywNCiAgICA+ICAgICA+IENocmlzLg0KICAgID4gICAgID4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+ICAgICA+IExzciBtYWlsaW5n IGxpc3QNCiAgICA+ICAgICA+IExzckBpZXRmLm9yZw0KICAgID4gICAgID4gaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sc3INCiAgICA+IA0KICAgID4gICAgIF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQogICAgPiAgICAgTHNyIG1h aWxpbmcgbGlzdA0KICAgID4gICAgIExzckBpZXRmLm9yZw0KICAgID4gICAgIGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHNyDQogICAgPiANCiAgICA+IA0KICAgID4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+IExzciBt YWlsaW5nIGxpc3QNCiAgICA+IExzckBpZXRmLm9yZw0KICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9sc3INCiAgICA+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQogICAgPiBMc3IgbWFpbGluZyBsaXN0DQogICAgPiBMc3JA aWV0Zi5vcmcNCiAgICA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHNy DQogICAgDQogICAgDQoNCg== From nobody Sun Mar 31 15:00:29 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05BF112022A for ; Sun, 31 Mar 2019 15:00:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.503 X-Spam-Level: X-Spam-Status: No, score=-14.503 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Qt4qQoQi; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=nAEFyhjX 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 gaG_y5pJprvR for ; Sun, 31 Mar 2019 15:00:26 -0700 (PDT) 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 D37AA120225 for ; Sun, 31 Mar 2019 15:00:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3014; q=dns/txt; s=iport; t=1554069625; x=1555279225; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=S1adtrfvtnTSTEmwf9B64evkiXXwsIrUouUK7+0FYmw=; b=Qt4qQoQi9yN3LiZeuBNj9J1bPxWg5GiHendWbcONO7t8pCRpNSGRfmv8 AhNc8KBAWa25ONBxUoi32kc49ss72VD4nhWoh43KxsXaJJrtZq0R7liB1 E7//j9dwq0mqaYEkhANFDOFSzexMD7NVR++DhYQiB+eWhkRec+rnH7Uer E=; IronPort-PHdr: =?us-ascii?q?9a23=3Aj2JplBd5Z43PTf1LCjj4102mlGMj4e+mNxMJ6p?= =?us-ascii?q?chl7NFe7ii+JKnJkHE+PFxlwKUD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFl?= =?us-ascii?q?cejNkO2QkpAcqLE0r+effhYiESF8VZX1gj9Ha+YgBY?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ANAAAPN6Fc/5hdJa1jGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBUQYBAQELAYE9UAOBXAQLJwqEBINHA4RSimBKgWiXNIEuFIEQA1Q?= =?us-ascii?q?OAQEshEACF4UgIjQJDQEBAwEBCQEDAm0cDIVLBiMRDAEBOA8CAQgODAImAgI?= =?us-ascii?q?CMBUQAgQBEoMigV4DFQGdXAKKFHGBL4J5AQEFgkaCMxiCDAiBCyQBizIXgX+?= =?us-ascii?q?BEAEnDBOCTD6ELAKDIDGCJo0Di1+MC2AJApNeGoIDizaGc4s/gRiSNgIEAgQ?= =?us-ascii?q?FAg4BAQWBTTiBVnAVOyoBgkGCCoNuilNygSiOFAGBHgEB?= X-IronPort-AV: E=Sophos;i="5.60,294,1549929600"; d="scan'208";a="252382104" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 31 Mar 2019 22:00:24 +0000 Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by rcdn-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x2VM0OUh026386 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 31 Mar 2019 22:00:24 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 31 Mar 2019 17:00:24 -0500 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 31 Mar 2019 17:00:23 -0500 Received: from NAM02-BL2-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.1473.3 via Frontend Transport; Sun, 31 Mar 2019 17:00:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=S1adtrfvtnTSTEmwf9B64evkiXXwsIrUouUK7+0FYmw=; b=nAEFyhjXVUNoBeU6MZbBsPuAb2bmLzJb+RD4o30xTHZ9rk18pGyf81x8VvCvwZg7n139r26V+tPj850PEisJACJjhJxrLLD4a1cXVe+WwM7PqEdQ35rTizkllNgBMrGFiEanjv2bq/DeAbGAwbxY7s+ULlvNUwAagakXyTUByz0= Received: from BN6PR1101MB2226.namprd11.prod.outlook.com (10.174.112.11) by BN6PR1101MB2227.namprd11.prod.outlook.com (10.174.112.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.17; Sun, 31 Mar 2019 22:00:22 +0000 Received: from BN6PR1101MB2226.namprd11.prod.outlook.com ([fe80::9c05:e282:840b:51a1]) by BN6PR1101MB2226.namprd11.prod.outlook.com ([fe80::9c05:e282:840b:51a1%8]) with mapi id 15.20.1750.017; Sun, 31 Mar 2019 22:00:22 +0000 From: "Acee Lindem (acee)" To: Christian Hopps , "lsr@ietf.org" Thread-Topic: [Lsr] "unknown TLVs" in YANG data models Thread-Index: AQHU5//Kv0gcxLN43E+UAD+JsSxLR6YmBzeA Date: Sun, 31 Mar 2019 22:00:22 +0000 Message-ID: <068C6E29-B716-4137-AD71-8898F84285EB@cisco.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=acee@cisco.com; x-originating-ip: [173.38.117.65] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 253008c1-a937-4508-cec3-08d6b62445be x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600127)(711020)(4605104)(2017052603328)(7153060)(7193020); SRVR:BN6PR1101MB2227; x-ms-traffictypediagnostic: BN6PR1101MB2227: x-microsoft-antispam-prvs: x-forefront-prvs: 0993689CD1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(346002)(396003)(39860400002)(136003)(366004)(376002)(199004)(189003)(6486002)(229853002)(71190400001)(2616005)(106356001)(33656002)(86362001)(68736007)(6116002)(3846002)(105586002)(446003)(11346002)(81156014)(81166006)(8676002)(53936002)(8936002)(486006)(6506007)(76176011)(476003)(305945005)(14454004)(25786009)(26005)(14444005)(99286004)(7736002)(97736004)(5660300002)(82746002)(478600001)(2501003)(256004)(6246003)(102836004)(36756003)(2906002)(110136005)(186003)(83716004)(66066001)(316002)(6436002)(6512007)(71200400001)(170073001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN6PR1101MB2227; H:BN6PR1101MB2226.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: cD6ys0ZmzMwvYPh9GqusAJ3mKiYIG86jnVBf79NMKDUbdwj7o21HSwHgU1NwvncU5gIMA0kv/22zaLSRqntqKUm+RCRUPPmuhXUBQAS6zMJqms0+3VUkwn8c1ppvi/UjDasJWNVhpQZBYf+TETl4GjpHiZEXIdCrg/DxdPzdapcAJ3D5n1ymin8nGy6thCQ7KgtA+LCkYPCUIVf9gesx+Ai7J6PDA8EPALmAS2WT3Xxxhy2Kq/HL7vr2e+J3GfhV9tcza4A1XDsk5fonQ5hGVCNcQQCse6cAkL2tMrPjYLKPNeTws8NJMxlfZCcWnwkf7KQRkFiao05a5Ys/boMeGxjbhDJ7skCJB7c8GCgUqkulTY1T82njX1HBaTYxzgoyo9Q4RI3vxpFoh2Vz5MlxD1CdvMEPNaAv9dR4/V9fz9M= Content-Type: text/plain; charset="utf-8" Content-ID: <899FC496BF8D3F41B930A86BFD2A50F2@namprd11.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 253008c1-a937-4508-cec3-08d6b62445be X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Mar 2019 22:00:22.2962 (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-Transport-CrossTenantHeadersStamped: BN6PR1101MB2227 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.23, xch-rcd-013.cisco.com X-Outbound-Node: rcdn-core-1.cisco.com Archived-At: Subject: Re: [Lsr] "unknown TLVs" in YANG data models X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2019 22:00:28 -0000 SGkgQ2hyaXMsDQoNCu+7v09uIDMvMzEvMTksIDQ6MjQgUE0sICJMc3Igb24gYmVoYWxmIG9mIENo cmlzdGlhbiBIb3BwcyIgPGxzci1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBjaG9wcHNA Y2hvcHBzLm9yZz4gd3JvdGU6DQoNCiAgICBTbyB0aGlzIGNhbWUgdXAgZHVyaW5nIHRoZSBzZWNv bmQgc2Vzc2lvbiBhdCBJRVRGMTA0LiBPdXIgYmFzZSBZQU5HIGRhdGEgbW9kZWxzIGhhdmUgImJh a2VkIiByZXByZXNlbnRhdGlvbnMgb2YgVExWIGRhdGEgYW5kIHRoZW4gYSBjYXRjaCBhbGwgInVu a25vd24gdGx2IiBsaXN0IGZvciB0aGUgdW5yZWNvZ25pemVkIGRhdGEuDQogICAgDQogICAgV2hl biBhIG5ldyBmZWF0dXJlIGlzIGFkZGVkIHRoYXQgYWRkcyBhIG5ldyBUTFZzIGl0IHdvdWxkIHNl ZW0gb2J2aW91cyB0byBhbHNvIGFkZCBhbiBhdWdtZW50YXRpb24gdG8gdGhlIGJhc2UgbW9kZWwg dG8gcHJvdmlkZSBhIHNpbWlsYXIgImJha2VkIiB2ZXJzaW9uIG9mIHRoZSBuZXcgVExWIGRhdGEu IEhvd2V2ZXIsIGRvZXMgdGhpcyBub3cgbWVhbiB0aGF0IHRoZSBUTFYgaXMgbm8gbG9uZ2VyICJ1 bmtub3duIj8gSXMgdGhlIGRhdGEgcmVtb3ZlZCBmcm9tIHRoZSB1bmtub3duIGxpc3Qgb3IganVz dCBwcmVzZW50IGluIGJvdGggY2FzZXM/DQoNCklmIHRoZSBkZXZpY2Ugc3VwcG9ydHMgdGhlIG5l dyBmZWF0dXJlLCBpdCBpcyBubyBsb25nZXIgdW5rbm93biBhbmQgcmVtb3ZlZC4gDQoNCiAgICAN CiAgICBUaGlua2luZyBhYm91dCB0aGlzIG1hZGUgbWUgcmVhbGl6ZSB0aGUgZm9sbG93aW5nOiBJ dCdzIHZlcnkgY29tbW9uIHRvIHdhbnQgdG8gZ2V0ICphbGwqIHRoZSBUTFYgZGF0YSBpbiByYXcg Zm9ybS4gV2l0aCB0aGUgY3VycmVudCBkZXNpZ24gdGhlIGNsaWVudCBoYXMgdG8gc2V0dGxlIGZv ciByZXZlcnNlIGVuZ2luZWVyaW5nIHRoZSBiYWtlZCBkYXRhIGluIGFkZGl0aW9uIHRvIHB1bGxp bmcgdGhlIFRMViBkYXRhIGZyb20gdGhlIHVua25vd24gbGlzdC4NCg0KV2UgYWxyZWFkeSBwcm92 aWRlIHRoZSB3aG9sZSBMU0EgaW4gInJhdyIgZm9ybWF0IGRvIHRoZSBkYXRhIGlzIHRoZXJlLiAN CiAgICANCiAgICBBIG1vcmUgZnVuY3Rpb25hbCBjaG9pY2UgaXMgdG8gc2ltcGx5IGhhdmUgdGhl ICJ1bmtub253bi10bHYiIGxpc3QgcmV0dXJuICphbGwqIHRoZSBUTFYgZGF0YS4gV2hldGhlciBh IFRMViBpcyAia25vd24iIChpLmUuLCBhIGJha2VkIHZlcnNpb24gaXMgcHJlc2VudCkgdG8gdGhl IHNlcnZlciBpcyBhbHJlYWR5IGluZGljYXRlZCBieSBsb29raW5nIGF0IHRoZSBzZXJ2ZXJzIHJl cG9ydGVkIGNhcGFiaWxpdGllcy4NCg0KV2VsbCwgdGhpcyB3b3VsZCBiZSBhIDNyZCByZXByZXNl bnRhdGlvbiBvZiB0aGUgc2FtZSBkYXRhLiBBbHNvLCBub3RlIHRoYXQgVExWcyBjYW4gYmUgbmVz dGVkIHNvIHRoaXMgd291bGQgYmUgYXBwbGllZCByZWN1cnNpdmVseS4gSSBrbm93IHRoYXQgSVMt SVMgb25seSBuZXN0cyB0d28gbGV2ZWwgYW5kIHJlZmVycyB0byB0aGUgbGF0dGVyIGFzIHN1Yi1z dWItVExWLiBPU1BGIGRvZXNuJ3QgaGF2ZSB0aGlzIGxpbWl0YXRpb24uIA0KICAgIA0KICAgIEF0 IGxlYXN0IHdpdGggdGhlIElTLUlTIG1vZHVsZSB0aGlzIGNvdWxkIGJlIGEgbWlub3IgY2hhbmdl IChyZW5hbWUgInVua25vd24tdGx2cyIgdG8gInRsdnMiIGFuZCB1cGRhdGUgdGhlIGRlc2NyaXB0 aW9uKS4gSSBiZWxpZXZlIHRoZSBjaGFuZ2UgaXMgYWxzbyBzaW1pbGFybHkgbWlub3IgZm9yIE9T UEYgYXMgd2VsbC4NCg0KUmlnaHQgLSBvbmx5IGl0IHdvdWxkIGJlIGFwcGxpZWQgYXQgZWFjaCBs ZXZlbC4gRm9yIGV4YW1wbGUsIGEgVExWcyB3b3VsZCBoYXZlIGEgcmF3IGxpc3Qgb2Ygc3ViLVRM VnMuIA0KICAgIA0KICAgIEl0IHdvdWxkIGJlIG5pY2UsIGlmIHBlb3BsZSBhZ3JlZSwgYW5kIGFn cmVlIGl0cyBub3QgdG9vIGxhdGUsIHRvIG1ha2UgdGhpcyBjaGFuZ2Ugbm93IHJhdGhlciB0aGFu IHdhaXQgZm9yIHRoZSBJRVNHL0lFVEYgTEMgdG8gY29tcGxldGUgYW5kIHRoZW4gaGF2ZSB0byBk byBhIEJJUyB1cGRhdGUuDQoNCkknbSBub3Qgb3Bwb3NlZCB0aG91Z2ggSSdkIGFzayB3aHkgdGhl IHJhdyBMU0EgZm9ybWF0IHdvdWxkIG5vdCBzdWZmaWNlLiANCg0KVGhhbmtzLA0KQWNlZQ0KICAg IA0KICAgIFRoYW5rcywNCiAgICBDaHJpcy4NCiAgICANCg0K From nobody Sun Mar 31 16:32:23 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A131120013 for ; Sun, 31 Mar 2019 16:32:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 L-IVP0KTtPfN for ; Sun, 31 Mar 2019 16:32:20 -0700 (PDT) Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id BC040120004 for ; Sun, 31 Mar 2019 16:32:19 -0700 (PDT) Received: from stubbs.int.chopps.org (047-050-069-038.biz.spectrum.com [47.50.69.38]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 194B5604D2; Sun, 31 Mar 2019 19:32:19 -0400 (EDT) From: Christian Hopps Message-Id: Content-Type: multipart/signed; boundary="Apple-Mail=_06A1AE70-74F6-4A6E-9A3E-2C9C3843877E"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Sun, 31 Mar 2019 19:32:18 -0400 In-Reply-To: <068C6E29-B716-4137-AD71-8898F84285EB@cisco.com> Cc: Christian Hopps , "lsr@ietf.org" To: "Acee Lindem (acee)" References: <068C6E29-B716-4137-AD71-8898F84285EB@cisco.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Lsr] "unknown TLVs" in YANG data models X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2019 23:32:22 -0000 --Apple-Mail=_06A1AE70-74F6-4A6E-9A3E-2C9C3843877E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 31, 2019, at 6:00 PM, Acee Lindem (acee) = wrote: >=20 > Hi Chris, >=20 > =EF=BB=BFOn 3/31/19, 4:24 PM, "Lsr on behalf of Christian Hopps" = wrote: >=20 > So this came up during the second session at IETF104. Our base YANG = data models have "baked" representations of TLV data and then a catch = all "unknown tlv" list for the unrecognized data. >=20 > When a new feature is added that adds a new TLVs it would seem = obvious to also add an augmentation to the base model to provide a = similar "baked" version of the new TLV data. However, does this now mean = that the TLV is no longer "unknown"? Is the data removed from the = unknown list or just present in both cases? >=20 > If the device supports the new feature, it is no longer unknown and = removed. >=20 >=20 > Thinking about this made me realize the following: It's very common = to want to get *all* the TLV data in raw form. With the current design = the client has to settle for reverse engineering the baked data in = addition to pulling the TLV data from the unknown list. >=20 > We already provide the whole LSA in "raw" format do the data is there. OK, I didn't see the entire LSP was included in raw format. Well, that's = a bit more work for the client, but the data is still available, so = probably not worth the late change. Thanks, Chris. >=20 >=20 > A more functional choice is to simply have the "unknonwn-tlv" list = return *all* the TLV data. Whether a TLV is "known" (i.e., a baked = version is present) to the server is already indicated by looking at the = servers reported capabilities. >=20 > Well, this would be a 3rd representation of the same data. Also, note = that TLVs can be nested so this would be applied recursively. I know = that IS-IS only nests two level and refers to the latter as sub-sub-TLV. = OSPF doesn't have this limitation. >=20 > At least with the IS-IS module this could be a minor change (rename = "unknown-tlvs" to "tlvs" and update the description). I believe the = change is also similarly minor for OSPF as well. >=20 > Right - only it would be applied at each level. For example, a TLVs = would have a raw list of sub-TLVs. >=20 > It would be nice, if people agree, and agree its not too late, to = make this change now rather than wait for the IESG/IETF LC to complete = and then have to do a BIS update. >=20 > I'm not opposed though I'd ask why the raw LSA format would not = suffice. >=20 > Thanks, > Acee >=20 > Thanks, > Chris. >=20 >=20 --Apple-Mail=_06A1AE70-74F6-4A6E-9A3E-2C9C3843877E Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEm56yH/NF+m1FHa6lLh2DDte4MCUFAlyhTgIACgkQLh2DDte4 MCWxNQ//ecLDzMUy4bDY1QIuRjzeF5NbXuBj9digD7hdDaorvPaW/oPPo+JVJtYv N/0He9yUiuDJ7bwGUjvO+yqNamoIY4sQziAr+C3YcfCtlW9xucq9JgM2QlQzG8bK xSilaWKSc00H+KO/tN3HKv8PQeMJeaibewUXuIR1VGebGj0MYwEpzCzqY+F4KsC0 97tC8668QeI/XRh/9mN1Rwf7T5n+H/FeB4M6eZT6YqHs1P3LRoTOh5PwHKoI5DvX W+WbFrpa6mQc57wIABViXqgI+qN6ZkcBEWfuqu1T5LZlgS1pts9E4fA7l+NlCifE 2gnOdGa0I3rwpXiLy3AVr777VNuDUqT28Rp8mfJF32ARojyuZkg6inYBmE6FrIkA M0cvh20X2FClEWX8QxVbZz8UGP2fM7YMFIF5SAAWLodwNLg7Ji7EvGV4EyU5SHq9 wbwqELBurzg/3uF9kGvJX/batdL9KHvuJg6iOvjRdDET5VrIyGEk54hS94na8cmW fCRCk0EgAMBhAyks1hwC6+xt2hhd6obhNafzp47ftZybrJrQU6y8vYBAqyW+I4ck KWHJmwrO1aNu+pmqCO3JH11swel7KRq4fqXlFQ05Jg133vUbSWlekrFUFKyiCSQ3 Zrd8PypTbE4bsyWLg5h3sTwYnz6Aa24vAgItMeI303Ehu391pTs= =mPzI -----END PGP SIGNATURE----- --Apple-Mail=_06A1AE70-74F6-4A6E-9A3E-2C9C3843877E-- From nobody Sun Mar 31 16:34:47 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 57A8A1201BE for ; Sun, 31 Mar 2019 16:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=bL3tdNQ5; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=BMOZfe12 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 olALpwXgbHXf for ; Sun, 31 Mar 2019 16:34:43 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C2E3120004 for ; Sun, 31 Mar 2019 16:34:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4270; q=dns/txt; s=iport; t=1554075283; x=1555284883; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=3CT8unrS2yIMoq3hH0VLlDhjpmc42I7WxGVizGlWwg0=; b=bL3tdNQ5iQXvX8M6g7iArb85HdeoQiObTjPq6GRR5MUbRmN2o7l5B4Xm zAflbt9SQzRn8zRHaLHpPqPuf8ANu+PWEaBeu3/Q5asiWtbrpTVFHX5Yy uVNuRIXF4aCpI0c8vDTeE5DaBnZ7UK7Q6s6Tq/4eU/qmFapDI9mlDTTbs Y=; IronPort-PHdr: =?us-ascii?q?9a23=3Arc2bwBB98gzgz1OmDvcWUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qs03kTRU9Dd7PRJw6rNvqbsVHZIwK7JsWtKMfkuHw?= =?us-ascii?q?QAld1QmgUhBMCfDkiuI//sdCY3BstqX15+9Hb9Ok9QS47z?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAAA3TaFc/4oNJK1jGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBPVADaHQECyeEDoNHA4RSimBKgg2XD4EuFIE?= =?us-ascii?q?QA1QOAQEYCwmEQAIXhSAiNAkNAQEDAQEJAQMCbRwMhUoBAQEEAQEhEQwBASw?= =?us-ascii?q?MCwQCAQgRBAEBAQICJgICAiULFQgIAgQBEgiDG4FdAxUBAgydLQKKFHGBL4J?= =?us-ascii?q?5AQEFhHkYggwDBYELJAGLMheBQD+BEAFGgkw+gmEBAYE7DgIYJIJkMYImjQO?= =?us-ascii?q?LX4wLYAkCk3iCA4s2hnOLP4EYkjYCBAIEBQIOAQEFgU04gVZwFTuCbIIKDBe?= =?us-ascii?q?DS4UUhT9ygSiMZ4JMAQE?= X-IronPort-AV: E=Sophos;i="5.60,294,1549929600"; d="scan'208";a="545127824" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 31 Mar 2019 23:34:41 +0000 Received: from XCH-ALN-003.cisco.com (xch-aln-003.cisco.com [173.36.7.13]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x2VNYerq004189 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 31 Mar 2019 23:34:40 GMT Received: from xhs-rtp-001.cisco.com (64.101.210.228) by XCH-ALN-003.cisco.com (173.36.7.13) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 31 Mar 2019 18:34:39 -0500 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.1473.3; Sun, 31 Mar 2019 19:34:38 -0400 Received: from NAM03-DM3-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sun, 31 Mar 2019 18:34:38 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=3CT8unrS2yIMoq3hH0VLlDhjpmc42I7WxGVizGlWwg0=; b=BMOZfe12vHoDCMxZB7PRK3d+hhCFhOvLG5xeKpQBcXxtub3mV3WlqBq7rtHkUAU7txEP45jo7Uuk1nWKgpqfdBmV8Vwrm05I2XhP6gynewLZ2z5drd2fwkbDT3m4/8+Ww/B4PROT+6KHL57O9L1wxaeeS4KcyNXCAOcmolZKGKs= Received: from BYAPR11MB3638.namprd11.prod.outlook.com (20.178.237.19) by BYAPR11MB3222.namprd11.prod.outlook.com (20.177.127.215) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.17; Sun, 31 Mar 2019 23:34:37 +0000 Received: from BYAPR11MB3638.namprd11.prod.outlook.com ([fe80::28ae:a91c:f4fd:15cb]) by BYAPR11MB3638.namprd11.prod.outlook.com ([fe80::28ae:a91c:f4fd:15cb%4]) with mapi id 15.20.1750.017; Sun, 31 Mar 2019 23:34:37 +0000 From: "Les Ginsberg (ginsberg)" To: "Acee Lindem (acee)" , Christian Hopps , "lsr@ietf.org" Thread-Topic: [Lsr] "unknown TLVs" in YANG data models Thread-Index: AQHU5//KRfIJWWrksE2jHATlIvBgh6YmSkYAgAAZAIA= Date: Sun, 31 Mar 2019 23:34:37 +0000 Message-ID: References: <068C6E29-B716-4137-AD71-8898F84285EB@cisco.com> In-Reply-To: <068C6E29-B716-4137-AD71-8898F84285EB@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ginsberg@cisco.com; x-originating-ip: [2001:420:c0c8:1008::92] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c9ca6ec4-001d-46d9-05b5-08d6b631703b x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600139)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:BYAPR11MB3222; x-ms-traffictypediagnostic: BYAPR11MB3222: x-ms-exchange-purlcount: 1 x-microsoft-antispam-prvs: x-forefront-prvs: 0993689CD1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(366004)(376002)(346002)(396003)(39860400002)(13464003)(189003)(199004)(8676002)(316002)(446003)(6306002)(478600001)(55016002)(46003)(105586002)(14454004)(11346002)(229853002)(110136005)(7696005)(966005)(486006)(71200400001)(6246003)(71190400001)(8936002)(2906002)(6436002)(76176011)(86362001)(25786009)(5660300002)(7736002)(476003)(305945005)(53936002)(2501003)(14444005)(97736004)(186003)(6506007)(106356001)(81156014)(68736007)(81166006)(256004)(6116002)(9686003)(102836004)(52536014)(99286004)(33656002)(53546011)(74316002)(170073001); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3222; H:BYAPR11MB3638.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: TdZz68tEsGP5TZhCHNNQ71aGNK6k8rydnuulqk7Rd9kDghr8UFWFk9FvRxp3lPiR1q5gndIYgoEKI9udhKrvjmCpIGlSeBkXihuRB0ZwdTUfxdECTBud4oWiuysLc7dA28fiFm4geiJRY7TM6/j07wJ2rLNDR5DpKO0AgU8xveswD4WCHSLLW4ZJMdnURKpMdUqveprCeaw4JjzkIrF/LxGMlGTxDSooX/Jp1YnHDsRO4moPlyutvAkK85x59dbjgVsKbqUsCt7IH/llKvwGKLixamh8DnXcIJcBao3aOyXTKCRAjvSk2c07x2QgnLusu4+AVFf9bxmVjkp6uf8ORax8Kh5Yn4+kvoHVAn6x70jzGKrkfECr97lg38dBOmCYzgAuVa2G5hNLQebMhJy30MLR+AIbUkx1/b831RVFOl4= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c9ca6ec4-001d-46d9-05b5-08d6b631703b X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Mar 2019 23:34:37.0341 (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-Transport-CrossTenantHeadersStamped: BYAPR11MB3222 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.13, xch-aln-003.cisco.com X-Outbound-Node: alln-core-5.cisco.com Archived-At: Subject: Re: [Lsr] "unknown TLVs" in YANG data models X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2019 23:34:45 -0000 QWNlZSAtDQoNCkEgbWlub3IgY29ycmVjdGlvbi4gDQpJUy1JUyBoYXMgbm8gbGltaXQgdG8gdGhl IG51bWJlciBvZiBsZXZlbHMgIlRMVnMiIGNhbiBiZSBuZXN0ZWQuIFRoZSBtb3N0IHdlIGhhdmUg bmVlZGVkIHRodXMgZmFyIGlzIDIgKGkuZS4sIHN1Yi1zdWItVExWKSAtIGJ1dCB0aGVyZSBpcyBu byBwcm90b2NvbCBsaW1pdGF0aW9uLiANClRoYXQgc2FpZCwgSSBkbyBub3QgZW5jb3VyYWdlIGRl ZXAgbmVzdGluZyAtIEkgYW0gbm90IHRocmlsbGVkIHRvIGhhdmUgc3ViLXN1Yi1UTFZzIC0gYnV0 IHdoZW4gaXQgbWFrZXMgc2Vuc2UgdGhlbiB3ZSBkZWZpbmUgdGhlbS4NCg0KSSBkbyBhZ3JlZSB3 aXRoIHlvdSB0aGF0ICJyYXciIHNlZW1zIHRvIGJlIHN1ZmZpY2llbnQgdG8gY292ZXIgInVua25v d24iIGFzIHdlbGwuDQoNCiAgIExlcw0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0N Cj4gRnJvbTogTHNyIDxsc3ItYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIEFjZWUgTGlu ZGVtIChhY2VlKQ0KPiBTZW50OiBTdW5kYXksIE1hcmNoIDMxLCAyMDE5IDM6MDAgUE0NCj4gVG86 IENocmlzdGlhbiBIb3BwcyA8Y2hvcHBzQGNob3Bwcy5vcmc+OyBsc3JAaWV0Zi5vcmcNCj4gU3Vi amVjdDogUmU6IFtMc3JdICJ1bmtub3duIFRMVnMiIGluIFlBTkcgZGF0YSBtb2RlbHMNCj4gDQo+ IEhpIENocmlzLA0KPiANCj4g77u/T24gMy8zMS8xOSwgNDoyNCBQTSwgIkxzciBvbiBiZWhhbGYg b2YgQ2hyaXN0aWFuIEhvcHBzIiA8bHNyLQ0KPiBib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBv ZiBjaG9wcHNAY2hvcHBzLm9yZz4gd3JvdGU6DQo+IA0KPiAgICAgU28gdGhpcyBjYW1lIHVwIGR1 cmluZyB0aGUgc2Vjb25kIHNlc3Npb24gYXQgSUVURjEwNC4gT3VyIGJhc2UgWUFORyBkYXRhDQo+ IG1vZGVscyBoYXZlICJiYWtlZCIgcmVwcmVzZW50YXRpb25zIG9mIFRMViBkYXRhIGFuZCB0aGVu IGEgY2F0Y2ggYWxsDQo+ICJ1bmtub3duIHRsdiIgbGlzdCBmb3IgdGhlIHVucmVjb2duaXplZCBk YXRhLg0KPiANCj4gICAgIFdoZW4gYSBuZXcgZmVhdHVyZSBpcyBhZGRlZCB0aGF0IGFkZHMgYSBu ZXcgVExWcyBpdCB3b3VsZCBzZWVtIG9idmlvdXMNCj4gdG8gYWxzbyBhZGQgYW4gYXVnbWVudGF0 aW9uIHRvIHRoZSBiYXNlIG1vZGVsIHRvIHByb3ZpZGUgYSBzaW1pbGFyICJiYWtlZCINCj4gdmVy c2lvbiBvZiB0aGUgbmV3IFRMViBkYXRhLiBIb3dldmVyLCBkb2VzIHRoaXMgbm93IG1lYW4gdGhh dCB0aGUgVExWIGlzDQo+IG5vIGxvbmdlciAidW5rbm93biI/IElzIHRoZSBkYXRhIHJlbW92ZWQg ZnJvbSB0aGUgdW5rbm93biBsaXN0IG9yIGp1c3QNCj4gcHJlc2VudCBpbiBib3RoIGNhc2VzPw0K PiANCj4gSWYgdGhlIGRldmljZSBzdXBwb3J0cyB0aGUgbmV3IGZlYXR1cmUsIGl0IGlzIG5vIGxv bmdlciB1bmtub3duIGFuZA0KPiByZW1vdmVkLg0KPiANCj4gDQo+ICAgICBUaGlua2luZyBhYm91 dCB0aGlzIG1hZGUgbWUgcmVhbGl6ZSB0aGUgZm9sbG93aW5nOiBJdCdzIHZlcnkgY29tbW9uIHRv DQo+IHdhbnQgdG8gZ2V0ICphbGwqIHRoZSBUTFYgZGF0YSBpbiByYXcgZm9ybS4gV2l0aCB0aGUg Y3VycmVudCBkZXNpZ24gdGhlIGNsaWVudA0KPiBoYXMgdG8gc2V0dGxlIGZvciByZXZlcnNlIGVu Z2luZWVyaW5nIHRoZSBiYWtlZCBkYXRhIGluIGFkZGl0aW9uIHRvIHB1bGxpbmcgdGhlDQo+IFRM ViBkYXRhIGZyb20gdGhlIHVua25vd24gbGlzdC4NCj4gDQo+IFdlIGFscmVhZHkgcHJvdmlkZSB0 aGUgd2hvbGUgTFNBIGluICJyYXciIGZvcm1hdCBkbyB0aGUgZGF0YSBpcyB0aGVyZS4NCj4gDQo+ ICAgICBBIG1vcmUgZnVuY3Rpb25hbCBjaG9pY2UgaXMgdG8gc2ltcGx5IGhhdmUgdGhlICJ1bmtu b253bi10bHYiIGxpc3QgcmV0dXJuDQo+ICphbGwqIHRoZSBUTFYgZGF0YS4gV2hldGhlciBhIFRM ViBpcyAia25vd24iIChpLmUuLCBhIGJha2VkIHZlcnNpb24gaXMNCj4gcHJlc2VudCkgdG8gdGhl IHNlcnZlciBpcyBhbHJlYWR5IGluZGljYXRlZCBieSBsb29raW5nIGF0IHRoZSBzZXJ2ZXJzIHJl cG9ydGVkDQo+IGNhcGFiaWxpdGllcy4NCj4gDQo+IFdlbGwsIHRoaXMgd291bGQgYmUgYSAzcmQg cmVwcmVzZW50YXRpb24gb2YgdGhlIHNhbWUgZGF0YS4gQWxzbywgbm90ZSB0aGF0DQo+IFRMVnMg Y2FuIGJlIG5lc3RlZCBzbyB0aGlzIHdvdWxkIGJlIGFwcGxpZWQgcmVjdXJzaXZlbHkuIEkga25v dyB0aGF0IElTLUlTDQo+IG9ubHkgbmVzdHMgdHdvIGxldmVsIGFuZCByZWZlcnMgdG8gdGhlIGxh dHRlciBhcyBzdWItc3ViLVRMVi4gT1NQRiBkb2Vzbid0DQo+IGhhdmUgdGhpcyBsaW1pdGF0aW9u Lg0KPiANCj4gICAgIEF0IGxlYXN0IHdpdGggdGhlIElTLUlTIG1vZHVsZSB0aGlzIGNvdWxkIGJl IGEgbWlub3IgY2hhbmdlIChyZW5hbWUNCj4gInVua25vd24tdGx2cyIgdG8gInRsdnMiIGFuZCB1 cGRhdGUgdGhlIGRlc2NyaXB0aW9uKS4gSSBiZWxpZXZlIHRoZSBjaGFuZ2UgaXMNCj4gYWxzbyBz aW1pbGFybHkgbWlub3IgZm9yIE9TUEYgYXMgd2VsbC4NCj4gDQo+IFJpZ2h0IC0gb25seSBpdCB3 b3VsZCBiZSBhcHBsaWVkIGF0IGVhY2ggbGV2ZWwuIEZvciBleGFtcGxlLCBhIFRMVnMgd291bGQg aGF2ZQ0KPiBhIHJhdyBsaXN0IG9mIHN1Yi1UTFZzLg0KPiANCj4gICAgIEl0IHdvdWxkIGJlIG5p Y2UsIGlmIHBlb3BsZSBhZ3JlZSwgYW5kIGFncmVlIGl0cyBub3QgdG9vIGxhdGUsIHRvIG1ha2Ug dGhpcw0KPiBjaGFuZ2Ugbm93IHJhdGhlciB0aGFuIHdhaXQgZm9yIHRoZSBJRVNHL0lFVEYgTEMg dG8gY29tcGxldGUgYW5kIHRoZW4gaGF2ZQ0KPiB0byBkbyBhIEJJUyB1cGRhdGUuDQo+IA0KPiBJ J20gbm90IG9wcG9zZWQgdGhvdWdoIEknZCBhc2sgd2h5IHRoZSByYXcgTFNBIGZvcm1hdCB3b3Vs ZCBub3Qgc3VmZmljZS4NCj4gDQo+IFRoYW5rcywNCj4gQWNlZQ0KPiANCj4gICAgIFRoYW5rcywN Cj4gICAgIENocmlzLg0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IExzciBtYWlsaW5nIGxpc3QNCj4gTHNyQGlldGYub3JnDQo+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHNyDQo= From nobody Sun Mar 31 16:47:39 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C31F1201A3 for ; Sun, 31 Mar 2019 16:47:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=czZ0x8Fp; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=DbXOzPbD 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 SHHjuYjobDQL for ; Sun, 31 Mar 2019 16:47:34 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9102A120073 for ; Sun, 31 Mar 2019 16:47:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4364; q=dns/txt; s=iport; t=1554076054; x=1555285654; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=ej5Omyzu+si6mBFEmbZoLXrnOJldlTSGKpY2SrEqT1k=; b=czZ0x8FpnK0OPgF8v0aLys4Pybmzu/scg4GGlFJ5XQTF/4XuQBf0MJX3 S/EFAJ977Sa5Jl6OU1etZahn7O7rZ70iv/Pr/frYuaDmmQAc767aC3YuJ OVsRZRoIm2MUdaSSkJHcoVG2SdwlczCS+DBONux3Pv7aUyN07aHU8Ry1J A=; IronPort-PHdr: =?us-ascii?q?9a23=3A9kSexxZIrhsaQ7iAL6B3Bcr/LSx94ef9IxIV55?= =?us-ascii?q?w7irlHbqWk+dH4MVfC4el20gabRp3VvvRDjeee87vtX2AN+96giDgDa9QNMn?= =?us-ascii?q?1NksAKh0olCc+BB1f8KavlbiohFslYW3du/mqwNg5eH8OtL1A=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAADGUKFc/4MNJK1jGgEBAQEBAgE?= =?us-ascii?q?BAQEHAgEBAQGBUQUBAQEBCwGBPVADaHQECyeEDoNHA4RSimBKgg2JOI1XgS6?= =?us-ascii?q?BJANUDgEBGAsJhEACF4UgIjQJDQEBAwEBCQEDAm0cDIVKAQEBBAEBIREMAQE?= =?us-ascii?q?sCQMLBAIBBgIRBAEBAwImAgICHwYLFQgIAgQBEgiDG4FdAxUBAgyMSJBeAoo?= =?us-ascii?q?UcYEvgnkBAQWBNQIOQYJzDQuCDAiBCyQBizIXgUA/gRBHgkw+ghpHAQECAQG?= =?us-ascii?q?BXySCZDGCJopcgieEQZNTNgkCh2+IL4NaggNdhS+MHYs/hhGBPIwBAgQCBAU?= =?us-ascii?q?CDgEBBYFNOIFWcBUaIYJsCYIBg26FFIU/coEojzMBAQ?= X-IronPort-AV: E=Sophos;i="5.60,294,1549929600"; d="scan'208";a="323459095" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 31 Mar 2019 23:47:32 +0000 Received: from XCH-RCD-017.cisco.com (xch-rcd-017.cisco.com [173.37.102.27]) by alln-core-1.cisco.com (8.15.2/8.15.2) with ESMTPS id x2VNlWQY023518 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Sun, 31 Mar 2019 23:47:32 GMT Received: from xhs-rtp-003.cisco.com (64.101.210.230) by XCH-RCD-017.cisco.com (173.37.102.27) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 31 Mar 2019 18:47:32 -0500 Received: from xhs-rcd-001.cisco.com (173.37.227.246) by xhs-rtp-003.cisco.com (64.101.210.230) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 31 Mar 2019 19:47:31 -0400 Received: from NAM01-BY2-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-001.cisco.com (173.37.227.246) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Sun, 31 Mar 2019 18:47:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ej5Omyzu+si6mBFEmbZoLXrnOJldlTSGKpY2SrEqT1k=; b=DbXOzPbDL056yDO2IlQg9JKIQYrw0H7yepBbNY0if8gUMU9FBS2ziTfb8aPJVPneuXDze2DKu7W0vAYIJJj/LCGAU4DuTuHVL0/P9cLaGP5H3HgjIguACwMUlpo9YLz3DMIiw02kyocNZJjVdOG2Z+dYfWe07/Xjd0v69jRJQb4= Received: from BYAPR11MB3638.namprd11.prod.outlook.com (20.178.237.19) by BYAPR11MB3095.namprd11.prod.outlook.com (20.177.227.77) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.17; Sun, 31 Mar 2019 23:47:29 +0000 Received: from BYAPR11MB3638.namprd11.prod.outlook.com ([fe80::28ae:a91c:f4fd:15cb]) by BYAPR11MB3638.namprd11.prod.outlook.com ([fe80::28ae:a91c:f4fd:15cb%4]) with mapi id 15.20.1750.017; Sun, 31 Mar 2019 23:47:29 +0000 From: "Les Ginsberg (ginsberg)" To: "7riw77@gmail.com" <7riw77@gmail.com>, "lsr@ietf.org" Thread-Topic: [Lsr] FW: New Version Notification for draft-white-distoptflood-00.txt Thread-Index: AQLwM/JIkPbzT8Vkdbi80JHv2Wjy+aPvl4FQgAA2U4A= Date: Sun, 31 Mar 2019 23:47:29 +0000 Message-ID: References: <155406381670.12357.17272312414769230549.idtracker@ietfa.amsl.com> <04bf01d4e7ff$e16d7230$a4485690$@gmail.com> In-Reply-To: <04bf01d4e7ff$e16d7230$a4485690$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ginsberg@cisco.com; x-originating-ip: [2001:420:c0c8:1008::92] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 0ccb5142-b361-412b-4b88-08d6b6333c6b x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600139)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:BYAPR11MB3095; x-ms-traffictypediagnostic: BYAPR11MB3095: x-ms-exchange-purlcount: 6 x-microsoft-antispam-prvs: x-forefront-prvs: 0993689CD1 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(39860400002)(346002)(366004)(376002)(396003)(199004)(189003)(13464003)(81156014)(6436002)(53546011)(478600001)(66574012)(102836004)(110136005)(5660300002)(6506007)(6306002)(256004)(99286004)(966005)(33656002)(106356001)(7696005)(105586002)(55016002)(14454004)(14444005)(53936002)(52536014)(68736007)(9686003)(186003)(15650500001)(8676002)(6116002)(6246003)(2906002)(486006)(76176011)(11346002)(8936002)(476003)(305945005)(71190400001)(71200400001)(316002)(7736002)(2501003)(46003)(446003)(81166006)(25786009)(74316002)(86362001)(97736004)(229853002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3095; H:BYAPR11MB3638.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: RjYrApTD7Af8wnU7j2WE8IwVNAhKP+2DTUZQJuxUxYje12uol//LqoB56p3AIyqFuXVeVocS94m1jW45ZFr+X/l3NtOgnxLx5m0W4kxIiXAqmVlG1bTAUhQFPJSGTRgXTG3BG73Hx+S+W9yAs/Aq7QUnKGVeA445WBH917UmJ1Ol6jzQAuzweLpZGnnq/U0/PaLW8yRDNX/1vEkdsOjUdbUiH0oKLWrDtACdZDTSmGsoqUD93IsVud930Ia+cSS6Kvp2YRFVlhGdK+700+0hc7Gux/GtlmQqOkvH3VdVBImrr4HCTE356gAejQ9zJ2dtdMn+ZTtun3wFsk7jcCnsHrXhyVkoXDeEpvzu9N39IzbnqhepxIAyrcDKXXEvtL7BWDbhY4n/p1T0Nc8Iq/KSg2E93YJSri/BQ5lHxRWn8L4= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 0ccb5142-b361-412b-4b88-08d6b6333c6b X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Mar 2019 23:47:29.0794 (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-Transport-CrossTenantHeadersStamped: BYAPR11MB3095 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.27, xch-rcd-017.cisco.com X-Outbound-Node: alln-core-1.cisco.com Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-white-distoptflood-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 31 Mar 2019 23:47:38 -0000 UnVzcyAtDQoNClRoZSBXRyBqdXN0IHdlbnQgdGhyb3VnaCBhIGxlbmd0aHkgY29uc2lkZXJhdGlv biBvZiBtdWx0aXBsZSBmbG9vZGluZyBvcHRpbWl6YXRpb24gZHJhZnRzIGFuZCBzZWxlY3RlZCBo dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWxzci1keW5hbWljLWZs b29kaW5nLyBhcyB0aGUgdmVoaWNsZSBmb3IgdGhlIFdHIHRvIHVzZSB0byBtb3ZlIGZvcndhcmQg aW4gdGhpcyBhcmVhLg0KDQpJdCB3b3VsZCBiZSBnb29kIGlmLCBpbiB0aGUgY29udGV4dCBvZiB0 aGUgYWJvdmUsIHlvdSBhcnRpY3VsYXRlZCB3aHkgaXQgbWFrZXMgc2Vuc2UgZm9yIHRoZSBXRyB0 byBkbyB5ZXQgYW5vdGhlciByb3VuZCBvZiBzdWNoIGRpc2N1c3Npb24uIA0KDQooRnVsbCBkaXNj bG9zdXJlOiBJIGFtIGEgY28tYXV0aG9yIG9uIGRyYWZ0LWlldGYtbHNyLWR5bmFtaWMtZmxvb2Rp bmcgLSBidXQgbXkgcXVlc3Rpb24gaXNuJ3QgY29taW5nIGZyb20gdGhhdCBwZXJzcGVjdGl2ZS4g KQ0KDQogICBMZXMNCg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IExz ciA8bHNyLWJvdW5jZXNAaWV0Zi5vcmc+IE9uIEJlaGFsZiBPZiA3cml3NzdAZ21haWwuY29tDQo+ IFNlbnQ6IFN1bmRheSwgTWFyY2ggMzEsIDIwMTkgMToyNSBQTQ0KPiBUbzogbHNyQGlldGYub3Jn DQo+IFN1YmplY3Q6IFtMc3JdIEZXOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0 LXdoaXRlLWRpc3RvcHRmbG9vZC0NCj4gMDAudHh0DQo+IA0KPiANCj4gRllJIC0tIEkndmUgcHV0 IGp1c3QgdGhlIGZsb29kaW5nIG9wdGltaXphdGlvbnMgZnJvbSB0aGUgb3BlbmZhYnJpYyB3b3Jr IGludG8gYQ0KPiBzZXBhcmF0ZSBkcmFmdCBhbmQgc3VibWl0dGVkIGl0LiBJJ3ZlIGFsc28gbW9k aWZpZWQgdGhlIHdvcmRpbmcgYSBiaXQsIGFzIHRoaXMgaXMNCj4gYXBwbGljYWJsZSBmYXIgYmV5 b25kIGRhdGEgY2VudGVyIGZhYnJpY3MuDQo+IA0KPiDwn5iKIC9yDQo+IA0KPiA+IC0tLS0tT3Jp Z2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIDxp bnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc+DQo+ID4gU2VudDogU3VuZGF5LCBNYXJjaCAzMSwgMjAx OSA0OjI0IFBNDQo+ID4gVG86IFNoYXduIFphbmRpIDxzemFuZGlAbGlua2VkaW4uY29tPjsgUnVz cyBXaGl0ZSA8cnVzc0ByaXcudXM+DQo+ID4gU3ViamVjdDogTmV3IFZlcnNpb24gTm90aWZpY2F0 aW9uIGZvciBkcmFmdC13aGl0ZS1kaXN0b3B0Zmxvb2QtMDAudHh0DQo+ID4NCj4gPg0KPiA+IEEg bmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC13aGl0ZS1kaXN0b3B0Zmxvb2QtMDAudHh0IGhhcyBi ZWVuIHN1Y2Nlc3NmdWxseQ0KPiA+IHN1Ym1pdHRlZCBieSBSdXNzIFdoaXRlIGFuZCBwb3N0ZWQg dG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCj4gPg0KPiA+IE5hbWU6CQlkcmFmdC13aGl0ZS1kaXN0 b3B0Zmxvb2QNCj4gPiBSZXZpc2lvbjoJMDANCj4gPiBUaXRsZToJCUlTLUlTIE9wdGltYWwgRGlz dHJpYnV0ZWQgRmxvb2RpbmcgZm9yIERlbnNlIFRvcG9sb2dpZXMNCj4gPiBEb2N1bWVudCBkYXRl OgkyMDE5LTAzLTMxDQo+ID4gR3JvdXA6CQlJbmRpdmlkdWFsIFN1Ym1pc3Npb24NCj4gPiBQYWdl czoJCTEzDQo+ID4gVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2ludGVybmV0 LWRyYWZ0cy9kcmFmdC13aGl0ZS1kaXN0b3B0Zmxvb2QtDQo+ID4gMDAudHh0DQo+ID4gU3RhdHVz OiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LXdoaXRlLWRp c3RvcHRmbG9vZC8NCj4gPiBIdG1saXplZDogICAgICAgaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LXdoaXRlLWRpc3RvcHRmbG9vZC0wMA0KPiA+IEh0bWxpemVkOiAgICAgICBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LXdoaXRlLQ0KPiBkaXN0b3B0 Zmxvb2QNCj4gPg0KPiA+DQo+ID4gQWJzdHJhY3Q6DQo+ID4gICAgRGVuc2UgdG9wb2xvZ2llcywg c3VjaCBhcyBkYXRhIGNlbnRlciBmYWJyaWNzIGJhc2VkIG9uIHRoZSBDbG9zIGFuZA0KPiA+ICAg IGJ1dHRlcmZseSBmYWJyaWMgdG9wb2xvZ2llcy4gIEZsb29kaW5nIG1lY2hhbmlzbXMgZGVzaWdu ZWQgZm9yIHNwYXJzZQ0KPiA+ICAgIHRvcG9sb2dpZXMsIHdoZW4gdXNlZCBpbiB0aGVzZSBkZW5z ZSB0b3BvbG9naWVzLCBjYW4gcmVzdWx0IGluIHNsb3dlcg0KPiA+ICAgIGNvbnZlcmdlbmNlIHRp bWVzIGFuZCBoaWdoZXIgcmVzb3VyY2UgdXRpbGl6YXRpb24uICBUaGUgbW9kaWZpY2F0aW9ucw0K PiA+ICAgIHRvIHRoZSBmbG9vZGluZyBtZWNoYW5pc20gaW4gdGhlIEludGVybWVkaWF0ZSBTeXN0 ZW0gdG8gSW50ZXJtZWRpYXRlDQo+ID4gICAgU3lzdGVtIChJUy1JUykgbGluayBzdGF0ZSBwcm90 b2NvbCBkZXNjcmliZWQgaW4gdGhpcyBkb2N1bWVudCByZWR1Y2UNCj4gPiAgICByZXNvdXJjZSB1 dGlsaXphdGlvbiB0byBhIG1pbmltdW0sIHdoaWxlIGluY3JlYXNlaW5nIGNvbnZlcmdlbmNlDQo+ ID4gICAgcGVyZm9ybWFuY2UgaW4gZGVuc2UgdG9wb2xvZ2llcy4NCj4gPg0KPiA+ICAgIE5vdGUg dGhhdCBhIENsb3MgZmFicmljIGlzIHVzZWQgYXMgdGhlIHByaW1hcnkgZXhhbXBsZSBvZiBhIGRl c25lDQo+ID4gICAgZmxvb2RpbmcgdG9wb2xvZ3kgdGhyb3VnaG91dCB0aGlzIGRvY3VtZW50LiAg SG93ZXZlciwgdGhlIGZsb29kaW5nDQo+ID4gICAgb3B0aW1pemF0aW9ucyBkZXNjcmliZWQgaW4g dGhpcyBkb2N1bWVudCBhcHBseSB0byBhbnkgZGVuc2UgdG9wb2xvZ3kuDQo+ID4NCj4gPg0KPiA+ DQo+ID4NCj4gPiBQbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0 ZXMgZnJvbSB0aGUgdGltZSBvZg0KPiBzdWJtaXNzaW9uDQo+ID4gdW50aWwgdGhlIGh0bWxpemVk IHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCj4gPg0K PiA+IFRoZSBJRVRGIFNlY3JldGFyaWF0DQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gTHNyIG1haWxpbmcgbGlzdA0KPiBMc3JAaWV0 Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9sc3INCg== From nobody Sun Mar 31 18:18:09 2019 Return-Path: <7riw77@gmail.com> X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA26E120041 for ; Sun, 31 Mar 2019 18:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-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 v_r0841DjEdc for ; Sun, 31 Mar 2019 18:18:06 -0700 (PDT) Received: from mail-ot1-x332.google.com (mail-ot1-x332.google.com [IPv6:2607:f8b0:4864:20::332]) (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 1F04A120013 for ; Sun, 31 Mar 2019 18:18:06 -0700 (PDT) Received: by mail-ot1-x332.google.com with SMTP id t8so7018655otp.7 for ; Sun, 31 Mar 2019 18:18:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language; bh=ZpbHrgcQWQF0/r8CE4/fO21CCT+o+RHrhSb+VjQUZ8A=; b=NSZLyjk75M7lGZ3CXc7bdJz6xifIQaSfk1PS8Z2U+VzPc7jIZMfEKCl2SjC2KI2I7l K1IBvizyE0eJhXXMIeglgvGPYnVuAtGWmztrlfUWEic3RlEOjggLg8kA5NE2rcTvnjLS 1anxHl7avCqm3exEnJF3IUk8/70apfI5zSBGwB2zSIxvEnvcJQB4HkX5PJhngM4DZw56 dl/BSuJjWc2RCY6TuKMShejNf9+IuYX7NPIoFTJ7C+tAQsam255hnom88R6SfQMW7EsH lZ3LiA3B2c6UxgS6Y8Zzp4WYZV3EJvHrY5sLuoQUe3aEajcCDnZTQpOE/eSzfCHvbumS Ibng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=ZpbHrgcQWQF0/r8CE4/fO21CCT+o+RHrhSb+VjQUZ8A=; b=WhN12MbGHa5322NqaT68hOJWvpTP/HDrhjJofXXYbhUq0Ei63zgUM/TSunN/Ma3M+C NpQWBcssZVI1lw0VMxl17EUyRExfHLkvFSJk/K3pqD+jg1kee2KkKSiVGcL1ElmD/2gm QgV0SIOY3hz3vbTzy4Q956HH0re0o81LGYrXwg3xUG4lW5IeDIdNWKD7Ixthqk++Hmv/ v31fhM9FgkuomQesDGmP78hSwRefUyYGBLpThoXx2M0lTPB4gO2PFxh72v1gUhJdXHXk LCysEw1cf9I5hCtp2pQK9zlcjKIJ1HenkTslzLmI6kJHglPEa2KBf3TruGdjHBXuv3ww +2XA== X-Gm-Message-State: APjAAAU67Hg81j8kJPkpIOFGYbMhpv5eaFpIGOe08GAeMdeKqR8zlnuU nDKBVBYWjAkfcBZeyZXCS9U= X-Google-Smtp-Source: APXvYqz4LPvzovsdfH96NVO+brV8HOhO/hLIhWTHEcoJ/baXo9A+t6USCOPjn3JBhqLk7HtMuFvtVQ== X-Received: by 2002:a9d:7e91:: with SMTP id m17mr16962839otp.78.1554081485429; Sun, 31 Mar 2019 18:18:05 -0700 (PDT) Received: from RussPC ([2600:1700:720:1050::440]) by smtp.gmail.com with ESMTPSA id v24sm3408005oic.32.2019.03.31.18.18.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 31 Mar 2019 18:18:05 -0700 (PDT) From: <7riw77@gmail.com> To: "'Les Ginsberg \(ginsberg\)'" , References: <155406381670.12357.17272312414769230549.idtracker@ietfa.amsl.com> <04bf01d4e7ff$e16d7230$a4485690$@gmail.com> In-Reply-To: Date: Sun, 31 Mar 2019 21:18:04 -0400 Message-ID: <073101d4e828$c2209c80$4661d580$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQLwM/JIkPbzT8Vkdbi80JHv2Wjy+QFj45+JAYMdoeSj2LEcUA== Content-Language: en-us Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-white-distoptflood-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2019 01:18:08 -0000 > The WG just went through a lengthy consideration of multiple flooding > optimization drafts and selected = https://datatracker.ietf.org/doc/draft-ietf- > lsr-dynamic-flooding/ as the vehicle for the WG to use to move forward = in > this area. Yep. > It would be good if, in the context of the above, you articulated why = it makes > sense for the WG to do yet another round of such discussion. =3D=3D In this idea, the flooding topology is computed within an IGP area with the dense topology either centrally on an elected node, termed the Area Leader, or in a distributed manner on all nodes that are supporting Dynamic Flooding. =3D=3D Because this is only one way to solve the problem... The process = outlined in the draft I just published is a different and simpler way = that applies to a wider range of topologies than the dynamic flooding = draft does, afaict.=20 =F0=9F=98=8A /r=20 From nobody Sun Mar 31 18:55:57 2019 Return-Path: X-Original-To: lsr@ietfa.amsl.com Delivered-To: lsr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 65CD91200EC for ; Sun, 31 Mar 2019 18:55:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.502 X-Spam-Level: X-Spam-Status: No, score=-14.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, 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=TMLHRzMH; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=T8heZAF/ 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 x4L5q64DtxQh for ; Sun, 31 Mar 2019 18:55:53 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 208C812006F for ; Sun, 31 Mar 2019 18:55:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2710; q=dns/txt; s=iport; t=1554083753; x=1555293353; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=XtH8IJfwIKl3DNjvZ9rwwKEWTWKwPSCXM3vIgu/IGTU=; b=TMLHRzMH9Hd20elAuiAEmuhDIELqox70dVKBtoy6KefQvbOlk5kvWJ/i 8IIeZ7/9MI4kqzYBI7euE1sxSiJXD6piF8aozi06uvfLZS6O2hpGEhDWN xCoUYx+XShzedEpp9+GiAA3UjF9SQ5bhW8SjvfEmyxKRzCOjRR8QrrJ2+ w=; IronPort-PHdr: =?us-ascii?q?9a23=3AkoWaPRIwangoctirENmcpTVXNCE6p7X5OBIU4Z?= =?us-ascii?q?M7irVIN76u5InmIFeBvKd2lFGcW4Ld5roEkOfQv636EU04qZea+DFnEtRXUg?= =?us-ascii?q?Mdz8AfngguGsmAXEL6KuXgYjY1NM9DT1RiuXq8NBsdFQ=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ANAAB5bqFc/5FdJa1jGwEBAQEDAQE?= =?us-ascii?q?BBwMBAQGBUQYBAQELAYE9UANodAQLJ4QOg0cDhFKKYIJXiTiNV4EugSQDVA4?= =?us-ascii?q?BARgLCYRAAheFICI0CQ0BAQMBAQkBAwJtHAyFSgEBAQEDAQEhEQwBASwJAws?= =?us-ascii?q?EAgEGAhEEAQEDAiYCAgIfBgsVCAgCBAESCIMbgV0DFQECDIw1kF4CihRxgS+?= =?us-ascii?q?CeQEBBYFFQYJzDQuCDAMFgQskAYsyF4FAP4FXgkw+ghpHAQECAQGBX4MIMYI?= =?us-ascii?q?mjQOLdoweNgkCh2+IL4NaggOGDIwdiz+GEYE8jAECBAIEBQIOAQEFgU04gVZ?= =?us-ascii?q?wFTuCbIIKg26FFIU/coEojzMBAQ?= X-IronPort-AV: E=Sophos;i="5.60,294,1549929600"; d="scan'208";a="252963581" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Apr 2019 01:55:51 +0000 Received: from XCH-ALN-008.cisco.com (xch-aln-008.cisco.com [173.36.7.18]) by rcdn-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id x311tpqY017777 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 1 Apr 2019 01:55:51 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-ALN-008.cisco.com (173.36.7.18) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 31 Mar 2019 20:55:50 -0500 Received: from xhs-aln-001.cisco.com (173.37.135.118) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Sun, 31 Mar 2019 20:55:50 -0500 Received: from NAM02-CY1-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.1473.3 via Frontend Transport; Sun, 31 Mar 2019 20:55:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector1-cisco-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=XtH8IJfwIKl3DNjvZ9rwwKEWTWKwPSCXM3vIgu/IGTU=; b=T8heZAF/ue/9zmXp2agUTnL8rBboxR+T3NmSV41Jc5xyVbEBu+PEcTnR9lJlQHU6VwVAG2zidDF03Ah8vdyhILrBLqyB8L0UcZyEks1UO2GcjhvUYAdbt9Oz2SowsPQl/vAitVHIB7es0TH1nDq+mtx76+Q54vSzoNgE8W+D2zA= Received: from BYAPR11MB3638.namprd11.prod.outlook.com (20.178.237.19) by BYAPR11MB3526.namprd11.prod.outlook.com (20.177.227.24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1750.20; Mon, 1 Apr 2019 01:55:49 +0000 Received: from BYAPR11MB3638.namprd11.prod.outlook.com ([fe80::28ae:a91c:f4fd:15cb]) by BYAPR11MB3638.namprd11.prod.outlook.com ([fe80::28ae:a91c:f4fd:15cb%4]) with mapi id 15.20.1750.017; Mon, 1 Apr 2019 01:55:49 +0000 From: "Les Ginsberg (ginsberg)" To: "7riw77@gmail.com" <7riw77@gmail.com>, "lsr@ietf.org" Thread-Topic: [Lsr] FW: New Version Notification for draft-white-distoptflood-00.txt Thread-Index: AQLwM/JIkPbzT8Vkdbi80JHv2Wjy+aPvl4FQgAA2U4CAABvKAIAACRpw Date: Mon, 1 Apr 2019 01:55:49 +0000 Message-ID: References: <155406381670.12357.17272312414769230549.idtracker@ietfa.amsl.com> <04bf01d4e7ff$e16d7230$a4485690$@gmail.com> <073101d4e828$c2209c80$4661d580$@gmail.com> In-Reply-To: <073101d4e828$c2209c80$4661d580$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=ginsberg@cisco.com; x-originating-ip: [2001:420:c0c8:1008::92] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 539b4fe0-e868-4d6b-cc57-08d6b6452a59 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600139)(711020)(4605104)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7153060)(7193020); SRVR:BYAPR11MB3526; x-ms-traffictypediagnostic: BYAPR11MB3526: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-forefront-prvs: 0994F5E0C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(396003)(39860400002)(136003)(376002)(346002)(199004)(189003)(13464003)(14454004)(99286004)(316002)(478600001)(2501003)(2906002)(97736004)(7736002)(6246003)(33656002)(25786009)(52536014)(106356001)(53936002)(966005)(55016002)(6306002)(9686003)(8936002)(7696005)(81166006)(81156014)(8676002)(5660300002)(6116002)(46003)(93886005)(476003)(11346002)(71200400001)(71190400001)(6506007)(53546011)(446003)(102836004)(186003)(256004)(105586002)(486006)(68736007)(14444005)(15650500001)(76176011)(86362001)(74316002)(229853002)(110136005)(305945005)(6436002); DIR:OUT; SFP:1101; SCL:1; SRVR:BYAPR11MB3526; H:BYAPR11MB3638.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: rREzQxJ9UlC1Tz0CeDVzXd39vO2swQ2H1y83rVMcQ6gTeDP2Ajy9dj7HA3q/0+QrLhdSNWX2odVMkOr3P/igAVproriZ8KuqEi9ci6B2wSkNvZ7KhF1bS8x2Dglv5xj+ds6o+osInoBpR6VdSYAQy0HFIzkW2OuMWMNGUW1+MWMs0K+5ERVVL1oFRzLYpw/UX283gmDivmlnX+nBrGFltaZleJxPhOg4jYA2TDB6IsxoCDI0YnWWL0vpb62tlUqmlQOvmbOhVrQ4WqY94o5PphOrWynSfc0ORgn/4pZ77ybwrJWqa0Kr7fip2UMvKvsI7BjudHaFz9tHJE23bjGbq8KYWAGeOayL7RUxeKX2wRh7rfEy27pbF5lI52I93JInTjsJfjS+/7MI5cqnPBJZ/ZM0MCi/5lSoK478aB+MGl8= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 539b4fe0-e868-4d6b-cc57-08d6b6452a59 X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2019 01:55:49.7769 (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-Transport-CrossTenantHeadersStamped: BYAPR11MB3526 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.36.7.18, xch-aln-008.cisco.com X-Outbound-Node: rcdn-core-9.cisco.com Archived-At: Subject: Re: [Lsr] FW: New Version Notification for draft-white-distoptflood-00.txt X-BeenThere: lsr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Routing Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2019 01:55:56 -0000 UnVzcyAtDQoNClBsZWFzZSBzdGF0ZSBleHBsaWNpdGx5IHdoZXRoZXIgeW91IHdhbnQ6DQoNCmEp VGhpcyBkcmFmdCB0byBiZSBjb25zaWRlcmVkIGJ5IHRoZSBXRyBpbiBhZGRpdGlvbiB0byBkcmFm dC1pZXRmLWxzci1keW5hbWljLWZsb29kaW5nIChpLmUuLCB3ZSBzaG91bGQgd29yayBvbiBib3Ro IGRyYWZ0cyBpbiBwYXJhbGxlbCkNCg0KYilUaGlzIGRyYWZ0IHRvIGJlIGNvbnNpZGVyZWQgYXMg YSByZXBsYWNlbWVudCBmb3IgZHJhZnQtaWV0Zi1sc3ItZHluYW1pYy1mbG9vZGluZyAoaS5lLiwg d2Ugc2hvdWxkIGFiYW5kb24gd29yayBvbiBkcmFmdC1pZXRmLWxzci1keW5hbWljLWZsb29kaW5n IGFuZCBpbnN0ZWFkIHdvcmsgb24gdGhpcyBkcmFmdCkNCg0KYylZb3Ugd2FudCB0aGUgaWRlYXMg YXJ0aWN1bGF0ZWQgaW4gdGhpcyBkcmFmdCB0byBiZSBpbmNvcnBvcmF0ZWQgaW50byBkcmFmdC1p ZXRmLWxzci1keW5hbWljLWZsb29kaW5nDQoNCihhbmQgcGxlYXNlIGRvbid0IHNheSAiaXQgZG9l c24ndCBtYXR0ZXIiIC0gYmVjYXVzZSBpdCBjZXJ0YWlubHkgZG9lcyBtYXR0ZXIgOi0pICkNCg0K VGhhbnguDQoNCiAgIExlcw0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJv bTogTHNyIDxsc3ItYm91bmNlc0BpZXRmLm9yZz4gT24gQmVoYWxmIE9mIDdyaXc3N0BnbWFpbC5j b20NCj4gU2VudDogU3VuZGF5LCBNYXJjaCAzMSwgMjAxOSA2OjE4IFBNDQo+IFRvOiBMZXMgR2lu c2JlcmcgKGdpbnNiZXJnKSA8Z2luc2JlcmdAY2lzY28uY29tPjsgbHNyQGlldGYub3JnDQo+IFN1 YmplY3Q6IFJlOiBbTHNyXSBGVzogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC13 aGl0ZS1kaXN0b3B0Zmxvb2QtDQo+IDAwLnR4dA0KPiANCj4gDQo+ID4gVGhlIFdHIGp1c3Qgd2Vu dCB0aHJvdWdoIGEgbGVuZ3RoeSBjb25zaWRlcmF0aW9uIG9mIG11bHRpcGxlIGZsb29kaW5nDQo+ ID4gb3B0aW1pemF0aW9uIGRyYWZ0cyBhbmQgc2VsZWN0ZWQgaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtDQo+IGlldGYtDQo+ID4gbHNyLWR5bmFtaWMtZmxvb2RpbmcvIGFz IHRoZSB2ZWhpY2xlIGZvciB0aGUgV0cgdG8gdXNlIHRvIG1vdmUgZm9yd2FyZCBpbg0KPiA+IHRo aXMgYXJlYS4NCj4gDQo+IFllcC4NCj4gDQo+ID4gSXQgd291bGQgYmUgZ29vZCBpZiwgaW4gdGhl IGNvbnRleHQgb2YgdGhlIGFib3ZlLCB5b3UgYXJ0aWN1bGF0ZWQgd2h5IGl0DQo+IG1ha2VzDQo+ ID4gc2Vuc2UgZm9yIHRoZSBXRyB0byBkbyB5ZXQgYW5vdGhlciByb3VuZCBvZiBzdWNoIGRpc2N1 c3Npb24uDQo+IA0KPiA9PQ0KPiBJbiB0aGlzIGlkZWEsIHRoZSBmbG9vZGluZyB0b3BvbG9neSBp cyBjb21wdXRlZCB3aXRoaW4gYW4gSUdQIGFyZWENCj4gICAgd2l0aCB0aGUgZGVuc2UgdG9wb2xv Z3kgZWl0aGVyIGNlbnRyYWxseSBvbiBhbiBlbGVjdGVkIG5vZGUsIHRlcm1lZA0KPiAgICB0aGUg QXJlYSBMZWFkZXIsIG9yIGluIGEgZGlzdHJpYnV0ZWQgbWFubmVyIG9uIGFsbCBub2RlcyB0aGF0 IGFyZQ0KPiAgICBzdXBwb3J0aW5nIER5bmFtaWMgRmxvb2RpbmcuDQo+ID09DQo+IA0KPiBCZWNh dXNlIHRoaXMgaXMgb25seSBvbmUgd2F5IHRvIHNvbHZlIHRoZSBwcm9ibGVtLi4uIFRoZSBwcm9j ZXNzIG91dGxpbmVkIGluDQo+IHRoZSBkcmFmdCBJIGp1c3QgcHVibGlzaGVkIGlzIGEgZGlmZmVy ZW50IGFuZCBzaW1wbGVyIHdheSB0aGF0IGFwcGxpZXMgdG8gYSB3aWRlcg0KPiByYW5nZSBvZiB0 b3BvbG9naWVzIHRoYW4gdGhlIGR5bmFtaWMgZmxvb2RpbmcgZHJhZnQgZG9lcywgYWZhaWN0Lg0K PiANCj4g8J+YiiAvcg0KPiANCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IExzciBtYWlsaW5nIGxpc3QNCj4gTHNyQGlldGYub3JnDQo+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbHNyDQo=